1. 12 2月, 2010 1 次提交
  2. 26 1月, 2010 2 次提交
    • R
      iwlwifi: make broadcast station addition generic · 3459ab5a
      Reinette Chatre 提交于
      Add function pointer for broadcast station addition so that we can call it
      in from iwlcore at a later time. We only distinguish between iwlagn and
      iwl3945 broadcast station addition. For the iwl3945 station addition we add
      that function to iwlcore since that is where most station functionality
      resides, making it part of iwl3945 will require significant code
      reorganization that will dilute station management functionality. This
      seems to be an efficient solution.
      
      It may seem as though we are removing error checking when adding the 3945
      broadcast station but this error checking was never really necessary since
      the function returns the station id and the broadcast station id is always
      set.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3459ab5a
    • T
      iwlwifi: Tune radio to prevent unexpected behavior · 3e4fb5fa
      Trieu 'Andrew' Nguyen 提交于
      We have seen the throughput dropped due to external noisy environment
      and the radio is out of tune.  There are lot of plcp errors indicating
      this condition. Eventually the station can get de-authenticated by the
      Access Point.  By resetting and tuning the radio, the plcp errors are
      reduced or eliminated and the throughput starts to rise.
      
      To prevent unexpected behavior such as drop in throughput or deauthentication,
      - The change provides the driver feature to monitor and tune the radio base on
      the statistics notification from the uCode.
      - It also allows the setting of the plcp error rate threshold via
      the plcp_delta under debugfs interface.
      Signed-off-by: NTrieu 'Andrew' Nguyen <trieux.t.nguyen@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3e4fb5fa
  3. 20 1月, 2010 1 次提交
  4. 12 1月, 2010 1 次提交
  5. 05 1月, 2010 1 次提交
  6. 23 12月, 2009 2 次提交
  7. 22 12月, 2009 1 次提交
  8. 24 11月, 2009 2 次提交
  9. 19 11月, 2009 2 次提交
  10. 12 11月, 2009 2 次提交
  11. 28 10月, 2009 8 次提交
  12. 12 10月, 2009 1 次提交
  13. 08 10月, 2009 7 次提交
  14. 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
  15. 23 9月, 2009 2 次提交
  16. 15 9月, 2009 1 次提交
  17. 20 8月, 2009 1 次提交
  18. 14 8月, 2009 3 次提交
    • R
      iwlwifi: revert uCode Alive notification with timeout · c03ea162
      Reinette Chatre 提交于
      commit "iwlwifi: uCode Alive notification with timeout" introduced a more
      reliable mechanism for ucode loading. Unfortunately we hit a problem with
      it frequently enough to make a 4965 unusable. The problem can be seen in
      debug log below. What this code attempts is to set runtime ucode up to
      load, start a timer to wait for the alive response from runtime ucode, and
      if it times out it tries again. As can be seen below we receive the alive
      response and wake the waiting task _before_ the tasks starts waiting. The
      task thus times out as the alive response is not received while it is
      waiting for it and it restarts the device. This starts the cycle all over
      again.
      
      [29739.000819] ieee80211 phy0: U iwl_mac_start enter
      [29739.005751] ieee80211 phy0: U iwl_prepare_card_hw iwl_prepare_card_hw enter
      [29739.012798] ieee80211 phy0: U iwl_set_hw_ready hardware ready
      [29739.057200] ieee80211 phy0: U iwl4965_load_bsm Begin load bsm
      [29739.063366] ieee80211 phy0: U iwl4965_verify_bsm Begin verify bsm
      [29739.072485] ieee80211 phy0: U iwl4965_verify_bsm BSM bootstrap uCode image OK
      [29739.079671] ieee80211 phy0: U iwl4965_load_bsm BSM write complete, poll 0 iterations
      [29739.257019] ieee80211 phy0: I iwl_rx_reply_alive Alive ucode status 0x00000001 revision 0x1 0x9
      [29739.260964] ieee80211 phy0: I iwl_rx_reply_alive Initialization Alive received.
      [29739.260964] ieee80211 phy0: U __iwl_up iwlagn is coming up
      [29739.278571] ieee80211 phy0: U iwl_mac_start Start UP work done.
      [29739.284509] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 788
      [29739.292432] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 10312
      [29739.302004] ieee80211 phy0: U iwl_verify_ucode Initialize uCode is good in inst SRAM
      [29739.309746] ieee80211 phy0: U iwl4965_hw_get_temperature Running temperature calibration
      [29739.317833] ieee80211 phy0: U iwl4965_hw_get_temperature Calib values R[1-3]: -36 13522 -13496 R4: -2726
      [29739.327337] ieee80211 phy0: U iwl4965_hw_get_temperature Calibrated temperature: 310K, 37C
      [29739.335598] ieee80211 phy0: U iwl4965_init_alive_start Initialization Alive received.
      [29739.343477] ieee80211 phy0: U iwl4965_set_ucode_ptrs Runtime uCode pointers are set.
      [29739.351283] ieee80211 phy0: I iwl_rx_reply_alive Alive ucode status 0x00000001 revision 0x1 0x0
      [29739.355210] ieee80211 phy0: I iwl_rx_reply_alive Runtime Alive received.
      [29739.366731] iwlagn 0000:03:00.0: Runtime uCode already alive? Waiting for alive anyway
      [29743.284110] iwlagn 0000:03:00.0: START_ALIVE timeout after 4000ms.
      [29743.290337] ieee80211 phy0: U iwl_mac_add_interface enter: type 2
      [29744.364089] iwlagn 0000:03:00.0: Runtime timeout after 5000ms
      [29744.370882] ieee80211 phy0: U iwl_alive_start Runtime Alive received.
      [29744.377347] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 788
      [29744.385287] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 10312
      [29744.393397] ieee80211 phy0: U iwlcore_verify_inst_sparse ucode inst image size is 94720
      [29744.415835] ieee80211 phy0: U iwl_verify_ucode Runtime uCode is good in inst SRAM
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c03ea162
    • W
      iwlwifi: name changed from "fat" to "ht40" · 7aafef1c
      Wey-Yi Guy 提交于
      Rename "fat" to "ht40"
      The term "fat channel" is deprecated in favor of "HT40"
      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>
      7aafef1c
    • R
      iwlwifi: re-introduce per device debugging · 3d816c77
      Reinette Chatre 提交于
      Commit "iwlwifi: make debug level more user friendly" cleaned up the
      debug level handling. In doing so it created a single global debug
      level for all devices. Some setups do consits of more that one iwlwifi
      device and in these setups there is a requirement that debug levels
      should be unique per device.
      
      We now re-introduce the per device debugging while maintaining the
      cleanup effort of the previous patch.
      
      The maintain the global debug level and now introduce a per-device debug
      level that will be used if it (the per-device debug level) is set. The
      per-device debug level can be controlled via the debug_level sysfs file
      while the global debug level is controlled by the debug module parameter.
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Acked-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3d816c77
  19. 28 7月, 2009 1 次提交
    • 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