Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 5月, 2008 2 次提交
    • M
      b43: Rewrite LO calibration algorithm · f5eda47f
      由 Michael Buesch 提交于 
      This patch distributes the Local Oscillator calibration bursts over time,
so that calibration only happens when it's actually needed.
Currently we periodically perform a recalibration of the whole table.
The table is huge and this takes lots of time. Additionally only small bits
of the table are actually needed at a given time. So instead of maintaining
a huge table with all possible calibration values, we create dynamic calibration
settings that
a) We only calibrate when they are actually needed.
b) Are cached for some time until they expire.
So a recalibration might happen if we need a calibration setting that's not
cached, or if the active calibration setting expires.
Currently the expire timeout is set to 30 seconds. We may raise that in future.

This patch reduces overall memory consumption by nuking the
huge static calibration tables.

This patch has been tested on several 4306, 4311 and 4318 flavours.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f5eda47f
    • I
      mac80211: Replace ieee80211_tx_control->key_idx with ieee80211_key_conf · 1c014420
      由 Ivo van Doorn 提交于 
      The hw_key_idx inside the ieee80211_key_conf structure does
not provide all the information drivers might need to perform
hardware encryption.

This is in particular true for rt2x00 who needs to know the
key algorithm and whether it is a shared or pairwise key.

By passing the ieee80211_key_conf pointer it assures us that
drivers can make full use of all information that it should know
about a particular key.

Additionally this patch updates all drivers to grab the hw_key_idx from
the ieee80211_key_conf structure.

v2: Removed bogus u16 cast
v3: Add warning about ieee80211_tx_control pointers
v4: Update warning about ieee80211_tx_control pointers
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1c014420
  3. 02 5月, 2008 1 次提交
  5. 01 5月, 2008 1 次提交
  7. 29 4月, 2008 1 次提交
  9. 24 4月, 2008 4 次提交
  11. 20 4月, 2008 1 次提交
    • R
      PM: Remove destroy_suspended_device() · b844eba2
      由 Rafael J. Wysocki 提交于 
      After 2.6.24 there was a plan to make the PM core acquire all device
semaphores during a suspend/hibernation to protect itself from
concurrent operations involving device objects.  That proved to be
too heavy-handed and we found a better way to achieve the goal, but
before it happened, we had introduced the functions
device_pm_schedule_removal() and destroy_suspended_device() to allow
drivers to "safely" destroy a suspended device and we had adapted some
drivers to use them.  Now that these functions are no longer necessary,
it seems reasonable to remove them and modify their users to use the
normal device unregistration instead.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b844eba2
  13. 17 4月, 2008 1 次提交
    • M
      b43: Add fastpath to b43_mac_suspend() · ba380013
      由 Michael Buesch 提交于 
      This adds a fastpath for the common workloads to the
MAC suspend flushing.
In common workloads the FIFO flush will take between 100 and
200 microseconds. So we want to avoid calling msleep() in the
common case, as it will waste over 800 microseconds + scheduler
overhead.

This fastpath will hit in workloads where only small chunks
of data are transmitted (downloading a file) or when a TX rate bigger
or equal to 24MBit/s is used when transmitting lots of stuff (iperf).
So in the commonly used workloads it will basically always hit.

In case the fastpath is not hit, there's no real performance or latency
disadvantage from that.

And yes, I measured this. So this is not one of these
bad Programmer Likeliness Assumptions that are always wrong. ;)
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ba380013
  15. 16 4月, 2008 1 次提交
    • M
      ssb: Fix usage of struct device used for DMAing · 4ac58469
      由 Michael Buesch 提交于 
      This fixes DMA on architectures where DMA is nontrivial, like PPC64.
We must use the host-device's (PCI) struct device for any DMA
operation instead of the SSB device. For this we add a new
struct device pointer to the SSB device structure that will always
point to the right device for DMAing.

Without this patch b43 and b44 drivers won't work on complex-DMA
architectures, that for example need dev->archdata for DMA operations.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4ac58469
  17. 09 4月, 2008 9 次提交
  19. 02 4月, 2008 2 次提交
  21. 26 3月, 2008 1 次提交
  23. 25 3月, 2008 2 次提交
  25. 14 3月, 2008 3 次提交
  27. 08 3月, 2008 4 次提交
  29. 07 3月, 2008 1 次提交
  31. 01 3月, 2008 4 次提交
  33. 28 2月, 2008 1 次提交
  35. 16 2月, 2008 1 次提交