An error occurred fetching the project authors.
  1. 06 Jul, 2014 1 commit
  2. 25 Jun, 2014 1 commit
  3. 24 Jun, 2014 3 commits
  4. 22 May, 2014 3 commits
  5. 21 May, 2014 2 commits
  6. 19 May, 2014 1 commit
  7. 14 May, 2014 1 commit
  8. 13 May, 2014 1 commit
  9. 11 May, 2014 2 commits
  10. 06 May, 2014 4 commits
  11. 13 Apr, 2014 7 commits
  12. 06 Apr, 2014 1 commit
    • Avri Altman's avatar
      iwlwifi: mvm: Handle power management constraints for additional use-cases · 19889025
      Avri Altman authored
      Today, the driver logic looks for the conditions to disable
      power management albeit power management should be enabled
      in a very few distinct cases.
      This patch changes the driver logic to enable power
      management once the required conditions met.
      While at it, make some housekeeping and support a few
      additional use cases:
      
      a) Add support for a standalone p2p client:
         Power management should be enabled for a P2P client
         MAC only if the firmware supports it (TLV flag is set).
         Instead we used the DCM flag, therefore we didn't cover
         use cases that did not include the DCM flag.
      
      b) Add support to Same-Channel-Mode (SCM):
         If both clients share the same channel (SCM), and there
         are no other active vifs in the system, power management
         should be enabled only if the firmware supports this
         (TLV flag is set).
      
      c) Fix power management logic for GO/AP:
         Today, when we detect an active GO / AP MAC - we disable
         power management for all the vifs altogether.
         Actually, the correct behavior is to enable power
         management on a client if on a different channel
         (based on the firmware capabilities).
      
      d) Housekeeping - Along with that, this patch includes some
         code-reorganizing: Today the logic of disabling power is
         scattered across several functions, specifically in the
         iterator. For the sake of both readability and
         scalability, we moved this logic to its applicable
         function, leaving the iterator gather information only.
         Furthermore, as power management is a MAC-related
         attribute, we moved the power management member to the
         iwl_mvm_vif structure.
      Signed-off-by: default avatarAvri Altman <avri.altman@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      19889025
  13. 18 Mar, 2014 3 commits
    • Alexander Bondar's avatar
      iwlwifi: mvm: configure low latency dependent scan parameters · 50df8a30
      Alexander Bondar authored
      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: default avatarAlexander Bondar <alexander.bondar@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      50df8a30
    • Emmanuel Grumbach's avatar
      iwlwifi: mvm: BT Coex - add debugfs hook to set BT Tx priority · cdb00563
      Emmanuel Grumbach authored
      In order to debug the firmware, we need to be able to set
      the BT priority of WiFi packets. This priority is set based
      on the type of the packet (control frames, EAPOL etc...).
      For debugging purposes, allow to override this priority by
      a debugfs controlled value.
      Enable this feature that needs this priority to be able to
      test it.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      cdb00563
    • Emmanuel Grumbach's avatar
      iwlwifi: mvm: send udev event upon firmware error to dump logs · 1bd3cbc1
      Emmanuel Grumbach authored
      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: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      1bd3cbc1
  14. 16 Mar, 2014 3 commits
  15. 11 Mar, 2014 4 commits
  16. 09 Mar, 2014 3 commits