lkml.org 
[lkml]   [2008]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/4] atmel-mci: support multiple mmc slots
Pierre Ossman <drzeus-list@drzeus.cx> wrote:
> On Wed, 24 Sep 2008 16:35:27 +0200
> Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote:
>
> >
> > On AP7000, the clock line is shared. Do I have to run the clock at the
> > minimum of the two slots' maximum rates, or does it only matter when
> > the card is being accessed?
> >
>
> I'd say always. I'd never dare overclock something that's powered, even
> if we're not currently communicating with it.

Ok.

> 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?

> > > > > (This will also get a bit more painful when/if the core starts
> > > > > disabling the clock when a card is idle)
> > > >
> > > > The atmel-mci driver already stops the clock between requests.
> > >
> > > Then I expect a patch to remove that. Fiddling with the clock is
> > > dangerous and I've seen everything from hung cards to silently broken
> > > writes when you disable the clock too early after a request.
> >
> > Ok. I'll see if I can fix that -- I take it you want a patch for
> > 2.6.27, then?
> >
>
> .28 should be fine. It's a pretty uncommon bug.

Ok, good. A change like that needs quite extensive testing.

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...

Haavard


\
 
 \ /
  Last update: 2008-09-25 15:55    [W:0.196 / U:0.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site