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

[Mark Brown <broonie@kernel.org>]

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

On Mon, Dec 02, 2019 at 02:02:41PM +0000, Vaittinen, Matti wrote:
> On Mon, 2019-12-02 at 13:11 +0000, Mark Brown wrote:

> > 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.

> Hm. So if I understand this correctly, you mean user should set the
> suspend 'target' - and then call the set_suspend_voltage for this
> state. To set voltages for all states one should do loop

The general idea is that we set the suspend state during the
process of suspending rather than in advance - that way when the
hardware doesn't understand different types of suspsend things
work fine.

> get_current_mode()

> for_all_modes() {
> 	set_mode()
> 	set_voltage()
> }

> restore_original_mode()

> am I on a right track? I'll try to see if I can find some examples of
> this - thanks.

I don't understand the save and restore of mode?  If setting the
suspend configuration affects the runtime state then the hardware
doesn't support suspend configuration.

> > 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).

> Problem is that the run-level controlled regulator can't be
> individually controlled (unless it is only regulator in the group). I

Regulators that have to be controlled en masse aren't really
supported by the API, it only understands regulators that are
individually controllable.

> But just to confirm, I meant for example assigning bucks 1,2,6 and 7
> into a group which 'state' is changed via GPIO line. Say 'states' are
> RUN0, RUN1. For each of these bucks we can define a voltage and
> enable/disable status which is to be used on RUN0, and another
> voltage/state tuple for RUN1.

So you could also just create a group consisting of a single
regulator?  That would be fine for the API.

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