linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alberto Panizzo <maramaopercheseimorto@gmail.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	Mauro Carvalho Chehab <mchehab@infradead.org>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Magnus Damm <damm@opensource.se>,
	M?rton N?meth <nm127@freemail.hu>,
	linux-media@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] soc_camera: Add the ability to bind regulators to soc_camedra devices
Date: Tue, 30 Nov 2010 11:45:23 +0100	[thread overview]
Message-ID: <1291113923.3235.58.camel@realization> (raw)
In-Reply-To: <20101129155122.GB30926@sirena.org.uk>

On lun, 2010-11-29 at 15:51 +0000, Mark Brown wrote:
> On Mon, Nov 29, 2010 at 10:34:57AM +0100, Alberto Panizzo wrote:
> > On dom, 2010-11-28 at 20:05 +0100, Guennadi Liakhovetski wrote:
> 
> > >  (2) would anyone really want to 
> > > use several regulators for a camera sensor? If so, can it be the case, 
> > > that, for example, the regulators have to be switched off in the reverse 
> > > order to switching on? Or something else?
> 
> > Well, I'm working on the i.MX31 3 Stack board support and there are 2 
> > regulators that powers the camera and if you consider the digital output
> > that enable another supplier needed, the total regulators are three..
> > So, yes a list of regulators is needed in this case, and Yes I did not 
> > considered the order of enabling and disabling operations. Just because
> > even the freescale drivers didn't.
> 
> > A practical general rule is to turn off switchers in the reverse order
> > than the turning on one. And this can be easily implemented here.
> > But as you rose the question, we can add priorities of turning on and 
> > off.
> 
> If you use the regulator bulk API it'll reverse the ordering when doing
> the power down (or should if it doesn't already).

Great API regulator_bulk, let's get it a try! ..I was reinventing the 
hot water..

> 
> > > > +static int soc_camera_power_set(struct soc_camera_device *icd,
> > > > +				struct soc_camera_link *icl,
> > > > +				int power_on)
> > > > +{
> > > > +	int ret, i;
> > > > +
> > > > +	for (i = 0; i < icd->num_soc_regulators; i++) {
> > > > +		if (power_on) {
> > > > +			ret = regulator_set_voltage(icd->soc_regulators[i],
> > > > +				icl->soc_regulator_descs[i].value_on_min,
> > > > +				icl->soc_regulator_descs[i].value_on_max);
> 
> Unless you're actively varying the voltages at runtime (as Guennadi
> mentioned) I'd really expect the voltages to be handled by the regulator
> constraints.

This is sane thinking at a static board configuration. What if a single 
board have different deploying schemas where two different cameras can 
be placed on the same connector and these cameras have different voltage
levels for core supply? This scenario will require two different 
constraints chosen at compile time -> two different kernel binaries.
Otherwise constraints will always pick the minimum level and maybe this 
will not be enough.

Best regards,

-- 
Alberto!

        Be Persistent!
                - Greg Kroah-Hartman (FOSDEM 2010)


  reply	other threads:[~2010-11-30 10:45 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-28 17:18 [PATCH 1/3] soc_camera: Add the ability to bind regulators to soc_camedra devices Alberto Panizzo
2010-11-28 17:24 ` [PATCH 2/3] mx3_camera: Support correctly the YUV222 and BAYER configurations of CSI Alberto Panizzo
2010-11-28 17:26   ` [PATCH 3/3] V4L2: Add a v4l2-subdev (soc-camera) driver for OmniVision OV2640 sensor Alberto Panizzo
2010-12-01 23:32     ` Guennadi Liakhovetski
2010-12-02 10:33       ` Alberto Panizzo
2010-12-02 14:53       ` [PATCH v2] " Alberto Panizzo
2010-11-30 14:25   ` [PATCH 2/3] mx3_camera: Support correctly the YUV222 and BAYER configurations of CSI Alberto Panizzo
2010-11-30 14:31     ` Guennadi Liakhovetski
2010-11-30 14:39       ` Alberto Panizzo
2010-12-01 18:54   ` Guennadi Liakhovetski
2010-12-18 16:24     ` Guennadi Liakhovetski
2010-12-30 19:38       ` Guennadi Liakhovetski
2011-01-03 11:46         ` Alberto Panizzo
2011-01-03 17:33         ` Alberto Panizzo
2011-01-03 19:37           ` Guennadi Liakhovetski
2011-01-03 22:07             ` Alberto Panizzo
2011-01-11 17:29               ` Alberto Panizzo
2011-01-12 11:13               ` [PATCH 0/2] Fix the way mx3_camera manage non 8-bpp pixel formats Alberto Panizzo
2011-01-12 11:16                 ` [PATCH 1/2] soc_mediabus: export a useful method to obtain the number of samples that makes up a pixel format Alberto Panizzo
2011-01-12 11:20                 ` [PATCH 2/2] Fix capture issues for non 8-bit per pixel formats Alberto Panizzo
2011-01-15 21:35                   ` Guennadi Liakhovetski
2011-01-17  9:41                     ` Alberto Panizzo
2011-01-17  9:52                     ` [PATCH 2/2 v2] " Alberto Panizzo
2011-01-03 16:06     ` [PATCH 2/3] mx3_camera: Support correctly the YUV222 and BAYER configurations of CSI Alberto Panizzo
2011-01-03 16:24       ` Guennadi Liakhovetski
2010-11-28 19:05 ` [PATCH 1/3] soc_camera: Add the ability to bind regulators to soc_camedra devices Guennadi Liakhovetski
2010-11-29  9:34   ` Alberto Panizzo
2010-11-29 15:51     ` Mark Brown
2010-11-30 10:45       ` Alberto Panizzo [this message]
2010-11-30 11:05         ` Mark Brown
2010-11-29 15:44   ` Mark Brown

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=1291113923.3235.58.camel@realization \
    --to=maramaopercheseimorto@gmail.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=damm@opensource.se \
    --cc=g.liakhovetski@gmx.de \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.org \
    --cc=nm127@freemail.hu \
    /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).