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

[Mark Brown]

On Fri, Nov 29, 2019 at 07:48:13AM +0000, Vaittinen, Matti wrote:
> On Tue, 2019-11-19 at 19:36 +0000, Mark Brown wrote:

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

> I looked through the set but didn't spot any new interface towards the
> regulator driver (which accesses the HW). I saw interface towards
> regulator consumer driver which can be used to set the constrains
> though.

The regulator driver has a bunch fo set_suspend_ operations.

> Specifically, I don't see voltage setting callback for different run-
> modes. Nor do I see voltage setting (or differentiation) of more than
> one suspend state.

set_suspend_voltage.

> To explain it further - my assumption is that the BD71828 'run-levels'
> (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.

> run-levels, can't be individually controlled. If state for one is
> changed, the state is changed for all of them. The DVS bucks 1,2,6 and

We don't really have anything that'd only work for group configuration
except for the suspend modes.

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

> I wish I was working with the full product so that I could see and
> learn a proper example on how the cpufreq actually uses these
> interfaces :) I'd really like to understand this much better. Maybe
> this could be a topic for you to present in some Linux conference ;)
> Just please ping me when you are doing that and I'll be listening there
> for sure ;)

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.

> Anyways, my idea was to set the inital voltage values for these states
> via DT - but allow the voltages to be changed at run-time too (I guess
> this idea is visible in the patch 12).

It'd be much better if you could avoid putting the voltages in the
binding if they're not strictly required.

Attachment: signature.asc
Description: PGP signature