Messages in this thread | | | Date | Thu, 2 Oct 2008 10:31:37 +0200 | From | Pierre Ossman <> | Subject | Re: [PATCH 3/4] atmel-mci: support multiple mmc slots |
| |
On Thu, 25 Sep 2008 15:51:49 +0200 Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote:
> Pierre Ossman <drzeus-list@drzeus.cx> wrote: > > On Wed, 24 Sep 2008 16:35:27 +0200 > > Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote: > > > > Remember to deal with the case of a powered but unclocked card. This > > will primarily happen during card init, but it could should up later as > > well if we start implementing aggressive power management. > > Ok, but how _do_ I deal with that? If the clock is turned off due to > power management, it should be safe to leave it running at the same > rate. But how about initialization? Should I stall the queue until the > newly-powered card gets a clock rate? >
Yes, I don't see any other safe way of handling it.
> Btw, I just noticed that other thread about pxamci clock management. > Will it cause problems if the clock stops briefly from time to time? > Currently, the controller stops the clock if the FIFO gets full/empty > during transfer -- this is configurable, but I'd much rather let the > clock stop than risk FIFO overruns/underruns...
Hopefully not. :)
The spec gives no other means of flow control than messing with the clock. But as has been noted, some cards get a bit freaky if we leave them without a clock for too long, so care should be taken to try to minimise the time it is stopped.
Rgds -- -- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. [unhandled content-type:application/pgp-signature] | |