1. 29 7月, 2015 3 次提交
    • 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
    • Q
      ath10k: Improve performance by reducing tx_lock contention · 005fb161
      Qi Zhou 提交于
      During tx completion, tx_lock is held for longer than required, preventing
      efficient refill of htt->pending_tx. Refactor the code so that only MSDU
      related operations are protected by the lock.
      
      Improves downstream performance on a dual-core ARM Freescale LS1024A
      (f.k.a. Mindspeed Comcerto 2000) AP with a 3x3 client from 495 to 580 Mbps.
      Other CPU bound multicore systems may also benefit.
      Signed-off-by: NDenton Gentry <dgentry@google.com>
      Signed-off-by: NAvery Pennarun <apenwarr@google.com>
      [mfaltesek@google.com: removed conflicting code for tracking msdu_ids.]
      Signed-off-by: NMarty Faltesek <mfaltesek@google.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      005fb161
    • K
      ath10k: suppress 'failed to process fft' warning messages · 3413e97d
      Kevin Darbyshire-Bryant 提交于
      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: NKevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      3413e97d
  2. 24 7月, 2015 7 次提交
  3. 12 7月, 2015 8 次提交
  4. 02 7月, 2015 8 次提交
    • 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: advertise 10.4 fw ap and sta iface combination to mac80211 · cf36fef0
      Raja Mani 提交于
      10.4 fw supports upto 16 interface in ap mode and 1 interface
      in station mode, overall total interfaces supported are 16
      interfaces. Populate this limit in wiphy->iface_combinations.
      Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      cf36fef0
    • 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
    • R
      ath10k: add scan support for 10.4 fw · b2297baa
      Raja Mani 提交于
      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: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      b2297baa
    • R
      ath10k: enable vdev and peer related operations for 10.4 fw · 373b48cf
      Raja Mani 提交于
      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: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      373b48cf
    • R
      ath10k: handle 10.4 firmware wmi swba event · 3cec3be3
      Raja Mani 提交于
      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
      descriptor.
      
      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: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      3cec3be3
    • R
      ath10k: enhance swba event handler to adapt different size tim bitmap · a03fee34
      Raja Mani 提交于
      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: NRaja Mani <rmani@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      a03fee34
  5. 30 6月, 2015 14 次提交