Re: [RFC 0/2] Qualcomm RPM sleep states

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu 04 Dec 13:15 PST 2014, Stephen Boyd wrote:

> On 11/28/2014 12:16 PM, Mark Brown wrote:
> > On Thu, Nov 27, 2014 at 11:42:41AM -0800, Bjorn Andersson wrote:

[..]

> >> The exposure of multiple regulators moves the problem to the
> >> devicetree, making sure to map the consumers to the right
> >> state/regulator. But it should only be the cpu (in its various forms)
> >> that ever consume the active only regulator.
> > He said hopefully...  :)

:)

> >
> > I think I now have a reasonable picture of what's going on but wanted to
> > confirm that what I'm saying above makes sense.
> 
> That's good. Is there any conclusion here? I'm still thinking that
> having multiple regulators for the same physical supply is the right
> thing to do.
> 

As I said, the only other idea I've come up with will not cut it for the
regulators that need more than enable/disable support when going to sleep.

Even if we came up with some model of exposing something similar to the suspend
state, we would still need to expose it in a way that we can specify which
(active/sleep/both) state in the consumer. Hence in practice we end up with
exposing multiple regulators in one way or another.


I can't help thinking that this would be a problem with the static suspend
settings as well; i.e. what is the static suspend state for a regulator that
powers a WiFi chip? For me the answer would often be "it's enabled iff the WiFi
consumer asks for it" - but maybe it's not supposed to be used for "dynamic"
regulators.


Nontheless, we have reached conclusions regarding my RFC. So I'll move on and
finish up a multi-regulator implementation and we can continue the discussion
based on that.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux