2010/10/27 Ghorai, Sukumar <s-gho...@ti.com>: > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
