regulator_set_voltage and regulator_set_optimum_mode usage question

regulator_set_voltage and regulator_set_optimum_mode usage question

[David Collins]

Hi Mark and Liam,

I was wondering what the best way is to handle a situation in which a
consumer driver wishes to be as generic as possible by calling a sequence
like this for any regulator that is uses:

vreg = regulator_get(dev, "foo_vdd");
regulator_set_voltage(vreg, 1000000, 2000000);
regulator_set_optimum_mode(vreg, 50000);
regulator_enable(vreg);

The problem that arises is that the "regulator" it is supplied by may in
fact be a voltage switch.  The driver for this switch is set up so that
only enable, disable, and is_enabled callbacks are specified.  This has
the effect of making all regulator_set_voltage and
regulator_set_optimum_mode calls return an error.

Is there a mechanism in the regulator framework that will allow a consumer
to determine if these APIs are available for a given regulator?

I considered changing the switch drivers to provide dummy voltage and mode
callbacks.  The voltage range would then be any positive integer
(including 0).  However, this results in a problem if one consumer calls
only regulator_enable and then a second consumer calls
regulator_set_voltage with some range, perhaps [1000000, 2000000],
followed by regulator_enable.  regulator_check_consumers will fail inside
of regulator_set_voltage for the second consumer because the implicit [0,
0] request of the first consumer does not overlap [1000000, 2000000].

What are your thoughts on this situation?

Thanks,
David Collins

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: regulator_set_voltage and regulator_set_optimum_mode usage question

[Mark Brown]

On Fri, May 13, 2011 at 09:27:03AM -0700, David Collins wrote:

> vreg = regulator_get(dev, "foo_vdd");
> regulator_set_voltage(vreg, 1000000, 2000000);
> regulator_set_optimum_mode(vreg, 50000);
> regulator_enable(vreg);

> The problem that arises is that the "regulator" it is supplied by may in
> fact be a voltage switch.  The driver for this switch is set up so that
> only enable, disable, and is_enabled callbacks are specified.  This has
> the effect of making all regulator_set_voltage and
> regulator_set_optimum_mode calls return an error.

The switch driver should be doing a better job here, at least reporting
the voltage that the parent has.  This is going to need core support to
dance around the locking, we need a property the driver can set to say
that it is a voltage switch.  In fact, we ideally need a dynamic thing
which the driver can set at runtime as some regulators have passthrough
modes.

As with several of the other things it'd be really helpful if you could
provide actual system examples - without seeing the system it's hard to
know what makes sense.  My first question looking at your above code is
why a consumer which cares if it's setting the mode is sharing a
regulator with other devices in the system in the first place - as I'm
fairly sure I've mentioned previously you're then relying on every
device involved participating in optimising the mode which is in general
optimistic.  I'm guessing from a grep of the kernel that this is for
your OTG driver?

For set_optimum_mode() I'd not expect the consumer driver to care too
much about failures unless it's succesfully lowered the optimum mode in
the past and is trying to raise things.  I'll just send a patch out
which makes us report success if there's no support for set_mode(), it's
mostly ornamental anyway.  I've sent a patch for that.

> Is there a mechanism in the regulator framework that will allow a consumer
> to determine if these APIs are available for a given regulator?

For the voltage setting the consumer driver can enumerate the range of
voltages which it can set - if it can't control voltage this should come
out as the empty set.  The consumer is going to need to know about
particular voltages as well as the general ability to set voltages at
all.  This is good practice anyway to ensure the consumer interoperates
well with boards that don't allow them the full range of voltages they
may want or with regulators with coarse grained voltage steps.

For the mode optimisation the patch I sent should mean that the API is
always available.

> I considered changing the switch drivers to provide dummy voltage and mode
> callbacks.  The voltage range would then be any positive integer
> (including 0).  However, this results in a problem if one consumer calls

This obviously isn't at all good - it's totally not what the consumer
asked for and it's not really useful as we're not joined up with
anything else in the parent domain, including basic error checking if
the parent domain voltage is allowed to vary.

> only regulator_enable and then a second consumer calls
> regulator_set_voltage with some range, perhaps [1000000, 2000000],
> followed by regulator_enable.  regulator_check_consumers will fail inside
> of regulator_set_voltage for the second consumer because the implicit [0,
> 0] request of the first consumer does not overlap [1000000, 2000000].

This just seems like a generic and largely unrelated issue; it's just
that you can't have consumers that set and don't set voltages sharing
a regulator.  I've sent a patch which should address the issue.