diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/laptops/thinkpad-acpi.txt | 5 | ||||
| -rw-r--r-- | Documentation/spinlocks.txt | 45 |
2 files changed, 12 insertions, 38 deletions
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 1565eefd6fd..61815483efa 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -534,6 +534,8 @@ Events that are never propagated by the driver: 0x2404 System is waking up from hibernation to undock 0x2405 System is waking up from hibernation to eject bay 0x5010 Brightness level changed/control event +0x6000 KEYBOARD: Numlock key pressed +0x6005 KEYBOARD: Fn key pressed (TO BE VERIFIED) Events that are propagated by the driver to userspace: @@ -545,6 +547,8 @@ Events that are propagated by the driver to userspace: 0x3006 Bay hotplug request (hint to power up SATA link when the optical drive tray is ejected) 0x4003 Undocked (see 0x2x04), can sleep again +0x4010 Docked into hotplug port replicator (non-ACPI dock) +0x4011 Undocked from hotplug port replicator (non-ACPI dock) 0x500B Tablet pen inserted into its storage bay 0x500C Tablet pen removed from its storage bay 0x6011 ALARM: battery is too hot @@ -552,6 +556,7 @@ Events that are propagated by the driver to userspace: 0x6021 ALARM: a sensor is too hot 0x6022 ALARM: a sensor is extremely hot 0x6030 System thermal table changed +0x6040 Nvidia Optimus/AC adapter related (TO BE VERIFIED) Battery nearly empty alarms are a last resort attempt to get the operating system to hibernate or shutdown cleanly (0x2313), or shutdown diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt index 2e3c64b1a6a..9dbe885ecd8 100644 --- a/Documentation/spinlocks.txt +++ b/Documentation/spinlocks.txt @@ -13,18 +13,8 @@ static DEFINE_SPINLOCK(xxx_lock); The above is always safe. It will disable interrupts _locally_, but the spinlock itself will guarantee the global lock, so it will guarantee that there is only one thread-of-control within the region(s) protected by that -lock. This works well even under UP. The above sequence under UP -essentially is just the same as doing - - unsigned long flags; - - save_flags(flags); cli(); - ... critical section ... - restore_flags(flags); - -so the code does _not_ need to worry about UP vs SMP issues: the spinlocks -work correctly under both (and spinlocks are actually more efficient on -architectures that allow doing the "save_flags + cli" in one operation). +lock. This works well even under UP also, so the code does _not_ need to +worry about UP vs SMP issues: the spinlocks work correctly under both. NOTE! Implications of spin_locks for memory are further described in: @@ -36,27 +26,7 @@ The above is usually pretty simple (you usually need and want only one spinlock for most things - using more than one spinlock can make things a lot more complex and even slower and is usually worth it only for sequences that you _know_ need to be split up: avoid it at all cost if you -aren't sure). HOWEVER, it _does_ mean that if you have some code that does - - cli(); - .. critical section .. - sti(); - -and another sequence that does - - spin_lock_irqsave(flags); - .. critical section .. - spin_unlock_irqrestore(flags); - -then they are NOT mutually exclusive, and the critical regions can happen -at the same time on two different CPU's. That's fine per se, but the -critical regions had better be critical for different things (ie they -can't stomp on each other). - -The above is a problem mainly if you end up mixing code - for example the -routines in ll_rw_block() tend to use cli/sti to protect the atomicity of -their actions, and if a driver uses spinlocks instead then you should -think about issues like the above. +aren't sure). This is really the only really hard part about spinlocks: once you start using spinlocks they tend to expand to areas you might not have noticed @@ -120,11 +90,10 @@ Lesson 3: spinlocks revisited. The single spin-lock primitives above are by no means the only ones. They are the most safe ones, and the ones that work under all circumstances, -but partly _because_ they are safe they are also fairly slow. They are -much faster than a generic global cli/sti pair, but slower than they'd -need to be, because they do have to disable interrupts (which is just a -single instruction on a x86, but it's an expensive one - and on other -architectures it can be worse). +but partly _because_ they are safe they are also fairly slow. They are slower +than they'd need to be, because they do have to disable interrupts +(which is just a single instruction on a x86, but it's an expensive one - +and on other architectures it can be worse). If you have a case where you have to protect a data structure across several CPU's and you want to use spinlocks you can potentially use |