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 10:45:40 +0200 Message-ID: <51D53634.5040405@gmail.com> References: <20130702204255.2044c01b@armhf> <20130702191923.GD13924@flint.arm.linux.org.uk> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130704083307.GH10414-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 10:33, Sascha Hauer wrote: > On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote: >>>> 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. >> >> 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. > > 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, olpc just needs lcd0 and has built-in hdmi in the SoC (IIRC). The driver needs to know what to wait for, and that is given by the DT super-node. I consider kernels with missing drivers compared to what is given in the DT as broken setup. You cannot complain about missing SATA if you leave out SATA driver, or - if you implemented the driver into two parts - leave out one of the two SATA driver parts. Sebastian