[RFC] REGULATOR: core add 3 new modes/statuses

[RFC] REGULATOR: core add 3 new modes/statuses

[Graeme Gregory]

Hi, wanted to check how well a patch of this sort would go down before
sending a final version.

At least two of the PMICs I support twl6032 and twl6035 (and varients)
would benefit from these extra modes.

Graeme

[PATCH] REGULATOR: core add 3 new modes/statuses

[Graeme Gregory]

This patch adds three new modes to the regulator core these are present
in many TI PMICs and I expect ones by other manufecturers.

USBBOOST this effectively turns the regulator around instead of using
the USB 5v and converting this down to power USB hardware the regulator
instead takes the internal voltage and boosts it to 5v for USB. Most
commonly used when a device goes into OTG host mode.

BYPASS the input voltage on the regulator is transferred directly to the
output.

TRACKING the regulator tracks another resource and produces the same
voltage. This is commonly used where an switching power supply produces
a voltage but a quality smoothed version of the same voltage produced
by an LDO is required as well.

Signed-off-by: Graeme Gregory <gg@slimlogic.co.uk>
---
 drivers/regulator/core.c           |   15 +++++++++++++++
 include/linux/regulator/consumer.h |    3 +++
 include/linux/regulator/driver.h   |    3 +++
 3 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index c056abd..a4e5da4 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -414,6 +414,15 @@ static ssize_t regulator_status_show(struct device *dev,
 	case REGULATOR_STATUS_STANDBY:
 		label = "standby";
 		break;
+	case REGULATOR_STATUS_USBBOOST:
+		label = "usbboost";
+		break;
+	case REGULATOR_STATUS_BYPASS:
+		label = "bypass";
+		break;
+	case REGULATOR_STATUS_TRACKING:
+		label = "tracking";
+		break;
 	default:
 		return -ERANGE;
 	}
@@ -2680,6 +2689,12 @@ int regulator_mode_to_status(unsigned int mode)
 		return REGULATOR_STATUS_IDLE;
 	case REGULATOR_STATUS_STANDBY:
 		return REGULATOR_STATUS_STANDBY;
+	case REGULATOR_MODE_USBBOOST:
+		return REGULATOR_STATUS_USBBOOST;
+	case REGULATOR_MODE_BYPASS:
+		return REGULATOR_STATUS_BYPASS;
+	case REGULATOR_MODE_TRACKING:
+		return REGULATOR_STATUS_TRACKING;
 	default:
 		return 0;
 	}
diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
index 4ed1b30..6d5c6ed 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -81,6 +81,9 @@ struct notifier_block;
 #define REGULATOR_MODE_NORMAL			0x2
 #define REGULATOR_MODE_IDLE			0x4
 #define REGULATOR_MODE_STANDBY			0x8
