1. 03 4月, 2010 1 次提交
  2. 26 3月, 2010 1 次提交
  3. 30 1月, 2010 2 次提交
  4. 27 1月, 2010 1 次提交
  5. 20 1月, 2010 1 次提交
  6. 19 11月, 2009 1 次提交
  7. 28 10月, 2009 3 次提交
  8. 08 10月, 2009 2 次提交
    • W
      iwlwifi: reliable entering of critical temperature state · 7812b167
      Wey-Yi Guy 提交于
      When uCode detects critical temperature it should send "card state
      notification" interrupt to driver and then shut itself down to prevent
      overheating. There is a race condition where uCode shuts down before it
      can deliver the interrupt to driver.
      Additional method provided here for driver to enter CT_KILL state based
      on temperature reading.
      
      How it works:
      Method 1:
      If driver receive "card state notification" interrupt from uCode; it
      enters "CT_KILL" state immediately
      
      Method 2:
      If the last temperature report by Card reach Critical temperature,
      driver will send "statistic notification" request to uCode to verify the
      temperature reading, if driver can not get reply from uCode within
      300ms, driver will enter CT_KILL state automatically.
      
      Method 3:
      If the last temperature report by Card did not reach Critical
      temperature, but uCode already shut down due to critical temperature.
      All the host commands send to uCode will not get process by uCode;
      when command queue reach the limit, driver will check the last reported
      temperature reading, if it is within pre-defined margin, enter "CT_KILL"
      state immediately. In this case, when uCode ready to exit from "CT_KILL" state,
      driver need to restart the adapter in order to reset all the queues and
      resume normal operation.
      
      One additional issue being address here, when system is in CT_KILL
      state, both tx and rx already stopped, but driver still can send host
      command to uCode, it will flood the command queue since card was not
      responding; adding STATUS_CT_KILL flag to reject enqueue host commands
      to uCode if it is in CT_KILL state, when uCode is ready to come out of
      CT_KILL, driver will clear  the STATUS_CT_KILL bit and allow enqueue the host
      commands to uCode to recover from CT_KILL state.
      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>
      7812b167
    • J
      iwlwifi: support idle for 6000 series hw · 78f5fb7f
      Johannes Berg 提交于
      Using powersave while idle saves a lot of power, but
      we've had problems with this on some cards (5150 has
      been reported to be problematic). However, on the new
      6000 series we're seeing no problems, so for now let
      that hardware benefit from idle mode, we can look at
      the problems with other hardware one by one and then
      enable those once we figure out the problems.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      78f5fb7f
  9. 23 9月, 2009 1 次提交
  10. 15 9月, 2009 1 次提交
  11. 01 9月, 2009 2 次提交
  12. 14 8月, 2009 6 次提交
  13. 28 7月, 2009 2 次提交
    • W
      iwlwifi: Thermal Throttling Management - part 2 · 46f9381a
      Wey-Yi Guy 提交于
      Part 2 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
      Advance Thermal Throttling:
      TI-0: system power index, no tx/rx restriction, HT enabled
      TI-1: power index 5, 1 spatial stream Tx, multiple spatial stream Rx, HT
      enabled
      TI-2: power index 5: 1 spatial stream Tx, 1 spatial stream Rx, HT
      disabled
      TI-CT-KILL: power index 5, no Tx, no Rx, HT disabled
      
      For advance Thermal Throttling, CT_KILL_ENTER threshold and CT_KILL_EXIT
      threshold are different; uCode will not stay awake until reach
      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>
      46f9381a
    • 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
  14. 12 5月, 2009 2 次提交
    • J
      iwlwifi: clean up PS code · 7af2c460
      Johannes Berg 提交于
      This removes all the dead code that tries to adjust the power
      saving level based on the system AC state (inacceptable policy
      in the kernel) or based on overtemp conditions (unused).
      
      Also, pass _all_ policy wrt. enabling PS to mac80211, since
      we do not use the power_disabled internally I now use that to
      mirror the mac80211 CONF_PS setting. When mac80211 turns off
      CONF_PS we follow suit. This means that the user power level
      (which can currently only be set from sysfs) is not touched
      for mac80211 powersave changes.
      
      This means no "association status" checks are necessary since
      mac80211 will not allow power save to be enabled when not
      associated.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NMohamed Abbas <mohamed.abbas@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7af2c460
    • J
      iwlwifi: fix PS disable status race · f0f74a0e
      Johannes Berg 提交于
      iwlwifi internally needs to keep track of whether PS
      is enabled in the firmware or not. To do this, it keeps
      a bit in the status flags, called STATUS_POWER_PMI.
      
      The code to set this bit looks as follows:
      
      static int iwl_set_power(struct iwl_priv *priv, void *cmd)
      {
      	return iwl_send_cmd_pdu_async(priv, POWER_TABLE_CMD,
      				      sizeof(struct iwl_powertable_cmd),
      				      cmd, NULL);
      }
      
      int iwl_power_update_mode(...)
      {
      	[...]
      	if (final_mode != IWL_POWER_MODE_CAM)
      		set_bit(STATUS_POWER_PMI, &priv->status);
      
      	iwl_update_power_cmd(priv, &cmd, final_mode);
      	cmd.keep_alive_beacons = 0;
      
      	if (final_mode == IWL_POWER_INDEX_5)
      		cmd.flags |= IWL_POWER_FAST_PD;
      
      	ret = iwl_set_power(priv, &cmd);
      
      	if (final_mode == IWL_POWER_MODE_CAM)
      		clear_bit(STATUS_POWER_PMI, &priv->status);
      	else
      		set_bit(STATUS_POWER_PMI, &priv->status);
      
      	if (priv->cfg->ops->lib->update_chain_flags && update_chains)
      		priv->cfg->ops->lib->update_chain_flags(priv);
      	[...]
      }
      
      Now, this bit really needs to track what the _firmware_
      thinks, not what the driver thinks. Therefore, there is
      a race condition here -- the driver sets the bit before
      it knows that the async command sent to the card in the
      iwl_set_power function has been processed. As a result,
      the call to update_chain_flags() may think that the card
      has been woken up (PMI bit cleared) while in reality it
      hasn't processed the async POWER_TABLE_CMD yet.
      
      This leads to bugs -- any commands the update_chain_flags
      function sends can get stuck and subsequent commands also
      fail.
      
      The fix is almost trivial: since there's no reason to send
      an async command here (in fact, there almost never should
      be since many mac80211 callbacks can sleep) just make the
      function wait for the card to process the command and then
      return and clear the PMI bit.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NMohamed Abbas <mohamed.abbas@intel.com>
      Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f0f74a0e
  15. 28 3月, 2009 1 次提交
  16. 14 2月, 2009 1 次提交
  17. 10 2月, 2009 2 次提交
  18. 30 1月, 2009 3 次提交
  19. 13 12月, 2008 2 次提交
  20. 22 11月, 2008 1 次提交
  21. 01 11月, 2008 1 次提交
  22. 16 9月, 2008 1 次提交
  23. 12 9月, 2008 2 次提交