Re: [RFC v2 0/5] Common Display Framework

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 3422 bytes --]

On 2012-11-23 21:56, Thierry Reding wrote:
> On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> [...]
>> Display entities are accessed by driver using notifiers. Any driver can
>> register a display entity notifier with the CDF, which then calls the notifier
>> when a matching display entity is registered. The reason for this asynchronous
>> mode of operation, compared to how drivers acquire regulator or clock
>> resources, is that the display entities can use resources provided by the
>> display driver. For instance a panel can be a child of the DBI or DSI bus
>> controlled by the display device, or use a clock provided by that device. We
>> can't defer the display device probe until the panel is registered and also
>> defer the panel device probe until the display is registered. As most display
>> drivers need to handle output devices hotplug (HDMI monitors for instance),
>> handling other display entities through a notification system seemed to be the
>> easiest solution.
>>
>> Note that this brings a different issue after registration, as display
>> controller and display entity drivers would take a reference to each other.
>> Those circular references would make driver unloading impossible. One possible
>> solution to this problem would be to simulate an unplug event for the display
>> entity, to force the display driver to release the dislay entities it uses. We
>> would need a userspace API for that though. Better solutions would of course
>> be welcome.
> 
> Maybe I don't understand all of the underlying issues correctly, but a
> parent/child model would seem like a better solution to me. We discussed
> this back when designing the DT bindings for Tegra DRM and came to the
> conclusion that the output resource of the display controller (RGB,
> HDMI, DSI or TVO) was the most suitable candidate to be the parent of
> the panel or display attached to it. The reason for that decision was
> that it keeps the flow of data or addressing of nodes consistent. So the
> chain would look something like this (on Tegra):
> 
> 	CPU
> 	+-host1x
> 	  +-dc
> 	    +-rgb
> 	    | +-panel
> 	    +-hdmi
> 	      +-monitor
> 
> In a natural way this makes the output resource the master of the panel
> or display. From a programming point of view this becomes quite easy to
> implement and is very similar to how other busses like I2C or SPI are
> modelled. In device tree these would be represented as subnodes, while
> with platform data some kind of lookup could be done like for regulators
> or alternatively a board setup registration mechanism like what's in
> place for I2C or SPI.

You didn't explicitly say it, but I presume you are talking about the
device model for panels, not just how to refer to the outputs.

How would you deal with a, say, DPI panel that is controlled via I2C or
SPI? You can have the panel device be both a panel device, child of a
RGB output, and an i2c device.

The model you propose is currently used in omapdss, and while it seems
simple and logical, it's not that simple with panels/chips with separate
control and data busses.

I think it makes more sense to consider the device as a child of the
control bus. So a DPI panel controlled via I2C is an I2C device, and it
just happens to use a DPI video output as a resource (like it could use
a regulator, gpio, etc).

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]