Re: MMC Driver RFC

[Richard Purdie]

Russell King:
> > The PXA code calls mmc_detect_change() whenever an interrupt is detected.
> > The MMC core then does a schedule_work(&host->detect). The problem is 
> > that
> > when the interrupt is generated, the card may not be 100% inserted or 
> > 100%
> > removed. Given the mechanical nature of insertions and removals, 
> > electrical
> > contact is possible for a while after removal has been started (and a 
> > while
> > before insertion is complete).
>
> If your socket works like that, you need to handle that by using a timer
> yourself.  It normally only affects removal rather than insertion.

It has only shown up on removal events *so far*. I know that the interrupt 
triggers before the card is fully seated in the slot upon insertion on this 
device as well and I'd imagine it does so on other devices given the 
physical design of the cards. Initalisation whilst the electrical contacts 
are still moving can't be a wise idea even if it hasn't bitten anyone yet.

I'm therefore asking if there is a general case for waiting a short while 
after any card insertion/removal event?

If not, I will just have to delay the interrupt on my hardware as you 
suggest. (A user isn't going to notice 0.25s delay in the grand scheme of 
things...). I suspect I'll not be the last person to have problems with this 
though.

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

> > I suspect this is related to the 1ms wait that was added to mmc_setup() 
> > as
> > per comments. Is there any documentation which tells us exactly what 
> > timings
> > we should be aiming for here? Has anyone else has problems like this?
>
> There isn't any 1ms wait in mmc_setup().

I was referrng to the 1ms delay in mmc_idle_cards() which is called twice by 
mmc_setup(). There is a comment about it in mmc_setup(): "We wait 1ms to 
give cards time to respond.". Was this just derived from experimentation?

> People are nervous about SD support - the SD forum has been traditionally
> rather closed, and there is the perception that a SD card driver may not
> go down well.  I have even heard rumours of patent issues/IP issues in
> this area, and I don't wish to get stung.
>
> However, that said, the situation has improved recently - we've gone from
> no documentation to limited documentation.  However, this documentation
> still isn't sufficient to do the job - eg, the SD formats for the CID
> and CSD registers remain completely undocumented.

Looking at the code from hh.org, it could be (and probably has been) derived 
from the documentation available so I can't see a patent/IP problem although 
I understand the concern. I agree that lack of info about the formatting of 
CID and CSD registers is an issue although the hh.org code does seem to 
work. Is guessing what the values mean an IP/patent infringement?...

Richard 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/