Best practice device tree design for display subsystems/DRM

Russell King rmk at arm.linux.org.uk
Tue Jul 2 12:19:23 PDT 2013


On Tue, Jul 02, 2013 at 08:42:55PM +0200, Jean-Francois Moine wrote:
> It seems that you did not look at the NVIDIA Tegra driver (I got its
> general concept for my own driver, but I used a simple atomic counter):
> 
> - at probe time, the main driver (drivers/gpu/host1x/drm/drm.c) scans
>   the DT and finds its external modules. These ones are put in a
>   "clients" list.
> 
> - when loaded, the other modules register themselves into the main
>   driver. This last one checks if each module is in the "client" list.
>   If so, the module is moved from the "client" to an "active" list".
> 
> - when the "client" list is empty, this means all modules are started,
>   and, so, the main driver starts the drm stuff.
> 
> The active list is kept for module unloading.

Please tell me how this works with the two LCD controllers if you wish
to drive the two LCD controllers as entirely separate devices.  Given
that the above requires the use of global data in the driver, how do
you distinguish between the two?

> Putting "phandle"s in the 'display' seems more flexible (I did not do so
> because I knew the hardware - 2 LCDs and the dcon/ire).

Except you haven't looked at the bigger picture - the Armada 510 is
unusual in that it has two LCD controllers and the DCON.  All of the
other SoCs using this IP block that I've been able to research have
only one LCD controller and no DCON.  I don't think they even have an
IRE (image rotation engine) either.

Neither have you considered the case where you may wish to keep the
two LCD controllers entirely separate (eg, you want X to drive one
but something else on the other.)  X drives the DRM device as a whole,
including all CRTCs which make up that device - with them combined
into one DRM device, you can't ask X to leave one controller alone
because you're doing something else with it.  (This is just the simple
extension of the common case of a single LCD controller, so it's
really nothing special.)

So, the unusual case _is_ the Armada 510 with its two LCD controllers
and DCON which we _could_ work out some way of wrapping up into one
DRM device, or we could just ignore the special case, ignore the DCON
and just keep the two LCD CRTCs as two separate and independent DRM
devices.

I'm actually starting to come towards the conclusion that we should go
for the easiest solution, which is the one I just mentioned, and forget
trying to combine these devices into one super DRM driver.

-- 
Russell King


More information about the dri-devel mailing list