Re: [PATCH 1/2] MMC Agressive clocking framework v7

[Linus Walleij <linus.walleij@stericsson.com>]

Ohad Ben-Cohen wrote:

> Have you considered migrating this to runtime PM API ?
>
> Runtime PM core already provides most of the necessary plumbing:
> referred work, reference counting, tunable delay, active/suspended
> status, etc..

Doesn't it require a struct device* to be used?

I cannot use the host controller struct because that may be using
dev_pm_ops for some other scheme.

> It will also allow you to avoid overloading the set_ios() operation:
> once suspended, host controllers will receive an idle notification
> from runtime PM core. also CONFIG_MMC_CLKGATE will probably not be
> needed anymore (no API changes so everything should just work as
> before. only difference is that now hosts can start supporting  these
> runtime PM notifications).

Then you must mean that it should be implemented in each and every
driver instead, like it is today. We had a long discussion about
that already.

This means replicating the knowledge of the last card operation,
the 8 MCI cycles required for the timeout and the check
that the card is not sdio into every single driver instead of
moving it up in the core (as was Pierre Ossmans original
suggestion some two years ago or so).

Right now the way I see it the host driver can support
dev_pm_ops and simply call runtime_pm_put() when it recieves an
ios with clock frequency 0, so it's not like it contradicts
runtime PM.

The plumbing used in runtime PM is however very applicable to the
task, so if it could be made to work in a subsystem without any
struct device* anchor, it would be very reusable. Is this
feasible?

Yours,
Linus Walleij