Best practice device tree design for display subsystems/DRM

[Jean-Francois Moine]

On Tue, 2 Jul 2013 11:43:59 -0600
Daniel Drake <dsd at laptop.org> wrote:

> Hi,

Hi Daniel,

> I'm looking into implementing devicetree support in armada_drm and
> would like to better understand the best practice here.
> 
> Adding DT support for a DRM driver seems to be complicated by the fact
> that DRM is not "hotpluggable" - it is not possible for the drm_device
> to be initialised without an output, with the output connector/encoder
> appearing at some later moment. Instead, the connectors/encoders must
> be fully loaded before the drm_driver load function returns. This
> means that we cannot drive the individual display components through
> individual, separate modules - we need a way to control their load
> order.
> 
> Looking at existing DRM drivers:
	[snip]

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.

> Russell King suggested an alternative design for armada_drm. If all
> display components are represented within the same "display"
> super-node, we can examine the DT during drm_device initialisation and
> initialise the appropriate output components. In this case, the output
> components would not be registered as platform drivers.
> 
> The end result would be something similar to exynos/tilcdc (i.e.
> drm_driver figuring out its output in the appropriate moment), however
> the hackyness of using global storage to store output devices before
> drm_driver is ready is avoided. And there is the obvious difference in
> devicetree layout, which would look something like:
> 
> display {
>   compatible = "marvell,armada-510-display";
>   clocks = <&ext_clk0>, <&lcd_pll_clk>;
>   lcd0 {
>     compatible = "marvell,armada-510-lcd";
>     reg = <0xf1820000 0x1000>;
>     interrupts = <47>;
>   };
>   lcd1 {
>     compatible = "marvell,armada-510-lcd";
>     reg = <0xf1810000 0x1000>;
>     interrupts = <46>;
>   };
>   dcon {
>     compatible = "marvell,armada-510-dcon";
>     reg = <...>;
>   };
> };

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).

But, anyway, this does not solve the exact moment the modules are
loaded at startup time.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/