Re: MMC Driver RFC

[Pierre Ossman <drzeus-list@drzeus.cx>]

Ian Molton wrote:

>
> I've been getting errors replying to you but had no alternative 
> address to use. perhaps you could mail me from another account ?
>
Afraid everything gets routed to the same account in the end anyway. I 
checked the logs and the problem is that your mail server has a HELO 
that differs from its IP (outmail.freedom2surf.net vs. 194.106.33.237). 
Reverse is ok, but forward points to 194.106.56.14.

>> * Moved SD-specific commands to a separate section in the header so 
>> they are more easily distinguished.
>
>
> I had been meaning to move all the c code referencing SD to a seperate 
> sd.c file such that it could be compiled optionally on top of MMC. at 
> the time it wasnt mature enough to be worth it, but that may be worth 
> revisiting now.
>
I've had the same idea. But I think it will be difficult since we need 
som funky logic during init. Perhaps a model where each mode 
(MMC/SD/SDIO) each gets their turn trying to find something on the bus. 
But this would require a rather large rewrite of the MMC layer. We would 
need to separate MMC logic from the driver interface. And mmc_block and 
sd_block would more or less be the same. Considering how much is similar 
(and most people want SD support anyhow), I'm not sure that we have much 
to gain from separating them.

>> * The mode (SD/MMC) of the host is stored. Since MMC uses a bus 
>> topology and SD uses a star one it is useful to be able to see which 
>> mode the controller is in.
>
>
> Is this needed? presumably any controller that implements MMC/SD slots 
> can only have one card/slot anyhow.
>
> Mind you, I have plans to look at SDIO, so that may alter things...
>
I need it to determine if the code should send an RCA or ask for one, 
and to determine if it should try and read the SCR. Your solution used 
an extra parameter but I thought a mode flag would be better since we 
might need to know mode later on (after init.).

>
> The toshiba controller appears to want to be told when an ACMD is 
> issued, compared to a normal CMD.

No hints in the spec about why? Seems very strange since there's no 
change in what goes over the wire.

Rgds
Pierre