1. 23 3月, 2016 2 次提交
  2. 22 3月, 2016 1 次提交
  3. 18 3月, 2016 1 次提交
  4. 04 3月, 2016 2 次提交
  5. 26 2月, 2016 2 次提交
  6. 26 1月, 2016 3 次提交
  7. 08 12月, 2015 1 次提交
  8. 30 11月, 2015 6 次提交
  9. 05 11月, 2015 1 次提交
    • Y
      ath10k: debugfs file to enable Bluetooth coexistence feature · 844fa572
      Yanbo Li 提交于
      As not all QCA98XX radios are not connected to Bluetooth modules, enabling the
      BT coex feature in firmware will have side effects if the radio's GPIO are
      connected with other (non-BT) HW modules. Add debugfs file to control the
      firmware BT coex logic and set the feature as disable by default to avoid that
      btcoex is accidentally enabled.
      
      To enable this feature, execute:
      
      echo 1 > /sys/kernel/debug/ieee80211/phyX/ath10k/btcoex
      
      To disable:
      
      echo 0 > /sys/kernel/debug/ieee80211/phyX/ath10k/btcoex
      
      The firmware support this feature since 10.2.4.54 on 2G-only board, dual band
      or 5G boards don't support this. The feature's name is WMI_SERVICE_COEX_GPIO
      and the btcoex file is not created if firmware doesn't support it.
      Signed-off-by: NYanbo Li <yanbol@qca.qualcomm.com>
      [kvalo@qca.qualcomm.com: use btcoex filename and other smaller fixes]
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      844fa572
  10. 19 10月, 2015 1 次提交
  11. 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
  12. 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
  13. 19 8月, 2015 1 次提交
  14. 13 8月, 2015 1 次提交
  15. 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
  16. 16 6月, 2015 2 次提交
  17. 22 4月, 2015 1 次提交
    • M
      ath10k: allow loading device specific board files · de57e2c8
      Michal Kazior 提交于
      Some devices differ slightly and require different
      board files. If wrong board data is used they
      crash or behave incorrectly.
      
      These devices can be differentiated by looking at
      PCI subsystem device id. That is the case for
      qca61x4 devices at least.
      
      The board specific filename is constructed as:
      
       board-<bus>-<id>.bin
      
      For PCI in particular it is:
      
       board-pci-<vendor>:<dev>:<subsys_vendor>:<subsys_dev>.bin
      
      These files are looked in device/hw specific
      directories. Hence for Killer 1525 (qca6174 hw2.1)
      ath10k will request:
      
        /lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin
      
      To not break any existing setups (e.g. in case
      some devices in the wild already have subsys ids)
      if a board specific file isn't found a generic one
      is used which is the one which would be used until
      now. This guarantees that after upgrading a driver
      device will not suddenly stop working due to
      now-missing specific board file. If this is the
      case a "fallback" string is appended to the info
      string when driver boots.
      
      Keep in mind this is distinct from cal-pci-*.bin
      files which contain full calibration data and MAC
      address. Cal data is aimed at systems where
      calibration data is stored out of band, e.g. on
      nand flash instead of device EEPROM - an approach
      taken by some AP/router vendors.
      
      Board files are more of a template and needs some
      bits to be filled in by the OTP program using
      device EEPROM contents.
      
      One could argue to map subsystem ids to some board
      design codename strings instead of using raw ids
      when building the board filename. Using a mapping
      however would make it a lot more cumbersome and
      time consuming (due to how patches propagate over
      various kernel trees) to add support for some new
      device board designs. Adding a board file is a lot
      quicker and doesn't require recompilation.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      de57e2c8
  18. 09 4月, 2015 1 次提交
  19. 02 4月, 2015 1 次提交
  20. 23 3月, 2015 3 次提交
  21. 15 2月, 2015 3 次提交
  22. 04 2月, 2015 1 次提交
  23. 13 1月, 2015 1 次提交
  24. 23 12月, 2014 1 次提交