On Fri, Apr 25, 2014 at 02:15:30PM +0100, Russell King - ARM Linux wrote: > On Fri, Apr 25, 2014 at 03:08:49PM +0200, Markus Pargmann wrote: > > I just tried the different parts of the patch. Without the following > > change, emmc works: > > > > --- a/drivers/mmc/host/sdhci.c > > +++ b/drivers/mmc/host/sdhci.c > > @@ -1507,12 +1507,6 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios) > > host->ops->set_clock(host, host->clock); > > } > > > > - > > - /* Reset SD Clock Enable */ > > - clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL); > > - clk &= ~SDHCI_CLOCK_CARD_EN; > > - sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL); > > - > > So the bit which stops us violating the SD spec stops eMMC from working... > that's... just great. > > Okay, I'll look deeper at this and see what can be done, but I suspect it > will turn out to require more patches and be more invasive. Well, I've given up trying to work out how to clean that mess up - sdhci will attempt to do all the high speed switching bollocks every time a set_ios call is made, turning the clock on and off multiple times in the process. I've since replaced it with a patch covering just the last hunk of this patch and killed the other two changes there (and rewritten the description.) I'm afraid that it looks like we're going to be stuck with turning the clock on and off multiple times during the transition to 1.8V signalling, which is technically against the SD spec. The spec'd procedure is: - send command - check card reports busy - clock off - switch to 1.8v signalling - wait 5ms - clock on - wait 1ms - check card reports non-busy whereas what we end up doing is: - send command - check card reports busy - clock off - switch to 1.8v signalling, waiting 5 to 5.5ms - wait 5ms - clock on - clock off - tweak other settings - clock on again - wait 1ms - check card reports non-busy -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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
