Hello Mark! On Fri, 2019-11-29 at 12:09 +0000, Mark Brown wrote: > 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. 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). For example, from CPU point of view the BD71828 PMIC states HIBERNATE and LPSR are probably both just "suspend" - but the PMIC could set different voltages or ON/OFF states for some regulators depending on the 'suspend' target (LPSR or HIBERNATE or STANDBY). Yet, as I said, I haven't seen how these states are used by real devices - we don't currently have any in-tree SoCs which use BD71828 and utilize these states (as far as I know). Hence I can't really figure out how to add support for these PMIC features if there is no 'de-facto' mechanism in place :( > > > 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. Yes. But this does only allow setting one suspend voltage for regulator, not own voltage for HIBERNATE, LPSR, STANDBY etc - or am I mistaken? > > 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. 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. > > 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. Thanks. As I said, I thought the 'quality of regulation' states could have been supporting also changing the voltages. > > > > 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. Right. I guess your answers mean that there is no "regulator group control" for "adaptive voltage changes" supported by regulator framework / cpufreq - as of now. Furthermore, I have understood that it is different story depending on PMIC and CPU/SoC capabilities. (Like PMIC inbuilt states and state change mechanisms, SoC voltage scaling support etc.) > 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. Hmm.. I guess I can omit that from in-tree driver for now. I can try maintaining own set of patches for existing customers for now. I think adding these to bindings later is not impossible :) Removing them would probably be harder. Thanks again Mark. I truly appreciate your help and guidance :) Br, Matti
