[patch 2.6.28-rc3-omap 0/4] twl4030 regulator support

[patch 2.6.28-rc3-omap 0/4] twl4030 regulator support

[David Brownell]

On the grounds that it's probably the way to go, here's initial
support for the regulator framework.

 - simplified TWL child creation code ... updates an earlier
	patch, AFAICT this is ready to merge now
 - regulator driver support ... core functionality seems done
 - create regulator devices ... ditto
 - hook it up for testing ... NOT FOR MERGING

This is a trifle awkward for me to test without test points
to measure the dozen or so LDO regulators that are exposed.
But poking at the registers tells sensible stories, and the
regulator driver code and device setup seem to be in more
or less usable shape ... so it's time to circulate this code!

If this checks out, the first three patches should merge
and then stuff like USB (easiest) and HSMMC can start to
use it.


It's my expectation that virtually no-one on this list will
ever have used the regulator framework before; it's very new,
and the regulator drivers in the mainline kernel aren't for
chips that get much use with current OMAP boards.

So my advice to anyone wanting to switch TWL LDOs on/off is
to allocate an hour or two to play around with the sysfs
interfaces you'll get by applying all four patches and then
booting the resulting kernel:

  /sys/class/regulator/regulator.*/...
	a dozen regulators, most attributes useless (see [1],
	especially [2], and maybe [3] for optional patches
	to improve utility); all are read-only
  /sys/devices/platform/reg-virt-consumer.*
	half as many regulators (platform_bus bug), but
	with WRITABLE attributes for testing with

The "virtual consumer" thing is drivers/regulator/virtual.c
and you'll have to read its code for details ... basically,
write the min and max voltage attributes there (or zero them)
then look at the regulator.* attributes and/or check the
testpoints on your board.

Appended is a script that dumps regulator stats in more
digestible form than raw sysfs:

VMMC1	-- normal, 	3150000 uVolts 	(regulator.0)
	1850000 <--> 3150000 uVolts
VDAC	-- normal, 	1800000 uVolts 	(regulator.1)
	1200000 <--> 1800000 uVolts
VAUX3	-- normal, 	2800000 uVolts 	(regulator.10)
	1500000 <--> 2800000 uVolts
VAUX4	-- off, 	1000000 uVolts 	(regulator.11)
VAUX2	-- normal, 	1500000 uVolts 	(regulator.2)
	1300000 <--> 2800000 uVolts
VUSB1V5	-- normal, 	1500000 uVolts 	(regulator.3)
VUSB1V8	-- normal, 	1800000 uVolts 	(regulator.4)
VUSB3V1	-- normal, 	3100000 uVolts 	(regulator.5)
VUSBCP	-- off, 	4800000 uVolts 	(regulator.6)
VMMC2	-- off, 	2600000 uVolts 	(regulator.7)
VSIM	-- normal, 	1800000 uVolts 	(regulator.8)
	1800000 <--> 3000000 uVolts
VAUX1	-- off, 	3000000 uVolts 	(regulator.9)

Enjoy!

- Dave

[1] http://marc.info/?l=linux-kernel&m=122645403604873&w=2
[2] http://marc.info/?l=linux-kernel&m=122645416305013&w=2
[3] http://marc.info/?l=linux-kernel&m=122645416305018&w=2


#!/bin/bash

cd /sys/class/regulator || exit 1

for F in *
do
	NAME=$(cat $F/name)
	test $NAME = VAUX2_4030 && NAME=VAUX2
	OPMODE=$(cat $F/opmode)
	STATE=$(cat $F/state)
	test $OPMODE != off -a $STATE = disabled && OPMODE=off
	UVOLTS="0"
	test -f $F/microvolts && UVOLTS=$(cat $F/microvolts)

	echo $NAME"	-- "$OPMODE", 	"$UVOLTS" uVolts 	("$F")"

	test $OPMODE = off && continue

	# FIXME:  may have device links ... display them too
	test ! -f $F/min_microvolts && continue

	UVOLTS_MIN=$(cat $F/min_microvolts)
	UVOLTS_MAX=$(cat $F/max_microvolts)
	echo "	"$UVOLTS_MIN" <--> "$UVOLTS_MAX uVolts

