public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Grzeschik <mgr@pengutronix.de>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>,
	Michael Grzeschik <m.grzeschik@pengutronix.de>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	baruch@tkos.co.il
Subject: Re: [PATCH 1/5] mx2_camera: change to register and probe
Date: Wed, 4 Aug 2010 10:53:26 +0200	[thread overview]
Message-ID: <20100804085326.GA10780@pengutronix.de> (raw)
In-Reply-To: <Pine.LNX.4.64.1008041020280.29386@axis700.grange>

On Wed, Aug 04, 2010 at 10:24:50AM +0200, Guennadi Liakhovetski wrote:
> On Wed, 4 Aug 2010, Sascha Hauer wrote:
> 
> > On Wed, Aug 04, 2010 at 01:01:34AM +0200, Guennadi Liakhovetski wrote:
> > > On Tue, 3 Aug 2010, Michael Grzeschik wrote:
> > > 
> > > > On Tue, Aug 03, 2010 at 08:22:13PM +0200, Guennadi Liakhovetski wrote:
> > > > > On Tue, 3 Aug 2010, Michael Grzeschik wrote:
> > > > > 
> > > > > > change this driver back to register and probe, since some platforms
> > > > > > first have to initialize an already registered power regulator to switch
> > > > > > on the camera.
> > > > > 
> > > > > Sorry, don't see a difference. Can you give an example of two call 
> > > > > sequences, where this change changes the behaviour?
> > > > >
> > > > 
> > > > Yes, when you look at the today posted patch [1] you find the function
> > > > pcm970_baseboard_init_late as an late_initcall. It uses an already
> > > > registred regulator device to turn on the power of the camera before the
> > > > cameras device registration.
> > > > 
> > > > [1] [PATCH 1/2] ARM: i.MX27 pcm970: Add camera support
> > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2010-August/022317.html
> > > 
> > > Sorry again, still don't understand. What I mean is the following: take 
> > > two cases - before and after your patch. What is the difference? As far as 
> > > I know, the difference between platform_driver_probe() and 
> > > platform_driver_register() is just that the probe method gets discarded in 
> > > an __init section, which is suitable for non hotpluggable devices. I don't 
> > > know what the difference this should make for call order. So, that's what 
> > > I am asking about. Can you explain, how this patch changes the call order 
> > > in your case? Can you tell, that in the unpatches case the probe is called 
> > > at that moment, and in the patched case it is called at a different point 
> > > of time and that fixes the problem.
> > 
> > 
> > The following is above platform_driver_probe:
> > 
> >  * Use this instead of platform_driver_register() when you know the device
> >  * is not hotpluggable and has already been registered, and you want to
> >  * remove its run-once probe() infrastructure from memory after the
> >  * driver has bound to the device.
> > 
> > So platform_driver_probe will only call the probe function when the device
> > is already there when this function runs. This is not the case on our board.
> > We have to register the camera in late_initcall (to make sure the needed
> > regulators are already there). During late_initcall time the
> > platform_driver_probe has already run.
> 
> Ok, now I see. I missed the key-phrase: "before the cameras device 
> registration." Ok, in this case, it's certainly a valid reason for the 
> change. Just one more question: wouldn't calling 
> pcm970_baseboard_init_late() from device_initcall fix the problem without 
> requiring to change the driver?

No, sorry but this doesn't solve the problem. I tested it and get an
"unable to get regulator: -19" when i hit on that. The problem is the
device init order. The pcm970_baseboard_init_late comes first and
then the regulator. So i think we should keep that patch.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2010-08-04  8:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-03  9:37 [PATCH 0/5] mx2_camera changes and corrections Michael Grzeschik
2010-08-03  9:37 ` [PATCH 1/5] mx2_camera: change to register and probe Michael Grzeschik
2010-08-03 18:22   ` Guennadi Liakhovetski
2010-08-03 19:57     ` Michael Grzeschik
2010-08-03 23:01       ` Guennadi Liakhovetski
2010-08-04  7:09         ` Sascha Hauer
2010-08-04  8:24           ` Guennadi Liakhovetski
2010-08-04  8:53             ` Michael Grzeschik [this message]
2010-08-04  9:48               ` Guennadi Liakhovetski
2010-08-05 20:17   ` Guennadi Liakhovetski
2010-08-10 10:25     ` Michael Grzeschik
2010-08-10 19:08       ` Guennadi Liakhovetski
2010-08-11  7:13         ` Michael Grzeschik
2010-08-03  9:37 ` [PATCH 2/5] mx2_camera: remove emma limitation for RGB565 Michael Grzeschik
2010-08-04  9:55   ` Guennadi Liakhovetski
2010-08-04 10:27     ` Michael Grzeschik
2010-08-05 19:25       ` Guennadi Liakhovetski
2010-08-09 14:22         ` [PATCH v2] " Michael Grzeschik
2010-08-09 14:57         ` [PATCH v2][RESEND] " Michael Grzeschik
2010-08-03  9:37 ` [PATCH 3/5] mx2_camera: fix for list bufnum in frame_done_emma Michael Grzeschik
2010-08-03  9:37 ` [PATCH 4/5] mx2_camera: add rising edge for pixclock Michael Grzeschik
2010-08-03  9:37 ` [PATCH 5/5] mx2_camera: add informative camera clock frequency printout Michael Grzeschik
2010-08-05 20:30   ` Guennadi Liakhovetski
2010-08-05 20:54     ` Michael Grzeschik
2010-08-27  9:46       ` Guennadi Liakhovetski
2010-08-27 12:39   ` [PATCH v2] " Michael Grzeschik

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=20100804085326.GA10780@pengutronix.de \
    --to=mgr@pengutronix.de \
    --cc=baruch@tkos.co.il \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-media@vger.kernel.org \
    --cc=m.grzeschik@pengutronix.de \
    --cc=s.hauer@pengutronix.de \
    /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