Re: New MMC maintainer needed
Pierre Ossman : This things are currently lingering in my inbox: [..] [PATCH 1/2] atmel-mci: Unified Atmel MCI drivers (AVR32 AT91) http://marc.info/?l=linux-arm-kernelm=124577578729455 This is nice work and it's really up to Nicolas when he wants it merged. Ok guys, it should be fine if we can plan a merge for those bits: I have additional patches that are waiting on top of this one... Thanks a lot. Bye, -- Nicolas Ferre -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
Matt Fleming wrote: On Mon, Aug 03, 2009 at 02:13:28PM +0300, Adrian Hunter wrote: Pierre Ossman wrote: Con: - The scanning code gets less clear as you increase the number of possible paths through it. - Different systems will have different init sequences, possibly provoking bugs in the cards. - Host driver writers now have more capability bits they have to consider. And these might be less than obvious since SD/MMC/SDIO are normally compatible so these bits seem useless. - With the current logic (which was better in the first version), normal drivers will have to explicitly state that they work as intended by setting all bits. And the pro is objective. Pro: - A slightly reduced scanning time. That's great! Why do you disregard this so easily? Ping. Adrian, do you have any initialisation times for this patch? I'm afraid I don't have any eMMC hardware, so I'm not able to gather any numbers. Sorry for the slow reply. Results in microseconds: before after eMMC194145 193641 uSD 41432129 However, that excludes powering up. For example the pbias setting on omap_hsmmc for MMC1 (uSD for us) has a 100ms delay. So the difference is negligible. Although, the notion of unnecessarily sending SDIO commands to an uSD, and SDIO and SD commands to an eMMC, seems wrong. Especially when trying to debug very-hard-to-reproduce errors. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Wed, Aug 12, 2009 at 03:27:31PM -0700, Andrew Morton wrote: davem has set up linux-...@vger.kernel.org for us. It will be archived at marc.info. Thanks to both.. I was thinking that we wouldn't need a separate list but then I realised I didn't have anywhere to send MMC bug reports. echo subscribe linux-mmc | mail majord...@vger.kernel.org Unless someone has beaten me to it, From a920e6c11635cab6261541a487db7b68b4892a74 Mon Sep 17 00:00:00 2001 From: Matt Fleming m...@console-pimps.org Date: Thu, 13 Aug 2009 09:17:23 +0100 Subject: [PATCH] mmc: Add linux-mmc mailing list A new linux-mmc mailing list has been set up at vger.kernel.org for all things related to MMC/SD development. Signed-off-by: Matt Fleming m...@console-pimps.org --- MAINTAINERS |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b1114cf..e16c7dd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3420,6 +3420,7 @@ S:Supported F: drivers/mfd/ MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM +L: linux-...@vger.kernel.org S: Orphan F: drivers/mmc/ F: include/linux/mmc/ -- 1.6.4.rc0 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
davem has set up linux-...@vger.kernel.org for us. It will be archived at marc.info. Thanks to both.. I was thinking that we wouldn't need a separate list but then I realised I didn't have anywhere to send MMC bug reports. echo subscribe linux-mmc | mail majord...@vger.kernel.org -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Friday 31 July 2009, Pierre Ossman wrote: Restoring back the system state from MMC after a successful hibernation http://marc.info/?t=12481853473r=1w=2 I don't agree with this approach. The point of the workqueue is so that the kernel can do things in parallel, so this patch is a step back. The problem is really with how the kernel doesn't properly cope with asynchronous disk scanning during bootup. The root_delay parameter was added for this for the normal case, but it seems more work is needed. Doesn't handing of resumes needs more attention overall? Example, root on eMMC (e.g. a 32-MByte non-removable chip) wouldn't resume at all well the last time I checked ... mounted file systems (not just root) made trouble. Hardware that reliably reports card insert/remove was rude in the same ways. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Fri, 31 Jul 2009 11:54:07 +0100 Matt Fleming m...@console-pimps.org wrote: On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote: [PATCH 0/32] mmc and omap_hsmmc patches http://marc.info/?t=124722953900010r=1w=2 I haven't looked through these at all. The ones affecting the core probably need some thorough reviews. I did notice the patch to say which cards a controller supports though, and I'm very sceptical about that one. The scanning process should work anyway, and the performance impact should be negligible as it is only on init. So that patch only adds complexity and confusion IMO. How much complexity does it really add? Surely it's better to give the host controller driver writers the ability to not entertain supporting some cards if they cannot be used? If they want to avoid the scanning process for certain cards, why not let them? Let's look at the pros and cons of this: Con: - The scanning code gets less clear as you increase the number of possible paths through it. - Different systems will have different init sequences, possibly provoking bugs in the cards. - Host driver writers now have more capability bits they have to consider. And these might be less than obvious since SD/MMC/SDIO are normally compatible so these bits seem useless. - With the current logic (which was better in the first version), normal drivers will have to explicitly state that they work as intended by setting all bits. Pro: - A slightly reduced scanning time. I simply don't see it as being worth it. Linux patches generally need to provide the answer to Why?, not just be able to avoid Why not?. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: New MMC maintainer needed
On Mon, Aug 03, 2009 at 12:34:29PM +0200, Pierre Ossman wrote: On Fri, 31 Jul 2009 11:54:07 +0100 Matt Fleming m...@console-pimps.org wrote: On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote: [PATCH 0/32] mmc and omap_hsmmc patches http://marc.info/?t=124722953900010r=1w=2 I haven't looked through these at all. The ones affecting the core probably need some thorough reviews. I did notice the patch to say which cards a controller supports though, and I'm very sceptical about that one. The scanning process should work anyway, and the performance impact should be negligible as it is only on init. So that patch only adds complexity and confusion IMO. How much complexity does it really add? Surely it's better to give the host controller driver writers the ability to not entertain supporting some cards if they cannot be used? If they want to avoid the scanning process for certain cards, why not let them? Let's look at the pros and cons of this: Con: - The scanning code gets less clear as you increase the number of possible paths through it. Yes, it does but the function is only small. It's not that much more complexity. And there's a trade off here between the added complexity and the shorter initialisation time for cards. Running initialisation functions on cards that don't need it just seems pointless. - Different systems will have different init sequences, possibly provoking bugs in the cards. Good. I'd like to know about bugs in the cards so that we can fix/work around any issues. This seems like a pretty weak argument against the change to me. - Host driver writers now have more capability bits they have to consider. And these might be less than obvious since SD/MMC/SDIO are normally compatible so these bits seem useless. Yes, but they also have the flexibility to more clearly describe their host controllers. Besides, any new host controller driver will likely just copy one of the older drivers (which I updated) anyway. - With the current logic (which was better in the first version), normal drivers will have to explicitly state that they work as intended by setting all bits. I thought that the way I wrote the patch was more natural (which was why I rewrote Adrian's to begin with), but if you think the original was clearer I've no issue with pushing that patch through instead. Pro: - A slightly reduced scanning time. I simply don't see it as being worth it. Linux patches generally need to provide the answer to Why?, not just be able to avoid Why not?. That's not at all what I said, I have provided the why (and so have you by noting the Pro above). -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
Pierre Ossman wrote: On Fri, 31 Jul 2009 11:54:07 +0100 Matt Fleming m...@console-pimps.org wrote: On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote: [PATCH 0/32] mmc and omap_hsmmc patches http://marc.info/?t=124722953900010r=1w=2 I haven't looked through these at all. The ones affecting the core probably need some thorough reviews. I did notice the patch to say which cards a controller supports though, and I'm very sceptical about that one. The scanning process should work anyway, and the performance impact should be negligible as it is only on init. So that patch only adds complexity and confusion IMO. How much complexity does it really add? Surely it's better to give the host controller driver writers the ability to not entertain supporting some cards if they cannot be used? If they want to avoid the scanning process for certain cards, why not let them? Let's look at the pros and cons of this: But the cons are all subjective. Con: - The scanning code gets less clear as you increase the number of possible paths through it. - Different systems will have different init sequences, possibly provoking bugs in the cards. - Host driver writers now have more capability bits they have to consider. And these might be less than obvious since SD/MMC/SDIO are normally compatible so these bits seem useless. - With the current logic (which was better in the first version), normal drivers will have to explicitly state that they work as intended by setting all bits. And the pro is objective. Pro: - A slightly reduced scanning time. That's great! Why do you disregard this so easily? I simply don't see it as being worth it. Linux patches generally need to provide the answer to Why?, not just be able to avoid Why not?. You have just supplied answers to both Why? and Why not?. In my opinion Why? outweighs Why not? because the pro is objective and the cons and not. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Mon, 03 Aug 2009 14:13:28 +0300 Adrian Hunter adrian.hun...@nokia.com wrote: Pierre Ossman wrote: On Fri, 31 Jul 2009 11:54:07 +0100 Matt Fleming m...@console-pimps.org wrote: On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote: [PATCH 0/32] mmc and omap_hsmmc patches http://marc.info/?t=124722953900010r=1w=2 I haven't looked through these at all. The ones affecting the core probably need some thorough reviews. I did notice the patch to say which cards a controller supports though, and I'm very sceptical about that one. The scanning process should work anyway, and the performance impact should be negligible as it is only on init. So that patch only adds complexity and confusion IMO. How much complexity does it really add? Surely it's better to give the host controller driver writers the ability to not entertain supporting some cards if they cannot be used? If they want to avoid the scanning process for certain cards, why not let them? Let's look at the pros and cons of this: But the cons are all subjective. Con: - The scanning code gets less clear as you increase the number of possible paths through it. - Different systems will have different init sequences, possibly provoking bugs in the cards. - Host driver writers now have more capability bits they have to consider. And these might be less than obvious since SD/MMC/SDIO are normally compatible so these bits seem useless. - With the current logic (which was better in the first version), normal drivers will have to explicitly state that they work as intended by setting all bits. Subjective or not, they are real and valid. And the pro is objective. Pro: - A slightly reduced scanning time. That's great! Why do you disregard this so easily? Coz nobody quantified it. Let's go to the changelog: : Some hosts can accept only certain types of cards. For example, an eMMC : is MMC only and a uSD slot may be SD only. However the MMC card scanning : logic checks for all card types one by one. : : Add host capabilities to specify which card types can be used, and amend : the card scanning logic to skip scanning for those types which cannot be : used. See, it provides no reason at all for adding this additional complexity. Now we're told it's faster. OK. How much faster? Show us the numbers so we can all understand why the change is justifiable! -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
What to do now? Lift up your spirit and get back to work? ;-) -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Fri, 2009-07-31 at 23:53 -0700, Alex Dubov wrote: What to do now? Lift up your spirit and get back to work? ;-) Not a bad idea :-) Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
This things are currently lingering in my inbox: [PATCH 1/1] MMC: SDIO card reset support for Intel Moorestown platform http://lkml.org/lkml/2009/6/16/269 SDIO cards have a global reset that in theory might be useful. I'm not sure it is in practice though as it is a very blunt instrument and it has created some problems in the past. A PCI equivalent to this reset would be resetting an entire PCI card, making it and every subfunction fall off the bus and come back again. The complexity of handling this can be high since every subfunction needs to be involved. The patch above adds new callbacks to handle this, but I think it can proabably be handled as a normal removal/insertion. This reset should only be used as a last resort anyway. Lastly, using this reset method might not even be useful. The libertas guys tried using it to get back a wedged card, but they did not have much success. I recommend holding off on this functionality until someone can show that the added functionality is worth the complexity. [PATCH 1/2] MMC Agressive clocking framework http://marc.info/?l=linux-arm-kernelm=124394660502578w=2 (and several subsequent versions) I like this idea and it should be merged. What I didn't like about the initial versions were that the MMC core was too involved with low level decisions in drivers. IMO (and the PM guys from what I can tell) the drivers should automatically do relevant PM stuff, only restricted by what the MMC core has told the driver should be going on on the bus. The missing piece here was that the core needed to tell the drivers when they could turn off the clock on the bus. This can be difficult as some cards need the clock to drive their internal logic for writes (although this is in violation of the specs). This means the clock needs to be left running some time after a request. There are also a bunch of drivers that tries to do this themselves, and often without the delay. These should be fixed to leave such decisions to the core. [PATCH] mmc: prevent dangling block device from accessing stale queues http://marc.info/?l=linux-kernelm=124413857119112 This one is more fun as it requires digging into the block layer. :/ The thread above describes the problem so I'm not going to reiterate it here. The short summary of why I don't want the patch though is that I believe it papers over the problem and doesn't solve it. I've been meaning to look further into the issue, but if someone else has the time then please go digging. [PATCH 1/2] atmel-mci: Unified Atmel MCI drivers (AVR32 AT91) http://marc.info/?l=linux-arm-kernelm=124577578729455 This is nice work and it's really up to Nicolas when he wants it merged. [PATCH] DaVinci: MMC: V5: MMC/SD controller driver for DaVinci family. (couldn't find an archive) This driver has undergone some reviews and should be more or less done. Please check the previous review comments to confirm that everything has been fixed. [PATCH] mmc_spi: fail gracefully if host or card do not support the switch command http://marc.info/?l=linux-kernelm=124473347118158 This is to work around buggy cards. I'm not convinced the problem is fully understood yet though so I need to look more at this. MMC driver for HTC Dream http://marc.info/?t=12463124022r=1w=2 This is a new driver that needs a review. It seems to make the classical mistakes, so have a look at my earlier driver reviews to see what to look for. [PATCH] MMC Core: Drop initialization frequency floor to 50kHz http://lkml.org/lkml/2009/7/1/529 The initial patch wasn't very good, but lowering the speed to 350 kHz should be okay. A new patch is needed and probably some testing in -next. [PATCH] MMCI: use AMBA bus accessors http://marc.info/?t=12468978043r=1w=2 http://marc.info/?t=12468997891r=1w=2 http://marc.info/?t=12468995675r=1w=2 http://marc.info/?t=12468995992r=1w=2 Should probably all be merged. [PATCH] Add support for debugging MMC channel individually. http://list.drzeus.cx/pipermail/sdhci-devel/2009-July/002713.html I agree with Marcel. This kind of fine grained control belongs in debugfs. [PATCH] sdio: do not ignore MMC_VDD_165_195 http://marc.info/?t=12476400031r=1w=2 There has already been some discussions around this, and quite correctly the bit this patch wants to use is undefined. Restoring back the system state from MMC after a successful hibernation http://marc.info/?t=12481853473r=1w=2 I don't agree with this approach. The point of the workqueue is so that the kernel can do things in parallel, so this patch is a step back. The problem is really with how the kernel doesn't properly cope with asynchronous disk scanning during bootup. The root_delay parameter was added for this for the normal case, but it seems more work is needed. move mmci-omap-hs's probe function to .devinit.text http://marc.info/?t=12473461301r=1w=2 Second patch is probably okay, but the maintainers need to respond. [PATCH 0/32] mmc and omap_hsmmc patches
Re: New MMC maintainer needed
On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote: [PATCH 0/32] mmc and omap_hsmmc patches http://marc.info/?t=124722953900010r=1w=2 I haven't looked through these at all. The ones affecting the core probably need some thorough reviews. I did notice the patch to say which cards a controller supports though, and I'm very sceptical about that one. The scanning process should work anyway, and the performance impact should be negligible as it is only on init. So that patch only adds complexity and confusion IMO. How much complexity does it really add? Surely it's better to give the host controller driver writers the ability to not entertain supporting some cards if they cannot be used? If they want to avoid the scanning process for certain cards, why not let them? -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
Andrew Morton wrote: I expect that Dave Miller can set up linux-...@vger.kernel.org in a jiffy. A MAINTAINERS patch should be made if this is done. I've sent him an email, will let you all know what happens. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
I use the public specs from sdcard.org for more or less everything. I also have a MMC 4 spec, which was generously donated to me by Nokia. Unfortunately I am not allowed to pass that on. I can look things up for people if they have specific questions though. The MMC Association has merged with JEDEC, so now everyone can download the specs, e.g. http://www.jedec.org/download/search/JESD84-A44.pdf . Segher -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
Matt Fleming wrote: Is the 3.00 spec publicly available? There does not appear to be a simplified version of the 3.00 specification. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ 'member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom' -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Wed, 22 Jul 2009 15:17:44 -0700 Andrew Morton a...@linux-foundation.org wrote: Thanks, Pierre. Until and unless someone else steps up I can act as maintainer of last resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi, gpio, i2o and about 1000 other identifiable subsystems. I'm not falling of the face of the earth here, so people can still cc me on MMC patches, although I probably cannot answer all of them. I don't want to be the bottle neck that keeps MMC patches and discussions moving at a glacial speed, which is the situation we're in today. Fortunately, MMC doesn't appear to have its own mailing list so I'll actually get to see the patches. I do monitor a couple of subsystem-specific lists (fbdev, hwmon) but the delays can be awful - a month or two. MMC discussions tend to often be very system specific, which makes lists such as the arm kernel list more appropriate. Also, I've always tried to steer people to LKML as it allows others to keep a casual eye on things. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: New MMC maintainer needed
On Thu, 23 Jul 2009 01:08:08 +0100 Ian Molton i...@mnementh.co.uk wrote: Pierre - do you have a bunch of MMC spec-type docs around? I've lost all but the few sparse datasheets for TMIO that I had, so some docs covering protocol / commands would be useful. Any references / downloads that you know of? I use the public specs from sdcard.org for more or less everything. I also have a MMC 4 spec, which was generously donated to me by Nokia. Unfortunately I am not allowed to pass that on. I can look things up for people if they have specific questions though. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: New MMC maintainer needed
I'll try to compose a list of outstanding discussions and patches so that people know what needs attention. I'll try to get that done in the next few days. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: New MMC maintainer needed
Pierre Ossman wrote: MMC discussions tend to often be very system specific, which makes lists such as the arm kernel list more appropriate. Also, I've always tried to steer people to LKML as it allows others to keep a casual eye on things. I think an MMC list wouldnt be a bad idea now that we have a sort of 'distributed maintainership' thing going on... itd help get people up to speed... -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Fri, 24 Jul 2009 15:29:44 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Thu, 23 Jul 2009 14:52:09 +0100
Matt Fleming m...@console-pimps.org wrote:
On Thu, Jul 23, 2009 at 09:50:03AM +0300, Ohad Ben-Cohen wrote:
Hi Andrew,
On Thu, Jul 23, 2009 at 9:22 AM, Andrew
Mortona...@linux-foundation.org wrote:
I actually already have a little pile of MMC things queued:
Please also consider queuing up the attached patch as well.
The patch is removing the current SDIO cards 1.8V limit, which is
needed for embedded
SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers
like we have on the ZOOM2 boards for example).
Thank you,
Ohad.
From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00
2001 From: Ohad Ben-Cohen o...@bencohen.org
Date: Wed, 15 Jul 2009 09:21:41 +0300
Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
This is needed for 1.8V embedded SDIO devices and supporting host
controllers (e.g. TI 127x and ZOOM2 boards)
Signed-off-by: Ohad Ben-Cohen o...@bencohen.org
---
drivers/mmc/core/sdio.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index fb99ccf..6f221dc 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host,
u32 ocr) ocr = ~0x7F;
}
- if (ocr MMC_VDD_165_195) {
- printk(KERN_WARNING %s: SDIO card claims to
support the
-incompletely defined 'low voltage
range'. This
-will be ignored.\n, mmc_hostname(host));
- ocr = ~MMC_VDD_165_195;
- }
-
host-ocr = mmc_select_voltage(host, ocr);
/*
--
1.5.4.3
Looks OK to me, I'm unaware of a reason to not allow a card to use
MMC_VDD_165_195 if that's what it wants.
Yes, that code was there from day #1, via Pierre's original commit.
There is no indication in either the code comments or the changelog
why it was done this way.
Other ways of finding out why this code is there include:
a) search the mailing list for review discussion. I can't find it
in my lkml archive.
b) ask Pierre :)
Both the (Simplified) SD and SDIO specifications do not formally define
the 'low voltage' range in the way the MMC spec does. ie: You won't
find anything in the SD specs that even tell you what the range is -
it just says that it exists.
So we (I wrote the first incarnation of this check for normal SD cards)
decided to bail if a card requested the low voltage range. Now, if
there's actually hardware out there that is SD/SDIO and operates at
1.8V, we should probably do something more appropriate. :-)
It's obviously an easy change but I'd feel a lot more comfortable if
someone can point us to a document that states that the SD/SDIO low
voltage range is defined to match the MMC one. Maybe one of the NDA
docs actually states this.
Andrew - I'm also willing to be cc'ed on MMC changes and I'll respond
to the best of my (limited) abilities.
--phil
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
Philip Langdale wrote: Both the (Simplified) SD and SDIO specifications do not formally define the 'low voltage' range in the way the MMC spec does. ie: You won't find anything in the SD specs that even tell you what the range is - it just says that it exists. Standard SD/SDIO cards only support 2.7-3.6V. 1.8V operation is added in SD physical spec 3.00 and is part of any of the UHS-1 modes (SDR12-SDR104 and DDR50). It has a different timings and requires a different (3.00 compliant) host controller. So we (I wrote the first incarnation of this check for normal SD cards) decided to bail if a card requested the low voltage range. Now, if there's actually hardware out there that is SD/SDIO and operates at 1.8V, we should probably do something more appropriate. :-) The SD/SDIO stack must ignore reserved bits unless a per-card quirk gives an additional meaning to the reserved bit. It's obviously an easy change but I'd feel a lot more comfortable if someone can point us to a document that states that the SD/SDIO low voltage range is defined to match the MMC one. Maybe one of the NDA docs actually states this. The non-simplified documents don't say anything on this. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ 'member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom' -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Mon, Jul 27, 2009 at 01:09:47PM +0100, David Vrabel wrote: Philip Langdale wrote: Both the (Simplified) SD and SDIO specifications do not formally define the 'low voltage' range in the way the MMC spec does. ie: You won't find anything in the SD specs that even tell you what the range is - it just says that it exists. Standard SD/SDIO cards only support 2.7-3.6V. 1.8V operation is added in SD physical spec 3.00 and is part of any of the UHS-1 modes (SDR12-SDR104 and DDR50). It has a different timings and requires a different (3.00 compliant) host controller. Is the 3.00 spec publicly available? -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Mon, 27 Jul 2009 22:40:01 +0100 Matt Fleming m...@console-pimps.org wrote: On Mon, Jul 27, 2009 at 01:09:47PM +0100, David Vrabel wrote: Philip Langdale wrote: Both the (Simplified) SD and SDIO specifications do not formally define the 'low voltage' range in the way the MMC spec does. ie: You won't find anything in the SD specs that even tell you what the range is - it just says that it exists. Standard SD/SDIO cards only support 2.7-3.6V. 1.8V operation is added in SD physical spec 3.00 and is part of any of the UHS-1 modes (SDR12-SDR104 and DDR50). It has a different timings and requires a different (3.00 compliant) host controller. Is the 3.00 spec publicly available? Indeed! If the 1.8V operations have conformance requirements beyond those of MMCplus/MMCmobile, then we can't just remove the current test as proposed. I've been checking the sdcard.org site periodically for new specs and haven't seen anything yet. --phil -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Thu, 23 Jul 2009 14:52:09 +0100
Matt Fleming m...@console-pimps.org wrote:
On Thu, Jul 23, 2009 at 09:50:03AM +0300, Ohad Ben-Cohen wrote:
Hi Andrew,
On Thu, Jul 23, 2009 at 9:22 AM, Andrew Mortona...@linux-foundation.org
wrote:
I actually already have a little pile of MMC things queued:
Please also consider queuing up the attached patch as well.
The patch is removing the current SDIO cards 1.8V limit, which is
needed for embedded
SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers like we
have on the ZOOM2 boards for example).
Thank you,
Ohad.
From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@bencohen.org
Date: Wed, 15 Jul 2009 09:21:41 +0300
Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
This is needed for 1.8V embedded SDIO devices and supporting host
controllers
(e.g. TI 127x and ZOOM2 boards)
Signed-off-by: Ohad Ben-Cohen o...@bencohen.org
---
drivers/mmc/core/sdio.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index fb99ccf..6f221dc 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
ocr = ~0x7F;
}
- if (ocr MMC_VDD_165_195) {
- printk(KERN_WARNING %s: SDIO card claims to support the
- incompletely defined 'low voltage range'. This
- will be ignored.\n, mmc_hostname(host));
- ocr = ~MMC_VDD_165_195;
- }
-
host-ocr = mmc_select_voltage(host, ocr);
/*
--
1.5.4.3
Looks OK to me, I'm unaware of a reason to not allow a card to use
MMC_VDD_165_195 if that's what it wants.
Yes, that code was there from day #1, via Pierre's original commit. There
is no indication in either the code comments or the changelog why it was done
this way.
Other ways of finding out why this code is there include:
a) search the mailing list for review discussion. I can't find it
in my lkml archive.
b) ask Pierre :)
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming m...@console-pimps.org wrote: On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote: Andrew Morton wrote: Until and unless someone else steps up I can act as maintainer of last resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi, gpio, i2o and about 1000 other identifiable subsystems. If no-one else is helping out, Im happy to also be CC'd on MMC patches. Ditto. Thanks, guys. I actually already have a little pile of MMC things queued: http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch I guess we own them now ;) -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Wed, Jul 22, 2009 at 11:22:59PM -0700, Andrew Morton wrote: On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming m...@console-pimps.org wrote: On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote: Andrew Morton wrote: Until and unless someone else steps up I can act as maintainer of last resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi, gpio, i2o and about 1000 other identifiable subsystems. If no-one else is helping out, Im happy to also be CC'd on MMC patches. Ditto. Thanks, guys. I actually already have a little pile of MMC things queued: http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch I guess we own them now ;) While you're in MMC collection mode: http://lkml.org/lkml/2009/7/17/75 wants to be queued, too. Presumably Ian will get to it at some point, though. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
Hi Andrew,
On Thu, Jul 23, 2009 at 9:22 AM, Andrew Mortona...@linux-foundation.org wrote:
I actually already have a little pile of MMC things queued:
Please also consider queuing up the attached patch as well.
The patch is removing the current SDIO cards 1.8V limit, which is
needed for embedded
SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers like we
have on the ZOOM2 boards for example).
Thank you,
Ohad.
From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@bencohen.org
Date: Wed, 15 Jul 2009 09:21:41 +0300
Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
This is needed for 1.8V embedded SDIO devices and supporting host controllers
(e.g. TI 127x and ZOOM2 boards)
Signed-off-by: Ohad Ben-Cohen o...@bencohen.org
---
drivers/mmc/core/sdio.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index fb99ccf..6f221dc 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
ocr = ~0x7F;
}
- if (ocr MMC_VDD_165_195) {
- printk(KERN_WARNING %s: SDIO card claims to support the
- incompletely defined 'low voltage range'. This
- will be ignored.\n, mmc_hostname(host));
- ocr = ~MMC_VDD_165_195;
- }
-
host-ocr = mmc_select_voltage(host, ocr);
/*
--
1.5.4.3
Re: New MMC maintainer needed
Andrew Morton wrote: On Thu, 23 Jul 2009 06:54:47 +0100 Matt Fleming m...@console-pimps.org wrote: On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote: Andrew Morton wrote: Until and unless someone else steps up I can act as maintainer of last resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi, gpio, i2o and about 1000 other identifiable subsystems. If no-one else is helping out, Im happy to also be CC'd on MMC patches. Ditto. Thanks, guys. I actually already have a little pile of MMC things queued: http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch I guess we own them now ;) There are also 32 patches starting here: http://marc.info/?l=linux-kernelm=124722949501844w=2 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
Hi Andrew, On Wed, 22 Jul 2009 23:22:59 -0700 Andrew Morton a...@linux-foundation.org wrote: I actually already have a little pile of MMC things queued: http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch I guess we own them now ;) So how about, as an experiment, you put all those (at least those that are stable) into a git tree (or quilt series) based on Linus' tree and I could replace the current linux-next mmc tree (which is empty) with that. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgplLrRKRrnqA.pgp Description: PGP signature
Re: New MMC maintainer needed
On Thu, 23 Jul 2009 17:25:59 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: Hi Andrew, On Wed, 22 Jul 2009 23:22:59 -0700 Andrew Morton a...@linux-foundation.org wrote: I actually already have a little pile of MMC things queued: http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-in-mmc_power_up-use-previously-selected-ocr-if-available.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/omap-hsmmc-do-not-enable-buffer-ready-interrupt-if-using-dma.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/mmc-msm_sdccc-driver-for-htc-dream.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-convert-printkkern_level-to-pr_level.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-stylistic-cleaning.patch http://userweb.kernel.org/~akpm/mmotm/broken-out/msm_sdccc-move-overly-indented-code-to-separate-function.patch I guess we own them now ;) So how about, as an experiment, you put all those (at least those that are stable) into a git tree (or quilt series) based on Linus' tree and I could replace the current linux-next mmc tree (which is empty) with that. I haven't worked out how to do that yet :( (Well, I have, but it's all complex). It gets easy if I remove linux-next.patch from -mm. Maybe I'll do that. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
Hi Andrew, On Thu, 23 Jul 2009 00:32:28 -0700 Andrew Morton a...@linux-foundation.org wrote: It gets easy if I remove linux-next.patch from -mm. Maybe I'll do that. At that point we could add the stable part of -mm to linux-next :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpDugFOt7QgI.pgp Description: PGP signature
Re: New MMC maintainer needed
2009/7/23, Matt Fleming m...@console-pimps.org: On Thu, Jul 23, 2009 at 01:08:08AM +0100, Ian Molton wrote: Andrew Morton wrote: Until and unless someone else steps up I can act as maintainer of last resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi, gpio, i2o and about 1000 other identifiable subsystems. If no-one else is helping out, Im happy to also be CC'd on MMC patches. I am new in maintaining a kernel driver into community but I would help. -- Roberto A. Foglietta, Linux Embedded Consultant mobile: (+39) 349.33.30.697 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Thu, Jul 23, 2009 at 09:50:03AM +0300, Ohad Ben-Cohen wrote:
Hi Andrew,
On Thu, Jul 23, 2009 at 9:22 AM, Andrew Mortona...@linux-foundation.org
wrote:
I actually already have a little pile of MMC things queued:
Please also consider queuing up the attached patch as well.
The patch is removing the current SDIO cards 1.8V limit, which is
needed for embedded
SDIO devices like TI 127x WLAN devices (with 1.8V MMC controllers like we
have on the ZOOM2 boards for example).
Thank you,
Ohad.
From f9ba45b537dd12fc09443ee29c48860665f8ac82 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen o...@bencohen.org
Date: Wed, 15 Jul 2009 09:21:41 +0300
Subject: [PATCH] sdio: do not ignore MMC_VDD_165_195
This is needed for 1.8V embedded SDIO devices and supporting host controllers
(e.g. TI 127x and ZOOM2 boards)
Signed-off-by: Ohad Ben-Cohen o...@bencohen.org
---
drivers/mmc/core/sdio.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index fb99ccf..6f221dc 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -275,13 +275,6 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
ocr = ~0x7F;
}
- if (ocr MMC_VDD_165_195) {
- printk(KERN_WARNING %s: SDIO card claims to support the
-incompletely defined 'low voltage range'. This
-will be ignored.\n, mmc_hostname(host));
- ocr = ~MMC_VDD_165_195;
- }
-
host-ocr = mmc_select_voltage(host, ocr);
/*
--
1.5.4.3
Looks OK to me, I'm unaware of a reason to not allow a card to use
MMC_VDD_165_195 if that's what it wants.
Acked-by: Matt Fleming m...@console-pimps.org
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
Stephen Rothwell s...@canb.auug.org.au writes: Hi Andrew, On Thu, 23 Jul 2009 00:32:28 -0700 Andrew Morton a...@linux-foundation.org wrote: It gets easy if I remove linux-next.patch from -mm. Maybe I'll do that. At that point we could add the stable part of -mm to linux-next :-) I think that would be a great idea. It always bugged me that if Andrew pulls something in it's not automatically tested in -next. -Andi -- a...@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
On Tue, 14 Jul 2009 15:36:01 +0200 Pierre Ossman pie...@ossman.eu wrote: I'm afraid the time has come for me to step down as maintainer for the MMC/SD/SDIO subsystem and for someone else to take over the rudder. It is no secret that I haven't been able to give the maintainer role the resources it required, and as a result it has gone from being a fun hobby to a burdensome chore. I was hoping it was a temporary slump, but this has been the norm for over a year now, so it's time for me to throw in the towel. I don't have any clear nominees for a replacement, but if you feel that you are in a position to take over the maintainer role then please raise your hand. I only have a few patches in my queue right now and I can push those off to Linus before I quit. There are however a lot of unhandled messages that need attention. I can provide a list once a successor has been named. I realise that you have put a lot of time and effort into the patches you send me and I am truly sorry that I haven't been able to handle them better. Hopefully me stepping down means that we get someone who can actually take care of everything in a timely manner. I haven't decided what to do with the sdhci maintainership yet. Right now I only know I need a break and freeing myself from the MMC maintainer role is the first step. Hopefully I can return as a developer in the future. Thanks, Pierre. Until and unless someone else steps up I can act as maintainer of last resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi, gpio, i2o and about 1000 other identifiable subsystems. Fortunately, MMC doesn't appear to have its own mailing list so I'll actually get to see the patches. I do monitor a couple of subsystem-specific lists (fbdev, hwmon) but the delays can be awful - a month or two. When it comes to subsystems about which I have little knowledge I tend to work as follows: - scan the patch to see if anything stands out to my inexperienced eye - if possible, comment on it to make a bit of noise and to let the submitter and others know that a) someone has looked at it and b) there's a chance that it'll be merged. - try to identify some people who might have an interest in the patch and/or who might have related experience which would help them review this one effectively. So if someone finds themselves cc'ed on an MMC email from myself, please do take a bit of time to pass an eye across it, and let us know that you have done so - it really helps. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New MMC maintainer needed
Andrew Morton wrote: Until and unless someone else steps up I can act as maintainer of last resort for MMC. As I'm presently doing for fbdev, hwmon, rtc, spi, gpio, i2o and about 1000 other identifiable subsystems. If no-one else is helping out, Im happy to also be CC'd on MMC patches. I've been out of the loop, as I mentioned, but I dont mind helping out. I'm currently helping someone bring a PCI based TMIO type device online via email. Pierre - do you have a bunch of MMC spec-type docs around? I've lost all but the few sparse datasheets for TMIO that I had, so some docs covering protocol / commands would be useful. Any references / downloads that you know of? -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
New MMC maintainer needed
I'm afraid the time has come for me to step down as maintainer for the MMC/SD/SDIO subsystem and for someone else to take over the rudder. It is no secret that I haven't been able to give the maintainer role the resources it required, and as a result it has gone from being a fun hobby to a burdensome chore. I was hoping it was a temporary slump, but this has been the norm for over a year now, so it's time for me to throw in the towel. I don't have any clear nominees for a replacement, but if you feel that you are in a position to take over the maintainer role then please raise your hand. I only have a few patches in my queue right now and I can push those off to Linus before I quit. There are however a lot of unhandled messages that need attention. I can provide a list once a successor has been named. I realise that you have put a lot of time and effort into the patches you send me and I am truly sorry that I haven't been able to handle them better. Hopefully me stepping down means that we get someone who can actually take care of everything in a timely manner. I haven't decided what to do with the sdhci maintainership yet. Right now I only know I need a break and freeing myself from the MMC maintainer role is the first step. Hopefully I can return as a developer in the future. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature
Re: New MMC maintainer needed
Pierre Ossman wrote: I'm afraid the time has come for me to step down as maintainer for the MMC/SD/SDIO subsystem and for someone else to take over the rudder. Thank you for your time and effort on this subsystem. I havent done anything 'deep' in MMC for some time (since my initial SD mem card support), so I dont feel qualified to step up. Hopefully we'll find someone suitable. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
