sdio: add MMC_CAP_VDD_165_195 host capability

From: Ohad Ben-Cohen <[email protected]>

To allow the usage of MMC_VDD_165_195, host capability MMC_CAP_VDD_165_195 is introduced. This is necessary because MMC_VDD_165_195 is currently reserved/undefined.

That's a fair amount of work so perhaps in the interim something like this:

drivers/mmc/core/sdio.c +2 -0

@@ -494,6 +494,9 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
                ocr &= ~0x7F;
        }
 
+       if (ocr & MMC_VDD_165_195)
+               printk(KERN_WARNING "%s: warning: card claims non-standard 1.65-1.95

V support"
+
       host->ocr = mmc_select_voltage(host, ocr);

       /*

Quoted 5 lines · Ohad Ben-Cohen

From: Ohad Ben-Cohen <[email protected]>

To allow the usage of MMC_VDD_165_195, host capability MMC_CAP_VDD_165_195 is introduced. This is necessary because MMC_VDD_165_195 is currently reserved/undefined.

The host already reports what voltages it supports (in mmc_host::ocr_avail) so a seperate MMC_CAP_* isn't needed.

This interpretation of the reserved bits in the OCR should only done for certain cards where the bits actually do mean 1.8 V operation (with v2.0 signalling) is possible.

That's a fair amount of work so perhaps in the interim something like this:

drivers/mmc/core/sdio.c +2 -0

@@ -494,6 +494,9 @@ int mmc_attach_sdio(struct mmc_host *host, u32
 ocr) ocr &= ~0x7F;
 	}
 
+	if (ocr & MMC_VDD_165_195)
+		printk(KERN_WARNING "%s: warning: card claims

non-standard 1.65-1.95 V support"

drivers/mmc/core/sdio.c +1 -0

+
 	host->ocr = mmc_select_voltage(host, ocr);
 
 	/*

And revisit this if these bits either: a) gain a (different) standard meaning; or b) some other card uses these bits in a different non-standard way. Neither seems likely.

Hi David,

Ok, that sounds reasonable, but my concern is a controller that publishes support for MMC_VDD_165_195 for mmc cards but doesn't claim support for SDIO cards - particularly considering the signalling implications you mentioned. Now, maybe you don't see this happening in the wild, but it seems to me that it has to be possible. It seems that to guard against this, you'd need a host cap that says "165_195 for SD" and if it's not present, mask it out of the OCR when dealing with SD/IO cards.

Am I being too paranoid?

Quoted 12 lines · On Mon, 28 Sep 2009 19:25:48 -0700 Philip Langdale <[email protected]> wrote:

Hi David,

Ok, that sounds reasonable, but my concern is a controller that publishes support for MMC_VDD_165_195 for mmc cards but doesn't claim support for SDIO cards - particularly considering the signalling implications you mentioned. Now, maybe you don't see this happening in the wild, but it seems to me that it has to be possible. It seems that to guard against this, you'd need a host cap that says "165_195 for SD" and if it's not present, mask it out of the OCR when dealing with SD/IO cards.

Quoted 2 lines

Am I being too paranoid?

There is no way the vendor of the SD controller can know what this bit means to the vendor of the SD/SDIO card as it is undefined. I'm afraid I see no safe way of supporting this bit. The only thing we can do is interpret it as being the same as the MMC bit, but then only with an opt-in configuration as we might be killing hardware with this.

My understanding from the previous discussion was that SD 3.0 (and presumably
a matching SDHCI 3.0) fully define the low voltage range. As such, a controller
that is documented to conform to this spec, or is otherwise documented to implement the functionality, can be safely allowed to run SD cards that also
claim to support the bit.

Yes, there is a danger of pre 3.0 cards claiming to suport the low voltage range,
but I think there's a credible chance that no such cards actually exist, and if
they do, I think they're obscure enough to ignore - if they were a problem, the
SD association would have had to abandon using the same bit as MMC uses.

I must have missed that part of discussion. If the voltage fully overlaps with the MMC definition, then I don't see the controllers having to be designed explicitly for SD 3.0. If not, then we probably need a new voltage bit for the hosts. In that case separating supporting from non-supporting should sort itself out easily.

Btw, you really need to whip some sense into the line handling of your email client. :)

Quoted 5 lines · On Tue, 29 Sep 2009 23:37:32 +0200 Pierre Ossman <[email protected]> wrote:

I must have missed that part of discussion. If the voltage fully overlaps with the MMC definition, then I don't see the controllers having to be designed explicitly for SD 3.0. If not, then we probably need a new voltage bit for the hosts. In that case separating supporting from non-supporting should sort itself out easily.

The reason I think we need is a host cap is that low voltage operations apparently implies different signal timings. This is second hand from David as there are no public specs for 3.0 available yet. So, the failure case is a controller that publishes support for low voltage, but only expects MMC cards to use it.

In practice, I expect that the timings are close enough that this will work anyway, but I think the situation is analogous to HS-MMC vs HS-SD. There the timings are slightly different and you felt it was enough to justify a separate host cap for each one.

In fact, thinking about it in those terms, it suggests we need to retroactively introduce a reduced-voltage MMC host flag too, just in case SDHCI 3.0 controllers barf on those cards...

Quoted 6 lines

In practice, I expect that the timings are close enough that this will work anyway, but I think the situation is analogous to HS-MMC vs HS-SD. There the timings are slightly different and you felt it was enough to justify a separate host cap for each one.

It's difficult to say without seeing the spec. But if things are not backwards compatible, then we should probably add either a new timing mode, or a new bus mode (where we have open drain and push pull today).

Quoted 4 lines

In fact, thinking about it in those terms, it suggests we need to retroactively introduce a reduced-voltage MMC host flag too, just in case SDHCI 3.0 controllers barf on those cards...

Maybe. Again, it's difficult to say without seeing the specifics of the new specification.

Quoted 10 lines · On Thu, 8 Oct 2009 20:38:26 +0200 Pierre Ossman <[email protected]> wrote:

Quoted 5 lines

In practice, I expect that the timings are close enough that this will work anyway, but I think the situation is analogous to HS-MMC vs HS-SD. There the timings are slightly different and you felt it was enough to justify a separate host cap for each one.

It's difficult to say without seeing the spec. But if things are not backwards compatible, then we should probably add either a new timing mode, or a new bus mode (where we have open drain and push pull today).

Quoted 6 lines

Quoted 4 lines

In fact, thinking about it in those terms, it suggests we need to retroactively introduce a reduced-voltage MMC host flag too, just in case SDHCI 3.0 controllers barf on those cards...

Maybe. Again, it's difficult to say without seeing the specifics of the new specification.

Make sense. So, I guess the question is do we assume the best case (in which case there is no additional work to do - the code that is now in allows low voltage SDIO cards to try and run) or the worst case and add pre-emptive mode flags?

David, you've actually seen the new spec right? What's your opinion?

In the 3.00 spec, OCR bit 24 is S18R (Signalling 1.8V request). This is outside of the VDD region (bits 0:23). So I think we can support non standard DS/HS (Default Speed/High Speed) cards that report 1.8V operation (in the VDD region) and new UHS-I (Ultra High Speed phase I) cards without any confusion.

On a UHS-I capable controller, the software would send ACMD41 with S18R set and see if the card responses with it set. If so, it tells the card to switch to 1.8V signalling (CMD11) and tells the controller to switch to 1.8V signalling and SDR12 mode. The controller still supplies 3.3V to the card even after the switch. Later on the host software will query the card to find out what UHS-I modes are supported and switch card and controller to a faster mode (if possible).

Interesting. But that means that Ohad's patch doesn't make much sense; his uses the MMC low voltage OCR bit in an SDIO context. So either, the patch is wrong, or he's dealing with out-of-spec hardware.

Quoted 3 lines · Philip Langdale

Interesting. But that means that Ohad's patch doesn't make much sense; his uses the MMC low voltage OCR bit in an SDIO context. So either, the patch is wrong, or he's dealing with out-of-spec hardware.

Yes, the hardware is out-of-spec. It uses the undefined low voltage OCR bit to achieve 1.8V SDIO voltage. By removing the MMC_VDD_165_195 restriction, commit 27cce39f555def6f5ebe7f03d69ccc44ab25f0b2 makes it possible for the hardware to work with unpatched kernels.

Philip, David, Pierre - would you like to remove the MMC_VDD_165_195 restriction differently ? maybe to revive the MMC_CAP_VDD_165_195 host capability patch in some way (see
http://www.mail-archive.com/[email protected]/msg00386.html) ?

Quoted 9 lines · On Wed, 14 Oct 2009 09:56:28 +0200 Ohad Ben-Cohen <[email protected]> wrote:

Quoted 3 lines · Philip Langdale

Interesting. But that means that Ohad's patch doesn't make much sense; his uses the MMC low voltage OCR bit in an SDIO context. So either, the patch is wrong, or he's dealing with out-of-spec hardware.

Yes, the hardware is out-of-spec. It uses the undefined low voltage OCR bit to achieve 1.8V SDIO voltage. By removing the MMC_VDD_165_195 restriction, commit 27cce39f555def6f5ebe7f03d69ccc44ab25f0b2 makes it possible for the hardware to work with unpatched kernels.

Quoted 5 lines

Philip, David, Pierre - would you like to remove the MMC_VDD_165_195 restriction differently ? maybe to revive the MMC_CAP_VDD_165_195 host capability patch in some way (see
http://www.mail-archive.com/[email protected]/msg00386.html) ?

Since this is out-of-spec and therefore possibly dangerous behaviour, I'd like it to be opt-in for the user. And since it's so early in the init process, we can't automate it based on card id.

It can be done per-card, the switch to the lower voltage just needs to be deferred. Initially set the voltage to a standard one that's supported by the card and host. After the card is fully initialized and enumerated, have a hook for per-card fixups. For the particular non-standard card in question, this would then reduce the voltage to 1.8V.