XO-1.75/XO4 don't support 1.8 volt SD cards

[jvonau]

filing as per http://lists.laptop.org/pipermail/devel/2012-October/036017.html

[cjb]

Already sent a patch to devel@, waiting for testing.

[dsd]

The patch doesn't make any difference - it for eMMC.

The problem here is that the kernel tries to go back to 3.3V after detecting the failure, but fails.

An upstream RFC patch fixes this for XO-4 (3.5) but not for XO-1.75 (3.0). The failure was obvious, so I fixed it with a sdhci patch. That fixed XO-1.75 and broke XO-4. Sigh.

[dsd]

sdhci fix (3.5)

[dsd]

upstream rfc (3.5)

[dsd]

upstream rfc (3.0)

[dsd]

sdhci fix (3.0)

[dsd]

http://marc.info/?l=linux-mmc&m=135103249232651&w=3

All work in progress posted here.

[dsd]

The conclusions from the upstream discussion so far is that we haven't found a reliable way of power-cycling the SD card on XO-1.75. So we were tipping towards adding a quirk.

Then cjb pointed out this code in the xo-1.75 board file:

	gpio_request(35, "ext_sd power");
	gpio_direction_output(35, 1);
	pxa_register_device(&mmp2_device_sdh0, &olpc_xo_1_75_ext_sd, sizeof(olpc_xo_1_75_ext_sd));

So I tried implementing a vmmc regulator on gpio 35, spent more time fiddling, and didn't get anywhere. In fact, it was as if playing with the gpio has no influence at all.

Sure enough, going back to arm-3.0 and modifying the above board file, setting the value to 0 instead of 1, or removing the gpio assignment altogether, doesn't stop the external SD card from working (testing with a normal 3.3V card as a baseline here).

When people are back from XO-4 bringup we should do a bit more investigation here; is GPIO 35 really hooked up to external SD card power? Then we can decide where to go.

[pgf]

i'm afraid the board file is wrong. gpio 35 is hooked up to a test point. the socket is hardwired to 3.3V.

[wad]

Why doesn't someone ask me, if they don't know ?

On XO-1.75: Only +3.3V operation of the SD interfaces is supported, but they definitely are NOT hardwired. Power is switched.

The external SD slot power switch is controlled by EN_SD2_PWR#.

Both the internal eMMC and the internal SD slot share an MMC interface. Only one can be used at a time, selected by a jumper when the internal SD slot is installed. As such, they share a power switch, controlled by EN_SD1_PWR#.

However, as with the XO-1.5, these power control lines do NOT go to a GPIO accessible by the main processor. They are instead connected to the embedded controller. They can be turned on and off by sending commands to the EC. I believe the EC firmware already implements these commands, but Linux was not wired up properly to use them.

This method of control was done because we encountered some SD cards which violated the SD spec and lost data if they were turned off immediately after a data transfer. Having the EC control their power allows it to maintain power to the SD card for a second after the main processor is turned off, fixing our random data loss problems. I believe this breaks the simplistic DT model of how things are turned on/off...

[cjb]

Thanks, Wad. The bug title's confusing: all we're trying to do at the moment is control the 3.3V supply to the external SD so that we can reset it correctly.

The EC command to do that isn't documented in http://wiki.laptop.org/go/XO_1.75_HOST_to_EC_Protocol.

Paul, please could you tell us which EC command to use to control EN_SD2_PWR#?

Dan, I guess we'll need a new platform hook to perform the reset in MMC.

[rsmith]

The EC command to do that isn't documented in http://wiki.laptop.org/go/XO_1.75_HOST_to_EC_Protocol. Paul, please could you tell us which EC command to use to control EN_SD2_PWR#?

-ENOTIMPLEMENTED

In the 1.5 to 1.75 port I guess we never bothered to implement those commands. EC turns on the rails at power up and leaves them up until power down.

Give me an hour or so and I'll re-add the command. It will be EC cmd 0x6f with and arg of 1 or 0 to power up/down.

[pgf]

dsd -- now you should know never to pay any attention to me when i make pronouncements about hardware. at best i'm only half right.

[rsmith]

Give me an hour or so and I'll re-add the command. It will be EC cmd 0x6f with and arg of 1 or 0 to power up/down.

Test EC code attached to this ticket.

[rsmith]

Replying to rsmith:

Give me an hour or so and I'll re-add the command. It will be EC cmd 0x6f with and arg of 1 or 0 to power up/down.

Test EC code attached to this ticket.

To update from a USB flash stick.

ok flash-ec u:\ec_sd2.bin

[wad]

pgf,

You are too hard on yourself. You were completely correct, to a first approximation. Until Richard restored that EC command, the power was hardwired on.

[dsd]

Thanks for all the input. Another question I have (happy to wait til a later date, don't want to further distract from bringup): is the software in general able to perform a complete power cycle of an external SD card, when using this SoC, using only the sdhci interface (no gpios, etc)? Both in our case, and in the normal case, if there is a difference.

What I'm basically wondering is if the driver can safely make the assumption that power cycling a card is impossible unless it has a GPIO or platform reset method.

In other words, is the SD card power supply routed through the SoC where it could potentially have an on/off switch applied at the SDHCI interface level, or does the SoC design effectively mandate that the power supply is something separate?

Can the same response be applied to other sdhci-based systems or is the answer always going to be specific to the hardware implementation?

[dsd]

The new EC code works great with cmd 0x6f. Thanks. Now I'll work with upstream to see if that is the direction we want to go, with the other options considered too.

[wad]

It varies whether the SDHCI controller brings the power control pins from the SDHCI interface out for use externally.

On the Via VX850 used in the XO-1.5, the SDHCI power control (both on/off and volt. select) was brought out to pins --- but the circuitry was flawed and they didn't hold their value across suspend/resume. We fixed this with external circuitry but other designers might have used GPIOs instead.

Neither of the Marvell SoCs brought the SDHCI power control signals out to pins, forcing the use of GPIOs instead. Marvell's reference designs tend to either wire the SD cards to +3.3V, providing no control over card power, or wire it to their PMIC which would require an I2C command to turn it on/off.

[dsd]

Thanks for the explanation - that clears it up.

For the upstream XO-1.75 fix, we seem to have settled on simply providing a flag in the device tree that indicates that the controller has no 1.8v supply available. So there is no immediate need for the new EC command, although it would be useful to have around. It was also valuable to be able to verify what we were suspecting.

The upstream patches have been tentatively acked by cjb:

• sdhci: add quirk for lack of 1.8v support
• mmc: add no-1-8-v device tree flag

With the upstream path seemingly complete, I've added a hack to arm-3.0-wip to disable 1.8v and this makes George Hunt's UHS-I card work (3453366).

[dsd]

Test in 13.1.0 build 16.

[dsd]

Tested in 13.1.0 build 30 on XO-1.75 and XO-4, this is working correctly.