[PATCH 21/38] mmc: sdhci: hack up driver to make it more compliant with UHS-1

[Russell King - ARM Linux]

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.