From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sylwester Nawrocki Date: Thu, 11 Apr 2013 19:58:50 +0000 Subject: Re: [PATCH v8 0/7] V4L2 clock and async patches and soc-camera example Message-Id: <516715FA.8000901@gmail.com> List-Id: References: <1365433538-15975-1-git-send-email-g.liakhovetski@gmx.de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Guennadi Liakhovetski Cc: linux-media@vger.kernel.org, Laurent Pinchart , Hans Verkuil , Sylwester Nawrocki , linux-sh@vger.kernel.org, Magnus Damm , Sakari Ailus , Prabhakar Lad Hi Guennadi, On 04/11/2013 11:59 AM, Guennadi Liakhovetski wrote: > Hi all > > On Mon, 8 Apr 2013, Guennadi Liakhovetski wrote: > >> > Mostly just a re-spin of v7 with minor modifications. >> > >> > Guennadi Liakhovetski (7): >> > media: V4L2: add temporary clock helpers >> > media: V4L2: support asynchronous subdevice registration >> > media: soc-camera: switch I2C subdevice drivers to use v4l2-clk >> > soc-camera: add V4L2-async support >> > sh_mobile_ceu_camera: add asynchronous subdevice probing support >> > imx074: support asynchronous probing >> > ARM: shmobile: convert ap4evb to asynchronously register camera >> > subdevices > > So far there haven't been any comments to this, and Mauro asked to push > all non-fixes to him by tomorrow. So, if at least the API is now ok, we > could push this to 3.10, at least the core patches 1 and 2. Then during > 3.10 we could look at porting individual drivers on top of this. This patch series has significantly improved over time but I'm not sure it is all ready to merge it at this moment. At least it doesn't make sense to me to merge it without any users. The purpose of an introduction of this whole asynchronous probing concept was to add support for the device tree based systems. However there is no patch in this series that would be adding device tree support to some V4L2 driver. That's a minor issue though I think. A significant blocking point IMHO is that this API is bound to the circular dependency issue between a sub-device and the host driver. I think we should have at least some specific ideas on how to resolve it before pushing the API upstream. Or are there any already ? One of the ideas I had was to make a sub-device driver drop the reference it has to the clock provider module (the host) as soon as it gets registered to it. But it doesn't seem straightforward with the common clock API. Other option is a sysfs attribute at a host driver that would allow to release its sub-device(s). But it sounds a bit strange to me to require userspace to touch some sysfs attributes before being able to remove some modules. Something probably needs to be changed at the high level design to avoid this circular dependency. Thanks, Sylwester