Re: mmc: sdio: runtime PM and 8686 problems

["Joe Woodward" <jw@terrafix.co.uk>]

Right, a bit more information.

First I tried just adding delays as suggested:

# Delays in core.c:mmc_power_up() increased to 1000.
# Delay in core.c:mmc_power_off() increased to 1000.
# sdio.c:mmc_sdio_power_restore() modified to add delays.
...
	msleep(500);
	sdio_reset(host);
	msleep(500);
	mmc_go_idle(host);
	msleep(500);
	mmc_send_if_cond(host, host->ocr_avail);
	msleep(500);

	ret = mmc_send_io_op_cond(host, 0, &ocr);
...

And there was no improvement (it slowed down the probe a lot!), so I tried again with much longer delays (3 seconds rather than 500ms) and still no change.

So I added control of the nRESET line in sdio.c:mmc_sdio_power_restore().
...
	gpio_set_value(16, 0);  /* GPIO16 is the nRESET line */
	msleep(10);
	gpio_set_value(16, 1);
	msleep(100);

	msleep(3000);
	sdio_reset(host);
	msleep(3000);
	mmc_go_idle(host);
	msleep(3000);
	mmc_send_if_cond(host, host->ocr_avail);
	msleep(3000);
...

and things sprung in to life, well sometimes! Sadly this only worked intermittently, and only with longer delays.

I guess this may not be a suprise, as I'm force resetting the card but not doing a full "probe".

I'm afraid I can't probe the nRESET line as the SD8686 is hidden under a shielding can, and I don't have the schematics for the GUMSTIX Overo to be able to 
look for the signal anywhere else.

With the SD8686 only working every now and again with the nRESET control it's difficult to make progress as I'm stabbing around in the dark - I never really 
know if I'm improving things or not when adding/removing timeouts etc...

Previous kernel's never had runtime PM enabled, so I'm not sure what you mean to compare there?

Whatever procedure is first applied to the SD8686 with runtime PM disabled works 100% of the time.

Does anyone know if OLPC keep any out-of-tree patches to make runtime PM work for them on the SD8686 (maybe fudging GPIOs or similar)?

Cheers,
Joe



-----Original Message-----
From: Daniel Drake <dsd@laptop.org>
To: Joe Woodward <jw@terrafix.co.uk>
Cc: Ohad Ben-Cohen <ohad@wizery.com>, linux-mmc@vger.kernel.org, Chris Ball <cjb@laptop.org>
Date: Sat, 3 Dec 2011 10:44:18 -0600
Subject: Re: mmc: sdio: runtime PM and 8686 problems

> On Thu, Dec 1, 2011 at 5:28 AM, Joe Woodward <jw@terrafix.co.uk> wrote:
> > I've had a play with the nRESET line (as far as I can tell it is the
> only pin I have access to), and no joy.
> >
> > Also tried playing about a bit with the CMD sequence, again no joy.
> >
> > I'm not entirely sure of the CMD sequence. It seems we get:
> >  - CMD52 (x2)
> >  - CMD0
> >  - CMD8 (fails)
> >  - CMD5 (fails)
> >
> > In the "SDIO Simplified Specification Version 2.00"
> (https://www.sdcard.org/developers/overview/sdio/sdio_spec/Simplified_S
> DIO_Card_Spec.pdf) page 6 it
> > seems only a CMD52 should be required to "Re-init IO". Previous
> thread posts state CMD5 (x2) are required by the 8686, but why
> CMD0/CMD8?
> >
> > Incidentally errors only occur after the CMD0, but before the first
> error we get (i.e. a change of cs from 1 to 0):
> > "mmc1: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 20 width 0
> timing 0".
> 
> Can you see how this compares with older working kernels?
> 
> Some more things to try:
> there are some delays in mmc_power_off - try increasing them to 1000.
> 
> 
> mmc_sdio_power_restore does:
> sdio_reset (cmd52)
> mmc_go_idle (cmd0)
> mmc_send_if_cond (cmd8)
> mmc_send_io_op_cond (cmd52)
> 
> These are the commands you have been looking at from the angle of the
> logs.
> 
> Try sprinkling in a load of msleep(500) delays before and inbetween
> those commands. And if you suspect some of them are not necessary
> trying removing them, etc.
> 
> Non-scientific but this is how we have got things working so far :)
> 
> Thanks,
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html