1. 09 9月, 2015 2 次提交
    • V
      ath10k: drop probe responses when too many are queued · 7b7da0a0
      Vivek Natarajan 提交于
      In a noisy environment, when multiple interfaces are created,
      the management tx descriptors are fully occupied by the probe
      responses from all the interfaces. This prevents a new station
      from a successful association.
      
      Fix this by limiting the probe responses when the specified
      threshold limit is reached.
      Signed-off-by: NVivek Natarajan <nataraja@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      7b7da0a0
    • V
      ath10k: fix DMA alloc failure for target requested memory chunks · a925a376
      Vasanthakumar Thiagarajan 提交于
      During long hours of stress testing like AP interface up/down along
      with continuous ping flood from a station doing connect/disconnect,
      it is observed that the system is not able to allocate DMA consistent
      memory of size > 512KB chunks as requested by firmware in WMI_SERVICE_EVENTID.
      With the system memory getting fragmented during the run based on the
      size of the memory requested, the failure to return physically continguous
      memory of high order can happen. Once the system gets to this situation,
      bringing up the wifi interface will fail and a system reboot may be needed
      to make it work again. This problem is obseved with QCA99X0.
      
      To fix this issue, allocate the DMA memory requested by firmware during
      device probe time and keep it during the life time of the device. WMI service
      ready event handler is changed to allocate the memory chunks if it is
      not already allocated or if the memory allocated for the previous ready
      event is not same as the current requested ones. After this patch the
      memory usage when wifi is inactive will be inceased by few 100KB to
      3MB based on the target type.
      
      Failure happens with the following stack trace
      
      [29557.488773] kworker/u4:1: page allocation failure: order:8, mode:0xd0
      [29557.494297] CPU: 0 PID: 8402 Comm: kworker/u4:1 Not tainted 3.14.43 #7
      [29557.500793] Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core]
      [29557.508602] [<c021e9b0>] (unwind_backtrace) from [<c021ba90>] (show_stack+0x10/0x14)
      [29557.516580] [<c021ba90>] (show_stack) from [<c03bdddc>] (dump_stack+0x88/0xcc)
      [29557.523612] [<c03bdddc>] (dump_stack) from [<c0290e34>] (warn_alloc_failed+0xdc/0x108)
      [29557.531515] [<c0290e34>] (warn_alloc_failed) from [<c0292d88>] (__alloc_pages_nodemask+0x4f0/0x654)
      [29557.540485] [<c0292d88>] (__alloc_pages_nodemask) from [<c0222b48>] (__dma_alloc_buffer.isra.20+0x2c/0x104)
      [29557.550260] [<c0222b48>] (__dma_alloc_buffer.isra.20) from [<c0222c34>] (__alloc_remap_buffer.isra.23+0x14/0xb8)
      [29557.560413] [<c0222c34>] (__alloc_remap_buffer.isra.23) from [<c022305c>] (__dma_alloc+0x224/0x2b8)
      [29557.569490] [<c022305c>] (__dma_alloc) from [<c0223208>] (arm_dma_alloc+0x84/0x90)
      [29557.577010] [<c0223208>] (arm_dma_alloc) from [<bf5159d0>] (ath10k_wmi_event_service_ready_work+0x2f8/0x420 [ath10k_core])
      [29557.588055] [<bf5159d0>] (ath10k_wmi_event_service_ready_work [ath10k_core]) from [<c024260c>] (process_one_work+0x20c/0x328)
      [29557.599305] [<c024260c>] (process_one_work) from [<c02432d0>] (worker_thread+0x228/0x360)
      [29557.607470] [<c02432d0>] (worker_thread) from [<c0247f88>] (kthread+0xd8/0xec)
      [29557.614750] [<c0247f88>] (kthread) from [<c0208d18>] (ret_from_fork+0x14/0x3c)
      [29557.712751] Normal: 696*4kB (UEMR) 512*8kB (UEMR) 367*16kB (UEMR) 404*32kB (UEMR) 455*64kB (UEMR) 424*128kB (UEMR) 379*256kB (UMR) 327*512kB (UMR) 1*1024kB (R) 0*2048kB 0*4096kB = 374544kB
      Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      a925a376
  2. 26 8月, 2015 1 次提交
    • M
      ath10k: add qca6164 support · 36582e5d
      Michal Kazior 提交于
      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: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      36582e5d
  3. 19 8月, 2015 1 次提交
  4. 17 8月, 2015 1 次提交
  5. 30 7月, 2015 1 次提交
    • R
      ath10k: fix memory alloc failure in qca99x0 during wmi svc rdy event · c8ecfc1c
      Raja Mani 提交于
      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: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      c8ecfc1c
  6. 29 7月, 2015 1 次提交
    • D
      ath10k: enable raw encap mode and software crypto engine · ccec9038
      David Liu 提交于
      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: NDavid Liu <cfliu.tw@gmail.com>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Tested-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ccec9038
  7. 02 7月, 2015 3 次提交
    • R
      ath10k: configure frag desc memory to target for qca99X0 · d9156b5f
      Raja Mani 提交于
      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: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d9156b5f
    • R
      ath10k: set max spatial stream to 4 for 10.4 fw · 5c8726ec
      Raja Mani 提交于
      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: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      5c8726ec
    • R
      ath10k: add 10.4 fw specific htt msg definitions · 721ad3ca
      Raja Mani 提交于
      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: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      721ad3ca
  8. 30 6月, 2015 6 次提交
  9. 16 6月, 2015 1 次提交
  10. 01 6月, 2015 1 次提交
  11. 29 5月, 2015 1 次提交
    • M
      ath10k: handle cycle counter wraparound · 587f7031
      Michal Kazior 提交于
      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: NSrinivasa Duvvuri <sduvvuri@chromium.org>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      587f7031
  12. 05 5月, 2015 1 次提交
    • K
      ath10k: add ATH10K_FW_FEATURE_IGNORE_OTP_RESULT · d9153546
      Kalle Valo 提交于
      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: NKalle Valo <kvalo@qca.qualcomm.com>
      d9153546
  13. 22 4月, 2015 2 次提交
    • M
      ath10k: allow loading device specific board files · de57e2c8
      Michal Kazior 提交于
      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: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      de57e2c8
    • M
      ath10k: share board file loading code across FW APIs · d0ed74f3
      Michal Kazior 提交于
      There's no need to implement the same thing twice.
      Reduce code duplication.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d0ed74f3
  14. 09 4月, 2015 1 次提交
  15. 02 4月, 2015 2 次提交
  16. 30 3月, 2015 6 次提交
  17. 04 3月, 2015 1 次提交
  18. 04 2月, 2015 1 次提交
  19. 27 1月, 2015 2 次提交
  20. 13 1月, 2015 1 次提交
  21. 23 12月, 2014 4 次提交
    • R
      ath10k: add thermal sensor device support · ac2953fc
      Rajkumar Manoharan 提交于
      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: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ac2953fc
    • R
      ath10k: add thermal cooling device support · fe6f36d6
      Rajkumar Manoharan 提交于
      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: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      fe6f36d6
    • R
      ath10k: add 10.2.4 firmware support · 4a16fbec
      Rajkumar Manoharan 提交于
      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: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      4a16fbec
    • K
      ath10k: set max_num_vdevs based on wmi op version · 30c78167
      Kalle Valo 提交于
      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: NKalle Valo <kvalo@qca.qualcomm.com>
      30c78167