+Olof who posted the patch that Yuvaraj referenced. On Tue, Jul 1, 2014 at 5:20 AM, Yuvaraj Cd <yuvaraj.lkml@xxxxxxxxx> wrote: > On Tue, Jul 1, 2014 at 12:27 PM, James Cameron <quozl@xxxxxxxxxx> wrote: >> On Mon, Jun 30, 2014 at 11:44:29PM -0700, Bing Zhao wrote: >>> I may have missed something, but doesn't the MMC_POWER_OFF and >>> MMC_POWER_ON|UP handling in controller driver help? >>> Anyway the clocks/GPIOs/regulators are sort of platform >>> dependent. Would it be better putting it in /arch/arm/mach-xxxxx/? >> >> Wouldn't device tree for mmc be better? > I have come across same problem.Below is the thread in which more > discussions happened on this. > http://patchwork.ozlabs.org/patch/312444/ > I am adding few more those who are interested in this solution. Thanks to Yuvaraj for referencing the old thread. It seems like there are already enough chefs in the kitchen so I'm not going to add any more suggestions myself. I'll point out that on all ARM Chromebooks (which to date have a Marvell part connected via SDIO) all face the same problem. In production kernels we've continued to get by with various hacks. The current kernels use a hack with regulator chaining and assumptions about 32K clocks already being on. This is less egregious than the hacks in older kernels which initted WiFi in the LCD backlight function (dont ask) but is still a hack. -Doug -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
