On 10 February 2015 at 05:11, Bjorn Andersson <bjorn@xxxxxxx> wrote: > On Feb 9, 2015 1:07 PM, "Andy Green" <andy.green@xxxxxxxxxx> wrote: >> >> On 10 February 2015 at 01:54, Bjorn Andersson <bjorn@xxxxxxx> wrote: >> > On Sat, Jan 17, 2015 at 9:11 PM, Andy Green <andy.green@xxxxxxxxxx> >> > wrote: >> >> WCN3620 powersaving mode is not stable. Disable it if we're >> >> on a wcn3620 chip type. >> >> >> >> Signed-off-by: Andy Green <andy.green@xxxxxxxxxx> >> >> --- >> >> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