done

Re: [patch 2.6.28-rc3-omap 0/4] twl4030 regulator support

[Tony Lindgren]

* David Brownell <david-b@pacbell.net> [081111 18:10]:
> On the grounds that it's probably the way to go, here's initial
> support for the regulator framework.
> 
>  - simplified TWL child creation code ... updates an earlier
> 	patch, AFAICT this is ready to merge now
>  - regulator driver support ... core functionality seems done
>  - create regulator devices ... ditto
>  - hook it up for testing ... NOT FOR MERGING
> 
> This is a trifle awkward for me to test without test points
> to measure the dozen or so LDO regulators that are exposed.
> But poking at the registers tells sensible stories, and the
> regulator driver code and device setup seem to be in more
> or less usable shape ... so it's time to circulate this code!
> 
> If this checks out, the first three patches should merge
> and then stuff like USB (easiest) and HSMMC can start to
> use it.

Nice! Do you want to wait a bit before converting HSMMC to avoid
adding extra dependencies to get that driver merged upstream first?

BTW, your first patch in this series does not apply, can you please
refresh? I just pushed a bunch of patches from you, can you also
please check I'm not missing any of your patches?

Thanks,

Tony



> It's my expectation that virtually no-one on this list will
> ever have used the regulator framework before; it's very new,
> and the regulator drivers in the mainline kernel aren't for
> chips that get much use with current OMAP boards.
> 
> So my advice to anyone wanting to switch TWL LDOs on/off is
> to allocate an hour or two to play around with the sysfs
> interfaces you'll get by applying all four patches and then
> booting the resulting kernel:
> 
>   /sys/class/regulator/regulator.*/...
> 	a dozen regulators, most attributes useless (see [1],
> 	especially [2], and maybe [3] for optional patches
> 	to improve utility); all are read-only
>   /sys/devices/platform/reg-virt-consumer.*
> 	half as many regulators (platform_bus bug), but
> 	with WRITABLE attributes for testing with
> 
> The "virtual consumer" thing is drivers/regulator/virtual.c
> and you'll have to read its code for details ... basically,
> write the min and max voltage attributes there (or zero them)
> then look at the regulator.* attributes and/or check the
> testpoints on your board.
> 
> Appended is a script that dumps regulator stats in more
> digestible form than raw sysfs:
> 
> VMMC1	-- normal, 	3150000 uVolts 	(regulator.0)
> 	1850000 <--> 3150000 uVolts
> VDAC	-- normal, 	1800000 uVolts 	(regulator.1)
> 	1200000 <--> 1800000 uVolts
> VAUX3	-- normal, 	2800000 uVolts 	(regulator.10)
> 	1500000 <--> 2800000 uVolts
> VAUX4	-- off, 	1000000 uVolts 	(regulator.11)
> VAUX2	-- normal, 	1500000 uVolts 	(regulator.2)
> 	1300000 <--> 2800000 uVolts
> VUSB1V5	-- normal, 	1500000 uVolts 	(regulator.3)
> VUSB1V8	-- normal, 	1800000 uVolts 	(regulator.4)
> VUSB3V1	-- normal, 	3100000 uVolts 	(regulator.5)
> VUSBCP	-- off, 	4800000 uVolts 	(regulator.6)
> VMMC2	-- off, 	2600000 uVolts 	(regulator.7)
> VSIM	-- normal, 	1800000 uVolts 	(regulator.8)
> 	1800000 <--> 3000000 uVolts
> VAUX1	-- off, 	3000000 uVolts 	(regulator.9)
> 
> Enjoy!
> 
> - Dave
> 
> [1] http://marc.info/?l=linux-kernel&m=122645403604873&w=2
> [2] http://marc.info/?l=linux-kernel&m=122645416305013&w=2
> [3] http://marc.info/?l=linux-kernel&m=122645416305018&w=2
> 
> 
> #!/bin/bash
> 
> cd /sys/class/regulator || exit 1
> 
> for F in *
> do
> 	NAME=$(cat $F/name)
> 	test $NAME = VAUX2_4030 && NAME=VAUX2
> 	OPMODE=$(cat $F/opmode)
> 	STATE=$(cat $F/state)
> 	test $OPMODE != off -a $STATE = disabled && OPMODE=off
> 	UVOLTS="0"
> 	test -f $F/microvolts && UVOLTS=$(cat $F/microvolts)
> 
> 	echo $NAME"	-- "$OPMODE", 	"$UVOLTS" uVolts 	("$F")"
> 
> 	test $OPMODE = off && continue
> 
> 	# FIXME:  may have device links ... display them too
> 	test ! -f $F/min_microvolts && continue
> 
> 	UVOLTS_MIN=$(cat $F/min_microvolts)
> 	UVOLTS_MAX=$(cat $F/max_microvolts)
> 	echo "	"$UVOLTS_MIN" <--> "$UVOLTS_MAX uVolts
> 
> done
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 2.6.28-rc3-omap 0/4] twl4030 regulator support

