linux-kernel - Re: [PATCH 1/3] soc_camera: Add the ability to bind regulators to soc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 30 Nov 2010 11:45:23 +0100
From:	Alberto Panizzo <maramaopercheseimorto@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	Hans Verkuil <hverkuil@...all.nl>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Magnus Damm <damm@...nsource.se>,
	M?rton N?meth <nm127@...email.hu>, linux-media@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] soc_camera: Add the ability to bind regulators to
 soc_camedra devices

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)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/