Re: [PATCH v5 01/16] dt-bindings: regulator: Document ROHM BD71282 regulator bindings

[Mark Brown <broonie@kernel.org>]

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

On Mon, Dec 02, 2019 at 07:57:13AM +0000, Vaittinen, Matti wrote:
> On Fri, 2019-11-29 at 12:09 +0000, Mark Brown wrote:

> > The regulator driver has a bunch fo set_suspend_ operations.

> Hmm. I saw these. But unless I am mistaken linux only knows one
> 'suspend' state whereas the PMIC has a few separate states I can see as
> 'suspend' states. As far as I understood the set_suspend_voltage does
> not allow setting separate suspend voltages depending on the "type of
> suspend" (as there is only one 'suspend' state).

No, look at the bindings - we support a bunch of different
suspend states matching the different suspend states that the
kernel as a whole supports.  We don't assume that the device will
know this but you can always use the current suspend we're going
for to decide where to update.

> > > (RUN0, ... RUN3) could be mapped to regulator modes
> > > REGULATOR_MODE_FAST, REGULATOR_MODE_NORMAL, REGULATOR_MODE_IDLE
> > > and 
> > > REGULATOR_MODE_STANDBY. But regulators which are controlled by
> > > these

> > That doesn't make sense at all, the modes affect the quality of
> > regulation not the voltage that is set.

> Thanks. I misunderstood this. I thought these states could be used for
> some adaptive voltages. My understanding is that the RUN0,...RUN3 are
> designed for that - but I didn't know if regulator framework is
> designed for this.

The framework doesn't care how a device is controlled, that's up
to the device.  Like I said I recommend figuring out what
voltages are useful to have quick access to at runtime, for
example it's likely that it's good to have quick access to the
highest voltage that's been set (and/or the top of the
constraints).

> > The cpufreq code is all there in kernel - drivers/cpufreq.  I can't
> > remember if Android still has a custom governor in their trees but it
> > doesn't really make much difference in terms of how it interacts with
> > the regulator drivers.

> Right. I guess your answers mean that there is no "regulator group
> control" for "adaptive voltage changes" supported by regulator

I can't parse the above, sorry.  What is "regulator group
control"?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]