Re: [PATCH v2 3/3] drm/edid: Implement SCDC Read Request capability detection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 05, 2016 at 02:19:48PM +0000, Jose Abreu wrote:
> Hi Thierry,
> 
> 
> On 05-12-2016 11:14, Thierry Reding wrote:
> > On Mon, Dec 05, 2016 at 11:06:15AM +0000, Jose Abreu wrote:
> >> Hi Thierry,
> >>
> >>
> >> Do you think while you are at it you could implement a
> >> set_scrambling() callback? It should be pretty straight forward:
> >> you read the SCDC_TMDS_CONFIG reg, do a mask, and then write it
> >> again.
> >>
> >>
> >> I think this is an important feature that we should have.
> > Yeah, agreed. I was actually thinking about going one step further and
> > provide more of the polling functionality as a helper. Even if we have
> > accessors that wrap the low-level functionality, most drivers would
> > still have to provide their own delayed workqueue to deal with sinks
> > (or sources) that don't support read requests. Having this in standard
> > helpers would help reduce the boilerplate a lot further.
> >
> > Does your hardware by any chance support read requests on SCDC? It'd be
> > interesting to see how that works in practice. Unfortunately Tegra does
> > not seem to support it.
> >
> > Thierry
> 
> Yes, my HW supports it though I don't have the setup here to test
> right now (but it was used before). In our controller it is
> pretty straight forward:
>     1) Enable interrupt for rr indication [source]
>     2) Enable update read on a rr [source]
>     3) Set rr flag in the sink [sink]
> 
> Point 2) makes it clear: Whenever we get a rr then the source
> will automatically read the sink and dump the contents read in
> the regbank. Then the SW gets an interrupt and it should read the
> contents of the registers.

Yes, I suspect that there will be three types of setups:

	1) fully supported and integrated RR capability (such as in your
	   case)

	2) external I2C controller with the means of detecting the read
	   request (and signal via an interrupt)

	3) no read request support at all, in which case a delayed work
	   queue is needed to poll periodically


For cases 1) and 3) it's probably only useful to have a helper to enable
scrambling. For 2) there might be some use in having a helper that can
setup the delayed work queue.

Given that we don't have any implementation yet, maybe it's better to
defer the creation of helpers until we see common patterns emerge. The
helper to enable scrambling could be useful in any case, though, so I'll
add one.

Thierry

Attachment: signature.asc
Description: PGP signature

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux