[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20081002103137.57f5a9ad@mjolnir.drzeus.cx>
Date: Thu, 2 Oct 2008 10:31:37 +0200
From: Pierre Ossman <drzeus-list@...eus.cx>
To: Haavard Skinnemoen <haavard.skinnemoen@...el.com>
Cc: kernel@...32linux.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] atmel-mci: support multiple mmc slots
On Thu, 25 Sep 2008 15:51:49 +0200
Haavard Skinnemoen <haavard.skinnemoen@...el.com> wrote:
> Pierre Ossman <drzeus-list@...eus.cx> wrote:
> > On Wed, 24 Sep 2008 16:35:27 +0200
> > Haavard Skinnemoen <haavard.skinnemoen@...el.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.
Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)
Powered by blists - more mailing lists