Thread (49 messages) 49 messages, 7 authors, 2014-06-09

Re: RFC: representing sdio devices oob interrupt, clks, etc. in device tree

From: Ulf Hansson <hidden>
Date: 2014-06-09 14:07:54
Also in: linux-arm-kernel, linux-mmc

On 4 June 2014 17:55, Mark Brown [off-list ref] wrote:
On Tue, Jun 03, 2014 at 12:57:52PM +0200, Ulf Hansson wrote:
quoted
On 28 May 2014 13:03, Mark Brown [off-list ref] wrote:
quoted
quoted
No, runtime PM isn't really fine grained - I'm talking about things
like starting and stopping individual resources or configuring them.
quoted
Are you saying that you have several levels of quiescent mode of your
external chip?
Partly, but also there can be active modes that don't use all
functionality and hence can leave some of the inputs powered down (for
example if a reference clock is used for some feature that isn't used
all the time then that reference clock may be able to be powered down
when the function is not in use).  The device isn't suspended but it can
do without some of the resources it has.
quoted
I am a bit puzzled of how such library should look like, but I suppose
we need to be able to go to different power states through it.
Typically the library may be invoked both from the mmc core to do
power up/off and from the sdio func driver to handle power save.
quoted
Does it make sense to you as well?
Yes, certainly for the power up/down and runtime PM type operations.
For your information; I have started implementing a library to handle
power sequences. I intend to have this separated from mmc, to let
other subsystems re-use the same code.

It will not require a compatible string, but instead use something
like 'power-method = blah' property.

I intend to post this as an RFC in couple of days.

Kind regards
Uffe
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help