From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from perceval.ideasonboard.com ([95.142.166.194]:40169 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751099Ab3AHIbg (ORCPT ); Tue, 8 Jan 2013 03:31:36 -0500 From: Laurent Pinchart To: Sascha Hauer Cc: Rob Clark , Thomas Petazzoni , Linux Fbdev development list , Benjamin Gaignard , Tom Gall , Kyungmin Park , "dri-devel@lists.freedesktop.org" , Ragesh Radhakrishnan , Tomi Valkeinen , Philipp Zabel , Maxime Ripard , Vikas Sajjan , Sumit Semwal , Sebastien Guiriec , "linux-media@vger.kernel.org" Subject: Re: [RFC v2 0/5] Common Display Framework Date: Tue, 08 Jan 2013 09:33:13 +0100 Message-ID: <8761492.9kNDi4CAnk@avalon> In-Reply-To: <20121228000404.GY26326@pengutronix.de> References: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com> <20121228000404.GY26326@pengutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-media-owner@vger.kernel.org List-ID: On Friday 28 December 2012 01:04:04 Sascha Hauer wrote: > On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote: > > On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer wrote: > > > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: > > >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart > > > > > > This implies that the master driver knows all potential subdevices, > > > something which is not true for SoCs which have external i2c encoders > > > attached to unrelated i2c controllers. > > > > well, it can be brute-forced.. ie. drm driver calls common > > register_all_panels() fxn, which, well, registers all the > > panel/display subdev's based on their corresponding CONFIG_FOO_PANEL > > defines. If you anyways aren't building the panels as separate > > modules, that would work. Maybe not the most *elegant* approach, but > > simple and functional. > > > > I guess it partly depends on the structure in devicetree. If you are > > > > assuming that the i2c encoder belongs inside the i2c bus, like: > > &i2cN { > > > > foo-i2c-encoder { > > > > .... > > > > }; > > > > }; > > > > and you are letting devicetree create the devices, then it doesn't > > quite work. I'm not entirely convinced you should do it that way. > > Really any device like that is going to be hooked up to at least a > > couple busses.. i2c, some sort of bus carrying pixel data, maybe some > > gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and > > then use phandle stuff to link it to the various other busses it > > > > needs: > > mydrmdev { > > foo-i2c-encoder { > > i2c = <&i2cN>; > > gpio = <&gpioM 2 3> > > ... > > }; > > }; > > This seems to shift initialization order problem to another place. Here we > have to make sure the controller is initialized before the drm driver. Same > with suspend/resume. > > It's not only i2c devices, also platform devices. On i.MX for example we > have a hdmi transmitter which is somewhere on the physical address space. > > I think grouping the different units together in a devicetree blob because > we think they might form a logical virtual device is not going to work. It > might make it easier from a drm perspective, but I think doing this will > make for a lot of special cases. What will happen for example if you have > two encoder devices in a row to configure? The foo-i2c-encoder would then > get another child node. > > Right now the devicetree is strictly ordered by (control-, not data-) bus > topology. Linux has great helper code to support this model. Giving up this > help to brute force a different topology and then trying to fit the result > back into the Linux Bus hierarchy doesn't sound like a good idea to me. I agree. The Linux device model is architectured around a control bus based tree, I don't want to change that. With devices hooked up on several busses we will have dependency issues anyway, regardless of how we describe them in DT. If we hook up the nodes from a data bus perspective we will run into control bus dependency issues. It's thus better in my opinion to keep the classic control bus based model and solve the data bus dependency issues. > > ok, admittedly that is a bit different from other proposals about how > > this all fits in devicetree.. but otoh, I'm not a huge believer in > > letting something that is supposed to make life easier (DT), actually > > make things harder or more complicated. Plus this CDF stuff all needs > > to also work on platforms not using OF/DT. > > Right, but every other platform I know of is also described by its bus > topology, be it platform device based or PCI or maybe even USB based. > > CDF has to solve the same problem as ASoC and soc-camera: subdevices for > a virtual device can come from many different corners of the system. BTW > one example for a i2c encoder would be the SiI9022 which could not only > be part of a drm device, but also of an ASoC device. -- Regards, Laurent Pinchart From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laurent Pinchart Date: Tue, 08 Jan 2013 08:33:13 +0000 Subject: Re: [RFC v2 0/5] Common Display Framework Message-Id: <8761492.9kNDi4CAnk@avalon> List-Id: References: <1353620736-6517-1-git-send-email-laurent.pinchart@ideasonboard.com> <20121228000404.GY26326@pengutronix.de> In-Reply-To: <20121228000404.GY26326@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Sascha Hauer Cc: Rob Clark , Thomas Petazzoni , Linux Fbdev development list , Benjamin Gaignard , Tom Gall , Kyungmin Park , "dri-devel@lists.freedesktop.org" , Ragesh Radhakrishnan , Tomi Valkeinen , Philipp Zabel , Maxime Ripard , Vikas Sajjan , Sumit Semwal , Sebastien Guiriec , "linux-media@vger.kernel.org" On Friday 28 December 2012 01:04:04 Sascha Hauer wrote: > On Thu, Dec 27, 2012 at 01:57:56PM -0600, Rob Clark wrote: > > On Thu, Dec 27, 2012 at 1:18 PM, Sascha Hauer wrote: > > > On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote: > > >> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart > > > > > > This implies that the master driver knows all potential subdevices, > > > something which is not true for SoCs which have external i2c encoders > > > attached to unrelated i2c controllers. > > > > well, it can be brute-forced.. ie. drm driver calls common > > register_all_panels() fxn, which, well, registers all the > > panel/display subdev's based on their corresponding CONFIG_FOO_PANEL > > defines. If you anyways aren't building the panels as separate > > modules, that would work. Maybe not the most *elegant* approach, but > > simple and functional. > > > > I guess it partly depends on the structure in devicetree. If you are > > > > assuming that the i2c encoder belongs inside the i2c bus, like: > > &i2cN { > > > > foo-i2c-encoder { > > > > .... > > > > }; > > > > }; > > > > and you are letting devicetree create the devices, then it doesn't > > quite work. I'm not entirely convinced you should do it that way. > > Really any device like that is going to be hooked up to at least a > > couple busses.. i2c, some sort of bus carrying pixel data, maybe some > > gpio's, etc. So maybe makes more sense for a virtual drm/kms bus, and > > then use phandle stuff to link it to the various other busses it > > > > needs: > > mydrmdev { > > foo-i2c-encoder { > > i2c = <&i2cN>; > > gpio = <&gpioM 2 3> > > ... > > }; > > }; > > This seems to shift initialization order problem to another place. Here we > have to make sure the controller is initialized before the drm driver. Same > with suspend/resume. > > It's not only i2c devices, also platform devices. On i.MX for example we > have a hdmi transmitter which is somewhere on the physical address space. > > I think grouping the different units together in a devicetree blob because > we think they might form a logical virtual device is not going to work. It > might make it easier from a drm perspective, but I think doing this will > make for a lot of special cases. What will happen for example if you have > two encoder devices in a row to configure? The foo-i2c-encoder would then > get another child node. > > Right now the devicetree is strictly ordered by (control-, not data-) bus > topology. Linux has great helper code to support this model. Giving up this > help to brute force a different topology and then trying to fit the result > back into the Linux Bus hierarchy doesn't sound like a good idea to me. I agree. The Linux device model is architectured around a control bus based tree, I don't want to change that. With devices hooked up on several busses we will have dependency issues anyway, regardless of how we describe them in DT. If we hook up the nodes from a data bus perspective we will run into control bus dependency issues. It's thus better in my opinion to keep the classic control bus based model and solve the data bus dependency issues. > > ok, admittedly that is a bit different from other proposals about how > > this all fits in devicetree.. but otoh, I'm not a huge believer in > > letting something that is supposed to make life easier (DT), actually > > make things harder or more complicated. Plus this CDF stuff all needs > > to also work on platforms not using OF/DT. > > Right, but every other platform I know of is also described by its bus > topology, be it platform device based or PCI or maybe even USB based. > > CDF has to solve the same problem as ASoC and soc-camera: subdevices for > a virtual device can come from many different corners of the system. BTW > one example for a i2c encoder would be the SiI9022 which could not only > be part of a drm device, but also of an ASoC device. -- Regards, Laurent Pinchart