| Message ID | 20190116113723.15668-1-ulf.hansson@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | [V2] wlcore: sdio: Fixup power on/off sequence | expand |
On Wed, 16 Jan 2019 at 16:43, Tony Lindgren <tony@atomide.com> wrote: > > * Ulf Hansson <ulf.hansson@linaro.org> [190116 11:37]: > > During "wlan-up", we are programming the FW into the WiFi-chip. However, > > re-programming the FW doesn't work, unless a power cycle of the WiFi-chip > > is made in-between the programmings. > > > > To conform to this requirement and to fix the regression in a simple way, > > let's start by allowing that the SDIO card (WiFi-chip) may stay powered on > > (runtime resumed) when wl12xx_sdio_power_off() returns. The intent with the > > current code is to treat this scenario as an error, but unfortunate this > > doesn't work as expected, so let's fix this. > > > > The other part is to guarantee that a power cycle of the SDIO card has been > > completed when wl12xx_sdio_power_on() returns, as to allow the FW > > programming to succeed. However, relying solely on runtime PM to deal with > > this isn't sufficient. For example, userspace may prevent runtime suspend > > via sysfs for the device that represents the SDIO card, leading to that the > > mmc core also keeps it powered on. For this reason, let's instead do a > > brute force power cycle in wl12xx_sdio_power_on(). > > > > Fixes: 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling") > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > > --- > > > > Changes in v2: > > - Keep the SDIO host claimed when calling mmc_hw_reset(). > > - Add a fixes tag. > > This v2 version works for me as tested with: > > # while [ 1 ]; do ifconfig wlan0 down; ifconfig wlan0 up; done > [ 181.364990] wlcore: down > [ 182.116424] wlcore: firmware booted (Rev 6.3.10.0.141) > [ 182.151641] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > [ 182.166778] wlcore: down > [ 182.773132] wlcore: firmware booted (Rev 6.3.10.0.141) > [ 182.811096] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > ... > > Thanks for fixing this issue properly, and feel free to add: > > Tested-by: Tony Lindgren <tony@atomide.com> Thanks for testing, great news! Before queuing this as fix, let's also see what the Hikey folkz thinks of this. I have pinged Anders and he is currently running a test suite. Kalle, can you please tag this for stable as well? Kind regards Uffe
On Tue, 22 Jan 2019 at 17:08, Jan Kiszka <jan.kiszka@web.de> wrote: > > On 21.01.19 15:40, Ulf Hansson wrote: > > On Fri, 18 Jan 2019 at 16:09, Ulf Hansson <ulf.hansson@linaro.org> wrote: > >> > >> On Fri, 18 Jan 2019 at 13:09, Jan Kiszka <jan.kiszka@web.de> wrote: > >>> > >>> On 17.01.19 10:54, Ulf Hansson wrote: > >>>> On Wed, 16 Jan 2019 at 21:26, Jan Kiszka <jan.kiszka@web.de> wrote: > >>>>> > >>>>> On 16.01.19 12:37, Ulf Hansson wrote: > >>>>>> During "wlan-up", we are programming the FW into the WiFi-chip. However, > >>>>>> re-programming the FW doesn't work, unless a power cycle of the WiFi-chip > >>>>>> is made in-between the programmings. > >>>>>> > >>>>>> To conform to this requirement and to fix the regression in a simple way, > >>>>>> let's start by allowing that the SDIO card (WiFi-chip) may stay powered on > >>>>>> (runtime resumed) when wl12xx_sdio_power_off() returns. The intent with the > >>>>>> current code is to treat this scenario as an error, but unfortunate this > >>>>>> doesn't work as expected, so let's fix this. > >>>>>> > >>>>>> The other part is to guarantee that a power cycle of the SDIO card has been > >>>>>> completed when wl12xx_sdio_power_on() returns, as to allow the FW > >>>>>> programming to succeed. However, relying solely on runtime PM to deal with > >>>>>> this isn't sufficient. For example, userspace may prevent runtime suspend > >>>>>> via sysfs for the device that represents the SDIO card, leading to that the > >>>>>> mmc core also keeps it powered on. For this reason, let's instead do a > >>>>>> brute force power cycle in wl12xx_sdio_power_on(). > >>>>>> > >>>>>> Fixes: 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling") > >>>>>> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > >>>>>> --- > >>>>>> > >>>>>> Changes in v2: > >>>>>> - Keep the SDIO host claimed when calling mmc_hw_reset(). > >>>>>> - Add a fixes tag. > >>>>>> --- > >>>>>> drivers/net/wireless/ti/wlcore/sdio.c | 15 +++++++-------- > >>>>>> 1 file changed, 7 insertions(+), 8 deletions(-) > >>>>>> > >>>>>> diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c > >>>>>> index bd10165d7eec..4d4b07701149 100644 > >>>>>> --- a/drivers/net/wireless/ti/wlcore/sdio.c > >>>>>> +++ b/drivers/net/wireless/ti/wlcore/sdio.c > >>>>>> @@ -164,6 +164,12 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue *glue) > >>>>>> } > >>>>>> > >>>>>> sdio_claim_host(func); > >>>>>> + /* > >>>>>> + * To guarantee that the SDIO card is power cycled, as required to make > >>>>>> + * the FW programming to succeed, let's do a brute force HW reset. > >>>>>> + */ > >>>>>> + mmc_hw_reset(card->host); > >>>>>> + > >>>>>> sdio_enable_func(func); > >>>>>> sdio_release_host(func); > >>>>>> > >>>>>> @@ -174,20 +180,13 @@ static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue *glue) > >>>>>> { > >>>>>> struct sdio_func *func = dev_to_sdio_func(glue->dev); > >>>>>> struct mmc_card *card = func->card; > >>>>>> - int error; > >>>>>> > >>>>>> sdio_claim_host(func); > >>>>>> sdio_disable_func(func); > >>>>>> sdio_release_host(func); > >>>>>> > >>>>>> /* Let runtime PM know the card is powered off */ > >>>>>> - error = pm_runtime_put(&card->dev); > >>>>>> - if (error < 0 && error != -EBUSY) { > >>>>>> - dev_err(&card->dev, "%s failed: %i\n", __func__, error); > >>>>>> - > >>>>>> - return error; > >>>>>> - } > >>>>>> - > >>>>>> + pm_runtime_put(&card->dev); > >>>>>> return 0; > >>>>>> } > >>>>>> > >>>>>> > >>>>> > >>>>> Just tested on both HiKey (620) and Ultra96 but it fails to fix the issue on > >>>>> both. I'm getting > >>>>> > >>>>> wl1271_sdio: probe of mmc2:0001:1 failed with error -16 > >>>>> > >>>>> during boot again, and the interface is not available. > >>>> > >>>> Okay, sounds like this may be a different problem then. Can you share > >>>> the complete log and the kernel config? > >>> > >>> You can find the config here [1], log from the HiKey boot attached. > >>> > >>>> I can prepare a debug patch as well, if you are willing to re-run the test? > >>> > >>> Sure, send it over, I can run it. > >> > >> Alright, sounds great. However, I need to defer that to Monday/Tuesday > >> next week. > >> > >>> > >>>> > >>>> Adding a post-power-on-delay-ms of 1 ms as you suggested [1], doesn't > >>>> sounds like the correct solution to me, unless I am overlooking some > >>>> things. The point is, since the mmc core succeeds to detect and > >>>> initialize the SDIO card, the power sequence seems to be correct. > >>> > >>> Yeah, I'm not claiming at all I know what I'm doing there, just that it happens > >>> to work. > >> > >> I see. Good to know, thanks! > >> > >>> > >>> Jan > >>> > >>> [1] > >>> https://github.com/siemens/jailhouse-images/blob/next/recipes-kernel/linux/files/arm64_defconfig_4.19 > >> > >> I have looked through the log and the defconfig. No obvious things > >> found at this point. Thanks for sharing them! > >> > > > > So, I have put together a debug patch, mostly to verify that things > > seems to be correct in regards to runtime PM. It should produce some > > prints to the log, particular during power on/off of the SDIO card and > > during probe of the wifi driver. Please re-run the test on top of the > > v2 version of the $subject patch. > > > > Log attached. Thanks! Okay, so the re-initialization of the SDIO card is failing, that's very valuable information. I noticed one difference while comparing your log with the one I received (offlist) from Anders... In your case the initialization frequency that works the first time is 300KHz, while in Anders case it's 100KHz. This sounds a bit fishy to me, so maybe there are some problems with the pwrseq after all. Let me think a bit and see what I can come up with as a possible solution. In the meantime, can you re-run the test with same debug patch, but change the post-power-on-delay-ms to let's say 10 ms in the DTS? I am going to ask Anders to do the same test on his side, as to see if we get different values of the found initialization frequency. Kind regards Uffe
On Tue, 22 Jan 2019 at 17:24, Kalle Valo <kvalo@codeaurora.org> wrote: > > Ulf Hansson <ulf.hansson@linaro.org> wrote: > > > During "wlan-up", we are programming the FW into the WiFi-chip. However, > > re-programming the FW doesn't work, unless a power cycle of the WiFi-chip > > is made in-between the programmings. > > > > To conform to this requirement and to fix the regression in a simple way, > > let's start by allowing that the SDIO card (WiFi-chip) may stay powered on > > (runtime resumed) when wl12xx_sdio_power_off() returns. The intent with the > > current code is to treat this scenario as an error, but unfortunate this > > doesn't work as expected, so let's fix this. > > > > The other part is to guarantee that a power cycle of the SDIO card has been > > completed when wl12xx_sdio_power_on() returns, as to allow the FW > > programming to succeed. However, relying solely on runtime PM to deal with > > this isn't sufficient. For example, userspace may prevent runtime suspend > > via sysfs for the device that represents the SDIO card, leading to that the > > mmc core also keeps it powered on. For this reason, let's instead do a > > brute force power cycle in wl12xx_sdio_power_on(). > > > > Fixes: 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling") > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > > Tested-by: Tony Lindgren <tony@atomide.com> > > Tested-by: Anders Roxell <anders.roxell@linaro.org> > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> > > Patch applied to wireless-drivers.git, thanks. > > 13e62626c578 wlcore: sdio: Fixup power on/off sequence Great, thanks! Let's see how we can fix Jan's problem on top. Kind regards Uffe
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c index bd10165d7eec..4d4b07701149 100644 --- a/drivers/net/wireless/ti/wlcore/sdio.c +++ b/drivers/net/wireless/ti/wlcore/sdio.c @@ -164,6 +164,12 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue *glue) } sdio_claim_host(func); + /* + * To guarantee that the SDIO card is power cycled, as required to make + * the FW programming to succeed, let's do a brute force HW reset. + */ + mmc_hw_reset(card->host); + sdio_enable_func(func); sdio_release_host(func); @@ -174,20 +180,13 @@ static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue *glue) { struct sdio_func *func = dev_to_sdio_func(glue->dev); struct mmc_card *card = func->card; - int error; sdio_claim_host(func); sdio_disable_func(func); sdio_release_host(func); /* Let runtime PM know the card is powered off */ - error = pm_runtime_put(&card->dev); - if (error < 0 && error != -EBUSY) { - dev_err(&card->dev, "%s failed: %i\n", __func__, error); - - return error; - } - + pm_runtime_put(&card->dev); return 0; }
During "wlan-up", we are programming the FW into the WiFi-chip. However, re-programming the FW doesn't work, unless a power cycle of the WiFi-chip is made in-between the programmings. To conform to this requirement and to fix the regression in a simple way, let's start by allowing that the SDIO card (WiFi-chip) may stay powered on (runtime resumed) when wl12xx_sdio_power_off() returns. The intent with the current code is to treat this scenario as an error, but unfortunate this doesn't work as expected, so let's fix this. The other part is to guarantee that a power cycle of the SDIO card has been completed when wl12xx_sdio_power_on() returns, as to allow the FW programming to succeed. However, relying solely on runtime PM to deal with this isn't sufficient. For example, userspace may prevent runtime suspend via sysfs for the device that represents the SDIO card, leading to that the mmc core also keeps it powered on. For this reason, let's instead do a brute force power cycle in wl12xx_sdio_power_on(). Fixes: 728a9dc61f13 ("wlcore: sdio: Fix flakey SDIO runtime PM handling") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> --- Changes in v2: - Keep the SDIO host claimed when calling mmc_hw_reset(). - Add a fixes tag. --- drivers/net/wireless/ti/wlcore/sdio.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) -- 2.17.1