Re: [RFC][PATCH] MMC: Major restructuring and cleanup
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] MMC: Major restructuring and cleanup
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 maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] MMC: Major restructuring and cleanup
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] MMC: Major restructuring and cleanup
(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 maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
