1. 14 6月, 2018 1 次提交
  2. 24 4月, 2018 2 次提交
  3. 19 4月, 2018 2 次提交
  4. 27 12月, 2017 3 次提交
  5. 06 7月, 2017 1 次提交
  6. 16 6月, 2017 1 次提交
  7. 01 6月, 2017 1 次提交
  8. 13 4月, 2017 1 次提交
  9. 05 4月, 2017 1 次提交
  10. 07 2月, 2017 1 次提交
  11. 28 1月, 2017 1 次提交
  12. 19 1月, 2017 1 次提交
    • M
      ath10k: dump Copy Engine registers during firmware crash · c75c398b
      Mohammed Shafi Shajakhan 提交于
      Dump Copy Engine source and destination ring addresses.
      This is useful information to debug firmware crashes, assertes or hangs over long run
      assessing the Copy Engine Register status. This also enables dumping CE
      register status in debugfs Crash Dump file.
      
      Screenshot:
      
      ath10k_pci 0000:02:00.0: simulating hard firmware crash
      ath10k_pci 0000:02:00.0: firmware crashed! (uuid 84901ff5-d33c-456e-93ee-0165dea643cf)
      ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
      ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
      ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
      ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
      ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1
      ath10k_pci 0000:02:00.0: firmware register dump:
      ath10k_pci 0000:02:00.0: [00]: 0x4100016C 0x00000000 0x009A0F2A 0x00000000
      ath10k_pci 0000:02:00.0: [04]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [08]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [12]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [16]: 0x00000000 0x00000000 0x00000000 0x009A0F2A
      ath10k_pci 0000:02:00.0: [20]: 0x00000000 0x00401930 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [24]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [28]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [32]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [40]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [44]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [48]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [52]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: [56]: 0x00000000 0x00000000 0x00000000 0x00000000
      ath10k_pci 0000:02:00.0: Copy Engine register dump:
      ath10k_pci 0000:02:00.0: [00]: 0x00057400   7   7   3   3
      ath10k_pci 0000:02:00.0: [01]: 0x00057800  18  18  85  86
      ath10k_pci 0000:02:00.0: [02]: 0x00057c00  49  49  48  49
      ath10k_pci 0000:02:00.0: [03]: 0x00058000  16  16  17  16
      ath10k_pci 0000:02:00.0: [04]: 0x00058400   4   4  44   4
      ath10k_pci 0000:02:00.0: [05]: 0x00058800  12  12  11  12
      ath10k_pci 0000:02:00.0: [06]: 0x00058c00   3   3   3   3
      ath10k_pci 0000:02:00.0: [07]: 0x00059000   0   0   0   0
      ieee80211 phy0: Hardware restart was requested
      ath10k_pci 0000:02:00.0: device successfully recovered
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      [kvalo@qca.qualcomm.com: simplify the implementation]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      c75c398b
  13. 28 9月, 2016 1 次提交
    • R
      ath10k: fix copy engine 5 destination ring stuck · 0628467f
      Rajkumar Manoharan 提交于
      Firmware is running watchdog timer for tracking copy engine ring index
      and write index. Whenever both indices are stuck at same location for
      given duration, watchdog will be trigger to assert target. While
      updating copy engine destination ring write index, driver ensures that
      write index will not be same as read index by finding delta between these
      two indices (CE_RING_DELTA).
      
      HTT target to host copy engine (CE5) is special case where ring buffers
      will be reused and delta check is not applied while updating write index.
      In rare scenario, whenever CE5 ring is full, both indices will be referring
      same location and this is causing CE ring stuck issue as explained
      above. This issue is originally reported on IPQ4019 during long hour stress
      testing and during veriwave max clients testsuites. The same issue is
      also observed in other chips as well. Fix this by ensuring that write
      index is one less than read index which means that full ring is
      available for receiving data.
      
      Cc: stable@vger.kernel.org
      Tested-by: NTamizh chelvam <c_traja@qti.qualcomm.com>
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      0628467f
  14. 27 9月, 2016 1 次提交
  15. 02 9月, 2016 1 次提交
  16. 14 4月, 2016 1 次提交
  17. 04 4月, 2016 2 次提交
    • R
      ath10k: reuse copy engine 5 (htt rx) descriptors · 128abd09
      Rajkumar Manoharan 提交于
      Whenever htt rx indication i.e target to host messages are received
      on rx copy engine (CE5), the message will be freed after processing
      the response. Then CE 5 will be refilled with new descriptors at
      post rx processing. This memory alloc and free operations can be avoided
      by reusing the same descriptors.
      
      During CE pipe allocation, full ring is not initialized i.e n-1 entries
      are filled up. So for CE 5 full ring should be filled up to reuse
      descriptors. Moreover CE 5 write index will be updated in single shot
      instead of incremental access. This could avoid multiple pci_write and
      ce_ring access. From experiments, It improves CPU usage by ~3% in IPQ4019
      platform.
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      128abd09
    • R
      ath10k: cleanup copy engine receive next completion · 24d9ef5e
      Rajkumar Manoharan 提交于
      The physical address necessary to unmap DMA ('bufferp') is stored
      in ath10k_skb_cb as 'paddr'. For diag register read and write
      operations, 'paddr' is stored in transfer context. ath10k doesn't rely
      on the meta/transfer_id. So the unused output arguments {bufferp, nbytesp
      and transfer_idp} are removed from CE recv_next completion.
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      24d9ef5e
  18. 29 10月, 2015 3 次提交
  19. 16 10月, 2015 2 次提交
  20. 09 10月, 2015 1 次提交
    • R
      ath10k: optimize ce_lock on post rx buffer processing · ab4e3db0
      Rajkumar Manoharan 提交于
      After processing received packets from copy engine, host will allocate
      new buffer and queue them back to copy engine ring for further
      packet reception. On post rx processing path, skb allocation and
      dma mapping are unnecessarily handled within ce_lock. This is affecting
      peak throughput and also causing more CPU consumption. Optimize this
      by acquiring ce_lock only when accessing copy engine ring and moving
      skb allocation out of ce_lock.
      
      In AP148 platform with QCA99x0 in conducted environment, UDP uplink peak
      throughput is improved from ~1320 Mbps to ~1450 Mbps and TCP uplink peak
      throughput is increased from ~1240 Mbps (70% host CPU load) to ~1300 Mbps
      (71% CPU load). Similarly ~40Mbps improvement is observed in downlink
      path.
      Signed-off-by: NRajkumar Manoharan <rmanohar@qti.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      ab4e3db0
  21. 30 6月, 2015 1 次提交
  22. 27 1月, 2015 1 次提交
    • M
      ath10k: add support for qca6174 · d63955b3
      Michal Kazior 提交于
      The QCA6174 in combination with new wmi-tlv firmware is capable of
      multi-channel, beamforming, tdls and other features.
      
      This patch just makes it possible to boot these devices and do some basic stuff
      like connect to an AP without encryption. Some things may not work or may be
      unreliable. New features will be implemented later. This will be addressed
      eventually with future patches.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d63955b3
  23. 08 12月, 2014 1 次提交
  24. 31 10月, 2014 2 次提交
  25. 23 10月, 2014 1 次提交
  26. 26 9月, 2014 2 次提交
    • K
      ath10k: add diag_read() to hif ops · eef25405
      Kalle Valo 提交于
      diag_read() is used for reading from firmware memory via the diagnose window.
      First user will be cal_data debugfs file.
      
      To serialise diagnostic window access and make it safe to use while firmware is
      running take ce_lock both in ath10k_pci_diag_write_mem() and
      ath10k_pci_diag_read_mem(). Because of that all the CE calls had to be changed
      to _nolock variants.
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      eef25405
    • K
      ath10k: don't enable interrupts for the diagnostic window · d5d6805b
      Kalle Valo 提交于
      The diagnostic window (CE7) uses polling and is not initiliased to retrieve
      interrupts so disable interrupts altogether for CE7. Otherwise ath10k crashes
      when using the diagnostic window while the firmware is running due to NULL
      dereference and polling reads timeout.
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      d5d6805b
  27. 18 9月, 2014 1 次提交
  28. 27 8月, 2014 1 次提交
  29. 25 8月, 2014 2 次提交