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
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
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: [PATCH] sdio: add CD disable support
On Thu, Jul 30, 2009 at 02:54:08PM +0300, Ohad Ben-Cohen wrote: From: Ohad Ben-Cohen o...@wizery.com To save power, the pull-up resistor on CD/DAT[3] (pin 1) of the card can be disconnected. This is desired, e.g., with embedded SDIO devices which do not rely on this pin for card detection. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- drivers/mmc/core/sdio.c | 32 include/linux/mmc/card.h |3 ++- 2 files changed, 34 insertions(+), 1 deletions(-) Do you have a follow-up patch to make use of this new functionality? I can't see anywhere where disable_cd is set. -- 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 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
