RE: [EXTERNAL] Re: [RFT 3/6] wlcore: Add support for runtime PM

> >This happens on runtime_suspend() where we are already in PLT > >and then that error gets stored and then next pm_runtime_get() > >returns -EINVAL. The patch below should fix it. I'll fold it > i>nto the runtime PM related patch assuming it works for you. > > > >Regards, > > > >Tony > > > >8<

RE: [EXTERNAL] Re: [RFT 3/6] wlcore: Add support for runtime PM

>> However, trying a wl1281 module and enabling PLT mode it boots ok but after >> a couple of seconds the below crash is seen. >> Seems like a similar crash to the one I have seen before,right? > >Sorry for the delay, only today had enough time to figure >this one out, see below. > >> sh-4.4#

RE: [EXTERNAL] Re: [RFT 3/6] wlcore: Add support for runtime PM

> > * Tony Lindgren [180605 04:22]: > > > * Reizer, Eyal [180603 06:07]: > > > > I have noticed the following recovery a couple of times on my setup > > when the board was > > > > just sitting for a long time with just pings > > > > It s

RE: [EXTERNAL] Re: [RFT 3/6] wlcore: Add support for runtime PM

> > * Tony Lindgren [180605 04:22]: > > * Reizer, Eyal [180603 06:07]: > > > I have noticed the following recovery a couple of times on my setup > when the board was > > > just sitting for a long time with just pings > > > It starts with a firmware r

RE: [EXTERNAL] Re: [RFT 3/6] wlcore: Add support for runtime PM

