diff mbox

[6/7] net: wireless: wcn36xx: remove powersaving for wcn3620

Message ID 20150118051111.31866.39208.stgit@114-36-241-182.dynamic.hinet.net (mailing list archive)
State Changes Requested
Delegated to: Kalle Valo
Headers show

Commit Message

Andy Green Jan. 18, 2015, 5:11 a.m. UTC 
WCN3620 powersaving mode is not stable.  Disable it if we're
on a wcn3620 chip type.

Signed-off-by: Andy Green <andy.green@linaro.org>
---
 drivers/net/wireless/ath/wcn36xx/main.c |    4 ++++
 1 file changed, 4 insertions(+)


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Bjorn Andersson Feb. 9, 2015, 5:54 p.m. UTC | #1 
On Sat, Jan 17, 2015 at 9:11 PM, Andy Green <andy.green@linaro.org> wrote:
> WCN3620 powersaving mode is not stable.  Disable it if we're
> on a wcn3620 chip type.
>
> Signed-off-by: Andy Green <andy.green@linaro.org>
> ---
>  drivers/net/wireless/ath/wcn36xx/main.c |    4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
> index c4178c7..569d45b 100644
> --- a/drivers/net/wireless/ath/wcn36xx/main.c
> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
> @@ -924,6 +924,10 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>                 IEEE80211_HW_AMPDU_AGGREGATION |
>                 IEEE80211_HW_TIMING_BEACON_ONLY;
>
> +       /* 3620 powersaving currently unstable */
> +       if (wcn->chip_version == WCN36XX_CHIP_3620)
> +               wcn->hw->flags &= ~IEEE80211_HW_SUPPORTS_PS;
> +

Hi Andy,

I have the same problem (Data Abort Exception in wcnss) on 3680, this
with my wip smd code and a hacked up remoteproc-pil. I haven't spent
any effort on debugging this, but it looks like it's something related
to what we have ported to mainline (or lack thereof) rather than a
3620 specific issue.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andy Green Feb. 9, 2015, 9:07 p.m. UTC | #2 
On 10 February 2015 at 01:54, Bjorn Andersson <bjorn@kryo.se> wrote:
> On Sat, Jan 17, 2015 at 9:11 PM, Andy Green <andy.green@linaro.org> wrote:
>> WCN3620 powersaving mode is not stable.  Disable it if we're
>> on a wcn3620 chip type.
>>
>> Signed-off-by: Andy Green <andy.green@linaro.org>
>> ---
>>  drivers/net/wireless/ath/wcn36xx/main.c |    4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
>> index c4178c7..569d45b 100644
>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>> @@ -924,6 +924,10 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>>                 IEEE80211_HW_AMPDU_AGGREGATION |
>>                 IEEE80211_HW_TIMING_BEACON_ONLY;
>>
>> +       /* 3620 powersaving currently unstable */
>> +       if (wcn->chip_version == WCN36XX_CHIP_3620)
>> +               wcn->hw->flags &= ~IEEE80211_HW_SUPPORTS_PS;
>> +
>
> Hi Andy,
>
> I have the same problem (Data Abort Exception in wcnss) on 3680, this
> with my wip smd code and a hacked up remoteproc-pil. I haven't spent
> any effort on debugging this, but it looks like it's something related
> to what we have ported to mainline (or lack thereof) rather than a
> 3620 specific issue.

Makes sense since I only have 3620, I assumed it's related to that.

However he can work for a while with powersaving on, but ping
latencies are +600-800ms and he's shaky.

Later I found something mac80211 generic scan preparation or post-scan
code (for scan initiated by wpa_supplicant) is able to stop wlan
traffic after a few goes even if the actual scan mode smd is not sent.

At that point I think a nice solution would be a donation of time from
guys who specialize in wcn for a living to come and hand out a pony or
two...

-Andy

