1. 22 12月, 2009 1 次提交
  2. 24 11月, 2009 2 次提交
  3. 19 11月, 2009 2 次提交
  4. 12 11月, 2009 2 次提交
  5. 03 11月, 2009 1 次提交
  6. 28 10月, 2009 7 次提交
  7. 12 10月, 2009 1 次提交
  8. 08 10月, 2009 11 次提交
  9. 29 9月, 2009 1 次提交
    • R
      iwlwifi: fix 3945 ucode info retrieval after failure · b7a79404
      Reinette Chatre 提交于
      When hardware or uCode problem occurs driver captures significant
      information from device to enable debugging. The format of this information
      is different between 3945 and 4965 and later devices, yet currently the
      3945 uses the 4965 and later format. Fix this by adding a new library call
      that is initialized to the correct formatting routine based on device.
      
      This moves the iwlagn event and error log handling back to iwl-agn.c to
      make it part of iwlagn module.
      
      Also remove the 3945 sysfs file that triggers dump of event log - there is
      already a debugfs file that can do it for all drivers.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b7a79404
  10. 23 9月, 2009 1 次提交
  11. 20 8月, 2009 3 次提交
  12. 14 8月, 2009 1 次提交
  13. 05 8月, 2009 1 次提交
  14. 28 7月, 2009 2 次提交
    • W
      iwlwifi: Thermal Throttling Management - Part 1 · 39b73fb1
      Wey-Yi Guy 提交于
      Part 1 of Thermal Throttling Management -
      
      Thermal Throttling feature is used to put NIC into low power state when
      driver detect the Radio temperature reach pre-defined threshold
      
      Two Thermal Throttling Management Methods; this patch introduce the
      Legacy Thermal Management:
         IWL_TI_0: normal temperature, system power state
         IWL_TI_1: high temperature detect, low power state
         IWL_TI_2: higher temperature detected, lower power state
         IWL_TI_CT_KILL: critical temperature detected, lowest power state
      
      Once get into CT_KILL state, uCode go into sleep, driver will stop all
      the active queues, then move to IWL_TI_CT_KILL state; also set up 5
      seconds timer to toggle CSR flag, uCode wake up upon CSR flag change,
      then measure the temperature.
      If temperature is above CT_KILL exit threshold, uCode go backto sleep;
      if temperature is below CT_KILL exit threshold, uCode send Card State
      Notification response with appropriate CT_KILL status flag, and uCode
      remain awake, Driver receive Card State Notification Response and update
      the card temperature to the CT_KILL exit threshold.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      39b73fb1
    • W
      iwlwifi: critical temperature enter/exit condition · 672639de
      Wey-Yi Guy 提交于
      If advance thermal throttling is used the driver need to pass both
      "enter" and "exit" temperature to uCode.
      
      Using different critical temperature threshold for legacy and advance
      thermal throttling management based on the type of thermal throttling
      method is used except 1000.
      For 1000, it use advance thermal throttling critical temperature
      threshold, but with legacy thermal management implementation until ucode
      has the necessary implementations in place.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      672639de
  15. 25 7月, 2009 3 次提交
    • R
      iwlwifi: make debug level more user friendly · a562a9dd
      Reinette Chatre 提交于
      * Deprecate the "debug50" module parameter used to obtain
        5000 series and up debugging. Replace it with "debug" module
        parameter to match with original driver and be consistent
        between them. The "debug50" module parameter can still be used,
        except that the module parameter is not writable in keeping
        with its previous state. We currently just mark it as "deprecated"
        and do not have it in the feature-removal-schedule. Some more
        cleanup of module parameters needs to be done and can then be
        entered together.
      
      * Only make "debug" module parameters visible if the driver
        is compiled with CONFIG_IWLWIFI_DEBUG. This will eliminate
        a lot of confusion where users think they have set debug flags
        but yet cannot see any debug output.
      
      * Make module parameters writable. This eliminates the need for the
        "debug_level" sysfs file, which can now also be deprecated and
        added to feature-removal-schedule. This file is in significant
        use though with many iwlwifi documents and text referring users
        to it. We can thus not take its removal lightly and keep it around.
      
      With iwlcore shared between iwlagn and iwl3945 we really do not need
      debug module parameters for each but can instead have one debug
      module parameter for the iwlcore module. The same issue is here as
      with the sysfs file - a lot of iwlwifi documentation and text (like
      bug reports) rely on iwlagn and iwl3945 having this module parameter,
      so changing this to a module parameter of iwlcore will have significant
      impact and we do not do this for that reason.
      
      One consequence of this patch is that if a user is running a system
      with both 3945 and later hardware then the setting of the one module
      parameter will affect the value of the other. The likelihood of this
      seems low - and even if this setup is present it does not seem like an
      issue for both modules to run with the same debug level.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a562a9dd
    • J
      iwlwifi: Handle new firmware file with ucode build number in header · cc0f555d
      Jay Sternberg 提交于
      Adding new API version to account for change to ucode file format.  New
      header includes the build number of the ucode.  This build number is the
      SVN revision thus allowing for exact correlation to the code that
      generated it.
      
      The header adds the build number so that older ucode images can also be
      enhanced to include the build in the future.
      
      some cleanup in iwl_read_ucode needed to ensure old header not used and
      reduce unnecessary references through pointer with the data is already
      in heap variable.
      Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cc0f555d
    • W
      iwlagn: modify digital SVR for 1000 · 02c06e4a
      Wey-Yi Guy 提交于
      On 1000, there are two Switching Voltage Regulators (SVR). The first one
      apply digital voltage level (1.32V) for PCIe block and core. We need to
      use this regulator to solve a stability issue related to noisy DC2DC
      line in the silicon.
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      02c06e4a
  16. 11 7月, 2009 1 次提交