1. 28 1月, 2016 1 次提交
  2. 23 11月, 2015 1 次提交
  3. 13 11月, 2015 1 次提交
    • V
      ath10k: fix peerid configuration in htt tx desc for htt version < 3.4 · d39de991
      Vasanthakumar Thiagarajan 提交于
      Of a word in struct htt_data_tx_desc htt version >= 3.4 firmware uses
      LSB 16-bit for frequency configuration which is used for offchannel tx
      and MSB 16-bit is for peerid. But other firmwares using version 2.X
      (10.1, 10.2.2, 10.2.4 and 10.4) are using 32-bit for peerid in htt tx
      desc. So far no issue is found with the existing code setting peerid and
      freq for HTT version 2.X, this could be mainly because of 0 as frequecy
      (home channel) is being always passed with those firmwares. There may be
      issues when non-zero freq is passed with firmware using < 3.4 htt version.
      To be safe use target_version_major and target_version_minor along with
      htt-op-version before configuring peer id and freq in htt tx desc. This
      patch extends ath10k_mac_tx_frm_has_freq() to check for htt_op_version_tlv
      and uses the helper while setting peerid in htt_tx_desc.
      
      Fixes: 8d6d3624 ("ath10k: fix offchan reliability")
      Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d39de991
  4. 05 11月, 2015 1 次提交
  5. 16 10月, 2015 1 次提交
  6. 06 10月, 2015 1 次提交
  7. 09 9月, 2015 1 次提交
  8. 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
  9. 24 7月, 2015 3 次提交
  10. 02 7月, 2015 2 次提交
    • 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: 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
  11. 09 4月, 2015 1 次提交
  12. 30 3月, 2015 2 次提交
    • M
      ath10k: add hw rate definitions · 6aa4cf1c
      Michal Kazior 提交于
      Prepare defines for future use.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      6aa4cf1c
    • R
      ath10k: add ATH10K_FW_IE_HTT_OP_VERSION · 8348db29
      Rajkumar Manoharan 提交于
      Target to host HTT messages are conflicting between 10.x and other
      firmware revisions. By maintaining separate HTT T2H tables for each
      firmware revisions (main, 10x and tlv) similar to WMI abstraction,
      solves the conflicts. Add ATH10K_FW_IE_HTT_OP_VERSION so that the firmware can
      advertise the HTT interface to ath10k.
      
      This fix is needed to get management frames over HTT (ie.
      ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX disabled) working with 10.2.4.48-2 firmware.
      Otherwise there will be unknown htt events and nothing works:
      
      [30087.438343] ath10k_pci 0000:02:00.0: htt event (19) not handled
      [30087.448691] ath10k_pci 0000:02:00.0: htt event (19) not handled
      [30149.032974] ath10k_pci 0000:02:00.0: htt event (19) not handled
      
      If the firmware does not have ATH10K_FW_IE_HTT_OP_VERSION use the main HTT
      interface. That way old firmware images will still work.
      
      Cc: Michal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      8348db29
  13. 27 1月, 2015 2 次提交
  14. 13 1月, 2015 1 次提交
  15. 01 12月, 2014 1 次提交
  16. 26 11月, 2014 1 次提交
  17. 07 10月, 2014 1 次提交
  18. 18 9月, 2014 2 次提交
    • K
      ath10k: miscellaneous checkpatch fixes · 8cc7f26c
      Kalle Valo 提交于
      Fixes checkpatch warnings:
      
      ath10k/htc.c:49: WARNING: Possible unnecessary 'out of memory' message
      ath10k/htc.c:810: WARNING: Possible unnecessary 'out of memory' message
      ath10k/htt.h:1034: CHECK: Please use a blank line after function/struct/union/enum declarations
      ath10k/htt_rx.c:135: CHECK: Unnecessary parentheses around htt->rx_ring.alloc_idx.vaddr
      ath10k/htt_rx.c:173: CHECK: Unnecessary parentheses around htt->rx_ring.alloc_idx.vaddr
      ath10k/pci.c:633: WARNING: macros should not use a trailing semicolon
      ath10k/wmi.c:3594: WARNING: quoted string split across lines
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      8cc7f26c
    • K
      ath10k: fix use of multiple blank lines · c6e2e60e
      Kalle Valo 提交于
      Fixes checkpatch warnings:
      
      CHECK: Please don't use multiple blank lines
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      c6e2e60e
  19. 14 7月, 2014 1 次提交
  20. 23 5月, 2014 1 次提交
  21. 25 3月, 2014 4 次提交
  22. 28 2月, 2014 3 次提交
    • M
      ath10k: batch htt tx/rx completions · 6c5151a9
      Michal Kazior 提交于
      HTT Rx endpoint processes both frame rx
      indications and frame tx completion indications.
      
      Those completions typically come in batches and
      may be mixed so it makes sense to defer processing
      hoping to get a bunch of them and take advantage
      of hot caches.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      6c5151a9
    • M
      ath10k: bypass htc for htt tx path · a16942e6
      Michal Kazior 提交于
      Going through full htc tx path for htt tx is a
      waste of resources. By skipping it it's possible
      to easily submit scatter-gather to the pci hif for
      reduced host cpu load and improved performance.
      
      The new approach uses dma pool to store the
      following metadata for each tx request:
       * msdu fragment list
       * htc header
       * htt tx command
      
      The htt tx command contains a msdu prefetch.
      Instead of copying it original mapped msdu address
      is used to submit a second scatter-gather item to
      hif to make a complete htt tx command.
      
      The htt tx command itself hands over dma mapped
      pointers to msdus and completion of the command
      itself doesn't mean the frame has been sent and
      can be unmapped/freed. This is why htc tx
      completion is skipped for htt tx as all tx related
      resources are freed upon htt tx completion
      indication event (which also implicitly means htt
      tx command itself was completed).
      
      Since now each htt tx request effectively consists
      of 2 copy engine items CE_HTT_H2T_MSG_SRC_NENTRIES
      is updated to allow maximum of
      TARGET_10X_NUM_MSDU_DESC msdus being queued. This
      keeps the tx path resource management simple.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      a16942e6
    • C
      ath10k: set the mactime of ieee80211_rx_status · e72698f8
      Chun-Yeow Yeoh 提交于
      Retrieve the mactime of ieee80211_rx_status based on received
      data frame. The value is obtained from the htt_rx_indication_ppdu
      structure and only available in 32-bit.
      
      kvalo: white space fixes
      Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      e72698f8
  23. 16 12月, 2013 1 次提交
  24. 15 11月, 2013 1 次提交
  25. 26 9月, 2013 1 次提交
  26. 06 9月, 2013 1 次提交
  27. 15 8月, 2013 1 次提交
  28. 30 7月, 2013 1 次提交
  29. 13 6月, 2013 1 次提交
    • K
      ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices · 5e3dd157
      Kalle Valo 提交于
      Here's a new mac80211 driver for Qualcomm Atheros 802.11ac QCA98xx devices.
      A major difference from ath9k is that there's now a firmware and
      that's why we had to implement a new driver.
      
      The wiki page for the driver is:
      
      http://wireless.kernel.org/en/users/Drivers/ath10k
      
      The driver has had many authors, they are listed here alphabetically:
      
      Bartosz Markowski <bartosz.markowski@tieto.com>
      Janusz Dziedzic <janusz.dziedzic@tieto.com>
      Kalle Valo <kvalo@qca.qualcomm.com>
      Marek Kwaczynski <marek.kwaczynski@tieto.com>
      Marek Puzyniak <marek.puzyniak@tieto.com>
      Michal Kazior <michal.kazior@tieto.com>
      Sujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      5e3dd157