1. 19 3月, 2014 1 次提交
    • 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
  2. 12 3月, 2014 1 次提交
    • E
      iwlwifi: mvm: BT Coex add support for Co-running block · b9fae2d5
      Emmanuel Grumbach 提交于
      7265 features a new calibration which is called antenna
      coupling. The purpose of this calibration (which isn't
      really a calibration), is to measure the isolation between
      the antennas and that can give us useful information for
      the Coex modules.
      
      With this information, we can tune the LookUpTables (LUTs)
      that define the BT / WiFi contention policy.
      
      The LUTs currently contain dummy values - but they will be
      updated soon.
      
      While at it, change the current code to stop duplicate the
      host command while sending. This was needed back then, when
      the command was short enough to be allocated on the stack.
      Since then, the command grew a lot and is now allocated on
      the heap - hence we can use the NOCOPY option instead.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      b9fae2d5
  3. 09 3月, 2014 2 次提交
  4. 21 2月, 2014 1 次提交
  5. 13 2月, 2014 2 次提交
  6. 04 2月, 2014 5 次提交
  7. 14 1月, 2014 1 次提交
  8. 01 1月, 2014 2 次提交
  9. 10 12月, 2013 5 次提交
  10. 26 11月, 2013 1 次提交
  11. 29 10月, 2013 1 次提交
  12. 18 10月, 2013 1 次提交
  13. 11 10月, 2013 1 次提交
  14. 03 10月, 2013 3 次提交
  15. 16 8月, 2013 2 次提交
  16. 12 8月, 2013 1 次提交
  17. 09 8月, 2013 1 次提交
  18. 06 8月, 2013 1 次提交
  19. 31 7月, 2013 2 次提交
  20. 16 7月, 2013 2 次提交
  21. 25 6月, 2013 1 次提交
  22. 18 6月, 2013 1 次提交
  23. 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
  24. 29 5月, 2013 1 次提交