1. 26 Aug, 2015 1 commit
  2. 17 Aug, 2015 4 commits
    • Vasanthakumar Thiagarajan's avatar
      ath10k: fill in wmi 10.4 command handlers for addba/delba debug commands · b2887410
      Vasanthakumar Thiagarajan authored
      WMI 10.4 uses the same command interface as QCA988X for addba/delba
      debug wmi commands. Fill wmi_10_4_ops table with the functions used
      for QCA988X for these commands.
      With this change, the following debugfs entries can be used to
      configure the aggregation mode and to send addba request,
      addba response and delba respectively in manual aggregation mode
      for QCA99X0 chip.
      Signed-off-by: default avatarVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    • Raja Mani's avatar
      ath10k: handle 10.4 firmware phyerr event · 2b0a2e0d
      Raja Mani authored
      Header format of 10.4 firmware phyerr event is not alligned
      with pre 10.4 firmware. Introduce new wmi handlers to parse
      10.4 firmware specific phyerror event header.
      With changes covered in this patch, radar detection works on
      qca9x0 hw 2.0 which uses 10.4 firmware.
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    • Raja Mani's avatar
      ath10k: refactor phyerr event handlers · 991adf71
      Raja Mani authored
      Existing phyerr event handlers directly uses phyerr header format
      (ie, struct wmi_phyerr and struct wmi_phyerr_event) in the code
      exactly on how firmware packs it. This is the problem in 10.4 fw
      specific phyerr event handling where it uses different phyerror
      header format. Before adding 10.4 specific handler, little bit of
      refactor is done in existing phyerr handlers.
      Two new abstracted structures (struct wmi_phyerr_ev_hdr_arg and
      struct wmi_phyerr_ev_arg) are introduced to remove dependency of using
      firmware specific header format in the code. So that firmware specific
      phyerror handlers can populate values to abstracted structures and
      the following code can use abstracted struct for further operation.
      .pull_phyerr_hdr is added newly to pull common phyerr header info
      like tsf, buf_len, number of phyerr packed. Existing .pull_phyerr
      handler is changed and called to parse every sub phyerrs in the event.
      Validated these refactoring on qca988x hw2.0 using fw 10.2.4 version.
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    • Vasanthakumar Thiagarajan's avatar
      ath10k: fix invalid survey reporting for QCA99X0 · 3d2a2e29
      Vasanthakumar Thiagarajan authored
      There are three WMI_CHAN_INFO events reported per channel
      in QCA99X0 firmware. First one is a notification at the begining
      of the channel dwell time with cmd_flag as CHAN_INFO_START(cmd_flag = 0),
      second one is a notification at the end of the dwell time with cmd_flag
      CHAN_INFO_PRE_COMPLETE (cmd_flag = 2) and the third is the indication
      with CHAN_INFO_COMPLETE (cmd_flag = 1) which is the last indication for
      the channel. Since there is a new state before the completion, the handler
      is to fixed so that the counts are deducted from the ones reported with
      CHAN_INFO_START rather than the ones reported with CHAN_INFO_PRE_COMPLETE.
      Without this fix there will be lots of 0 msecs reported as active
      and busy time.
      Signed-off-by: default avatarVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
  3. 13 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
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
  5. 29 Jul, 2015 2 commits
    • 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'.
         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
             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]
             - 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
             - relative Tx performance drop is seen but is within reasonable and
               expected threshold (A-MSDU must be disabled with RAW Tx)
           b) Connectivity Testing
             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
             - each test takes all possible endpoint pairs and pings
             - each pair-ping flushes arp table
             - ip6 is used
           c) Testbed Topology:
              [ap] ---- [sta]
              endpoints: ap, sta
              [veth0] [ap] ---- [sta] [veth2]
                 |     |          |     |
              [veth1]  |          \   [veth3]
                  \   /            \  /
                  [br0]            [br1]
              endpoints: veth0, veth2, br0, br1
              note: STA works in 4addr mode, AP has wds_sta=1
              [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
          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>
    • Kevin Darbyshire-Bryant's avatar
      ath10k: suppress 'failed to process fft' warning messages · 3413e97d
      Kevin Darbyshire-Bryant authored
      When using DFS channels on Ath10k, kernel log has repeated warning message
      'failed to process fft: -22' typically under medium/heavy traffic.
      This patch switches the warnings to driver debug (WMI events) mode only
      thus reducing log file noise.
      DFS and spectral scan share underlying HW mechanisms and enabling one
      (DFS) enables the other (spectral scan) as far as event reporting from
      firmware to driver is concerned. Spectral scan events take no part in
      processing of DFS radar pulses which are delivered as distinct events,
      so the fft (spectral event) warning is harmless and DFS interference
      detection/protection still occurs.
      Symptoms seen & fix tested in both debug & non-debug modes on TP-Link
      Archer C7 v2 platform.
      Signed-off-by: default avatarKevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
  6. 11 Jul, 2015 1 commit
  7. 01 Jul, 2015 5 commits
    • 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>
    • Raja Mani's avatar
      ath10k: add scan support for 10.4 fw · b2297baa
      Raja Mani authored
      Existing non 10.4 firmware scan related events and commands are
      matching with 10.4 firmware (except chan info event). Link general
      start scan,stop scan, scan channel list configuration functions
      to 10.4 wmi function table and add a new handler to parse 10.4
      specific chan info event.
      10.4 firmware has extra scan completion reason
      WMI_SCAN_REASON_INTERNAL_FAILURE and new scan event
      WMI_SCAN_EVENT_FOREIGN_CHANNEL_EXIT compared to previous firmware
      versions. These things are added in respective enum.
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    • Raja Mani's avatar
      ath10k: enable vdev and peer related operations for 10.4 fw · 373b48cf
      Raja Mani authored
      Most of existing vdev and peer related functions (vdev create,
      vdev delete, vdev start, peer create, peer delete, peer flush, etc)
      are reusable for 10.4 firmware. Link those general vdev and peer
      functions to 10.4 wmi function table.
      Existing general pktlog enable/disable, dbglog configuration functions
      are reusable for 10.4 and add them also in wmi function table.
      Also handle few wmi events (sevice rdy, echo, dbg msg, tbtt offset
      update, dbg print) in ath10k_wmi_10_4_op_rx(). wow event is not
      applicable in 10.4 firmware, have it under not implemented print.
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    • Raja Mani's avatar
      ath10k: handle 10.4 firmware wmi swba event · 3cec3be3
      Raja Mani authored
      10.4 firmware swba event payload has space to accommodate upto
      512 client traffic indication info & one p2p noa descriptor.
      It's is not matching with exiting swba event format defined for
      non 10.4 firmware. Non 10.4 firmware swba event format is designed
      to support only upto only 128 client and four p2p notice of absence
      following changes are done in this patch to enable ath10k to handle
      10.4 firmware swba event,
       - link generic ath10k_wmi_event_host_swba() to handle 10.4 swba
         event in 10.4 wmi rx handler.
       - add 10.4 specific swba event structure wmi_10_4_host_swba_event.
       - new function ath10k_wmi_10_4_op_pull_swba_ev() to parse
         10.4 swba event.
       - increase tim_bitmap[] size in ath10k_vif to 64 to hold 512 station
         power save state.
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    • Raja Mani's avatar
      ath10k: enhance swba event handler to adapt different size tim bitmap · a03fee34
      Raja Mani authored
      Due to 512 client support in 10.4 firmware, size of tim ie is going
      to be slightly higher than non 10.4 firmware. So, size of tim_bitmap
      what is carried in swba event from 10.4 firmware is bit higher.
      The only bottle neck to reuse existing swba handler
      ath10k_wmi_event_host_swba() for 10.4 is that code designed to deal
      with fixed size tim bitmap(ie, tim_info[].tim_bitmap in wmi_swba_ev_arg).
      This patch removes such size limitation and makes it more suitable
      to handle swba event which has different size tim bitmap.
      All existing swba event parsing functions are changed to adapt this
      change. Actual support to handle 10.4 swba event is added in next patch.
      Only preparation is made in this patch.
      Signed-off-by: default avatarRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
  8. 30 Jun, 2015 10 commits
  9. 09 Jun, 2015 2 commits
  10. 29 May, 2015 3 commits
    • Michal Kazior's avatar
      ath10k: fix inconsistent survey reports · 44b7d483
      Michal Kazior authored
      In some cases some channel survey data was
      reported incorrect.
      Channel info events were expected to come in pairs
      without and with COMPLETE flag set respectively
      for each channel visit during scan.
      The known deviation from this is rule for last
      scan chan info and first (next) scan chan info
      both have COMPLETE flag set. This was either
      programmed with the intent of providing BSS cycle
      count info or this is an artefact of firmware scan
      state machine. Either way this is useless due to
      short wraparound time, wraparound quirks and no
      overflow notification.
      Survey dumps now include only data gathered during
      scan channel visits that can be computed
      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>
    • 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>
    • Michal Kazior's avatar
      ath10k: move cycle_count macro · 0936ea3f
      Michal Kazior authored
      The macro isn't WMI specific. Instead it is
      related to hardware chip so move the macro
      accordingly. While at it document the magic value.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
  11. 11 May, 2015 1 commit
  12. 17 Apr, 2015 1 commit
  13. 01 Apr, 2015 4 commits
  14. 30 Mar, 2015 3 commits
  15. 12 Mar, 2015 1 commit