Merge commit '8700c95adb03' into timers/nohz
The full dynticks tree needs the latest RCU and sched upstream updates in order to fix some dependencies. Merge a common upstream merge point that has these updates. Conflicts: include/linux/perf_event.h kernel/rcutree.h kernel/rcutree_plugin.h Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
This commit is contained in:
18
CREDITS
18
CREDITS
@@ -761,6 +761,10 @@ S: Northampton
|
|||||||
S: NN1 3QT
|
S: NN1 3QT
|
||||||
S: United Kingdom
|
S: United Kingdom
|
||||||
|
|
||||||
|
N: Massimo Dal Zotto
|
||||||
|
E: dz@debian.org
|
||||||
|
D: i8k Dell laptop SMM driver
|
||||||
|
|
||||||
N: Uwe Dannowski
|
N: Uwe Dannowski
|
||||||
E: Uwe.Dannowski@ira.uka.de
|
E: Uwe.Dannowski@ira.uka.de
|
||||||
W: http://i30www.ira.uka.de/~dannowsk/
|
W: http://i30www.ira.uka.de/~dannowsk/
|
||||||
@@ -953,11 +957,11 @@ S: Blacksburg, Virginia 24061
|
|||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
N: Randy Dunlap
|
N: Randy Dunlap
|
||||||
E: rdunlap@xenotime.net
|
E: rdunlap@infradead.org
|
||||||
W: http://www.xenotime.net/linux/linux.html
|
W: http://www.infradead.org/~rdunlap/
|
||||||
W: http://www.linux-usb.org
|
|
||||||
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
|
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
|
||||||
D: x86 SMP, ACPI, bootflag hacking
|
D: x86 SMP, ACPI, bootflag hacking
|
||||||
|
D: documentation, builds
|
||||||
S: (ask for current address)
|
S: (ask for current address)
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
@@ -1510,6 +1514,14 @@ D: Natsemi ethernet
|
|||||||
D: Cobalt Networks (x86) support
|
D: Cobalt Networks (x86) support
|
||||||
D: This-and-That
|
D: This-and-That
|
||||||
|
|
||||||
|
N: Mark M. Hoffman
|
||||||
|
E: mhoffman@lightlink.com
|
||||||
|
D: asb100, lm93 and smsc47b397 hardware monitoring drivers
|
||||||
|
D: hwmon subsystem core
|
||||||
|
D: hwmon subsystem maintainer
|
||||||
|
D: i2c-sis96x and i2c-stub SMBus drivers
|
||||||
|
S: USA
|
||||||
|
|
||||||
N: Dirk Hohndel
|
N: Dirk Hohndel
|
||||||
E: hohndel@suse.de
|
E: hohndel@suse.de
|
||||||
D: The XFree86[tm] Project
|
D: The XFree86[tm] Project
|
||||||
|
7
Documentation/ABI/testing/sysfs-bus-mei
Normal file
7
Documentation/ABI/testing/sysfs-bus-mei
Normal file
@@ -0,0 +1,7 @@
|
|||||||
|
What: /sys/bus/mei/devices/.../modalias
|
||||||
|
Date: March 2013
|
||||||
|
KernelVersion: 3.10
|
||||||
|
Contact: Samuel Ortiz <sameo@linux.intel.com>
|
||||||
|
linux-mei@linux.intel.com
|
||||||
|
Description: Stores the same MODALIAS value emitted by uevent
|
||||||
|
Format: mei:<mei device name>
|
@@ -32,7 +32,7 @@ Date: January 2008
|
|||||||
KernelVersion: 2.6.25
|
KernelVersion: 2.6.25
|
||||||
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
|
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
|
||||||
Description:
|
Description:
|
||||||
If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
|
If CONFIG_PM_RUNTIME is enabled then this file
|
||||||
is present. When read, it returns the total time (in msec)
|
is present. When read, it returns the total time (in msec)
|
||||||
that the USB device has been connected to the machine. This
|
that the USB device has been connected to the machine. This
|
||||||
file is read-only.
|
file is read-only.
|
||||||
@@ -45,7 +45,7 @@ Date: January 2008
|
|||||||
KernelVersion: 2.6.25
|
KernelVersion: 2.6.25
|
||||||
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
|
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
|
||||||
Description:
|
Description:
|
||||||
If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
|
If CONFIG_PM_RUNTIME is enabled then this file
|
||||||
is present. When read, it returns the total time (in msec)
|
is present. When read, it returns the total time (in msec)
|
||||||
that the USB device has been active, i.e. not in a suspended
|
that the USB device has been active, i.e. not in a suspended
|
||||||
state. This file is read-only.
|
state. This file is read-only.
|
||||||
@@ -187,7 +187,7 @@ What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm
|
|||||||
Date: September 2011
|
Date: September 2011
|
||||||
Contact: Andiry Xu <andiry.xu@amd.com>
|
Contact: Andiry Xu <andiry.xu@amd.com>
|
||||||
Description:
|
Description:
|
||||||
If CONFIG_USB_SUSPEND is set and a USB 2.0 lpm-capable device
|
If CONFIG_PM_RUNTIME is set and a USB 2.0 lpm-capable device
|
||||||
is plugged in to a xHCI host which support link PM, it will
|
is plugged in to a xHCI host which support link PM, it will
|
||||||
perform a LPM test; if the test is passed and host supports
|
perform a LPM test; if the test is passed and host supports
|
||||||
USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will
|
USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will
|
||||||
|
@@ -173,3 +173,15 @@ Description: Processor frequency boosting control
|
|||||||
Boosting allows the CPU and the firmware to run at a frequency
|
Boosting allows the CPU and the firmware to run at a frequency
|
||||||
beyound it's nominal limit.
|
beyound it's nominal limit.
|
||||||
More details can be found in Documentation/cpu-freq/boost.txt
|
More details can be found in Documentation/cpu-freq/boost.txt
|
||||||
|
|
||||||
|
|
||||||
|
What: /sys/devices/system/cpu/cpu#/crash_notes
|
||||||
|
/sys/devices/system/cpu/cpu#/crash_notes_size
|
||||||
|
Date: April 2013
|
||||||
|
Contact: kexec@lists.infradead.org
|
||||||
|
Description: address and size of the percpu note.
|
||||||
|
|
||||||
|
crash_notes: the physical address of the memory that holds the
|
||||||
|
note of cpu#.
|
||||||
|
|
||||||
|
crash_notes_size: size of the note of cpu#.
|
||||||
|
@@ -227,7 +227,7 @@ X!Isound/sound_firmware.c
|
|||||||
<chapter id="uart16x50">
|
<chapter id="uart16x50">
|
||||||
<title>16x50 UART Driver</title>
|
<title>16x50 UART Driver</title>
|
||||||
!Edrivers/tty/serial/serial_core.c
|
!Edrivers/tty/serial/serial_core.c
|
||||||
!Edrivers/tty/serial/8250/8250.c
|
!Edrivers/tty/serial/8250/8250_core.c
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<chapter id="fbdev">
|
<chapter id="fbdev">
|
||||||
|
@@ -217,9 +217,14 @@ over a rather long period of time, but improvements are always welcome!
|
|||||||
whether the increased speed is worth it.
|
whether the increased speed is worth it.
|
||||||
|
|
||||||
8. Although synchronize_rcu() is slower than is call_rcu(), it
|
8. Although synchronize_rcu() is slower than is call_rcu(), it
|
||||||
usually results in simpler code. So, unless update performance
|
usually results in simpler code. So, unless update performance is
|
||||||
is critically important or the updaters cannot block,
|
critically important, the updaters cannot block, or the latency of
|
||||||
synchronize_rcu() should be used in preference to call_rcu().
|
synchronize_rcu() is visible from userspace, synchronize_rcu()
|
||||||
|
should be used in preference to call_rcu(). Furthermore,
|
||||||
|
kfree_rcu() usually results in even simpler code than does
|
||||||
|
synchronize_rcu() without synchronize_rcu()'s multi-millisecond
|
||||||
|
latency. So please take advantage of kfree_rcu()'s "fire and
|
||||||
|
forget" memory-freeing capabilities where it applies.
|
||||||
|
|
||||||
An especially important property of the synchronize_rcu()
|
An especially important property of the synchronize_rcu()
|
||||||
primitive is that it automatically self-limits: if grace periods
|
primitive is that it automatically self-limits: if grace periods
|
||||||
@@ -268,7 +273,8 @@ over a rather long period of time, but improvements are always welcome!
|
|||||||
e. Periodically invoke synchronize_rcu(), permitting a limited
|
e. Periodically invoke synchronize_rcu(), permitting a limited
|
||||||
number of updates per grace period.
|
number of updates per grace period.
|
||||||
|
|
||||||
The same cautions apply to call_rcu_bh() and call_rcu_sched().
|
The same cautions apply to call_rcu_bh(), call_rcu_sched(),
|
||||||
|
call_srcu(), and kfree_rcu().
|
||||||
|
|
||||||
9. All RCU list-traversal primitives, which include
|
9. All RCU list-traversal primitives, which include
|
||||||
rcu_dereference(), list_for_each_entry_rcu(), and
|
rcu_dereference(), list_for_each_entry_rcu(), and
|
||||||
@@ -296,9 +302,9 @@ over a rather long period of time, but improvements are always welcome!
|
|||||||
all currently executing rcu_read_lock()-protected RCU read-side
|
all currently executing rcu_read_lock()-protected RCU read-side
|
||||||
critical sections complete. It does -not- necessarily guarantee
|
critical sections complete. It does -not- necessarily guarantee
|
||||||
that all currently running interrupts, NMIs, preempt_disable()
|
that all currently running interrupts, NMIs, preempt_disable()
|
||||||
code, or idle loops will complete. Therefore, if you do not have
|
code, or idle loops will complete. Therefore, if your
|
||||||
rcu_read_lock()-protected read-side critical sections, do -not-
|
read-side critical sections are protected by something other
|
||||||
use synchronize_rcu().
|
than rcu_read_lock(), do -not- use synchronize_rcu().
|
||||||
|
|
||||||
Similarly, disabling preemption is not an acceptable substitute
|
Similarly, disabling preemption is not an acceptable substitute
|
||||||
for rcu_read_lock(). Code that attempts to use preemption
|
for rcu_read_lock(). Code that attempts to use preemption
|
||||||
@@ -401,9 +407,9 @@ over a rather long period of time, but improvements are always welcome!
|
|||||||
read-side critical sections. It is the responsibility of the
|
read-side critical sections. It is the responsibility of the
|
||||||
RCU update-side primitives to deal with this.
|
RCU update-side primitives to deal with this.
|
||||||
|
|
||||||
17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and
|
17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and the
|
||||||
the __rcu sparse checks to validate your RCU code. These
|
__rcu sparse checks (enabled by CONFIG_SPARSE_RCU_POINTER) to
|
||||||
can help find problems as follows:
|
validate your RCU code. These can help find problems as follows:
|
||||||
|
|
||||||
CONFIG_PROVE_RCU: check that accesses to RCU-protected data
|
CONFIG_PROVE_RCU: check that accesses to RCU-protected data
|
||||||
structures are carried out under the proper RCU
|
structures are carried out under the proper RCU
|
||||||
|
@@ -64,6 +64,11 @@ checking of rcu_dereference() primitives:
|
|||||||
but retain the compiler constraints that prevent duplicating
|
but retain the compiler constraints that prevent duplicating
|
||||||
or coalescsing. This is useful when when testing the
|
or coalescsing. This is useful when when testing the
|
||||||
value of the pointer itself, for example, against NULL.
|
value of the pointer itself, for example, against NULL.
|
||||||
|
rcu_access_index(idx):
|
||||||
|
Return the value of the index and omit all barriers, but
|
||||||
|
retain the compiler constraints that prevent duplicating
|
||||||
|
or coalescsing. This is useful when when testing the
|
||||||
|
value of the index itself, for example, against -1.
|
||||||
|
|
||||||
The rcu_dereference_check() check expression can be any boolean
|
The rcu_dereference_check() check expression can be any boolean
|
||||||
expression, but would normally include a lockdep expression. However,
|
expression, but would normally include a lockdep expression. However,
|
||||||
|
@@ -79,7 +79,20 @@ complete. Pseudo-code using rcu_barrier() is as follows:
|
|||||||
2. Execute rcu_barrier().
|
2. Execute rcu_barrier().
|
||||||
3. Allow the module to be unloaded.
|
3. Allow the module to be unloaded.
|
||||||
|
|
||||||
The rcutorture module makes use of rcu_barrier in its exit function
|
There are also rcu_barrier_bh(), rcu_barrier_sched(), and srcu_barrier()
|
||||||
|
functions for the other flavors of RCU, and you of course must match
|
||||||
|
the flavor of rcu_barrier() with that of call_rcu(). If your module
|
||||||
|
uses multiple flavors of call_rcu(), then it must also use multiple
|
||||||
|
flavors of rcu_barrier() when unloading that module. For example, if
|
||||||
|
it uses call_rcu_bh(), call_srcu() on srcu_struct_1, and call_srcu() on
|
||||||
|
srcu_struct_2(), then the following three lines of code will be required
|
||||||
|
when unloading:
|
||||||
|
|
||||||
|
1 rcu_barrier_bh();
|
||||||
|
2 srcu_barrier(&srcu_struct_1);
|
||||||
|
3 srcu_barrier(&srcu_struct_2);
|
||||||
|
|
||||||
|
The rcutorture module makes use of rcu_barrier() in its exit function
|
||||||
as follows:
|
as follows:
|
||||||
|
|
||||||
1 static void
|
1 static void
|
||||||
|
@@ -92,14 +92,14 @@ If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
|
|||||||
more information is printed with the stall-warning message, for example:
|
more information is printed with the stall-warning message, for example:
|
||||||
|
|
||||||
INFO: rcu_preempt detected stall on CPU
|
INFO: rcu_preempt detected stall on CPU
|
||||||
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0
|
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0 softirq=82/543
|
||||||
(t=65000 jiffies)
|
(t=65000 jiffies)
|
||||||
|
|
||||||
In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
|
In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
|
||||||
printed:
|
printed:
|
||||||
|
|
||||||
INFO: rcu_preempt detected stall on CPU
|
INFO: rcu_preempt detected stall on CPU
|
||||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending
|
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 nonlazy_posted: 25 .D
|
||||||
(t=65000 jiffies)
|
(t=65000 jiffies)
|
||||||
|
|
||||||
The "(64628 ticks this GP)" indicates that this CPU has taken more
|
The "(64628 ticks this GP)" indicates that this CPU has taken more
|
||||||
@@ -116,13 +116,28 @@ number between the two "/"s is the value of the nesting, which will
|
|||||||
be a small positive number if in the idle loop and a very large positive
|
be a small positive number if in the idle loop and a very large positive
|
||||||
number (as shown above) otherwise.
|
number (as shown above) otherwise.
|
||||||
|
|
||||||
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
|
The "softirq=" portion of the message tracks the number of RCU softirq
|
||||||
not in the process of trying to force itself into dyntick-idle state, the
|
handlers that the stalled CPU has executed. The number before the "/"
|
||||||
"." indicates that the CPU has not given up forcing RCU into dyntick-idle
|
is the number that had executed since boot at the time that this CPU
|
||||||
mode (it would be "H" otherwise), and the "timer not pending" indicates
|
last noted the beginning of a grace period, which might be the current
|
||||||
that the CPU has not recently forced RCU into dyntick-idle mode (it
|
(stalled) grace period, or it might be some earlier grace period (for
|
||||||
would otherwise indicate the number of microseconds remaining in this
|
example, if the CPU might have been in dyntick-idle mode for an extended
|
||||||
forced state).
|
time period. The number after the "/" is the number that have executed
|
||||||
|
since boot until the current time. If this latter number stays constant
|
||||||
|
across repeated stall-warning messages, it is possible that RCU's softirq
|
||||||
|
handlers are no longer able to execute on this CPU. This can happen if
|
||||||
|
the stalled CPU is spinning with interrupts are disabled, or, in -rt
|
||||||
|
kernels, if a high-priority process is starving RCU's softirq handler.
|
||||||
|
|
||||||
|
For CONFIG_RCU_FAST_NO_HZ kernels, the "last_accelerate:" prints the
|
||||||
|
low-order 16 bits (in hex) of the jiffies counter when this CPU last
|
||||||
|
invoked rcu_try_advance_all_cbs() from rcu_needs_cpu() or last invoked
|
||||||
|
rcu_accelerate_cbs() from rcu_prepare_for_idle(). The "nonlazy_posted:"
|
||||||
|
prints the number of non-lazy callbacks posted since the last call to
|
||||||
|
rcu_needs_cpu(). Finally, an "L" indicates that there are currently
|
||||||
|
no non-lazy callbacks ("." is printed otherwise, as shown above) and
|
||||||
|
"D" indicates that dyntick-idle processing is enabled ("." is printed
|
||||||
|
otherwise, for example, if disabled via the "nohz=" kernel boot parameter).
|
||||||
|
|
||||||
|
|
||||||
Multiple Warnings From One Stall
|
Multiple Warnings From One Stall
|
||||||
|
@@ -265,9 +265,9 @@ rcu_dereference()
|
|||||||
rcu_read_lock();
|
rcu_read_lock();
|
||||||
p = rcu_dereference(head.next);
|
p = rcu_dereference(head.next);
|
||||||
rcu_read_unlock();
|
rcu_read_unlock();
|
||||||
x = p->address;
|
x = p->address; /* BUG!!! */
|
||||||
rcu_read_lock();
|
rcu_read_lock();
|
||||||
y = p->data;
|
y = p->data; /* BUG!!! */
|
||||||
rcu_read_unlock();
|
rcu_read_unlock();
|
||||||
|
|
||||||
Holding a reference from one RCU read-side critical section
|
Holding a reference from one RCU read-side critical section
|
||||||
|
@@ -60,8 +60,7 @@ own source tree. For example:
|
|||||||
"dontdiff" is a list of files which are generated by the kernel during
|
"dontdiff" is a list of files which are generated by the kernel during
|
||||||
the build process, and should be ignored in any diff(1)-generated
|
the build process, and should be ignored in any diff(1)-generated
|
||||||
patch. The "dontdiff" file is included in the kernel tree in
|
patch. The "dontdiff" file is included in the kernel tree in
|
||||||
2.6.12 and later. For earlier kernel versions, you can get it
|
2.6.12 and later.
|
||||||
from <http://www.xenotime.net/linux/doc/dontdiff>.
|
|
||||||
|
|
||||||
Make sure your patch does not include any extra files which do not
|
Make sure your patch does not include any extra files which do not
|
||||||
belong in a patch submission. Make sure to review your patch -after-
|
belong in a patch submission. Make sure to review your patch -after-
|
||||||
@@ -421,7 +420,7 @@ person it names. This tag documents that potentially interested parties
|
|||||||
have been included in the discussion
|
have been included in the discussion
|
||||||
|
|
||||||
|
|
||||||
14) Using Reported-by:, Tested-by: and Reviewed-by:
|
14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
|
||||||
|
|
||||||
If this patch fixes a problem reported by somebody else, consider adding a
|
If this patch fixes a problem reported by somebody else, consider adding a
|
||||||
Reported-by: tag to credit the reporter for their contribution. Please
|
Reported-by: tag to credit the reporter for their contribution. Please
|
||||||
@@ -469,6 +468,13 @@ done on the patch. Reviewed-by: tags, when supplied by reviewers known to
|
|||||||
understand the subject area and to perform thorough reviews, will normally
|
understand the subject area and to perform thorough reviews, will normally
|
||||||
increase the likelihood of your patch getting into the kernel.
|
increase the likelihood of your patch getting into the kernel.
|
||||||
|
|
||||||
|
A Suggested-by: tag indicates that the patch idea is suggested by the person
|
||||||
|
named and ensures credit to the person for the idea. Please note that this
|
||||||
|
tag should not be added without the reporter's permission, especially if the
|
||||||
|
idea was not posted in a public forum. That said, if we diligently credit our
|
||||||
|
idea reporters, they will, hopefully, be inspired to help us again in the
|
||||||
|
future.
|
||||||
|
|
||||||
|
|
||||||
15) The canonical patch format
|
15) The canonical patch format
|
||||||
|
|
||||||
|
56
Documentation/arm/sunxi/clocks.txt
Normal file
56
Documentation/arm/sunxi/clocks.txt
Normal file
@@ -0,0 +1,56 @@
|
|||||||
|
Frequently asked questions about the sunxi clock system
|
||||||
|
=======================================================
|
||||||
|
|
||||||
|
This document contains useful bits of information that people tend to ask
|
||||||
|
about the sunxi clock system, as well as accompanying ASCII art when adequate.
|
||||||
|
|
||||||
|
Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the
|
||||||
|
system?
|
||||||
|
|
||||||
|
A: The 24MHz oscillator allows gating to save power. Indeed, if gated
|
||||||
|
carelessly the system would stop functioning, but with the right
|
||||||
|
steps, one can gate it and keep the system running. Consider this
|
||||||
|
simplified suspend example:
|
||||||
|
|
||||||
|
While the system is operational, you would see something like
|
||||||
|
|
||||||
|
24MHz 32kHz
|
||||||
|
|
|
||||||
|
PLL1
|
||||||
|
\
|
||||||
|
\_ CPU Mux
|
||||||
|
|
|
||||||
|
[CPU]
|
||||||
|
|
||||||
|
When you are about to suspend, you switch the CPU Mux to the 32kHz
|
||||||
|
oscillator:
|
||||||
|
|
||||||
|
24Mhz 32kHz
|
||||||
|
| |
|
||||||
|
PLL1 |
|
||||||
|
/
|
||||||
|
CPU Mux _/
|
||||||
|
|
|
||||||
|
[CPU]
|
||||||
|
|
||||||
|
Finally you can gate the main oscillator
|
||||||
|
|
||||||
|
32kHz
|
||||||
|
|
|
||||||
|
|
|
||||||
|
/
|
||||||
|
CPU Mux _/
|
||||||
|
|
|
||||||
|
[CPU]
|
||||||
|
|
||||||
|
Q: Were can I learn more about the sunxi clocks?
|
||||||
|
|
||||||
|
A: The linux-sunxi wiki contains a page documenting the clock registers,
|
||||||
|
you can find it at
|
||||||
|
|
||||||
|
http://linux-sunxi.org/A10/CCM
|
||||||
|
|
||||||
|
The authoritative source for information at this time is the ccmu driver
|
||||||
|
released by Allwinner, you can find it at
|
||||||
|
|
||||||
|
https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.0/arch/arm/mach-sun4i/clock/ccmu
|
@@ -32,14 +32,10 @@ Platform data for lp855x
|
|||||||
For supporting platform specific data, the lp855x platform data can be used.
|
For supporting platform specific data, the lp855x platform data can be used.
|
||||||
|
|
||||||
* name : Backlight driver name. If it is not defined, default name is set.
|
* name : Backlight driver name. If it is not defined, default name is set.
|
||||||
* mode : Brightness control mode. PWM or register based.
|
|
||||||
* device_control : Value of DEVICE CONTROL register.
|
* device_control : Value of DEVICE CONTROL register.
|
||||||
* initial_brightness : Initial value of backlight brightness.
|
* initial_brightness : Initial value of backlight brightness.
|
||||||
* period_ns : Platform specific PWM period value. unit is nano.
|
* period_ns : Platform specific PWM period value. unit is nano.
|
||||||
Only valid when brightness is pwm input mode.
|
Only valid when brightness is pwm input mode.
|
||||||
* load_new_rom_data :
|
|
||||||
0 : use default configuration data
|
|
||||||
1 : update values of eeprom or eprom registers on loading driver
|
|
||||||
* size_program : Total size of lp855x_rom_data.
|
* size_program : Total size of lp855x_rom_data.
|
||||||
* rom_data : List of new eeprom/eprom registers.
|
* rom_data : List of new eeprom/eprom registers.
|
||||||
|
|
||||||
@@ -54,10 +50,8 @@ static struct lp855x_rom_data lp8552_eeprom_arr[] = {
|
|||||||
|
|
||||||
static struct lp855x_platform_data lp8552_pdata = {
|
static struct lp855x_platform_data lp8552_pdata = {
|
||||||
.name = "lcd-bl",
|
.name = "lcd-bl",
|
||||||
.mode = REGISTER_BASED,
|
|
||||||
.device_control = I2C_CONFIG(LP8552),
|
.device_control = I2C_CONFIG(LP8552),
|
||||||
.initial_brightness = INITIAL_BRT,
|
.initial_brightness = INITIAL_BRT,
|
||||||
.load_new_rom_data = 1,
|
|
||||||
.size_program = ARRAY_SIZE(lp8552_eeprom_arr),
|
.size_program = ARRAY_SIZE(lp8552_eeprom_arr),
|
||||||
.rom_data = lp8552_eeprom_arr,
|
.rom_data = lp8552_eeprom_arr,
|
||||||
};
|
};
|
||||||
@@ -65,7 +59,6 @@ static struct lp855x_platform_data lp8552_pdata = {
|
|||||||
example 2) lp8556 platform data : pwm input mode with default rom data
|
example 2) lp8556 platform data : pwm input mode with default rom data
|
||||||
|
|
||||||
static struct lp855x_platform_data lp8556_pdata = {
|
static struct lp855x_platform_data lp8556_pdata = {
|
||||||
.mode = PWM_BASED,
|
|
||||||
.device_control = PWM_CONFIG(LP8556),
|
.device_control = PWM_CONFIG(LP8556),
|
||||||
.initial_brightness = INITIAL_BRT,
|
.initial_brightness = INITIAL_BRT,
|
||||||
.period_ns = 1000000,
|
.period_ns = 1000000,
|
||||||
|
@@ -442,7 +442,7 @@ You can attach the current shell task by echoing 0:
|
|||||||
You can use the cgroup.procs file instead of the tasks file to move all
|
You can use the cgroup.procs file instead of the tasks file to move all
|
||||||
threads in a threadgroup at once. Echoing the PID of any task in a
|
threads in a threadgroup at once. Echoing the PID of any task in a
|
||||||
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
|
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
|
||||||
be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
|
attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
|
||||||
in the writing task's threadgroup.
|
in the writing task's threadgroup.
|
||||||
|
|
||||||
Note: Since every task is always a member of exactly one cgroup in each
|
Note: Since every task is always a member of exactly one cgroup in each
|
||||||
@@ -580,6 +580,7 @@ propagation along the hierarchy. See the comment on
|
|||||||
cgroup_for_each_descendant_pre() for details.
|
cgroup_for_each_descendant_pre() for details.
|
||||||
|
|
||||||
void css_offline(struct cgroup *cgrp);
|
void css_offline(struct cgroup *cgrp);
|
||||||
|
(cgroup_mutex held by caller)
|
||||||
|
|
||||||
This is the counterpart of css_online() and called iff css_online()
|
This is the counterpart of css_online() and called iff css_online()
|
||||||
has succeeded on @cgrp. This signifies the beginning of the end of
|
has succeeded on @cgrp. This signifies the beginning of the end of
|
||||||
|
@@ -13,9 +13,7 @@ either an integer or * for all. Access is a composition of r
|
|||||||
The root device cgroup starts with rwm to 'all'. A child device
|
The root device cgroup starts with rwm to 'all'. A child device
|
||||||
cgroup gets a copy of the parent. Administrators can then remove
|
cgroup gets a copy of the parent. Administrators can then remove
|
||||||
devices from the whitelist or add new entries. A child cgroup can
|
devices from the whitelist or add new entries. A child cgroup can
|
||||||
never receive a device access which is denied by its parent. However
|
never receive a device access which is denied by its parent.
|
||||||
when a device access is removed from a parent it will not also be
|
|
||||||
removed from the child(ren).
|
|
||||||
|
|
||||||
2. User Interface
|
2. User Interface
|
||||||
|
|
||||||
@@ -50,3 +48,69 @@ task to a new cgroup. (Again we'll probably want to change that).
|
|||||||
|
|
||||||
A cgroup may not be granted more permissions than the cgroup's
|
A cgroup may not be granted more permissions than the cgroup's
|
||||||
parent has.
|
parent has.
|
||||||
|
|
||||||
|
4. Hierarchy
|
||||||
|
|
||||||
|
device cgroups maintain hierarchy by making sure a cgroup never has more
|
||||||
|
access permissions than its parent. Every time an entry is written to
|
||||||
|
a cgroup's devices.deny file, all its children will have that entry removed
|
||||||
|
from their whitelist and all the locally set whitelist entries will be
|
||||||
|
re-evaluated. In case one of the locally set whitelist entries would provide
|
||||||
|
more access than the cgroup's parent, it'll be removed from the whitelist.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
A
|
||||||
|
/ \
|
||||||
|
B
|
||||||
|
|
||||||
|
group behavior exceptions
|
||||||
|
A allow "b 8:* rwm", "c 116:1 rw"
|
||||||
|
B deny "c 1:3 rwm", "c 116:2 rwm", "b 3:* rwm"
|
||||||
|
|
||||||
|
If a device is denied in group A:
|
||||||
|
# echo "c 116:* r" > A/devices.deny
|
||||||
|
it'll propagate down and after revalidating B's entries, the whitelist entry
|
||||||
|
"c 116:2 rwm" will be removed:
|
||||||
|
|
||||||
|
group whitelist entries denied devices
|
||||||
|
A all "b 8:* rwm", "c 116:* rw"
|
||||||
|
B "c 1:3 rwm", "b 3:* rwm" all the rest
|
||||||
|
|
||||||
|
In case parent's exceptions change and local exceptions are not allowed
|
||||||
|
anymore, they'll be deleted.
|
||||||
|
|
||||||
|
Notice that new whitelist entries will not be propagated:
|
||||||
|
A
|
||||||
|
/ \
|
||||||
|
B
|
||||||
|
|
||||||
|
group whitelist entries denied devices
|
||||||
|
A "c 1:3 rwm", "c 1:5 r" all the rest
|
||||||
|
B "c 1:3 rwm", "c 1:5 r" all the rest
|
||||||
|
|
||||||
|
when adding "c *:3 rwm":
|
||||||
|
# echo "c *:3 rwm" >A/devices.allow
|
||||||
|
|
||||||
|
the result:
|
||||||
|
group whitelist entries denied devices
|
||||||
|
A "c *:3 rwm", "c 1:5 r" all the rest
|
||||||
|
B "c 1:3 rwm", "c 1:5 r" all the rest
|
||||||
|
|
||||||
|
but now it'll be possible to add new entries to B:
|
||||||
|
# echo "c 2:3 rwm" >B/devices.allow
|
||||||
|
# echo "c 50:3 r" >B/devices.allow
|
||||||
|
or even
|
||||||
|
# echo "c *:3 rwm" >B/devices.allow
|
||||||
|
|
||||||
|
Allowing or denying all by writing 'a' to devices.allow or devices.deny will
|
||||||
|
not be possible once the device cgroups has children.
|
||||||
|
|
||||||
|
4.1 Hierarchy (internal implementation)
|
||||||
|
|
||||||
|
device cgroups is implemented internally using a behavior (ALLOW, DENY) and a
|
||||||
|
list of exceptions. The internal state is controlled using the same user
|
||||||
|
interface to preserve compatibility with the previous whitelist-only
|
||||||
|
implementation. Removal or addition of exceptions that will reduce the access
|
||||||
|
to devices will be propagated down the hierarchy.
|
||||||
|
For every propagated exception, the effective rules will be re-evaluated based
|
||||||
|
on current parent's access rules.
|
||||||
|
@@ -40,6 +40,7 @@ Features:
|
|||||||
- soft limit
|
- soft limit
|
||||||
- moving (recharging) account at moving a task is selectable.
|
- moving (recharging) account at moving a task is selectable.
|
||||||
- usage threshold notifier
|
- usage threshold notifier
|
||||||
|
- memory pressure notifier
|
||||||
- oom-killer disable knob and oom-notifier
|
- oom-killer disable knob and oom-notifier
|
||||||
- Root cgroup has no limit controls.
|
- Root cgroup has no limit controls.
|
||||||
|
|
||||||
@@ -65,6 +66,7 @@ Brief summary of control files.
|
|||||||
memory.stat # show various statistics
|
memory.stat # show various statistics
|
||||||
memory.use_hierarchy # set/show hierarchical account enabled
|
memory.use_hierarchy # set/show hierarchical account enabled
|
||||||
memory.force_empty # trigger forced move charge to parent
|
memory.force_empty # trigger forced move charge to parent
|
||||||
|
memory.pressure_level # set memory pressure notifications
|
||||||
memory.swappiness # set/show swappiness parameter of vmscan
|
memory.swappiness # set/show swappiness parameter of vmscan
|
||||||
(See sysctl's vm.swappiness)
|
(See sysctl's vm.swappiness)
|
||||||
memory.move_charge_at_immigrate # set/show controls of moving charges
|
memory.move_charge_at_immigrate # set/show controls of moving charges
|
||||||
@@ -762,7 +764,73 @@ At reading, current status of OOM is shown.
|
|||||||
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
|
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
|
||||||
be stopped.)
|
be stopped.)
|
||||||
|
|
||||||
11. TODO
|
11. Memory Pressure
|
||||||
|
|
||||||
|
The pressure level notifications can be used to monitor the memory
|
||||||
|
allocation cost; based on the pressure, applications can implement
|
||||||
|
different strategies of managing their memory resources. The pressure
|
||||||
|
levels are defined as following:
|
||||||
|
|
||||||
|
The "low" level means that the system is reclaiming memory for new
|
||||||
|
allocations. Monitoring this reclaiming activity might be useful for
|
||||||
|
maintaining cache level. Upon notification, the program (typically
|
||||||
|
"Activity Manager") might analyze vmstat and act in advance (i.e.
|
||||||
|
prematurely shutdown unimportant services).
|
||||||
|
|
||||||
|
The "medium" level means that the system is experiencing medium memory
|
||||||
|
pressure, the system might be making swap, paging out active file caches,
|
||||||
|
etc. Upon this event applications may decide to further analyze
|
||||||
|
vmstat/zoneinfo/memcg or internal memory usage statistics and free any
|
||||||
|
resources that can be easily reconstructed or re-read from a disk.
|
||||||
|
|
||||||
|
The "critical" level means that the system is actively thrashing, it is
|
||||||
|
about to out of memory (OOM) or even the in-kernel OOM killer is on its
|
||||||
|
way to trigger. Applications should do whatever they can to help the
|
||||||
|
system. It might be too late to consult with vmstat or any other
|
||||||
|
statistics, so it's advisable to take an immediate action.
|
||||||
|
|
||||||
|
The events are propagated upward until the event is handled, i.e. the
|
||||||
|
events are not pass-through. Here is what this means: for example you have
|
||||||
|
three cgroups: A->B->C. Now you set up an event listener on cgroups A, B
|
||||||
|
and C, and suppose group C experiences some pressure. In this situation,
|
||||||
|
only group C will receive the notification, i.e. groups A and B will not
|
||||||
|
receive it. This is done to avoid excessive "broadcasting" of messages,
|
||||||
|
which disturbs the system and which is especially bad if we are low on
|
||||||
|
memory or thrashing. So, organize the cgroups wisely, or propagate the
|
||||||
|
events manually (or, ask us to implement the pass-through events,
|
||||||
|
explaining why would you need them.)
|
||||||
|
|
||||||
|
The file memory.pressure_level is only used to setup an eventfd. To
|
||||||
|
register a notification, an application must:
|
||||||
|
|
||||||
|
- create an eventfd using eventfd(2);
|
||||||
|
- open memory.pressure_level;
|
||||||
|
- write string like "<event_fd> <fd of memory.pressure_level> <level>"
|
||||||
|
to cgroup.event_control.
|
||||||
|
|
||||||
|
Application will be notified through eventfd when memory pressure is at
|
||||||
|
the specific level (or higher). Read/write operations to
|
||||||
|
memory.pressure_level are no implemented.
|
||||||
|
|
||||||
|
Test:
|
||||||
|
|
||||||
|
Here is a small script example that makes a new cgroup, sets up a
|
||||||
|
memory limit, sets up a notification in the cgroup and then makes child
|
||||||
|
cgroup experience a critical pressure:
|
||||||
|
|
||||||
|
# cd /sys/fs/cgroup/memory/
|
||||||
|
# mkdir foo
|
||||||
|
# cd foo
|
||||||
|
# cgroup_event_listener memory.pressure_level low &
|
||||||
|
# echo 8000000 > memory.limit_in_bytes
|
||||||
|
# echo 8000000 > memory.memsw.limit_in_bytes
|
||||||
|
# echo $$ > tasks
|
||||||
|
# dd if=/dev/zero | read x
|
||||||
|
|
||||||
|
(Expect a bunch of notifications, and eventually, the oom-killer will
|
||||||
|
trigger.)
|
||||||
|
|
||||||
|
12. TODO
|
||||||
|
|
||||||
1. Add support for accounting huge pages (as a separate controller)
|
1. Add support for accounting huge pages (as a separate controller)
|
||||||
2. Make per-cgroup scanner reclaim not-shared pages first
|
2. Make per-cgroup scanner reclaim not-shared pages first
|
||||||
|
@@ -174,9 +174,9 @@ int clk_foo_enable(struct clk_hw *hw)
|
|||||||
};
|
};
|
||||||
|
|
||||||
Below is a matrix detailing which clk_ops are mandatory based upon the
|
Below is a matrix detailing which clk_ops are mandatory based upon the
|
||||||
hardware capbilities of that clock. A cell marked as "y" means
|
hardware capabilities of that clock. A cell marked as "y" means
|
||||||
mandatory, a cell marked as "n" implies that either including that
|
mandatory, a cell marked as "n" implies that either including that
|
||||||
callback is invalid or otherwise uneccesary. Empty cells are either
|
callback is invalid or otherwise unnecessary. Empty cells are either
|
||||||
optional or must be evaluated on a case-by-case basis.
|
optional or must be evaluated on a case-by-case basis.
|
||||||
|
|
||||||
clock hardware characteristics
|
clock hardware characteristics
|
||||||
@@ -231,3 +231,14 @@ To better enforce this policy, always follow this simple rule: any
|
|||||||
statically initialized clock data MUST be defined in a separate file
|
statically initialized clock data MUST be defined in a separate file
|
||||||
from the logic that implements its ops. Basically separate the logic
|
from the logic that implements its ops. Basically separate the logic
|
||||||
from the data and all is well.
|
from the data and all is well.
|
||||||
|
|
||||||
|
Part 6 - Disabling clock gating of unused clocks
|
||||||
|
|
||||||
|
Sometimes during development it can be useful to be able to bypass the
|
||||||
|
default disabling of unused clocks. For example, if drivers aren't enabling
|
||||||
|
clocks properly but rely on them being on from the bootloader, bypassing
|
||||||
|
the disabling means that the driver will remain functional while the issues
|
||||||
|
are sorted out.
|
||||||
|
|
||||||
|
To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
|
||||||
|
kernel.
|
||||||
|
@@ -30,6 +30,7 @@ The target is named "raid" and it accepts the following parameters:
|
|||||||
raid10 Various RAID10 inspired algorithms chosen by additional params
|
raid10 Various RAID10 inspired algorithms chosen by additional params
|
||||||
- RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
|
- RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
|
||||||
- RAID1E: Integrated Adjacent Stripe Mirroring
|
- RAID1E: Integrated Adjacent Stripe Mirroring
|
||||||
|
- RAID1E: Integrated Offset Stripe Mirroring
|
||||||
- and other similar RAID10 variants
|
- and other similar RAID10 variants
|
||||||
|
|
||||||
Reference: Chapter 4 of
|
Reference: Chapter 4 of
|
||||||
@@ -64,15 +65,15 @@ The target is named "raid" and it accepts the following parameters:
|
|||||||
synchronisation state for each region.
|
synchronisation state for each region.
|
||||||
|
|
||||||
[raid10_copies <# copies>]
|
[raid10_copies <# copies>]
|
||||||
[raid10_format near]
|
[raid10_format <near|far|offset>]
|
||||||
These two options are used to alter the default layout of
|
These two options are used to alter the default layout of
|
||||||
a RAID10 configuration. The number of copies is can be
|
a RAID10 configuration. The number of copies is can be
|
||||||
specified, but the default is 2. There are other variations
|
specified, but the default is 2. There are also three
|
||||||
to how the copies are laid down - the default and only current
|
variations to how the copies are laid down - the default
|
||||||
option is "near". Near copies are what most people think of
|
is "near". Near copies are what most people think of with
|
||||||
with respect to mirroring. If these options are left
|
respect to mirroring. If these options are left unspecified,
|
||||||
unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
|
or 'raid10_copies 2' and/or 'raid10_format near' are given,
|
||||||
are given, then the layouts for 2, 3 and 4 devices are:
|
then the layouts for 2, 3 and 4 devices are:
|
||||||
2 drives 3 drives 4 drives
|
2 drives 3 drives 4 drives
|
||||||
-------- ---------- --------------
|
-------- ---------- --------------
|
||||||
A1 A1 A1 A1 A2 A1 A1 A2 A2
|
A1 A1 A1 A1 A2 A1 A1 A2 A2
|
||||||
@@ -85,6 +86,33 @@ The target is named "raid" and it accepts the following parameters:
|
|||||||
3-device layout is what might be called a 'RAID1E - Integrated
|
3-device layout is what might be called a 'RAID1E - Integrated
|
||||||
Adjacent Stripe Mirroring'.
|
Adjacent Stripe Mirroring'.
|
||||||
|
|
||||||
|
If 'raid10_copies 2' and 'raid10_format far', then the layouts
|
||||||
|
for 2, 3 and 4 devices are:
|
||||||
|
2 drives 3 drives 4 drives
|
||||||
|
-------- -------------- --------------------
|
||||||
|
A1 A2 A1 A2 A3 A1 A2 A3 A4
|
||||||
|
A3 A4 A4 A5 A6 A5 A6 A7 A8
|
||||||
|
A5 A6 A7 A8 A9 A9 A10 A11 A12
|
||||||
|
.. .. .. .. .. .. .. .. ..
|
||||||
|
A2 A1 A3 A1 A2 A2 A1 A4 A3
|
||||||
|
A4 A3 A6 A4 A5 A6 A5 A8 A7
|
||||||
|
A6 A5 A9 A7 A8 A10 A9 A12 A11
|
||||||
|
.. .. .. .. .. .. .. .. ..
|
||||||
|
|
||||||
|
If 'raid10_copies 2' and 'raid10_format offset', then the
|
||||||
|
layouts for 2, 3 and 4 devices are:
|
||||||
|
2 drives 3 drives 4 drives
|
||||||
|
-------- ------------ -----------------
|
||||||
|
A1 A2 A1 A2 A3 A1 A2 A3 A4
|
||||||
|
A2 A1 A3 A1 A2 A2 A1 A4 A3
|
||||||
|
A3 A4 A4 A5 A6 A5 A6 A7 A8
|
||||||
|
A4 A3 A6 A4 A5 A6 A5 A8 A7
|
||||||
|
A5 A6 A7 A8 A9 A9 A10 A11 A12
|
||||||
|
A6 A5 A9 A7 A8 A10 A9 A12 A11
|
||||||
|
.. .. .. .. .. .. .. .. ..
|
||||||
|
Here we see layouts closely akin to 'RAID1E - Integrated
|
||||||
|
Offset Stripe Mirroring'.
|
||||||
|
|
||||||
<#raid_devs>: The number of devices composing the array.
|
<#raid_devs>: The number of devices composing the array.
|
||||||
Each device consists of two entries. The first is the device
|
Each device consists of two entries. The first is the device
|
||||||
containing the metadata (if any); the second is the one containing the
|
containing the metadata (if any); the second is the one containing the
|
||||||
@@ -142,3 +170,5 @@ Version History
|
|||||||
1.3.0 Added support for RAID 10
|
1.3.0 Added support for RAID 10
|
||||||
1.3.1 Allow device replacement/rebuild for RAID 10
|
1.3.1 Allow device replacement/rebuild for RAID 10
|
||||||
1.3.2 Fix/improve redundancy checking for RAID10
|
1.3.2 Fix/improve redundancy checking for RAID10
|
||||||
|
1.4.0 Non-functional change. Removes arg from mapping function.
|
||||||
|
1.4.1 Add RAID10 "far" and "offset" algorithm support.
|
||||||
|
@@ -14,9 +14,19 @@ Required properties:
|
|||||||
- atmel,adc-status-register: Offset of the Interrupt Status Register
|
- atmel,adc-status-register: Offset of the Interrupt Status Register
|
||||||
- atmel,adc-trigger-register: Offset of the Trigger Register
|
- atmel,adc-trigger-register: Offset of the Trigger Register
|
||||||
- atmel,adc-vref: Reference voltage in millivolts for the conversions
|
- atmel,adc-vref: Reference voltage in millivolts for the conversions
|
||||||
|
- atmel,adc-res: List of resolution in bits supported by the ADC. List size
|
||||||
|
must be two at least.
|
||||||
|
- atmel,adc-res-names: Contains one identifier string for each resolution
|
||||||
|
in atmel,adc-res property. "lowres" and "highres"
|
||||||
|
identifiers are required.
|
||||||
|
|
||||||
Optional properties:
|
Optional properties:
|
||||||
- atmel,adc-use-external: Boolean to enable of external triggers
|
- atmel,adc-use-external: Boolean to enable of external triggers
|
||||||
|
- atmel,adc-use-res: String corresponding to an identifier from
|
||||||
|
atmel,adc-res-names property. If not specified, the highest
|
||||||
|
resolution will be used.
|
||||||
|
- atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
|
||||||
|
- atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
|
||||||
|
|
||||||
Optional trigger Nodes:
|
Optional trigger Nodes:
|
||||||
- Required properties:
|
- Required properties:
|
||||||
@@ -40,6 +50,9 @@ adc0: adc@fffb0000 {
|
|||||||
atmel,adc-trigger-register = <0x08>;
|
atmel,adc-trigger-register = <0x08>;
|
||||||
atmel,adc-use-external;
|
atmel,adc-use-external;
|
||||||
atmel,adc-vref = <3300>;
|
atmel,adc-vref = <3300>;
|
||||||
|
atmel,adc-res = <8 10>;
|
||||||
|
atmel,adc-res-names = "lowres", "highres";
|
||||||
|
atmel,adc-use-res = "lowres";
|
||||||
|
|
||||||
trigger@0 {
|
trigger@0 {
|
||||||
trigger-name = "external-rising";
|
trigger-name = "external-rising";
|
||||||
|
18
Documentation/devicetree/bindings/arm/msm/ssbi.txt
Normal file
18
Documentation/devicetree/bindings/arm/msm/ssbi.txt
Normal file
@@ -0,0 +1,18 @@
|
|||||||
|
* Qualcomm SSBI
|
||||||
|
|
||||||
|
Some Qualcomm MSM devices contain a point-to-point serial bus used to
|
||||||
|
communicate with a limited range of devices (mostly power management
|
||||||
|
chips).
|
||||||
|
|
||||||
|
These require the following properties:
|
||||||
|
|
||||||
|
- compatible: "qcom,ssbi"
|
||||||
|
|
||||||
|
- qcom,controller-type
|
||||||
|
indicates the SSBI bus variant the controller should use to talk
|
||||||
|
with the slave device. This should be one of "ssbi", "ssbi2", or
|
||||||
|
"pmic-arbiter". The type chosen is determined by the attached
|
||||||
|
slave.
|
||||||
|
|
||||||
|
The slave device should be the single child node of the ssbi device
|
||||||
|
with a compatible field.
|
60
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
Normal file
60
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
Normal file
@@ -0,0 +1,60 @@
|
|||||||
|
Samsung Exynos Analog to Digital Converter bindings
|
||||||
|
|
||||||
|
The devicetree bindings are for the new ADC driver written for
|
||||||
|
Exynos4 and upward SoCs from Samsung.
|
||||||
|
|
||||||
|
New driver handles the following
|
||||||
|
1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
|
||||||
|
and future SoCs from Samsung
|
||||||
|
2. Add ADC driver under iio/adc framework
|
||||||
|
3. Also adds the Documentation for device tree bindings
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: Must be "samsung,exynos-adc-v1"
|
||||||
|
for exynos4412/5250 controllers.
|
||||||
|
Must be "samsung,exynos-adc-v2" for
|
||||||
|
future controllers.
|
||||||
|
- reg: Contains ADC register address range (base address and
|
||||||
|
length) and the address of the phy enable register.
|
||||||
|
- interrupts: Contains the interrupt information for the timer. The
|
||||||
|
format is being dependent on which interrupt controller
|
||||||
|
the Samsung device uses.
|
||||||
|
- #io-channel-cells = <1>; As ADC has multiple outputs
|
||||||
|
- clocks From common clock binding: handle to adc clock.
|
||||||
|
- clock-names From common clock binding: Shall be "adc".
|
||||||
|
- vdd-supply VDD input supply.
|
||||||
|
|
||||||
|
Note: child nodes can be added for auto probing from device tree.
|
||||||
|
|
||||||
|
Example: adding device info in dtsi file
|
||||||
|
|
||||||
|
adc: adc@12D10000 {
|
||||||
|
compatible = "samsung,exynos-adc-v1";
|
||||||
|
reg = <0x12D10000 0x100>, <0x10040718 0x4>;
|
||||||
|
interrupts = <0 106 0>;
|
||||||
|
#io-channel-cells = <1>;
|
||||||
|
io-channel-ranges;
|
||||||
|
|
||||||
|
clocks = <&clock 303>;
|
||||||
|
clock-names = "adc";
|
||||||
|
|
||||||
|
vdd-supply = <&buck5_reg>;
|
||||||
|
};
|
||||||
|
|
||||||
|
|
||||||
|
Example: Adding child nodes in dts file
|
||||||
|
|
||||||
|
adc@12D10000 {
|
||||||
|
|
||||||
|
/* NTC thermistor is a hwmon device */
|
||||||
|
ncp15wb473@0 {
|
||||||
|
compatible = "ntc,ncp15wb473";
|
||||||
|
pullup-uV = <1800000>;
|
||||||
|
pullup-ohm = <47000>;
|
||||||
|
pulldown-ohm = <0>;
|
||||||
|
io-channels = <&adc 4>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
Note: Does not apply to ADC driver under arch/arm/plat-samsung/
|
||||||
|
Note: The child node can be added under the adc node or separately.
|
22
Documentation/devicetree/bindings/clock/axi-clkgen.txt
Normal file
22
Documentation/devicetree/bindings/clock/axi-clkgen.txt
Normal file
@@ -0,0 +1,22 @@
|
|||||||
|
Binding for the axi-clkgen clock generator
|
||||||
|
|
||||||
|
This binding uses the common clock binding[1].
|
||||||
|
|
||||||
|
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : shall be "adi,axi-clkgen".
|
||||||
|
- #clock-cells : from common clock binding; Should always be set to 0.
|
||||||
|
- reg : Address and length of the axi-clkgen register set.
|
||||||
|
- clocks : Phandle and clock specifier for the parent clock.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- clock-output-names : From common clock binding.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
clock@0xff000000 {
|
||||||
|
compatible = "adi,axi-clkgen";
|
||||||
|
#clock-cells = <0>;
|
||||||
|
reg = <0xff000000 0x1000>;
|
||||||
|
clocks = <&osc 1>;
|
||||||
|
};
|
@@ -0,0 +1,24 @@
|
|||||||
|
Binding for simple fixed factor rate clock sources.
|
||||||
|
|
||||||
|
This binding uses the common clock binding[1].
|
||||||
|
|
||||||
|
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : shall be "fixed-factor-clock".
|
||||||
|
- #clock-cells : from common clock binding; shall be set to 0.
|
||||||
|
- clock-div: fixed divider.
|
||||||
|
- clock-mult: fixed multiplier.
|
||||||
|
- clocks: parent clock.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- clock-output-names : From common clock binding.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
clock {
|
||||||
|
compatible = "fixed-factor-clock";
|
||||||
|
clocks = <&parentclk>;
|
||||||
|
#clock-cells = <0>;
|
||||||
|
div = <2>;
|
||||||
|
mult = <1>;
|
||||||
|
};
|
114
Documentation/devicetree/bindings/clock/silabs,si5351.txt
Normal file
114
Documentation/devicetree/bindings/clock/silabs,si5351.txt
Normal file
@@ -0,0 +1,114 @@
|
|||||||
|
Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
|
||||||
|
|
||||||
|
Reference
|
||||||
|
[1] Si5351A/B/C Data Sheet
|
||||||
|
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
|
||||||
|
|
||||||
|
The Si5351a/b/c are programmable i2c clock generators with upto 8 output
|
||||||
|
clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
|
||||||
|
3 output clocks are accessible. The internal structure of the clock
|
||||||
|
generators can be found in [1].
|
||||||
|
|
||||||
|
==I2C device node==
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
|
||||||
|
- reg: i2c device address, shall be 0x60 or 0x61.
|
||||||
|
- #clock-cells: from common clock binding; shall be set to 1.
|
||||||
|
- clocks: from common clock binding; list of parent clock
|
||||||
|
handles, shall be xtal reference clock or xtal and clkin for
|
||||||
|
si5351c only.
|
||||||
|
- #address-cells: shall be set to 1.
|
||||||
|
- #size-cells: shall be set to 0.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- silabs,pll-source: pair of (number, source) for each pll. Allows
|
||||||
|
to overwrite clock source of pll A (number=0) or B (number=1).
|
||||||
|
|
||||||
|
==Child nodes==
|
||||||
|
|
||||||
|
Each of the clock outputs can be overwritten individually by
|
||||||
|
using a child node to the I2C device node. If a child node for a clock
|
||||||
|
output is not set, the eeprom configuration is not overwritten.
|
||||||
|
|
||||||
|
Required child node properties:
|
||||||
|
- reg: number of clock output.
|
||||||
|
|
||||||
|
Optional child node properties:
|
||||||
|
- silabs,clock-source: source clock of the output divider stage N, shall be
|
||||||
|
0 = multisynth N
|
||||||
|
1 = multisynth 0 for output clocks 0-3, else multisynth4
|
||||||
|
2 = xtal
|
||||||
|
3 = clkin (si5351c only)
|
||||||
|
- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
|
||||||
|
- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
|
||||||
|
divider.
|
||||||
|
- silabs,pll-master: boolean, multisynth can change pll frequency.
|
||||||
|
|
||||||
|
==Example==
|
||||||
|
|
||||||
|
/* 25MHz reference crystal */
|
||||||
|
ref25: ref25M {
|
||||||
|
compatible = "fixed-clock";
|
||||||
|
#clock-cells = <0>;
|
||||||
|
clock-frequency = <25000000>;
|
||||||
|
};
|
||||||
|
|
||||||
|
i2c-master-node {
|
||||||
|
|
||||||
|
/* Si5351a msop10 i2c clock generator */
|
||||||
|
si5351a: clock-generator@60 {
|
||||||
|
compatible = "silabs,si5351a-msop";
|
||||||
|
reg = <0x60>;
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
#clock-cells = <1>;
|
||||||
|
|
||||||
|
/* connect xtal input to 25MHz reference */
|
||||||
|
clocks = <&ref25>;
|
||||||
|
|
||||||
|
/* connect xtal input as source of pll0 and pll1 */
|
||||||
|
silabs,pll-source = <0 0>, <1 0>;
|
||||||
|
|
||||||
|
/*
|
||||||
|
* overwrite clkout0 configuration with:
|
||||||
|
* - 8mA output drive strength
|
||||||
|
* - pll0 as clock source of multisynth0
|
||||||
|
* - multisynth0 as clock source of output divider
|
||||||
|
* - multisynth0 can change pll0
|
||||||
|
* - set initial clock frequency of 74.25MHz
|
||||||
|
*/
|
||||||
|
clkout0 {
|
||||||
|
reg = <0>;
|
||||||
|
silabs,drive-strength = <8>;
|
||||||
|
silabs,multisynth-source = <0>;
|
||||||
|
silabs,clock-source = <0>;
|
||||||
|
silabs,pll-master;
|
||||||
|
clock-frequency = <74250000>;
|
||||||
|
};
|
||||||
|
|
||||||
|
/*
|
||||||
|
* overwrite clkout1 configuration with:
|
||||||
|
* - 4mA output drive strength
|
||||||
|
* - pll1 as clock source of multisynth1
|
||||||
|
* - multisynth1 as clock source of output divider
|
||||||
|
* - multisynth1 can change pll1
|
||||||
|
*/
|
||||||
|
clkout1 {
|
||||||
|
reg = <1>;
|
||||||
|
silabs,drive-strength = <4>;
|
||||||
|
silabs,multisynth-source = <1>;
|
||||||
|
silabs,clock-source = <0>;
|
||||||
|
pll-master;
|
||||||
|
};
|
||||||
|
|
||||||
|
/*
|
||||||
|
* overwrite clkout2 configuration with:
|
||||||
|
* - xtal as clock source of output divider
|
||||||
|
*/
|
||||||
|
clkout2 {
|
||||||
|
reg = <2>;
|
||||||
|
silabs,clock-source = <2>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
151
Documentation/devicetree/bindings/clock/sunxi.txt
Normal file
151
Documentation/devicetree/bindings/clock/sunxi.txt
Normal file
@@ -0,0 +1,151 @@
|
|||||||
|
Device Tree Clock bindings for arch-sunxi
|
||||||
|
|
||||||
|
This binding uses the common clock binding[1].
|
||||||
|
|
||||||
|
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : shall be one of the following:
|
||||||
|
"allwinner,sun4i-osc-clk" - for a gatable oscillator
|
||||||
|
"allwinner,sun4i-pll1-clk" - for the main PLL clock
|
||||||
|
"allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
|
||||||
|
"allwinner,sun4i-axi-clk" - for the AXI clock
|
||||||
|
"allwinner,sun4i-axi-gates-clk" - for the AXI gates
|
||||||
|
"allwinner,sun4i-ahb-clk" - for the AHB clock
|
||||||
|
"allwinner,sun4i-ahb-gates-clk" - for the AHB gates
|
||||||
|
"allwinner,sun4i-apb0-clk" - for the APB0 clock
|
||||||
|
"allwinner,sun4i-apb0-gates-clk" - for the APB0 gates
|
||||||
|
"allwinner,sun4i-apb1-clk" - for the APB1 clock
|
||||||
|
"allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
|
||||||
|
"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates
|
||||||
|
|
||||||
|
Required properties for all clocks:
|
||||||
|
- reg : shall be the control register address for the clock.
|
||||||
|
- clocks : shall be the input parent clock(s) phandle for the clock
|
||||||
|
- #clock-cells : from common clock binding; shall be set to 0 except for
|
||||||
|
"allwinner,sun4i-*-gates-clk" where it shall be set to 1
|
||||||
|
|
||||||
|
Additionally, "allwinner,sun4i-*-gates-clk" clocks require:
|
||||||
|
- clock-output-names : the corresponding gate names that the clock controls
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
osc24M: osc24M@01c20050 {
|
||||||
|
#clock-cells = <0>;
|
||||||
|
compatible = "allwinner,sun4i-osc-clk";
|
||||||
|
reg = <0x01c20050 0x4>;
|
||||||
|
clocks = <&osc24M_fixed>;
|
||||||
|
};
|
||||||
|
|
||||||
|
pll1: pll1@01c20000 {
|
||||||
|
#clock-cells = <0>;
|
||||||
|
compatible = "allwinner,sun4i-pll1-clk";
|
||||||
|
reg = <0x01c20000 0x4>;
|
||||||
|
clocks = <&osc24M>;
|
||||||
|
};
|
||||||
|
|
||||||
|
cpu: cpu@01c20054 {
|
||||||
|
#clock-cells = <0>;
|
||||||
|
compatible = "allwinner,sun4i-cpu-clk";
|
||||||
|
reg = <0x01c20054 0x4>;
|
||||||
|
clocks = <&osc32k>, <&osc24M>, <&pll1>;
|
||||||
|
};
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Gate clock outputs
|
||||||
|
|
||||||
|
The "allwinner,sun4i-*-gates-clk" clocks provide several gatable outputs;
|
||||||
|
their corresponding offsets as present on sun4i are listed below. Note that
|
||||||
|
some of these gates are not present on sun5i.
|
||||||
|
|
||||||
|
* AXI gates ("allwinner,sun4i-axi-gates-clk")
|
||||||
|
|
||||||
|
DRAM 0
|
||||||
|
|
||||||
|
* AHB gates ("allwinner,sun4i-ahb-gates-clk")
|
||||||
|
|
||||||
|
USB0 0
|
||||||
|
EHCI0 1
|
||||||
|
OHCI0 2*
|
||||||
|
EHCI1 3
|
||||||
|
OHCI1 4*
|
||||||
|
SS 5
|
||||||
|
DMA 6
|
||||||
|
BIST 7
|
||||||
|
MMC0 8
|
||||||
|
MMC1 9
|
||||||
|
MMC2 10
|
||||||
|
MMC3 11
|
||||||
|
MS 12**
|
||||||
|
NAND 13
|
||||||
|
SDRAM 14
|
||||||
|
|
||||||
|
ACE 16
|
||||||
|
EMAC 17
|
||||||
|
TS 18
|
||||||
|
|
||||||
|
SPI0 20
|
||||||
|
SPI1 21
|
||||||
|
SPI2 22
|
||||||
|
SPI3 23
|
||||||
|
PATA 24
|
||||||
|
SATA 25**
|
||||||
|
GPS 26*
|
||||||
|
|
||||||
|
VE 32
|
||||||
|
TVD 33
|
||||||
|
TVE0 34
|
||||||
|
TVE1 35
|
||||||
|
LCD0 36
|
||||||
|
LCD1 37
|
||||||
|
|
||||||
|
CSI0 40
|
||||||
|
CSI1 41
|
||||||
|
|
||||||
|
HDMI 43
|
||||||
|
DE_BE0 44
|
||||||
|
DE_BE1 45
|
||||||
|
DE_FE0 46
|
||||||
|
DE_FE1 47
|
||||||
|
|
||||||
|
MP 50
|
||||||
|
|
||||||
|
MALI400 52
|
||||||
|
|
||||||
|
* APB0 gates ("allwinner,sun4i-apb0-gates-clk")
|
||||||
|
|
||||||
|
CODEC 0
|
||||||
|
SPDIF 1*
|
||||||
|
AC97 2
|
||||||
|
IIS 3
|
||||||
|
|
||||||
|
PIO 5
|
||||||
|
IR0 6
|
||||||
|
IR1 7
|
||||||
|
|
||||||
|
KEYPAD 10
|
||||||
|
|
||||||
|
* APB1 gates ("allwinner,sun4i-apb1-gates-clk")
|
||||||
|
|
||||||
|
I2C0 0
|
||||||
|
I2C1 1
|
||||||
|
I2C2 2
|
||||||
|
|
||||||
|
CAN 4
|
||||||
|
SCR 5
|
||||||
|
PS20 6
|
||||||
|
PS21 7
|
||||||
|
|
||||||
|
UART0 16
|
||||||
|
UART1 17
|
||||||
|
UART2 18
|
||||||
|
UART3 19
|
||||||
|
UART4 20
|
||||||
|
UART5 21
|
||||||
|
UART6 22
|
||||||
|
UART7 23
|
||||||
|
|
||||||
|
Notation:
|
||||||
|
[*]: The datasheet didn't mention these, but they are present on AW code
|
||||||
|
[**]: The datasheet had this marked as "NC" but they are used on AW code
|
@@ -98,7 +98,7 @@ announce the pinrange to the pin ctrl subsystem. For example,
|
|||||||
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
|
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
|
||||||
reg = <0x1460 0x18>;
|
reg = <0x1460 0x18>;
|
||||||
gpio-controller;
|
gpio-controller;
|
||||||
gpio-ranges = <&pinctrl1 20 10>, <&pinctrl2 50 20>;
|
gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>;
|
||||||
|
|
||||||
}
|
}
|
||||||
|
|
||||||
@@ -107,8 +107,8 @@ where,
|
|||||||
|
|
||||||
Next values specify the base pin and number of pins for the range
|
Next values specify the base pin and number of pins for the range
|
||||||
handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
|
handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
|
||||||
pin 29 under pinctrl1 and pin 50 to pin 69 under pinctrl2 is handled
|
pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under
|
||||||
by this gpio controller.
|
pinctrl2 with gpio offset 10 is handled by this gpio controller.
|
||||||
|
|
||||||
The pinctrl node must have "#gpio-range-cells" property to show number of
|
The pinctrl node must have "#gpio-range-cells" property to show number of
|
||||||
arguments to pass with phandle from gpio controllers node.
|
arguments to pass with phandle from gpio controllers node.
|
||||||
|
29
Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
Normal file
29
Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
Normal file
@@ -0,0 +1,29 @@
|
|||||||
|
NTC Thermistor hwmon sensors
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
Requires node properties:
|
||||||
|
- "compatible" value : one of
|
||||||
|
"ntc,ncp15wb473"
|
||||||
|
"ntc,ncp18wb473"
|
||||||
|
"ntc,ncp21wb473"
|
||||||
|
"ntc,ncp03wb473"
|
||||||
|
"ntc,ncp15wl333"
|
||||||
|
- "pullup-uv" Pull up voltage in micro volts
|
||||||
|
- "pullup-ohm" Pull up resistor value in ohms
|
||||||
|
- "pulldown-ohm" Pull down resistor value in ohms
|
||||||
|
- "connected-positive" Always ON, If not specified.
|
||||||
|
Status change is possible.
|
||||||
|
- "io-channels" Channel node of ADC to be used for
|
||||||
|
conversion.
|
||||||
|
|
||||||
|
Read more about iio bindings at
|
||||||
|
Documentation/devicetree/bindings/iio/iio-bindings.txt
|
||||||
|
|
||||||
|
Example:
|
||||||
|
ncp15wb473@0 {
|
||||||
|
compatible = "ntc,ncp15wb473";
|
||||||
|
pullup-uv = <1800000>;
|
||||||
|
pullup-ohm = <47000>;
|
||||||
|
pulldown-ohm = <0>;
|
||||||
|
io-channels = <&adc 3>;
|
||||||
|
};
|
97
Documentation/devicetree/bindings/iio/iio-bindings.txt
Normal file
97
Documentation/devicetree/bindings/iio/iio-bindings.txt
Normal file
@@ -0,0 +1,97 @@
|
|||||||
|
This binding is derived from clock bindings, and based on suggestions
|
||||||
|
from Lars-Peter Clausen [1].
|
||||||
|
|
||||||
|
Sources of IIO channels can be represented by any node in the device
|
||||||
|
tree. Those nodes are designated as IIO providers. IIO consumer
|
||||||
|
nodes use a phandle and IIO specifier pair to connect IIO provider
|
||||||
|
outputs to IIO inputs. Similar to the gpio specifiers, an IIO
|
||||||
|
specifier is an array of one or more cells identifying the IIO
|
||||||
|
output on a device. The length of an IIO specifier is defined by the
|
||||||
|
value of a #io-channel-cells property in the IIO provider node.
|
||||||
|
|
||||||
|
[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2
|
||||||
|
|
||||||
|
==IIO providers==
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
|
||||||
|
with a single IIO output and 1 for nodes with multiple
|
||||||
|
IIO outputs.
|
||||||
|
|
||||||
|
Example for a simple configuration with no trigger:
|
||||||
|
|
||||||
|
adc: voltage-sensor@35 {
|
||||||
|
compatible = "maxim,max1139";
|
||||||
|
reg = <0x35>;
|
||||||
|
#io-channel-cells = <1>;
|
||||||
|
};
|
||||||
|
|
||||||
|
Example for a configuration with trigger:
|
||||||
|
|
||||||
|
adc@35 {
|
||||||
|
compatible = "some-vendor,some-adc";
|
||||||
|
reg = <0x35>;
|
||||||
|
|
||||||
|
adc1: iio-device@0 {
|
||||||
|
#io-channel-cells = <1>;
|
||||||
|
/* other properties */
|
||||||
|
};
|
||||||
|
adc2: iio-device@1 {
|
||||||
|
#io-channel-cells = <1>;
|
||||||
|
/* other properties */
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
==IIO consumers==
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
io-channels: List of phandle and IIO specifier pairs, one pair
|
||||||
|
for each IIO input to the device. Note: if the
|
||||||
|
IIO provider specifies '0' for #io-channel-cells,
|
||||||
|
then only the phandle portion of the pair will appear.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
io-channel-names:
|
||||||
|
List of IIO input name strings sorted in the same
|
||||||
|
order as the io-channels property. Consumers drivers
|
||||||
|
will use io-channel-names to match IIO input names
|
||||||
|
with IIO specifiers.
|
||||||
|
io-channel-ranges:
|
||||||
|
Empty property indicating that child nodes can inherit named
|
||||||
|
IIO channels from this node. Useful for bus nodes to provide
|
||||||
|
and IIO channel to their children.
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
device {
|
||||||
|
io-channels = <&adc 1>, <&ref 0>;
|
||||||
|
io-channel-names = "vcc", "vdd";
|
||||||
|
};
|
||||||
|
|
||||||
|
This represents a device with two IIO inputs, named "vcc" and "vdd".
|
||||||
|
The vcc channel is connected to output 1 of the &adc device, and the
|
||||||
|
vdd channel is connected to output 0 of the &ref device.
|
||||||
|
|
||||||
|
==Example==
|
||||||
|
|
||||||
|
adc: max1139@35 {
|
||||||
|
compatible = "maxim,max1139";
|
||||||
|
reg = <0x35>;
|
||||||
|
#io-channel-cells = <1>;
|
||||||
|
};
|
||||||
|
|
||||||
|
...
|
||||||
|
|
||||||
|
iio_hwmon {
|
||||||
|
compatible = "iio-hwmon";
|
||||||
|
io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
|
||||||
|
<&adc 3>, <&adc 4>, <&adc 5>,
|
||||||
|
<&adc 6>, <&adc 7>, <&adc 8>,
|
||||||
|
<&adc 9>;
|
||||||
|
};
|
||||||
|
|
||||||
|
some_consumer {
|
||||||
|
compatible = "some-consumer";
|
||||||
|
io-channels = <&adc 10>, <&adc 11>;
|
||||||
|
io-channel-names = "adc1", "adc2";
|
||||||
|
};
|
30
Documentation/devicetree/bindings/media/coda.txt
Normal file
30
Documentation/devicetree/bindings/media/coda.txt
Normal file
@@ -0,0 +1,30 @@
|
|||||||
|
Chips&Media Coda multi-standard codec IP
|
||||||
|
========================================
|
||||||
|
|
||||||
|
Coda codec IPs are present in i.MX SoCs in various versions,
|
||||||
|
called VPU (Video Processing Unit).
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : should be "fsl,<chip>-src" for i.MX SoCs:
|
||||||
|
(a) "fsl,imx27-vpu" for CodaDx6 present in i.MX27
|
||||||
|
(b) "fsl,imx53-vpu" for CODA7541 present in i.MX53
|
||||||
|
(c) "fsl,imx6q-vpu" for CODA960 present in i.MX6q
|
||||||
|
- reg: should be register base and length as documented in the
|
||||||
|
SoC reference manual
|
||||||
|
- interrupts : Should contain the VPU interrupt. For CODA960,
|
||||||
|
a second interrupt is needed for the MJPEG unit.
|
||||||
|
- clocks : Should contain the ahb and per clocks, in the order
|
||||||
|
determined by the clock-names property.
|
||||||
|
- clock-names : Should be "ahb", "per"
|
||||||
|
- iram : phandle pointing to the SRAM device node
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
vpu: vpu@63ff4000 {
|
||||||
|
compatible = "fsl,imx53-vpu";
|
||||||
|
reg = <0x63ff4000 0x1000>;
|
||||||
|
interrupts = <9>;
|
||||||
|
clocks = <&clks 63>, <&clks 63>;
|
||||||
|
clock-names = "ahb", "per";
|
||||||
|
iram = <&ocram>;
|
||||||
|
};
|
@@ -13,9 +13,6 @@ Required parent device properties:
|
|||||||
4 = active high level-sensitive
|
4 = active high level-sensitive
|
||||||
8 = active low level-sensitive
|
8 = active low level-sensitive
|
||||||
|
|
||||||
Optional parent device properties:
|
|
||||||
- reg : contains the PRCMU mailbox address for the AB8500 i2c port
|
|
||||||
|
|
||||||
The AB8500 consists of a large and varied group of sub-devices:
|
The AB8500 consists of a large and varied group of sub-devices:
|
||||||
|
|
||||||
Device IRQ Names Supply Names Description
|
Device IRQ Names Supply Names Description
|
||||||
@@ -86,9 +83,8 @@ Non-standard child device properties:
|
|||||||
- stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic
|
- stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic
|
||||||
- stericsson,earpeice-cmv : Earpeice voltage (only: 950 | 1100 | 1270 | 1580)
|
- stericsson,earpeice-cmv : Earpeice voltage (only: 950 | 1100 | 1270 | 1580)
|
||||||
|
|
||||||
ab8500@5 {
|
ab8500 {
|
||||||
compatible = "stericsson,ab8500";
|
compatible = "stericsson,ab8500";
|
||||||
reg = <5>; /* mailbox 5 is i2c */
|
|
||||||
interrupts = <0 40 0x4>;
|
interrupts = <0 40 0x4>;
|
||||||
interrupt-controller;
|
interrupt-controller;
|
||||||
#interrupt-cells = <2>;
|
#interrupt-cells = <2>;
|
||||||
|
@@ -10,10 +10,40 @@ Optional properties:
|
|||||||
- fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
|
- fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
|
||||||
|
|
||||||
Sub-nodes:
|
Sub-nodes:
|
||||||
- regulators : Contain the regulator nodes. The MC13892 regulators are
|
- regulators : Contain the regulator nodes. The regulators are bound using
|
||||||
bound using their names as listed below with their registers and bits
|
their names as listed below with their registers and bits for enabling.
|
||||||
for enabling.
|
|
||||||
|
|
||||||
|
MC13783 regulators:
|
||||||
|
sw1a : regulator SW1A (register 24, bit 0)
|
||||||
|
sw1b : regulator SW1B (register 25, bit 0)
|
||||||
|
sw2a : regulator SW2A (register 26, bit 0)
|
||||||
|
sw2b : regulator SW2B (register 27, bit 0)
|
||||||
|
sw3 : regulator SW3 (register 29, bit 20)
|
||||||
|
vaudio : regulator VAUDIO (register 32, bit 0)
|
||||||
|
viohi : regulator VIOHI (register 32, bit 3)
|
||||||
|
violo : regulator VIOLO (register 32, bit 6)
|
||||||
|
vdig : regulator VDIG (register 32, bit 9)
|
||||||
|
vgen : regulator VGEN (register 32, bit 12)
|
||||||
|
vrfdig : regulator VRFDIG (register 32, bit 15)
|
||||||
|
vrfref : regulator VRFREF (register 32, bit 18)
|
||||||
|
vrfcp : regulator VRFCP (register 32, bit 21)
|
||||||
|
vsim : regulator VSIM (register 33, bit 0)
|
||||||
|
vesim : regulator VESIM (register 33, bit 3)
|
||||||
|
vcam : regulator VCAM (register 33, bit 6)
|
||||||
|
vrfbg : regulator VRFBG (register 33, bit 9)
|
||||||
|
vvib : regulator VVIB (register 33, bit 11)
|
||||||
|
vrf1 : regulator VRF1 (register 33, bit 12)
|
||||||
|
vrf2 : regulator VRF2 (register 33, bit 15)
|
||||||
|
vmmc1 : regulator VMMC1 (register 33, bit 18)
|
||||||
|
vmmc2 : regulator VMMC2 (register 33, bit 21)
|
||||||
|
gpo1 : regulator GPO1 (register 34, bit 6)
|
||||||
|
gpo2 : regulator GPO2 (register 34, bit 8)
|
||||||
|
gpo3 : regulator GPO3 (register 34, bit 10)
|
||||||
|
gpo4 : regulator GPO4 (register 34, bit 12)
|
||||||
|
pwgt1spi : regulator PWGT1SPI (register 34, bit 15)
|
||||||
|
pwgt2spi : regulator PWGT2SPI (register 34, bit 16)
|
||||||
|
|
||||||
|
MC13892 regulators:
|
||||||
vcoincell : regulator VCOINCELL (register 13, bit 23)
|
vcoincell : regulator VCOINCELL (register 13, bit 23)
|
||||||
sw1 : regulator SW1 (register 24, bit 0)
|
sw1 : regulator SW1 (register 24, bit 0)
|
||||||
sw2 : regulator SW2 (register 25, bit 0)
|
sw2 : regulator SW2 (register 25, bit 0)
|
||||||
|
16
Documentation/devicetree/bindings/misc/sram.txt
Normal file
16
Documentation/devicetree/bindings/misc/sram.txt
Normal file
@@ -0,0 +1,16 @@
|
|||||||
|
Generic on-chip SRAM
|
||||||
|
|
||||||
|
Simple IO memory regions to be managed by the genalloc API.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
|
||||||
|
- compatible : mmio-sram
|
||||||
|
|
||||||
|
- reg : SRAM iomem address range
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
sram: sram@5c000000 {
|
||||||
|
compatible = "mmio-sram";
|
||||||
|
reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
|
||||||
|
};
|
@@ -1,7 +1,9 @@
|
|||||||
One-register-per-pin type device tree based pinctrl driver
|
One-register-per-pin type device tree based pinctrl driver
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
- compatible : "pinctrl-single"
|
- compatible : "pinctrl-single" or "pinconf-single".
|
||||||
|
"pinctrl-single" means that pinconf isn't supported.
|
||||||
|
"pinconf-single" means that generic pinconf is supported.
|
||||||
|
|
||||||
- reg : offset and length of the register set for the mux registers
|
- reg : offset and length of the register set for the mux registers
|
||||||
|
|
||||||
@@ -14,9 +16,61 @@ Optional properties:
|
|||||||
- pinctrl-single,function-off : function off mode for disabled state if
|
- pinctrl-single,function-off : function off mode for disabled state if
|
||||||
available and same for all registers; if not specified, disabling of
|
available and same for all registers; if not specified, disabling of
|
||||||
pin functions is ignored
|
pin functions is ignored
|
||||||
|
|
||||||
- pinctrl-single,bit-per-mux : boolean to indicate that one register controls
|
- pinctrl-single,bit-per-mux : boolean to indicate that one register controls
|
||||||
more than one pin
|
more than one pin
|
||||||
|
|
||||||
|
- pinctrl-single,drive-strength : array of value that are used to configure
|
||||||
|
drive strength in the pinmux register. They're value of drive strength
|
||||||
|
current and drive strength mask.
|
||||||
|
|
||||||
|
/* drive strength current, mask */
|
||||||
|
pinctrl-single,power-source = <0x30 0xf0>;
|
||||||
|
|
||||||
|
- pinctrl-single,bias-pullup : array of value that are used to configure the
|
||||||
|
input bias pullup in the pinmux register.
|
||||||
|
|
||||||
|
/* input, enabled pullup bits, disabled pullup bits, mask */
|
||||||
|
pinctrl-single,bias-pullup = <0 1 0 1>;
|
||||||
|
|
||||||
|
- pinctrl-single,bias-pulldown : array of value that are used to configure the
|
||||||
|
input bias pulldown in the pinmux register.
|
||||||
|
|
||||||
|
/* input, enabled pulldown bits, disabled pulldown bits, mask */
|
||||||
|
pinctrl-single,bias-pulldown = <2 2 0 2>;
|
||||||
|
|
||||||
|
* Two bits to control input bias pullup and pulldown: User should use
|
||||||
|
pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. One bit means
|
||||||
|
pullup, and the other one bit means pulldown.
|
||||||
|
* Three bits to control input bias enable, pullup and pulldown. User should
|
||||||
|
use pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. Input bias
|
||||||
|
enable bit should be included in pullup or pulldown bits.
|
||||||
|
* Although driver could set PIN_CONFIG_BIAS_DISABLE, there's no property as
|
||||||
|
pinctrl-single,bias-disable. Because pinctrl single driver could implement
|
||||||
|
it by calling pulldown, pullup disabled.
|
||||||
|
|
||||||
|
- pinctrl-single,input-schmitt : array of value that are used to configure
|
||||||
|
input schmitt in the pinmux register. In some silicons, there're two input
|
||||||
|
schmitt value (rising-edge & falling-edge) in the pinmux register.
|
||||||
|
|
||||||
|
/* input schmitt value, mask */
|
||||||
|
pinctrl-single,input-schmitt = <0x30 0x70>;
|
||||||
|
|
||||||
|
- pinctrl-single,input-schmitt-enable : array of value that are used to
|
||||||
|
configure input schmitt enable or disable in the pinmux register.
|
||||||
|
|
||||||
|
/* input, enable bits, disable bits, mask */
|
||||||
|
pinctrl-single,input-schmitt-enable = <0x30 0x40 0 0x70>;
|
||||||
|
|
||||||
|
- pinctrl-single,gpio-range : list of value that are used to configure a GPIO
|
||||||
|
range. They're value of subnode phandle, pin base in pinctrl device, pin
|
||||||
|
number in this range, GPIO function value of this GPIO range.
|
||||||
|
The number of parameters is depend on #pinctrl-single,gpio-range-cells
|
||||||
|
property.
|
||||||
|
|
||||||
|
/* pin base, nr pins & gpio function */
|
||||||
|
pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>;
|
||||||
|
|
||||||
This driver assumes that there is only one register for each pin (unless the
|
This driver assumes that there is only one register for each pin (unless the
|
||||||
pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
|
pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
|
||||||
specified in the pinctrl-bindings.txt document in this directory.
|
specified in the pinctrl-bindings.txt document in this directory.
|
||||||
@@ -42,6 +96,20 @@ Where 0xdc is the offset from the pinctrl register base address for the
|
|||||||
device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
|
device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
|
||||||
be used when applying this change to the register.
|
be used when applying this change to the register.
|
||||||
|
|
||||||
|
|
||||||
|
Optional sub-node: In case some pins could be configured as GPIO in the pinmux
|
||||||
|
register, those pins could be defined as a GPIO range. This sub-node is required
|
||||||
|
by pinctrl-single,gpio-range property.
|
||||||
|
|
||||||
|
Required properties in sub-node:
|
||||||
|
- #pinctrl-single,gpio-range-cells : the number of parameters after phandle in
|
||||||
|
pinctrl-single,gpio-range property.
|
||||||
|
|
||||||
|
range: gpio-range {
|
||||||
|
#pinctrl-single,gpio-range-cells = <3>;
|
||||||
|
};
|
||||||
|
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
/* SoC common file */
|
/* SoC common file */
|
||||||
@@ -58,7 +126,7 @@ pmx_core: pinmux@4a100040 {
|
|||||||
|
|
||||||
/* second controller instance for pins in wkup domain */
|
/* second controller instance for pins in wkup domain */
|
||||||
pmx_wkup: pinmux@4a31e040 {
|
pmx_wkup: pinmux@4a31e040 {
|
||||||
compatible = "pinctrl-single;
|
compatible = "pinctrl-single";
|
||||||
reg = <0x4a31e040 0x0038>;
|
reg = <0x4a31e040 0x0038>;
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
#size-cells = <0>;
|
#size-cells = <0>;
|
||||||
@@ -76,6 +144,29 @@ control_devconf0: pinmux@48002274 {
|
|||||||
pinctrl-single,function-mask = <0x5F>;
|
pinctrl-single,function-mask = <0x5F>;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
/* third controller instance for pins in gpio domain */
|
||||||
|
pmx_gpio: pinmux@d401e000 {
|
||||||
|
compatible = "pinconf-single";
|
||||||
|
reg = <0xd401e000 0x0330>;
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <1>;
|
||||||
|
ranges;
|
||||||
|
|
||||||
|
pinctrl-single,register-width = <32>;
|
||||||
|
pinctrl-single,function-mask = <7>;
|
||||||
|
|
||||||
|
/* sparse GPIO range could be supported */
|
||||||
|
pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1
|
||||||
|
&range 12 1 0 &range 13 29 1
|
||||||
|
&range 43 1 0 &range 44 49 1
|
||||||
|
&range 94 1 1 &range 96 2 1>;
|
||||||
|
|
||||||
|
range: gpio-range {
|
||||||
|
#pinctrl-single,gpio-range-cells = <3>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
|
||||||
/* board specific .dts file */
|
/* board specific .dts file */
|
||||||
|
|
||||||
&pmx_core {
|
&pmx_core {
|
||||||
@@ -96,6 +187,15 @@ control_devconf0: pinmux@48002274 {
|
|||||||
>;
|
>;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
uart0_pins: pinmux_uart0_pins {
|
||||||
|
pinctrl-single,pins = <
|
||||||
|
0x208 0 /* UART0_RXD (IOCFG138) */
|
||||||
|
0x20c 0 /* UART0_TXD (IOCFG139) */
|
||||||
|
>;
|
||||||
|
pinctrl-single,bias-pulldown = <0 2 2>;
|
||||||
|
pinctrl-single,bias-pullup = <0 1 1>;
|
||||||
|
};
|
||||||
|
|
||||||
/* map uart2 pins */
|
/* map uart2 pins */
|
||||||
uart2_pins: pinmux_uart2_pins {
|
uart2_pins: pinmux_uart2_pins {
|
||||||
pinctrl-single,pins = <
|
pinctrl-single,pins = <
|
||||||
@@ -122,6 +222,11 @@ control_devconf0: pinmux@48002274 {
|
|||||||
|
|
||||||
};
|
};
|
||||||
|
|
||||||
|
&uart1 {
|
||||||
|
pinctrl-names = "default";
|
||||||
|
pinctrl-0 = <&uart0_pins>;
|
||||||
|
};
|
||||||
|
|
||||||
&uart2 {
|
&uart2 {
|
||||||
pinctrl-names = "default";
|
pinctrl-names = "default";
|
||||||
pinctrl-0 = <&uart2_pins>;
|
pinctrl-0 = <&uart2_pins>;
|
||||||
|
@@ -7,6 +7,7 @@ on-chip controllers onto these pads.
|
|||||||
|
|
||||||
Required Properties:
|
Required Properties:
|
||||||
- compatible: should be one of the following.
|
- compatible: should be one of the following.
|
||||||
|
- "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
|
||||||
- "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
|
- "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
|
||||||
- "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
|
- "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
|
||||||
- "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller.
|
- "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller.
|
||||||
@@ -105,6 +106,8 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a
|
|||||||
|
|
||||||
- compatible: identifies the type of the external wakeup interrupt controller
|
- compatible: identifies the type of the external wakeup interrupt controller
|
||||||
The possible values are:
|
The possible values are:
|
||||||
|
- samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller
|
||||||
|
found on Samsung S3C64xx SoCs,
|
||||||
- samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
|
- samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
|
||||||
found on Samsung Exynos4210 SoC.
|
found on Samsung Exynos4210 SoC.
|
||||||
- interrupt-parent: phandle of the interrupt parent to which the external
|
- interrupt-parent: phandle of the interrupt parent to which the external
|
||||||
|
52
Documentation/devicetree/bindings/regulator/max8952.txt
Normal file
52
Documentation/devicetree/bindings/regulator/max8952.txt
Normal file
@@ -0,0 +1,52 @@
|
|||||||
|
Maxim MAX8952 voltage regulator
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: must be equal to "maxim,max8952"
|
||||||
|
- reg: I2C slave address, usually 0x60
|
||||||
|
- max8952,dvs-mode-microvolt: array of 4 integer values defining DVS voltages
|
||||||
|
in microvolts. All values must be from range <770000, 1400000>
|
||||||
|
- any required generic properties defined in regulator.txt
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- max8952,vid-gpios: array of two GPIO pins used for DVS voltage selection
|
||||||
|
- max8952,en-gpio: GPIO used to control enable status of regulator
|
||||||
|
- max8952,default-mode: index of default DVS voltage, from <0, 3> range
|
||||||
|
- max8952,sync-freq: sync frequency, must be one of following values:
|
||||||
|
- 0: 26 MHz
|
||||||
|
- 1: 13 MHz
|
||||||
|
- 2: 19.2 MHz
|
||||||
|
Defaults to 26 MHz if not specified.
|
||||||
|
- max8952,ramp-speed: voltage ramp speed, must be one of following values:
|
||||||
|
- 0: 32mV/us
|
||||||
|
- 1: 16mV/us
|
||||||
|
- 2: 8mV/us
|
||||||
|
- 3: 4mV/us
|
||||||
|
- 4: 2mV/us
|
||||||
|
- 5: 1mV/us
|
||||||
|
- 6: 0.5mV/us
|
||||||
|
- 7: 0.25mV/us
|
||||||
|
Defaults to 32mV/us if not specified.
|
||||||
|
- any available generic properties defined in regulator.txt
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
vdd_arm_reg: pmic@60 {
|
||||||
|
compatible = "maxim,max8952";
|
||||||
|
reg = <0x60>;
|
||||||
|
|
||||||
|
/* max8952-specific properties */
|
||||||
|
max8952,vid-gpios = <&gpx0 3 0>, <&gpx0 4 0>;
|
||||||
|
max8952,en-gpio = <&gpx0 1 0>;
|
||||||
|
max8952,default-mode = <0>;
|
||||||
|
max8952,dvs-mode-microvolt = <1250000>, <1200000>,
|
||||||
|
<1050000>, <950000>;
|
||||||
|
max8952,sync-freq = <0>;
|
||||||
|
max8952,ramp-speed = <0>;
|
||||||
|
|
||||||
|
/* generic regulator properties */
|
||||||
|
regulator-name = "vdd_arm";
|
||||||
|
regulator-min-microvolt = <770000>;
|
||||||
|
regulator-max-microvolt = <1400000>;
|
||||||
|
regulator-always-on;
|
||||||
|
regulator-boot-on;
|
||||||
|
};
|
@@ -0,0 +1,15 @@
|
|||||||
|
Atmel AT91RM9200 Real Time Clock
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: should be: "atmel,at91rm9200-rtc"
|
||||||
|
- reg: physical base address of the controller and length of memory mapped
|
||||||
|
region.
|
||||||
|
- interrupts: rtc alarm/event interrupt
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
rtc@fffffe00 {
|
||||||
|
compatible = "atmel,at91rm9200-rtc";
|
||||||
|
reg = <0xfffffe00 0x100>;
|
||||||
|
interrupts = <1 4 7>;
|
||||||
|
};
|
22
Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
Normal file
22
Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
Normal file
@@ -0,0 +1,22 @@
|
|||||||
|
Broadcom BCM2835 SPI0 controller
|
||||||
|
|
||||||
|
The BCM2835 contains two forms of SPI master controller, one known simply as
|
||||||
|
SPI0, and the other known as the "Universal SPI Master"; part of the
|
||||||
|
auxilliary block. This binding applies to the SPI0 controller.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: Should be "brcm,bcm2835-spi".
|
||||||
|
- reg: Should contain register location and length.
|
||||||
|
- interrupts: Should contain interrupt.
|
||||||
|
- clocks: The clock feeding the SPI controller.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
spi@20204000 {
|
||||||
|
compatible = "brcm,bcm2835-spi";
|
||||||
|
reg = <0x7e204000 0x1000>;
|
||||||
|
interrupts = <2 22>;
|
||||||
|
clocks = <&clk_spi>;
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
};
|
@@ -4,7 +4,7 @@ Required properties:
|
|||||||
- cell-index : QE SPI subblock index.
|
- cell-index : QE SPI subblock index.
|
||||||
0: QE subblock SPI1
|
0: QE subblock SPI1
|
||||||
1: QE subblock SPI2
|
1: QE subblock SPI2
|
||||||
- compatible : should be "fsl,spi".
|
- compatible : should be "fsl,spi" or "aeroflexgaisler,spictrl".
|
||||||
- mode : the SPI operation mode, it can be "cpu" or "cpu-qe".
|
- mode : the SPI operation mode, it can be "cpu" or "cpu-qe".
|
||||||
- reg : Offset and length of the register set for the device
|
- reg : Offset and length of the register set for the device
|
||||||
- interrupts : <a b> where a is the interrupt number and b is a
|
- interrupts : <a b> where a is the interrupt number and b is a
|
||||||
@@ -14,6 +14,7 @@ Required properties:
|
|||||||
controller you have.
|
controller you have.
|
||||||
- interrupt-parent : the phandle for the interrupt controller that
|
- interrupt-parent : the phandle for the interrupt controller that
|
||||||
services interrupts for this device.
|
services interrupts for this device.
|
||||||
|
- clock-frequency : input clock frequency to non FSL_SOC cores
|
||||||
|
|
||||||
Optional properties:
|
Optional properties:
|
||||||
- gpios : specifies the gpio pins to be used for chipselects.
|
- gpios : specifies the gpio pins to be used for chipselects.
|
||||||
|
@@ -0,0 +1,26 @@
|
|||||||
|
NVIDIA Tegra114 SPI controller.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : should be "nvidia,tegra114-spi".
|
||||||
|
- reg: Should contain SPI registers location and length.
|
||||||
|
- interrupts: Should contain SPI interrupts.
|
||||||
|
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
|
||||||
|
request selector for this SPI controller.
|
||||||
|
- This is also require clock named "spi" as per binding document
|
||||||
|
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||||
|
|
||||||
|
Recommended properties:
|
||||||
|
- spi-max-frequency: Definition as per
|
||||||
|
Documentation/devicetree/bindings/spi/spi-bus.txt
|
||||||
|
Example:
|
||||||
|
|
||||||
|
spi@7000d600 {
|
||||||
|
compatible = "nvidia,tegra114-spi";
|
||||||
|
reg = <0x7000d600 0x200>;
|
||||||
|
interrupts = <0 82 0x04>;
|
||||||
|
nvidia,dma-request-selector = <&apbdma 16>;
|
||||||
|
spi-max-frequency = <25000000>;
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <0>;
|
||||||
|
status = "disabled";
|
||||||
|
};
|
@@ -31,9 +31,6 @@ Required Board Specific Properties:
|
|||||||
|
|
||||||
- #address-cells: should be 1.
|
- #address-cells: should be 1.
|
||||||
- #size-cells: should be 0.
|
- #size-cells: should be 0.
|
||||||
- gpios: The gpio specifier for clock, mosi and miso interface lines (in the
|
|
||||||
order specified). The format of the gpio specifier depends on the gpio
|
|
||||||
controller.
|
|
||||||
|
|
||||||
Optional Board Specific Properties:
|
Optional Board Specific Properties:
|
||||||
|
|
||||||
@@ -86,9 +83,8 @@ Example:
|
|||||||
spi_0: spi@12d20000 {
|
spi_0: spi@12d20000 {
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
#size-cells = <0>;
|
#size-cells = <0>;
|
||||||
gpios = <&gpa2 4 2 3 0>,
|
pinctrl-names = "default";
|
||||||
<&gpa2 6 2 3 0>,
|
pinctrl-0 = <&spi0_bus>;
|
||||||
<&gpa2 7 2 3 0>;
|
|
||||||
|
|
||||||
w25q80bw@0 {
|
w25q80bw@0 {
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
|
15
Documentation/devicetree/bindings/staging/dwc2.txt
Normal file
15
Documentation/devicetree/bindings/staging/dwc2.txt
Normal file
@@ -0,0 +1,15 @@
|
|||||||
|
Platform DesignWare HS OTG USB 2.0 controller
|
||||||
|
-----------------------------------------------------
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : "snps,dwc2"
|
||||||
|
- reg : Should contain 1 register range (address and length)
|
||||||
|
- interrupts : Should contain 1 interrupt
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
usb@101c0000 {
|
||||||
|
compatible = "ralink,rt3050-usb, snps,dwc2";
|
||||||
|
reg = <0x101c0000 40000>;
|
||||||
|
interrupts = <18>;
|
||||||
|
};
|
@@ -26,7 +26,7 @@ Required properties:
|
|||||||
- crtc: the crtc this display is connected to, see below
|
- crtc: the crtc this display is connected to, see below
|
||||||
Optional properties:
|
Optional properties:
|
||||||
- interface_pix_fmt: How this display is connected to the
|
- interface_pix_fmt: How this display is connected to the
|
||||||
crtc. Currently supported types: "rgb24", "rgb565"
|
crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
|
||||||
- edid: verbatim EDID data block describing attached display.
|
- edid: verbatim EDID data block describing attached display.
|
||||||
- ddc: phandle describing the i2c bus handling the display data
|
- ddc: phandle describing the i2c bus handling the display data
|
||||||
channel
|
channel
|
||||||
|
@@ -11,6 +11,9 @@ Required properties:
|
|||||||
- "nvidia,tegra20-uart"
|
- "nvidia,tegra20-uart"
|
||||||
- "nxp,lpc3220-uart"
|
- "nxp,lpc3220-uart"
|
||||||
- "ibm,qpace-nwp-serial"
|
- "ibm,qpace-nwp-serial"
|
||||||
|
- "altr,16550-FIFO32"
|
||||||
|
- "altr,16550-FIFO64"
|
||||||
|
- "altr,16550-FIFO128"
|
||||||
- "serial" if the port type is unknown.
|
- "serial" if the port type is unknown.
|
||||||
- reg : offset and length of the register set for the device.
|
- reg : offset and length of the register set for the device.
|
||||||
- interrupts : should contain uart interrupt.
|
- interrupts : should contain uart interrupt.
|
||||||
@@ -30,6 +33,10 @@ Optional properties:
|
|||||||
RTAS and should not be registered.
|
RTAS and should not be registered.
|
||||||
- no-loopback-test: set to indicate that the port does not implements loopback
|
- no-loopback-test: set to indicate that the port does not implements loopback
|
||||||
test mode
|
test mode
|
||||||
|
- fifo-size: the fifo size of the UART.
|
||||||
|
- auto-flow-control: one way to enable automatic flow control support. The
|
||||||
|
driver is allowed to detect support for the capability even without this
|
||||||
|
property.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
|
@@ -11,6 +11,7 @@ Optional properties:
|
|||||||
that indicate usb controller index
|
that indicate usb controller index
|
||||||
- vbus-supply: regulator for vbus
|
- vbus-supply: regulator for vbus
|
||||||
- disable-over-current: disable over current detect
|
- disable-over-current: disable over current detect
|
||||||
|
- external-vbus-divider: enables off-chip resistor divider for Vbus
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
usb@02184000 { /* USB OTG */
|
usb@02184000 { /* USB OTG */
|
||||||
@@ -20,4 +21,5 @@ usb@02184000 { /* USB OTG */
|
|||||||
fsl,usbphy = <&usbphy1>;
|
fsl,usbphy = <&usbphy1>;
|
||||||
fsl,usbmisc = <&usbmisc 0>;
|
fsl,usbmisc = <&usbmisc 0>;
|
||||||
disable-over-current;
|
disable-over-current;
|
||||||
|
external-vbus-divider;
|
||||||
};
|
};
|
||||||
|
32
Documentation/devicetree/bindings/usb/ehci-omap.txt
Normal file
32
Documentation/devicetree/bindings/usb/ehci-omap.txt
Normal file
@@ -0,0 +1,32 @@
|
|||||||
|
OMAP HS USB EHCI controller
|
||||||
|
|
||||||
|
This device is usually the child of the omap-usb-host
|
||||||
|
Documentation/devicetree/bindings/mfd/omap-usb-host.txt
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
|
||||||
|
- compatible: should be "ti,ehci-omap"
|
||||||
|
- reg: should contain one register range i.e. start and length
|
||||||
|
- interrupts: description of the interrupt line
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
|
||||||
|
- phys: list of phandles to PHY nodes.
|
||||||
|
This property is required if at least one of the ports are in
|
||||||
|
PHY mode i.e. OMAP_EHCI_PORT_MODE_PHY
|
||||||
|
|
||||||
|
To specify the port mode, see
|
||||||
|
Documentation/devicetree/bindings/mfd/omap-usb-host.txt
|
||||||
|
|
||||||
|
Example for OMAP4:
|
||||||
|
|
||||||
|
usbhsehci: ehci@4a064c00 {
|
||||||
|
compatible = "ti,ehci-omap", "usb-ehci";
|
||||||
|
reg = <0x4a064c00 0x400>;
|
||||||
|
interrupts = <0 77 0x4>;
|
||||||
|
};
|
||||||
|
|
||||||
|
&usbhsehci {
|
||||||
|
phys = <&hsusb1_phy 0 &hsusb3_phy>;
|
||||||
|
};
|
||||||
|
|
15
Documentation/devicetree/bindings/usb/ohci-omap3.txt
Normal file
15
Documentation/devicetree/bindings/usb/ohci-omap3.txt
Normal file
@@ -0,0 +1,15 @@
|
|||||||
|
OMAP HS USB OHCI controller (OMAP3 and later)
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
|
||||||
|
- compatible: should be "ti,ohci-omap3"
|
||||||
|
- reg: should contain one register range i.e. start and length
|
||||||
|
- interrupts: description of the interrupt line
|
||||||
|
|
||||||
|
Example for OMAP4:
|
||||||
|
|
||||||
|
usbhsohci: ohci@4a064800 {
|
||||||
|
compatible = "ti,ohci-omap3", "usb-ohci";
|
||||||
|
reg = <0x4a064800 0x400>;
|
||||||
|
interrupts = <0 76 0x4>;
|
||||||
|
};
|
@@ -8,10 +8,10 @@ OMAP MUSB GLUE
|
|||||||
and disconnect.
|
and disconnect.
|
||||||
- multipoint : Should be "1" indicating the musb controller supports
|
- multipoint : Should be "1" indicating the musb controller supports
|
||||||
multipoint. This is a MUSB configuration-specific setting.
|
multipoint. This is a MUSB configuration-specific setting.
|
||||||
- num_eps : Specifies the number of endpoints. This is also a
|
- num-eps : Specifies the number of endpoints. This is also a
|
||||||
MUSB configuration-specific setting. Should be set to "16"
|
MUSB configuration-specific setting. Should be set to "16"
|
||||||
- ram_bits : Specifies the ram address size. Should be set to "12"
|
- ram-bits : Specifies the ram address size. Should be set to "12"
|
||||||
- interface_type : This is a board specific setting to describe the type of
|
- interface-type : This is a board specific setting to describe the type of
|
||||||
interface between the controller and the phy. It should be "0" or "1"
|
interface between the controller and the phy. It should be "0" or "1"
|
||||||
specifying ULPI and UTMI respectively.
|
specifying ULPI and UTMI respectively.
|
||||||
- mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
|
- mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
|
||||||
@@ -29,18 +29,46 @@ usb_otg_hs: usb_otg_hs@4a0ab000 {
|
|||||||
ti,hwmods = "usb_otg_hs";
|
ti,hwmods = "usb_otg_hs";
|
||||||
ti,has-mailbox;
|
ti,has-mailbox;
|
||||||
multipoint = <1>;
|
multipoint = <1>;
|
||||||
num_eps = <16>;
|
num-eps = <16>;
|
||||||
ram_bits = <12>;
|
ram-bits = <12>;
|
||||||
ctrl-module = <&omap_control_usb>;
|
ctrl-module = <&omap_control_usb>;
|
||||||
};
|
};
|
||||||
|
|
||||||
Board specific device node entry
|
Board specific device node entry
|
||||||
&usb_otg_hs {
|
&usb_otg_hs {
|
||||||
interface_type = <1>;
|
interface-type = <1>;
|
||||||
mode = <3>;
|
mode = <3>;
|
||||||
power = <50>;
|
power = <50>;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
OMAP DWC3 GLUE
|
||||||
|
- compatible : Should be "ti,dwc3"
|
||||||
|
- ti,hwmods : Should be "usb_otg_ss"
|
||||||
|
- reg : Address and length of the register set for the device.
|
||||||
|
- interrupts : The irq number of this device that is used to interrupt the
|
||||||
|
MPU
|
||||||
|
- #address-cells, #size-cells : Must be present if the device has sub-nodes
|
||||||
|
- utmi-mode : controls the source of UTMI/PIPE status for VBUS and OTG ID.
|
||||||
|
It should be set to "1" for HW mode and "2" for SW mode.
|
||||||
|
- ranges: the child address space are mapped 1:1 onto the parent address space
|
||||||
|
|
||||||
|
Sub-nodes:
|
||||||
|
The dwc3 core should be added as subnode to omap dwc3 glue.
|
||||||
|
- dwc3 :
|
||||||
|
The binding details of dwc3 can be found in:
|
||||||
|
Documentation/devicetree/bindings/usb/dwc3.txt
|
||||||
|
|
||||||
|
omap_dwc3 {
|
||||||
|
compatible = "ti,dwc3";
|
||||||
|
ti,hwmods = "usb_otg_ss";
|
||||||
|
reg = <0x4a020000 0x1ff>;
|
||||||
|
interrupts = <0 93 4>;
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <1>;
|
||||||
|
utmi-mode = <2>;
|
||||||
|
ranges;
|
||||||
|
};
|
||||||
|
|
||||||
OMAP CONTROL USB
|
OMAP CONTROL USB
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
|
@@ -1,20 +1,25 @@
|
|||||||
* Samsung's usb phy transceiver
|
SAMSUNG USB-PHY controllers
|
||||||
|
|
||||||
The Samsung's phy transceiver is used for controlling usb phy for
|
** Samsung's usb 2.0 phy transceiver
|
||||||
s3c-hsotg as well as ehci-s5p and ohci-exynos usb controllers
|
|
||||||
across Samsung SOCs.
|
The Samsung's usb 2.0 phy transceiver is used for controlling
|
||||||
|
usb 2.0 phy for s3c-hsotg as well as ehci-s5p and ohci-exynos
|
||||||
|
usb controllers across Samsung SOCs.
|
||||||
TODO: Adding the PHY binding with controller(s) according to the under
|
TODO: Adding the PHY binding with controller(s) according to the under
|
||||||
developement generic PHY driver.
|
developement generic PHY driver.
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
|
|
||||||
Exynos4210:
|
Exynos4210:
|
||||||
- compatible : should be "samsung,exynos4210-usbphy"
|
- compatible : should be "samsung,exynos4210-usb2phy"
|
||||||
- reg : base physical address of the phy registers and length of memory mapped
|
- reg : base physical address of the phy registers and length of memory mapped
|
||||||
region.
|
region.
|
||||||
|
- clocks: Clock IDs array as required by the controller.
|
||||||
|
- clock-names: names of clock correseponding IDs clock property as requested
|
||||||
|
by the controller driver.
|
||||||
|
|
||||||
Exynos5250:
|
Exynos5250:
|
||||||
- compatible : should be "samsung,exynos5250-usbphy"
|
- compatible : should be "samsung,exynos5250-usb2phy"
|
||||||
- reg : base physical address of the phy registers and length of memory mapped
|
- reg : base physical address of the phy registers and length of memory mapped
|
||||||
region.
|
region.
|
||||||
|
|
||||||
@@ -44,12 +49,69 @@ Example:
|
|||||||
usbphy@125B0000 {
|
usbphy@125B0000 {
|
||||||
#address-cells = <1>;
|
#address-cells = <1>;
|
||||||
#size-cells = <1>;
|
#size-cells = <1>;
|
||||||
compatible = "samsung,exynos4210-usbphy";
|
compatible = "samsung,exynos4210-usb2phy";
|
||||||
reg = <0x125B0000 0x100>;
|
reg = <0x125B0000 0x100>;
|
||||||
ranges;
|
ranges;
|
||||||
|
|
||||||
|
clocks = <&clock 2>, <&clock 305>;
|
||||||
|
clock-names = "xusbxti", "otg";
|
||||||
|
|
||||||
usbphy-sys {
|
usbphy-sys {
|
||||||
/* USB device and host PHY_CONTROL registers */
|
/* USB device and host PHY_CONTROL registers */
|
||||||
reg = <0x10020704 0x8>;
|
reg = <0x10020704 0x8>;
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
|
|
||||||
|
** Samsung's usb 3.0 phy transceiver
|
||||||
|
|
||||||
|
Starting exynso5250, Samsung's SoC have usb 3.0 phy transceiver
|
||||||
|
which is used for controlling usb 3.0 phy for dwc3-exynos usb 3.0
|
||||||
|
controllers across Samsung SOCs.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
|
||||||
|
Exynos5250:
|
||||||
|
- compatible : should be "samsung,exynos5250-usb3phy"
|
||||||
|
- reg : base physical address of the phy registers and length of memory mapped
|
||||||
|
region.
|
||||||
|
- clocks: Clock IDs array as required by the controller.
|
||||||
|
- clock-names: names of clocks correseponding to IDs in the clock property
|
||||||
|
as requested by the controller driver.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- #address-cells: should be '1' when usbphy node has a child node with 'reg'
|
||||||
|
property.
|
||||||
|
- #size-cells: should be '1' when usbphy node has a child node with 'reg'
|
||||||
|
property.
|
||||||
|
- ranges: allows valid translation between child's address space and parent's
|
||||||
|
address space.
|
||||||
|
|
||||||
|
- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
|
||||||
|
interface for usb-phy. It should provide the following information required by
|
||||||
|
usb-phy controller to control phy.
|
||||||
|
- reg : base physical address of PHY_CONTROL registers.
|
||||||
|
The size of this register is the total sum of size of all PHY_CONTROL
|
||||||
|
registers that the SoC has. For example, the size will be
|
||||||
|
'0x4' in case we have only one PHY_CONTROL register (e.g.
|
||||||
|
OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210)
|
||||||
|
and, '0x8' in case we have two PHY_CONTROL registers (e.g.
|
||||||
|
USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x).
|
||||||
|
and so on.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
usbphy@12100000 {
|
||||||
|
compatible = "samsung,exynos5250-usb3phy";
|
||||||
|
reg = <0x12100000 0x100>;
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <1>;
|
||||||
|
ranges;
|
||||||
|
|
||||||
|
clocks = <&clock 1>, <&clock 286>;
|
||||||
|
clock-names = "ext_xtal", "usbdrd30";
|
||||||
|
|
||||||
|
usbphy-sys {
|
||||||
|
/* USB device and host PHY_CONTROL registers */
|
||||||
|
reg = <0x10040704 0x8>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
34
Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
Normal file
34
Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
Normal file
@@ -0,0 +1,34 @@
|
|||||||
|
USB NOP PHY
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: should be usb-nop-xceiv
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
|
||||||
|
/bindings/clock/clock-bindings.txt
|
||||||
|
This property is required if clock-frequency is specified.
|
||||||
|
|
||||||
|
- clock-names: Should be "main_clk"
|
||||||
|
|
||||||
|
- clock-frequency: the clock frequency (in Hz) that the PHY clock must
|
||||||
|
be configured to.
|
||||||
|
|
||||||
|
- vcc-supply: phandle to the regulator that provides RESET to the PHY.
|
||||||
|
|
||||||
|
- reset-supply: phandle to the regulator that provides power to the PHY.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
hsusb1_phy {
|
||||||
|
compatible = "usb-nop-xceiv";
|
||||||
|
clock-frequency = <19200000>;
|
||||||
|
clocks = <&osc 0>;
|
||||||
|
clock-names = "main_clk";
|
||||||
|
vcc-supply = <&hsusb1_vcc_regulator>;
|
||||||
|
reset-supply = <&hsusb1_reset_regulator>;
|
||||||
|
};
|
||||||
|
|
||||||
|
hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
|
||||||
|
and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
|
||||||
|
hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
|
||||||
|
controls RESET.
|
@@ -5,6 +5,7 @@ using them to avoid name-space collisions.
|
|||||||
|
|
||||||
ad Avionic Design GmbH
|
ad Avionic Design GmbH
|
||||||
adi Analog Devices, Inc.
|
adi Analog Devices, Inc.
|
||||||
|
aeroflexgaisler Aeroflex Gaisler AB
|
||||||
ak Asahi Kasei Corp.
|
ak Asahi Kasei Corp.
|
||||||
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
|
amcc Applied Micro Circuits Corporation (APM, formally AMCC)
|
||||||
apm Applied Micro Circuits Corporation (APM)
|
apm Applied Micro Circuits Corporation (APM)
|
||||||
@@ -48,6 +49,7 @@ samsung Samsung Semiconductor
|
|||||||
sbs Smart Battery System
|
sbs Smart Battery System
|
||||||
schindler Schindler
|
schindler Schindler
|
||||||
sil Silicon Image
|
sil Silicon Image
|
||||||
|
silabs Silicon Laboratories
|
||||||
simtek
|
simtek
|
||||||
sirf SiRF Technology, Inc.
|
sirf SiRF Technology, Inc.
|
||||||
snps Synopsys, Inc.
|
snps Synopsys, Inc.
|
||||||
|
41
Documentation/devicetree/bindings/video/backlight/lp855x.txt
Normal file
41
Documentation/devicetree/bindings/video/backlight/lp855x.txt
Normal file
@@ -0,0 +1,41 @@
|
|||||||
|
lp855x bindings
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553",
|
||||||
|
"ti,lp8556", "ti,lp8557"
|
||||||
|
- reg: I2C slave address (u8)
|
||||||
|
- dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device.
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- bl-name: Backlight device name (string)
|
||||||
|
- init-brt: Initial value of backlight brightness (u8)
|
||||||
|
- pwm-period: PWM period value. Set only PWM input mode used (u32)
|
||||||
|
- rom-addr: Register address of ROM area to be updated (u8)
|
||||||
|
- rom-val: Register value to be updated (u8)
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
/* LP8556 */
|
||||||
|
backlight@2c {
|
||||||
|
compatible = "ti,lp8556";
|
||||||
|
reg = <0x2c>;
|
||||||
|
|
||||||
|
bl-name = "lcd-bl";
|
||||||
|
dev-ctrl = /bits/ 8 <0x85>;
|
||||||
|
init-brt = /bits/ 8 <0x10>;
|
||||||
|
};
|
||||||
|
|
||||||
|
/* LP8557 */
|
||||||
|
backlight@2c {
|
||||||
|
compatible = "ti,lp8557";
|
||||||
|
reg = <0x2c>;
|
||||||
|
|
||||||
|
dev-ctrl = /bits/ 8 <0x41>;
|
||||||
|
init-brt = /bits/ 8 <0x0a>;
|
||||||
|
|
||||||
|
/* 4V OV, 4 output LED string enabled */
|
||||||
|
rom_14h {
|
||||||
|
rom-addr = /bits/ 8 <0x14>;
|
||||||
|
rom-val = /bits/ 8 <0xcf>;
|
||||||
|
};
|
||||||
|
};
|
@@ -0,0 +1,27 @@
|
|||||||
|
TPS65217 family of regulators
|
||||||
|
|
||||||
|
The TPS65217 chip contains a boost converter and current sinks which can be
|
||||||
|
used to drive LEDs for use as backlights.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible: "ti,tps65217"
|
||||||
|
- reg: I2C slave address
|
||||||
|
- backlight: node for specifying WLED1 and WLED2 lines in TPS65217
|
||||||
|
- isel: selection bit, valid values: 1 for ISEL1 (low-level) and 2 for ISEL2 (high-level)
|
||||||
|
- fdim: PWM dimming frequency, valid values: 100, 200, 500, 1000
|
||||||
|
- default-brightness: valid values: 0-100
|
||||||
|
|
||||||
|
Each regulator is defined using the standard binding for regulators.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
tps: tps@24 {
|
||||||
|
reg = <0x24>;
|
||||||
|
compatible = "ti,tps65217";
|
||||||
|
backlight {
|
||||||
|
isel = <1>; /* 1 - ISET1, 2 ISET2 */
|
||||||
|
fdim = <100>; /* TPS65217_BL_FDIM_100HZ */
|
||||||
|
default-brightness = <50>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
@@ -5,58 +5,32 @@ Required properties:
|
|||||||
- compatible : "via,vt8500-fb"
|
- compatible : "via,vt8500-fb"
|
||||||
- reg : Should contain 1 register ranges(address and length)
|
- reg : Should contain 1 register ranges(address and length)
|
||||||
- interrupts : framebuffer controller interrupt
|
- interrupts : framebuffer controller interrupt
|
||||||
- display: a phandle pointing to the display node
|
- bits-per-pixel : bit depth of framebuffer (16 or 32)
|
||||||
|
|
||||||
Required nodes:
|
Required subnodes:
|
||||||
- display: a display node is required to initialize the lcd panel
|
- display-timings: see display-timing.txt for information
|
||||||
This should be in the board dts.
|
|
||||||
- default-mode: a videomode within the display with timing parameters
|
|
||||||
as specified below.
|
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
fb@d800e400 {
|
fb@d8050800 {
|
||||||
compatible = "via,vt8500-fb";
|
compatible = "via,vt8500-fb";
|
||||||
reg = <0xd800e400 0x400>;
|
reg = <0xd800e400 0x400>;
|
||||||
interrupts = <12>;
|
interrupts = <12>;
|
||||||
display = <&display>;
|
bits-per-pixel = <16>;
|
||||||
default-mode = <&mode0>;
|
|
||||||
};
|
|
||||||
|
|
||||||
VIA VT8500 Display
|
display-timings {
|
||||||
-----------------------------------------------------
|
native-mode = <&timing0>;
|
||||||
Required properties (as per of_videomode_helper):
|
timing0: 800x480 {
|
||||||
|
clock-frequency = <0>; /* unused but required */
|
||||||
- hactive, vactive: Display resolution
|
|
||||||
- hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
|
|
||||||
in pixels
|
|
||||||
vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
|
|
||||||
lines
|
|
||||||
- clock: displayclock in Hz
|
|
||||||
- bpp: lcd panel bit-depth.
|
|
||||||
<16> for RGB565, <32> for RGB888
|
|
||||||
|
|
||||||
Optional properties (as per of_videomode_helper):
|
|
||||||
- width-mm, height-mm: Display dimensions in mm
|
|
||||||
- hsync-active-high (bool): Hsync pulse is active high
|
|
||||||
- vsync-active-high (bool): Vsync pulse is active high
|
|
||||||
- interlaced (bool): This is an interlaced mode
|
|
||||||
- doublescan (bool): This is a doublescan mode
|
|
||||||
|
|
||||||
Example:
|
|
||||||
display: display@0 {
|
|
||||||
modes {
|
|
||||||
mode0: mode@0 {
|
|
||||||
hactive = <800>;
|
hactive = <800>;
|
||||||
vactive = <480>;
|
vactive = <480>;
|
||||||
hback-porch = <88>;
|
|
||||||
hfront-porch = <40>;
|
hfront-porch = <40>;
|
||||||
|
hback-porch = <88>;
|
||||||
hsync-len = <0>;
|
hsync-len = <0>;
|
||||||
vback-porch = <32>;
|
vback-porch = <32>;
|
||||||
vfront-porch = <11>;
|
vfront-porch = <11>;
|
||||||
vsync-len = <1>;
|
vsync-len = <1>;
|
||||||
clock = <0>; /* unused but required */
|
|
||||||
bpp = <16>; /* non-standard but required */
|
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
|
@@ -4,20 +4,30 @@ Wondermedia WM8505 Framebuffer
|
|||||||
Required properties:
|
Required properties:
|
||||||
- compatible : "wm,wm8505-fb"
|
- compatible : "wm,wm8505-fb"
|
||||||
- reg : Should contain 1 register ranges(address and length)
|
- reg : Should contain 1 register ranges(address and length)
|
||||||
- via,display: a phandle pointing to the display node
|
- bits-per-pixel : bit depth of framebuffer (16 or 32)
|
||||||
|
|
||||||
Required nodes:
|
Required subnodes:
|
||||||
- display: a display node is required to initialize the lcd panel
|
- display-timings: see display-timing.txt for information
|
||||||
This should be in the board dts. See definition in
|
|
||||||
Documentation/devicetree/bindings/video/via,vt8500-fb.txt
|
|
||||||
- default-mode: a videomode node as specified in
|
|
||||||
Documentation/devicetree/bindings/video/via,vt8500-fb.txt
|
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
||||||
fb@d8050800 {
|
fb@d8051700 {
|
||||||
compatible = "wm,wm8505-fb";
|
compatible = "wm,wm8505-fb";
|
||||||
reg = <0xd8050800 0x200>;
|
reg = <0xd8051700 0x200>;
|
||||||
display = <&display>;
|
bits-per-pixel = <16>;
|
||||||
default-mode = <&mode0>;
|
|
||||||
|
display-timings {
|
||||||
|
native-mode = <&timing0>;
|
||||||
|
timing0: 800x480 {
|
||||||
|
clock-frequency = <0>; /* unused but required */
|
||||||
|
hactive = <800>;
|
||||||
|
vactive = <480>;
|
||||||
|
hfront-porch = <40>;
|
||||||
|
hback-porch = <88>;
|
||||||
|
hsync-len = <0>;
|
||||||
|
vback-porch = <32>;
|
||||||
|
vfront-porch = <11>;
|
||||||
|
vsync-len = <1>;
|
||||||
|
};
|
||||||
|
};
|
||||||
};
|
};
|
||||||
|
@@ -150,12 +150,28 @@ discard -- If set, issues discard/TRIM commands to the block
|
|||||||
device when blocks are freed. This is useful for SSD devices
|
device when blocks are freed. This is useful for SSD devices
|
||||||
and sparse/thinly-provisoned LUNs.
|
and sparse/thinly-provisoned LUNs.
|
||||||
|
|
||||||
nfs -- This option maintains an index (cache) of directory
|
nfs=stale_rw|nostale_ro
|
||||||
inodes by i_logstart which is used by the nfs-related code to
|
|
||||||
improve look-ups.
|
|
||||||
|
|
||||||
Enable this only if you want to export the FAT filesystem
|
Enable this only if you want to export the FAT filesystem
|
||||||
over NFS
|
over NFS.
|
||||||
|
|
||||||
|
stale_rw: This option maintains an index (cache) of directory
|
||||||
|
inodes by i_logstart which is used by the nfs-related code to
|
||||||
|
improve look-ups. Full file operations (read/write) over NFS is
|
||||||
|
supported but with cache eviction at NFS server, this could
|
||||||
|
result in ESTALE issues.
|
||||||
|
|
||||||
|
nostale_ro: This option bases the inode number and filehandle
|
||||||
|
on the on-disk location of a file in the MS-DOS directory entry.
|
||||||
|
This ensures that ESTALE will not be returned after a file is
|
||||||
|
evicted from the inode cache. However, it means that operations
|
||||||
|
such as rename, create and unlink could cause filehandles that
|
||||||
|
previously pointed at one file to point at a different file,
|
||||||
|
potentially causing data corruption. For this reason, this
|
||||||
|
option also mounts the filesystem readonly.
|
||||||
|
|
||||||
|
To maintain backward compatibility, '-o nfs' is also accepted,
|
||||||
|
defaulting to stale_rw
|
||||||
|
|
||||||
|
|
||||||
<bool>: 0,1,yes,no,true,false
|
<bool>: 0,1,yes,no,true,false
|
||||||
|
|
||||||
|
@@ -15,7 +15,7 @@ Supported chips:
|
|||||||
Addresses scanned: -
|
Addresses scanned: -
|
||||||
Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1276.pdf
|
Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1276.pdf
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
@@ -4,28 +4,50 @@ Kernel driver adt7410
|
|||||||
Supported chips:
|
Supported chips:
|
||||||
* Analog Devices ADT7410
|
* Analog Devices ADT7410
|
||||||
Prefix: 'adt7410'
|
Prefix: 'adt7410'
|
||||||
Addresses scanned: I2C 0x48 - 0x4B
|
Addresses scanned: None
|
||||||
Datasheet: Publicly available at the Analog Devices website
|
Datasheet: Publicly available at the Analog Devices website
|
||||||
http://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf
|
http://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf
|
||||||
|
* Analog Devices ADT7420
|
||||||
|
Prefix: 'adt7420'
|
||||||
|
Addresses scanned: None
|
||||||
|
Datasheet: Publicly available at the Analog Devices website
|
||||||
|
http://www.analog.com/static/imported-files/data_sheets/ADT7420.pdf
|
||||||
|
* Analog Devices ADT7310
|
||||||
|
Prefix: 'adt7310'
|
||||||
|
Addresses scanned: None
|
||||||
|
Datasheet: Publicly available at the Analog Devices website
|
||||||
|
http://www.analog.com/static/imported-files/data_sheets/ADT7310.pdf
|
||||||
|
* Analog Devices ADT7320
|
||||||
|
Prefix: 'adt7320'
|
||||||
|
Addresses scanned: None
|
||||||
|
Datasheet: Publicly available at the Analog Devices website
|
||||||
|
http://www.analog.com/static/imported-files/data_sheets/ADT7320.pdf
|
||||||
|
|
||||||
Author: Hartmut Knaack <knaack.h@gmx.de>
|
Author: Hartmut Knaack <knaack.h@gmx.de>
|
||||||
|
|
||||||
Description
|
Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
The ADT7410 is a temperature sensor with rated temperature range of -55°C to
|
The ADT7310/ADT7410 is a temperature sensor with rated temperature range of
|
||||||
+150°C. It has a high accuracy of +/-0.5°C and can be operated at a resolution
|
-55°C to +150°C. It has a high accuracy of +/-0.5°C and can be operated at a
|
||||||
of 13 bits (0.0625°C) or 16 bits (0.0078°C). The sensor provides an INT pin to
|
resolution of 13 bits (0.0625°C) or 16 bits (0.0078°C). The sensor provides an
|
||||||
indicate that a minimum or maximum temperature set point has been exceeded, as
|
INT pin to indicate that a minimum or maximum temperature set point has been
|
||||||
well as a critical temperature (CT) pin to indicate that the critical
|
exceeded, as well as a critical temperature (CT) pin to indicate that the
|
||||||
temperature set point has been exceeded. Both pins can be set up with a common
|
critical temperature set point has been exceeded. Both pins can be set up with a
|
||||||
hysteresis of 0°C - 15°C and a fault queue, ranging from 1 to 4 events. Both
|
common hysteresis of 0°C - 15°C and a fault queue, ranging from 1 to 4 events.
|
||||||
pins can individually set to be active-low or active-high, while the whole
|
Both pins can individually set to be active-low or active-high, while the whole
|
||||||
device can either run in comparator mode or interrupt mode. The ADT7410
|
device can either run in comparator mode or interrupt mode. The ADT7410 supports
|
||||||
supports continous temperature sampling, as well as sampling one temperature
|
continuous temperature sampling, as well as sampling one temperature value per
|
||||||
value per second or even justget one sample on demand for power saving.
|
second or even just get one sample on demand for power saving. Besides, it can
|
||||||
Besides, it can completely power down its ADC, if power management is
|
completely power down its ADC, if power management is required.
|
||||||
required.
|
|
||||||
|
The ADT7320/ADT7420 is register compatible, the only differences being the
|
||||||
|
package, a slightly narrower operating temperature range (-40°C to +150°C), and
|
||||||
|
a better accuracy (0.25°C instead of 0.50°C.)
|
||||||
|
|
||||||
|
The difference between the ADT7310/ADT7320 and ADT7410/ADT7420 is the control
|
||||||
|
interface, the ADT7310 and ADT7320 use SPI while the ADT7410 and ADT7420 use
|
||||||
|
I2C.
|
||||||
|
|
||||||
Configuration Notes
|
Configuration Notes
|
||||||
-------------------
|
-------------------
|
||||||
|
@@ -49,7 +49,7 @@ Supported chips:
|
|||||||
Addresses scanned: I2C 0x18 - 0x1f
|
Addresses scanned: I2C 0x18 - 0x1f
|
||||||
|
|
||||||
Author:
|
Author:
|
||||||
Guenter Roeck <guenter.roeck@ericsson.com>
|
Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
@@ -8,7 +8,7 @@ Supported devices:
|
|||||||
Documentation:
|
Documentation:
|
||||||
http://www.lineagepower.com/oem/pdf/CPLI2C.pdf
|
http://www.lineagepower.com/oem/pdf/CPLI2C.pdf
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
@@ -1,7 +1,13 @@
|
|||||||
Kernel driver max8688
|
Kernel driver lm25066
|
||||||
=====================
|
=====================
|
||||||
|
|
||||||
Supported chips:
|
Supported chips:
|
||||||
|
* TI LM25056
|
||||||
|
Prefix: 'lm25056'
|
||||||
|
Addresses scanned: -
|
||||||
|
Datasheets:
|
||||||
|
http://www.ti.com/lit/gpn/lm25056
|
||||||
|
http://www.ti.com/lit/gpn/lm25056a
|
||||||
* National Semiconductor LM25066
|
* National Semiconductor LM25066
|
||||||
Prefix: 'lm25066'
|
Prefix: 'lm25066'
|
||||||
Addresses scanned: -
|
Addresses scanned: -
|
||||||
@@ -19,14 +25,15 @@ Supported chips:
|
|||||||
Datasheet:
|
Datasheet:
|
||||||
http://www.national.com/pf/LM/LM5066.html
|
http://www.national.com/pf/LM/LM5066.html
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This driver supports hardware montoring for National Semiconductor LM25066,
|
This driver supports hardware montoring for National Semiconductor / TI LM25056,
|
||||||
LM5064, and LM5064 Power Management, Monitoring, Control, and Protection ICs.
|
LM25066, LM5064, and LM5064 Power Management, Monitoring, Control, and
|
||||||
|
Protection ICs.
|
||||||
|
|
||||||
The driver is a client driver to the core PMBus driver. Please see
|
The driver is a client driver to the core PMBus driver. Please see
|
||||||
Documentation/hwmon/pmbus for details on PMBus client drivers.
|
Documentation/hwmon/pmbus for details on PMBus client drivers.
|
||||||
@@ -60,14 +67,19 @@ in1_max Maximum input voltage.
|
|||||||
in1_min_alarm Input voltage low alarm.
|
in1_min_alarm Input voltage low alarm.
|
||||||
in1_max_alarm Input voltage high alarm.
|
in1_max_alarm Input voltage high alarm.
|
||||||
|
|
||||||
in2_label "vout1"
|
in2_label "vmon"
|
||||||
in2_input Measured output voltage.
|
in2_input Measured voltage on VAUX pin
|
||||||
in2_average Average measured output voltage.
|
in2_min Minimum VAUX voltage (LM25056 only).
|
||||||
in2_min Minimum output voltage.
|
in2_max Maximum VAUX voltage (LM25056 only).
|
||||||
in2_min_alarm Output voltage low alarm.
|
in2_min_alarm VAUX voltage low alarm (LM25056 only).
|
||||||
|
in2_max_alarm VAUX voltage high alarm (LM25056 only).
|
||||||
|
|
||||||
in3_label "vout2"
|
in3_label "vout1"
|
||||||
in3_input Measured voltage on vaux pin
|
Not supported on LM25056.
|
||||||
|
in3_input Measured output voltage.
|
||||||
|
in3_average Average measured output voltage.
|
||||||
|
in3_min Minimum output voltage.
|
||||||
|
in3_min_alarm Output voltage low alarm.
|
||||||
|
|
||||||
curr1_label "iin"
|
curr1_label "iin"
|
||||||
curr1_input Measured input current.
|
curr1_input Measured input current.
|
||||||
|
@@ -23,7 +23,7 @@ Supported chips:
|
|||||||
Datasheet: Publicly available at the Maxim website
|
Datasheet: Publicly available at the Maxim website
|
||||||
http://www.maxim-ic.com/
|
http://www.maxim-ic.com/
|
||||||
* Microchip (TelCom) TCN75
|
* Microchip (TelCom) TCN75
|
||||||
Prefix: 'lm75'
|
Prefix: 'tcn75'
|
||||||
Addresses scanned: none
|
Addresses scanned: none
|
||||||
Datasheet: Publicly available at the Microchip website
|
Datasheet: Publicly available at the Microchip website
|
||||||
http://www.microchip.com/
|
http://www.microchip.com/
|
||||||
|
36
Documentation/hwmon/lm95234
Normal file
36
Documentation/hwmon/lm95234
Normal file
@@ -0,0 +1,36 @@
|
|||||||
|
Kernel driver lm95234
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
* National Semiconductor / Texas Instruments LM95234
|
||||||
|
Addresses scanned: I2C 0x18, 0x4d, 0x4e
|
||||||
|
Datasheet: Publicly available at the Texas Instruments website
|
||||||
|
http://www.ti.com/product/lm95234
|
||||||
|
|
||||||
|
|
||||||
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
LM95234 is an 11-bit digital temperature sensor with a 2-wire System Management
|
||||||
|
Bus (SMBus) interface and TrueTherm technology that can very accurately monitor
|
||||||
|
the temperature of four remote diodes as well as its own temperature.
|
||||||
|
The four remote diodes can be external devices such as microprocessors,
|
||||||
|
graphics processors or diode-connected 2N3904s. The LM95234's TruTherm
|
||||||
|
beta compensation technology allows sensing of 90 nm or 65 nm process
|
||||||
|
thermal diodes accurately.
|
||||||
|
|
||||||
|
All temperature values are given in millidegrees Celsius. Temperature
|
||||||
|
is provided within a range of -127 to +255 degrees (+127.875 degrees for
|
||||||
|
the internal sensor). Resolution depends on temperature input and range.
|
||||||
|
|
||||||
|
Each sensor has its own maximum limit, but the hysteresis is common to all
|
||||||
|
channels. The hysteresis is configurable with the tem1_max_hyst attribute and
|
||||||
|
affects the hysteresis on all channels. The first two external sensors also
|
||||||
|
have a critical limit.
|
||||||
|
|
||||||
|
The lm95234 driver can change its update interval to a fixed set of values.
|
||||||
|
It will round up to the next selectable interval. See the datasheet for exact
|
||||||
|
values. Reading sensor values more often will do no harm, but will return
|
||||||
|
'old' values.
|
@@ -2,24 +2,32 @@ Kernel driver ltc2978
|
|||||||
=====================
|
=====================
|
||||||
|
|
||||||
Supported chips:
|
Supported chips:
|
||||||
|
* Linear Technology LTC2974
|
||||||
|
Prefix: 'ltc2974'
|
||||||
|
Addresses scanned: -
|
||||||
|
Datasheet: http://www.linear.com/product/ltc2974
|
||||||
* Linear Technology LTC2978
|
* Linear Technology LTC2978
|
||||||
Prefix: 'ltc2978'
|
Prefix: 'ltc2978'
|
||||||
Addresses scanned: -
|
Addresses scanned: -
|
||||||
Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
|
Datasheet: http://www.linear.com/product/ltc2978
|
||||||
* Linear Technology LTC3880
|
* Linear Technology LTC3880
|
||||||
Prefix: 'ltc3880'
|
Prefix: 'ltc3880'
|
||||||
Addresses scanned: -
|
Addresses scanned: -
|
||||||
Datasheet: http://cds.linear.com/docs/Datasheet/3880f.pdf
|
Datasheet: http://www.linear.com/product/ltc3880
|
||||||
|
* Linear Technology LTC3883
|
||||||
|
Prefix: 'ltc3883'
|
||||||
|
Addresses scanned: -
|
||||||
|
Datasheet: http://www.linear.com/product/ltc3883
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
The LTC2978 is an octal power supply monitor, supervisor, sequencer and
|
LTC2974 is a quad digital power supply manager. LTC2978 is an octal power supply
|
||||||
margin controller. The LTC3880 is a dual, PolyPhase DC/DC synchronous
|
monitor. LTC3880 is a dual output poly-phase step-down DC/DC controller. LTC3883
|
||||||
step-down switching regulator controller.
|
is a single phase step-down DC/DC controller.
|
||||||
|
|
||||||
|
|
||||||
Usage Notes
|
Usage Notes
|
||||||
@@ -41,63 +49,90 @@ Sysfs attributes
|
|||||||
in1_label "vin"
|
in1_label "vin"
|
||||||
in1_input Measured input voltage.
|
in1_input Measured input voltage.
|
||||||
in1_min Minimum input voltage.
|
in1_min Minimum input voltage.
|
||||||
in1_max Maximum input voltage.
|
in1_max Maximum input voltage. LTC2974 and LTC2978 only.
|
||||||
in1_lcrit Critical minimum input voltage.
|
in1_lcrit Critical minimum input voltage. LTC2974 and LTC2978
|
||||||
|
only.
|
||||||
in1_crit Critical maximum input voltage.
|
in1_crit Critical maximum input voltage.
|
||||||
in1_min_alarm Input voltage low alarm.
|
in1_min_alarm Input voltage low alarm.
|
||||||
in1_max_alarm Input voltage high alarm.
|
in1_max_alarm Input voltage high alarm. LTC2974 and LTC2978 only.
|
||||||
in1_lcrit_alarm Input voltage critical low alarm.
|
in1_lcrit_alarm Input voltage critical low alarm. LTC2974 and LTC2978
|
||||||
|
only.
|
||||||
in1_crit_alarm Input voltage critical high alarm.
|
in1_crit_alarm Input voltage critical high alarm.
|
||||||
in1_lowest Lowest input voltage. LTC2978 only.
|
in1_lowest Lowest input voltage. LTC2974 and LTC2978 only.
|
||||||
in1_highest Highest input voltage.
|
in1_highest Highest input voltage.
|
||||||
in1_reset_history Reset history. Writing into this attribute will reset
|
in1_reset_history Reset input voltage history.
|
||||||
history for all attributes.
|
|
||||||
|
|
||||||
in[2-9]_label "vout[1-8]". Channels 3 to 9 on LTC2978 only.
|
in[N]_label "vout[1-8]".
|
||||||
in[2-9]_input Measured output voltage.
|
LTC2974: N=2-5
|
||||||
in[2-9]_min Minimum output voltage.
|
LTC2978: N=2-9
|
||||||
in[2-9]_max Maximum output voltage.
|
LTC3880: N=2-3
|
||||||
in[2-9]_lcrit Critical minimum output voltage.
|
LTC3883: N=2
|
||||||
in[2-9]_crit Critical maximum output voltage.
|
in[N]_input Measured output voltage.
|
||||||
in[2-9]_min_alarm Output voltage low alarm.
|
in[N]_min Minimum output voltage.
|
||||||
in[2-9]_max_alarm Output voltage high alarm.
|
in[N]_max Maximum output voltage.
|
||||||
in[2-9]_lcrit_alarm Output voltage critical low alarm.
|
in[N]_lcrit Critical minimum output voltage.
|
||||||
in[2-9]_crit_alarm Output voltage critical high alarm.
|
in[N]_crit Critical maximum output voltage.
|
||||||
in[2-9]_lowest Lowest output voltage. LTC2978 only.
|
in[N]_min_alarm Output voltage low alarm.
|
||||||
in[2-9]_highest Lowest output voltage.
|
in[N]_max_alarm Output voltage high alarm.
|
||||||
in[2-9]_reset_history Reset history. Writing into this attribute will reset
|
in[N]_lcrit_alarm Output voltage critical low alarm.
|
||||||
history for all attributes.
|
in[N]_crit_alarm Output voltage critical high alarm.
|
||||||
|
in[N]_lowest Lowest output voltage. LTC2974 and LTC2978 only.
|
||||||
|
in[N]_highest Highest output voltage.
|
||||||
|
in[N]_reset_history Reset output voltage history.
|
||||||
|
|
||||||
temp[1-3]_input Measured temperature.
|
temp[N]_input Measured temperature.
|
||||||
|
On LTC2974, temp[1-4] report external temperatures,
|
||||||
|
and temp5 reports the chip temperature.
|
||||||
On LTC2978, only one temperature measurement is
|
On LTC2978, only one temperature measurement is
|
||||||
supported and reflects the internal temperature.
|
supported and reports the chip temperature.
|
||||||
On LTC3880, temp1 and temp2 report external
|
On LTC3880, temp1 and temp2 report external
|
||||||
temperatures, and temp3 reports the internal
|
temperatures, and temp3 reports the chip temperature.
|
||||||
temperature.
|
On LTC3883, temp1 reports an external temperature,
|
||||||
temp[1-3]_min Mimimum temperature.
|
and temp2 reports the chip temperature.
|
||||||
temp[1-3]_max Maximum temperature.
|
temp[N]_min Mimimum temperature. LTC2974 and LTC2978 only.
|
||||||
temp[1-3]_lcrit Critical low temperature.
|
temp[N]_max Maximum temperature.
|
||||||
temp[1-3]_crit Critical high temperature.
|
temp[N]_lcrit Critical low temperature.
|
||||||
temp[1-3]_min_alarm Chip temperature low alarm.
|
temp[N]_crit Critical high temperature.
|
||||||
temp[1-3]_max_alarm Chip temperature high alarm.
|
temp[N]_min_alarm Temperature low alarm. LTC2974 and LTC2978 only.
|
||||||
temp[1-3]_lcrit_alarm Chip temperature critical low alarm.
|
temp[N]_max_alarm Temperature high alarm.
|
||||||
temp[1-3]_crit_alarm Chip temperature critical high alarm.
|
temp[N]_lcrit_alarm Temperature critical low alarm.
|
||||||
temp[1-3]_lowest Lowest measured temperature. LTC2978 only.
|
temp[N]_crit_alarm Temperature critical high alarm.
|
||||||
temp[1-3]_highest Highest measured temperature.
|
temp[N]_lowest Lowest measured temperature. LTC2974 and LTC2978 only.
|
||||||
temp[1-3]_reset_history Reset history. Writing into this attribute will reset
|
Not supported for chip temperature sensor on LTC2974.
|
||||||
history for all attributes.
|
temp[N]_highest Highest measured temperature. Not supported for chip
|
||||||
|
temperature sensor on LTC2974.
|
||||||
|
temp[N]_reset_history Reset temperature history. Not supported for chip
|
||||||
|
temperature sensor on LTC2974.
|
||||||
|
|
||||||
power[1-2]_label "pout[1-2]". LTC3880 only.
|
power1_label "pin". LTC3883 only.
|
||||||
power[1-2]_input Measured power.
|
power1_input Measured input power.
|
||||||
|
|
||||||
curr1_label "iin". LTC3880 only.
|
power[N]_label "pout[1-4]".
|
||||||
|
LTC2974: N=1-4
|
||||||
|
LTC2978: Not supported
|
||||||
|
LTC3880: N=1-2
|
||||||
|
LTC3883: N=2
|
||||||
|
power[N]_input Measured output power.
|
||||||
|
|
||||||
|
curr1_label "iin". LTC3880 and LTC3883 only.
|
||||||
curr1_input Measured input current.
|
curr1_input Measured input current.
|
||||||
curr1_max Maximum input current.
|
curr1_max Maximum input current.
|
||||||
curr1_max_alarm Input current high alarm.
|
curr1_max_alarm Input current high alarm.
|
||||||
|
curr1_highest Highest input current. LTC3883 only.
|
||||||
|
curr1_reset_history Reset input current history. LTC3883 only.
|
||||||
|
|
||||||
curr[2-3]_label "iout[1-2]". LTC3880 only.
|
curr[N]_label "iout[1-4]".
|
||||||
curr[2-3]_input Measured input current.
|
LTC2974: N=1-4
|
||||||
curr[2-3]_max Maximum input current.
|
LTC2978: not supported
|
||||||
curr[2-3]_crit Critical input current.
|
LTC3880: N=2-3
|
||||||
curr[2-3]_max_alarm Input current high alarm.
|
LTC3883: N=2
|
||||||
curr[2-3]_crit_alarm Input current critical high alarm.
|
curr[N]_input Measured output current.
|
||||||
|
curr[N]_max Maximum output current.
|
||||||
|
curr[N]_crit Critical high output current.
|
||||||
|
curr[N]_lcrit Critical low output current. LTC2974 only.
|
||||||
|
curr[N]_max_alarm Output current high alarm.
|
||||||
|
curr[N]_crit_alarm Output current critical high alarm.
|
||||||
|
curr[N]_lcrit_alarm Output current critical low alarm. LTC2974 only.
|
||||||
|
curr[N]_lowest Lowest output current. LTC2974 only.
|
||||||
|
curr[N]_highest Highest output current.
|
||||||
|
curr[N]_reset_history Reset output current history.
|
||||||
|
@@ -8,7 +8,7 @@ Supported chips:
|
|||||||
Datasheet:
|
Datasheet:
|
||||||
http://cds.linear.com/docs/Datasheet/42612fb.pdf
|
http://cds.linear.com/docs/Datasheet/42612fb.pdf
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
@@ -7,7 +7,7 @@ Supported chips:
|
|||||||
Addresses scanned: -
|
Addresses scanned: -
|
||||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
|
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
@@ -24,7 +24,7 @@ Supported chips:
|
|||||||
http://datasheets.maxim-ic.com/en/ds/MAX16070-MAX16071.pdf
|
http://datasheets.maxim-ic.com/en/ds/MAX16070-MAX16071.pdf
|
||||||
|
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
@@ -27,7 +27,7 @@ Supported chips:
|
|||||||
Addresses scanned: -
|
Addresses scanned: -
|
||||||
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34461.pdf
|
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34461.pdf
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
@@ -7,7 +7,7 @@ Supported chips:
|
|||||||
Addresses scanned: -
|
Addresses scanned: -
|
||||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
|
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
188
Documentation/hwmon/nct6775
Normal file
188
Documentation/hwmon/nct6775
Normal file
@@ -0,0 +1,188 @@
|
|||||||
|
Note
|
||||||
|
====
|
||||||
|
|
||||||
|
This driver supersedes the NCT6775F and NCT6776F support in the W83627EHF
|
||||||
|
driver.
|
||||||
|
|
||||||
|
Kernel driver NCT6775
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
* Nuvoton NCT5572D/NCT6771F/NCT6772F/NCT6775F/W83677HG-I
|
||||||
|
Prefix: 'nct6775'
|
||||||
|
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||||
|
Datasheet: Available from Nuvoton upon request
|
||||||
|
* Nuvoton NCT5577D/NCT6776D/NCT6776F
|
||||||
|
Prefix: 'nct6776'
|
||||||
|
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||||
|
Datasheet: Available from Nuvoton upon request
|
||||||
|
* Nuvoton NCT5532D/NCT6779D
|
||||||
|
Prefix: 'nct6779'
|
||||||
|
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||||
|
Datasheet: Available from Nuvoton upon request
|
||||||
|
|
||||||
|
Authors:
|
||||||
|
Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
This driver implements support for the Nuvoton NCT6775F, NCT6776F, and NCT6779D
|
||||||
|
and compatible super I/O chips.
|
||||||
|
|
||||||
|
The chips support up to 25 temperature monitoring sources. Up to 6 of those are
|
||||||
|
direct temperature sensor inputs, the others are special sources such as PECI,
|
||||||
|
PCH, and SMBUS. Depending on the chip type, 2 to 6 of the temperature sources
|
||||||
|
can be monitored and compared against minimum, maximum, and critical
|
||||||
|
temperatures. The driver reports up to 10 of the temperatures to the user.
|
||||||
|
There are 4 to 5 fan rotation speed sensors, 8 to 15 analog voltage sensors,
|
||||||
|
one VID, alarms with beep warnings (control unimplemented), and some automatic
|
||||||
|
fan regulation strategies (plus manual fan control mode).
|
||||||
|
|
||||||
|
The temperature sensor sources on all chips are configurable. The configured
|
||||||
|
source for each of the temperature sensors is provided in tempX_label.
|
||||||
|
|
||||||
|
Temperatures are measured in degrees Celsius and measurement resolution is
|
||||||
|
either 1 degC or 0.5 degC, depending on the temperature source and
|
||||||
|
configuration. An alarm is triggered when the temperature gets higher than
|
||||||
|
the high limit; it stays on until the temperature falls below the hysteresis
|
||||||
|
value. Alarms are only supported for temp1 to temp6, depending on the chip type.
|
||||||
|
|
||||||
|
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
|
||||||
|
triggered if the rotation speed has dropped below a programmable limit. On
|
||||||
|
NCT6775F, fan readings can be divided by a programmable divider (1, 2, 4, 8,
|
||||||
|
16, 32, 64 or 128) to give the readings more range or accuracy; the other chips
|
||||||
|
do not have a fan speed divider. The driver sets the most suitable fan divisor
|
||||||
|
itself; specifically, it increases the divider value each time a fan speed
|
||||||
|
reading returns an invalid value, and it reduces it if the fan speed reading
|
||||||
|
is lower than optimal. Some fans might not be present because they share pins
|
||||||
|
with other functions.
|
||||||
|
|
||||||
|
Voltage sensors (also known as IN sensors) report their values in millivolts.
|
||||||
|
An alarm is triggered if the voltage has crossed a programmable minimum
|
||||||
|
or maximum limit.
|
||||||
|
|
||||||
|
The driver supports automatic fan control mode known as Thermal Cruise.
|
||||||
|
In this mode, the chip attempts to keep the measured temperature in a
|
||||||
|
predefined temperature range. If the temperature goes out of range, fan
|
||||||
|
is driven slower/faster to reach the predefined range again.
|
||||||
|
|
||||||
|
The mode works for fan1-fan5.
|
||||||
|
|
||||||
|
sysfs attributes
|
||||||
|
----------------
|
||||||
|
|
||||||
|
pwm[1-5] - this file stores PWM duty cycle or DC value (fan speed) in range:
|
||||||
|
0 (lowest speed) to 255 (full)
|
||||||
|
|
||||||
|
pwm[1-5]_enable - this file controls mode of fan/temperature control:
|
||||||
|
* 0 Fan control disabled (fans set to maximum speed)
|
||||||
|
* 1 Manual mode, write to pwm[0-5] any value 0-255
|
||||||
|
* 2 "Thermal Cruise" mode
|
||||||
|
* 3 "Fan Speed Cruise" mode
|
||||||
|
* 4 "Smart Fan III" mode (NCT6775F only)
|
||||||
|
* 5 "Smart Fan IV" mode
|
||||||
|
|
||||||
|
pwm[1-5]_mode - controls if output is PWM or DC level
|
||||||
|
* 0 DC output
|
||||||
|
* 1 PWM output
|
||||||
|
|
||||||
|
Common fan control attributes
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
pwm[1-5]_temp_sel Temperature source. Value is temperature sensor index.
|
||||||
|
For example, select '1' for temp1_input.
|
||||||
|
pwm[1-5]_weight_temp_sel
|
||||||
|
Secondary temperature source. Value is temperature
|
||||||
|
sensor index. For example, select '1' for temp1_input.
|
||||||
|
Set to 0 to disable secondary temperature control.
|
||||||
|
|
||||||
|
If secondary temperature functionality is enabled, it is controlled with the
|
||||||
|
following attributes.
|
||||||
|
|
||||||
|
pwm[1-5]_weight_duty_step
|
||||||
|
Duty step size.
|
||||||
|
pwm[1-5]_weight_temp_step
|
||||||
|
Temperature step size. With each step over
|
||||||
|
temp_step_base, the value of weight_duty_step is added
|
||||||
|
to the current pwm value.
|
||||||
|
pwm[1-5]_weight_temp_step_base
|
||||||
|
Temperature at which secondary temperature control kicks
|
||||||
|
in.
|
||||||
|
pwm[1-5]_weight_temp_step_tol
|
||||||
|
Temperature step tolerance.
|
||||||
|
|
||||||
|
Thermal Cruise mode (2)
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
If the temperature is in the range defined by:
|
||||||
|
|
||||||
|
pwm[1-5]_target_temp Target temperature, unit millidegree Celsius
|
||||||
|
(range 0 - 127000)
|
||||||
|
pwm[1-5]_temp_tolerance
|
||||||
|
Target temperature tolerance, unit millidegree Celsius
|
||||||
|
|
||||||
|
there are no changes to fan speed. Once the temperature leaves the interval, fan
|
||||||
|
speed increases (if temperature is higher that desired) or decreases (if
|
||||||
|
temperature is lower than desired), using the following limits and time
|
||||||
|
intervals.
|
||||||
|
|
||||||
|
pwm[1-5]_start fan pwm start value (range 1 - 255), to start fan
|
||||||
|
when the temperature is above defined range.
|
||||||
|
pwm[1-5]_floor lowest fan pwm (range 0 - 255) if temperature is below
|
||||||
|
the defined range. If set to 0, the fan is expected to
|
||||||
|
stop if the temperature is below the defined range.
|
||||||
|
pwm[1-5]_step_up_time milliseconds before fan speed is increased
|
||||||
|
pwm[1-5]_step_down_time milliseconds before fan speed is decreased
|
||||||
|
pwm[1-5]_stop_time how many milliseconds must elapse to switch
|
||||||
|
corresponding fan off (when the temperature was below
|
||||||
|
defined range).
|
||||||
|
|
||||||
|
Speed Cruise mode (3)
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
This modes tries to keep the fan speed constant.
|
||||||
|
|
||||||
|
fan[1-5]_target Target fan speed
|
||||||
|
fan[1-5]_tolerance
|
||||||
|
Target speed tolerance
|
||||||
|
|
||||||
|
|
||||||
|
Untested; use at your own risk.
|
||||||
|
|
||||||
|
Smart Fan IV mode (5)
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
This mode offers multiple slopes to control the fan speed. The slopes can be
|
||||||
|
controlled by setting the pwm and temperature attributes. When the temperature
|
||||||
|
rises, the chip will calculate the DC/PWM output based on the current slope.
|
||||||
|
There are up to seven data points depending on the chip type. Subsequent data
|
||||||
|
points should be set to higher temperatures and higher pwm values to achieve
|
||||||
|
higher fan speeds with increasing temperature. The last data point reflects
|
||||||
|
critical temperature mode, in which the fans should run at full speed.
|
||||||
|
|
||||||
|
pwm[1-5]_auto_point[1-7]_pwm
|
||||||
|
pwm value to be set if temperature reaches matching
|
||||||
|
temperature range.
|
||||||
|
pwm[1-5]_auto_point[1-7]_temp
|
||||||
|
Temperature over which the matching pwm is enabled.
|
||||||
|
pwm[1-5]_temp_tolerance
|
||||||
|
Temperature tolerance, unit millidegree Celsius
|
||||||
|
pwm[1-5]_crit_temp_tolerance
|
||||||
|
Temperature tolerance for critical temperature,
|
||||||
|
unit millidegree Celsius
|
||||||
|
|
||||||
|
pwm[1-5]_step_up_time milliseconds before fan speed is increased
|
||||||
|
pwm[1-5]_step_down_time milliseconds before fan speed is decreased
|
||||||
|
|
||||||
|
Usage Notes
|
||||||
|
-----------
|
||||||
|
|
||||||
|
On various ASUS boards with NCT6776F, it appears that CPUTIN is not really
|
||||||
|
connected to anything and floats, or that it is connected to some non-standard
|
||||||
|
temperature measurement device. As a result, the temperature reported on CPUTIN
|
||||||
|
will not reflect a usable value. It often reports unreasonably high
|
||||||
|
temperatures, and in some cases the reported temperature declines if the actual
|
||||||
|
temperature increases (similar to the raw PECI temperature value - see PECI
|
||||||
|
specification for details). CPUTIN should therefore be be ignored on ASUS
|
||||||
|
boards. The CPU temperature on ASUS boards is reported from PECI 0.
|
@@ -34,7 +34,7 @@ Supported chips:
|
|||||||
Addresses scanned: -
|
Addresses scanned: -
|
||||||
Datasheet: n.a.
|
Datasheet: n.a.
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
@@ -40,7 +40,7 @@ bits for humidity, or 12 bits for temperature and 8 bits for humidity.
|
|||||||
The humidity calibration coefficients are programmed into an OTP memory on the
|
The humidity calibration coefficients are programmed into an OTP memory on the
|
||||||
chip. These coefficients are used to internally calibrate the signals from the
|
chip. These coefficients are used to internally calibrate the signals from the
|
||||||
sensors. Disabling the reload of those coefficients allows saving 10ms for each
|
sensors. Disabling the reload of those coefficients allows saving 10ms for each
|
||||||
measurement and decrease power consumption, while loosing on precision.
|
measurement and decrease power consumption, while losing on precision.
|
||||||
|
|
||||||
Some options may be set directly in the sht15_platform_data structure
|
Some options may be set directly in the sht15_platform_data structure
|
||||||
or via sysfs attributes.
|
or via sysfs attributes.
|
||||||
|
@@ -29,7 +29,7 @@ Supported chips:
|
|||||||
http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf
|
http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf
|
||||||
http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf
|
http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Module Parameters
|
Module Parameters
|
||||||
|
@@ -8,8 +8,16 @@ Supported chips:
|
|||||||
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp401.html
|
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp401.html
|
||||||
* Texas Instruments TMP411
|
* Texas Instruments TMP411
|
||||||
Prefix: 'tmp411'
|
Prefix: 'tmp411'
|
||||||
Addresses scanned: I2C 0x4c
|
Addresses scanned: I2C 0x4c, 0x4d, 0x4e
|
||||||
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp411.html
|
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp411.html
|
||||||
|
* Texas Instruments TMP431
|
||||||
|
Prefix: 'tmp431'
|
||||||
|
Addresses scanned: I2C 0x4c, 0x4d
|
||||||
|
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp431.html
|
||||||
|
* Texas Instruments TMP432
|
||||||
|
Prefix: 'tmp432'
|
||||||
|
Addresses scanned: I2C 0x4c, 0x4d
|
||||||
|
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp432.html
|
||||||
|
|
||||||
Authors:
|
Authors:
|
||||||
Hans de Goede <hdegoede@redhat.com>
|
Hans de Goede <hdegoede@redhat.com>
|
||||||
@@ -18,19 +26,19 @@ Authors:
|
|||||||
Description
|
Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This driver implements support for Texas Instruments TMP401 and
|
This driver implements support for Texas Instruments TMP401, TMP411,
|
||||||
TMP411 chips. These chips implements one remote and one local
|
TMP431, and TMP432 chips. These chips implement one or two remote and
|
||||||
temperature sensor. Temperature is measured in degrees
|
one local temperature sensors. Temperature is measured in degrees
|
||||||
Celsius. Resolution of the remote sensor is 0.0625 degree. Local
|
Celsius. Resolution of the remote sensor is 0.0625 degree. Local
|
||||||
sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not
|
sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not
|
||||||
supported by the driver so far, so using the default resolution of 0.5
|
supported by the driver so far, so using the default resolution of 0.5
|
||||||
degree).
|
degree).
|
||||||
|
|
||||||
The driver provides the common sysfs-interface for temperatures (see
|
The driver provides the common sysfs-interface for temperatures (see
|
||||||
/Documentation/hwmon/sysfs-interface under Temperatures).
|
Documentation/hwmon/sysfs-interface under Temperatures).
|
||||||
|
|
||||||
The TMP411 chip is compatible with TMP401. It provides some additional
|
The TMP411 and TMP431 chips are compatible with TMP401. TMP411 provides
|
||||||
features.
|
some additional features.
|
||||||
|
|
||||||
* Minimum and Maximum temperature measured since power-on, chip-reset
|
* Minimum and Maximum temperature measured since power-on, chip-reset
|
||||||
|
|
||||||
@@ -40,3 +48,6 @@ features.
|
|||||||
|
|
||||||
Exported via sysfs attribute temp_reset_history. Writing 1 to this
|
Exported via sysfs attribute temp_reset_history. Writing 1 to this
|
||||||
file triggers a reset.
|
file triggers a reset.
|
||||||
|
|
||||||
|
TMP432 is compatible with TMP401 and TMP431. It supports two external
|
||||||
|
temperature sensors.
|
||||||
|
@@ -11,7 +11,7 @@ Supported chips:
|
|||||||
http://focus.ti.com/lit/ds/symlink/ucd9090.pdf
|
http://focus.ti.com/lit/ds/symlink/ucd9090.pdf
|
||||||
http://focus.ti.com/lit/ds/symlink/ucd90910.pdf
|
http://focus.ti.com/lit/ds/symlink/ucd90910.pdf
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
@@ -15,7 +15,7 @@ Supported chips:
|
|||||||
http://focus.ti.com/lit/ds/symlink/ucd9246.pdf
|
http://focus.ti.com/lit/ds/symlink/ucd9246.pdf
|
||||||
http://focus.ti.com/lit/ds/symlink/ucd9248.pdf
|
http://focus.ti.com/lit/ds/symlink/ucd9248.pdf
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
@@ -54,7 +54,7 @@ http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146401
|
|||||||
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146256
|
http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146256
|
||||||
|
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
@@ -125,7 +125,7 @@ in2_label "vmon"
|
|||||||
in2_input Measured voltage on VMON (ZL2004) or VDRV (ZL9101M,
|
in2_input Measured voltage on VMON (ZL2004) or VDRV (ZL9101M,
|
||||||
ZL9117M) pin. Reported voltage is 16x the voltage on the
|
ZL9117M) pin. Reported voltage is 16x the voltage on the
|
||||||
pin (adjusted internally by the chip).
|
pin (adjusted internally by the chip).
|
||||||
in2_lcrit Critical minumum VMON/VDRV Voltage.
|
in2_lcrit Critical minimum VMON/VDRV Voltage.
|
||||||
in2_crit Critical maximum VMON/VDRV voltage.
|
in2_crit Critical maximum VMON/VDRV voltage.
|
||||||
in2_lcrit_alarm VMON/VDRV voltage critical low alarm.
|
in2_lcrit_alarm VMON/VDRV voltage critical low alarm.
|
||||||
in2_crit_alarm VMON/VDRV voltage critical high alarm.
|
in2_crit_alarm VMON/VDRV voltage critical high alarm.
|
||||||
|
@@ -5,7 +5,7 @@ Supported adapters:
|
|||||||
Documentation:
|
Documentation:
|
||||||
http://www.diolan.com/i2c/u2c12.html
|
http://www.diolan.com/i2c/u2c12.html
|
||||||
|
|
||||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
Author: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
|
||||||
Description
|
Description
|
||||||
-----------
|
-----------
|
||||||
|
@@ -882,7 +882,7 @@ int err_inj()
|
|||||||
cpu=parameters[i].cpu;
|
cpu=parameters[i].cpu;
|
||||||
k = cpu%64;
|
k = cpu%64;
|
||||||
j = cpu/64;
|
j = cpu/64;
|
||||||
mask[j]=1<<k;
|
mask[j] = 1UL << k;
|
||||||
|
|
||||||
if (sched_setaffinity(0, MASK_SIZE*8, mask)==-1) {
|
if (sched_setaffinity(0, MASK_SIZE*8, mask)==-1) {
|
||||||
perror("Error sched_setaffinity:");
|
perror("Error sched_setaffinity:");
|
||||||
|
@@ -3,10 +3,26 @@ ALPS Touchpad Protocol
|
|||||||
|
|
||||||
Introduction
|
Introduction
|
||||||
------------
|
------------
|
||||||
|
Currently the ALPS touchpad driver supports five protocol versions in use by
|
||||||
|
ALPS touchpads, called versions 1, 2, 3, 4 and 5.
|
||||||
|
|
||||||
Currently the ALPS touchpad driver supports four protocol versions in use by
|
Since roughly mid-2010 several new ALPS touchpads have been released and
|
||||||
ALPS touchpads, called versions 1, 2, 3, and 4. Information about the various
|
integrated into a variety of laptops and netbooks. These new touchpads
|
||||||
protocol versions is contained in the following sections.
|
have enough behavior differences that the alps_model_data definition
|
||||||
|
table, describing the properties of the different versions, is no longer
|
||||||
|
adequate. The design choices were to re-define the alps_model_data
|
||||||
|
table, with the risk of regression testing existing devices, or isolate
|
||||||
|
the new devices outside of the alps_model_data table. The latter design
|
||||||
|
choice was made. The new touchpad signatures are named: "Rushmore",
|
||||||
|
"Pinnacle", and "Dolphin", which you will see in the alps.c code.
|
||||||
|
For the purposes of this document, this group of ALPS touchpads will
|
||||||
|
generically be called "new ALPS touchpads".
|
||||||
|
|
||||||
|
We experimented with probing the ACPI interface _HID (Hardware ID)/_CID
|
||||||
|
(Compatibility ID) definition as a way to uniquely identify the
|
||||||
|
different ALPS variants but there did not appear to be a 1:1 mapping.
|
||||||
|
In fact, it appeared to be an m:n mapping between the _HID and actual
|
||||||
|
hardware type.
|
||||||
|
|
||||||
Detection
|
Detection
|
||||||
---------
|
---------
|
||||||
@@ -20,9 +36,13 @@ If the E6 report is successful, the touchpad model is identified using the "E7
|
|||||||
report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is
|
report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is
|
||||||
matched against known models in the alps_model_data_array.
|
matched against known models in the alps_model_data_array.
|
||||||
|
|
||||||
With protocol versions 3 and 4, the E7 report model signature is always
|
For older touchpads supporting protocol versions 3 and 4, the E7 report
|
||||||
73-02-64. To differentiate between these versions, the response from the
|
model signature is always 73-02-64. To differentiate between these
|
||||||
"Enter Command Mode" sequence must be inspected as described below.
|
versions, the response from the "Enter Command Mode" sequence must be
|
||||||
|
inspected as described below.
|
||||||
|
|
||||||
|
The new ALPS touchpads have an E7 signature of 73-03-50 or 73-03-0A but
|
||||||
|
seem to be better differentiated by the EC Command Mode response.
|
||||||
|
|
||||||
Command Mode
|
Command Mode
|
||||||
------------
|
------------
|
||||||
@@ -47,6 +67,14 @@ address of the register being read, and the third contains the value of the
|
|||||||
register. Registers are written by writing the value one nibble at a time
|
register. Registers are written by writing the value one nibble at a time
|
||||||
using the same encoding used for addresses.
|
using the same encoding used for addresses.
|
||||||
|
|
||||||
|
For the new ALPS touchpads, the EC command is used to enter command
|
||||||
|
mode. The response in the new ALPS touchpads is significantly different,
|
||||||
|
and more important in determining the behavior. This code has been
|
||||||
|
separated from the original alps_model_data table and put in the
|
||||||
|
alps_identify function. For example, there seem to be two hardware init
|
||||||
|
sequences for the "Dolphin" touchpads as determined by the second byte
|
||||||
|
of the EC response.
|
||||||
|
|
||||||
Packet Format
|
Packet Format
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
@@ -187,3 +215,28 @@ There are several things worth noting here.
|
|||||||
well.
|
well.
|
||||||
|
|
||||||
So far no v4 devices with tracksticks have been encountered.
|
So far no v4 devices with tracksticks have been encountered.
|
||||||
|
|
||||||
|
ALPS Absolute Mode - Protocol Version 5
|
||||||
|
---------------------------------------
|
||||||
|
This is basically Protocol Version 3 but with different logic for packet
|
||||||
|
decode. It uses the same alps_process_touchpad_packet_v3 call with a
|
||||||
|
specialized decode_fields function pointer to correctly interpret the
|
||||||
|
packets. This appears to only be used by the Dolphin devices.
|
||||||
|
|
||||||
|
For single-touch, the 6-byte packet format is:
|
||||||
|
|
||||||
|
byte 0: 1 1 0 0 1 0 0 0
|
||||||
|
byte 1: 0 x6 x5 x4 x3 x2 x1 x0
|
||||||
|
byte 2: 0 y6 y5 y4 y3 y2 y1 y0
|
||||||
|
byte 3: 0 M R L 1 m r l
|
||||||
|
byte 4: y10 y9 y8 y7 x10 x9 x8 x7
|
||||||
|
byte 5: 0 z6 z5 z4 z3 z2 z1 z0
|
||||||
|
|
||||||
|
For mt, the format is:
|
||||||
|
|
||||||
|
byte 0: 1 1 1 n3 1 n2 n1 x24
|
||||||
|
byte 1: 1 y7 y6 y5 y4 y3 y2 y1
|
||||||
|
byte 2: ? x2 x1 y12 y11 y10 y9 y8
|
||||||
|
byte 3: 0 x23 x22 x21 x20 x19 x18 x17
|
||||||
|
byte 4: 0 x9 x8 x7 x6 x5 x4 x3
|
||||||
|
byte 5: 0 x16 x15 x14 x13 x12 x11 x10
|
||||||
|
@@ -131,6 +131,7 @@ Code Seq#(hex) Include File Comments
|
|||||||
'H' 40-4F sound/hdspm.h conflict!
|
'H' 40-4F sound/hdspm.h conflict!
|
||||||
'H' 40-4F sound/hdsp.h conflict!
|
'H' 40-4F sound/hdsp.h conflict!
|
||||||
'H' 90 sound/usb/usx2y/usb_stream.h
|
'H' 90 sound/usb/usx2y/usb_stream.h
|
||||||
|
'H' A0 uapi/linux/usb/cdc-wdm.h
|
||||||
'H' C0-F0 net/bluetooth/hci.h conflict!
|
'H' C0-F0 net/bluetooth/hci.h conflict!
|
||||||
'H' C0-DF net/bluetooth/hidp/hidp.h conflict!
|
'H' C0-DF net/bluetooth/hidp/hidp.h conflict!
|
||||||
'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict!
|
'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict!
|
||||||
|
@@ -297,6 +297,7 @@ Boot into System Kernel
|
|||||||
On ia64, 256M@256M is a generous value that typically works.
|
On ia64, 256M@256M is a generous value that typically works.
|
||||||
The region may be automatically placed on ia64, see the
|
The region may be automatically placed on ia64, see the
|
||||||
dump-capture kernel config option notes above.
|
dump-capture kernel config option notes above.
|
||||||
|
If use sparse memory, the size should be rounded to GRANULE boundaries.
|
||||||
|
|
||||||
On s390x, typically use "crashkernel=xxM". The value of xx is dependent
|
On s390x, typically use "crashkernel=xxM". The value of xx is dependent
|
||||||
on the memory consumption of the kdump system. In general this is not
|
on the memory consumption of the kdump system. In general this is not
|
||||||
|
@@ -44,6 +44,7 @@ parameter is applicable:
|
|||||||
AVR32 AVR32 architecture is enabled.
|
AVR32 AVR32 architecture is enabled.
|
||||||
AX25 Appropriate AX.25 support is enabled.
|
AX25 Appropriate AX.25 support is enabled.
|
||||||
BLACKFIN Blackfin architecture is enabled.
|
BLACKFIN Blackfin architecture is enabled.
|
||||||
|
CLK Common clock infrastructure is enabled.
|
||||||
DRM Direct Rendering Management support is enabled.
|
DRM Direct Rendering Management support is enabled.
|
||||||
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
|
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
|
||||||
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
|
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
|
||||||
@@ -320,6 +321,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||||||
on: enable for both 32- and 64-bit processes
|
on: enable for both 32- and 64-bit processes
|
||||||
off: disable for both 32- and 64-bit processes
|
off: disable for both 32- and 64-bit processes
|
||||||
|
|
||||||
|
alloc_snapshot [FTRACE]
|
||||||
|
Allocate the ftrace snapshot buffer on boot up when the
|
||||||
|
main buffer is allocated. This is handy if debugging
|
||||||
|
and you need to use tracing_snapshot() on boot up, and
|
||||||
|
do not want to use tracing_snapshot_alloc() as it needs
|
||||||
|
to be done where GFP_KERNEL allocations are allowed.
|
||||||
|
|
||||||
amd_iommu= [HW,X86-64]
|
amd_iommu= [HW,X86-64]
|
||||||
Pass parameters to the AMD IOMMU driver in the system.
|
Pass parameters to the AMD IOMMU driver in the system.
|
||||||
Possible values are:
|
Possible values are:
|
||||||
@@ -465,6 +473,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||||||
|
|
||||||
cio_ignore= [S390]
|
cio_ignore= [S390]
|
||||||
See Documentation/s390/CommonIO for details.
|
See Documentation/s390/CommonIO for details.
|
||||||
|
clk_ignore_unused
|
||||||
|
[CLK]
|
||||||
|
Keep all clocks already enabled by bootloader on,
|
||||||
|
even if no driver has claimed them. This is useful
|
||||||
|
for debug and development, but should not be
|
||||||
|
needed on a platform with proper driver support.
|
||||||
|
For more information, see Documentation/clk.txt.
|
||||||
|
|
||||||
clock= [BUGS=X86-32, HW] gettimeofday clocksource override.
|
clock= [BUGS=X86-32, HW] gettimeofday clocksource override.
|
||||||
[Deprecated]
|
[Deprecated]
|
||||||
@@ -596,9 +611,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||||||
is selected automatically. Check
|
is selected automatically. Check
|
||||||
Documentation/kdump/kdump.txt for further details.
|
Documentation/kdump/kdump.txt for further details.
|
||||||
|
|
||||||
crashkernel_low=size[KMG]
|
|
||||||
[KNL, x86] parts under 4G.
|
|
||||||
|
|
||||||
crashkernel=range1:size1[,range2:size2,...][@offset]
|
crashkernel=range1:size1[,range2:size2,...][@offset]
|
||||||
[KNL] Same as above, but depends on the memory
|
[KNL] Same as above, but depends on the memory
|
||||||
in the running system. The syntax of range is
|
in the running system. The syntax of range is
|
||||||
@@ -606,6 +618,26 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||||||
a memory unit (amount[KMG]). See also
|
a memory unit (amount[KMG]). See also
|
||||||
Documentation/kdump/kdump.txt for an example.
|
Documentation/kdump/kdump.txt for an example.
|
||||||
|
|
||||||
|
crashkernel=size[KMG],high
|
||||||
|
[KNL, x86_64] range could be above 4G. Allow kernel
|
||||||
|
to allocate physical memory region from top, so could
|
||||||
|
be above 4G if system have more than 4G ram installed.
|
||||||
|
Otherwise memory region will be allocated below 4G, if
|
||||||
|
available.
|
||||||
|
It will be ignored if crashkernel=X is specified.
|
||||||
|
crashkernel=size[KMG],low
|
||||||
|
[KNL, x86_64] range under 4G. When crashkernel=X,high
|
||||||
|
is passed, kernel could allocate physical memory region
|
||||||
|
above 4G, that cause second kernel crash on system
|
||||||
|
that require some amount of low memory, e.g. swiotlb
|
||||||
|
requires at least 64M+32K low memory. Kernel would
|
||||||
|
try to allocate 72M below 4G automatically.
|
||||||
|
This one let user to specify own low range under 4G
|
||||||
|
for second kernel instead.
|
||||||
|
0: to disable low allocation.
|
||||||
|
It will be ignored when crashkernel=X,high is not used
|
||||||
|
or memory reserved is below 4G.
|
||||||
|
|
||||||
cs89x0_dma= [HW,NET]
|
cs89x0_dma= [HW,NET]
|
||||||
Format: <dma>
|
Format: <dma>
|
||||||
|
|
||||||
@@ -788,6 +820,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||||||
edd= [EDD]
|
edd= [EDD]
|
||||||
Format: {"off" | "on" | "skip[mbr]"}
|
Format: {"off" | "on" | "skip[mbr]"}
|
||||||
|
|
||||||
|
efi_no_storage_paranoia [EFI; X86]
|
||||||
|
Using this parameter you can use more than 50% of
|
||||||
|
your efi variable storage. Use this parameter only if
|
||||||
|
you are really sure that your UEFI does sane gc and
|
||||||
|
fulfills the spec otherwise your board may brick.
|
||||||
|
|
||||||
eisa_irq_edge= [PARISC,HW]
|
eisa_irq_edge= [PARISC,HW]
|
||||||
See header of drivers/parisc/eisa.c.
|
See header of drivers/parisc/eisa.c.
|
||||||
|
|
||||||
@@ -2469,9 +2507,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||||||
In kernels built with CONFIG_RCU_NOCB_CPU=y, set
|
In kernels built with CONFIG_RCU_NOCB_CPU=y, set
|
||||||
the specified list of CPUs to be no-callback CPUs.
|
the specified list of CPUs to be no-callback CPUs.
|
||||||
Invocation of these CPUs' RCU callbacks will
|
Invocation of these CPUs' RCU callbacks will
|
||||||
be offloaded to "rcuoN" kthreads created for
|
be offloaded to "rcuox/N" kthreads created for
|
||||||
that purpose. This reduces OS jitter on the
|
that purpose, where "x" is "b" for RCU-bh, "p"
|
||||||
|
for RCU-preempt, and "s" for RCU-sched, and "N"
|
||||||
|
is the CPU number. This reduces OS jitter on the
|
||||||
offloaded CPUs, which can be useful for HPC and
|
offloaded CPUs, which can be useful for HPC and
|
||||||
|
|
||||||
real-time workloads. It can also improve energy
|
real-time workloads. It can also improve energy
|
||||||
efficiency for asymmetric multiprocessors.
|
efficiency for asymmetric multiprocessors.
|
||||||
|
|
||||||
@@ -2495,6 +2536,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||||||
leaf rcu_node structure. Useful for very large
|
leaf rcu_node structure. Useful for very large
|
||||||
systems.
|
systems.
|
||||||
|
|
||||||
|
rcutree.jiffies_till_first_fqs= [KNL,BOOT]
|
||||||
|
Set delay from grace-period initialization to
|
||||||
|
first attempt to force quiescent states.
|
||||||
|
Units are jiffies, minimum value is zero,
|
||||||
|
and maximum value is HZ.
|
||||||
|
|
||||||
|
rcutree.jiffies_till_next_fqs= [KNL,BOOT]
|
||||||
|
Set delay between subsequent attempts to force
|
||||||
|
quiescent states. Units are jiffies, minimum
|
||||||
|
value is one, and maximum value is HZ.
|
||||||
|
|
||||||
rcutree.qhimark= [KNL,BOOT]
|
rcutree.qhimark= [KNL,BOOT]
|
||||||
Set threshold of queued
|
Set threshold of queued
|
||||||
RCU callbacks over which batch limiting is disabled.
|
RCU callbacks over which batch limiting is disabled.
|
||||||
@@ -2509,16 +2561,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||||||
rcutree.rcu_cpu_stall_timeout= [KNL,BOOT]
|
rcutree.rcu_cpu_stall_timeout= [KNL,BOOT]
|
||||||
Set timeout for RCU CPU stall warning messages.
|
Set timeout for RCU CPU stall warning messages.
|
||||||
|
|
||||||
rcutree.jiffies_till_first_fqs= [KNL,BOOT]
|
rcutree.rcu_idle_gp_delay= [KNL,BOOT]
|
||||||
Set delay from grace-period initialization to
|
Set wakeup interval for idle CPUs that have
|
||||||
first attempt to force quiescent states.
|
RCU callbacks (RCU_FAST_NO_HZ=y).
|
||||||
Units are jiffies, minimum value is zero,
|
|
||||||
and maximum value is HZ.
|
|
||||||
|
|
||||||
rcutree.jiffies_till_next_fqs= [KNL,BOOT]
|
rcutree.rcu_idle_lazy_gp_delay= [KNL,BOOT]
|
||||||
Set delay between subsequent attempts to force
|
Set wakeup interval for idle CPUs that have
|
||||||
quiescent states. Units are jiffies, minimum
|
only "lazy" RCU callbacks (RCU_FAST_NO_HZ=y).
|
||||||
value is one, and maximum value is HZ.
|
Lazy RCU callbacks are those which RCU can
|
||||||
|
prove do nothing more than free memory.
|
||||||
|
|
||||||
rcutorture.fqs_duration= [KNL,BOOT]
|
rcutorture.fqs_duration= [KNL,BOOT]
|
||||||
Set duration of force_quiescent_state bursts.
|
Set duration of force_quiescent_state bursts.
|
||||||
@@ -3230,6 +3281,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||||||
or other driver-specific files in the
|
or other driver-specific files in the
|
||||||
Documentation/watchdog/ directory.
|
Documentation/watchdog/ directory.
|
||||||
|
|
||||||
|
workqueue.disable_numa
|
||||||
|
By default, all work items queued to unbound
|
||||||
|
workqueues are affine to the NUMA nodes they're
|
||||||
|
issued on, which results in better behavior in
|
||||||
|
general. If NUMA affinity needs to be disabled for
|
||||||
|
whatever reason, this option can be used. Note
|
||||||
|
that this also can be controlled per-workqueue for
|
||||||
|
workqueues visible under /sys/bus/workqueue/.
|
||||||
|
|
||||||
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
|
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
|
||||||
default x2apic cluster mode on platforms
|
default x2apic cluster mode on platforms
|
||||||
supporting x2apic.
|
supporting x2apic.
|
||||||
|
138
Documentation/misc-devices/mei/mei-client-bus.txt
Normal file
138
Documentation/misc-devices/mei/mei-client-bus.txt
Normal file
@@ -0,0 +1,138 @@
|
|||||||
|
Intel(R) Management Engine (ME) Client bus API
|
||||||
|
===============================================
|
||||||
|
|
||||||
|
|
||||||
|
Rationale
|
||||||
|
=========
|
||||||
|
MEI misc character device is useful for dedicated applications to send and receive
|
||||||
|
data to the many FW appliance found in Intel's ME from the user space.
|
||||||
|
However for some of the ME functionalities it make sense to leverage existing software
|
||||||
|
stack and expose them through existing kernel subsystems.
|
||||||
|
|
||||||
|
In order to plug seamlessly into the kernel device driver model we add kernel virtual
|
||||||
|
bus abstraction on top of the MEI driver. This allows implementing linux kernel drivers
|
||||||
|
for the various MEI features as a stand alone entities found in their respective subsystem.
|
||||||
|
Existing device drivers can even potentially be re-used by adding an MEI CL bus layer to
|
||||||
|
the existing code.
|
||||||
|
|
||||||
|
|
||||||
|
MEI CL bus API
|
||||||
|
===========
|
||||||
|
A driver implementation for an MEI Client is very similar to existing bus
|
||||||
|
based device drivers. The driver registers itself as an MEI CL bus driver through
|
||||||
|
the mei_cl_driver structure:
|
||||||
|
|
||||||
|
struct mei_cl_driver {
|
||||||
|
struct device_driver driver;
|
||||||
|
const char *name;
|
||||||
|
|
||||||
|
const struct mei_cl_device_id *id_table;
|
||||||
|
|
||||||
|
int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id);
|
||||||
|
int (*remove)(struct mei_cl_device *dev);
|
||||||
|
};
|
||||||
|
|
||||||
|
struct mei_cl_id {
|
||||||
|
char name[MEI_NAME_SIZE];
|
||||||
|
kernel_ulong_t driver_info;
|
||||||
|
};
|
||||||
|
|
||||||
|
The mei_cl_id structure allows the driver to bind itself against a device name.
|
||||||
|
|
||||||
|
To actually register a driver on the ME Client bus one must call the mei_cl_add_driver()
|
||||||
|
API. This is typically called at module init time.
|
||||||
|
|
||||||
|
Once registered on the ME Client bus, a driver will typically try to do some I/O on
|
||||||
|
this bus and this should be done through the mei_cl_send() and mei_cl_recv()
|
||||||
|
routines. The latter is synchronous (blocks and sleeps until data shows up).
|
||||||
|
In order for drivers to be notified of pending events waiting for them (e.g.
|
||||||
|
an Rx event) they can register an event handler through the
|
||||||
|
mei_cl_register_event_cb() routine. Currently only the MEI_EVENT_RX event
|
||||||
|
will trigger an event handler call and the driver implementation is supposed
|
||||||
|
to call mei_recv() from the event handler in order to fetch the pending
|
||||||
|
received buffers.
|
||||||
|
|
||||||
|
|
||||||
|
Example
|
||||||
|
=======
|
||||||
|
As a theoretical example let's pretend the ME comes with a "contact" NFC IP.
|
||||||
|
The driver init and exit routines for this device would look like:
|
||||||
|
|
||||||
|
#define CONTACT_DRIVER_NAME "contact"
|
||||||
|
|
||||||
|
static struct mei_cl_device_id contact_mei_cl_tbl[] = {
|
||||||
|
{ CONTACT_DRIVER_NAME, },
|
||||||
|
|
||||||
|
/* required last entry */
|
||||||
|
{ }
|
||||||
|
};
|
||||||
|
MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl);
|
||||||
|
|
||||||
|
static struct mei_cl_driver contact_driver = {
|
||||||
|
.id_table = contact_mei_tbl,
|
||||||
|
.name = CONTACT_DRIVER_NAME,
|
||||||
|
|
||||||
|
.probe = contact_probe,
|
||||||
|
.remove = contact_remove,
|
||||||
|
};
|
||||||
|
|
||||||
|
static int contact_init(void)
|
||||||
|
{
|
||||||
|
int r;
|
||||||
|
|
||||||
|
r = mei_cl_driver_register(&contact_driver);
|
||||||
|
if (r) {
|
||||||
|
pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n");
|
||||||
|
return r;
|
||||||
|
}
|
||||||
|
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
static void __exit contact_exit(void)
|
||||||
|
{
|
||||||
|
mei_cl_driver_unregister(&contact_driver);
|
||||||
|
}
|
||||||
|
|
||||||
|
module_init(contact_init);
|
||||||
|
module_exit(contact_exit);
|
||||||
|
|
||||||
|
And the driver's simplified probe routine would look like that:
|
||||||
|
|
||||||
|
int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id)
|
||||||
|
{
|
||||||
|
struct contact_driver *contact;
|
||||||
|
|
||||||
|
[...]
|
||||||
|
mei_cl_enable_device(dev);
|
||||||
|
|
||||||
|
mei_cl_register_event_cb(dev, contact_event_cb, contact);
|
||||||
|
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
|
||||||
|
In the probe routine the driver first enable the MEI device and then registers
|
||||||
|
an ME bus event handler which is as close as it can get to registering a
|
||||||
|
threaded IRQ handler.
|
||||||
|
The handler implementation will typically call some I/O routine depending on
|
||||||
|
the pending events:
|
||||||
|
|
||||||
|
#define MAX_NFC_PAYLOAD 128
|
||||||
|
|
||||||
|
static void contact_event_cb(struct mei_cl_device *dev, u32 events,
|
||||||
|
void *context)
|
||||||
|
{
|
||||||
|
struct contact_driver *contact = context;
|
||||||
|
|
||||||
|
if (events & BIT(MEI_EVENT_RX)) {
|
||||||
|
u8 payload[MAX_NFC_PAYLOAD];
|
||||||
|
int payload_size;
|
||||||
|
|
||||||
|
payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD);
|
||||||
|
if (payload_size <= 0)
|
||||||
|
return;
|
||||||
|
|
||||||
|
/* Hook to the NFC subsystem */
|
||||||
|
nfc_hci_recv_frame(contact->hdev, payload, payload_size);
|
||||||
|
}
|
||||||
|
}
|
@@ -15,6 +15,13 @@ amemthresh - INTEGER
|
|||||||
enabled and the variable is automatically set to 2, otherwise
|
enabled and the variable is automatically set to 2, otherwise
|
||||||
the strategy is disabled and the variable is set to 1.
|
the strategy is disabled and the variable is set to 1.
|
||||||
|
|
||||||
|
backup_only - BOOLEAN
|
||||||
|
0 - disabled (default)
|
||||||
|
not 0 - enabled
|
||||||
|
|
||||||
|
If set, disable the director function while the server is
|
||||||
|
in backup mode to avoid packet loops for DR/TUN methods.
|
||||||
|
|
||||||
conntrack - BOOLEAN
|
conntrack - BOOLEAN
|
||||||
0 - disabled (default)
|
0 - disabled (default)
|
||||||
not 0 - enabled
|
not 0 - enabled
|
||||||
|
@@ -105,6 +105,83 @@ Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
|
|||||||
Proto [2 bytes]
|
Proto [2 bytes]
|
||||||
Raw protocol(IP, IPv6, etc) frame.
|
Raw protocol(IP, IPv6, etc) frame.
|
||||||
|
|
||||||
|
3.3 Multiqueue tuntap interface:
|
||||||
|
|
||||||
|
From version 3.8, Linux supports multiqueue tuntap which can uses multiple
|
||||||
|
file descriptors (queues) to parallelize packets sending or receiving. The
|
||||||
|
device allocation is the same as before, and if user wants to create multiple
|
||||||
|
queues, TUNSETIFF with the same device name must be called many times with
|
||||||
|
IFF_MULTI_QUEUE flag.
|
||||||
|
|
||||||
|
char *dev should be the name of the device, queues is the number of queues to
|
||||||
|
be created, fds is used to store and return the file descriptors (queues)
|
||||||
|
created to the caller. Each file descriptor were served as the interface of a
|
||||||
|
queue which could be accessed by userspace.
|
||||||
|
|
||||||
|
#include <linux/if.h>
|
||||||
|
#include <linux/if_tun.h>
|
||||||
|
|
||||||
|
int tun_alloc_mq(char *dev, int queues, int *fds)
|
||||||
|
{
|
||||||
|
struct ifreq ifr;
|
||||||
|
int fd, err, i;
|
||||||
|
|
||||||
|
if (!dev)
|
||||||
|
return -1;
|
||||||
|
|
||||||
|
memset(&ifr, 0, sizeof(ifr));
|
||||||
|
/* Flags: IFF_TUN - TUN device (no Ethernet headers)
|
||||||
|
* IFF_TAP - TAP device
|
||||||
|
*
|
||||||
|
* IFF_NO_PI - Do not provide packet information
|
||||||
|
* IFF_MULTI_QUEUE - Create a queue of multiqueue device
|
||||||
|
*/
|
||||||
|
ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_MULTI_QUEUE;
|
||||||
|
strcpy(ifr.ifr_name, dev);
|
||||||
|
|
||||||
|
for (i = 0; i < queues; i++) {
|
||||||
|
if ((fd = open("/dev/net/tun", O_RDWR)) < 0)
|
||||||
|
goto err;
|
||||||
|
err = ioctl(fd, TUNSETIFF, (void *)&ifr);
|
||||||
|
if (err) {
|
||||||
|
close(fd);
|
||||||
|
goto err;
|
||||||
|
}
|
||||||
|
fds[i] = fd;
|
||||||
|
}
|
||||||
|
|
||||||
|
return 0;
|
||||||
|
err:
|
||||||
|
for (--i; i >= 0; i--)
|
||||||
|
close(fds[i]);
|
||||||
|
return err;
|
||||||
|
}
|
||||||
|
|
||||||
|
A new ioctl(TUNSETQUEUE) were introduced to enable or disable a queue. When
|
||||||
|
calling it with IFF_DETACH_QUEUE flag, the queue were disabled. And when
|
||||||
|
calling it with IFF_ATTACH_QUEUE flag, the queue were enabled. The queue were
|
||||||
|
enabled by default after it was created through TUNSETIFF.
|
||||||
|
|
||||||
|
fd is the file descriptor (queue) that we want to enable or disable, when
|
||||||
|
enable is true we enable it, otherwise we disable it
|
||||||
|
|
||||||
|
#include <linux/if.h>
|
||||||
|
#include <linux/if_tun.h>
|
||||||
|
|
||||||
|
int tun_set_queue(int fd, int enable)
|
||||||
|
{
|
||||||
|
struct ifreq ifr;
|
||||||
|
|
||||||
|
memset(&ifr, 0, sizeof(ifr));
|
||||||
|
|
||||||
|
if (enable)
|
||||||
|
ifr.ifr_flags = IFF_ATTACH_QUEUE;
|
||||||
|
else
|
||||||
|
ifr.ifr_flags = IFF_DETACH_QUEUE;
|
||||||
|
|
||||||
|
return ioctl(fd, TUNSETQUEUE, (void *)&ifr);
|
||||||
|
}
|
||||||
|
|
||||||
Universal TUN/TAP device driver Frequently Asked Question.
|
Universal TUN/TAP device driver Frequently Asked Question.
|
||||||
|
|
||||||
1. What platforms are supported by TUN/TAP driver ?
|
1. What platforms are supported by TUN/TAP driver ?
|
||||||
|
@@ -736,6 +736,13 @@ All the above functions are mandatory to implement for a pinmux driver.
|
|||||||
Pin control interaction with the GPIO subsystem
|
Pin control interaction with the GPIO subsystem
|
||||||
===============================================
|
===============================================
|
||||||
|
|
||||||
|
Note that the following implies that the use case is to use a certain pin
|
||||||
|
from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
|
||||||
|
and similar functions. There are cases where you may be using something
|
||||||
|
that your datasheet calls "GPIO mode" but actually is just an electrical
|
||||||
|
configuration for a certain device. See the section below named
|
||||||
|
"GPIO mode pitfalls" for more details on this scenario.
|
||||||
|
|
||||||
The public pinmux API contains two functions named pinctrl_request_gpio()
|
The public pinmux API contains two functions named pinctrl_request_gpio()
|
||||||
and pinctrl_free_gpio(). These two functions shall *ONLY* be called from
|
and pinctrl_free_gpio(). These two functions shall *ONLY* be called from
|
||||||
gpiolib-based drivers as part of their gpio_request() and
|
gpiolib-based drivers as part of their gpio_request() and
|
||||||
@@ -774,6 +781,111 @@ obtain the function "gpioN" where "N" is the global GPIO pin number if no
|
|||||||
special GPIO-handler is registered.
|
special GPIO-handler is registered.
|
||||||
|
|
||||||
|
|
||||||
|
GPIO mode pitfalls
|
||||||
|
==================
|
||||||
|
|
||||||
|
Sometime the developer may be confused by a datasheet talking about a pin
|
||||||
|
being possible to set into "GPIO mode". It appears that what hardware
|
||||||
|
engineers mean with "GPIO mode" is not necessarily the use case that is
|
||||||
|
implied in the kernel interface <linux/gpio.h>: a pin that you grab from
|
||||||
|
kernel code and then either listen for input or drive high/low to
|
||||||
|
assert/deassert some external line.
|
||||||
|
|
||||||
|
Rather hardware engineers think that "GPIO mode" means that you can
|
||||||
|
software-control a few electrical properties of the pin that you would
|
||||||
|
not be able to control if the pin was in some other mode, such as muxed in
|
||||||
|
for a device.
|
||||||
|
|
||||||
|
Example: a pin is usually muxed in to be used as a UART TX line. But during
|
||||||
|
system sleep, we need to put this pin into "GPIO mode" and ground it.
|
||||||
|
|
||||||
|
If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
|
||||||
|
to think that you need to come up with something real complex, that the
|
||||||
|
pin shall be used for UART TX and GPIO at the same time, that you will grab
|
||||||
|
a pin control handle and set it to a certain state to enable UART TX to be
|
||||||
|
muxed in, then twist it over to GPIO mode and use gpio_direction_output()
|
||||||
|
to drive it low during sleep, then mux it over to UART TX again when you
|
||||||
|
wake up and maybe even gpio_request/gpio_free as part of this cycle. This
|
||||||
|
all gets very complicated.
|
||||||
|
|
||||||
|
The solution is to not think that what the datasheet calls "GPIO mode"
|
||||||
|
has to be handled by the <linux/gpio.h> interface. Instead view this as
|
||||||
|
a certain pin config setting. Look in e.g. <linux/pinctrl/pinconf-generic.h>
|
||||||
|
and you find this in the documentation:
|
||||||
|
|
||||||
|
PIN_CONFIG_OUTPUT: this will configure the pin in output, use argument
|
||||||
|
1 to indicate high level, argument 0 to indicate low level.
|
||||||
|
|
||||||
|
So it is perfectly possible to push a pin into "GPIO mode" and drive the
|
||||||
|
line low as part of the usual pin control map. So for example your UART
|
||||||
|
driver may look like this:
|
||||||
|
|
||||||
|
#include <linux/pinctrl/consumer.h>
|
||||||
|
|
||||||
|
struct pinctrl *pinctrl;
|
||||||
|
struct pinctrl_state *pins_default;
|
||||||
|
struct pinctrl_state *pins_sleep;
|
||||||
|
|
||||||
|
pins_default = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_DEFAULT);
|
||||||
|
pins_sleep = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_SLEEP);
|
||||||
|
|
||||||
|
/* Normal mode */
|
||||||
|
retval = pinctrl_select_state(pinctrl, pins_default);
|
||||||
|
/* Sleep mode */
|
||||||
|
retval = pinctrl_select_state(pinctrl, pins_sleep);
|
||||||
|
|
||||||
|
And your machine configuration may look like this:
|
||||||
|
--------------------------------------------------
|
||||||
|
|
||||||
|
static unsigned long uart_default_mode[] = {
|
||||||
|
PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
|
||||||
|
};
|
||||||
|
|
||||||
|
static unsigned long uart_sleep_mode[] = {
|
||||||
|
PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0),
|
||||||
|
};
|
||||||
|
|
||||||
|
static struct pinctrl_map __initdata pinmap[] = {
|
||||||
|
PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
|
||||||
|
"u0_group", "u0"),
|
||||||
|
PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
|
||||||
|
"UART_TX_PIN", uart_default_mode),
|
||||||
|
PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
|
||||||
|
"u0_group", "gpio-mode"),
|
||||||
|
PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
|
||||||
|
"UART_TX_PIN", uart_sleep_mode),
|
||||||
|
};
|
||||||
|
|
||||||
|
foo_init(void) {
|
||||||
|
pinctrl_register_mappings(pinmap, ARRAY_SIZE(pinmap));
|
||||||
|
}
|
||||||
|
|
||||||
|
Here the pins we want to control are in the "u0_group" and there is some
|
||||||
|
function called "u0" that can be enabled on this group of pins, and then
|
||||||
|
everything is UART business as usual. But there is also some function
|
||||||
|
named "gpio-mode" that can be mapped onto the same pins to move them into
|
||||||
|
GPIO mode.
|
||||||
|
|
||||||
|
This will give the desired effect without any bogus interaction with the
|
||||||
|
GPIO subsystem. It is just an electrical configuration used by that device
|
||||||
|
when going to sleep, it might imply that the pin is set into something the
|
||||||
|
datasheet calls "GPIO mode" but that is not the point: it is still used
|
||||||
|
by that UART device to control the pins that pertain to that very UART
|
||||||
|
driver, putting them into modes needed by the UART. GPIO in the Linux
|
||||||
|
kernel sense are just some 1-bit line, and is a different use case.
|
||||||
|
|
||||||
|
How the registers are poked to attain the push/pull and output low
|
||||||
|
configuration and the muxing of the "u0" or "gpio-mode" group onto these
|
||||||
|
pins is a question for the driver.
|
||||||
|
|
||||||
|
Some datasheets will be more helpful and refer to the "GPIO mode" as
|
||||||
|
"low power mode" rather than anything to do with GPIO. This often means
|
||||||
|
the same thing electrically speaking, but in this latter case the
|
||||||
|
software engineers will usually quickly identify that this is some
|
||||||
|
specific muxing/configuration rather than anything related to the GPIO
|
||||||
|
API.
|
||||||
|
|
||||||
|
|
||||||
Board/machine configuration
|
Board/machine configuration
|
||||||
==================================
|
==================================
|
||||||
|
|
||||||
|
@@ -1,6 +1,5 @@
|
|||||||
*=============*
|
Operating Performance Points (OPP) Library
|
||||||
* OPP Library *
|
==========================================
|
||||||
*=============*
|
|
||||||
|
|
||||||
(C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated
|
(C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated
|
||||||
|
|
||||||
@@ -16,15 +15,31 @@ Contents
|
|||||||
|
|
||||||
1. Introduction
|
1. Introduction
|
||||||
===============
|
===============
|
||||||
|
1.1 What is an Operating Performance Point (OPP)?
|
||||||
|
|
||||||
Complex SoCs of today consists of a multiple sub-modules working in conjunction.
|
Complex SoCs of today consists of a multiple sub-modules working in conjunction.
|
||||||
In an operational system executing varied use cases, not all modules in the SoC
|
In an operational system executing varied use cases, not all modules in the SoC
|
||||||
need to function at their highest performing frequency all the time. To
|
need to function at their highest performing frequency all the time. To
|
||||||
facilitate this, sub-modules in a SoC are grouped into domains, allowing some
|
facilitate this, sub-modules in a SoC are grouped into domains, allowing some
|
||||||
domains to run at lower voltage and frequency while other domains are loaded
|
domains to run at lower voltage and frequency while other domains run at
|
||||||
more. The set of discrete tuples consisting of frequency and voltage pairs that
|
voltage/frequency pairs that are higher.
|
||||||
|
|
||||||
|
The set of discrete tuples consisting of frequency and voltage pairs that
|
||||||
the device will support per domain are called Operating Performance Points or
|
the device will support per domain are called Operating Performance Points or
|
||||||
OPPs.
|
OPPs.
|
||||||
|
|
||||||
|
As an example:
|
||||||
|
Let us consider an MPU device which supports the following:
|
||||||
|
{300MHz at minimum voltage of 1V}, {800MHz at minimum voltage of 1.2V},
|
||||||
|
{1GHz at minimum voltage of 1.3V}
|
||||||
|
|
||||||
|
We can represent these as three OPPs as the following {Hz, uV} tuples:
|
||||||
|
{300000000, 1000000}
|
||||||
|
{800000000, 1200000}
|
||||||
|
{1000000000, 1300000}
|
||||||
|
|
||||||
|
1.2 Operating Performance Points Library
|
||||||
|
|
||||||
OPP library provides a set of helper functions to organize and query the OPP
|
OPP library provides a set of helper functions to organize and query the OPP
|
||||||
information. The library is located in drivers/base/power/opp.c and the header
|
information. The library is located in drivers/base/power/opp.c and the header
|
||||||
is located in include/linux/opp.h. OPP library can be enabled by enabling
|
is located in include/linux/opp.h. OPP library can be enabled by enabling
|
||||||
|
@@ -170,5 +170,5 @@ Reminder: sizeof() result is of type size_t.
|
|||||||
Thank you for your cooperation and attention.
|
Thank you for your cooperation and attention.
|
||||||
|
|
||||||
|
|
||||||
By Randy Dunlap <rdunlap@xenotime.net> and
|
By Randy Dunlap <rdunlap@infradead.org> and
|
||||||
Andrew Murray <amurray@mpc-data.co.uk>
|
Andrew Murray <amurray@mpc-data.co.uk>
|
||||||
|
@@ -143,7 +143,8 @@ Parameter: id: handle for debug log
|
|||||||
|
|
||||||
Return Value: none
|
Return Value: none
|
||||||
|
|
||||||
Description: frees memory for a debug log
|
Description: frees memory for a debug log and removes all registered debug
|
||||||
|
views.
|
||||||
Must not be called within an interrupt handler
|
Must not be called within an interrupt handler
|
||||||
|
|
||||||
---------------------------------------------------------------------------
|
---------------------------------------------------------------------------
|
||||||
|
@@ -1,4 +1,4 @@
|
|||||||
Copyright (c) 2003-2012 QLogic Corporation
|
Copyright (c) 2003-2013 QLogic Corporation
|
||||||
QLogic Linux FC-FCoE Driver
|
QLogic Linux FC-FCoE Driver
|
||||||
|
|
||||||
This program includes a device driver for Linux 3.x.
|
This program includes a device driver for Linux 3.x.
|
||||||
|
@@ -890,9 +890,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||||||
enable_msi - Enable Message Signaled Interrupt (MSI) (default = off)
|
enable_msi - Enable Message Signaled Interrupt (MSI) (default = off)
|
||||||
power_save - Automatic power-saving timeout (in second, 0 =
|
power_save - Automatic power-saving timeout (in second, 0 =
|
||||||
disable)
|
disable)
|
||||||
power_save_controller - Support runtime D3 of HD-audio controller
|
power_save_controller - Reset HD-audio controller in power-saving mode
|
||||||
(-1 = on for supported chip (default), false = off,
|
(default = on)
|
||||||
true = force to on even for unsupported hardware)
|
|
||||||
align_buffer_size - Force rounding of buffer/period sizes to multiples
|
align_buffer_size - Force rounding of buffer/period sizes to multiples
|
||||||
of 128 bytes. This is more efficient in terms of memory
|
of 128 bytes. This is more efficient in terms of memory
|
||||||
access but isn't required by the HDA spec and prevents
|
access but isn't required by the HDA spec and prevents
|
||||||
@@ -912,7 +911,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||||||
models depending on the codec chip. The list of available models
|
models depending on the codec chip. The list of available models
|
||||||
is found in HD-Audio-Models.txt
|
is found in HD-Audio-Models.txt
|
||||||
|
|
||||||
The model name "genric" is treated as a special case. When this
|
The model name "generic" is treated as a special case. When this
|
||||||
model is given, the driver uses the generic codec parser without
|
model is given, the driver uses the generic codec parser without
|
||||||
"codec-patch". It's sometimes good for testing and debugging.
|
"codec-patch". It's sometimes good for testing and debugging.
|
||||||
|
|
||||||
|
@@ -285,7 +285,7 @@ sample data.
|
|||||||
<H4>
|
<H4>
|
||||||
7.2.4 Close Callback</H4>
|
7.2.4 Close Callback</H4>
|
||||||
The <TT>close</TT> callback is called when this device is closed by the
|
The <TT>close</TT> callback is called when this device is closed by the
|
||||||
applicaion. If any private data was allocated in open callback, it must
|
application. If any private data was allocated in open callback, it must
|
||||||
be released in the close callback. The deletion of ALSA port should be
|
be released in the close callback. The deletion of ALSA port should be
|
||||||
done here, too. This callback must not be NULL.
|
done here, too. This callback must not be NULL.
|
||||||
<H4>
|
<H4>
|
||||||
|
@@ -18,6 +18,7 @@ files can be found in mm/swap.c.
|
|||||||
|
|
||||||
Currently, these files are in /proc/sys/vm:
|
Currently, these files are in /proc/sys/vm:
|
||||||
|
|
||||||
|
- admin_reserve_kbytes
|
||||||
- block_dump
|
- block_dump
|
||||||
- compact_memory
|
- compact_memory
|
||||||
- dirty_background_bytes
|
- dirty_background_bytes
|
||||||
@@ -53,11 +54,41 @@ Currently, these files are in /proc/sys/vm:
|
|||||||
- percpu_pagelist_fraction
|
- percpu_pagelist_fraction
|
||||||
- stat_interval
|
- stat_interval
|
||||||
- swappiness
|
- swappiness
|
||||||
|
- user_reserve_kbytes
|
||||||
- vfs_cache_pressure
|
- vfs_cache_pressure
|
||||||
- zone_reclaim_mode
|
- zone_reclaim_mode
|
||||||
|
|
||||||
==============================================================
|
==============================================================
|
||||||
|
|
||||||
|
admin_reserve_kbytes
|
||||||
|
|
||||||
|
The amount of free memory in the system that should be reserved for users
|
||||||
|
with the capability cap_sys_admin.
|
||||||
|
|
||||||
|
admin_reserve_kbytes defaults to min(3% of free pages, 8MB)
|
||||||
|
|
||||||
|
That should provide enough for the admin to log in and kill a process,
|
||||||
|
if necessary, under the default overcommit 'guess' mode.
|
||||||
|
|
||||||
|
Systems running under overcommit 'never' should increase this to account
|
||||||
|
for the full Virtual Memory Size of programs used to recover. Otherwise,
|
||||||
|
root may not be able to log in to recover the system.
|
||||||
|
|
||||||
|
How do you calculate a minimum useful reserve?
|
||||||
|
|
||||||
|
sshd or login + bash (or some other shell) + top (or ps, kill, etc.)
|
||||||
|
|
||||||
|
For overcommit 'guess', we can sum resident set sizes (RSS).
|
||||||
|
On x86_64 this is about 8MB.
|
||||||
|
|
||||||
|
For overcommit 'never', we can take the max of their virtual sizes (VSZ)
|
||||||
|
and add the sum of their RSS.
|
||||||
|
On x86_64 this is about 128MB.
|
||||||
|
|
||||||
|
Changing this takes effect whenever an application requests memory.
|
||||||
|
|
||||||
|
==============================================================
|
||||||
|
|
||||||
block_dump
|
block_dump
|
||||||
|
|
||||||
block_dump enables block I/O debugging when set to a nonzero value. More
|
block_dump enables block I/O debugging when set to a nonzero value. More
|
||||||
@@ -542,6 +573,7 @@ memory until it actually runs out.
|
|||||||
|
|
||||||
When this flag is 2, the kernel uses a "never overcommit"
|
When this flag is 2, the kernel uses a "never overcommit"
|
||||||
policy that attempts to prevent any overcommit of memory.
|
policy that attempts to prevent any overcommit of memory.
|
||||||
|
Note that user_reserve_kbytes affects this policy.
|
||||||
|
|
||||||
This feature can be very useful because there are a lot of
|
This feature can be very useful because there are a lot of
|
||||||
programs that malloc() huge amounts of memory "just-in-case"
|
programs that malloc() huge amounts of memory "just-in-case"
|
||||||
@@ -645,6 +677,24 @@ The default value is 60.
|
|||||||
|
|
||||||
==============================================================
|
==============================================================
|
||||||
|
|
||||||
|
- user_reserve_kbytes
|
||||||
|
|
||||||
|
When overcommit_memory is set to 2, "never overommit" mode, reserve
|
||||||
|
min(3% of current process size, user_reserve_kbytes) of free memory.
|
||||||
|
This is intended to prevent a user from starting a single memory hogging
|
||||||
|
process, such that they cannot recover (kill the hog).
|
||||||
|
|
||||||
|
user_reserve_kbytes defaults to min(3% of the current process size, 128MB).
|
||||||
|
|
||||||
|
If this is reduced to zero, then the user will be allowed to allocate
|
||||||
|
all free memory with a single process, minus admin_reserve_kbytes.
|
||||||
|
Any subsequent attempts to execute a command will result in
|
||||||
|
"fork: Cannot allocate memory".
|
||||||
|
|
||||||
|
Changing this takes effect whenever an application requests memory.
|
||||||
|
|
||||||
|
==============================================================
|
||||||
|
|
||||||
vfs_cache_pressure
|
vfs_cache_pressure
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
|
205
Documentation/this_cpu_ops.txt
Normal file
205
Documentation/this_cpu_ops.txt
Normal file
@@ -0,0 +1,205 @@
|
|||||||
|
this_cpu operations
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
this_cpu operations are a way of optimizing access to per cpu
|
||||||
|
variables associated with the *currently* executing processor through
|
||||||
|
the use of segment registers (or a dedicated register where the cpu
|
||||||
|
permanently stored the beginning of the per cpu area for a specific
|
||||||
|
processor).
|
||||||
|
|
||||||
|
The this_cpu operations add a per cpu variable offset to the processor
|
||||||
|
specific percpu base and encode that operation in the instruction
|
||||||
|
operating on the per cpu variable.
|
||||||
|
|
||||||
|
This means there are no atomicity issues between the calculation of
|
||||||
|
the offset and the operation on the data. Therefore it is not
|
||||||
|
necessary to disable preempt or interrupts to ensure that the
|
||||||
|
processor is not changed between the calculation of the address and
|
||||||
|
the operation on the data.
|
||||||
|
|
||||||
|
Read-modify-write operations are of particular interest. Frequently
|
||||||
|
processors have special lower latency instructions that can operate
|
||||||
|
without the typical synchronization overhead but still provide some
|
||||||
|
sort of relaxed atomicity guarantee. The x86 for example can execute
|
||||||
|
RMV (Read Modify Write) instructions like inc/dec/cmpxchg without the
|
||||||
|
lock prefix and the associated latency penalty.
|
||||||
|
|
||||||
|
Access to the variable without the lock prefix is not synchronized but
|
||||||
|
synchronization is not necessary since we are dealing with per cpu
|
||||||
|
data specific to the currently executing processor. Only the current
|
||||||
|
processor should be accessing that variable and therefore there are no
|
||||||
|
concurrency issues with other processors in the system.
|
||||||
|
|
||||||
|
On x86 the fs: or the gs: segment registers contain the base of the
|
||||||
|
per cpu area. It is then possible to simply use the segment override
|
||||||
|
to relocate a per cpu relative address to the proper per cpu area for
|
||||||
|
the processor. So the relocation to the per cpu base is encoded in the
|
||||||
|
instruction via a segment register prefix.
|
||||||
|
|
||||||
|
For example:
|
||||||
|
|
||||||
|
DEFINE_PER_CPU(int, x);
|
||||||
|
int z;
|
||||||
|
|
||||||
|
z = this_cpu_read(x);
|
||||||
|
|
||||||
|
results in a single instruction
|
||||||
|
|
||||||
|
mov ax, gs:[x]
|
||||||
|
|
||||||
|
instead of a sequence of calculation of the address and then a fetch
|
||||||
|
from that address which occurs with the percpu operations. Before
|
||||||
|
this_cpu_ops such sequence also required preempt disable/enable to
|
||||||
|
prevent the kernel from moving the thread to a different processor
|
||||||
|
while the calculation is performed.
|
||||||
|
|
||||||
|
The main use of the this_cpu operations has been to optimize counter
|
||||||
|
operations.
|
||||||
|
|
||||||
|
this_cpu_inc(x)
|
||||||
|
|
||||||
|
results in the following single instruction (no lock prefix!)
|
||||||
|
|
||||||
|
inc gs:[x]
|
||||||
|
|
||||||
|
instead of the following operations required if there is no segment
|
||||||
|
register.
|
||||||
|
|
||||||
|
int *y;
|
||||||
|
int cpu;
|
||||||
|
|
||||||
|
cpu = get_cpu();
|
||||||
|
y = per_cpu_ptr(&x, cpu);
|
||||||
|
(*y)++;
|
||||||
|
put_cpu();
|
||||||
|
|
||||||
|
Note that these operations can only be used on percpu data that is
|
||||||
|
reserved for a specific processor. Without disabling preemption in the
|
||||||
|
surrounding code this_cpu_inc() will only guarantee that one of the
|
||||||
|
percpu counters is correctly incremented. However, there is no
|
||||||
|
guarantee that the OS will not move the process directly before or
|
||||||
|
after the this_cpu instruction is executed. In general this means that
|
||||||
|
the value of the individual counters for each processor are
|
||||||
|
meaningless. The sum of all the per cpu counters is the only value
|
||||||
|
that is of interest.
|
||||||
|
|
||||||
|
Per cpu variables are used for performance reasons. Bouncing cache
|
||||||
|
lines can be avoided if multiple processors concurrently go through
|
||||||
|
the same code paths. Since each processor has its own per cpu
|
||||||
|
variables no concurrent cacheline updates take place. The price that
|
||||||
|
has to be paid for this optimization is the need to add up the per cpu
|
||||||
|
counters when the value of the counter is needed.
|
||||||
|
|
||||||
|
|
||||||
|
Special operations:
|
||||||
|
-------------------
|
||||||
|
|
||||||
|
y = this_cpu_ptr(&x)
|
||||||
|
|
||||||
|
Takes the offset of a per cpu variable (&x !) and returns the address
|
||||||
|
of the per cpu variable that belongs to the currently executing
|
||||||
|
processor. this_cpu_ptr avoids multiple steps that the common
|
||||||
|
get_cpu/put_cpu sequence requires. No processor number is
|
||||||
|
available. Instead the offset of the local per cpu area is simply
|
||||||
|
added to the percpu offset.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Per cpu variables and offsets
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
Per cpu variables have *offsets* to the beginning of the percpu
|
||||||
|
area. They do not have addresses although they look like that in the
|
||||||
|
code. Offsets cannot be directly dereferenced. The offset must be
|
||||||
|
added to a base pointer of a percpu area of a processor in order to
|
||||||
|
form a valid address.
|
||||||
|
|
||||||
|
Therefore the use of x or &x outside of the context of per cpu
|
||||||
|
operations is invalid and will generally be treated like a NULL
|
||||||
|
pointer dereference.
|
||||||
|
|
||||||
|
In the context of per cpu operations
|
||||||
|
|
||||||
|
x is a per cpu variable. Most this_cpu operations take a cpu
|
||||||
|
variable.
|
||||||
|
|
||||||
|
&x is the *offset* a per cpu variable. this_cpu_ptr() takes
|
||||||
|
the offset of a per cpu variable which makes this look a bit
|
||||||
|
strange.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Operations on a field of a per cpu structure
|
||||||
|
--------------------------------------------
|
||||||
|
|
||||||
|
Let's say we have a percpu structure
|
||||||
|
|
||||||
|
struct s {
|
||||||
|
int n,m;
|
||||||
|
};
|
||||||
|
|
||||||
|
DEFINE_PER_CPU(struct s, p);
|
||||||
|
|
||||||
|
|
||||||
|
Operations on these fields are straightforward
|
||||||
|
|
||||||
|
this_cpu_inc(p.m)
|
||||||
|
|
||||||
|
z = this_cpu_cmpxchg(p.m, 0, 1);
|
||||||
|
|
||||||
|
|
||||||
|
If we have an offset to struct s:
|
||||||
|
|
||||||
|
struct s __percpu *ps = &p;
|
||||||
|
|
||||||
|
z = this_cpu_dec(ps->m);
|
||||||
|
|
||||||
|
z = this_cpu_inc_return(ps->n);
|
||||||
|
|
||||||
|
|
||||||
|
The calculation of the pointer may require the use of this_cpu_ptr()
|
||||||
|
if we do not make use of this_cpu ops later to manipulate fields:
|
||||||
|
|
||||||
|
struct s *pp;
|
||||||
|
|
||||||
|
pp = this_cpu_ptr(&p);
|
||||||
|
|
||||||
|
pp->m--;
|
||||||
|
|
||||||
|
z = pp->n++;
|
||||||
|
|
||||||
|
|
||||||
|
Variants of this_cpu ops
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
this_cpu ops are interrupt safe. Some architecture do not support
|
||||||
|
these per cpu local operations. In that case the operation must be
|
||||||
|
replaced by code that disables interrupts, then does the operations
|
||||||
|
that are guaranteed to be atomic and then reenable interrupts. Doing
|
||||||
|
so is expensive. If there are other reasons why the scheduler cannot
|
||||||
|
change the processor we are executing on then there is no reason to
|
||||||
|
disable interrupts. For that purpose the __this_cpu operations are
|
||||||
|
provided. For example.
|
||||||
|
|
||||||
|
__this_cpu_inc(x);
|
||||||
|
|
||||||
|
Will increment x and will not fallback to code that disables
|
||||||
|
interrupts on platforms that cannot accomplish atomicity through
|
||||||
|
address relocation and a Read-Modify-Write operation in the same
|
||||||
|
instruction.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
&this_cpu_ptr(pp)->n vs this_cpu_ptr(&pp->n)
|
||||||
|
--------------------------------------------
|
||||||
|
|
||||||
|
The first operation takes the offset and forms an address and then
|
||||||
|
adds the offset of the n field.
|
||||||
|
|
||||||
|
The second one first adds the two offsets and then does the
|
||||||
|
relocation. IMHO the second form looks cleaner and has an easier time
|
||||||
|
with (). The second form also is consistent with the way
|
||||||
|
this_cpu_read() and friends are used.
|
||||||
|
|
||||||
|
|
||||||
|
Christoph Lameter, April 3rd, 2013
|
File diff suppressed because it is too large
Load Diff
@@ -1,7 +1,9 @@
|
|||||||
Uprobe-tracer: Uprobe-based Event Tracing
|
Uprobe-tracer: Uprobe-based Event Tracing
|
||||||
=========================================
|
=========================================
|
||||||
|
|
||||||
Documentation written by Srikar Dronamraju
|
Documentation written by Srikar Dronamraju
|
||||||
|
|
||||||
|
|
||||||
Overview
|
Overview
|
||||||
--------
|
--------
|
||||||
Uprobe based trace events are similar to kprobe based trace events.
|
Uprobe based trace events are similar to kprobe based trace events.
|
||||||
@@ -13,16 +15,18 @@ current_tracer. Instead of that, add probe points via
|
|||||||
/sys/kernel/debug/tracing/events/uprobes/<EVENT>/enabled.
|
/sys/kernel/debug/tracing/events/uprobes/<EVENT>/enabled.
|
||||||
|
|
||||||
However unlike kprobe-event tracer, the uprobe event interface expects the
|
However unlike kprobe-event tracer, the uprobe event interface expects the
|
||||||
user to calculate the offset of the probepoint in the object
|
user to calculate the offset of the probepoint in the object.
|
||||||
|
|
||||||
Synopsis of uprobe_tracer
|
Synopsis of uprobe_tracer
|
||||||
-------------------------
|
-------------------------
|
||||||
p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a probe
|
p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a uprobe
|
||||||
|
r[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a return uprobe (uretprobe)
|
||||||
|
-:[GRP/]EVENT : Clear uprobe or uretprobe event
|
||||||
|
|
||||||
GRP : Group name. If omitted, use "uprobes" for it.
|
GRP : Group name. If omitted, "uprobes" is the default value.
|
||||||
EVENT : Event name. If omitted, the event name is generated
|
EVENT : Event name. If omitted, the event name is generated based
|
||||||
based on SYMBOL+offs.
|
on SYMBOL+offs.
|
||||||
PATH : path to an executable or a library.
|
PATH : Path to an executable or a library.
|
||||||
SYMBOL[+offs] : Symbol+offset where the probe is inserted.
|
SYMBOL[+offs] : Symbol+offset where the probe is inserted.
|
||||||
|
|
||||||
FETCHARGS : Arguments. Each probe can have up to 128 args.
|
FETCHARGS : Arguments. Each probe can have up to 128 args.
|
||||||
@@ -37,20 +41,29 @@ the third is the number of probe miss-hits.
|
|||||||
|
|
||||||
Usage examples
|
Usage examples
|
||||||
--------------
|
--------------
|
||||||
To add a probe as a new event, write a new definition to uprobe_events
|
* Add a probe as a new uprobe event, write a new definition to uprobe_events
|
||||||
as below.
|
as below: (sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash)
|
||||||
|
|
||||||
echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
|
echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
|
||||||
|
|
||||||
This sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash
|
* Add a probe as a new uretprobe event:
|
||||||
|
|
||||||
|
echo 'r: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
|
||||||
|
|
||||||
|
* Unset registered event:
|
||||||
|
|
||||||
|
echo '-:bash_0x4245c0' >> /sys/kernel/debug/tracing/uprobe_events
|
||||||
|
|
||||||
|
* Print out the events that are registered:
|
||||||
|
|
||||||
|
cat /sys/kernel/debug/tracing/uprobe_events
|
||||||
|
|
||||||
|
* Clear all events:
|
||||||
|
|
||||||
echo > /sys/kernel/debug/tracing/uprobe_events
|
echo > /sys/kernel/debug/tracing/uprobe_events
|
||||||
|
|
||||||
This clears all probe points.
|
Following example shows how to dump the instruction pointer and %ax register
|
||||||
|
at the probed text address. Probe zfree function in /bin/zsh:
|
||||||
The following example shows how to dump the instruction pointer and %ax
|
|
||||||
a register at the probed text address. Here we are trying to probe
|
|
||||||
function zfree in /bin/zsh
|
|
||||||
|
|
||||||
# cd /sys/kernel/debug/tracing/
|
# cd /sys/kernel/debug/tracing/
|
||||||
# cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp
|
# cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp
|
||||||
@@ -59,21 +72,26 @@ function zfree in /bin/zsh
|
|||||||
0000000000446420 g DF .text 0000000000000012 Base zfree
|
0000000000446420 g DF .text 0000000000000012 Base zfree
|
||||||
|
|
||||||
0x46420 is the offset of zfree in object /bin/zsh that is loaded at
|
0x46420 is the offset of zfree in object /bin/zsh that is loaded at
|
||||||
0x00400000. Hence the command to probe would be :
|
0x00400000. Hence the command to uprobe would be:
|
||||||
|
|
||||||
# echo 'p /bin/zsh:0x46420 %ip %ax' > uprobe_events
|
# echo 'p:zfree_entry /bin/zsh:0x46420 %ip %ax' > uprobe_events
|
||||||
|
|
||||||
Please note: User has to explicitly calculate the offset of the probepoint
|
And the same for the uretprobe would be:
|
||||||
|
|
||||||
|
# echo 'r:zfree_exit /bin/zsh:0x46420 %ip %ax' >> uprobe_events
|
||||||
|
|
||||||
|
Please note: User has to explicitly calculate the offset of the probe-point
|
||||||
in the object. We can see the events that are registered by looking at the
|
in the object. We can see the events that are registered by looking at the
|
||||||
uprobe_events file.
|
uprobe_events file.
|
||||||
|
|
||||||
# cat uprobe_events
|
# cat uprobe_events
|
||||||
p:uprobes/p_zsh_0x46420 /bin/zsh:0x00046420 arg1=%ip arg2=%ax
|
p:uprobes/zfree_entry /bin/zsh:0x00046420 arg1=%ip arg2=%ax
|
||||||
|
r:uprobes/zfree_exit /bin/zsh:0x00046420 arg1=%ip arg2=%ax
|
||||||
|
|
||||||
The format of events can be seen by viewing the file events/uprobes/p_zsh_0x46420/format
|
Format of events can be seen by viewing the file events/uprobes/zfree_entry/format
|
||||||
|
|
||||||
# cat events/uprobes/p_zsh_0x46420/format
|
# cat events/uprobes/zfree_entry/format
|
||||||
name: p_zsh_0x46420
|
name: zfree_entry
|
||||||
ID: 922
|
ID: 922
|
||||||
format:
|
format:
|
||||||
field:unsigned short common_type; offset:0; size:2; signed:0;
|
field:unsigned short common_type; offset:0; size:2; signed:0;
|
||||||
@@ -94,6 +112,7 @@ events, you need to enable it by:
|
|||||||
# echo 1 > events/uprobes/enable
|
# echo 1 > events/uprobes/enable
|
||||||
|
|
||||||
Lets disable the event after sleeping for some time.
|
Lets disable the event after sleeping for some time.
|
||||||
|
|
||||||
# sleep 20
|
# sleep 20
|
||||||
# echo 0 > events/uprobes/enable
|
# echo 0 > events/uprobes/enable
|
||||||
|
|
||||||
@@ -104,10 +123,11 @@ And you can see the traced information via /sys/kernel/debug/tracing/trace.
|
|||||||
#
|
#
|
||||||
# TASK-PID CPU# TIMESTAMP FUNCTION
|
# TASK-PID CPU# TIMESTAMP FUNCTION
|
||||||
# | | | | |
|
# | | | | |
|
||||||
zsh-24842 [006] 258544.995456: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
|
zsh-24842 [006] 258544.995456: zfree_entry: (0x446420) arg1=446420 arg2=79
|
||||||
zsh-24842 [007] 258545.000270: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
|
zsh-24842 [007] 258545.000270: zfree_exit: (0x446540 <- 0x446420) arg1=446540 arg2=0
|
||||||
zsh-24842 [002] 258545.043929: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
|
zsh-24842 [002] 258545.043929: zfree_entry: (0x446420) arg1=446420 arg2=79
|
||||||
zsh-24842 [004] 258547.046129: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79
|
zsh-24842 [004] 258547.046129: zfree_exit: (0x446540 <- 0x446420) arg1=446540 arg2=0
|
||||||
|
|
||||||
Each line shows us probes were triggered for a pid 24842 with ip being
|
Output shows us uprobe was triggered for a pid 24842 with ip being 0x446420
|
||||||
0x446421 and contents of ax register being 79.
|
and contents of ax register being 79. And uretprobe was triggered with ip at
|
||||||
|
0x446540 with counterpart function entry at 0x446420.
|
||||||
|
@@ -33,6 +33,10 @@ built with CONFIG_USB_SUSPEND enabled (which depends on
|
|||||||
CONFIG_PM_RUNTIME). System PM support is present only if the kernel
|
CONFIG_PM_RUNTIME). System PM support is present only if the kernel
|
||||||
was built with CONFIG_SUSPEND or CONFIG_HIBERNATION enabled.
|
was built with CONFIG_SUSPEND or CONFIG_HIBERNATION enabled.
|
||||||
|
|
||||||
|
(Starting with the 3.10 kernel release, dynamic PM support for USB is
|
||||||
|
present whenever the kernel was built with CONFIG_PM_RUNTIME enabled.
|
||||||
|
The CONFIG_USB_SUSPEND option has been eliminated.)
|
||||||
|
|
||||||
|
|
||||||
What is Remote Wakeup?
|
What is Remote Wakeup?
|
||||||
----------------------
|
----------------------
|
||||||
@@ -206,10 +210,8 @@ initialized to 5. (The idle-delay values for already existing devices
|
|||||||
will not be affected.)
|
will not be affected.)
|
||||||
|
|
||||||
Setting the initial default idle-delay to -1 will prevent any
|
Setting the initial default idle-delay to -1 will prevent any
|
||||||
autosuspend of any USB device. This is a simple alternative to
|
autosuspend of any USB device. This has the benefit of allowing you
|
||||||
disabling CONFIG_USB_SUSPEND and rebuilding the kernel, and it has the
|
then to enable autosuspend for selected devices.
|
||||||
added benefit of allowing you to enable autosuspend for selected
|
|
||||||
devices.
|
|
||||||
|
|
||||||
|
|
||||||
Warnings
|
Warnings
|
||||||
|
@@ -8,7 +8,9 @@ The Linux kernel supports the following overcommit handling modes
|
|||||||
default.
|
default.
|
||||||
|
|
||||||
1 - Always overcommit. Appropriate for some scientific
|
1 - Always overcommit. Appropriate for some scientific
|
||||||
applications.
|
applications. Classic example is code using sparse arrays
|
||||||
|
and just relying on the virtual memory consisting almost
|
||||||
|
entirely of zero pages.
|
||||||
|
|
||||||
2 - Don't overcommit. The total address space commit
|
2 - Don't overcommit. The total address space commit
|
||||||
for the system is not permitted to exceed swap + a
|
for the system is not permitted to exceed swap + a
|
||||||
@@ -18,6 +20,10 @@ The Linux kernel supports the following overcommit handling modes
|
|||||||
pages but will receive errors on memory allocation as
|
pages but will receive errors on memory allocation as
|
||||||
appropriate.
|
appropriate.
|
||||||
|
|
||||||
|
Useful for applications that want to guarantee their
|
||||||
|
memory allocations will be available in the future
|
||||||
|
without having to initialize every page.
|
||||||
|
|
||||||
The overcommit policy is set via the sysctl `vm.overcommit_memory'.
|
The overcommit policy is set via the sysctl `vm.overcommit_memory'.
|
||||||
|
|
||||||
The overcommit percentage is set via `vm.overcommit_ratio'.
|
The overcommit percentage is set via `vm.overcommit_ratio'.
|
||||||
|
185
MAINTAINERS
185
MAINTAINERS
@@ -90,6 +90,9 @@ Descriptions of section entries:
|
|||||||
F: drivers/net/* all files in drivers/net, but not below
|
F: drivers/net/* all files in drivers/net, but not below
|
||||||
F: */net/* all files in "any top level directory"/net
|
F: */net/* all files in "any top level directory"/net
|
||||||
One pattern per line. Multiple F: lines acceptable.
|
One pattern per line. Multiple F: lines acceptable.
|
||||||
|
N: Files and directories with regex patterns.
|
||||||
|
N: [^a-z]tegra all files whose path contains the word tegra
|
||||||
|
One pattern per line. Multiple N: lines acceptable.
|
||||||
X: Files and directories that are NOT maintained, same rules as F:
|
X: Files and directories that are NOT maintained, same rules as F:
|
||||||
Files exclusions are tested before file matches.
|
Files exclusions are tested before file matches.
|
||||||
Can be useful for excluding a specific subdirectory, for instance:
|
Can be useful for excluding a specific subdirectory, for instance:
|
||||||
@@ -97,13 +100,12 @@ Descriptions of section entries:
|
|||||||
X: net/ipv6/
|
X: net/ipv6/
|
||||||
matches all files in and below net excluding net/ipv6/
|
matches all files in and below net excluding net/ipv6/
|
||||||
K: Keyword perl extended regex pattern to match content in a
|
K: Keyword perl extended regex pattern to match content in a
|
||||||
patch or file, or an affected filename. For instance:
|
patch or file. For instance:
|
||||||
K: of_get_profile
|
K: of_get_profile
|
||||||
matches patch or file content, or filenames, that contain
|
matches patches or files that contain "of_get_profile"
|
||||||
"of_get_profile"
|
|
||||||
K: \b(printk|pr_(info|err))\b
|
K: \b(printk|pr_(info|err))\b
|
||||||
matches patch or file content, or filenames, that contain one or
|
matches patches or files that contain one or more of the words
|
||||||
more of the words printk, pr_info or pr_err
|
printk, pr_info or pr_err
|
||||||
One regex pattern per line. Multiple K: lines acceptable.
|
One regex pattern per line. Multiple K: lines acceptable.
|
||||||
|
|
||||||
Note: For the hard of thinking, this list is meant to remain in alphabetical
|
Note: For the hard of thinking, this list is meant to remain in alphabetical
|
||||||
@@ -114,12 +116,6 @@ Maintainers List (try to look for most precise areas first)
|
|||||||
|
|
||||||
-----------------------------------
|
-----------------------------------
|
||||||
|
|
||||||
3C505 NETWORK DRIVER
|
|
||||||
M: Philip Blundell <philb@gnu.org>
|
|
||||||
L: netdev@vger.kernel.org
|
|
||||||
S: Maintained
|
|
||||||
F: drivers/net/ethernet/i825xx/3c505*
|
|
||||||
|
|
||||||
3C59X NETWORK DRIVER
|
3C59X NETWORK DRIVER
|
||||||
M: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
|
M: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
@@ -1037,6 +1033,7 @@ F: drivers/mmc/host/msm_sdcc.h
|
|||||||
F: drivers/tty/serial/msm_serial.h
|
F: drivers/tty/serial/msm_serial.h
|
||||||
F: drivers/tty/serial/msm_serial.c
|
F: drivers/tty/serial/msm_serial.c
|
||||||
F: drivers/*/pm8???-*
|
F: drivers/*/pm8???-*
|
||||||
|
F: drivers/ssbi/
|
||||||
F: include/linux/mfd/pm8xxx/
|
F: include/linux/mfd/pm8xxx/
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davidb/linux-msm.git
|
||||||
S: Maintained
|
S: Maintained
|
||||||
@@ -1344,12 +1341,6 @@ S: Maintained
|
|||||||
F: drivers/platform/x86/asus*.c
|
F: drivers/platform/x86/asus*.c
|
||||||
F: drivers/platform/x86/eeepc*.c
|
F: drivers/platform/x86/eeepc*.c
|
||||||
|
|
||||||
ASUS ASB100 HARDWARE MONITOR DRIVER
|
|
||||||
M: "Mark M. Hoffman" <mhoffman@lightlink.com>
|
|
||||||
L: lm-sensors@lm-sensors.org
|
|
||||||
S: Maintained
|
|
||||||
F: drivers/hwmon/asb100.c
|
|
||||||
|
|
||||||
ASYNCHRONOUS TRANSFERS/TRANSFORMS (IOAT) API
|
ASYNCHRONOUS TRANSFERS/TRANSFORMS (IOAT) API
|
||||||
M: Dan Williams <djbw@fb.com>
|
M: Dan Williams <djbw@fb.com>
|
||||||
W: http://sourceforge.net/projects/xscaleiop
|
W: http://sourceforge.net/projects/xscaleiop
|
||||||
@@ -1473,6 +1464,12 @@ F: drivers/dma/at_hdmac.c
|
|||||||
F: drivers/dma/at_hdmac_regs.h
|
F: drivers/dma/at_hdmac_regs.h
|
||||||
F: include/linux/platform_data/dma-atmel.h
|
F: include/linux/platform_data/dma-atmel.h
|
||||||
|
|
||||||
|
ATMEL I2C DRIVER
|
||||||
|
M: Ludovic Desroches <ludovic.desroches@atmel.com>
|
||||||
|
L: linux-i2c@vger.kernel.org
|
||||||
|
S: Supported
|
||||||
|
F: drivers/i2c/busses/i2c-at91.c
|
||||||
|
|
||||||
ATMEL ISI DRIVER
|
ATMEL ISI DRIVER
|
||||||
M: Josh Wu <josh.wu@atmel.com>
|
M: Josh Wu <josh.wu@atmel.com>
|
||||||
L: linux-media@vger.kernel.org
|
L: linux-media@vger.kernel.org
|
||||||
@@ -2361,12 +2358,6 @@ W: http://www.arm.linux.org.uk/
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/video/cyber2000fb.*
|
F: drivers/video/cyber2000fb.*
|
||||||
|
|
||||||
CYCLADES 2X SYNC CARD DRIVER
|
|
||||||
M: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
|
|
||||||
W: http://oops.ghostprotocols.net:81/blog
|
|
||||||
S: Maintained
|
|
||||||
F: drivers/net/wan/cycx*
|
|
||||||
|
|
||||||
CYCLADES ASYNC MUX DRIVER
|
CYCLADES ASYNC MUX DRIVER
|
||||||
W: http://www.cyclades.com/
|
W: http://www.cyclades.com/
|
||||||
S: Orphan
|
S: Orphan
|
||||||
@@ -2453,9 +2444,7 @@ S: Maintained
|
|||||||
F: drivers/platform/x86/dell-laptop.c
|
F: drivers/platform/x86/dell-laptop.c
|
||||||
|
|
||||||
DELL LAPTOP SMM DRIVER
|
DELL LAPTOP SMM DRIVER
|
||||||
M: Massimo Dal Zotto <dz@debian.org>
|
S: Orphan
|
||||||
W: http://www.debian.org/~dz/i8k/
|
|
||||||
S: Maintained
|
|
||||||
F: drivers/char/i8k.c
|
F: drivers/char/i8k.c
|
||||||
F: include/uapi/linux/i8k.h
|
F: include/uapi/linux/i8k.h
|
||||||
|
|
||||||
@@ -2470,6 +2459,12 @@ M: Matthew Garrett <mjg59@srcf.ucam.org>
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/platform/x86/dell-wmi.c
|
F: drivers/platform/x86/dell-wmi.c
|
||||||
|
|
||||||
|
DESIGNWARE USB2 DRD IP DRIVER
|
||||||
|
M: Paul Zimmerman <paulz@synopsys.com>
|
||||||
|
L: linux-usb@vger.kernel.org
|
||||||
|
S: Maintained
|
||||||
|
F: drivers/staging/dwc2/
|
||||||
|
|
||||||
DESIGNWARE USB3 DRD IP DRIVER
|
DESIGNWARE USB3 DRD IP DRIVER
|
||||||
M: Felipe Balbi <balbi@ti.com>
|
M: Felipe Balbi <balbi@ti.com>
|
||||||
L: linux-usb@vger.kernel.org
|
L: linux-usb@vger.kernel.org
|
||||||
@@ -2641,7 +2636,7 @@ F: include/uapi/drm/
|
|||||||
|
|
||||||
INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
|
INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
|
||||||
M: Daniel Vetter <daniel.vetter@ffwll.ch>
|
M: Daniel Vetter <daniel.vetter@ffwll.ch>
|
||||||
L: intel-gfx@lists.freedesktop.org (subscribers-only)
|
L: intel-gfx@lists.freedesktop.org
|
||||||
L: dri-devel@lists.freedesktop.org
|
L: dri-devel@lists.freedesktop.org
|
||||||
T: git git://people.freedesktop.org/~danvet/drm-intel
|
T: git git://people.freedesktop.org/~danvet/drm-intel
|
||||||
S: Supported
|
S: Supported
|
||||||
@@ -3067,12 +3062,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git
|
|||||||
F: drivers/video/s1d13xxxfb.c
|
F: drivers/video/s1d13xxxfb.c
|
||||||
F: include/video/s1d13xxxfb.h
|
F: include/video/s1d13xxxfb.h
|
||||||
|
|
||||||
ETHEREXPRESS-16 NETWORK DRIVER
|
|
||||||
M: Philip Blundell <philb@gnu.org>
|
|
||||||
L: netdev@vger.kernel.org
|
|
||||||
S: Maintained
|
|
||||||
F: drivers/net/ethernet/i825xx/eexpress.*
|
|
||||||
|
|
||||||
ETHERNET BRIDGE
|
ETHERNET BRIDGE
|
||||||
M: Stephen Hemminger <stephen@networkplumber.org>
|
M: Stephen Hemminger <stephen@networkplumber.org>
|
||||||
L: bridge@lists.linux-foundation.org
|
L: bridge@lists.linux-foundation.org
|
||||||
@@ -3260,6 +3249,12 @@ F: Documentation/firmware_class/
|
|||||||
F: drivers/base/firmware*.c
|
F: drivers/base/firmware*.c
|
||||||
F: include/linux/firmware.h
|
F: include/linux/firmware.h
|
||||||
|
|
||||||
|
FLASHSYSTEM DRIVER (IBM FlashSystem 70/80 PCI SSD Flash Card)
|
||||||
|
M: Joshua Morris <josh.h.morris@us.ibm.com>
|
||||||
|
M: Philip Kelleher <pjk1939@linux.vnet.ibm.com>
|
||||||
|
S: Maintained
|
||||||
|
F: drivers/block/rsxx/
|
||||||
|
|
||||||
FLOPPY DRIVER
|
FLOPPY DRIVER
|
||||||
M: Jiri Kosina <jkosina@suse.cz>
|
M: Jiri Kosina <jkosina@suse.cz>
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/floppy.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/floppy.git
|
||||||
@@ -3520,7 +3515,7 @@ F: drivers/isdn/gigaset/
|
|||||||
F: include/uapi/linux/gigaset_dev.h
|
F: include/uapi/linux/gigaset_dev.h
|
||||||
|
|
||||||
GPIO SUBSYSTEM
|
GPIO SUBSYSTEM
|
||||||
M: Grant Likely <grant.likely@secretlab.ca>
|
M: Grant Likely <grant.likely@linaro.org>
|
||||||
M: Linus Walleij <linus.walleij@linaro.org>
|
M: Linus Walleij <linus.walleij@linaro.org>
|
||||||
S: Maintained
|
S: Maintained
|
||||||
T: git git://git.secretlab.ca/git/linux-2.6.git
|
T: git git://git.secretlab.ca/git/linux-2.6.git
|
||||||
@@ -3869,7 +3864,7 @@ F: drivers/i2c/busses/i2c-ismt.c
|
|||||||
F: Documentation/i2c/busses/i2c-ismt
|
F: Documentation/i2c/busses/i2c-ismt
|
||||||
|
|
||||||
I2C/SMBUS STUB DRIVER
|
I2C/SMBUS STUB DRIVER
|
||||||
M: "Mark M. Hoffman" <mhoffman@lightlink.com>
|
M: Jean Delvare <khali@linux-fr.org>
|
||||||
L: linux-i2c@vger.kernel.org
|
L: linux-i2c@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/i2c/i2c-stub.c
|
F: drivers/i2c/i2c-stub.c
|
||||||
@@ -4023,6 +4018,22 @@ M: Stanislaw Gruszka <stf_xl@wp.pl>
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/usb/atm/ueagle-atm.c
|
F: drivers/usb/atm/ueagle-atm.c
|
||||||
|
|
||||||
|
INA209 HARDWARE MONITOR DRIVER
|
||||||
|
M: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
L: lm-sensors@lm-sensors.org
|
||||||
|
S: Maintained
|
||||||
|
F: Documentation/hwmon/ina209
|
||||||
|
F: Documentation/devicetree/bindings/i2c/ina209.txt
|
||||||
|
F: drivers/hwmon/ina209.c
|
||||||
|
|
||||||
|
INA2XX HARDWARE MONITOR DRIVER
|
||||||
|
M: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
L: lm-sensors@lm-sensors.org
|
||||||
|
S: Maintained
|
||||||
|
F: Documentation/hwmon/ina2xx
|
||||||
|
F: drivers/hwmon/ina2xx.c
|
||||||
|
F: include/linux/platform_data/ina2xx.h
|
||||||
|
|
||||||
INDUSTRY PACK SUBSYSTEM (IPACK)
|
INDUSTRY PACK SUBSYSTEM (IPACK)
|
||||||
M: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
|
M: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
|
||||||
M: Jens Taprogge <jens.taprogge@taprogge.org>
|
M: Jens Taprogge <jens.taprogge@taprogge.org>
|
||||||
@@ -4337,7 +4348,7 @@ F: drivers/irqchip/
|
|||||||
|
|
||||||
IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
|
IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY)
|
||||||
M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
||||||
M: Grant Likely <grant.likely@secretlab.ca>
|
M: Grant Likely <grant.likely@linaro.org>
|
||||||
T: git git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
|
T: git git://git.secretlab.ca/git/linux-2.6.git irqdomain/next
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/IRQ-domain.txt
|
F: Documentation/IRQ-domain.txt
|
||||||
@@ -4824,11 +4835,8 @@ F: arch/powerpc/platforms/40x/
|
|||||||
F: arch/powerpc/platforms/44x/
|
F: arch/powerpc/platforms/44x/
|
||||||
|
|
||||||
LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
|
LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
|
||||||
M: Grant Likely <grant.likely@secretlab.ca>
|
|
||||||
W: http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
|
|
||||||
L: linuxppc-dev@lists.ozlabs.org
|
L: linuxppc-dev@lists.ozlabs.org
|
||||||
T: git git://git.secretlab.ca/git/linux-2.6.git
|
S: Unmaintained
|
||||||
S: Maintained
|
|
||||||
F: arch/powerpc/*/*virtex*
|
F: arch/powerpc/*/*virtex*
|
||||||
F: arch/powerpc/*/*/*virtex*
|
F: arch/powerpc/*/*/*virtex*
|
||||||
|
|
||||||
@@ -4937,6 +4945,12 @@ W: logfs.org
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: fs/logfs/
|
F: fs/logfs/
|
||||||
|
|
||||||
|
LPC32XX MACHINE SUPPORT
|
||||||
|
M: Roland Stigge <stigge@antcom.de>
|
||||||
|
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||||
|
S: Maintained
|
||||||
|
F: arch/arm/mach-lpc32xx/
|
||||||
|
|
||||||
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
|
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
|
||||||
M: Nagalakshmi Nandigama <Nagalakshmi.Nandigama@lsi.com>
|
M: Nagalakshmi Nandigama <Nagalakshmi.Nandigama@lsi.com>
|
||||||
M: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
|
M: Sreekanth Reddy <Sreekanth.Reddy@lsi.com>
|
||||||
@@ -5061,9 +5075,8 @@ S: Maintained
|
|||||||
F: drivers/net/ethernet/marvell/sk*
|
F: drivers/net/ethernet/marvell/sk*
|
||||||
|
|
||||||
MARVELL LIBERTAS WIRELESS DRIVER
|
MARVELL LIBERTAS WIRELESS DRIVER
|
||||||
M: Dan Williams <dcbw@redhat.com>
|
|
||||||
L: libertas-dev@lists.infradead.org
|
L: libertas-dev@lists.infradead.org
|
||||||
S: Maintained
|
S: Orphan
|
||||||
F: drivers/net/wireless/libertas/
|
F: drivers/net/wireless/libertas/
|
||||||
|
|
||||||
MARVELL MV643XX ETHERNET DRIVER
|
MARVELL MV643XX ETHERNET DRIVER
|
||||||
@@ -5116,6 +5129,15 @@ S: Maintained
|
|||||||
F: Documentation/hwmon/max6650
|
F: Documentation/hwmon/max6650
|
||||||
F: drivers/hwmon/max6650.c
|
F: drivers/hwmon/max6650.c
|
||||||
|
|
||||||
|
MAX6697 HARDWARE MONITOR DRIVER
|
||||||
|
M: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
L: lm-sensors@lm-sensors.org
|
||||||
|
S: Maintained
|
||||||
|
F: Documentation/hwmon/max6697
|
||||||
|
F: Documentation/devicetree/bindings/i2c/max6697.txt
|
||||||
|
F: drivers/hwmon/max6697.c
|
||||||
|
F: include/linux/platform_data/max6697.h
|
||||||
|
|
||||||
MAXIRADIO FM RADIO RECEIVER DRIVER
|
MAXIRADIO FM RADIO RECEIVER DRIVER
|
||||||
M: Hans Verkuil <hverkuil@xs4all.nl>
|
M: Hans Verkuil <hverkuil@xs4all.nl>
|
||||||
L: linux-media@vger.kernel.org
|
L: linux-media@vger.kernel.org
|
||||||
@@ -5394,6 +5416,13 @@ L: linux-scsi@vger.kernel.org
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/scsi/NCR_D700.*
|
F: drivers/scsi/NCR_D700.*
|
||||||
|
|
||||||
|
NCT6775 HARDWARE MONITOR DRIVER
|
||||||
|
M: Guenter Roeck <linux@roeck-us.net>
|
||||||
|
L: lm-sensors@lm-sensors.org
|
||||||
|
S: Maintained
|
||||||
|
F: Documentation/hwmon/nct6775
|
||||||
|
F: drivers/hwmon/nct6775.c
|
||||||
|
|
||||||
NETEFFECT IWARP RNIC DRIVER (IW_NES)
|
NETEFFECT IWARP RNIC DRIVER (IW_NES)
|
||||||
M: Faisal Latif <faisal.latif@intel.com>
|
M: Faisal Latif <faisal.latif@intel.com>
|
||||||
L: linux-rdma@vger.kernel.org
|
L: linux-rdma@vger.kernel.org
|
||||||
@@ -5556,6 +5585,7 @@ F: include/uapi/linux/if_*
|
|||||||
F: include/uapi/linux/netdevice.h
|
F: include/uapi/linux/netdevice.h
|
||||||
|
|
||||||
NETXEN (1/10) GbE SUPPORT
|
NETXEN (1/10) GbE SUPPORT
|
||||||
|
M: Manish Chopra <manish.chopra@qlogic.com>
|
||||||
M: Sony Chacko <sony.chacko@qlogic.com>
|
M: Sony Chacko <sony.chacko@qlogic.com>
|
||||||
M: Rajesh Borundia <rajesh.borundia@qlogic.com>
|
M: Rajesh Borundia <rajesh.borundia@qlogic.com>
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
@@ -5640,6 +5670,14 @@ S: Maintained
|
|||||||
F: drivers/video/riva/
|
F: drivers/video/riva/
|
||||||
F: drivers/video/nvidia/
|
F: drivers/video/nvidia/
|
||||||
|
|
||||||
|
NVM EXPRESS DRIVER
|
||||||
|
M: Matthew Wilcox <willy@linux.intel.com>
|
||||||
|
L: linux-nvme@lists.infradead.org
|
||||||
|
T: git git://git.infradead.org/users/willy/linux-nvme.git
|
||||||
|
S: Supported
|
||||||
|
F: drivers/block/nvme.c
|
||||||
|
F: include/linux/nvme.h
|
||||||
|
|
||||||
OMAP SUPPORT
|
OMAP SUPPORT
|
||||||
M: Tony Lindgren <tony@atomide.com>
|
M: Tony Lindgren <tony@atomide.com>
|
||||||
L: linux-omap@vger.kernel.org
|
L: linux-omap@vger.kernel.org
|
||||||
@@ -5668,7 +5706,7 @@ S: Maintained
|
|||||||
F: arch/arm/*omap*/*clock*
|
F: arch/arm/*omap*/*clock*
|
||||||
|
|
||||||
OMAP POWER MANAGEMENT SUPPORT
|
OMAP POWER MANAGEMENT SUPPORT
|
||||||
M: Kevin Hilman <khilman@ti.com>
|
M: Kevin Hilman <khilman@deeprootsystems.com>
|
||||||
L: linux-omap@vger.kernel.org
|
L: linux-omap@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: arch/arm/*omap*/*pm*
|
F: arch/arm/*omap*/*pm*
|
||||||
@@ -5762,7 +5800,7 @@ F: arch/arm/*omap*/usb*
|
|||||||
|
|
||||||
OMAP GPIO DRIVER
|
OMAP GPIO DRIVER
|
||||||
M: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
M: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
||||||
M: Kevin Hilman <khilman@ti.com>
|
M: Kevin Hilman <khilman@deeprootsystems.com>
|
||||||
L: linux-omap@vger.kernel.org
|
L: linux-omap@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/gpio/gpio-omap.c
|
F: drivers/gpio/gpio-omap.c
|
||||||
@@ -5816,7 +5854,7 @@ F: Documentation/i2c/busses/i2c-ocores
|
|||||||
F: drivers/i2c/busses/i2c-ocores.c
|
F: drivers/i2c/busses/i2c-ocores.c
|
||||||
|
|
||||||
OPEN FIRMWARE AND FLATTENED DEVICE TREE
|
OPEN FIRMWARE AND FLATTENED DEVICE TREE
|
||||||
M: Grant Likely <grant.likely@secretlab.ca>
|
M: Grant Likely <grant.likely@linaro.org>
|
||||||
M: Rob Herring <rob.herring@calxeda.com>
|
M: Rob Herring <rob.herring@calxeda.com>
|
||||||
L: devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers)
|
L: devicetree-discuss@lists.ozlabs.org (moderated for non-subscribers)
|
||||||
W: http://fdt.secretlab.ca
|
W: http://fdt.secretlab.ca
|
||||||
@@ -6194,7 +6232,7 @@ F: include/linux/power_supply.h
|
|||||||
F: drivers/power/
|
F: drivers/power/
|
||||||
|
|
||||||
PNP SUPPORT
|
PNP SUPPORT
|
||||||
M: Adam Belay <abelay@mit.edu>
|
M: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
||||||
M: Bjorn Helgaas <bhelgaas@google.com>
|
M: Bjorn Helgaas <bhelgaas@google.com>
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/pnp/
|
F: drivers/pnp/
|
||||||
@@ -6430,6 +6468,8 @@ F: Documentation/networking/LICENSE.qla3xxx
|
|||||||
F: drivers/net/ethernet/qlogic/qla3xxx.*
|
F: drivers/net/ethernet/qlogic/qla3xxx.*
|
||||||
|
|
||||||
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
|
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
|
||||||
|
M: Rajesh Borundia <rajesh.borundia@qlogic.com>
|
||||||
|
M: Shahed Shaikh <shahed.shaikh@qlogic.com>
|
||||||
M: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
|
M: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
|
||||||
M: Sony Chacko <sony.chacko@qlogic.com>
|
M: Sony Chacko <sony.chacko@qlogic.com>
|
||||||
M: linux-driver@qlogic.com
|
M: linux-driver@qlogic.com
|
||||||
@@ -6534,12 +6574,6 @@ S: Maintained
|
|||||||
F: Documentation/blockdev/ramdisk.txt
|
F: Documentation/blockdev/ramdisk.txt
|
||||||
F: drivers/block/brd.c
|
F: drivers/block/brd.c
|
||||||
|
|
||||||
RAMSAM DRIVER (IBM RamSan 70/80 PCI SSD Flash Card)
|
|
||||||
M: Joshua Morris <josh.h.morris@us.ibm.com>
|
|
||||||
M: Philip Kelleher <pjk1939@linux.vnet.ibm.com>
|
|
||||||
S: Maintained
|
|
||||||
F: drivers/block/rsxx/
|
|
||||||
|
|
||||||
RANDOM NUMBER DRIVER
|
RANDOM NUMBER DRIVER
|
||||||
M: Theodore Ts'o" <tytso@mit.edu>
|
M: Theodore Ts'o" <tytso@mit.edu>
|
||||||
S: Maintained
|
S: Maintained
|
||||||
@@ -6608,7 +6642,7 @@ S: Supported
|
|||||||
F: fs/reiserfs/
|
F: fs/reiserfs/
|
||||||
|
|
||||||
REGISTER MAP ABSTRACTION
|
REGISTER MAP ABSTRACTION
|
||||||
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
M: Mark Brown <broonie@kernel.org>
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
|
||||||
S: Supported
|
S: Supported
|
||||||
F: drivers/base/regmap/
|
F: drivers/base/regmap/
|
||||||
@@ -6934,7 +6968,6 @@ F: drivers/scsi/st*
|
|||||||
|
|
||||||
SCTP PROTOCOL
|
SCTP PROTOCOL
|
||||||
M: Vlad Yasevich <vyasevich@gmail.com>
|
M: Vlad Yasevich <vyasevich@gmail.com>
|
||||||
M: Sridhar Samudrala <sri@us.ibm.com>
|
|
||||||
M: Neil Horman <nhorman@tuxdriver.com>
|
M: Neil Horman <nhorman@tuxdriver.com>
|
||||||
L: linux-sctp@vger.kernel.org
|
L: linux-sctp@vger.kernel.org
|
||||||
W: http://lksctp.sourceforge.net
|
W: http://lksctp.sourceforge.net
|
||||||
@@ -7156,7 +7189,7 @@ F: arch/arm/mach-s3c2410/bast-irq.c
|
|||||||
|
|
||||||
TI DAVINCI MACHINE SUPPORT
|
TI DAVINCI MACHINE SUPPORT
|
||||||
M: Sekhar Nori <nsekhar@ti.com>
|
M: Sekhar Nori <nsekhar@ti.com>
|
||||||
M: Kevin Hilman <khilman@ti.com>
|
M: Kevin Hilman <khilman@deeprootsystems.com>
|
||||||
L: davinci-linux-open-source@linux.davincidsp.com (moderated for non-subscribers)
|
L: davinci-linux-open-source@linux.davincidsp.com (moderated for non-subscribers)
|
||||||
T: git git://gitorious.org/linux-davinci/linux-davinci.git
|
T: git git://gitorious.org/linux-davinci/linux-davinci.git
|
||||||
Q: http://patchwork.kernel.org/project/linux-davinci/list/
|
Q: http://patchwork.kernel.org/project/linux-davinci/list/
|
||||||
@@ -7189,13 +7222,6 @@ L: netdev@vger.kernel.org
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/net/ethernet/sis/sis900.*
|
F: drivers/net/ethernet/sis/sis900.*
|
||||||
|
|
||||||
SIS 96X I2C/SMBUS DRIVER
|
|
||||||
M: "Mark M. Hoffman" <mhoffman@lightlink.com>
|
|
||||||
L: linux-i2c@vger.kernel.org
|
|
||||||
S: Maintained
|
|
||||||
F: Documentation/i2c/busses/i2c-sis96x
|
|
||||||
F: drivers/i2c/busses/i2c-sis96x.c
|
|
||||||
|
|
||||||
SIS FRAMEBUFFER DRIVER
|
SIS FRAMEBUFFER DRIVER
|
||||||
M: Thomas Winischhofer <thomas@winischhofer.net>
|
M: Thomas Winischhofer <thomas@winischhofer.net>
|
||||||
W: http://www.winischhofer.net/linuxsisvga.shtml
|
W: http://www.winischhofer.net/linuxsisvga.shtml
|
||||||
@@ -7273,7 +7299,7 @@ F: Documentation/hwmon/sch5627
|
|||||||
F: drivers/hwmon/sch5627.c
|
F: drivers/hwmon/sch5627.c
|
||||||
|
|
||||||
SMSC47B397 HARDWARE MONITOR DRIVER
|
SMSC47B397 HARDWARE MONITOR DRIVER
|
||||||
M: "Mark M. Hoffman" <mhoffman@lightlink.com>
|
M: Jean Delvare <khali@linux-fr.org>
|
||||||
L: lm-sensors@lm-sensors.org
|
L: lm-sensors@lm-sensors.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/hwmon/smsc47b397
|
F: Documentation/hwmon/smsc47b397
|
||||||
@@ -7364,7 +7390,7 @@ F: sound/
|
|||||||
|
|
||||||
SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC)
|
SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEMENT (ASoC)
|
||||||
M: Liam Girdwood <lgirdwood@gmail.com>
|
M: Liam Girdwood <lgirdwood@gmail.com>
|
||||||
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
M: Mark Brown <broonie@kernel.org>
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
|
||||||
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
|
||||||
W: http://alsa-project.org/main/index.php/ASoC
|
W: http://alsa-project.org/main/index.php/ASoC
|
||||||
@@ -7452,11 +7478,11 @@ S: Maintained
|
|||||||
F: drivers/clk/spear/
|
F: drivers/clk/spear/
|
||||||
|
|
||||||
SPI SUBSYSTEM
|
SPI SUBSYSTEM
|
||||||
M: Grant Likely <grant.likely@secretlab.ca>
|
M: Mark Brown <broonie@kernel.org>
|
||||||
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
M: Grant Likely <grant.likely@linaro.org>
|
||||||
L: spi-devel-general@lists.sourceforge.net
|
L: spi-devel-general@lists.sourceforge.net
|
||||||
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
|
||||||
Q: http://patchwork.kernel.org/project/spi-devel-general/list/
|
Q: http://patchwork.kernel.org/project/spi-devel-general/list/
|
||||||
T: git git://git.secretlab.ca/git/linux-2.6.git
|
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: Documentation/spi/
|
F: Documentation/spi/
|
||||||
F: drivers/spi/
|
F: drivers/spi/
|
||||||
@@ -7696,9 +7722,10 @@ F: include/linux/swiotlb.h
|
|||||||
|
|
||||||
SYNOPSYS ARC ARCHITECTURE
|
SYNOPSYS ARC ARCHITECTURE
|
||||||
M: Vineet Gupta <vgupta@synopsys.com>
|
M: Vineet Gupta <vgupta@synopsys.com>
|
||||||
L: linux-snps-arc@vger.kernel.org
|
|
||||||
S: Supported
|
S: Supported
|
||||||
F: arch/arc/
|
F: arch/arc/
|
||||||
|
F: Documentation/devicetree/bindings/arc/
|
||||||
|
F: drivers/tty/serial/arc-uart.c
|
||||||
|
|
||||||
SYSV FILESYSTEM
|
SYSV FILESYSTEM
|
||||||
M: Christoph Hellwig <hch@infradead.org>
|
M: Christoph Hellwig <hch@infradead.org>
|
||||||
@@ -7866,7 +7893,7 @@ L: linux-tegra@vger.kernel.org
|
|||||||
Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
|
Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
|
||||||
S: Supported
|
S: Supported
|
||||||
K: (?i)[^a-z]tegra
|
N: [^a-z]tegra
|
||||||
|
|
||||||
TEHUTI ETHERNET DRIVER
|
TEHUTI ETHERNET DRIVER
|
||||||
M: Andy Gospodarek <andy@greyhouse.net>
|
M: Andy Gospodarek <andy@greyhouse.net>
|
||||||
@@ -7909,6 +7936,12 @@ T: git git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
|
|||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/platform/x86/thinkpad_acpi.c
|
F: drivers/platform/x86/thinkpad_acpi.c
|
||||||
|
|
||||||
|
TI BANDGAP AND THERMAL DRIVER
|
||||||
|
M: Eduardo Valentin <eduardo.valentin@ti.com>
|
||||||
|
L: linux-pm@vger.kernel.org
|
||||||
|
S: Maintained
|
||||||
|
F: drivers/staging/omap-thermal/
|
||||||
|
|
||||||
TI FLASH MEDIA INTERFACE DRIVER
|
TI FLASH MEDIA INTERFACE DRIVER
|
||||||
M: Alex Dubov <oakad@yahoo.com>
|
M: Alex Dubov <oakad@yahoo.com>
|
||||||
S: Maintained
|
S: Maintained
|
||||||
@@ -8346,9 +8379,10 @@ S: Maintained
|
|||||||
F: drivers/usb/serial/option.c
|
F: drivers/usb/serial/option.c
|
||||||
|
|
||||||
USB PEGASUS DRIVER
|
USB PEGASUS DRIVER
|
||||||
M: Petko Manolov <petkan@users.sourceforge.net>
|
M: Petko Manolov <petkan@nucleusys.com>
|
||||||
L: linux-usb@vger.kernel.org
|
L: linux-usb@vger.kernel.org
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
|
T: git git://git.code.sf.net/p/pegasus2/git
|
||||||
W: http://pegasus2.sourceforge.net/
|
W: http://pegasus2.sourceforge.net/
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/net/usb/pegasus.*
|
F: drivers/net/usb/pegasus.*
|
||||||
@@ -8368,9 +8402,10 @@ S: Supported
|
|||||||
F: drivers/usb/class/usblp.c
|
F: drivers/usb/class/usblp.c
|
||||||
|
|
||||||
USB RTL8150 DRIVER
|
USB RTL8150 DRIVER
|
||||||
M: Petko Manolov <petkan@users.sourceforge.net>
|
M: Petko Manolov <petkan@nucleusys.com>
|
||||||
L: linux-usb@vger.kernel.org
|
L: linux-usb@vger.kernel.org
|
||||||
L: netdev@vger.kernel.org
|
L: netdev@vger.kernel.org
|
||||||
|
T: git git://git.code.sf.net/p/pegasus2/git
|
||||||
W: http://pegasus2.sourceforge.net/
|
W: http://pegasus2.sourceforge.net/
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/net/usb/rtl8150.c
|
F: drivers/net/usb/rtl8150.c
|
||||||
@@ -8696,8 +8731,8 @@ F: drivers/scsi/vmw_pvscsi.c
|
|||||||
F: drivers/scsi/vmw_pvscsi.h
|
F: drivers/scsi/vmw_pvscsi.h
|
||||||
|
|
||||||
VOLTAGE AND CURRENT REGULATOR FRAMEWORK
|
VOLTAGE AND CURRENT REGULATOR FRAMEWORK
|
||||||
M: Liam Girdwood <lrg@ti.com>
|
M: Liam Girdwood <lgirdwood@gmail.com>
|
||||||
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
M: Mark Brown <broonie@kernel.org>
|
||||||
W: http://opensource.wolfsonmicro.com/node/15
|
W: http://opensource.wolfsonmicro.com/node/15
|
||||||
W: http://www.slimlogic.co.uk/?p=48
|
W: http://www.slimlogic.co.uk/?p=48
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lrg/regulator.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lrg/regulator.git
|
||||||
@@ -8960,9 +8995,7 @@ S: Maintained
|
|||||||
F: drivers/net/ethernet/xilinx/xilinx_axienet*
|
F: drivers/net/ethernet/xilinx/xilinx_axienet*
|
||||||
|
|
||||||
XILINX SYSTEMACE DRIVER
|
XILINX SYSTEMACE DRIVER
|
||||||
M: Grant Likely <grant.likely@secretlab.ca>
|
S: Unmaintained
|
||||||
W: http://www.secretlab.ca/
|
|
||||||
S: Maintained
|
|
||||||
F: drivers/block/xsysace.c
|
F: drivers/block/xsysace.c
|
||||||
|
|
||||||
XILINX UARTLITE SERIAL DRIVER
|
XILINX UARTLITE SERIAL DRIVER
|
||||||
|
9
Makefile
9
Makefile
@@ -1,7 +1,7 @@
|
|||||||
VERSION = 3
|
VERSION = 3
|
||||||
PATCHLEVEL = 9
|
PATCHLEVEL = 9
|
||||||
SUBLEVEL = 0
|
SUBLEVEL = 0
|
||||||
EXTRAVERSION = -rc1
|
EXTRAVERSION =
|
||||||
NAME = Unicycling Gorilla
|
NAME = Unicycling Gorilla
|
||||||
|
|
||||||
# *DOCUMENTATION*
|
# *DOCUMENTATION*
|
||||||
@@ -513,7 +513,8 @@ ifeq ($(KBUILD_EXTMOD),)
|
|||||||
# Carefully list dependencies so we do not try to build scripts twice
|
# Carefully list dependencies so we do not try to build scripts twice
|
||||||
# in parallel
|
# in parallel
|
||||||
PHONY += scripts
|
PHONY += scripts
|
||||||
scripts: scripts_basic include/config/auto.conf include/config/tristate.conf
|
scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
|
||||||
|
asm-generic
|
||||||
$(Q)$(MAKE) $(build)=$(@)
|
$(Q)$(MAKE) $(build)=$(@)
|
||||||
|
|
||||||
# Objects we will link into vmlinux / subdirs we need to visit
|
# Objects we will link into vmlinux / subdirs we need to visit
|
||||||
@@ -1331,11 +1332,11 @@ kernelversion:
|
|||||||
# Clear a bunch of variables before executing the submake
|
# Clear a bunch of variables before executing the submake
|
||||||
tools/: FORCE
|
tools/: FORCE
|
||||||
$(Q)mkdir -p $(objtree)/tools
|
$(Q)mkdir -p $(objtree)/tools
|
||||||
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS= O=$(objtree) subdir=tools -C $(src)/tools/
|
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(objtree) subdir=tools -C $(src)/tools/
|
||||||
|
|
||||||
tools/%: FORCE
|
tools/%: FORCE
|
||||||
$(Q)mkdir -p $(objtree)/tools
|
$(Q)mkdir -p $(objtree)/tools
|
||||||
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS= O=$(objtree) subdir=tools -C $(src)/tools/ $*
|
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(objtree) subdir=tools -C $(src)/tools/ $*
|
||||||
|
|
||||||
# Single targets
|
# Single targets
|
||||||
# ---------------------------------------------------------------------------
|
# ---------------------------------------------------------------------------
|
||||||
|
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user