On Tue, Nov 19, 2019 at 06:51:37PM +0000, Vaittinen, Matti wrote:
> On Tue, 2019-11-19 at 18:13 +0000, Mark Brown wrote:

> > Ah, OK.  I didn't even notice that patch when I scanned the series.
> > I'll look out for this next time around but that sounds like it's
> > generally going in the right direction, especially if it's integrated
> > with the suspend mode regulator bindings that Chunyan did.

> Probably it is not as I am not familiar with Chunyan's work. I'll try
> looking what has been done on that front :) And I am pretty sure you
> might not be happy with that patch - but perhaps you can give me a
> nudge to better direction...

The driver interface was added in "regulator: add PM suspend and resume
hooks".

> > Yes, I think this needs clarification as I completely failed to pick
> > up
> > on this and did indeed read this as referring to the
> > modes.  "Voltages
> > that can be set in RUN mode" or something?  I take it these voltages
> > are
> > fixed and the OS can't change them?

> Unfortunately they are not. Voltages and enable/disable statuses for
> each run-level (and individually for each run-level capable buck) can
> be changed at runtime via I2C. And a customer requested me also to
> support this - hence the in-kernel API - but I am sure you have some
> nice words when you check the patch 12. :]

Ah, that's actually better.  It opens up possiblities for making use of
the feature without encoding voltages in DT.  For example, you can cache
the last however many voltages that were set and jump quickly to them or
do something like put the top of the constraints in to help with
governors like ondemand.  I'd recommend trying for something like that
rather than encoding in DT, it'll probably be more robust with things
like cpufreq changing.