Re: [PATCH 0/5] mmc: sdio: Enable SW reset of SDIO cards

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Shawn,

On Mon, May 07, 2018 at 03:29:31PM +0800, Shawn Lin wrote:
> On 2018/5/6 22:01, Quentin Schulz wrote:
> > Hi Ulf,
> > 
> > On Wed, May 02, 2018 at 11:26:30AM +0200, Ulf Hansson wrote:
> > > On 23 April 2018 at 11:50, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> > > > On 14 April 2018 at 13:25, Quentin Schulz <quentin.schulz@xxxxxxxxxxx> wrote:
> > > > > Hi Ulf and Hans,
> > > > > 
> > > > > On Fri, Apr 06, 2018 at 10:41:10AM +0200, Hans de Goede wrote:
> > > > > > Hi Ulf,
> > > > > > 
> > > > > > On 05-04-18 22:19, Ulf Hansson wrote:
> > > > > > > It's rather common that SDIO func devices becomes loaded with a new firmware as
> > > > > > > a part of the SDIO func driver being probed. However, in some special scenarios
> > > > > > > the SDIO func device needs a SW reset, as to start running the new firmware.
> > > > > > > 
> > > > > > > More importantly, a full power cycle doesn't work, as that would reset also the
> > > > > > > firmware, thus the existing mmc_hw_reset() API can't be used to deal with these
> > > > > > > scenarios.
> > > > > > > 
> > > > > > > Therefore this series suggest to add a new API, mmc_sw_reset(), which resets
> > > > > > > and re-initialize the SDIO card. A couple of the patches in the series are
> > > > > > > mostly re-factorings making generic improvements to the related code.
> > > > > > > 
> > > > > > > For more background to this series, feel free to digest the discussions from
> > > > > > > the submitted patch: https://patchwork.kernel.org/patch/9857175/
> > > > > > > 
> > > > > > > It should be noted, at this point this series has only be compile tested. Help
> > > > > > > with tests and deployment of using the new API is greatly appreciated.
> > > > > > 
> > > > > > Thank you for this series, I've taken a quick look and it looks good,
> > > > > > but the proof is in the pudding. Quentin can you test this on an ARM
> > > > > > board with an ESP8089 sometime the coming week?
> > > > > > 
> > > > > 
> > > > > I applied your patches on top of next-20180406.
> > > > > 
> > > > > I may need some help to get the ESP8089 driver to work. Note that I'm
> > > > > very new to MMC and SDIO, just so you know (and so you can adapt your
> > > > > answer).
> > > > > 
> > > > > It's filling my kernel log buffer with a lot of these[1]. I've basically
> > > > > replaced Hans's mmc_force_detect_change() by your mmc_sw_reset() in
> > > > > esp_sdio_probe() of the ESP8089 driver and that's it. Here is my old
> > > > > patch series for ESP8089[2].
> > > > > 
> > > > > I can't say if it's an error in your patch series or me using it the
> > > > > wrong way.
> > > > > 
> > > > > Could you help me debug this so that we can make the "weird" SDIO
> > > > > devices such as the ESP8089 work in the kernel :)?
> > > > > 
> > > > > I'll try to mount my rootfs from something else than an initramfs so
> > > > > that it may solve my problem of dmesg not showing the whole log.
> > > > > 
> > > > > [1] http://code.bulix.org/eechlb-318686
> > > > 
> > > > Unless I am misstaken, it looks like the messages comes from a
> > > > WARN_ON(!host->claimed); in mmc_wait_for_cmd().
> > > > 
> > > > Did you call sdio_claim_host() before calling mmc_sw_reset()? And then
> > > > of course you need to release the host when you are ready executing
> > > > the required operations, sdio_release_host().
> > > > 
> > 
> > That was it, thanks.
> > 
> > Now, I go pass mmc_sw_reset and the init of the driver can continue but
> > I'm now hitting a timeout waiting for a completion.
> > 
> > I'll need definitely to put more time into it to debug it now. Next week
> > has two holidays in France though, I'll try my best to find time to work
> > on it next week but can't promise much work will be done.
> > 
> > If anyone wants to help meanwhile, here is the code:
> > https://github.com/QSchulz/linux/tree/mmc_sw_reset/esp8089
> > 
> > This is the bootlog of the tablet:
> > http://code.bulix.org/t7iken-328962
> 
> Could you try:
> 
> drivers/net/wireless/espressif/esp8089/sdio_sif_esp.c
> -543,21 +530,61 @@ static int esp_sdio_probe(struct sdio_func *func,
> 	sdio_claim_host(func);
> +	sdio_release_irq(func);
> 	mmc_sw_reset(host);
> 	sdio_release_host(func);
> 

You rock :) That made it work despite my wrong assumptions. Thanks a
lot!

We've got ESP8089 working without a dirty hack \o/ (well at least not on
the core side :) ).

Ulf, I'm very happy (and relieved) to give my

Tested-by: Quentin Schulz <quentin.schulz@xxxxxxxxxxx>

Thanks a ton for the patch series, I can now go back to cleaning up the
WiFi driver :)

Quentin

> > 
> > Hope we can get this sorted out somehow quickly so we can just put this
> > issue of weird SDIO devices behind us once and for all :) (well, until
> > the next weird ones :D).
> > 
> > Thanks,
> > Quentin
> > 
> > > > > [2] https://lkml.org/lkml/2017/7/21/386
> > > > > 
> > > > > Let me know how I can be helpful,
> > > > > Thanks,
> > > > > Quentin
> > > 
> > > Quentin, ping!
> > > 
> > > Just tell me if there is anything else I can help out with!
> > > 
> > > Kind regards
> > > Uffe
> 

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux