QCA9984 VHT160 support

[Sebastian Gottschall]

Am 17.05.2016 um 14:18 schrieb Michal Kazior:
> + re-adding ath10k list
>
>
> On 17 May 2016 at 14:05, Sebastian Gottschall <s.gottschall at dd-wrt.com> wrote:
>> Am 17.05.2016 um 14:00 schrieb Michal Kazior:
>>> On 17 May 2016 at 13:43, Sebastian Gottschall <s.gottschall at dd-wrt.com> wrote:
>>>> Attached you will find a testing patch for VHT160 support. i tested it today
>>>> on a QCA9984 device and it seems to work.
>>>> feel free to make any corrections
>>> Hi,
>>>
>>> Send patches inline, please. Preferably via git send-email. It's a lot
>>> easier to review them this way.
>> unfortunaty i dont work with git right now and i wanted to send it to
>> the list first for getting comments.
>> since the patch is also very small, it should be that complicated
>>>   From a quick glance vht capabilities setup looks weird:
>>>
>>>> if (ar->vht_cap_info &  IEEE80211_VHT_CAP_SHORT_GI_160) {
>>>>     vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
>>>>     vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ;
>>>> }
>>> Why? Is this really necessary?
>> the firmware does not report correct flags. just SHORT_GI_160.
>> i reviewed the firmware sourcecodes and found out that this is maybe a
>> misstake of the QCA developers.
>> so we need to add the 160MHZ support flags locally using the
>> SHORT_GI_160 which is always set on QCA9984.
>> otherwise mac80211 will not be capable of running vht160.
> I'm not sure if SGI160 implies 80+80.
according to the firmware sourcecode of 9984 it seems so. thats the only 
information source i have
>
>
>>> I would expect IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ and
>>> IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160_80PLUS80MHZ to be already set in
>>> ar->vht_cap_info if the chip supports 160 or 80+80.
>> me too. but it isnt :-)
> Sigh. A comment explaining that would be really nice.
there is no comment available. the only information source is the 
firmware sourcecode for the 9984 which i reviewed.
let me give you a small snippet
#if defined(CONFIG_160MHZ_SUPPORT)
#define VHT_CAP_WITH_STBC_1SS_VHT160 ((VHT_CAP_WITH_STBC_1SS) | 
(WMI_VHT_CAP_SGI_160MHZ))
#define VHT_CAP_WITH_STBC_2SS_VHT160 ((VHT_CAP_WITH_STBC_2SS) | 
(WMI_VHT_CAP_SGI_160MHZ))
#define VHT_CAP_WITH_STBC_3SS_VHT160 ((VHT_CAP_WITH_STBC_3SS) | 
(WMI_VHT_CAP_SGI_160MHZ))
#endif
#if defined(CONFIG_160MHZ_SUPPORT)
     dev_info->vht_cap_info  = VHT_CAP_WITH_STBC_1SS_VHT160;
#else
     dev_info->vht_cap_info  = VHT_CAP_WITH_STBC_1SS_VHT80;
#endif


so the firmware simply does not set the correct flags. thats all.
>
>
>>> You also don't seem to handle 80+80 because you just as phymode to 160
>>> regardless of center frequencies:
>>>
>>>> !ath10k_peer_assoc_h_vht_masked(vht_mcs_mask)) {
>>>>      if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
>>>>        phymode = MODE_11AC_VHT80;
>>>>      else if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
>>>>        phymode = MODE_11AC_VHT160;
>>>>      else if (sta->bandwidth == IEEE80211_STA_RX_BW_40)
>>>>        phymode = MODE_11AC_VHT40;
>>>>      else if (sta->bandwidth == IEEE80211_STA_RX_BW_20)
>> there is no 80+80 STA_RX_BW flag. i dont know how to handle this. and
>> yes, just 160 mhz is tested right now. right now it looks like mac80211
>> is not 80+80 ready.
> Hmm.. I wouldn't advertise 80+80 support then. All the more since
> there's no way of telling whether hw/fw actually supports it in the
> first place.
we can leave it out at the end, but the firmware seem to support it. so 
far i just tested 160 in ap mode yet, but found other
things in ath10k which need to be fixed. i'm on it right now
>
>
> Michal
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565