Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 28 1月, 2016 2 次提交
    • R
      ath10k: add basic skeleton to support ahb · 0b523ced
      由 Raja Mani 提交于 
      qca4019 uses ahb instead of pci where it slightly differs in device
enumeration, clock control, reset control, etc. Good thing is that
ahb also uses copy engine for the data transaction. So, the most of
the stuff implemented in pci.c/ce.c are reusable in ahb case too.

Device enumeration in ahb case comes through platform driver/device
model. All resource details like irq, memory map, clocks, etc for
qca4019 can be fetched from of_node of platform device.

Simply flow would look like,

 device tree => platform device (kernel) => platform driver (ath10k)

Device tree entry will have all qca4019 resource details and the same
info will be passed to kernel. Kernel will prepare new platform device
for that entry and expose DT info to of_node in platform device.
Later, ath10k would register platform driver with unique compatible name
and then kernels binds to corresponding compatible entry & calls ath10k
ahb probe functions. From there onwards, ath10k will take control of it
and move forward.

New bool flag CONFIG_ATH10K_AHB is added in Kconfig to conditionally
enable ahb support in ath10k. On enabling this flag, ath10k_pci.ko
will have ahb support. This patch adds only basic skeleton and few
macros to support ahb in the context of qca4019.
Signed-off-by: NRaja Mani <rmani@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      0b523ced
    • M
      ath10k: add new FW_FEATURE_PEER_FLOW_CONTROL · 9b783763
      由 Michal Kazior 提交于 
      This feature flag will be used for firmware which
supports pull-push model where host shares it's
software queue state with firmware and firmware
generates fetch requests telling host which queues
to dequeue tx from.

Primary function of this is improved MU-MIMO
performance with multiple clients.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      9b783763
  3. 26 1月, 2016 1 次提交
  5. 21 1月, 2016 1 次提交
  7. 23 11月, 2015 9 次提交
  9. 13 11月, 2015 1 次提交
  11. 05 11月, 2015 3 次提交
  13. 29 10月, 2015 4 次提交
  15. 14 10月, 2015 2 次提交
    • M
      ath10k: select board data based on BMI chip id and board id · db0984e5
      由 Manikanta Pubbisetty 提交于 
      QCA99X0 uses radio specific board names based on chip id and
board id combinations. We get these IDs from the target using BMI after otp.bin
has been started.

This patch reorders the call to the function ath10k_core_fetch_board_file
so that we have OTP binary before requesting for boardid-chipid. We get this
OTP data after parsing firmware-N.bin.

[kvalo@qca.qualcomm.com: try BMI_PARAM_GET_EEPROM_BOARD_ID with
 all boards and detect if command is not supported]
Signed-off-by: NManikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      db0984e5
    • M
      ath10k: add board 2 API support · 0a51b343
      由 Manikanta Pubbisetty 提交于 
      QCA6174 needs different board files based on board type. To make it easier to
distribute multiple board files and automatically choose correct board file
create a simple TLV file format following the same principles as with FW IEs.
The file is named board-2.bin and contain multiple board files. Each board file
then can have multiple names.

ath10k searches for file board-N.bin (where N is the interface version number
for the board file, just like we for firmware files) in /lib/firmware/*, for
example for qca99x0 it will try to find it here:

/lib/firmware/ath10k/QCA99X0/hw2.0/board-2.bin

If ath10k doesn't find board-2.bin then it will fallback to the old board.bin file.

This patch adds a simple name scheme using pci device id which for now will be
used by qca6174:

bus=%s,vendor=%04x,device=%04x,subsystem-vendor=%04x,subsystem-device=%04x

This removes the old method of having subsystem ids in ar->spec_board_id and
using that in the board file name.
Signed-off-by: NManikanta Pubbisetty <c_mpubbi@qti.qualcomm.com>
[kvalo@qca.qualcomm.com: simplified the file format, rewrote commit log, other smaller changes]
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      0a51b343
  17. 06 10月, 2015 1 次提交
    • M
      ath10k: implement debugfs interface for Transmit Power Control stats · 29542666
      由 Maharaja Kennadyrajan 提交于 
      The Transmit Power Control (TPC) dump will show the power control values for
each rate which makes it easier to debug calibration problems.

Example usage:

# cat /sys/kernel/debug/ieee80211/phy0/ath10k/tpc_stats
TPC config for channel  5180  mode  10

CTL             = 0x10 Reg. Domain              = 58
Antenna Gain    = 1    Reg. Max Antenna Gain    = 0
Power Limit     = 34   Reg. Max Power           = 34
Num tx chains   = 3    Num supported rates      = 155

**********CDD POWER TABLE*******

No.  Preamble Rate_code tpc_valu1 tpc_value2 tpc_value3
0       CCK     0x40       0            0       0
1       CCk     0x41       0            0       0

[...]

154     HTCUP   0x 0       24           0       0
**********STBC POWER TABLE******
No.  Preamble Rate_code tpc_valu1 tpc_value2 tpc_value3
0       CCK     0x40       0            0       0

[...]

154     HTCUP   0x 0       24           24      0
**********TXBF POWER TABLE******

is used to dump the tx power control stats.
Signed-off-by: NMaharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      29542666
  19. 04 10月, 2015 1 次提交
  21. 09 9月, 2015 1 次提交
  23. 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
  25. 17 8月, 2015 1 次提交
  27. 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
  29. 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
  31. 12 7月, 2015 1 次提交
  33. 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: 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
  35. 30 6月, 2015 4 次提交
  37. 16 6月, 2015 1 次提交
  39. 09 6月, 2015 1 次提交
    • M
      ath10k: remove ath10k_chanctx struct · 089ab7a5
      由 Michal Kazior 提交于 
      In practice there's no point in having a copy of
chanctx_conf.

Most of the time the channel pointer (and band
along with it) is accessed and this can't change
after a chanctx is created because switching is
done using explicit chanctx swapping via
switch_vif_chanctx().

The only thing that can change within a
chanctx_conf and is used by the driver is
radar_enabled and channel width. These are however
always accessed in adequate mac80211 callback
context which guarantees safe access to the
chanctx data.
Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      089ab7a5