+#define REGULATOR_MODE_USBBOOST			0x10
+#define REGULATOR_MODE_BYPASS			0x20
+#define REGULATOR_MODE_TRACKING			0x40
 
 /*
  * Regulator notifier events.
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index fa8b55b..594f0fe 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -31,6 +31,9 @@ enum regulator_status {
 	REGULATOR_STATUS_NORMAL,
 	REGULATOR_STATUS_IDLE,
 	REGULATOR_STATUS_STANDBY,
+	REGULATOR_STATUS_USBBOOST,
+	REGULATOR_STATUS_BYPASS,
+	REGULATOR_STATUS_TRACKING,
 };
 
 /**
-- 
1.7.5.4

Re: [PATCH] REGULATOR: core add 3 new modes/statuses

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 4224 bytes --]

On Tue, Mar 20, 2012 at 09:50:58PM +0000, Graeme Gregory wrote:
> This patch adds three new modes to the regulator core these are present
> in many TI PMICs and I expect ones by other manufecturers.

I'm not sure these are really modes, the framework essentially thinks as
modes as regulation quality but except in the case of bypass that's not
really what's going on here.

> USBBOOST this effectively turns the regulator around instead of using
> the USB 5v and converting this down to power USB hardware the regulator
> instead takes the internal voltage and boosts it to 5v for USB. Most
> commonly used when a device goes into OTG host mode.

In theory this could be done by other things so we should probably have
a better name, though in practice I'd be surprised to see many others.
It does totally break the idea of a mode, though - it's a massive change
in what the regulator does.

> BYPASS the input voltage on the regulator is transferred directly to the
> output.

This one I've actually been thinking about myself - we do want it for
low power states but I think we should consider splitting it since while
it does kind of look like a mode if you look at it funny (really it's
just very, very low quality regulation) it seems like we should be able
to do interesting things with it in the framework like turning off
regulation if the parent regulator can directly satisfy the children.
As a mode it's relatively limited if drivers won't select the mode
explicitly since if regulation weren't required some of the time it's
unlikely that the regulator would be in the picture at all.

This is all rather like the mode selection stuff so it might well be
that that's the best way of delivering the feature but I'm a bit nervous
of just doing that partly because it's a bit of a jump for a consumer to
go from "I want low current" to "I don't care so much what my input
voltage is" (though often a valid one) and partly because we're not
actually using the automatic mode selection logic since nobody is
providing the current numbers since that's a bit sensitive.  This second
issue with getting the information to deploy the feature is what's
swaying me, at the minute nobody's providing the information needed
except for some of the out of tree Qualcomm drivers.

What I'd envisage for a feature specific API would be something like a
call consumers could make to indicate that they're OK with bypass mode
paired with a constraint flag that lets the core pay attention - if all
the consumers vote for bypass it can get turned on.  Probably this could
be tied in with disable too so that a consumer that wasn't enabled would
automatically get set as voting for bypass, relying on the constraints
to disable the feature when not appropriate.

A further extension would be to allow boards to also automatically
enable bypass if the voltages requested by the consumers can be
satisfied directly from the parent regulator, though that's got some
rather obvious pitfalls.

Like I say I'm not entirely clear here, I keep meaning to try coding up
the custom API and see how it feels using it in a system - any thoughts?
Probably won't take me that long...

> TRACKING the regulator tracks another resource and produces the same
> voltage. This is commonly used where an switching power supply produces
> a voltage but a quality smoothed version of the same voltage produced
> by an LDO is required as well.

You also get this for ganging multiple regulators together to give a
higher power output, though normally you want variability so this has to
be handled at the hardware level.  This one also has an impact on how we
handle voltage changes, it'd be good if we could arrange things so that
get_voltage() and set_voltage() work through/with a regulator that's
tracking.

>  #define REGULATOR_MODE_NORMAL                  0x2
>  #define REGULATOR_MODE_IDLE                    0x4
>  #define REGULATOR_MODE_STANDBY                 0x8
> +#define REGULATOR_MODE_USBBOOST                        0x10
> +#define REGULATOR_MODE_BYPASS                  0x20
> +#define REGULATOR_MODE_TRACKING                        0x40

Note that the existing modes are all sorted in order of quality and the
framework does use that...

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] REGULATOR: core add 3 new modes/statuses

[Graeme Gregory]

On 21/03/2012 00:29, Mark Brown wrote:
> On Tue, Mar 20, 2012 at 09:50:58PM +0000, Graeme Gregory wrote:
>> This patch adds three new modes to the regulator core these are present
>> in many TI PMICs and I expect ones by other manufecturers.
> I'm not sure these are really modes, the framework essentially thinks as
> modes as regulation quality but except in the case of bypass that's not
> really what's going on here.
Your comments below do echo some of the doubts I had with this, why I
sent as an RFC before I went changing the driver to use them.

>> USBBOOST this effectively turns the regulator around instead of using
>> the USB 5v and converting this down to power USB hardware the regulator
>> instead takes the internal voltage and boosts it to 5v for USB. Most
>> commonly used when a device goes into OTG host mode.
> In theory this could be done by other things so we should probably have
> a better name, though in practice I'd be surprised to see many others.
> It does totally break the idea of a mode, though - it's a massive change
> in what the regulator does.
Im not attached to the name, I just chose it as BOOST is a type of SMPS
as well as being the common name for this function within TI. I do see
what you mean by it not really fitting the "mode" descriptor well!

>> BYPASS the input voltage on the regulator is transferred directly to the
>> output.
> This one I've actually been thinking about myself - we do want it for
> low power states but I think we should consider splitting it since while
> it does kind of look like a mode if you look at it funny (really it's
> just very, very low quality regulation) it seems like we should be able
> to do interesting things with it in the framework like turning off
> regulation if the parent regulator can directly satisfy the children.
> As a mode it's relatively limited if drivers won't select the mode
> explicitly since if regulation weren't required some of the time it's
> unlikely that the regulator would be in the picture at all.
>
> This is all rather like the mode selection stuff so it might well be
> that that's the best way of delivering the feature but I'm a bit nervous
> of just doing that partly because it's a bit of a jump for a consumer to
> go from "I want low current" to "I don't care so much what my input
> voltage is" (though often a valid one) and partly because we're not
> actually using the automatic mode selection logic since nobody is
> providing the current numbers since that's a bit sensitive.  This second
> issue with getting the information to deploy the feature is what's
> swaying me, at the minute nobody's providing the information needed
> except for some of the out of tree Qualcomm drivers.
>
> What I'd envisage for a feature specific API would be something like a
> call consumers could make to indicate that they're OK with bypass mode
> paired with a constraint flag that lets the core pay attention - if all
> the consumers vote for bypass it can get turned on.  Probably this could
> be tied in with disable too so that a consumer that wasn't enabled would
> automatically get set as voting for bypass, relying on the constraints
> to disable the feature when not appropriate.
>
> A further extension would be to allow boards to also automatically
> enable bypass if the voltages requested by the consumers can be
> satisfied directly from the parent regulator, though that's got some
> rather obvious pitfalls.
>
> Like I say I'm not entirely clear here, I keep meaning to try coding up
> the custom API and see how it feels using it in a system - any thoughts?
> Probably won't take me that long...
This Im not really sure on, I don't see much info on the actual use of
bypass mode in real devices yet. twl6035 uses it to power LDOUSB direct
from USB bus intead of using the internal SMPS. But so far that is the
only usecase I know of. Which of course means in bypass mode we not only
have to change parent to some non existent virtual regulator but also
enabled bypass mode.

>> TRACKING the regulator tracks another resource and produces the same
>> voltage. This is commonly used where an switching power supply produces
>> a voltage but a quality smoothed version of the same voltage produced
>> by an LDO is required as well.
> You also get this for ganging multiple regulators together to give a
> higher power output, though normally you want variability so this has to
> be handled at the hardware level.  This one also has an impact on how we
> handle voltage changes, it'd be good if we could arrange things so that
> get_voltage() and set_voltage() work through/with a regulator that's
> tracking.
I could see this also working if you set a parent regulator with a
TRACKING flag so the framework knows the link. The other thing to
consider is the twl6035 when you disable the parent SMPS on the LDO in
tracking mode the LDO then switches to non tracking mode and uses its
own configuration. When you turn SMPS back on it switch back to tracking
mode.
>>  #define REGULATOR_MODE_NORMAL                  0x2
>>  #define REGULATOR_MODE_IDLE                    0x4
>>  #define REGULATOR_MODE_STANDBY                 0x8
>> +#define REGULATOR_MODE_USBBOOST                        0x10
>> +#define REGULATOR_MODE_BYPASS                  0x20
>> +#define REGULATOR_MODE_TRACKING                        0x40
> Note that the existing modes are all sorted in order of quality and the
> framework does use that...
Yes I can see that now, didnt notice it at first.

Altogether it looks like adding these features requires a lot more work
than I had originally hoped :-(

I guess the best way for me to proceed is to start to think about each
of these "modes" individually and see what support I actually need from
regulator framework to get them implemented.

Graeme

Re: [PATCH] REGULATOR: core add 3 new modes/statuses

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2844 bytes --]

On Wed, Mar 21, 2012 at 10:49:56AM +0000, Graeme Gregory wrote:
> On 21/03/2012 00:29, Mark Brown wrote:
> > On Tue, Mar 20, 2012 at 09:50:58PM +0000, Graeme Gregory wrote:

> >> USBBOOST this effectively turns the regulator around instead of using

> > In theory this could be done by other things so we should probably have
> > a better name, though in practice I'd be surprised to see many others.
> > It does totally break the idea of a mode, though - it's a massive change
> > in what the regulator does.

> Im not attached to the name, I just chose it as BOOST is a type of SMPS
> as well as being the common name for this function within TI. I do see
> what you mean by it not really fitting the "mode" descriptor well!

Plain BOOST does seem OK as a name - it was the USB bit.

> > Like I say I'm not entirely clear here, I keep meaning to try coding up
> > the custom API and see how it feels using it in a system - any thoughts?
> > Probably won't take me that long...

> This Im not really sure on, I don't see much info on the actual use of
> bypass mode in real devices yet. twl6035 uses it to power LDOUSB direct
> from USB bus intead of using the internal SMPS. But so far that is the
> only usecase I know of. Which of course means in bypass mode we not only
> have to change parent to some non existent virtual regulator but also
> enabled bypass mode.

There's some other stuff deployed already, though mostly internally to
drivers as the regulators concerned aren't generic regulators but are
internal to the device.

> > You also get this for ganging multiple regulators together to give a
> > higher power output, though normally you want variability so this has to
> > be handled at the hardware level.  This one also has an impact on how we
> > handle voltage changes, it'd be good if we could arrange things so that
> > get_voltage() and set_voltage() work through/with a regulator that's
> > tracking.

> I could see this also working if you set a parent regulator with a
> TRACKING flag so the framework knows the link. The other thing to
> consider is the twl6035 when you disable the parent SMPS on the LDO in
> tracking mode the LDO then switches to non tracking mode and uses its
> own configuration. When you turn SMPS back on it switch back to tracking
> mode.

That one is even more fun, it's relatively straightforward if they both
have the same configuration but otherwise...

> Altogether it looks like adding these features requires a lot more work
> than I had originally hoped :-(

> I guess the best way for me to proceed is to start to think about each
> of these "modes" individually and see what support I actually need from
> regulator framework to get them implemented.

Yeah, probably.  It's more likely something will happen about bypass
mode without you doing anything but I wouldn't rely on it.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]