Messages in this thread |  | | Date | Mon, 3 Aug 2009 11:52:00 +0900 | Subject | Re: MMC: Make the configuration memory resource optional | From | Magnus Damm <> |
| |
On Fri, Jul 31, 2009 at 4:21 AM, Ian Molton<ian@mnementh.co.uk> wrote: > Guennadi Liakhovetski wrote: > >> While you're at it, please, consider swapping the two lines in >> tmio_mmc_probe(): >> >> - tmio_mmc_clk_stop(host); >> reset(host); >> + tmio_mmc_clk_stop(host); >> >> Otherwise, I think, reset causes problems trying to access the controller >> with disabled clock. At least this is needed on SuperH. > > Interesting. I'll see what the result of this is on TMIO - This sequence was > garnered from the WinCE driver for the chip. > > I cant see _why_ this should be a problem, as this disables the card clock, > not HCLK. Could you debug further in tmio_mmc_clk_stop() please and see if > reordering only one of the two IO accesses cures this?
I wonder if the clock framework patch from Guennadi ties in the clock that drives the TMIO block, instead of the interface clock that is used to communicate with the physical media? That would explain the reordering of the tmio_mmc_clk_stop() function.
In my mind, using the clock framework to control the interface clock sounds like a good plan. As for the clock that drives the TMIO block itself (that Guennadi's patch tries to control) - on a second thought it may make more sense to use the upcoming Runtime PM framework to control that one.
Making use of the Runtime PM comes with a big advantage - it will provide use with hooks to allow saving and restoring register context so the power domain containing the TMIO block can be powered off during runtime.
I'd be happy to fix up the Runtime PM related parts of the tmio_mmc driver if you'd like. The Runtime PM changes will of course "just work" in the MFD case - ie do nothing unless your architecture has support for it.
The recently posted Runtime PM patch for the SuperH Mobile I2C driver may serve as an example: http://patchwork.kernel.org/patch/38514/
Another solution is of course to use two clocks in TMIO driver - one for the interface clock and one for the hardware block itself. This may be better if you want to control the hardware block clocks from the MFD layer in the future. Let me know what you think.
Thanks for your help.
Cheers,
/ magnus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |