On Fri, 6 Jan 2012, Magnus Damm wrote: > Hi Guennadi, > > On Wed, Jan 4, 2012 at 11:17 PM, Guennadi Liakhovetski > <g.liakhovetski@xxxxxx> wrote: > > On ARM the same clock is used by the PM subsystem and by the driver > > directly. This leads to the clock staying permanently on, independent of > > the runtime PM state. This patch makes clock enable and disable calls in > > the driver SuperH-specific. > > > > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@xxxxxx> > > --- > > drivers/mmc/host/sh_mobile_sdhi.c | 6 ++++++ > > 1 files changed, 6 insertions(+), 0 deletions(-) > > Thanks for your patch. > > >From my point of view there is very little difference between SH and > SH-Mobile ARM, so I don't understand the special treatment. Also, is > this change really needed for SH with your recent Runtime PM patches? I didn't try SuperH. I seem to remember, there were 2 clocks per SDHI controller on some platforms, of which one was handled by runtime PM and the other one directly. However, a quick look through SDHI users didn't reveal any such cases, so, maybe I'm confusing SDHI with some other hardware block. In that case - yes, I'd gladly remove that handling completely! > I believe we need to make use of the clock framework to get the clock > rate configuration in the SDHI driver. At the same time we want to > stop the clock as frequently as possible. I believe we should disable > and enable the clock together with the Runtime PM get/put operations - > pretty much exactly like our I2C master driver does. The only problem > is, while the clock is disabled the clock rate may be changed. So we > need to be able to notify the MMC subsystem about the new clock rate. > > Any ideas on how to make this happen? Huh, if that's really possible... I'll have a look at that. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
