On omap5-uevm, I can iw dev wlan0 scan, but keep getting the following repeating and cannot connect to networks: WARNING: CPU: 0 PID: 176 at drivers/net/wireless/ti/wlcore/main.c:787 wl12xx_queue_recovery_work.part.7+0x54/0x60 [wlcore] Modules linked in: lib80211 bluetooth omapfb leds_gpio cfbfillrect led_class cfbimgblt cfbcopyarea cpufreq_dt omap_wdt omap4_keypad matrix_keymap evdev ti_soc_thermal thermal_sys hwmon snd_soc_omap_mcbsp wlcore_sdio wl18xx wlcore mac80211 cfg80211 connector_hdmi encoder_tpd12s015 omapdss gpio_pca953x hid_generic usbhid smsc95xx smsc75xx usbnet usb_f_acm u_ether usb_f_mass_storage usb_f_serial u_serial xhci_plat_hcd xhci_hcd dwc3_omap dwc3 ohci_omap3 ohci_hcd ehci_omap ehci_hcd phy_omap_usb2 libcomposite udc_core usbcore snd_soc_omap_abe_twl6040 snd_soc_omap_mcpdm snd_soc_twl6040 snd_soc_omap snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore rtc_palmas rtc_twl palmas_pwrbutton extcon_palmas extcon clk_palmas [last unloaded: wl12xx] CPU: 0 PID: 176 Comm: irq/45-wl18xx Tainted: G W 4.7.0-rc1+ #387 Hardware name: Generic OMAP5 (Flattened Device Tree) [<c0110338>] (unwind_backtrace) from [<c010c3dc>] (show_stack+0x10/0x14) [<c010c3dc>] (show_stack) from [<c048152c>] (dump_stack+0xb0/0xe4) [<c048152c>] (dump_stack) from [<c0137ba8>] (__warn+0xd8/0x104) [<c0137ba8>] (__warn) from [<c0137c84>] (warn_slowpath_null+0x20/0x28) [<c0137c84>] (warn_slowpath_null) from [<bf4268ec>] (wl12xx_queue_recovery_work.part.7+0x54/0x60 [wlcore]) [<bf4268ec>] (wl12xx_queue_recovery_work.part.7 [wlcore]) from [<bf426ba0>] (wlcore_irq+0x15c/0x174 [wlcore]) [<bf426ba0>] (wlcore_irq [wlcore]) from [<c019e3c4>] (irq_thread_fn+0x1c/0x34) [<c019e3c4>] (irq_thread_fn) from [<c019e6cc>] (irq_thread+0x130/0x1f8) [<c019e6cc>] (irq_thread) from [<c015ac78>] (kthread+0xdc/0xf8) [<c015ac78>] (kthread) from [<c0107910>] (ret_from_fork+0x14/0x24) ---[ end trace f2048e093a99db55 ]--- wlcore: Hardware recovery in progress. FW ver: Rev 8.9.0.1.55 wlcore: pc: 0x3e70, hint_sts: 0x00000000 count: 39 wlcore: down ieee80211 phy0: Hardware restart was requested wlan0: authentication with 42:04:7a:03:0b:78 timed out wlcore: PHY firmware version: Rev 8.2.0.0.233 wlcore: firmware booted (Rev 8.9.0.1.55) On omap4 pandaboard es, trying to connect to a network now produces: wlan0: associated wlan0: deauthenticating from xx:xx:xx:xx:xx:xx by local choice (Reason: 1=UNSPECIFIED)
The pandaboard issue seems to be limited to connecting to another wl12xx machine running hostapd. It seems that Marvell 8787 based machines have not trouble connecting to the wl12xx machine running hostapd, and my pandaboard connects fine to another access point. I get the the above trace for omap5-uevm with all the access points I've tried so far.
On igepv5 board with wl12xx, I can connect to an access point but keep getting these: [ 109.144180] ------------[ cut here ]------------ [ 109.149071] WARNING: CPU: 1 PID: 1610 at drivers/net/wireless/ti/wlcore/main.c:787 wl12xx_que] [ 109.161849] Modules linked in: arc4 wl12xx lib80211 bluetooth joydev input_leds omapfb cfbfil] [ 109.236773] CPU: 1 PID: 1610 Comm: irq/45-wl12xx Tainted: G W 4.7.0-rc1+ #409 [ 109.245435] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 109.251738] [<c0110338>] (unwind_backtrace) from [<c010c3dc>] (show_stack+0x10/0x14) [ 109.259863] [<c010c3dc>] (show_stack) from [<c048152c>] (dump_stack+0xb0/0xe4) [ 109.267432] [<c048152c>] (dump_stack) from [<c0137ba8>] (__warn+0xd8/0x104) [ 109.274744] [<c0137ba8>] (__warn) from [<c0137c84>] (warn_slowpath_null+0x20/0x28) [ 109.282724] [<c0137c84>] (warn_slowpath_null) from [<bf4268ec>] (wl12xx_queue_recovery_work.p) [ 109.294021] [<bf4268ec>] (wl12xx_queue_recovery_work.part.7 [wlcore]) from [<bf426ba0>] (wlco) [ 109.305551] [<bf426ba0>] (wlcore_irq [wlcore]) from [<c019e3c4>] (irq_thread_fn+0x1c/0x34) [ 109.314224] [<c019e3c4>] (irq_thread_fn) from [<c019e6cc>] (irq_thread+0x130/0x1f8) [ 109.322251] [<c019e6cc>] (irq_thread) from [<c015ac78>] (kthread+0xdc/0xf8) [ 109.329563] [<c015ac78>] (kthread) from [<c0107910>] (ret_from_fork+0x14/0x24) [ 109.337179] ---[ end trace e80aaab4abaee961 ]---
(In reply to Tony Lindgren from comment #2) > On igepv5 board with wl12xx, I can connect to an access point but keep > getting these: > > [ 109.144180] ------------[ cut here ]------------ > [ 109.149071] WARNING: CPU: 1 PID: 1610 at > drivers/net/wireless/ti/wlcore/main.c:787 wl12xx_que] That seems to point to recursive recovery prevention logic, I wonder which firmware was used here.
(In reply to Nishanth Menon from comment #3) > (In reply to Tony Lindgren from comment #2) > > On igepv5 board with wl12xx, I can connect to an access point but keep > > getting these: > > > > [ 109.144180] ------------[ cut here ]------------ > > [ 109.149071] WARNING: CPU: 1 PID: 1610 at > > drivers/net/wireless/ti/wlcore/main.c:787 wl12xx_que] > > That seems to point to recursive recovery prevention logic, I wonder which > firmware was used here. I tried to debug that issue a bit more, looks like the igepv5 wl12xx issue is related to spurious or lost GPIO interrupts. The wl18xx issue on omap5-uevm seems like a different issue that's specific to wl18xx. All the firmware here is the latest from linux-firmware git tree.
Can you please provide more details on the board being used and point me to the device-tree file used with it?
(In reply to Guy Mishol from comment #5) > Can you please provide more details on the board being used and point me to > the device-tree file used with it? This is omap4430-pandaboard and omap5 uevm https://eewiki.net/display/linuxonarm/OMAP5432+uEVM and https://en.wikipedia.org/wiki/PandaBoard
Which wilink chip is mounted on the omap5-uevm used here? I see in the .dtsi file that it is set for "ti,wl1271": https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/omap5-board-common.dtsi While it should be set for "ti,wl1835" in case of wilink8
Well the last time I looked at the driver it does not care about the compatible string currently as long as it's one on the list in the driver. I doubt chaning that makes any difference, did you test it?
Hi Tony, You are right about the compatible string. Just looks strange in the .dts file but no harm done. I don't have an omap5-uevm with latest wilink8 hardware assembled on it. Don't think such a board became public. I will try to look for one with a COM8 connector as there are a few that were made in the past but didn't get to production. What board do you have? Is it one with a wilink8 module assembled on it? If it is one of those, there may be issues with it as it has one of the first PG versions of wilink8 that is pre-RTM and latest drivers/firmware may not work ok with it.
(In reply to Eyal Reizer from comment #9) > Hi Tony, > > You are right about the compatible string. > Just looks strange in the .dts file but no harm done. > > I don't have an omap5-uevm with latest wilink8 hardware assembled on it. > Don't think such a board became public. > http://www.ti.com/lit/ug/swcu130/swcu130.pdf "M WL1857 Module – 802.11b/g/n,Bluetooth,NFC" Hmm... https://svtronics.com/5432 claims "Wireless Connectivity Wireless Chipset WiFi not available on this model" Drat - that is very helpful!!!! Grrr...
Is the issue discussed related to AP mode only? In case it is then there is a known regression with latest hostap and there is a fix in the works. In this case it is not related to a specific platform and should be seen on all.
Just for the record (4.7-rc4, also on 4.6) on pandaboard A2 wifi doesn't work at all I have only: [ 1.050354] reg-fixed-voltage wl12xx_vmmc: could not find pctldev for node /ocp/l4@4a000000/scm@100000/pinmux@40/pinmux_wl12xx_gpio, deferring probe [ 3.801940] of_get_named_gpiod_flags: parsed 'gpio' property of node '/wl12xx_vmmc[0]' - status (0) [ 4.160278] vwl1271: disabling
For the omap4-panda, this is probably not working for a LONG time... See this patch-set from 2014 that looks like was never accepted: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276597.html Seems like the kernel is missing the twl6030 32Khz clock driver that is needed for generating the slow clock for the WL6 module on-board. I have manually applied it on 4.7-rc4 (had to massage it a bit) and now wifi is working on an omap4-panda board Rev EA3 that I have here. It didn't work without it. My guess is that there are some u-boot builds that have probably handled it internally using i2c commands for enabling this 32Khz clock.
(In reply to Eyal Reizer from comment #13) > For the omap4-panda, this is probably not working for a LONG time... > > See this patch-set from 2014 that looks like was never accepted: > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276597.html > > Seems like the kernel is missing the twl6030 32Khz clock driver that is > needed for generating the slow clock for the WL6 module on-board. > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt ?
(In reply to Nishanth Menon from comment #14) > (In reply to Eyal Reizer from comment #13) > > For the omap4-panda, this is probably not working for a LONG time... > > > > See this patch-set from 2014 that looks like was never accepted: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276597.html > > > > Seems like the kernel is missing the twl6030 32Khz clock driver that is > > needed for generating the slow clock for the WL6 module on-board. > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/ > Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt ? Nice! was not familiar with this. Did anyone use this bindings with any omap4 based platform? I don't see any palmas related entries in any of the omap4 related device tree files.
(In reply to Eyal Reizer from comment #15) > (In reply to Nishanth Menon from comment #14) > > (In reply to Eyal Reizer from comment #13) > > > For the omap4-panda, this is probably not working for a LONG time... > > > > > > See this patch-set from 2014 that looks like was never accepted: > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276597.html > > > > > > Seems like the kernel is missing the twl6030 32Khz clock driver that is > > > needed for generating the slow clock for the WL6 module on-board. > > > > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/ > > Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt ? > > Nice! was not familiar with this. > Did anyone use this bindings with any omap4 based platform? > I don't see any palmas related entries in any of the omap4 related device > tree files. Yes, you are right, not specific to twl6030, but there seems to be usage in OMAP5 PMIC derivative, it seems https://patchwork.kernel.org/patch/9140589/ if that helps.. also see thread http://www.spinics.net/lists/linux-mmc/msg18140.html
Looks like there are two options here for omap4 users that need wl12xx 1. Use the patch-set I mentioned above to get a clock driver added for twl6030 and use it for wl12xx. 2. switch all omap4 related device tree bindings to use the palmas driver instead of the twl6030. Today is seems like it is somehow broken anyway, not just for wl12xx: See from 4.7-RC4 boot log: root@arm:~# dmesg | grep twl [ 7.403289] twl: not initialized [ 7.406555] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 [ 7.414642] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 [ 7.423461] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 [ 7.431579] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 [ 7.439697] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 [ 7.447784] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 Vs max 1316660 [ 7.455871] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1410000 Vs max 1316660 [ 7.939514] Skipping twl internal clock init and using bootloader value (unknown osc rate)
(In reply to Eyal Reizer from comment #17) > Looks like there are two options here for omap4 users that need wl12xx > 1. Use the patch-set I mentioned above to get a clock driver added for > twl6030 and use it for wl12xx. Looks like a revamp needed for http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276597.html -> @Marek/@Tony anyone? > 2. switch all omap4 related device tree bindings to use the palmas driver > instead of the twl6030. "ALL" Does not make sense to me. "clk" might be sensible. > Today is seems like it is somehow broken anyway, not just for wl12xx: ONLY the opp stuff is broken. That cleanup is pending and a long way off. > See from 4.7-RC4 boot log: > > root@arm:~# dmesg | grep twl > [ 7.403289] twl: not initialized > [ 7.406555] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > Vs max 1316660 > [ 7.414642] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > Vs max 1316660 > [ 7.423461] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > Vs max 1316660 > [ 7.431579] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > Vs max 1316660 > [ 7.439697] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > Vs max 1316660 > [ 7.447784] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > Vs max 1316660 > [ 7.455871] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1410000 > Vs max 1316660 > [ 7.939514] Skipping twl internal clock init and using bootloader value > (unknown osc rate) twl6030 regulator driver is not the same as palmas regulator driver. The issue you mention here is not related to clk requirement you have.
I've tried below patch (but maybe I did something wrong) but wifi still doesn't work: diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index df2e356..17de98c 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -18,6 +18,13 @@ display1 = &hdmi0; }; + mmc5_pwrseq: sdhci0_pwrseq { + compatible = "mmc-pwrseq-simple"; + clocks = <&clk32kg>; + clock-names = "ext_clock"; + }; + + leds: leds { compatible = "gpio-leds"; pinctrl-names = "default"; @@ -388,6 +395,10 @@ vio-supply = <&v1v8>; v2v1-supply = <&v2v1>; enable-active-high; + + clocks = <&clk32kg>; + clock-names = "clk32k"; + }; }; @@ -444,10 +455,12 @@ &mmc5 { pinctrl-names = "default"; pinctrl-0 = <&wl12xx_pins>; + mmc-pwrseq = <&mmc5_pwrseq>; vmmc-supply = <&wl12xx_vmmc>; non-removable; bus-width = <4>; cap-power-off-card; + status = "okay"; #address-cells = <1>; #size-cells = <0>; @@ -541,3 +554,10 @@ }; }; }; + +&twl6040 { + clk32kg: palmas_clk32k@1 { + compatible = "ti,palmas-clk32kg"; + #clock-cells = <0>; + }; +};
(In reply to Nishanth Menon from comment #18) > (In reply to Eyal Reizer from comment #17) > > Looks like there are two options here for omap4 users that need wl12xx > > 1. Use the patch-set I mentioned above to get a clock driver added for > > twl6030 and use it for wl12xx. > Looks like a revamp needed for > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276597.html > -> @Marek/@Tony anyone? I can pick that patches polish them and post again > > > 2. switch all omap4 related device tree bindings to use the palmas driver > > instead of the twl6030. > > "ALL" Does not make sense to me. "clk" might be sensible. > > > Today is seems like it is somehow broken anyway, not just for wl12xx: > > ONLY the opp stuff is broken. That cleanup is pending and a long way off. > > > See from 4.7-RC4 boot log: > > > > root@arm:~# dmesg | grep twl > > [ 7.403289] twl: not initialized > > [ 7.406555] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > > Vs max 1316660 > > [ 7.414642] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > > Vs max 1316660 > > [ 7.423461] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > > Vs max 1316660 > > [ 7.431579] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > > Vs max 1316660 > > [ 7.439697] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > > Vs max 1316660 > > [ 7.447784] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1375000 > > Vs max 1316660 > > [ 7.455871] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for 1410000 > > Vs max 1316660 > > [ 7.939514] Skipping twl internal clock init and using bootloader value > > (unknown osc rate) > > twl6030 regulator driver is not the same as palmas regulator driver. The > issue you mention here is not related to clk requirement you have.
(In reply to Marek Belisko from comment #20) > (In reply to Nishanth Menon from comment #18) > > (In reply to Eyal Reizer from comment #17) > > > Looks like there are two options here for omap4 users that need wl12xx > > > 1. Use the patch-set I mentioned above to get a clock driver added for > > > twl6030 and use it for wl12xx. > > Looks like a revamp needed for > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276597.html > > -> @Marek/@Tony anyone? > I can pick that patches polish them and post again AFAIU it wasn't accepted because 32kHz clokc was enabled by default which some people don't like. Missing part was mmc-pwrseq-simple which I believe will enable clocks properly (maybe we need to add handling of WLAN_EN pin to have startup according specs) > > > > > 2. switch all omap4 related device tree bindings to use the palmas driver > > > instead of the twl6030. > > > > "ALL" Does not make sense to me. "clk" might be sensible. > > > > > Today is seems like it is somehow broken anyway, not just for wl12xx: > > > > ONLY the opp stuff is broken. That cleanup is pending and a long way off. > > > > > See from 4.7-RC4 boot log: > > > > > > root@arm:~# dmesg | grep twl > > > [ 7.403289] twl: not initialized > > > [ 7.406555] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > Vs max 1316660 > > > [ 7.414642] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > Vs max 1316660 > > > [ 7.423461] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > Vs max 1316660 > > > [ 7.431579] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > Vs max 1316660 > > > [ 7.439697] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > Vs max 1316660 > > > [ 7.447784] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > Vs max 1316660 > > > [ 7.455871] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1410000 > > > Vs max 1316660 > > > [ 7.939514] Skipping twl internal clock init and using bootloader > value > > > (unknown osc rate) > > > > twl6030 regulator driver is not the same as palmas regulator driver. The > > issue you mention here is not related to clk requirement you have.
(In reply to Marek Belisko from comment #19) > I've tried below patch (but maybe I did something wrong) but wifi still > doesn't work: > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi > b/arch/arm/boot/dts/omap4-panda-common.dtsi > index df2e356..17de98c 100644 > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi > @@ -18,6 +18,13 @@ > display1 = &hdmi0; > }; > > + mmc5_pwrseq: sdhci0_pwrseq { > + compatible = "mmc-pwrseq-simple"; > + clocks = <&clk32kg>; > + clock-names = "ext_clock"; > + }; > + > + > leds: leds { > compatible = "gpio-leds"; > pinctrl-names = "default"; > @@ -388,6 +395,10 @@ > vio-supply = <&v1v8>; > v2v1-supply = <&v2v1>; > enable-active-high; > + > + clocks = <&clk32kg>; > + clock-names = "clk32k"; > + > }; > }; > > @@ -444,10 +455,12 @@ > &mmc5 { > pinctrl-names = "default"; > pinctrl-0 = <&wl12xx_pins>; > + mmc-pwrseq = <&mmc5_pwrseq>; > vmmc-supply = <&wl12xx_vmmc>; > non-removable; > bus-width = <4>; > cap-power-off-card; > + status = "okay"; > > #address-cells = <1>; > #size-cells = <0>; > @@ -541,3 +554,10 @@ > }; > }; > }; > + > +&twl6040 { > + clk32kg: palmas_clk32k@1 { > + compatible = "ti,palmas-clk32kg"; > + #clock-cells = <0>; > + }; > +}; Don't think this would work. The slow clock is generated by the 6030(PMIC) and not the 6040. The 6030 driver doesn't support clk generation without the patch-set mentioned above.
(In reply to Marek Belisko from comment #21) > (In reply to Marek Belisko from comment #20) > > (In reply to Nishanth Menon from comment #18) > > > (In reply to Eyal Reizer from comment #17) > > > > Looks like there are two options here for omap4 users that need wl12xx > > > > 1. Use the patch-set I mentioned above to get a clock driver added for > > > > twl6030 and use it for wl12xx. > > > Looks like a revamp needed for > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/276597.html > > > -> @Marek/@Tony anyone? > > I can pick that patches polish them and post again > AFAIU it wasn't accepted because 32kHz clokc was enabled by default which > some people don't like. Missing part was mmc-pwrseq-simple which I believe > will enable clocks properly (maybe we need to add handling of WLAN_EN pin to > have startup according specs) There has been a special version of u-boot that enabled this clock by default and this is why it worked. This is not part of mainline u-boot and hence the kernel need to enable it before the MMC is probed. See the following thread that discussed this removal of clock init from u-boot http://www.spinics.net/lists/linux-mmc/msg18140.html > > > > > > > 2. switch all omap4 related device tree bindings to use the palmas > driver > > > > instead of the twl6030. > > > > > > "ALL" Does not make sense to me. "clk" might be sensible. > > > > > > > Today is seems like it is somehow broken anyway, not just for wl12xx: > > > > > > ONLY the opp stuff is broken. That cleanup is pending and a long way off. > > > > > > > See from 4.7-RC4 boot log: > > > > > > > > root@arm:~# dmesg | grep twl > > > > [ 7.403289] twl: not initialized > > > > [ 7.406555] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > > Vs max 1316660 > > > > [ 7.414642] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > > Vs max 1316660 > > > > [ 7.423461] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > > Vs max 1316660 > > > > [ 7.431579] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > > Vs max 1316660 > > > > [ 7.439697] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > > Vs max 1316660 > > > > [ 7.447784] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1375000 > > > > Vs max 1316660 > > > > [ 7.455871] twl6030_uv_to_vsel:OUT OF RANGE! non mapped vsel for > 1410000 > > > > Vs max 1316660 > > > > [ 7.939514] Skipping twl internal clock init and using bootloader > value > > > > (unknown osc rate) > > > > > > twl6030 regulator driver is not the same as palmas regulator driver. The > > > issue you mention here is not related to clk requirement you have.
(In reply to Tony Lindgren from comment #1) > The pandaboard issue seems to be limited to connecting to another wl12xx > machine running hostapd. It seems that Marvell 8787 based machines have not > trouble connecting to the wl12xx machine running hostapd, and my pandaboard > connects fine to another access point. > > I get the the above trace for omap5-uevm with all the access points I've > tried so far. Further the issue with my pandaboard es connecting to another wl12xx running hostapd seems to have been caused by a minimal initramfs missing kernel crypto module ccm.ko. With ccm.ko loaded before connecting, the connection stays up and no longer produces error wlan0: deauthenticating from xx.xx.xx.xx.xx.xx by local choice (Reason: 1=UNSPECIFIED). Some more info on this in a TI thread at: https://e2e.ti.com/support/wireless_connectivity/wilink_wifi_bluetooth/f/307/p/400499/1416993 The omap5-uevm and omap5-igepv5 mysteries still remain for me though.
(In reply to Tony Lindgren from comment #4) > (In reply to Nishanth Menon from comment #3) > > (In reply to Tony Lindgren from comment #2) > > > On igepv5 board with wl12xx, I can connect to an access point but keep > > > getting these: > > > > > > [ 109.144180] ------------[ cut here ]------------ > > > [ 109.149071] WARNING: CPU: 1 PID: 1610 at > > > drivers/net/wireless/ti/wlcore/main.c:787 wl12xx_que] > > > > That seems to point to recursive recovery prevention logic, I wonder which > > firmware was used here. > > I tried to debug that issue a bit more, looks like the igepv5 wl12xx issue > is related to spurious or lost GPIO interrupts. The wl18xx issue on > omap5-uevm seems like a different issue that's specific to wl18xx. > > All the firmware here is the latest from linux-firmware git tree. I think wl12xx on igepv5 now mostly behaves after commit 08f9268b2a2e ("ARM: dts: ARM: dts: Fix omap5 SDIO dat1 interrupt"). Mostly the padconf for SDIO dat1 irq was wrong and gic was used as the interrupt controller for MMC instead of wakeupgen. However, the wl1837 on omap5-uevm does only works for iw dev wlan0 scan. Trying to connect to anything with wpa_supplicant produces the following error multiple times: wlcore: ERROR SW watchdog interrupt received! starting recovery. ... WARNING: CPU: 1 PID: 195 at drivers/net/wireless/ti/wlcore/main.c:796 wl12xx_queue_recovery_work.part.8+0x54/0x5c [wlcore] wlcore: Hardware recovery in progress. FW ver: Rev 8.9.0.0.69 wlcore: pc: 0x521c, hint_sts: 0x00000000 count: 53 wlcore: down ieee80211 phy0: Hardware restart was requested wlan0: send auth to xx... wlcore: PHY firmware version: Rev 8.2.0.0.236 wlcore: firmware booted (Rev 8.9.0.0.69) wlcore: ERROR SW watchdog interrupt received! starting recovery. ... This seems to be a common problem with various devices with wl18xx, just search for for "wlcore: ERROR SW watchdog interrupt received! starting recovery."