On Fri, Nov 2, 2012 at 8:35 AM, Johan Rudholm <jrudholm@xxxxxxxxx> wrote: > An initial question, would it be possible to solve this by disabling > the UHS support in the host cap, or through a quirk? Maybe this kind > of solution is not applicable in this scenario? I wonder this because > I guess it will be very hard to know how a card will react if we first > tell it that we're going to switch voltages and then don't, since this > is out of spec. That would definitely be possible. I'm not convinced this is outside the spec - the spec talks heavily about power cycling, which you would think would handle such cases (i.e. a full state reset). However, I think I have generated enough evidence in my last mail to show that we are not able to fully power cycle, giving further support for some kind of quirk. > 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. But it seems > that the power cycle code in sdhci_do_start_signal_voltage_switch > works? What if we export a couple of debug functions from sdhci.c > which allow us to power cycle and control the clock just like sdhci > does, and call these functions from core.c and sd.c? If this works > (and the failure is detected properly by the core layer, and 10 > retries are made etc), then we know that the problems most likely > depend on how mmc_set_ios and mmc_power_off/up work with sdhci. I've > attached a patch suggesting this, if you'd like to give it a try > (warning: the patch has not been tested). The patch does not do > anything about pm_runtime, but perhaps we don't need to worry about > this here. Your patch fixes the detection that the voltage switch has failed. It doesn't fix the reset though - it still returns the -110 error after trying to power cycle. I mentioned in an earlier mail that we had this working in 3.0. I went back to that configuration to investigate. Actually, it is maybe only reliable 50% of the time - the other 50% we get the same error. When it does work, here's what happens: - mmc_rescan_try_freq is called to try the 400khz frequency - in mmc_sd_get_cid(), rocr has value c1ff8000, so we try the 1.8 switch, this fails - we go back to 3.3v, then we receive the -110 timeout error immediately after - mmc_rescan_try_freq is called to try the 300khz frequency - the card is now alive for some reason - in mmc_sd_get_cid(), rocr has value c0ff8000, so we stick at 3.3V Rather odd. It seems that 3.0 is more successful at power cycling the card than 3.5, but it is far from reliable. It also appears that the card I have here might have some logic to realise that 1.8V failed so then it stops advertising the capability? Anyway, with all the unreliability, unknowns, and power cycle difficulty, I guess we should go for the quirk approach. Do you have any suggestions for how this should be implemented? Should I go for a new SDHCI quirk triggered by a new "sdhci,disable-1-8v" device tree property? Thanks Daniel -- 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
