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
