On 07/03/13 11:52, Russell King wrote:
On Wed, Jul 03, 2013 at 11:02:42AM +0200, Sascha Hauer 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.
And if we listen to that argument, then this problem is basically
impossible to solve sanely.
Are we really saying that we have no acceptable way to represent
componentized devices in DT? If that's true, then DT fails to represent
quite a lot of ARM hardware, and frankly we shouldn't be using it. I
can't believe that's true though.
I think DT is able to describe componentized devices, as long as you
ignore DRM/fbdev/ASoC's demands and try to have a look at the HW without
any specific backend in mind.
We both had a similar discussion about ASoC's separation of bus-side and
codec-side subdevices. In HW, there is no such separation but one single
audio controller (at least on Dove). Moreover, a full featured, again
virtual, sound card comprises a lot more than just what is in the SoC.
There is external codecs, jacks, aso.
The problem is that even with an ASoC like approach, that doesn't work
here because there's no way to know how many "components" to expect.
That's what the "supernode" is doing - telling us what components group
together to form a device.
True. The supernode forms a virtual device on top of the individual
components of both SoC and board. For the driver subsystem, all that is
required should be probed by starting from the supernode. If what is
found is not sufficient for the driver subsystem to register a working
subsystem device, bail out. If there is more than you expect, ignore
it and cross your fingers. IMHO DT is not the solution for describing
the world, but it is sufficient for any subsystem driver to find what
it needs to know.
Moreover, if you pay attention to my proposal, what you will realise is
that it isn't DRM specific - it's totally subsystem agnostic. All it's
doing is collecting a set of other devices together and only then
publishing a device representing the full set of sub-devices.
Now think about that: what is DRM specific about that solution? What
is the DRM specific about "collecting a set of devices together and
publishing a new device" ?
How is this not "describing the hardware"? If I attach a HDMI transceiver
to the DCON which is then connected to LCD0, is it not "describing the
hardware" to put into DT that LCD0, DCON, and the HDMI transceiver are
all connected together and therefore are required? One of the points of
DT after all is that it can and should be used to represent the
relationship between devices.
No - using the tree approach doesn't work, because LCD0, LCD1 and DCON
are all on the same physical bus, but are themselves connected together.
If you like, there are multiple heirarchies here - there's the bus
heirarchy, and then there's the device heirarchy. Both of these
heirarchies need to be represented in DT, otherwise you're not describing
the hardware properly.
IMHO DT is more than describing physical connections between devices but
also describing logical connections between devices. While, for example,
a SATA bus master could happily do DMA writes to the GPIO registers just
because it is physically connected to it, it makes no sense. OTOH an LED
connected to a gpio pin is not directly connected to the GPIO register
but at least needs to know who to ask for toggling the line.
I know there may be better examples than those above, but describing
a virtual video card with a supernode connecting separate devices is
sane and sound to me. It is done in a lot other driver subsystems just
the same way, DRM or fbdev is no different from that.
Also, maybe my point-of-view is influenced by how it is done on Marvell
SoCs/boards but I somehow consider it as a worst-case (maybe even
common case for SoCs in general).
Sebastian
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