> > * Tony Lindgren [180529 18:09]: > > --- a/drivers/net/wireless/ti/wlcore/main.c > > +++ b/drivers/net/wireless/ti/wlcore/main.c > ... > > +static int __maybe_unused wlcore_runtime_resume(struct device *dev) > > +{ > > + struct wl1271 *wl = dev_get_drvdata(dev); > > +

Re: [RFT 6/6] wlcore: Use generic runtime pm calls for wowlan elp configuration

> > > > > > With runtime PM enabled, we can now use generic calls to > > > pm_generic_runtime_suspend and pm_generic_runtime_resume for > enabling elp > > > during suspend when wowlan is enabled and waking the chip from elp > > > on resume. > > > > Sry, but not sure you can :( > > > > These

RE: [EXTERNAL] Re: [PATCH] wlcore: sdio: check for valid platform device data before suspend

> > the wl pointer can be null In case only wlcore_sdio is probed while > > no WiLink module is successfully probed, as in the case of mounting a > > wl12xx module while using a device tree file configured with wl18xx > > related settings. > > In this case the system was crashing in

RE: [EXTERNAL] Re: [PATCH] wlcore: use generic runtime pm calls for wowlan elp configuration

> > > With runtime PM enabled, we can now use generic calls to > > pm_generic_runtime_suspend and pm_generic_runtime_resume for > enabling elp > > during suspend when wowlan is enabled and waking the chip from elp > > on resume. > > remove the custom API that was used to ensure that the command >

RE: [PATCHv2 0/5] Runtime PM support for wlcore

> > > > > Here's a modified version of your patch, does that put wlcore to > > idle with wowlan during suspend for you? > > > > Still no joy. > It suspends/resumes ok but leaves the firmware disabled from entering ELP. Spent some time on it today and looks like adding calls to

RE: [EXTERNAL] [PATCHv2 0/5] Runtime PM support for wlcore

> > Here's a modified version of your patch, does that put wlcore to > idle with wowlan during suspend for you? > Still no joy. It suspends/resumes ok but leaves the firmware disabled from entering ELP. You can see the log below with some prints added to wlcore_runtime_suspend() And

RE: [EXTERNAL] [PATCHv2 0/5] Runtime PM support for wlcore

> > > > > > OK try replacing the pm_runtime_put_noidle() above with just > > > pm_runtime_put_sync(). The reason why I put noidle there was the > > > wlcore_fw_sleep() call, with that gone put_sync should do the trick. > > > > > > > I have tried that already. Same problem. The last call to: > >

RE: [EXTERNAL] [PATCHv2 0/5] Runtime PM support for wlcore

> > * Reizer, Eyal <ey...@ti.com> [180522 13:28]: > > Actually the below patch removing the call to wlcore_fw_sleep() avoids this > error. > > The downside is that the wl8 firmware remains fully active during supend, so > we > > Would need to find the r

RE: [EXTERNAL] [PATCHv2 0/5] Runtime PM support for wlcore

> > > > 8< > > diff --git a/drivers/net/wireless/ti/wlcore/main.c > > b/drivers/net/wireless/ti/wlcore/main.c > > --- a/drivers/net/wireless/ti/wlcore/main.c > > +++ b/drivers/net/wireless/ti/wlcore/main.c > > @@ -1867,8 +1867,6 @@ static int __maybe_unused > >

RE: [EXTERNAL] [PATCHv2 0/5] Runtime PM support for wlcore

> > > > This warning is because wlcore is wlcore is still in ELP. This is > > somehow possible even though we call pm_runtime_get_sync() in > > wl1271_op_resume(). Anyways, I'll try to reproduce it here. > > Sorry I can't somehow get my beagleboard to wake-up from suspend, > I'm almost certain

RE: [EXTERNAL] [PATCHv2 0/5] Runtime PM support for wlcore

Hi Tony, > > Hi all, > > Here's a series of patches to add runtime PM support for wlcore. It does not > yet implement autosuspend support, but let's get this tested first as the > autosuspend can mask enable/disable issues easily. > > Regards, > > Tony > > Changes since v1: > > - Fix issues

RE: [EXTERNAL] Re: [PATCH v2] wlcore: sdio: allow pm to handle sdio power

> > >> > >> > pm_runtime handles sdio power on and power off transitions. > >> > An old workaround for trying to control the power explicitly from the > >> > driver was in fact causing failures on suspend/resume as the mmc layer > >> > already power the module on resume. > >> > > >> > In case of

RE: [EXTERNAL] Re: [PATCH v2] wlcore: sdio: allow pm to handle sdio power

> > > pm_runtime handles sdio power on and power off transitions. > > An old workaround for trying to control the power explicitly from the > > driver was in fact causing failures on suspend/resume as the mmc layer > > already power the module on resume. > > > > In case of resume pm_runtime_get

[PATCH] wlcore: allow elp during wowlan suspend

when enabling wowlan and entering suspend the last write to the firmware allowing it to go into elp mode was not completing before suspend, leaving the firmware running in full active mode consuming high power. Use an immediate call instead of a work queue for this last access allowing the

RE: wl1837: poor performance?

Hi Russel, > -Original Message- > From: Russell King - ARM Linux [mailto:li...@armlinux.org.uk] > Sent: Saturday, October 14, 2017 2:30 PM > To: Reizer, Eyal > Cc: linux-wireless@vger.kernel.org; Altshul, Maxim; Narang, Saurabh > Subject: Re: wl1837: poor performance? &

[v9] wlcore: add missing nvs file name info for wilink8

The following commits: commit c815fdebef44 ("wlcore: spi: Populate config firmware data") commit d776fc86b82f ("wlcore: sdio: Populate config firmware data") Populated the nvs entry for wilink6 and wilink7 only while it is still needed for wilink8 as well. This broke user space backward

[v8] wlcore: add missing nvs file name info for wilink8

The following commits: commit c815fdebef44 ("wlcore: spi: Populate config firmware data") commit d776fc86b82f ("wlcore: sdio: Populate config firmware data") Populated the nvs entry for wilink6 and wilink7 only while it is still needed for wilink8 as well. This broke user space backward

RE: [v7 wlcore: add missing nvs file name info for wilink8

> > > > + if (oui_addr == 0xdeadbe && nic_addr == 0xef) { > > + wl1271_warning("Detected unconfigured mac address in > nvs.\n" > > + "derive from fuse instead.\n" > > + "in case of using a wl12xx device, your " > > +

[v7 wlcore: add missing nvs file name info for wilink8

The following commits: commit c815fdebef44 ("wlcore: spi: Populate config firmware data") commit d776fc86b82f ("wlcore: sdio: Populate config firmware data") Populated the nvs entry for wilink6 and wilink7 only while it is still needed for wilink8 as well. This broke user space backward

RE: [v6] wlcore: add missing nvs file name info for wilink8

> > > > > > > > > > Sure, just want to make sure we are not trying to add work around just > for > > > A couple of faulty devices. > > > > > > > > I have verified using a couple of com6 modules with an am335x-evm > and > > > > they had mac addresses read ok. > > > > > > > > Sounds like there are

RE: [v6] wlcore: add missing nvs file name info for wilink8

> > > > Sure, just want to make sure we are not trying to add work around just for > A couple of faulty devices. > > > > I have verified using a couple of com6 modules with an am335x-evm and > > they had mac addresses read ok. > > > > Sounds like there are multiple variants of the wl12xx > >

RE: [v6] wlcore: add missing nvs file name info for wilink8

> > >> The fact that is old does not change a thing, we still need to > >> support it no matter what the data sheet and your system design > >> says. A fix that breaks other things is not really a fix :) > >> > > > > Sure, just want to make sure we are not trying to add work around just for > > A

RE: [v6] wlcore: add missing nvs file name info for wilink8

> > On Thu, Aug 10, 2017 at 4:35 PM, Reizer, Eyal <ey...@ti.com> wrote: > >> > > >> > Sorry for top posting (mobile...) > >> > I have verified with system design and the data sheet that every wilink > 6/7 > >> chip has a mac address in

RE: [v6] wlcore: add missing nvs file name info for wilink8

> > > > Sorry for top posting (mobile...) > > I have verified with system design and the data sheet that every wilink 6/7 > chip has a mac address in fuse so probably the board you have (pretty old, > right?) has this mac address in fuse. Maybe it was from very early batches? > Anyway I see no

[v6] wlcore: add missing nvs file name info for wilink8

The following commits: commit c815fdebef44 ("wlcore: spi: Populate config firmware data") commit d776fc86b82f ("wlcore: sdio: Populate config firmware data") Populated the nvs entry for wilink6 and wilink7 only while it is still needed for wilink8 as well for specifying an alternate mac address.

RE: [v5] wlcore: add missing nvs file name info for wilink8

> > > Subject: Re: [v5] wlcore: add missing nvs file name info for wilink8 > > > > * Reizer, Eyal <ey...@ti.com> [170807 00:47]: > > > Hi Tony, > > > > > > > > * Reizer, Eyal <ey...@ti.com> [170807 00:32]: > > > > &g

RE: [v5] wlcore: add missing nvs file name info for wilink8

> Subject: Re: [v5] wlcore: add missing nvs file name info for wilink8 > > * Reizer, Eyal <ey...@ti.com> [170807 00:47]: > > Hi Tony, > > > > > > * Reizer, Eyal <ey...@ti.com> [170807 00:32]: > > > > The following commits: > > > &g

RE: [v5] wlcore: add missing nvs file name info for wilink8

Hi Tony, > > * Reizer, Eyal <ey...@ti.com> [170807 00:32]: > > The following commits: > > c815fde wlcore: spi: Populate config firmware data > > d776fc8 wlcore: sdio: Populate config firmware data > > > > Populated the nvs entry for wilink6 and

RE: [v4] wlcore: add missing nvs file name info for wilink8

> -Original Message- > From: Julian Calaby [mailto:julian.cal...@gmail.com] > Sent: Saturday, August 5, 2017 8:51 AM > To: Reizer, Eyal > Cc: Kalle Valo; ,Tony Lindgren; linux-wireless@vger.kernel.org; linux- > ker...@vger.kernel.org; sebastian.reic...@collabora.co.uk

[v4] wlcore: add missing nvs file name info for wilink8

The following commits: c815fde wlcore: spi: Populate config firmware data d776fc8 wlcore: sdio: Populate config firmware data Populated the nvs entry for wilink6 and wilink7 only while it is still needed for wilink8 as well. This broke user space backward compatibility when upgrading from older

RE: [v3] wl18xx: add missing nvs file name info for wilink8

Please ignore this patch. Wrong header. Submitted the correct one instead: https://patchwork.kernel.org/patch/9854809/ > -Original Message- > From: Reizer, Eyal > Sent: Thursday, July 20, 2017 3:13 PM > To: 'Kalle Valo'; ',Tony Lindgren'; 'linux-wireless@vger.kernel.org'; '

[v3] wlcore: add missing nvs file name info for wilink8

The following commits: c815fde wlcore: spi: Populate config firmware data d776fc8 wlcore: sdio: Populate config firmware data Populated the nvs entry for wilink6 and wilink7 only while it is still needed for wilink8 as well. This broke user space backward compatibility when upgrading from older

RE: [v3] wl18xx: add missing nvs file name info for wilink8

> The following commits: > c815fde wlcore: spi: Populate config firmware data > d776fc8 wlcore: sdio: Populate config firmware data > > Populated the nvs entry for wilink6 and wilink7 only while it is > still needed for wilink8 as well. > This broke user space backward compatibility when

[v3] wl18xx: add missing nvs file name info for wilink8

The following commits: c815fde wlcore: spi: Populate config firmware data d776fc8 wlcore: sdio: Populate config firmware data Populated the nvs entry for wilink6 and wilink7 only while it is still needed for wilink8 as well. This broke user space backward compatibility when upgrading from older

RE: [PATCH] wlcore: add missing nvs file name info for wilink8

> > > > On Wed, Jul 05, 2017 at 01:06:54AM -0700, Tony Lindgren wrote: > > > > > Not sure if this really is a regression as we've always had a bogus > > > > > wl1271-nvs.bin in linux-firmware.git. Sure would be nice to fix it, > > > > > but going back to using a generic wl1271-nvs.bin sure does

RE: [v2] wlcore: add missing nvs file name info for wilink8

Hi Tony, > > When working with wl18xx the nvs file is used for defining an alternate > > mac address and override the default mac address that is stored inside > > the wl18xx chip. > > > > The following commits: > > c815fde wlcore: spi: Populate config firmware data > > d776fc8 wlcore: sdio:

RE: [PATCH] wlcore: add missing nvs file name info for wilink8

Hi Tony, > > * Kalle Valo <kv...@codeaurora.org> [170703 04:30]: > > "Reizer, Eyal" <ey...@ti.com> writes: > > > > > When working with wl18xx the nvs file is used for defining an alternate > > > mac address and override the defau

[v2] wlcore: add missing nvs file name info for wilink8

When working with wl18xx the nvs file is used for defining an alternate mac address and override the default mac address that is stored inside the wl18xx chip. The following commits: c815fde wlcore: spi: Populate config firmware data d776fc8 wlcore: sdio: Populate config firmware data Populated

[PATCH] wlcore: add missing nvs file name info for wilink8

When working with wl18xx the nvs file is used for defining an alternate mac address and override the default mac address that is stored inside the wl18xx chip. update the structure field with the same default nvs file name that has been used in the past, otherwise userspace backward compatibility

[PATCH] wlcore: spi: fix build warning caused by redundant variable

The ret variable is unused in wlcore_probe_of() Remove it for fixing build warning. Fixes: 01efe65aba65 ("wlcore: spi: add wl18xx support") Signed-off-by: Eyal Reizer --- drivers/net/wireless/ti/wlcore/spi.c | 1 - 1 file changed, 1 deletion(-) diff --git

RE: [PATCHv8] wlcore: spi: add wl18xx support

> > > Add support for using with both wl12xx and wl18xx. > > > > - all wilink family needs special init command for entering wspi mode. > > extra clock cycles should be sent after the spi init command while the > > cs pin is high. > > - Use inverted chip select for sending a dummy 4 bytes

[PATCHv8] wlcore: spi: add wl18xx support

Add support for using with both wl12xx and wl18xx. - all wilink family needs special init command for entering wspi mode. extra clock cycles should be sent after the spi init command while the cs pin is high. - Use inverted chip select for sending a dummy 4 bytes command that completes the

RE: linux-next: build warning after merge of the wireless-drivers-next tree

Hi Stephen, > > After merging the wireless-drivers-next tree, today's linux-next build > (x86_64 allmodconfig) produced this warning: > > drivers/net/wireless/ti/wlcore/spi.c: In function 'wlcore_probe_of': > drivers/net/wireless/ti/wlcore/spi.c:457:6: warning: unused variable 'ret' [- >

RE: [PATCH v7] wlcore: spi: add wl18xx support

> > From: Eyal Reizer > > > > Add support for using with both wl12xx and wl18xx. > > > > - all wilink family needs special init command for entering wspi mode. > > extra clock cycles should be sent after the spi init command while the > > cs pin is high. > > - Use

[PATCH v6] wlcore: spi: add wl18xx support

Add support for using with both wl12xx and wl18xx. - all wilink family needs special init command for entering wspi mode. extra clock cycles should be sent after the spi init command while the cs pin is high. - Use inverted chip select for sending a dummy 4 bytes command that completes the

[PATCH v5] wlcore: spi: add wl18xx support

Add support for using with both wl12xx and wl18xx. - all wilink family needs special init command for entering wspi mode. extra clock cycles should be sent after the spi init command while the cs pin is high. - Use inverted chip select for sending a dummy 4 bytes command that completes the

[PATCH v5] wlcore: spi: add wl18xx support

Add support for using with both wl12xx and wl18xx. - all wilink family needs special init command for entering wspi mode. extra clock cycles should be sent after the spi init command while the cs pin is high. - Use inverted chip select for sending a dummy 4 bytes command that completes the

[PATCH v4] wlcore: spi: add wl18xx support

Add support for using with both wl12xx and wl18xx. - all wilink family needs special init command for entering wspi mode. extra clock cycles should be sent after the spi init command while the cs pin is high. - Use inverted chip select for sending a dummy 4 bytes command that completes the

RE: [PATCHv3] wlcore: spi: add wl18xx support

> > > > - all wilink family needs special init command for entering wspi mode. > > extra clock cycles should be sent after the spi init command while the > > cs pin is high. > > - Use inverted chip select for sending a dummy 4 bytes command that > > completes the init stage and puts the

[PATCHv3] wlcore: spi: add wl18xx support

Add support for using with both wl12xx and wl18xx. - all wilink family needs special init command for entering wspi mode. extra clock cycles should be sent after the spi init command while the cs pin is high. - Use inverted chip select for sending a dummy 4 bytes command that completes the

RE: [PATCHv2] wlcore: spi: add wl18xx support

> > > Thanks! Glad the illustration helped. > > I will try it out again as if i recall cotrectly, i did try that l, and it > > didnt produce > the correct waveform, but perhaps i didnt understand the usage of > .cs_change correctly. > > Will double check anyway. > > It could also be a bug in

RE: [PATCHv2] wlcore: spi: add wl18xx support

> > > > It is also part of the generic spi.h (include/Linux/spi/spi.h), > > > > already part of " struct spi_device" So it seemed redundant adding > > > > another mechanism for implementing the same. > > > > Platform that interact with a wilink need to use it, and platforms > > > > that don't have

RE: [PATCHv2] wlcore: spi: add wl18xx support

Arnd, > > > > > > > > - all wilink family needs special init command for entering wspi mode. > > > > extra clock cycles should be sent after the spi init command while the > > > > cs pin is high. > > > > - switch to controling the cs pin from the spi driver for achieveing the > > > > above.

RE: [PATCHv2] wlcore: spi: add wl18xx support

> > > > - all wilink family needs special init command for entering wspi mode. > > extra clock cycles should be sent after the spi init command while the > > cs pin is high. > > - switch to controling the cs pin from the spi driver for achieveing the > > above. > > - the selected cs gpio is

[PATCHv2] wlcore: spi: add wl18xx support

Add support for using with both wl12xx and wl18xx. - all wilink family needs special init command for entering wspi mode. extra clock cycles should be sent after the spi init command while the cs pin is high. - switch to controling the cs pin from the spi driver for achieveing the above. -

RE: [PATCH] wlcore: spi: add wl18xx support

> -Original Message- > From: Kalle Valo [mailto:kv...@codeaurora.org] > Sent: Thursday, April 07, 2016 3:25 PM > To: Eyal Reizer > Cc: linux-wireless@vger.kernel.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org; Reizer, Eyal; devicet...@vger.kernel.org >

RE: [PATCH] wlcore: spi: add wl18xx support

Ping on this patch > -Original Message- > From: Eyal Reizer [mailto:eyalrei...@gmail.com] > Sent: Wednesday, March 30, 2016 4:07 PM > To: kv...@codeaurora.org; linux-wireless@vger.kernel.org; > net...@vger.kernel.org; linux-ker...@vger.kernel.org > Cc: Reizer, Eyal