[David Brownell]

On Thursday 13 November 2008, Tony Lindgren wrote:
> Nice! Do you want to wait a bit before converting HSMMC to avoid
> adding extra dependencies to get that driver merged upstream first?

That would seem simplest, yes.


> BTW, your first patch in this series does not apply, can you please
> refresh? I just pushed a bunch of patches from you, can you also
> please check I'm not missing any of your patches?

That's because you merged the RFT version of that first patch.
Revert that, then try again with this series.

- dave
 

Re: [patch 2.6.28-rc3-omap 0/4] twl4030 regulator support

[David Brownell]

On Thursday 13 November 2008, David Brownell wrote:
> On Thursday 13 November 2008, Tony Lindgren wrote:
> > Nice! Do you want to wait a bit before converting HSMMC to avoid
> > adding extra dependencies to get that driver merged upstream first?
> 
> That would seem simplest, yes.
> 

Oh, and somewhat related ... nothing seems to turn off unused
regulators.  I'm thinking that bitmasks to define the P1/P2/P3
group memberships of most power resources would do the job.

- Dave

Re: [patch 2.6.28-rc3-omap 0/4] twl4030 regulator support

[Tony Lindgren]

* David Brownell <david-b@pacbell.net> [081113 17:01]:
> On Thursday 13 November 2008, David Brownell wrote:
> > On Thursday 13 November 2008, Tony Lindgren wrote:
> > > Nice! Do you want to wait a bit before converting HSMMC to avoid
> > > adding extra dependencies to get that driver merged upstream first?
> > 
> > That would seem simplest, yes.
> > 
> 
> Oh, and somewhat related ... nothing seems to turn off unused
> regulators.  I'm thinking that bitmasks to define the P1/P2/P3
> group memberships of most power resources would do the job.

Yeah I was wondering about that too. Should the processor group
membership be set only once during init?

Tony

Re: [patch 2.6.28-rc3-omap 0/4] twl4030 regulator support

[David Brownell]

On Thursday 13 November 2008, Tony Lindgren wrote:
> 
> > Oh, and somewhat related ... nothing seems to turn off unused
> > regulators.  I'm thinking that bitmasks to define the P1/P2/P3
> > group memberships of most power resources would do the job.
> 
> Yeah I was wondering about that too. Should the processor group
> membership be set only once during init?

I think it should certainly be set during init.  The PM scripts
don't change membership, but I can imagine some of them would
want to use custom type or subtype codes that would also need to
be set during init.

The current way to enable/disable a regulator for Linux purposes
is to add/remove it from the P1 group.  That seems OK for now...
only a handful of regulators use software control like that,
which would change membership after init.

But we *could* enable/disable by directly setting the mode.
I decided against doing it that way, on the grounds that until
we get some use cases that need something else, we're best off
keeping things simple.

- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html