linux-sh.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-media@vger.kernel.org, Hans Verkuil <hverkuil@xs4all.nl>,
	Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Sylwester Nawrocki <sylvester.nawrocki@gmail.com>,
	linux-sh@vger.kernel.org, Magnus Damm <magnus.damm@gmail.com>,
	Sakari Ailus <sakari.ailus@iki.fi>,
	Prabhakar Lad <prabhakar.lad@ti.com>
Subject: Re: [PATCH 1/6 v4] media: V4L2: support asynchronous subdevice registration
Date: Tue, 08 Jan 2013 10:35:42 +0000	[thread overview]
Message-ID: <18858693.KSUhrxG65A@avalon> (raw)
In-Reply-To: <Pine.LNX.4.64.1301081123590.1794@axis700.grange>

On Tuesday 08 January 2013 11:26:57 Guennadi Liakhovetski wrote:
> On Tue, 8 Jan 2013, Laurent Pinchart wrote:
> > On Tuesday 08 January 2013 10:56:43 Guennadi Liakhovetski wrote:
> > > On Tue, 8 Jan 2013, Laurent Pinchart wrote:
> > > > On Tuesday 08 January 2013 10:25:15 Guennadi Liakhovetski wrote:
> > > > > On Tue, 8 Jan 2013, Laurent Pinchart wrote:

[snip]

> > > > > > Could you please explain why you need both a bind notifier and a
> > > > > > bound notifier ? I was expecting a single
> > > > > > v4l2_async_subdev_register() call in subdev drivers (and, thinking
> > > > > > about it, I would probably name it v4l2_subdev_register()).
> > > > > 
> > > > > I think I can, yes. Because between .bind() and .bound() the
> > > > > subdevice driver does the actual hardware probing. So, .bind() is
> > > > > used to make sure the hardware can be accessed, most importantly to
> > > > > provide a clock to the subdevice. You can look at
> > > > > soc_camera_async_bind(). There I'm registering the clock for the
> > > > > subdevice, about to bind. Why I cannot do it before, is because I
> > > > > need subdevice name for clock matching. With I2C subdevices the
> > > > > subdevice name contains the name of the driver, adapter number and
> > > > > i2c address. The latter 2 I've got from host subdevice list. But not
> > > > > the driver name. I thought about also passing the driver name there,
> > > > > but that seemed too limiting to me. I also request regulators there,
> > > > > because before ->bound() the sensor driver, but that could be done
> > > > > on the first call to soc_camera_power_on(), although doing this
> > > > > "first call" thingie is kind of hackish too. I could add one more
> > > > > soc-camera-power helper like soc_camera_prepare() or similar too.
> > > > 
> > > > I think a soc_camera_power_init() function (or similar) would be a
> > > > good idea, yes.
> > > > 
> > > > > So, the main problem is the clock
> > > > > 
> > > > > subdevice name. Also see the comment in soc_camera.c:
> > > > > 	/*
> > > > > 	 * It is ok to keep the clock for the whole soc_camera_device
> > > > > 	 * life-time, in principle it would be more logical to register
> > > > > 	 * the clock on icd creation, the only problem is, that at that
> > > > > 	 * time we don't know the driver name yet.
> > > > > 	 */
> > > > 
> > > > I think we should fix that problem instead of shaping the async API
> > > > around a workaround :-)
> > > > 
> > > > From the subdevice point of view, the probe function should request
> > > > resources, perform whatever initialization is needed (including
> > > > verifying that the hardware is functional when possible), and the
> > > > register the subdev with the code if everything succeeded. Splitting
> > > > registration into bind() and bound() appears a bit as a workaround to
> > > > me.
> > > > 
> > > > If we need a workaround, I'd rather pass the device name in addition
> > > > to the I2C adapter number and address, instead of embedding the
> > > > workaround in this new API.
> > > 
> > > ...or we can change the I2C subdevice name format. The actual need to do
> > > 
> > > 	snprintf(clk_name, sizeof(clk_name), "%s %d-%04x",
> > > 	
> > > 		 asdl->dev->driver->name,
> > > 		 i2c_adapter_id(client->adapter), client->addr);
> > > 
> > > in soc-camera now to exactly match the subdevice name, as created by
> > > v4l2_i2c_subdev_init(), doesn't make me specifically happy either. What
> > > if the latter changes at some point? Or what if one driver wishes to
> > > create several subdevices for one I2C device?
> > 
> > The common clock framework uses %d-%04x, maybe we could use that as well
> > for clock names ?
> 
> And preserve the subdevice names? Then matching would be more difficult
> and less precise. Or change subdevice names too? I think, we can do the
> latter, since anyway at any time only one driver can be attached to an I2C
> device.