> Regards,
> Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andy Green Feb. 9, 2015, 9:28 p.m. UTC | #3 
On 10 February 2015 at 05:11, Bjorn Andersson <bjorn@kryo.se> wrote:
> On Feb 9, 2015 1:07 PM, "Andy Green" <andy.green@linaro.org> wrote:
>>
>> On 10 February 2015 at 01:54, Bjorn Andersson <bjorn@kryo.se> wrote:
>> > On Sat, Jan 17, 2015 at 9:11 PM, Andy Green <andy.green@linaro.org>
>> > wrote:
>> >> WCN3620 powersaving mode is not stable.  Disable it if we're
>> >> on a wcn3620 chip type.
>> >>
>> >> Signed-off-by: Andy Green <andy.green@linaro.org>
>> >> ---
>> >>  drivers/net/wireless/ath/wcn36xx/main.c |    4 ++++
>> >>  1 file changed, 4 insertions(+)
>> >>
>> >> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c
>> >> b/drivers/net/wireless/ath/wcn36xx/main.c
>> >> index c4178c7..569d45b 100644
>> >> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>> >> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>> >> @@ -924,6 +924,10 @@ static int wcn36xx_init_ieee80211(struct wcn36xx
>> >> *wcn)
>> >>                 IEEE80211_HW_AMPDU_AGGREGATION |
>> >>                 IEEE80211_HW_TIMING_BEACON_ONLY;
>> >>
>> >> +       /* 3620 powersaving currently unstable */
>> >> +       if (wcn->chip_version == WCN36XX_CHIP_3620)
>> >> +               wcn->hw->flags &= ~IEEE80211_HW_SUPPORTS_PS;
>> >> +
>> >
>> > Hi Andy,
>> >
>> > I have the same problem (Data Abort Exception in wcnss) on 3680, this
>> > with my wip smd code and a hacked up remoteproc-pil. I haven't spent
>> > any effort on debugging this, but it looks like it's something related
>> > to what we have ported to mainline (or lack thereof) rather than a
>> > 3620 specific issue.
>>
>> Makes sense since I only have 3620, I assumed it's related to that.
>>
>> However he can work for a while with powersaving on, but ping
>> latencies are +600-800ms and he's shaky.
>>
>> Later I found something mac80211 generic scan preparation or post-scan
>> code (for scan initiated by wpa_supplicant) is able to stop wlan
>> traffic after a few goes even if the actual scan mode smd is not sent.
>>
>> At that point I think a nice solution would be a donation of time from
>> guys who specialize in wcn for a living to come and hand out a pony or
>> two...
>>
>
> I agree, my goal is that we get this running in mainline (smd, smsm, smp2p
> and remoteproc-tz) so that people with the domain knowledge can go in and
> make it work well.

Sounds great thanks.

I also tried hostapd which is fully workable without encryption, plus
or minus the instabilities mentioned.  But for wpa, he chokes trying
to inject a packet.  So it's another pony needed from somewhere.

Can I ask if smdtty will also appear?  I uplevelled and hacked smdtty
a bit from a 3.10 reference tree for 8916-qrd, and I was able to get
wcn3620 BT working stably for BT keyboard + mouse and even ad2p.

However the hack bound together smdtty ch2 + 3 in smdtty driver and
made it understand about the missing hci protocol byte... this is far
from reasonable for upstream, but it works like the 3.10 except needs
no special bluez / userland treatment.  So I'm curious if no smdtty
how the split smd hci / acl link in firmware will appear coherently to
userspace as a normal uart.

-Andy

> Regards,
> Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bjorn Andersson Feb. 9, 2015, 9:40 p.m. UTC | #4 
On Mon, Feb 9, 2015 at 1:28 PM, Andy Green <andy.green@linaro.org> wrote:
> On 10 February 2015 at 05:11, Bjorn Andersson <bjorn@kryo.se> wrote:
>> On Feb 9, 2015 1:07 PM, "Andy Green" <andy.green@linaro.org> wrote:
>>>
>>> On 10 February 2015 at 01:54, Bjorn Andersson <bjorn@kryo.se> wrote:
>>> > On Sat, Jan 17, 2015 at 9:11 PM, Andy Green <andy.green@linaro.org>
[..]
>>> At that point I think a nice solution would be a donation of time from
>>> guys who specialize in wcn for a living to come and hand out a pony or
>>> two...
>>>
>>
>> I agree, my goal is that we get this running in mainline (smd, smsm, smp2p
>> and remoteproc-tz) so that people with the domain knowledge can go in and
>> make it work well.
>
[..]
>
> Can I ask if smdtty will also appear?  I uplevelled and hacked smdtty
> a bit from a 3.10 reference tree for 8916-qrd, and I was able to get
> wcn3620 BT working stably for BT keyboard + mouse and even ad2p.
>
> However the hack bound together smdtty ch2 + 3 in smdtty driver and
> made it understand about the missing hci protocol byte... this is far
> from reasonable for upstream, but it works like the 3.10 except needs
> no special bluez / userland treatment.  So I'm curious if no smdtty
> how the split smd hci / acl link in firmware will appear coherently to
> userspace as a normal uart.
>

