1. 27 Apr, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: implement more versatile set_bitrate_mask · 45c9abc0
      Michal Kazior authored
      Until now only a single fixed tx rate or nss was
      allowed to be set.
      
      The patch attempts to improve this by allowing
      most bitrate masks. The limitation is VHT MCS
      rates cannot be expressed separately using
      existing firmware interfaces and only the
      following VHT MCS ranges are supported: none, 0-7,
      0-8, and 0-9.
      
      This keeps the old behaviour when requesting
      single tx rate or single nss. The new bitrate mask
      logic is only applied to other cases that would
      return -EINVAL until now.
      
      Depending on firmware revisions some combinations
      may crash firmware so use with care, please.
      
      This depends on "ath10k: don't use reassoc flag".
      Without it key cache would effectively be
      invalidated upon bitrate change leading to
      communication being no longer possible.
      
      These work:
      
        iw wlan0 set bitrates legacy-5 6 12 ht-mcs-5 1 2 3
        iw wlan0 set bitrates legacy-5 ht-mcs-5 7 8 9
        iw wlan0 set bitrates legacy-5 24 ht-mcs-5 vht-mcs-5 1:0-9
      
      These won't work:
      
        iw wlan0 set bitrates legacy-5 ht-mcs-5 vht-mcs-5 1:0-5
        iw wlan0 set bitrates vht-mcs-5 2:7-9
      
      (note the invalid VHT MCS ranges)
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      45c9abc0
  2. 21 Apr, 2015 3 commits
    • Michal Kazior's avatar
      ath10k: fix qca61x4 hw2.1 support · 11a002ef
      Michal Kazior authored
      During initialization firmware does some sort of
      memory switch between DRAM and IRAM. If
      configuration value for bank switching isn't
      correct device crashes during init.
      
      The new value prevents firmware 11.0.0.302 (and
      possibly others) for qca61x4 hw2.1 from crashing
      during init.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      11a002ef
    • Michal Kazior's avatar
      ath10k: allow loading device specific board files · de57e2c8
      Michal Kazior authored
      Some devices differ slightly and require different
      board files. If wrong board data is used they
      crash or behave incorrectly.
      
      These devices can be differentiated by looking at
      PCI subsystem device id. That is the case for
      qca61x4 devices at least.
      
      The board specific filename is constructed as:
      
       board-<bus>-<id>.bin
      
      For PCI in particular it is:
      
       board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin
      
      These files are looked in device/hw specific
      directories. Hence for Killer 1525 (qca6174 hw2.1)
      ath10k will request:
      
        /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin
      
      To not break any existing setups (e.g. in case
      some devices in the wild already have subsys ids)
      if a board specific file isn't found a generic one
      is used which is the one which would be used until
      now. This guarantees that after upgrading a driver
      device will not suddenly stop working due to
      now-missing specific board file. If this is the
      case a "fallback" string is appended to the info
      string when driver boots.
      
      Keep in mind this is distinct from cal-pci-*.bin
      files which contain full calibration data and MAC
      address. Cal data is aimed at systems where
      calibration data is stored out of band, e.g. on
      nand flash instead of device EEPROM - an approach
      taken by some AP/router vendors.
      
      Board files are more of a template and needs some
      bits to be filled in by the OTP program using
      device EEPROM contents.
      
      One could argue to map subsystem ids to some board
      design codename strings instead of using raw ids
      when building the board filename. Using a mapping
      however would make it a lot more cumbersome and
      time consuming (due to how patches propagate over
      various kernel trees) to add support for some new
      device board designs. Adding a board file is a lot
      quicker and doesn't require recompilation.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      de57e2c8
    • Michal Kazior's avatar
      ath10k: share board file loading code across FW APIs · d0ed74f3
      Michal Kazior authored
      There's no need to implement the same thing twice.
      Reduce code duplication.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      d0ed74f3
  3. 17 Apr, 2015 10 commits
  4. 15 Apr, 2015 5 commits
    • Peter Oh's avatar
      ath: lower JP W53 band DFS detection threshold around 30% · 26bea13a
      Peter Oh authored
      Japan's W53 band requires 50% data traffic during its DFS test,
      but WLAN baseband used by ath9k and ath10k is not able to achieve
      current threshold rate, 50%, under the data traffic rate.
      In other words, HW occasionally fails detecting radar pulses,
      so that SW cannot get enough radar reports to achieve the rate.
      Signed-off-by: default avatarPeter Oh <poh@qca.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      26bea13a
    • Peter Oh's avatar
      ath: define JP DFS patterns separated from FCC · cb3fbd63
      Peter Oh authored
      Separate Japan's DFS pattern from FCC to control PPB threshold.
      
      Currently all the radar detectors use the same threshold rate at
      50%, but it's not able to achieve if data traffic rate is higher
      than 40% because WLAN baseband used by ath9k and ath10k often fails
      detecting radar pulses, so that SW cannot get enough radar reports
      to achieve the rate.
      
      Since Japan's W53 band requires 50% data traffic during its DFS
      test we need to apply different threshold rate than others on it.
      Hence define its own pattern to give flexibility to threshold rate.
      Signed-off-by: default avatarPeter Oh <poh@qca.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      cb3fbd63
    • Michal Kazior's avatar
      ath10k: use scan burst for hw roc · dbd3f9f3
      Michal Kazior authored
      This improves chances of getting onto a foreign
      channel and thus makes P2P a bit more reliable.
      
      Without scan burst it was possible for firmware to
      not switch to foreign channel resulting in "failed
      to switch to channel for roc scan" warning. This
      would also effectively fail some offchan tx
      requests and lead to P2P find/connect taking
      longer. This could be observed when other vifs
      were running/busy, e.g. with P2P GO.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      dbd3f9f3
    • Michal Kazior's avatar
      ath10k: fix hw roc expiration · fcf98446
      Michal Kazior authored
      It is not guaranteed firmware will switch to
      foreign channel immediately after starting scan
      sequence. To account for that don't use duration
      parameter for scan time. Instead request insanely
      long scan and use timeout worker to cancel it from
      driver.
      
      This should improve P2P reliability a bit.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      fcf98446
    • Peter Oh's avatar
      ath: support new FCC DFS Radar Type 1 · 694c0e0a
      Peter Oh authored
      Add support for new FCC DFS rules released on August 14, 2014.
      FCC has added a new radar type named Radar Type 1 and original
      Radar Type 1 is renamed to Radar Type 0 in consequence.
      
      During the certificate test, Type 1 PRI values are randomly selected
      within the range of 518 and 3066 and we divide it to 3 groups based on
      practical test result data collected for more than a year.
      
      For about Radar type ID, it does nothing to functionalities.
      In other words, even if we re-order the IDs, DFS detection will
      work as well, but we give the ID with matching to FCC doc.
      
      By adding this support, the drivers using this DFS function are
      able to support both of old and new FCC DFS rules simultaneously
      without any other changes.
      Signed-off-by: default avatarPeter Oh <poh@qca.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      694c0e0a
  5. 09 Apr, 2015 7 commits
  6. 01 Apr, 2015 14 commits