That's right. Where else is the subdev name used ?

> > > > > > > +void v4l2_async_subdev_unbind(struct v4l2_async_subdev_list
> > > > > > > *asdl);
> > > > > > > +#endif

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2013-01-08 10:35 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-26 17:49 [PATCH v3 0/6] V4L2 asynchronous probing + soc-camera example Guennadi Liakhovetski
2012-12-26 17:49 ` [PATCH 1/6] media: V4L2: support asynchronous subdevice registration Guennadi Liakhovetski
2013-01-07 10:23   ` [PATCH 1/6 v4] " Guennadi Liakhovetski
2013-01-08  8:10     ` Laurent Pinchart
2013-01-08  9:25       ` Guennadi Liakhovetski
2013-01-08  9:41         ` Laurent Pinchart
2013-01-08  9:56           ` Guennadi Liakhovetski
2013-01-08 10:21             ` Laurent Pinchart
2013-01-08 10:26               ` Guennadi Liakhovetski
2013-01-08 10:35                 ` Laurent Pinchart [this message]
2013-01-08 11:37                   ` Sylwester Nawrocki
2013-01-08 12:41                     ` Laurent Pinchart
2013-01-08 13:15                       ` Sakari Ailus
2013-01-08 21:17                         ` Laurent Pinchart
2013-03-12 16:59                           ` V4L2 subdevice naming (was Re: [PATCH 1/6 v4] media: V4L2: support asynchronous subdevice registrati Guennadi Liakhovetski
2013-01-08 14:27                       ` [PATCH 1/6 v4] media: V4L2: support asynchronous subdevice registration Sylwester Nawrocki
2013-01-08 21:20                         ` Laurent Pinchart
2013-01-08 19:26                 ` Sylwester Nawrocki
2013-01-08 14:52       ` Sylwester Nawrocki
2013-01-08 21:23         ` Laurent Pinchart
2013-01-08 10:06     ` [PATCH 1/6 v5] " Guennadi Liakhovetski
2013-01-10  5:42       ` Prabhakar Lad
2012-12-26 17:49 ` [PATCH 2/6] media: soc-camera: switch I2C subdevice drivers to use v4l2-clk Guennadi Liakhovetski
2013-01-08  8:02   ` Laurent Pinchart
2012-12-26 17:49 ` [PATCH 3/6] soc-camera: add V4L2-async support Guennadi Liakhovetski
2012-12-26 17:49 ` [PATCH 4/6] sh_mobile_ceu_camera: add asynchronous subdevice probing support Guennadi Liakhovetski
2012-12-26 17:49 ` [PATCH 5/6] imx074: support asynchronous probing Guennadi Liakhovetski
2012-12-26 17:49 ` [PATCH 6/6] ARM: shmobile: convert ap4evb to asynchronously register camera subdevices Guennadi Liakhovetski
2013-01-08  4:27   ` Simon Horman
2013-01-08 22:35     ` Guennadi Liakhovetski
2013-01-09  0:04       ` Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18858693.KSUhrxG65A@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=prabhakar.lad@ti.com \
    --cc=s.nawrocki@samsung.com \
    --cc=sakari.ailus@iki.fi \
    --cc=sylvester.nawrocki@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).