Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 08 5月, 2008 3 次提交
    • J
      mac80211: QoS related cleanups · e100bb64
      由 Johannes Berg 提交于 
      This
 * makes the queue number passed to drivers a u16
   (as it will be with skb_get_queue_mapping)
 * removes the useless queue number defines
 * splits hw->queues into hw->queues/ampdu_queues
 * removes the debugfs files for per-queue counters
 * removes some dead QoS code
 * removes the beacon queue configuration for IBSS
   so that the drivers now never get a queue number
   bigger than (hw->queues + hw->ampdu_queues - 1)
   for tx and only in the range 0..hw->queues-1 for
   conf_tx.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e100bb64
    • M
      b43: Don't disable IRQs in mac_suspend · e40ac414
      由 Michael Buesch 提交于 
      This patch removes the IRQ-disable from mac_suspend.
The main advantage of this is to get rid of the IRQ-sync call in mac_suspend.
We need to remove the MAC suspend bit from the IRQ service mask, as otherwise
the IRQ handler would race with us.
Signed-off-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e40ac414
    • 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
  3. 02 5月, 2008 1 次提交
  5. 01 5月, 2008 1 次提交
  7. 29 4月, 2008 1 次提交
  9. 24 4月, 2008 3 次提交
  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. 09 4月, 2008 7 次提交
  17. 25 3月, 2008 1 次提交
  19. 14 3月, 2008 1 次提交
  21. 08 3月, 2008 2 次提交
  23. 07 3月, 2008 1 次提交
  25. 01 3月, 2008 3 次提交
  27. 16 2月, 2008 3 次提交
  29. 06 2月, 2008 2 次提交
  31. 01 2月, 2008 2 次提交
  33. 29 1月, 2008 7 次提交