Messages in this thread | | | Date | Tue, 23 Sep 2008 21:12:22 +0200 | From | Pierre Ossman <> | Subject | Re: [PATCH 3/4] atmel-mci: support multiple mmc slots |
| |
On Tue, 23 Sep 2008 20:16:50 +0200 Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote:
> Pierre Ossman <drzeus-list@drzeus.cx> wrote: > > > > You forgot the most important part; how to handle the clock given two > > different requests. > > I don't think I did. The set_ios() function merely calculates the value > of MR and stashes it away. It isn't written to the controller until > after the host has been claimed for a request. >
I see... It still doesn't take into account conflicting clocks. Or does the multiplexer disable the clock for the inactive slot?
> > (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.
> Though I don't understand why the core would care about clocks. >
Power management. But it needs to be handled centrally. Primarily because of the reason above, but you might also have such things as SDIO functions requiring the clock to be on.
> > > > Fall back to polling? > > Probably, yes. Can I fall back to polling after the host has been > registered? >
Hmm... no. Not sure how to handle this...
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] | |