Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 22 9月, 2011 3 次提交
    • O
      hwspinlock/core: register a bank of hwspinlocks in a single API call · 300bab97
      由 Ohad Ben-Cohen 提交于 
      Hardware Spinlock devices usually contain numerous locks (known
devices today support between 32 to 256 locks).

Originally hwspinlock core required drivers to register (and later,
when needed, unregister) each lock separately.

That worked, but required hwspinlocks drivers to do a bit extra work
when they were probed/removed.

This patch changes hwspin_lock_{un}register() to allow a bank of
hwspinlocks to be {un}registered in a single invocation.

A new 'struct hwspinlock_device', which contains an array of 'struct
hwspinlock's is now being passed to the core upon registration (so
instead of wrapping each struct hwspinlock, a priv member has been added
to allow drivers to piggyback their private data with each hwspinlock).

While at it, several per-lock members were moved to be per-device:
1. struct device *dev
2. struct hwspinlock_ops *ops

In addition, now that the array of locks is handled by the core,
there's no reason to maintain a per-lock 'int id' member: the id of the
lock anyway equals to its index in the bank's array plus the bank's
base_id.
Remove this per-lock id member too, and instead use a simple pointers
arithmetic to derive it.

As a result of this change, hwspinlocks drivers are now simpler and smaller
(about %20 code reduction) and the memory footprint of the hwspinlock
framework is reduced.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      300bab97
    • J
      hwspinlock/core: use a mutex to protect the radix tree · 93b465c2
      由 Juan Gutierrez 提交于 
      Since we're using non-atomic radix tree allocations, we
should be protecting the tree using a mutex and not a
spinlock.

Non-atomic allocations and process context locking is good enough,
as the tree is manipulated only when locks are registered/
unregistered/requested/freed.

The locks themselves are still protected by spinlocks of course,
and mutexes are not involved in the locking/unlocking paths.

Cc: <stable@kernel.org>
Signed-off-by: NJuan Gutierrez <jgutierrez@ti.com>
[ohad@wizery.com: rewrite the commit log, #include mutex.h, add minor
commentary]
[ohad@wizery.com: update register/unregister parts in hwspinlock.txt]
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      93b465c2
    • O
      hwspinlock/core: simplify 'owner' handling · e467b642
      由 Ohad Ben-Cohen 提交于 
      Use struct device_driver's owner member instead of asking drivers to
explicitly pass the owner again.

This simplifies drivers and also save some memory, since there's no
point now in maintaining a separate owner pointer per hwspinlock.
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      e467b642
  3. 13 9月, 2011 1 次提交
  5. 11 9月, 2011 1 次提交
  7. 06 9月, 2011 1 次提交
  9. 25 8月, 2011 2 次提交
  11. 23 8月, 2011 1 次提交
  13. 19 8月, 2011 1 次提交
  15. 15 8月, 2011 2 次提交
  17. 14 8月, 2011 10 次提交
  19. 11 8月, 2011 1 次提交
  21. 10 8月, 2011 1 次提交
  23. 08 8月, 2011 1 次提交
  25. 07 8月, 2011 1 次提交
  27. 06 8月, 2011 3 次提交
  29. 05 8月, 2011 1 次提交
    • V
      cfq-iosched: Add documentation about idling · 4931402a
      由 Vivek Goyal 提交于 
      There are always questions about why CFQ is idling on various conditions.
Recent ones is Christoph asking again why to idle on REQ_NOIDLE. His
assertion is that XFS is relying more and more on workqueues and is
concerned that CFQ idling on IO from every workqueue will impact
XFS badly.

So he suggested that I add some more documentation about CFQ idling
and that can provide more clarity on the topic and also gives an
opprotunity to poke a hole in theory and lead to improvements.

So here is my attempt at that. Any comments are welcome.
Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      4931402a
  31. 04 8月, 2011 3 次提交
  33. 03 8月, 2011 7 次提交