From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guennadi Liakhovetski Date: Mon, 08 Oct 2012 16:00:45 +0000 Subject: Re: [PATCH 05/14] media: add a V4L2 OF parser Message-Id: List-Id: References: <1348754853-28619-1-git-send-email-g.liakhovetski@gmx.de> <201210081653.55984.hverkuil@xs4all.nl> <201210081741.43546.hverkuil@xs4all.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Hans Verkuil Cc: linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, Mark Brown , Magnus Damm , Laurent Pinchart , Sylwester Nawrocki , Sylwester Nawrocki , linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On Mon, 8 Oct 2012, Guennadi Liakhovetski wrote: > On Mon, 8 Oct 2012, Hans Verkuil wrote: > > > On Mon October 8 2012 17:15:53 Guennadi Liakhovetski wrote: [snip] > > > No, I don't think there is a way to get a device pointer from a DT node. > > > > Not a device pointer, but the i2c bus and i2c address. With that information > > you can get the i2c_client, and with that you can get the subdev pointer. > > How? How can you get a client pointer from adapter and i2c device address? > I haven't found anything suitable in i2c.h. Ok, you could use of_find_i2c_device_by_node(), but the second argument remains - if you need notifiers in one case, I don't think it makes sense to implement multiple methods. Thanks Guennadi > > If there is no way to get that information from the proposed V4L2 DT, then > > it needs to be modified since a bridge driver really needs to know which > > subdevs it has to register with the v4l2_device struct. That information is > > also board specific so it should be part of the DT. > > > > > > > > > In my view you cannot do a proper initialization unless you have both the > > > > bridge driver and all subdev drivers loaded and instantiated. They need one > > > > another. So I am perfectly fine with letting the probe function do next to > > > > nothing and postponing that until register() is called. I2C and actual probing > > > > to check if it's the right device is a bad idea in general since you have no > > > > idea what a hardware access to an unknown i2c device will do. There are still > > > > some corner cases where that is needed, but I do not think that that is an > > > > issue here. > > > > > > > > It would simplify things a lot IMHO. Also note that the register() op will > > > > work with any device, not just i2c. That may be a useful property as well. > > > > > > And what if the subdevice device is not yet instantiated by OF by the time > > > your bridge driver probes? > > > > That is where you still need to have a bus notifier mechanism. You have to be > > able to wait until all dependent drivers are loaded/instantiated, > > No, drivers are not the problem, as you say, you can load them. Devices > are the problem. You don't know when they will be registered. > > > or > > alternatively you have to be able to load them explicitly. But this should > > be relatively easy to implement in a generic manner. > > So, if you need notifiers anyway, why not use them in all cases instead of > mixing multiple methods? > > Thanks > Guennadi > > > I still think this sucks (excuse my language), but I see no way around it as > > long as there is no explicit probe order one can rely on. > > > > Regards, > > > > Hans > > > > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Guennadi Liakhovetski Subject: Re: [PATCH 05/14] media: add a V4L2 OF parser Date: Mon, 8 Oct 2012 18:00:45 +0200 (CEST) Message-ID: References: <1348754853-28619-1-git-send-email-g.liakhovetski@gmx.de> <201210081653.55984.hverkuil@xs4all.nl> <201210081741.43546.hverkuil@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: Hans Verkuil Cc: linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, Mark Brown , Magnus Damm , Laurent Pinchart , Sylwester Nawrocki , Sylwester Nawrocki , linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org On Mon, 8 Oct 2012, Guennadi Liakhovetski wrote: > On Mon, 8 Oct 2012, Hans Verkuil wrote: > > > On Mon October 8 2012 17:15:53 Guennadi Liakhovetski wrote: [snip] > > > No, I don't think there is a way to get a device pointer from a DT node. > > > > Not a device pointer, but the i2c bus and i2c address. With that information > > you can get the i2c_client, and with that you can get the subdev pointer. > > How? How can you get a client pointer from adapter and i2c device address? > I haven't found anything suitable in i2c.h. Ok, you could use of_find_i2c_device_by_node(), but the second argument remains - if you need notifiers in one case, I don't think it makes sense to implement multiple methods. Thanks Guennadi > > If there is no way to get that information from the proposed V4L2 DT, then > > it needs to be modified since a bridge driver really needs to know which > > subdevs it has to register with the v4l2_device struct. That information is > > also board specific so it should be part of the DT. > > > > > > > > > In my view you cannot do a proper initialization unless you have both the > > > > bridge driver and all subdev drivers loaded and instantiated. They need one > > > > another. So I am perfectly fine with letting the probe function do next to > > > > nothing and postponing that until register() is called. I2C and actual probing > > > > to check if it's the right device is a bad idea in general since you have no > > > > idea what a hardware access to an unknown i2c device will do. There are still > > > > some corner cases where that is needed, but I do not think that that is an > > > > issue here. > > > > > > > > It would simplify things a lot IMHO. Also note that the register() op will > > > > work with any device, not just i2c. That may be a useful property as well. > > > > > > And what if the subdevice device is not yet instantiated by OF by the time > > > your bridge driver probes? > > > > That is where you still need to have a bus notifier mechanism. You have to be > > able to wait until all dependent drivers are loaded/instantiated, > > No, drivers are not the problem, as you say, you can load them. Devices > are the problem. You don't know when they will be registered. > > > or > > alternatively you have to be able to load them explicitly. But this should > > be relatively easy to implement in a generic manner. > > So, if you need notifiers anyway, why not use them in all cases instead of > mixing multiple methods? > > Thanks > Guennadi > > > I still think this sucks (excuse my language), but I see no way around it as > > long as there is no explicit probe order one can rely on. > > > > Regards, > > > > Hans > > > > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from moutng.kundenserver.de ([212.227.126.186]:54859 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751200Ab2JHQBB (ORCPT ); Mon, 8 Oct 2012 12:01:01 -0400 Date: Mon, 8 Oct 2012 18:00:45 +0200 (CEST) From: Guennadi Liakhovetski To: Hans Verkuil cc: Sylwester Nawrocki , Sylwester Nawrocki , linux-media@vger.kernel.org, devicetree-discuss@lists.ozlabs.org, Laurent Pinchart , Magnus Damm , linux-sh@vger.kernel.org, Mark Brown , Stephen Warren , Arnd Bergmann , Grant Likely Subject: Re: [PATCH 05/14] media: add a V4L2 OF parser In-Reply-To: Message-ID: References: <1348754853-28619-1-git-send-email-g.liakhovetski@gmx.de> <201210081653.55984.hverkuil@xs4all.nl> <201210081741.43546.hverkuil@xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-media-owner@vger.kernel.org List-ID: On Mon, 8 Oct 2012, Guennadi Liakhovetski wrote: > On Mon, 8 Oct 2012, Hans Verkuil wrote: > > > On Mon October 8 2012 17:15:53 Guennadi Liakhovetski wrote: [snip] > > > No, I don't think there is a way to get a device pointer from a DT node. > > > > Not a device pointer, but the i2c bus and i2c address. With that information > > you can get the i2c_client, and with that you can get the subdev pointer. > > How? How can you get a client pointer from adapter and i2c device address? > I haven't found anything suitable in i2c.h. Ok, you could use of_find_i2c_device_by_node(), but the second argument remains - if you need notifiers in one case, I don't think it makes sense to implement multiple methods. Thanks Guennadi > > If there is no way to get that information from the proposed V4L2 DT, then > > it needs to be modified since a bridge driver really needs to know which > > subdevs it has to register with the v4l2_device struct. That information is > > also board specific so it should be part of the DT. > > > > > > > > > In my view you cannot do a proper initialization unless you have both the > > > > bridge driver and all subdev drivers loaded and instantiated. They need one > > > > another. So I am perfectly fine with letting the probe function do next to > > > > nothing and postponing that until register() is called. I2C and actual probing > > > > to check if it's the right device is a bad idea in general since you have no > > > > idea what a hardware access to an unknown i2c device will do. There are still > > > > some corner cases where that is needed, but I do not think that that is an > > > > issue here. > > > > > > > > It would simplify things a lot IMHO. Also note that the register() op will > > > > work with any device, not just i2c. That may be a useful property as well. > > > > > > And what if the subdevice device is not yet instantiated by OF by the time > > > your bridge driver probes? > > > > That is where you still need to have a bus notifier mechanism. You have to be > > able to wait until all dependent drivers are loaded/instantiated, > > No, drivers are not the problem, as you say, you can load them. Devices > are the problem. You don't know when they will be registered. > > > or > > alternatively you have to be able to load them explicitly. But this should > > be relatively easy to implement in a generic manner. > > So, if you need notifiers anyway, why not use them in all cases instead of > mixing multiple methods? > > Thanks > Guennadi > > > I still think this sucks (excuse my language), but I see no way around it as > > long as there is no explicit probe order one can rely on. > > > > Regards, > > > > Hans > > > > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/