Re: MMC Driver RFC

[Ian Molton <spyro@f2s.com>]

Russell King wrote:

> That depends whether the hardware already provides 0.5s of debounce
> already.  Some people do, some people don't.  This is why it needs to
> be left to the implementation and not a core issue.

Agreed. IIRC my toshiba PDAs *dont* provide a delay. OTOH they also 
provide *two* ways of detecting card presence...

>>>>2. Card Initialisation Problems
>>>
>>>Different cards behave differently.  I suspect you have yet another
>>>quirky card.
>>
>>What is the policy on handling this? Pin the error down, then see what can 
>>be done about it? I'll just have to move delays about until I find the one 
>>that helps guess.
>>
>>I was wondering if there was some kind of timing specification somewhere as 
>>all these cards seem to work fine under other operating systems...
> 
> That's probably the official MMC specification from the MMC forum.  Us
> mere open source developers don't have access to such costly specs, so
> we have to make do with the specs released by card manufacturers which
> do go into the protocol sufficiently deeply.
> 
> Unfortunately, such specs only cover MMC cards and not SD cards.

ISTR seeing a SD card doc at some point

> I have no idea - and that's the big problem.  We just don't know
> what the situation is with SD.
> 
> Maybe now that it's more wildly known that there's SD support available
> from handhelds.org, maybe (if the SD forum are reading lkml) we'll see
> some reaction.  Let's just hope it's positive.

Well I *know* I never saw the specs from the SD forum. I hacve never 
reverse engineered a SDHC core driver either (I have reverse engineered 
a chip driver but it contained no SD *protocol* information.

as such my code should be 100% safe to commit to the kernel.

PS. Richard - I am here - hope you receive this!