WLAN regression fixes for omap4 after moving to DT based booting
Subsystems (5)
Tony Lindgren
maintainercover WLAN regression fixes for omap4 after moving to DT based booting
Hi all,
Looks like these two patches are still missing as I did not update the kernel on my panda for a while but was testing with my 4430sdp that does not have the WLAN card..
Regards,
Tony
---
Tony Lindgren (2):
ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for blaze
arch/arm/boot/dts/omap4-panda-common.dtsi | 46 ++++++++++++++++++++++++++++- arch/arm/boot/dts/omap4-sdp.dts | 39 ++++++++++++++++++++++++- 2 files changed, 83 insertions(+), 2 deletions(-)
Signature · 1 line
Signature
Tony Lindgren
maintainerPATCH 1/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
Commit b42b9181 (ARM: OMAP2+: Remove board-omap4panda.c) removed legacy booting in favor of device tree based booting for pandaboard. That caused the WLAN to stop working as the related .dts entries fell through the cracks.
The legacy muxing was setting pulls for GPIO 48 and 49, so let's keep that behaviour for now to avoid further regressions for BT and FM. Also input logic was enabled for MMC CLK line, but I've verified that the input logic we don't need enabled for CLK line as it's not bidirectional.
Also, we want to use non-removable instead of ti,non-removable as the ti,non-removable also sets no_regulator_off_init which is really not what we want as then wl12xx won't get powered up and down which is needed for resetting it.
Note that looks like the WLAN interface fails to come up after a warm reset, but that most likely was also happening with the legacy booting and needs a separate fix.
--- arch/arm/boot/dts/omap4-panda-common.dtsi | 46 ++++++++++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-)
arch/arm/boot/dts/omap4-panda-common.dtsi +45 -1
@@ -107,6 +107,19 @@ */ clock-frequency = <19200000>; }; + + /* regulator for wl12xx on sdio5 */ + wl12xx_vmmc: wl12xx_vmmc { + pinctrl-names = "default"; + pinctrl-0 = <&wl12xx_gpio>; + compatible = "regulator-fixed"; + regulator-name = "vwl1271"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + gpio = <&gpio2 11 0>; + startup-delay-us = <70000>; + enable-active-high; + }; }; &omap4_pmx_wkup {
@@ -235,6 +248,33 @@ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */ >; }; + + /* + * wl12xx GPIO outputs for WLAN_EN, BT_EN, FM_EN, BT_WAKEUP + * REVISIT: Are the pull-ups needed for GPIO 48 and 49? + */ + wl12xx_gpio: pinmux_wl12xx_gpio { + pinctrl-single,pins = < + 0x26 (PIN_OUTPUT | MUX_MODE3) /* gpmc_a19.gpio_43 */ + 0x2c (PIN_OUTPUT | MUX_MODE3) /* gpmc_a22.gpio_46 */ + 0x30 (PIN_OUTPUT_PULLUP | MUX_MODE3) /* gpmc_a24.gpio_48 */ + 0x32 (PIN_OUTPUT_PULLUP | MUX_MODE3) /* gpmc_a25.gpio_49 */ + >; + }; + + /* wl12xx GPIO inputs and SDIO pins */ + wl12xx_pins: pinmux_wl12xx_pins { + pinctrl-single,pins = < + 0x38 (PIN_INPUT | MUX_MODE3) /* gpmc_ncs2.gpio_52 */ + 0x3a (PIN_INPUT | MUX_MODE3) /* gpmc_ncs3.gpio_53 */ + 0x108 (PIN_OUTPUT | MUX_MODE0) /* sdmmc5_clk.sdmmc5_clk */ + 0x10a (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_cmd.sdmmc5_cmd */ + 0x10c (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_dat0.sdmmc5_dat0 */ + 0x10e (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_dat1.sdmmc5_dat1 */ + 0x110 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_dat2.sdmmc5_dat2 */ + 0x112 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_dat3.sdmmc5_dat3 */ + >; + }; }; &i2c1 {
@@ -314,8 +354,12 @@ }; &mmc5 { - ti,non-removable; + pinctrl-names = "default"; + pinctrl-0 = <&wl12xx_pins>; + vmmc-supply = <&wl12xx_vmmc>; + non-removable; bus-width = <4>; + cap-power-off-card; }; &emif1 {
PATCH 1/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
Hi Tony,
Both patches look good to me, though I didn't have the time to retest them.
--
Cheers,
Luca.
Quoted 103 lines · Tony Lindgren
Commit
b42b9181(ARM: OMAP2+: Removeboard-omap4panda.c) removed legacy booting in favor of device tree based booting for pandaboard. That caused the WLAN to stop working as the related .dts entries fell through the cracks.The legacy muxing was setting pulls for GPIO 48 and 49, so let's keep that behaviour for now to avoid further regressions for BT and FM. Also input logic was enabled for MMC CLK line, but I've verified that the input logic we don't need enabled for CLK line as it's not bidirectional.
Also, we want to use non-removable instead of ti,non-removable as the ti,non-removable also sets
no_regulator_off_initwhich is really not what we want as then wl12xx won't get powered up and down which is needed for resetting it.Note that looks like the WLAN interface fails to come up after a warm reset, but that most likely was also happening with the legacy booting and needs a separate fix.
Cc Paolo Pisati <[email protected]>Cc Benoit Cousson <[email protected]>Cc Rajendra Nayak <[email protected]>Cc Luciano Coelho <[email protected]>Cc devicetree-discuss at lists.ozlabs.orgSigned-off-by Tony Lindgren <[email protected]>--- arch/arm/boot/dts/omap4-panda-common.dtsi | 46 ++++++++++++++++++++++++++++- 1 file changed, 45 insertions(+), 1 deletion(-)arch/arm/boot/dts/omap4-panda-common.dtsi +45
-1@@ -107,6 +107,19 @@ */ clock-frequency = <19200000>; }; + + /* regulator for wl12xx on sdio5 */ + wl12xx_vmmc: wl12xx_vmmc { + pinctrl-names = "default"; + pinctrl-0 = <&wl12xx_gpio>; + compatible = "regulator-fixed"; + regulator-name = "vwl1271"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + gpio = <&gpio2 11 0>; + startup-delay-us = <70000>; + enable-active-high; + }; }; &omap4_pmx_wkup {@@ -235,6 +248,33 @@ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */ >; }; + + /* + * wl12xx GPIO outputs for WLAN_EN, BT_EN, FM_EN, BT_WAKEUP + * REVISIT: Are the pull-ups needed for GPIO 48 and 49? + */ + wl12xx_gpio: pinmux_wl12xx_gpio { + pinctrl-single,pins = < + 0x26 (PIN_OUTPUT | MUX_MODE3) /* gpmc_a19.gpio_43 */ + 0x2c (PIN_OUTPUT | MUX_MODE3) /* gpmc_a22.gpio_46 */ + 0x30 (PIN_OUTPUT_PULLUP | MUX_MODE3) /* gpmc_a24.gpio_48 */ + 0x32 (PIN_OUTPUT_PULLUP | MUX_MODE3) /* gpmc_a25.gpio_49 */ + >; + }; + + /* wl12xx GPIO inputs and SDIO pins */ + wl12xx_pins: pinmux_wl12xx_pins { + pinctrl-single,pins = < + 0x38 (PIN_INPUT | MUX_MODE3) /* gpmc_ncs2.gpio_52 */ + 0x3a (PIN_INPUT | MUX_MODE3) /* gpmc_ncs3.gpio_53 */ + 0x108 (PIN_OUTPUT | MUX_MODE0) /* sdmmc5_clk.sdmmc5_clk */ + 0x10a (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_cmd.sdmmc5_cmd */ + 0x10c (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_dat0.sdmmc5_dat0 */ + 0x10e (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_dat1.sdmmc5_dat1 */ + 0x110 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_dat2.sdmmc5_dat2 */ + 0x112 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_dat3.sdmmc5_dat3 */ + >; + }; }; &i2c1 {@@ -314,8 +354,12 @@ }; &mmc5 { - ti,non-removable; + pinctrl-names = "default"; + pinctrl-0 = <&wl12xx_pins>; + vmmc-supply = <&wl12xx_vmmc>; + non-removable; bus-width = <4>; + cap-power-off-card; }; &emif1 {
PATCH 1/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
Quoted 2 lines · Luca Coelho
Both patches look good to me, though I didn't have the time to retest them.
Actually I don't even have a Blaze device anymore, so I can't really test the second patch. :(
--
Luca.
Tony Lindgren
maintainerPATCH 1/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
Quoted 6 lines · Luca Coelho
Quoted 2 lines · Luca Coelho
Both patches look good to me, though I didn't have the time to retest them.
Actually I don't even have a Blaze device anymore, so I can't really test the second patch. :(
OK no problem, I've tested it on panda es.
Regards,
Tony
PATCH 1/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
Hi Tony,
Quoted 9 lines · Tony Lindgren
Quoted 6 lines · Luca Coelho
Quoted 2 lines · Luca Coelho
Both patches look good to me, though I didn't have the time to retest them.
Actually I don't even have a Blaze device anymore, so I can't really test the second patch. :(
OK no problem, I've tested it on panda es.
Do we have someone out-there that still own a Blaze?
Anyway, I'm about to send a DTS fix branch for -rc2, so I'll include these two patches.
Thanks,
Benoit
Tony Lindgren
maintainerPATCH 1/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
Quoted 11 lines · Benoit Cousson
Hi Tony,
Quoted 8 lines · Tony Lindgren
Quoted 6 lines · Luca Coelho
Quoted 2 lines · Luca Coelho
Both patches look good to me, though I didn't have the time to retest them.
Actually I don't even have a Blaze device anymore, so I can't really test the second patch. :(
Quoted 6 lines
Quoted 1 line
OK no problem, I've tested it on panda es.
Do we have someone out-there that still own a Blaze?
Anyway, I'm about to send a DTS fix branch for -rc2, so I'll include these two patches.
OK yes good please do pick them up, I'll drop them from my not-yet-pushed-out omap-for-v3.12/fixes.
Regards,
Tony
Tony Lindgren
maintainerPATCH 1/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Benoit Cousson
Hi Tony,
Quoted 9 lines · Tony Lindgren
Quoted 6 lines · Luca Coelho
Quoted 2 lines · Luca Coelho
Both patches look good to me, though I didn't have the time to retest them.
Actually I don't even have a Blaze device anymore, so I can't really test the second patch. :(
OK no problem, I've tested it on panda es.
Quoted 7 lines
Quoted 4 lines
Do we have someone out-there that still own a Blaze?
Anyway, I'm about to send a DTS fix branch for -rc2, so I'll include these two patches.
OK yes good please do pick them up, I'll drop them from my not-yet-pushed-out omap-for-v3.12/fixes.
Hmm looks like there's also some new regression in the wl12xx driver:
# iwconfig wlan0 wlan0 no wireless extensions.
My test script was just doing:
# iw dev wlan0 scan
And that works fine. Luca, any ideas?
Regards,
Tony
PATCH 1/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
Quoted 26 lines · Tony Lindgren
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Benoit Cousson
Hi Tony,
Quoted 9 lines · Tony Lindgren
Quoted 6 lines · Luca Coelho
Quoted 2 lines · Luca Coelho
Both patches look good to me, though I didn't have the time to retest them.
Actually I don't even have a Blaze device anymore, so I can't really test the second patch. :(
OK no problem, I've tested it on panda es.
Quoted 7 lines
Quoted 4 lines
Do we have someone out-there that still own a Blaze?
Anyway, I'm about to send a DTS fix branch for -rc2, so I'll include these two patches.
OK yes good please do pick them up, I'll drop them from my not-yet-pushed-out omap-for-v3.12/fixes.
Hmm looks like there's also some new regression in the wl12xx driver:
Quoted 8 lines
# iwconfig wlan0 wlan0 no wireless extensions.My test script was just doing:
# iw dev wlan0 scanAnd that works fine. Luca, any ideas?
Have you compiled WEXT support in your kernel? iwconfig uses the (deprecated) Wireless Extensions API. iw uses the current nl80211 API.
If you want to use iwconfig and friends you need to enable CONFIG_CFG80211_WEXT.
--
Cheers,
Luca.
Tony Lindgren
maintainerPATCH 1/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
Quoted 34 lines · Luca Coelho
Quoted 33 lines · Tony Lindgren
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Benoit Cousson
Hi Tony,
Quoted 9 lines · Tony Lindgren
Quoted 6 lines · Luca Coelho
Quoted 2 lines · Luca Coelho
Both patches look good to me, though I didn't have the time to retest them.
Actually I don't even have a Blaze device anymore, so I can't really test the second patch. :(
OK no problem, I've tested it on panda es.
Quoted 7 lines
Quoted 4 lines
Do we have someone out-there that still own a Blaze?
Anyway, I'm about to send a DTS fix branch for -rc2, so I'll include these two patches.
OK yes good please do pick them up, I'll drop them from my not-yet-pushed-out omap-for-v3.12/fixes.
Hmm looks like there's also some new regression in the wl12xx driver:
# iwconfig wlan0 wlan0 no wireless extensions.My test script was just doing:
# iw dev wlan0 scan
Quoted 7 lines
Quoted 1 line
And that works fine. Luca, any ideas?
Have you compiled WEXT support in your kernel? iwconfig uses the (deprecated) Wireless Extensions API. iw uses the current nl80211 API.
If you want to use iwconfig and friends you need to enable
CONFIG_CFG80211_WEXT.
OK thanks, I don't need to use iwconfig. Looks like the default changed in commit 10bab00af (cfg80211: deprecate CFG80211_WEXT).
Regards,
Tony
PATCH 1/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
Quoted 37 lines · Tony Lindgren
Quoted 36 lines · Luca Coelho
Quoted 34 lines · Tony Lindgren
Quoted 14 lines · Tony Lindgren
Quoted 13 lines · Benoit Cousson
Hi Tony,
Quoted 9 lines · Tony Lindgren
Quoted 6 lines · Luca Coelho
Quoted 2 lines · Luca Coelho
Both patches look good to me, though I didn't have the time to retest them.
Actually I don't even have a Blaze device anymore, so I can't really test the second patch. :(
OK no problem, I've tested it on panda es.
Quoted 7 lines
Quoted 4 lines
Do we have someone out-there that still own a Blaze?
Anyway, I'm about to send a DTS fix branch for -rc2, so I'll include these two patches.
OK yes good please do pick them up, I'll drop them from my not-yet-pushed-out omap-for-v3.12/fixes.
Hmm looks like there's also some new regression in the wl12xx driver:
# iwconfig wlan0 wlan0 no wireless extensions.My test script was just doing:
# iw dev wlan0 scanAnd that works fine. Luca, any ideas?
Quoted 8 lines
Quoted 5 lines
Have you compiled WEXT support in your kernel? iwconfig uses the (deprecated) Wireless Extensions API. iw uses the current nl80211 API.
If you want to use iwconfig and friends you need to enable
CONFIG_CFG80211_WEXT.OK thanks, I don't need to use iwconfig. Looks like the default changed in commit
10bab00af(cfg80211: deprecateCFG80211_WEXT).
Yeah, it's not enabled by default anymore. And it was more than about time! ;)
--
Luca.
PATCH 1/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard
In reply to Benoit CoussonQuoted 13 lines · Benoit Cousson
Hi Tony,
Quoted 9 lines · Tony Lindgren
Quoted 7 lines · Luca Coelho
Quoted 3 lines · Luca Coelho
Both patches look good to me, though I didn't have the time to retest them.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Actually I don't even have a Blaze device anymore, so I can't really test the second patch. :(
OK no problem, I've tested it on panda es.
Do we have someone out-there that still own a Blaze?
I think I might have one in a box somewhere. I'll take a look.
-Olof
Tony Lindgren
maintainerPATCH 2/2 ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for blaze
In reply to Tony LindgrenCommit 76787b3b (ARM: OMAP2+: Remove board-4430sdp.c) removed legacy booting in favor of device tree based booting for 4430sdp. That caused the WLAN to stop working as the related .dts entries fell through the cracks.
I don't have the "1283 PG 2.21 connectivity device" on my 4430sdp, but the earlier version of this patch was tested by Luciano Coelho. This version has left out the input logic for MMC CLK line compared to the earlier version as that is not bidirectional, and should be safe to do.
--- arch/arm/boot/dts/omap4-sdp.dts | 39 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 38 insertions(+), 1 deletion(-)
arch/arm/boot/dts/omap4-sdp.dts +38 -1
@@ -140,6 +140,19 @@ "DMic", "Digital Mic", "Digital Mic", "Digital Mic1 Bias"; }; + + /* regulator for wl12xx on sdio5 */ + wl12xx_vmmc: wl12xx_vmmc { + pinctrl-names = "default"; + pinctrl-0 = <&wl12xx_gpio>; + compatible = "regulator-fixed"; + regulator-name = "vwl1271"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + gpio = <&gpio2 22 0>; + startup-delay-us = <70000>; + enable-active-high; + }; }; &omap4_pmx_wkup {
@@ -295,6 +308,26 @@ 0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */ >; }; + + /* wl12xx GPIO output for WLAN_EN */ + wl12xx_gpio: pinmux_wl12xx_gpio { + pinctrl-single,pins = < + 0x3c (PIN_OUTPUT | MUX_MODE3) /* gpmc_nwp.gpio_54 */ + >; + }; + + /* wl12xx GPIO inputs and SDIO pins */ + wl12xx_pins: pinmux_wl12xx_pins { + pinctrl-single,pins = < + 0x3a (PIN_INPUT | MUX_MODE3) /* gpmc_ncs3.gpio_53 */ + 0x108 (PIN_OUTPUT | MUX_MODE3) /* sdmmc5_clk.sdmmc5_clk */ + 0x10a (PIN_INPUT_PULLUP | MUX_MODE3) /* sdmmc5_cmd.sdmmc5_cmd */ + 0x10c (PIN_INPUT_PULLUP | MUX_MODE3) /* sdmmc5_dat0.sdmmc5_dat0 */ + 0x10e (PIN_INPUT_PULLUP | MUX_MODE3) /* sdmmc5_dat1.sdmmc5_dat1 */ + 0x110 (PIN_INPUT_PULLUP | MUX_MODE3) /* sdmmc5_dat2.sdmmc5_dat2 */ + 0x112 (PIN_INPUT_PULLUP | MUX_MODE3) /* sdmmc5_dat3.sdmmc5_dat3 */ + >; + }; }; &i2c1 {
@@ -420,8 +453,12 @@ }; &mmc5 { + pinctrl-names = "default"; + pinctrl-0 = <&wl12xx_pins>; + vmmc-supply = <&wl12xx_vmmc>; + non-removable; bus-width = <4>; - ti,non-removable; + cap-power-off-card; }; &emif1 {
cover WLAN regression fixes for omap4 after moving to DT based booting
In reply to Tony LindgrenHi,
Not related to wlan but with DT conversion; I noticed the following in dmesg on Panda ES with omap2plus_defconfig on current mainline:
[ 0.000000] smp_twd: clock not found -2
and:
[ 0.440399] omap-gpmc 50000000.gpmc: error: clk_get
-Olof
Tony Lindgren
maintainercover WLAN regression fixes for omap4 after moving to DT based booting
Quoted 6 lines · Olof Johansson
Hi,
Not related to wlan but with DT conversion; I noticed the following in dmesg on Panda ES with
omap2plus_defconfigon current mainline:[ 0.000000] smp_twd: clock not found -2
That should get fixed for v3.13 when we get the proper DT clocks for omap. Currently twd_get_clock() currently does:
if (np)
twd_clk = of_clk_get(np, 0);
else
twd_clk = clk_get_sys("smp_twd", NULL);So if fails in the np case right now.
I'd probably wait for v3.13 on this one to avoid adding temporary timer workarounds to twd_get_clock() or stuffing the clock for the timer by using of_clk_add_provider().
If people feel strongly that we should fix it for v3.12, then let me know. Things do work without it, of course the local timer is not being used though.
Quoted 3 lines
and:
[ 0.440399] omap-gpmc 50000000.gpmc: error: clk_get
Thanks that's an easy one. I'll queue the following fix.
Regards,
Tony
From: Tony Lindgren <[email protected]>
Date: Mon, 16 Sep 2013 14:22:31 -0700
Subject: [PATCH] ARM: OMAP4: Fix clock_get error for GPMC during boot
Looks like we still have the legacy clock alias name for omap4 GPMC (General Purpose Memory Controller), so let's fix it for the device tree naming. There's no need to keep the legacy naming as omap4 is DT only nowadays.
Without this fix we get the following error while booting:
[ 0.440399] omap-gpmc 50000000.gpmc: error: clk_get
arch/arm/mach-omap2/cclock44xx_data.c +1 -1
@@ -1632,7 +1632,7 @@ static struct omap_clk omap44xx_clks[] = {CLK (NULL ,"auxclk5_src_ck" , &auxclk5_src_ck),CLK (NULL ,"auxclk5_ck" , &auxclk5_ck),CLK (NULL ,"auxclkreq5_ck" , &auxclkreq5_ck), -CLK ("omap-gpmc" ,"fck" , &dummy_ck), +CLK ("50000000.gpmc" ,"fck" , &dummy_ck),CLK ("omap_i2c.1" ,"ick" , &dummy_ck),CLK ("omap_i2c.2" ,"ick" , &dummy_ck), CLK("omap_i2c.3", "ick", &dummy_ck),