Re: [RFC] MMC: Proposals on reworking clock and power management

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

 



2010/10/27 Ghorai, Sukumar <s-ghorai@xxxxxx>:

>     Option-3: with the *existing* API calls, namely the set_ios()
>               method as proposed by Linus Walleij  [4]

OK do you want to pick this up and fix it Sukumar? I will be
happy to review and test it on our hardware and forward-port
the second patch with the MMCI hooks.

I have this patchset on my TODO list, sadly with everything
else, I may find time on a flight tonite to look at it if there is
a lot of interest.

>   2.a) Card sleep, Power cutoff to the card:
>     This should be handled in the core where based on block layer
>     activity, calling corresponding API's from bus layer:
>     mmc_power_save_host/ mmc_power_restore_host

I think this is already discussed. What needs to be done in the
core is in the first patch, the driver then knows if the core is
happy with you shutting off the clock to the card, whether you
do it or not and under what circumstances is up to the driver.

The driver can then play around with it block clock and PM
hooks and whatnot, AFAICT the core does not need to be
aware of such stuff.

> 3. MMC_CAP_DISABLE - should not be a host capability.  This should be
>   a core feature that should be _transparent_  to all hosts with no
>   changes to any of the host drivers.

In my patchset the .set_ios(0) stuff is a Kconfig option. It cannot
be on per default until we are sure that all drivers will properly
deal with a zero clock argument from .set_ios(). If you're
confident with all host drivers handling the occasional .set_ios(0)
by all means just default-activate it.

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


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux