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
