1. 16 9月, 2014 1 次提交
    • A
      iwlwifi: mvm: prepare for scheduler config command · 3edf8ff6
      Avri Altman 提交于
      The scheduler is a HW sub-block that directs the work of the Flow
      Handler by issuing requests for frame transfers, specifying source
      and destination. Its primary function is to allocate flows into the
      TX FIFOs based upon a pre-determined mapping.
      
      The driver has some responsibilities to the scheduler, namely
      initialising and maintaining the hardware registers. This is
      currently done by directly accessing them, which can cause races
      with the firmware also accessing the registers.
      
      To address this problem, change the driver to no longer directly
      access the registers but go through the firmware for this if the
      firmware has support for DQA and thus the new command.
      Signed-off-by: NAvri Altman <avri.altman@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      3edf8ff6
  2. 04 9月, 2014 2 次提交
  3. 08 7月, 2014 2 次提交
  4. 06 7月, 2014 2 次提交
  5. 22 5月, 2014 1 次提交
  6. 19 5月, 2014 1 次提交
  7. 13 5月, 2014 2 次提交
  8. 07 5月, 2014 2 次提交
  9. 13 4月, 2014 1 次提交
  10. 19 3月, 2014 3 次提交
    • J
      iwlwifi: mvm: ignore unchanged low-latency flag · 3510aea4
      Johannes Berg 提交于
      If the low-latency update is called but there's no change then
      ignore the update instead of triggering all the required work.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      3510aea4
    • A
      iwlwifi: mvm: configure low latency dependent scan parameters · 50df8a30
      Alexander Bondar 提交于
      In case of system low latency configure passive scan to be fragmented.
      Set the following scan parameters for both immediate and scheduled scan:
       - passive scan fragment duration = 20ms
       - out-of-channel time = 70ms
       - suspend time = 105ms
      Restructure channel's active/passive dwell time configuration to better
      suit the above change.
      
      The idea is that under low latency traffic passive scan is fragmented,
      i.e. that dwell on a particular channel will be fragmented. Each
      fragment dwell time is 20ms and fragments period is 105ms. Skipping to
      next channel will be delayed by the same period (105ms). So suspend_time
      parameter describing both fragments and channels skipping periods is set
      to 105ms. This value is chosen so that overall passive scan duration
      will not be too long. Max_out_time in this case is set to 70ms, so for
      active scanning operating channel will be left for 70ms while for
      passive still for 20ms (fragment dwell).
      Signed-off-by: NAlexander Bondar <alexander.bondar@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      50df8a30
    • E
      iwlwifi: mvm: send udev event upon firmware error to dump logs · 1bd3cbc1
      Emmanuel Grumbach 提交于
      When the firmware asserts, the driver will dump the firmware
      state to an internal buffer. This buffer is kept aside until
      it is dumped through debugfs. Once an external application
      fetched the data, the buffer is freed and a new buffer can
      be allocated in case another assert occurs.
      
      A udev event is sent to trigger an external application.
      
      A simple rule like:
      DRIVER=="iwlwifi", ACTION=="change", RUN+="/sbin/dump_sram.sh"
      
      can fetch the data from debugfs.
      
      Here is my dump_sram.sh:
      
      phyname=$(basename ${DEVPATH})
      date=$(date +%F_%H_%M)
      filename=/var/log/iwl-sram-${phyname}-${date}.bin
      cat /sys/kernel/debug/ieee80211/${phyname}/iwlwifi/iwlmvm/fw_error_dump > ${filename}
      
      The current SRAM size is 80KB so, currently:
      $ ls -lh iwl-sram-phy0-2014-03-16_13_14.bin
      -rw-r--r-- 1 emmanuel emmanuel 81K Mar 16 13:15 iwl-sram-phy0-2014-03-16_13_14.bin
      
      and after compression:
      $ ls -lh iwl-sram-phy0-2014-03-16_13_14.bin.xz
      -rw-r--r-- 1 emmanuel emmanuel 13K Mar 16 13:15 iwl-sram-phy0-2014-03-16_13_14.bin.xz
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      1bd3cbc1
  11. 13 2月, 2014 2 次提交
  12. 07 2月, 2014 2 次提交
  13. 04 2月, 2014 7 次提交
  14. 31 1月, 2014 1 次提交
  15. 14 1月, 2014 1 次提交
  16. 01 1月, 2014 1 次提交
  17. 10 12月, 2013 2 次提交
  18. 03 10月, 2013 1 次提交
  19. 16 7月, 2013 1 次提交
  20. 30 5月, 2013 1 次提交
    • J
      iwlwifi: mvm: implement D3 testing · debff618
      Johannes Berg 提交于
      For testing the D3 (WoWLAN) firmware, it is useful to be able
      to run the firmware with instrumentation while the host isn't
      sleeping and can poke at the firmware debug logging etc.
      
      Implement this by a debugfs file. When the file is opened the
      D3 firmware is loaded and all regular commands are blocked.
      While the file is being read, poll the firmware's PME status
      flag and report EOF once it changes to non-zero. When it is
      closed, do (most of) the resume processing. This lets a user
      just "cat" the file. Pressing Ctrl-C to kill the cat process
      will resume the firwmare as though the platform resumed for
      non-wireless reason and when the firmware wants to wake up
      reading from the file automatically completes.
      
      Unlike in real suspend, only disable interrupts and don't
      reset the TX/RX hardware while in the test mode. This is a
      workaround for some interrupt problems that happen only when
      the PCIe link isn't fully reset (presumably by changing the
      PCI config space registers which the core PCI code does.)
      
      Note that while regular operations are blocked from sending
      commands to the firmware, they could still be made and cause
      strange mac80211 issues. Therefore, while using this testing
      feature you need to be careful to not try to disconnect, roam
      or similar, and will see warnings for such attempts.
      
      Als note that this requires an upcoming firmware change to
      tell the driver the location of the PME status flag in SRAM.
      D3 test will fail if the firmware doesn't report the pointer.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      debff618
  21. 29 5月, 2013 1 次提交
  22. 16 4月, 2013 1 次提交
  23. 04 4月, 2013 1 次提交
  24. 06 3月, 2013 1 次提交