From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Hesselbarth Subject: Re: Best practice device tree design for display subsystems/DRM Date: Thu, 04 Jul 2013 11:40:17 +0200 Message-ID: <51D54301.8080902@gmail.com> References: <51D330AC.5060903@gmail.com> <51D348F5.2080205@gmail.com> <00ae01ce77cb$524d57f0$f6e807d0$%dae@samsung.com> <20130703090242.GM516@pengutronix.de> <20130703095248.GG13924@flint.arm.linux.org.uk> <20130704083307.GH10414@pengutronix.de> <51D53634.5040405@gmail.com> <20130704085313.GY516@pengutronix.de> <51D53C0B.6060106@gmail.com> <20130704092305.GI10414@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130704092305.GI10414-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Sascha Hauer Cc: 'Jean-Francois Moine' , 'Daniel Drake' , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Inki Dae , Russell King List-Id: devicetree@vger.kernel.org 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