Best practice device tree design for display subsystems/DRM
Inki Dae
inki.dae at samsung.com
Wed Jul 3 21:43:20 EST 2013
> -----Original Message-----
> From: Sebastian Hesselbarth [mailto:sebastian.hesselbarth at gmail.com]
> Sent: Wednesday, July 03, 2013 7:53 PM
> To: Russell King
> Cc: Inki Dae; 'Sascha Hauer'; 'Daniel Drake'; 'Jean-Francois Moine';
> devicetree-discuss at lists.ozlabs.org; dri-devel at lists.freedesktop.org
> Subject: Re: Best practice device tree design for display subsystems/DRM
>
> 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
In case of fbdev, framebuffer driver would use lcd0 or lcd1 driver, or lcd0
and lcd1 drivers which are placed in drivers/video/backlight/.
And let's assume the following:
On board A
Display controller ------------- lcd 0
On board B
Display controller ------------- lcd 1
On board C
Display controller ------------- lcd 0 and lcd 1
Without the super node, user could configure Linux kernel through menuconfig
like below;
board A: enabling lcd 0, and disabling lcd 1,
board B: disabling lcd 0, and enabling lcd 1,
board C: enabling lcd 0 and lcd 1.
All we have to do is to configure menuconfig to enable only drivers for
certain board. Why does fbdev need the super node? Please give me comments
if there is my missing point.
Thanks,
Inki Dae
> 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
More information about the devicetree-discuss
mailing list