1. 12 7月, 2011 1 次提交
  2. 18 6月, 2011 2 次提交
  3. 11 6月, 2011 1 次提交
  4. 19 4月, 2011 2 次提交
  5. 08 4月, 2011 2 次提交
  6. 22 2月, 2011 3 次提交
  7. 01 2月, 2011 1 次提交
  8. 29 1月, 2011 1 次提交
  9. 25 11月, 2010 3 次提交
  10. 16 11月, 2010 1 次提交
  11. 06 10月, 2010 1 次提交
    • W
      iwlagn: reduce redundant parameter definitions · 7cb1b088
      Wey-Yi Guy 提交于
      move paramater definitions to a device paramater structure only
      leaving the device name, which antennas are used and what firmware
      file to use in the iwl_cfg structure.  this will not completely
      remove the redundancies but greatly reduce them for devices that
      only vary by name or antennas.  the parameters that are more
      likely to change within a given device family are left in iwl_cfg.
      also separate bt param structure added to help reduce more.
      Signed-off-by: NJay Sternberg <jay.e.sternberg@intel.com>
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      7cb1b088
  12. 25 8月, 2010 2 次提交
  13. 11 5月, 2010 1 次提交
  14. 03 4月, 2010 1 次提交
  15. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  16. 26 3月, 2010 1 次提交
  17. 30 1月, 2010 2 次提交
  18. 27 1月, 2010 1 次提交
  19. 20 1月, 2010 1 次提交
  20. 19 11月, 2009 1 次提交
  21. 28 10月, 2009 3 次提交
  22. 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
  23. 23 9月, 2009 1 次提交
  24. 15 9月, 2009 1 次提交
  25. 01 9月, 2009 2 次提交
  26. 14 8月, 2009 2 次提交
    • J
      iwlwifi: automatically adjust sleep level · e312c24c
      Johannes Berg 提交于
      Depending on required latency requested by pm_qos (via mac80211)
      we can automatically adjust the sleep state. Also, mac80211 has
      a user-visible dynamic sleep feature where we are supposed to
      stay awake after sending/receiving frames to better receive
      response frames to our packets, this can be integrated into the
      sleep command.
      
      Currently, and this patch doesn't change that yet, we default
      to using sleep level 1 if PS is enabled. With a module parameter
      to iwlcore, automatic adjustment to changing network latency
      requirements can be enabled -- this isn't yet the default due
      to requiring more testing.
      
      The goal is to enable automatic adjustment and then go into the
      deepest possible sleep state possible depending on the networking
      latency requirements.
      
      This patch does, however, enable IEEE80211_HW_SUPPORTS_DYNAMIC_PS
      to avoid the double-timer (one in software and one in the device)
      when transmitting -- the exact timeout may be ignored but that is
      not of big concern.
      
      Note also that we keep the hard-coded power indices around for
      thermal throttling -- the specification of that calls for using
      the specified power levels. Those can also be selected in debugfs
      to allow easier testing of such parameters.
      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>
      e312c24c
    • J
      iwlwifi: refactor some thermal throttle code · 3ad3b92a
      Johannes Berg 提交于
      Some of the thermal throttle data structures and code
      are really very intermingled with the sleep (power)
      control code. They really do belong together in a way
      since the thermal throttle code uses powersaving to
      achieve its goal, but it's making it hard to work on
      the powersave code. Split this up to make that easier.
      I've also changed the antenna defines to an enum and
      used the same enum for RX and TX.
      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>
      3ad3b92a