On 07/04/13 11:23, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 11:10:35AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:53, Sascha Hauer wrote:
On Thu, Jul 04, 2013 at 10:45:40AM +0200, Sebastian Hesselbarth wrote:
On 07/04/13 10:33, Sascha Hauer wrote:
A componentized device never completes and it doesn't have to. A
componentized device can start once there is a path from an input
(crtc, i2s unit) to an output (connector, speaker).
Consider what happens with a supernode approach. Your board provides a
devicetree which has a supernode with hdmi and lvds referenced. Now you
build a kernel with the hdmi driver disabled. You would still expect the
lvds port to be working without having the kernel wait for the supernode
being complete.
Without supernode you can just start once you have everything between
the crtc and lvds nodes. If later a hdmi device joins in then you can
either notify the users (provided the DRM/KMS API supports it) or just
ignore it until the DRM device gets reopened.
Sascha,
that is what it is all about. You assume you a priori know what devices
will be required for the componentized device to successfully output
a video stream.
We have shown setups where you don't know what is required. Cubox
_needs_ lcd0 and hdmi-transmitter,
Then your Cubox devicetree has a link (that's how they call it in v4l2,
a link doesn't necessarily is a direct connection but can have multiple
devices in it) between lcd0 and hdmi.
I haven't looked up v4l2 "link" yet. But (a) if it is a separate node
how is that different from the "super-node" we are talking about or (b)
if it is a property, where do you put it?
Sorry, I should have explained this. The basic idea the v4l2 guys are
following is that they describe their hardware pipelines in the devicetree.
Each device can have ports which are connected via links. In the
devicetree a link basically becomes a phandle (a remote device will have
a phandle pointing back to the original device). For an overview have a
look at
Documentation/devicetree/bindings/media/video-interfaces.txt
With this you can describe the whole graph of devices you have in the
devicetree. The examples in this file have a path from a camera sensor
via a MIPI converter to a capture interface.
The difference to a supernode is that this approach describes the data
flow in the devicetree so that we can iterate over it to find links
between source and sink rather than relying on a list of subdevices to
be completed.
Agree. But that is not that different from linux,video-external-encoder
property I made up, except that the name is different.
And, I still see no way with that source/sink linking _alone_ how to
tell that either lcd0 and lcd1 act as a _single_ video card or lcd0 and
lcd1 are used in a _two_ video card setup.
There is no single device node on Dove that would sufficiently act as
the top node for a working video card on all boards. And there is no
framebuffer node to link each of the lcd0/1 nodes to.
That is what the super-node is for, form a virtual device called
video card to act as a container for all those SoC devices that are
not sufficient for a working video setup on their own.
If lcd0 needs that hdmi-transmitter you link it to the lcd0 node -
not the super-node. If lcd0 needs some pll clock you link it to the
lcd0 node - again not the super-node.
The super-node(s) just connects all SoC devices that shall be part of
your board-specific video card(s) - for Dove that is any combination of
lcd0, lcd0, dcon and video memory allocation.
Sebastian
Sebastian
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
