On 2018/5/7 15:36, Quentin Schulz wrote:
Hi 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);
I don't have the tablet with me at work, I'll let you know the output of
this modification in about 9 hours.
I think you're offering this patch because of the "sif sif_enable_irq
failed" debug message which calls sdio_claim_irq and fails.
Here sdio_claim_irq() fails at
https://elixir.bootlin.com/linux/latest/source/drivers/mmc/core/sdio_irq.c#L294
Right. I think the best thing to do here is to play whac-a-mole. :)
In the code of the ESP8089 driver, failing to claim the IRQ isn't
blocking and I don't think it was disabled or something was done in SDIO
subsystem on this IRQ or its handler. Anyway, anything's worth trying :)
I'll let you know, thanks,
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
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
