twl4030 regulator support

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

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

That would seem simplest, yes.

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

- dave

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

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

Tony

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html