Re: [PATCH 3/4] atmel-mci: support multiple mmc slots

[Pierre Ossman <drzeus-list@drzeus.cx>]

[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]