Best practice device tree design for display subsystems/DRM

[Sebastian Hesselbarth]

On 07/03/13 11:53, Russell King wrote:
> On Wed, Jul 03, 2013 at 06:48:41PM +0900, Inki Dae wrote:
>> That's not whether we can write device driver or not. dtsi is common spot in
>> other subsystems. Do you think the cardX node is meaningful to other
>> subsystems?
>
> Yes, because fbdev could also use it to solve the same problem which we're
> having with DRM.

Inki,

I do not understand why you keep referring to the SoC dtsi. Im my
example, I said that it is made up and joined from both SoC dtsi and
board dts.

So, of course, lcd controller nodes and dcon are part of dove.dtsi
because they are physically available on every Dove SoC.

Also, the connection from lcd0 to the external HDMI encoder node
is in the board dts because you can happily build a Dove SoC board
with a different HDMI encoder or with no encoder at all.

The video-card super node is not in any way specific to DRM and
describes a virtual graphics card comprising both SoC and board
components (on a per-board basis). You can have both DRM or fbdev
use that virtual video card node to register your subsystem drivers
required to provide video output.

I agree to what Sascha said, the decision to put one or two
virtual graphics card in the device tree depending on the use
case is sketchy. You can have one card/two card on the same
board, so at this point device tree is not describing HW but
use case.

But honestly, I see no way around it and it is the only way
to allow to even have the decision for one or two cards at all.
There is no way for auto-probing the users intention...

Sebastian