Hi! 2012/11/18 Daniel Drake <dsd@xxxxxxxxxx>: > On Fri, Nov 2, 2012 at 8:35 AM, Johan Rudholm <jrudholm@xxxxxxxxx> wrote: >> Good question. I’d guess that mmc_power_off/up does not work as >> expected here, that the card is not at all power cycled. > > Before going further on the "find a way to quirk it" route, there is > something else we could look into. > > According to our hardware engineers, the external SD card power has > been "always-on" until now. It is actually controlled by our embedded > controller, separate from the CPU. > > In a test firmware, I can now control the SD card power via our "OLPC > EC" interface, I call into that from mmc_power_up and mmc_power_down. > And, with your hacky patch to make the voltage switch failure > detection work, this fixes it: it tries 10 times at 1.8v then falls > back to 3.3 successfully. No more problems with the power cycle. Ah, great! Then we know what the issue was at least. Then I guess that this code did not work with your driver: host->ios.clock = 0; mmc_set_ios(host); so with my original patch ([RFC/PATCH,v2] mmc: core: Fixup signal voltage switch), the clock was actually never stopped during the signal voltage switch? I guess this will need some further investigation also. > So we have the option of fixing it that way: if we can fix the voltage > switch failure detection, we could implement a custom vmmc regulator > driver that uses our EC interface to enable and disable the SD power > appropriately, solving our ability to power cycle. Being able to power cycle the SD-card might also come in handy in other situations, perhaps if a poor SD-card misbehaves in some way? SD-cards have no "reset cord" like eMMCs, so being able to power cycle the card feels like a good thing. > On the other hand, we may have a good basis to add a quirk, triggered > by the device tree, for when the hardware physically does not have > 1.8v capabilities. This also seems proper, if we know we can't get 1.8V, then we shouldn't even try for it. In this way the detection will also be faster (no 10 retries). > I'm also curious if there is a 3rd option. It seems like in the case > of our SoC, the SoC design mandates that the SD card power is separate > from the SDHCI interface - requiring either a GPIO or some other > mechanism (e.g. OLPC EC) to be able to control it. > > I'm wondering if this is the same for all sdhci-pxa devices. And the > same for all sdhci devices? Maybe the SDHCI specs would help here, but > I guess they aren't public. > > If this is the case, the driver could have another heuristic: if there > is no vmmc regulator, there is no way of cutting the card power, > therefore we could avoid even trying 1.8v on the basis that we know we > can't recover if things go wrong. So the driver could for instance drop the MMC_CAP_UHS_DDR50 cap if there is no way to power cycle the card? I think that sounds reasonable and according to spec, although also a little bit hard since there probably are cards out there that never require a power cycle to perform a proper voltage switch? Kind regards, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
