1. 13 Aug, 2015 1 commit
  2. 29 Jul, 2015 1 commit
    • David Liu's avatar
      ath10k: enable raw encap mode and software crypto engine · ccec9038
      David Liu authored
      This patch enables raw Rx/Tx encap mode to support software based
      crypto engine. This patch introduces a new module param '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
             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]
             - 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
             - relative Tx performance drop is seen but is within reasonable and
               expected threshold (A-MSDU must be disabled with RAW Tx)
           b) Connectivity Testing
             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
             - each test takes all possible endpoint pairs and pings
             - each pair-ping flushes arp table
             - ip6 is used
           c) Testbed Topology:
              [ap] ---- [sta]
              endpoints: ap, sta
              [veth0] [ap] ---- [sta] [veth2]
                 |     |          |     |
              [veth1]  |          \   [veth3]
                  \   /            \  /
                  [br0]            [br1]
              endpoints: veth0, veth2, br0, br1
              note: STA works in 4addr mode, AP has wds_sta=1
              [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
          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: default avatarDavid Liu <cfliu.tw@gmail.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Tested-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
  3. 16 Jun, 2015 2 commits
  4. 21 Apr, 2015 1 commit
    • Michal Kazior's avatar
      ath10k: allow loading device specific board files · de57e2c8
      Michal Kazior authored
      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:
      For PCI in particular it is:
      These files are looked in device/hw specific
      directories. Hence for Killer 1525 (qca6174 hw2.1)
      ath10k will request:
      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: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
  5. 09 Apr, 2015 1 commit
  6. 01 Apr, 2015 1 commit
  7. 23 Mar, 2015 3 commits
  8. 15 Feb, 2015 3 commits
  9. 04 Feb, 2015 1 commit
  10. 13 Jan, 2015 1 commit
  11. 23 Dec, 2014 1 commit
  12. 08 Dec, 2014 2 commits
    • Peter Oh's avatar
      ath10k: add new wmi interface of NF cal period · a7bd3e99
      Peter Oh authored
      Introduce a new wmi interface controls noise floor (NF) calibration
      period via debugfs as firmware has introduced it on v10.2.
      It allows users to modify frequency of NF calibration in millisecond
      and changes RSSI reporting frequency consequently.
      Short calibration period will trigger more frequent NF calibration,
      so that RSSI reported in receive frames is more realistic.
      Till now calibration was done at 30 seconds.
      Signed-off-by: default avatarPeter Oh <poh@qca.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    • Michal Kazior's avatar
      ath10k: introduce wmi ops · d7579d12
      Michal Kazior authored
      Since the 10.x fw branch support was introduced it
      became apparent ath10k will need to be able to
      deal with different fw ABIs eventually.
      The patch creates an abstraction for dealing with
      command and event structures across different ABIs
      and mostly gets rid of the
      ATH10K_FW_FEATURE_WMI_10X flag usage.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
  13. 01 Dec, 2014 1 commit
  14. 25 Nov, 2014 3 commits
    • Michal Kazior's avatar
      ath10k: fix station count enforcement · cfd1061e
      Michal Kazior authored
      The number of peers isn't directly translatable to
      the number of stations because ath10k needs to
      reserve a few extra peers for special cases like
      multi-vif concurrency.
      The previous limit was 126 and 15 stations in AP
      mode for 10.x and main firmware branches
      respectively. The limit is now 128 and 16 which
      was the original intention.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    • Yanbo Li's avatar
      ath10k: add memory dump debugfs interface · 9f65ad25
      Yanbo Li authored
      Add mem_val debugfs file for dumping the firmware (target) memory and also for
      writing to the memory. The firmware memory is accessed through one file which
      uses position of the file as the firmware memory address. For example, with dd
      use skip parameter for the address.
      Beucase target memory width is 32 bits it's strongly recommended to use
      blocksize divisable with 4 when using this interface. For example, when using
      dd use bs=4 to set the block size to 4 and remember to divide both count and
      skip values with four.
      To read 4 kB chunk from address 0x400000:
      dd if=mem_value bs=4 count=1024 skip=1048576 | xxd -g1
      To write value 0x01020304 to address 0x400400:
      echo 0x01020304 | xxd -r | dd of=mem_value bs=4 seek=1048832
      To read 4 KB chunk of memory and then write back after edit:
      dd if=mem_value of=tmp.bin bs=4 count=1024 skip=1048576
      emacs tmp.bin
      dd if=tmp.bin of=mem_value bs=4 count=1024 seek=1048576
      Signed-off-by: default avatarYanbo Li <yanbol@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    • Yanbo Li's avatar
      ath10k: add register access debugfs interface · 077a3804
      Yanbo Li authored
      Debugfs files reg_addr and reg_val are used for reading and writing to the
      firmware (target) registers. reg_addr contains the address to be accessed,
      which also needs to be set first, and reg_value is when used for reading and
      writing the actual value in ASCII.
      To read a value from the firmware register 0x100000:
      # echo 0x100000 > reg_addr
      # cat reg_value
      To write value 0x2400 to address 0x100000:
      # echo 0x100000 > reg_addr
      # echo  0x2400 > reg_value
      Signed-off-by: default avatarYanbo Li <yanbol@qti.qualcomm.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
  15. 24 Nov, 2014 1 commit
  16. 30 Oct, 2014 1 commit
  17. 21 Oct, 2014 1 commit
    • Kalle Valo's avatar
      ath10k: retrieve calibration data from file · a58227ef
      Kalle Valo authored
      A frequent request have been to be able to provide calibration data from a
      file as some of the AP devices store the calibration data on an MTD partition.
      This patchset adds support for that and also makes it easier to add Device Tree
      support later on.
      The calibration data is found by using the id string provided by dev_name()
      using this format:
      With PCI the id string contains bus, slot and func values. For example for a
      PCI device in bus 2 slot 0, ath10k will try to retrieve a calibration data from
      a file:
      The calibration data sequence is:
      1. Check with request_firmware() if there's a calibration file
         ("cal-<bus>-<id>.bin") on the filesystem for this device. If yes, use that. If
         not, goto 2
      2. Check if otp.bin is able to successfully load the calibration data
         from OTP. If yes, use that. If not, goto 3.
      4. Print an error message that no calibration data found and stop driver
         initialization for this device.
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
  18. 07 Oct, 2014 1 commit
  19. 01 Oct, 2014 2 commits
  20. 29 Sep, 2014 5 commits
  21. 26 Sep, 2014 3 commits
  22. 23 Sep, 2014 1 commit
  23. 18 Sep, 2014 3 commits