Re: MMC Driver RFC

[Ian Molton]

Pierre Ossman wrote:
> Nice too see that you're alive Ian ;)
>
> I've been trying to send you some mail regarding your SD implementation 
> but I haven't received any replies. Perhaps they've gotten lost somewhere?

I've been getting errors replying to you but had no alternative address 
to use. perhaps you could mail me from another account ?

> A summary of what I've done (relative your work):
>
> * flags renamed to caps to better reflect what it does.
> * SD_4_BITS changed to 4_BIT_DATA. Hopefully 4-bit mode in SD and MMC 
> will be compatible, at least on the driver level.
> * HOST_ changed to MMC_ to conform with the rest of the macros.
> * Added a function in the driver to test for SD read-only switch.

Good stuff.

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

> * SCR register is read from card and used when determining bus width.

Good. This was needed.

> * I've separated SD detection a bit.

Good (see above :)

> * 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 also couldn't find the reason for the ACMD flags you've added. 
> Application commands only differ in semantics, not format, so I couldn't 
> figure out why these where needed. Perhaps I'm missing something.

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

> > as such my code should be 100% safe to commit to the kernel.
>
> My code is based on the SD card specs I've found so it probably isn't as 
> safe.

The card specs I have seen were public docs so we should be clear there.


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