All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Gottschall <s.gottschall@dd-wrt.com>
To: Michal Kazior <michal.kazior@tieto.com>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: Re: QCA9984 VHT160 support
Date: Tue, 17 May 2016 14:22:55 +0200	[thread overview]
Message-ID: <acfe08a2-31f6-e9e4-2785-9cad15d457b0@dd-wrt.com> (raw)
In-Reply-To: <CA+BoTQnopmxAQaWCyNvy20uWB65F=pMcoQ9Pz4LNWo3VGBMpHg@mail.gmail.com>

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@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@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@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  reply	other threads:[~2016-05-17 12:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10  6:11 Setting per-frame tx rate for frames injected in raw tx mode Raj Joshi
2016-05-10 16:28 ` Ben Greear
2016-05-11  6:41   ` Raj Joshi
2016-05-11 16:13     ` Ben Greear
2016-05-15  2:40       ` Raj Joshi
2016-05-15 15:17         ` Ben Greear
2016-05-15 17:15           ` Ben Greear
2016-05-17  7:14             ` Raj Joshi
2016-05-17  7:36               ` Michal Kazior
2016-05-17  7:43               ` Valo, Kalle
2016-05-17 11:43                 ` QCA9984 VHT160 support Sebastian Gottschall
2016-05-17 12:00                   ` Michal Kazior
     [not found]                     ` <4e407b2c-29f9-3c74-ea94-4206632441c3@dd-wrt.com>
2016-05-17 12:18                       ` Michal Kazior
2016-05-17 12:22                         ` Sebastian Gottschall [this message]
2016-05-17 12:35                           ` Sebastian Gottschall
2016-05-17 13:20                     ` Valo, Kalle
2016-09-14 10:37                   ` Valo, Kalle
2016-09-14 14:38                     ` Sebastian Gottschall
2016-09-14 14:44                       ` Valo, Kalle
2016-09-16  7:51                         ` [PATCH] " Sebastian Gottschall
2016-09-17  6:21                           ` unusual event Sebastian Gottschall
2016-10-10 16:04                           ` [PATCH] QCA9984 VHT160 support Valo, Kalle
2016-10-10 16:06                             ` Valo, Kalle
2016-10-11  1:30                               ` Sebastian Gottschall
2016-10-14 10:06                                 ` Valo, Kalle
2016-10-14 10:14                           ` Valo, Kalle
2016-10-18  8:20                             ` Sebastian Gottschall
2016-10-18  9:16                               ` Sebastian Gottschall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acfe08a2-31f6-e9e4-2785-9cad15d457b0@dd-wrt.com \
    --to=s.gottschall@dd-wrt.com \
    --cc=ath10k@lists.infradead.org \
    --cc=michal.kazior@tieto.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.