(This mail is cross-posted in order to reach the people most affected, so make sure you edit your receiver list when replying)
Hi everyone,
As I've mentioned to some of you, I've been working on restructuring the MMC layer in order to make it more easily maintained and to allow extensions like SDIO support. A first draft of this is now
ready for public review. I've cc:d those who have been waiting for this patch set (and Russell since he always gives blunt, but valuable feedback ;)).
Because of the size of the thing I decided to not attach it, but instead publish it in my public git tree:
http://www.kernel.org/git/?p=linux/kernel/git/drzeus/mmc.git;a=log;h=mmc-ng
One major mess right now is that the MMC layer handles two tasks: arbitrating who gets access to buses and cards, and initialising new cards as they are discovered. These two are currently intertwined
and it is difficult to get a decent overview of the system.
This first draft tries to solve this by moving all protocol stuff to their own files. The new core simply identifies what type of card that is present, then delegates the rest of the initialisation.
The commits themselves are a bit rough and will be more fine grained in a final version, but the end result should be the same. So I'd like to get as much input as possible from anyone who has the
time to review it. There are lots of changes, so I'm bound to have made mistakes in a few places.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
Pierre Ossman wrote:
> Hi everyone,
>
> As I've mentioned to some of you, I've been working on restructuring the MMC
> layer in order to make it more easily maintained and to allow extensions
> like SDIO support. A first draft of this is now ready for public review.
> I've cc:d those who have been waiting for this patch set (and Russell since
> he always gives blunt, but valuable feedback ;)).
So, I think I'm a bit too much of a kernel newbie to be able to provide a
definitive review, but I've looked over the changes and they look good to me.
I fully agree with the rearchitecturing - it makes it a lot easier to see
what's going on and it'll scale for SDIO (as you mention) and CE-ATA as well,
if we ever get a hold of any of those :-)
One concrete observation I'd make is that we should probably try and detect
MMC first instead of SD. Up until today, I'd have said it didn't really
matter, but I've been doing some reading and discovered that Protec make
some very strange cards they call "SuperSD" which can talk mmc4 and sd 1.1.
These will happily go along with either initialisation sequence - and as mmc4
is either the same or better than sd 1.1 from a performance point of view,
we should prefer it. This is independent of your restructuring, but as you're
fiddling with this code... :-)
http://www.hjreggel.net/cardspeed/special-sd.html#supersd
http://www.jactron.co.uk/pretec/ssd/consumer/super-sd.htm
--phil
Philip Langdale wrote:
> So, I think I'm a bit too much of a kernel newbie to be able to provide a
> definitive review, but I've looked over the changes and they look good to me.
>
Good to hear. I'd like to get this in ASAP, but in order to make sure
everyone gets a look at it, it'll have to go a round in -mm during the
next kernel.
> I fully agree with the rearchitecturing - it makes it a lot easier to see
> what's going on and it'll scale for SDIO (as you mention) and CE-ATA as well,
> if we ever get a hold of any of those :-)
>
With the very generous help of John Gilmore, I think we'll have those
sorted out in a jiffy. :)
> One concrete observation I'd make is that we should probably try and detect
> MMC first instead of SD. Up until today, I'd have said it didn't really
> matter, but I've been doing some reading and discovered that Protec make
> some very strange cards they call "SuperSD" which can talk mmc4 and sd 1.1.
> These will happily go along with either initialisation sequence - and as mmc4
> is either the same or better than sd 1.1 from a performance point of view,
> we should prefer it. This is independent of your restructuring, but as you're
> fiddling with this code... :-)
>
Eeeeww... This is a problem as the SD spec. clearly states the order of
init commands. So I wouldn't be surprised if we find SD cards that choke
on the MMC init sequence.
I guess what we lose by not supporting these is 8 bit data bus, but as
we do not currently have a controller for that I think the point is moot.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
Pierre Ossman wrote:
>
> Eeeeww... This is a problem as the SD spec. clearly states the order of
> init commands. So I wouldn't be surprised if we find SD cards that choke
> on the MMC init sequence.
>
> I guess what we lose by not supporting these is 8 bit data bus, but as
> we do not currently have a controller for that I think the point is moot.
Hrm. Even the MMC 4.1 App Note describes a unified init sequence where SD is
checked first.
So, these cards are essentially useless then. The number of hosts that support
MMC 4 but not SD can probably be counted on no hands. :-)
--phil