On Fri, 2015-01-30 at 11:37 +0100, Marek Szyprowski wrote:

Hello,

On 2015-01-29 11:56, Javier Martinez Canillas wrote:

quoted

On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski
[off-list ref] wrote:

quoted

quoted

Also, I wonder whether we could extend the mmc-pwrseq to cover your
case? Did you consider that as an option?

I didn't consider mmc-pwrseq yet. For me it looked straightforward to

I agree with Ulf that using mmc-pwrseq would be a good solution and in
fact I think the pwrseq_simple [0] driver will fit your use case since
it supports a reset GPIO pin which is what many WLAN chips attached to
a SDIO interface use.

Ok, I've checked mmc-prwseq and mmc-pwrseq-simple. I also checked the
hardware and it mmc-pwrseq-simple cannot be used directly.

Although the signal is called RSTN (on Odroid U3 schema), the eMMC card
gets resetted not on low line level, but during the rising edge. This RSTN
line is also pulled up by the external resistor. However, the strangest
thing is the fact that the default SoC configuration (which is applied
during hw reset) for this GPIO line is input, pulled-down. The SoC
internal pull-down is stronger than the external pull up, so in the end,
during the SoC reboot the RSTN signal is set to zero. Later bootloader
disables the internal pull-down.

To sum up - to perform proper reboot on Odroid U3/XU3, one need to set
RSTN to zero, wait a while and the set it back to 1.

To achieve this with mmc-pwrseq-simple, I would need to modify the power_off
callback to toggle reset line to zero and back to one. This however might
not be desired to other sd/mmc cards used with mmc-pwrseq-simple.

I can also provide separate mmc-pwrsrq-odroid driver, which will be very
similar to mmc-pwrseq-simple.

Apart from the initial odd setup of the SoC pins this is the standard
H/W reset operation specified by Jedec 4.4:

* pull the reset line down for at least 1us
* pull the line up again
* Wait at least 200us before sending commands

(sdhci_pci_int_hw_reset also implements this).

I'm not sure what the determining factor is for a pwrseq driver vs. it
being part of the mmc core would be. But if you do a pwrseq driver it
shouldn't be board specific e.g. call it mmc-pwrseq-emmc4.4 instead of
-odroid?


-- 
Sjoerd Simons [off-list ref]
Collabora Ltd.