I'm not entirely sure how we're to proceed with this one.

In msm-3.4 with BlueZ the kernel has a driver named hci_smd, that
consumes the two channels and register with the hci core.

In msm-3.10 Qualcomm have dropped this, because they are running
bluedroid which instead consumes the two smd channels in userspace
(through the smd_pkt driver).

We need smd_pkt for modem related matters anyways, so on that we can
run bluedroid and we could bring in hci_smd for use with BlueZ. But
then we would have to configure the kernel based on what stack we want
to run on top.

So we should probably look into userspace and try to consolidate
things there before deciding where to take this.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andy Green Feb. 9, 2015, 10:01 p.m. UTC | #5 
On 10 February 2015 at 05:40, Bjorn Andersson <bjorn@kryo.se> wrote:
> On Mon, Feb 9, 2015 at 1:28 PM, Andy Green <andy.green@linaro.org> wrote:
>> On 10 February 2015 at 05:11, Bjorn Andersson <bjorn@kryo.se> wrote:
>>> On Feb 9, 2015 1:07 PM, "Andy Green" <andy.green@linaro.org> wrote:
>>>>
>>>> On 10 February 2015 at 01:54, Bjorn Andersson <bjorn@kryo.se> wrote:
>>>> > On Sat, Jan 17, 2015 at 9:11 PM, Andy Green <andy.green@linaro.org>
> [..]
>>>> At that point I think a nice solution would be a donation of time from
>>>> guys who specialize in wcn for a living to come and hand out a pony or
>>>> two...
>>>>
>>>
>>> I agree, my goal is that we get this running in mainline (smd, smsm, smp2p
>>> and remoteproc-tz) so that people with the domain knowledge can go in and
>>> make it work well.
>>
> [..]
>>
>> Can I ask if smdtty will also appear?  I uplevelled and hacked smdtty
>> a bit from a 3.10 reference tree for 8916-qrd, and I was able to get
>> wcn3620 BT working stably for BT keyboard + mouse and even ad2p.
>>
>> However the hack bound together smdtty ch2 + 3 in smdtty driver and
>> made it understand about the missing hci protocol byte... this is far
>> from reasonable for upstream, but it works like the 3.10 except needs
>> no special bluez / userland treatment.  So I'm curious if no smdtty
>> how the split smd hci / acl link in firmware will appear coherently to
>> userspace as a normal uart.
>>
>
> I'm not entirely sure how we're to proceed with this one.
>
> In msm-3.4 with BlueZ the kernel has a driver named hci_smd, that
> consumes the two channels and register with the hci core.
>
> In msm-3.10 Qualcomm have dropped this, because they are running
> bluedroid which instead consumes the two smd channels in userspace
> (through the smd_pkt driver).
>
> We need smd_pkt for modem related matters anyways, so on that we can
> run bluedroid and we could bring in hci_smd for use with BlueZ. But
> then we would have to configure the kernel based on what stack we want
> to run on top.
>
> So we should probably look into userspace and try to consolidate
> things there before deciding where to take this.

I understand, although it's a shame to make a whole new protocol in
bluez when it's just the normal protocol with a byte trimmed at the
start of a block.  It can work with stock distro bluez out of the box
if the kernel binds the channels.

The hci_smd thing sounds okay, maybe he can be a module and Android /
bluedroid just doesn't have the module in the rootfs, traditional
Linux gets the module and udev inserts him.

-Andy

> Regards,
> Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
index c4178c7..569d45b 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -924,6 +924,10 @@  static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
 		IEEE80211_HW_AMPDU_AGGREGATION |
 		IEEE80211_HW_TIMING_BEACON_ONLY;
 
+	/* 3620 powersaving currently unstable */
+	if (wcn->chip_version == WCN36XX_CHIP_3620)
+		wcn->hw->flags &= ~IEEE80211_HW_SUPPORTS_PS;
+
 	wcn->hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
 		BIT(NL80211_IFTYPE_AP) |
 		BIT(NL80211_IFTYPE_ADHOC) |