On Fri, 2015-01-30 at 11:37 +0100, Marek Szyprowski wrote: > Hello, > > On 2015-01-29 11:56, Javier Martinez Canillas wrote: > > On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski > > <m.szyprowski@xxxxxxxxxxx> wrote: > >>> 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 <sjoerd.simons@xxxxxxxxxxxxxxx> Collabora Ltd.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature