Search Linux Wireless

Re: [EXTERNAL] Re: wlcore getting stuck on hikey after the runtime PM autosuspend support change

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

 



On Thu, Dec 13, 2018 at 5:49 AM Reizer, Eyal <eyalr@xxxxxx> wrote:
> > > > I Just tried on an available am335x-evm using 4.20.0-rc1 which I believe
> > has all the patches merged already.
> > > > I am using the same script  and not seeing any failure yet.
> > > > See below:
> > > >
> > > > root@am335x-evm:/usr/share/wl18xx# uname -r
> > > > 4.20.0-rc1-11287-gf487c00
> > > > root@am335x-evm:/usr/share/wl18xx#
> > > > root@am335x-evm:/usr/share/wl18xx#
> > > > root@am335x-evm:/usr/share/wl18xx#
> > > > root@am335x-evm:/usr/share/wl18xx#
> > > > root@am335x-evm:/usr/share/wl18xx# while true; do ifconfig wlan0
> > down; ifconfig wlan0 up; done;
> > > > [1378786.491101] wlcore: down
> > > > [1378787.093006] wlcore: PHY firmware version: Rev 8.2.0.0.242
> > > > [1378787.168523] wlcore: firmware booted (Rev 8.9.0.1.79)
> > > > [1378787.215897] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not
> > ready
> > > ...
> > >
> > > Yeah I was seeing the same yesterday when I tried it.
> > >
> > > Could it be that there needs to be a little msleep() after
> > > loading the firmware on some platforms and before enabling
> > > PM runtime?
> >
> > The issue I'm having seems to happen when trying to load the firmware,
> > getting stuck in mmc_wait_for_req_done -> wait_for_completion, so the
> > firmware is never really fully loaded when the hang happens.
> >
> When the interface is brought up the wlan_renable gpio comes up (enabled) and turning the wl18xx device on.
> It might be that what happens here is that the chip is not yet enabled when the first sdio command is started causing a timeout.
> There is normally a delay associated with the fixed voltage regulator that is tied to this gpio and used for disable/enable (startup-delay-us).

Right, what is not yet clear to me is why we need a longer delay in
the enable path when using the autosuspend patch. I would guess that
the suspend/resume logic in the mmc driver is what causes the extra
delay (in the case of hikey).

> Similar to this:
> / {
>         model = "TI AM335x BeagleBone Black Wireless";
>         compatible = "ti,am335x-bone-black-wireless", "ti,am335x-bone-black", "ti,am335x-bone", "ti,am33xx";
>
>         wlan_en_reg: fixedregulator@2 {
> ...
> ...
>                 startup-delay-us= <70000>;
>
>                 /* WL_EN */
>                 gpio = <&gpio3 9 0>;
>                 enable-active-high;
>         };
> };
>
> Perhaps, as a debug step, try to add a delay in "wl12xx_sdio_power_on":
> https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ti/wlcore/sdio.c
>
> and see if it makes a change?

I tried just increasing WL1271_PRE_POWER_ON_SLEEP from 20ms to 50ms
(which gets used before calling wl12xx_sdio_power_on), and that was
already enough to fix my issues on both hikey and beaglebone black
wireless.

Should we define another pre power on sleep specifically for the sdio
case (and use directly in wl12xx_sdio_power_on)?

Thanks,
-- 
Ricardo Salveti de Araujo



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux