1. 26 Aug, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: add qca6164 support · 36582e5d
      Michal Kazior authored
      
      
      This adds additional 0x0041 PCI Device ID
      definition to ath10k for QCA6164 which is a 1
      spatial stream sibling of the QCA6174 (which is 2
      spatial stream chip).
      
      The QCA6164 needs a dedicated board.bin file which
      is different than the one used for QCA6174. If the
      board.bin is wrong the device will crash early
      while trying to boot firmware. The register dump
      will look like this:
      
       ath10k_pci 0000:02:00.0: firmware register dump:
       ath10k_pci 0000:02:00.0: [00]: 0x05010000 0x000015B3 0x000A012D 0x00955B31
       ...
      
      Note the value 0x000A012D.
      
      Special credit goes to Alan Liu
      <alanliu@qca.qualcomm.com> for providing support
      help which enabled me to come up with this patch.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      36582e5d
  2. 19 Aug, 2015 1 commit
  3. 17 Aug, 2015 1 commit
  4. 30 Jul, 2015 1 commit
    • Raja Mani's avatar
      ath10k: fix memory alloc failure in qca99x0 during wmi svc rdy event · c8ecfc1c
      Raja Mani authored
      
      
      Host memory required for firmware is allocated while handling
      wmi service ready event. Right now, wmi service ready is handled
      in tasklet context and it calls dma_alloc_coherent() with atomic
      flag (GFP_ATOMIC) to allocate memory in host needed for firmware.
      The problem is, dma_alloc_coherent() with GFP_ATOMIC fails in
      the platform (at least in AP platform) where it has less atomic
      pool memory (< 2mb). QCA99X0 requires around 2 MB of host memory
      for one card, having additional QCA99X0 card in the same platform
      will require similarly amount of memory. So, it's not guaranteed that
      all the platform will have enough atomic memory pool.
      
      Fix this issue, by handling wmi service ready event in workqueue
      context and calling dma_alloc_coherent() with GFP_KERNEL. mac80211 work
      queue will not be ready at the time of handling wmi service ready.
      So, it can't be used to handle wmi service ready. Also, register work
      gets scheduled during insmod in existing ath10k_wq and waits for
      wmi service ready to completed. Both workqueue can't be used for
      this purpose. New auxiliary workqueue is added to handle wmi service
      ready.
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      c8ecfc1c
  5. 29 Jul, 2015 1 commit
    • David Liu's avatar
      ath10k: enable raw encap mode and software crypto engine · ccec9038
      David Liu authored
      
      
      This patch enables raw Rx/Tx encap mode to support software based
      crypto engine. This patch introduces a new module param 'cryptmode'.
      
       cryptmode:
      
         0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX
            encapsulation to the firmware. This is the default mode.
         1: Use sofware crypto engine globally with raw mode TX/RX
            encapsulation to the firmware.
      
      Known limitation:
         A-MSDU must be disabled for RAW Tx encap mode to perform well when
         heavy traffic is applied.
      
      Testing: (by Michal Kazior <michal.kazior@tieto.com>)
      
           a) Performance Testing
      
            cryptmode=1
             ap=qca988x sta=killer1525
              killer1525  ->  qca988x     194.496 mbps [tcp1 ip4]
              killer1525  ->  qca988x     238.309 mbps [tcp5 ip4]
              killer1525  ->  qca988x     266.958 mbps [udp1 ip4]
              killer1525  ->  qca988x     477.468 mbps [udp5 ip4]
              qca988x     ->  killer1525  301.378 mbps [tcp1 ip4]
              qca988x     ->  killer1525  297.949 mbps [tcp5 ip4]
              qca988x     ->  killer1525  331.351 mbps [udp1 ip4]
              qca988x     ->  killer1525  371.528 mbps [udp5 ip4]
             ap=killer1525 sta=qca988x
              qca988x     ->  killer1525  331.447 mbps [tcp1 ip4]
              qca988x     ->  killer1525  328.783 mbps [tcp5 ip4]
              qca988x     ->  killer1525  375.309 mbps [udp1 ip4]
              qca988x     ->  killer1525  403.379 mbps [udp5 ip4]
              killer1525  ->  qca988x     203.689 mbps [tcp1 ip4]
              killer1525  ->  qca988x     222.339 mbps [tcp5 ip4]
              killer1525  ->  qca988x     264.199 mbps [udp1 ip4]
              killer1525  ->  qca988x     479.371 mbps [udp5 ip4]
      
            Note:
             - only open network tested for RAW vs nwifi performance comparison
             - killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps)
             - used iperf
             - OTA, devices a few cm apart from each other, no shielding
             - tcpX/udpX, X - means number of threads used
      
            Overview:
             - relative Tx performance drop is seen but is within reasonable and
               expected threshold (A-MSDU must be disabled with RAW Tx)
      
           b) Connectivity Testing
      
            cryptmode=1
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta          OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta          OK
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta2br       OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br       OK
             ap=iwl6205 sta1=qca988x crypto=open     topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wep1     topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wpa      topology-1ap1sta2br1vlan  OK
             ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=open     topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wep1     topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wpa      topology-1ap1sta2br1vlan  OK
             ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan  OK
      
            Note:
             - each test takes all possible endpoint pairs and pings
             - each pair-ping flushes arp table
             - ip6 is used
      
           c) Testbed Topology:
      
            1ap1sta:
              [ap] ---- [sta]
      
              endpoints: ap, sta
      
            1ap1sta2br:
              [veth0] [ap] ---- [sta] [veth2]
                 |     |          |     |
              [veth1]  |          \   [veth3]
                  \   /            \  /
                  [br0]            [br1]
      
              endpoints: veth0, veth2, br0, br1
              note: STA works in 4addr mode, AP has wds_sta=1
      
            1ap1sta2br1vlan:
              [veth0] [ap] ---- [sta] [veth2]
                 |     |          |     |
              [veth1]  |          \   [veth3]
                  \   /            \  /
                [br0]              [br1]
                  |                  |
                [vlan0_id2]        [vlan1_id2]
      
              endpoints: vlan0_id2, vlan1_id2
              note: STA works in 4addr mode, AP has wds_sta=1
      
      Credits:
      
          Thanks to Michal Kazior <michal.kazior@tieto.com> who helped find the
          amsdu issue, contributed a workaround (already squashed into this
          patch), and contributed the throughput and connectivity tests results.
      Signed-off-by: default avatarDavid Liu <cfliu.tw@gmail.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Tested-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      ccec9038
  6. 01 Jul, 2015 3 commits
    • Raja Mani's avatar
      ath10k: configure frag desc memory to target for qca99X0 · d9156b5f
      Raja Mani authored
      
      
      Pre qca99X0 chipsets follows the model where dynamically allocate
      memory for frag desc on getting new skb for TX. But, this is not
      going to be the case in qca99X0. It expects frag desc memory to be
      allocated at boot time and let the driver to reuse allocated memory
      after every TX completion. So there won't be any dynamic frag memory
      memory allocation in qca99X0 during data transmission.
      
      qca99X0 hardware doesn't need fragment desc address to be programmed
      in msdu descriptor for every data transaction. It needs to know only
      starting address of fragment descriptor at the time of the boot.
      During data transmission, qca99X0 hardware can retrieve corresponding
      frag addr by adding programmed frag desc base addr + msdu id.
      
      Allocate continuous fragment descriptor memory (same size as number of
      descriptor) at the time of target initialization and configure allocated
      dma address to the target via HTT_H2T_MSG_TYPE_FRAG_DESC_BANK_CFG.
      
      How this is allocated continuous memory is going to be used is not
      covered in this patch. It just allocates memory and hand over to firmware.
      If we don't do it at init time, qca99X0 will stall when firmware tries
      to do TX.
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      d9156b5f
    • Raja Mani's avatar
      ath10k: set max spatial stream to 4 for 10.4 fw · 5c8726ec
      Raja Mani authored
      
      
      10.4 fw supports upto 4 spatial stream. Limit max spatial
      stream to 4 for 10.4 firmware and to 3 for non 10.4 firmware.
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      5c8726ec
    • Raja Mani's avatar
      ath10k: add 10.4 fw specific htt msg definitions · 721ad3ca
      Raja Mani authored
      
      
      New htt event table is added for 10.4 firmware. Following new htt
      events are available only 10.4. adding this to generic htt event
      table,
      	HTT_T2H_MSG_TYPE_EN_STATS,
      	HTT_T2H_MSG_TYPE_TX_FETCH_IND,
      	HTT_T2H_MSG_TYPE_TX_FETCH_CONF,
      	HTT_T2H_MSG_TYPE_TX_LOW_LATENCY_IND
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      721ad3ca
  7. 30 Jun, 2015 6 commits
  8. 16 Jun, 2015 1 commit
  9. 01 Jun, 2015 1 commit
  10. 29 May, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: handle cycle counter wraparound · 587f7031
      Michal Kazior authored
      
      
      When QCA988X cycle counter HW register wraps
      around it resets to 0x7fffffff instead of 0. All
      other cycle counter related registers are divided
      by 2 so they never wraparound themselves. QCA61X4
      has a uniform CC and it wraparounds in a regular
      fashion though.
      
      Worst case wraparound time is approx 24 seconds
      (2**31 / 88MHz). Since scan channel visit times
      are max 5 seconds (offchannel case) it is
      guaranteed there's been at most 1 wraparound and
      it is possible to compute survey active time
      value. It is, however, impossible to determine the
      point at which Rx Clear Count has been divided by
      two so it is not reported upon wraparound.
      
      This fixes some occasional incorrect survey data
      on QCA988X as some channels (depending on how/when
      scan/offchannel requests were requested) would
      have approx 24 sec active time which wasn't
      actually the case.
      
      This should improve hostapd ACS a little bit.
      Reported-by: default avatarSrinivasa Duvvuri <sduvvuri@chromium.org>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      587f7031
  11. 04 May, 2015 1 commit
    • Kalle Valo's avatar
      ath10k: add ATH10K_FW_FEATURE_IGNORE_OTP_RESULT · d9153546
      Kalle Valo authored
      
      
      qca6174 otp binary seems to always return an error to the host, even if the
      calibration succeeded. Add a firmware feature flag to detect if the firmware
      image which have this problem and workaround the issue in ath10k by ignoring
      the error code.
      
      I was also considering making this hw specific flag but as this is strictly a
      firmware issue it's best to handle this via a firmware feature flag so that it
      will be easy to disable the workaround.
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      d9153546
  12. 21 Apr, 2015 2 commits
    • 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
  13. 09 Apr, 2015 1 commit
  14. 01 Apr, 2015 2 commits
  15. 30 Mar, 2015 6 commits
  16. 04 Mar, 2015 1 commit
  17. 04 Feb, 2015 1 commit
  18. 27 Jan, 2015 2 commits
  19. 13 Jan, 2015 1 commit
  20. 23 Dec, 2014 4 commits
    • Rajkumar Manoharan's avatar
      ath10k: add thermal sensor device support · ac2953fc
      Rajkumar Manoharan authored
      
      
      Temperature sensor generates electrical analog voltage from temperature
      of each chain. The analog voltage is converted to digital value through
      ADC. For reading temperature values fom user space, hw monitoring device
      is used.
      
      Whenever the user requests for current temperature, the driver sends WMI
      command and wait for response. For reading temperature,
      
      cat /sys/class/ieee80211/phy*/device/hwmon/hwmon2/temp1_input
      Signed-off-by: default avatarRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      ac2953fc
    • Rajkumar Manoharan's avatar
      ath10k: add thermal cooling device support · fe6f36d6
      Rajkumar Manoharan authored
      
      
      Thermal cooling device support is added to control the temperature
      by throttling the data transmission for the given duration. Throttling
      is done using hw MAC quiet time setting. Period, duration and offset
      from TBTT can be set up to quiet the MAC transmits for the required duty
      cycle (% of quiet duration). The thermal device allows user to configure
      duty cycle.
      
      The quiet params are derived as follows.
      	period = max(25TU, beacon interval / number of bss)
      	duration = period * duty cycle / 100
      
      Quiet mode can be disabled by setting the duty cycle to 0. The cooling
      device can be found under /sys/class/thermal/cooling_deviceX/.
      Corresponding soft link to this device can be found under phy folder.
      
      /sys/class/ieee80211/phy*/device/cooling_device.
      
      To set duty cycle as 40%,
      
      echo 40 >/sys/class/ieee80211/phy*/device/cooling_device/cur_state
      Signed-off-by: default avatarRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      fe6f36d6
    • Rajkumar Manoharan's avatar
      ath10k: add 10.2.4 firmware support · 4a16fbec
      Rajkumar Manoharan authored
      
      
      10.2.4 firmware uses bitmask in wmi_resource_config to configure
      10.2 firmware features like airtime fairness and rx batch mode instead
      of maintaining separete bool entry. This allows new features that can be
      configure during init time without breaking backward compatibility.
      
      kvalo: use WMI op version, bump up FW API to 4 to not break older versions of
      ath10k
      Signed-off-by: default avatarRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      4a16fbec
    • Kalle Valo's avatar
      ath10k: set max_num_vdevs based on wmi op version · 30c78167
      Kalle Valo authored
      
      
      To make it easier to manage firmware differences, we should not use
      ATH10K_FW_FEATURE_WMI_10X outside ath10k_core_init_firmware_features(). To
      achieve that create new field ar->max_num_vdevs and set it based on wmi op
      version.
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      30c78167
  21. 16 Dec, 2014 1 commit
    • Michal Kazior's avatar
      ath10k: advertise p2p dev support · 75d2bd48
      Michal Kazior authored
      
      
      Firmware doesn't allow precise tx rate control so
      P2P wasn't entirely spec compliant (it was using
      CCK rates in some cases).
      
      The only way to make sure firmware doesn't use CCK
      rates is to have a vdev with P2P subtype used for
      scanning and tx. This can be done via a special
      dedicated P2P device interface support.
      
      This also removes the ancient hack from ath10k in
      favor of p2pdev.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      75d2bd48
  22. 08 Dec, 2014 1 commit