Best practice device tree design for display subsystems/DRM

Grant Likely grant.likely at secretlab.ca
Fri Jul 5 01:43:36 PDT 2013


On Wed, Jul 3, 2013 at 10:02 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> On Wed, Jul 03, 2013 at 05:57:18PM +0900, Inki Dae wrote:
>> > video {
>> >     /* Single video card w/ multiple lcd controllers */
>> >     card0 {
>> >             compatible = "marvell,armada-510-display";
>> >             reg = <0 0x3f000000 0x1000000>; /* video-mem hole */
>> >             /* later: linux,video-memory-size = <0x1000000>; */
>> >             marvell,video-devices = <&lcd0 &lcd1 &dcon>;
>> >     };
>> >
>> >     /* OR: Multiple video card w/ single lcd controllers */
>> >     card0 {
>> >             compatible = "marvell,armada-510-display";
>> >             ...
>> >             marvell,video-devices = <&lcd0>;
>> >     };
>> >
>> >     card1 {
>> >             compatible = "marvell,armada-510-display";
>> >             ...
>> >             marvell,video-devices = <&lcd1>;
>> >     };
>> > };
>>
>> Sorry but I'd like to say that this cannot be used commonly. Shouldn't you
>> really consider Linux framebuffer or other subsystems? The above dtsi file
>> is specific to DRM subsystem. And I think the dtsi file has no any
>> dependency on certain subsystem so board dtsi file should be considered for
>> all device drivers based on other subsystems: i.e., Linux framebuffer, DRM,
>> and so no. So I *strongly* object to it. All we have to do is to keep the
>> dtsi file as is, and to find other better way that can be used commonly in
>> DRM.
>
> +1 for not encoding the projected usecase of the graphics subsystem into
> the devicetree. Whether the two LCD controllers shall be used together
> or separately should not affect the devicetree. devicetree is about
> hardware description, not configuration.

It is however relevant to encode information about how devices are
related to each other. That could be an orthogonal binding though to
describe how displays are oriented relative to each other.

g.


More information about the dri-devel mailing list