On Mon, Dec 08, 2014 at 12:55:03PM -0800, Bjorn Andersson wrote: > On Mon 08 Dec 11:39 PST 2014, Mark Brown wrote:
> > Now I'm confused again. I thought entry and exit was all done > > separately so it was just about saying what should happen if the device > > were to idle? > But how do you actually expose that control to the consumers? I think having an idle state (or possibly just using the suspend state, I'm still foggy if the two states are actually different) seems to make sense? > > That's what should happen, we just don't currently really support doing > > this configuration dynamically (practically speaking I suspect anyone > > who cares just doesn't have a suspend mode for affected regulators at > > the minute). > What would such configuration look like? > In the suspend case you could introduce an api for setting parameters of the > suspend state, but that means that the individual drivers needs to be written > with awareness of the system state. Our proposal is to use the same api, but > with a different regulator*, but how should that acquired (and expressed in > dt). We already have an API for the suspend state, we just don't enable its use in DT yet other than static configuration. I'm not sure I see the connection to the system state in the consumer API here - I thought this was pretty much just setting the state when the device is turned off which seems device specific? > In our case, as most things change the both state (or active only if no > both/sleep), the standard regulator api would have to affect the both state. > Would we then have a separate api to modify the active state? Why would we need to introduce a new API for the active state?
signature.asc
Description: Digital signature
