Hello Again Mark, Sorry for long delay - I am really having too many things on my table right now :/ On Tue, 2019-11-19 at 19:36 +0000, Mark Brown wrote: > 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". 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. 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. 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 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 7 support this. Rest of the LDOs and BUCKs (and also those DVS bucks which are not configured to be controlled by run-levels) have modes RUN and IDLE, where the processor stays powered. In addition to these (active) modes/states, there is few states where processor is not powered. I guess these could be mapped to 'different' suspend states. At least LPSR, HBNT and SHIP states are such. These are again global PMIC states - not per regulator states. They can be either controlled by driving a pin on PMIC - or by I2C register setting. I don't see how I could differentiate these states when using standard APIs - nor do I know if these should be changed via regulator interfaces at all. All in all - I am also a bit unsure how I should do the mapping of the PMIC low-power modes to the modes used by Linux - the curse of working for component vendor is that I have limited visibility to actual end- products - if they are not in-tree. :( And I don't think we have any in-tree boards which use these low-power states (at least for now) - So if you or Rob do not object - I will leave these bindings in this doc - but I need to consider the value of adding stuff presented in patch 12 in-tree kernel... Guess I'll drop it out unless I get some better understanding how run-levels and low-power modes are handled in some of the actual devices. We can always add this support later :) > > > 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. 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 ;) 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). Br, Matti Vaittinen
