Re: MMC Driver RFC

From: Pierre Ossman
Date: Sun Jan 16 2005 - 07:24:27 EST


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

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