openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity

Omap fixes and minor defconfig updates that would be good to 

get in before -rc1.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIcBAABAgAGBQJR3RSDAAoJEBvUPslcq6Vz6rAQAK16H8VJB9l8pEzJGDS7/X0j
 8N+j1Zry0Ij0ZHQpzqR71h8Sh72PfdIVFnT6b04cJgBON92dmXqiBNv1pdIHRPlC
 DGyQ0W+vucF38iXRqSa7koxpEM8RRQcS4kJ3wUkvBwWA6s1x+MB/J5qtRkYg6iKI
 GPcBjIdh1pjBSLq37sCLQcSGxKHNH19i47KcN8C6piqiKNxnoDyVZKLAAt0jZNxe
 SrezGdz0keADDf/7/30TAjDBgY1LlWog6M9Ue6D6FO1YwFegWgM7XX3GsZfuhZ4s
 +zssE73UJETauOl7JJ+nsn8GDm2Q6U8zVm1pU9GEezm0pMCTJ2SDhtoxWY5zR/mH
 rYh8ia8IrMlX4mvQbKFhTZH3LWxLlGEJC21sCf5U3KuXv39SJlIjX9Qa/erWpMxd
 9McTyTWL7I6fXuMsuSUjdawvODem3kUXmwANNyMA1/NZ6uAMqK60l+/yLLjJRdFh
 jdFSeZ976ARp52TFqaf47KN3Jc5jJs5NVQ191JaoTxwWmgvaX0mcG8iKO7oaE+1y
 fR096Mt3jobMAbiQUdDnetkNBEiJ8uSJq4Y5IecvshAuPxu71eEB6OCdYQqmUfRo
 Nq8zPGmPKwT8rhCc2B3Paw++uI74f+S0WgsodGsDiBeFHzFztBY4PWKrXfxr9zzY
 01kscgUWM3MJ8xRWtVE+
 =kO4u
 -----END PGP SIGNATURE-----

Merge tag 'omap-for-v3.11/fixes-for-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes

Omap fixes and minor defconfig updates that would be good to
get in before -rc1.

* tag 'omap-for-v3.11/fixes-for-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: omap2plus_defconfig: Enable appended DTB support
  ARM: OMAP2+: Enable TI_EDMA in omap2plus_defconfig
  ARM: OMAP2+: omap2plus_defconfig: enable DRA752 thermal support by default
  ARM: OMAP2+: omap2plus_defconfig: enable TI bandgap driver
  ARM: OMAP2+: devices: remove duplicated include from devices.c
  ARM: OMAP3: igep0020: Set DSS pins in correct mux mode.
  ARM: OMAP2+: N900: enable N900-specific drivers even if device tree is enabled
  ARM: OMAP2+: Cocci spatch "ptr_ret.spatch"
  ARM: OMAP2+: Remove obsolete Makefile line
  ARM: OMAP5: Enable Cortex A15 errata 798181
  ARM: scu: provide inline dummy functions when SCU is not present
  ARM: OMAP4: sleep: build OMAP4 specific functions only for OMAP4
  ARM: OMAP2+: timer: initialize before using oh_name

Signed-off-by: Olof Johansson <olof@lixom.net>

Add/move/change conflicts in arch/arm/mach-omap2/Kconfig resolved.
This commit is contained in:
Olof Johansson 2013-07-12 10:59:39 -07:00
parent 9d8812df35 c24a6ae18a
commit f4b96f5e4f
2265 changed files with 74056 additions and 30383 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
Documentation/ABI/testing/sysfs-bus-acpi Normal file
View File

@ -0,0 +1,58 @@
What: /sys/bus/acpi/devices/.../path
Date: December 2006
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute indicates the full path of ACPI namespace
object associated with the device object. For example,
\_SB_.PCI0.
This file is not present for device objects representing
fixed ACPI hardware features (like power and sleep
buttons).
What: /sys/bus/acpi/devices/.../modalias
Date: July 2007
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute indicates the PNP IDs of the device object.
That is acpi:HHHHHHHH:[CCCCCCC:]. Where each HHHHHHHH or
CCCCCCCC contains device object's PNPID (_HID or _CID).
What: /sys/bus/acpi/devices/.../hid
Date: April 2005
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute indicates the hardware ID (_HID) of the
device object. For example, PNP0103.
This file is present for device objects having the _HID
control method.
What: /sys/bus/acpi/devices/.../description
Date: October 2012
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute contains the output of the device object's
_STR control method, if present.
What: /sys/bus/acpi/devices/.../adr
Date: October 2012
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute contains the output of the device object's
_ADR control method, which is present for ACPI device
objects representing devices having standard enumeration
algorithms, such as PCI.
What: /sys/bus/acpi/devices/.../uid
Date: October 2012
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute contains the output of the device object's
_UID control method, if present.
What: /sys/bus/acpi/devices/.../eject
Date: December 2006
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
Writing 1 to this attribute will trigger hot removal of
this device object. This file exists for every device
object that has _EJ0 method.

32
Documentation/ABI/testing/sysfs-bus-event_source-devices-events
View File

@ -27,14 +27,36 @@ Description: Generic performance monitoring events
"basename".
What: /sys/devices/cpu/events/PM_LD_MISS_L1
/sys/devices/cpu/events/PM_LD_REF_L1
/sys/devices/cpu/events/PM_CYC
What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
/sys/devices/cpu/events/PM_BRU_FIN
/sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
/sys/devices/cpu/events/PM_BRU_MPRED
/sys/devices/cpu/events/PM_INST_CMPL
/sys/devices/cpu/events/PM_CMPLU_STALL
/sys/devices/cpu/events/PM_CMPLU_STALL_BRU
/sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS
/sys/devices/cpu/events/PM_CMPLU_STALL_DFU
/sys/devices/cpu/events/PM_CMPLU_STALL_DIV
/sys/devices/cpu/events/PM_CMPLU_STALL_ERAT_MISS
/sys/devices/cpu/events/PM_CMPLU_STALL_FXU
/sys/devices/cpu/events/PM_CMPLU_STALL_IFU
/sys/devices/cpu/events/PM_CMPLU_STALL_LSU
/sys/devices/cpu/events/PM_CMPLU_STALL_REJECT
/sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR
/sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR_LONG
/sys/devices/cpu/events/PM_CMPLU_STALL_STORE
/sys/devices/cpu/events/PM_CMPLU_STALL_THRD
/sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR
/sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR_LONG
/sys/devices/cpu/events/PM_CYC
/sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED
/sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED_IC_MISS
/sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
/sys/devices/cpu/events/PM_GCT_NOSLOT_IC_MISS
/sys/devices/cpu/events/PM_GRP_CMPL
/sys/devices/cpu/events/PM_INST_CMPL
/sys/devices/cpu/events/PM_LD_MISS_L1
/sys/devices/cpu/events/PM_LD_REF_L1
/sys/devices/cpu/events/PM_RUN_CYC
/sys/devices/cpu/events/PM_RUN_INST_CMPL
Date: 2013/01/08

6
Documentation/ABI/testing/sysfs-bus-event_source-devices-format
View File

@ -9,6 +9,12 @@ Description:
we want to export, so that userspace can deal with sane
name/value pairs.
Userspace must be prepared for the possibility that attributes
define overlapping bit ranges. For example:
attr1 = 'config:0-23'
attr2 = 'config:0-7'
attr3 = 'config:12-35'
Example: 'config1:1,6-10,44'
Defines contents of attribute that occupies bits 1,6-10,44 of
perf_event_attr::config1.

20
Documentation/ABI/testing/sysfs-class-devfreq
View File

@ -78,3 +78,23 @@ Contact: Nishanth Menon <nm@ti.com>
Description:
The /sys/class/devfreq/.../available_governors shows
currently available governors in the system.
What: /sys/class/devfreq/.../min_freq
Date: January 2013
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../min_freq shows and stores
the minimum frequency requested by users. It is 0 if
the user does not care. min_freq overrides the
frequency requested by governors.
What: /sys/class/devfreq/.../max_freq
Date: January 2013
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../max_freq shows and stores
the maximum frequency requested by users. It is 0 if
the user does not care. max_freq overrides the
frequency requested by governors and min_freq.
The max_freq overrides min_freq because max_freq may be
used to throttle devices to avoid overheating.

20
Documentation/ABI/testing/sysfs-devices-online Normal file
View File

@ -0,0 +1,20 @@
What: /sys/devices/.../online
Date: April 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../online attribute is only present for
devices whose bus types provide .online() and .offline()
callbacks. The number read from it (0 or 1) reflects the value
of the device's 'offline' field. If that number is 1 and '0'
(or 'n', or 'N') is written to this file, the device bus type's
.offline() callback is executed for the device and (if
successful) its 'offline' field is updated accordingly. In
turn, if that number is 0 and '1' (or 'y', or 'Y') is written to
this file, the device bus type's .online() callback is executed
for the device and (if successful) its 'offline' field is
updated as appropriate.
After a successful execution of the bus type's .offline()
callback the device cannot be used for any purpose until either
it is removed (i.e. device_del() is called for it), or its bus
type's .online() is exeucted successfully.

2
Documentation/ABI/testing/sysfs-devices-sun
View File

@ -1,4 +1,4 @@
Whatt: /sys/devices/.../sun
What: /sys/devices/.../sun
Date: October 2012
Contact: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Description:

15
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -144,6 +144,21 @@ Description: Discover and change clock speed of CPUs
to learn how to control the knobs.
What: /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus
Date: June 2013
Contact: cpufreq@vger.kernel.org
Description: Discover CPUs in the same CPU frequency coordination domain
freqdomain_cpus is the list of CPUs (online+offline) that share
the same clock/freq domain (possibly at the hardware level).
That information may be hidden from the cpufreq core and the
value of related_cpus may be different from freqdomain_cpus. This
attribute is useful for user space DVFS controllers to get better
power/performance results for platforms using acpi-cpufreq.
This file is only present if the acpi-cpufreq driver is in use.
What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
Date: August 2008
KernelVersion: 2.6.27

10
Documentation/ABI/testing/sysfs-firmware-acpi
View File

@ -44,6 +44,16 @@ Description:
or 0 (unset). Attempts to write any other values to it will
cause -EINVAL to be returned.
What: /sys/firmware/acpi/hotplug/force_remove
Date: May 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The number in this file (0 or 1) determines whether (1) or not
(0) the ACPI subsystem will allow devices to be hot-removed even
if they cannot be put offline gracefully (from the kernel's
viewpoint). That number can be changed by writing a boolean
value to this file.
What: /sys/firmware/acpi/interrupts/
Date: February 2008
Contact: Len Brown <lenb@kernel.org>

3
Documentation/CodingStyle
View File

@ -389,7 +389,8 @@ Albeit deprecated by some people, the equivalent of the goto statement is
used frequently by compilers in form of the unconditional jump instruction.
The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done.
locations and some common work such as cleanup has to be done. If there is no
cleanup needed then just return directly.
The rationale is:

4
Documentation/DocBook/device-drivers.tmpl
View File

@ -297,10 +297,10 @@ KAO -->
</sect1>
<sect1><title>Frame Buffer Fonts</title>
<para>
Refer to the file drivers/video/console/fonts.c for more information.
Refer to the file lib/fonts/fonts.c for more information.
</para>
<!-- FIXME: Removed for now since no structured comments in source
X!Idrivers/video/console/fonts.c
X!Ilib/fonts/fonts.c
-->
</sect1>
</chapter>

13
Documentation/DocBook/genericirq.tmpl
View File

@ -464,6 +464,19 @@ if (desc->irq_data.chip->irq_eoi)
protected via desc->lock, by the generic layer.
</para>
</chapter>
<chapter id="genericchip">
<title>Generic interrupt chip</title>
<para>
To avoid copies of identical implementations of irq chips the
core provides a configurable generic interrupt chip
implementation. Developers should check carefuly whether the
generic chip fits their needs before implementing the same
functionality slightly different themself.
</para>
!Ekernel/irq/generic-chip.c
</chapter>
<chapter id="structs">
<title>Structures</title>
<para>

7
Documentation/DocBook/kernel-locking.tmpl
View File

@ -1955,12 +1955,17 @@ machines due to caching.
</sect1>
</chapter>
<chapter id="apiref">
<chapter id="apiref-mutex">
<title>Mutex API reference</title>
!Iinclude/linux/mutex.h
!Ekernel/mutex.c
</chapter>
<chapter id="apiref-futex">
<title>Futex API reference</title>
!Ikernel/futex.c
</chapter>
<chapter id="references">
<title>Further reading</title>

6
Documentation/RCU/checklist.txt
View File

@ -354,12 +354,6 @@ over a rather long period of time, but improvements are always welcome!
using RCU rather than SRCU, because RCU is almost always faster
and easier to use than is SRCU.
If you need to enter your read-side critical section in a
hardirq or exception handler, and then exit that same read-side
critical section in the task that was interrupted, then you need
to srcu_read_lock_raw() and srcu_read_unlock_raw(), which avoid
the lockdep checking that would otherwise this practice illegal.
Also unlike other forms of RCU, explicit initialization
and cleanup is required via init_srcu_struct() and
cleanup_srcu_struct(). These are passed a "struct srcu_struct"

6
Documentation/RCU/torture.txt
View File

@ -182,12 +182,6 @@ torture_type The type of RCU to test, with string values as follows:
"srcu_expedited": srcu_read_lock(), srcu_read_unlock() and
synchronize_srcu_expedited().
"srcu_raw": srcu_read_lock_raw(), srcu_read_unlock_raw(),
and call_srcu().
"srcu_raw_sync": srcu_read_lock_raw(), srcu_read_unlock_raw(),
and synchronize_srcu().
"sched": preempt_disable(), preempt_enable(), and
call_rcu_sched().

100
Documentation/RCU/trace.txt
View File

@ -530,113 +530,21 @@ o "nos" counts the number of times we balked for other
reasons, e.g., the grace period ended first.
CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats
CONFIG_TINY_RCU debugfs Files and Formats
These implementations of RCU provides a single debugfs file under the
top-level directory RCU, namely rcu/rcudata, which displays fields in
rcu_bh_ctrlblk, rcu_sched_ctrlblk and, for CONFIG_TINY_PREEMPT_RCU,
rcu_preempt_ctrlblk.
rcu_bh_ctrlblk and rcu_sched_ctrlblk.
The output of "cat rcu/rcudata" is as follows:
rcu_preempt: qlen=24 gp=1097669 g197/p197/c197 tasks=...
ttb=. btg=no ntb=184 neb=0 nnb=183 j=01f7 bt=0274
normal balk: nt=1097669 gt=0 bt=371 b=0 ny=25073378 nos=0
exp balk: bt=0 nos=0
rcu_sched: qlen: 0
rcu_bh: qlen: 0
This is split into rcu_preempt, rcu_sched, and rcu_bh sections, with the
rcu_preempt section appearing only in CONFIG_TINY_PREEMPT_RCU builds.
The last three lines of the rcu_preempt section appear only in
CONFIG_RCU_BOOST kernel builds. The fields are as follows:
This is split into rcu_sched and rcu_bh sections. The field is as
follows:
o "qlen" is the number of RCU callbacks currently waiting either
for an RCU grace period or waiting to be invoked. This is the
only field present for rcu_sched and rcu_bh, due to the
short-circuiting of grace period in those two cases.
o "gp" is the number of grace periods that have completed.
o "g197/p197/c197" displays the grace-period state, with the
"g" number being the number of grace periods that have started
(mod 256), the "p" number being the number of grace periods
that the CPU has responded to (also mod 256), and the "c"
number being the number of grace periods that have completed
(once again mode 256).
Why have both "gp" and "g"? Because the data flowing into
"gp" is only present in a CONFIG_RCU_TRACE kernel.
o "tasks" is a set of bits. The first bit is "T" if there are
currently tasks that have recently blocked within an RCU
read-side critical section, the second bit is "N" if any of the
aforementioned tasks are blocking the current RCU grace period,
and the third bit is "E" if any of the aforementioned tasks are
blocking the current expedited grace period. Each bit is "."
if the corresponding condition does not hold.
o "ttb" is a single bit. It is "B" if any of the blocked tasks
need to be priority boosted and "." otherwise.
o "btg" indicates whether boosting has been carried out during
the current grace period, with "exp" indicating that boosting
is in progress for an expedited grace period, "no" indicating
that boosting has not yet started for a normal grace period,
"begun" indicating that boosting has bebug for a normal grace
period, and "done" indicating that boosting has completed for
a normal grace period.
o "ntb" is the total number of tasks subjected to RCU priority boosting
periods since boot.
o "neb" is the number of expedited grace periods that have had
to resort to RCU priority boosting since boot.
o "nnb" is the number of normal grace periods that have had
to resort to RCU priority boosting since boot.
o "j" is the low-order 16 bits of the jiffies counter in hexadecimal.
o "bt" is the low-order 16 bits of the value that the jiffies counter
will have at the next time that boosting is scheduled to begin.
o In the line beginning with "normal balk", the fields are as follows:
o "nt" is the number of times that the system balked from
boosting because there were no blocked tasks to boost.
Note that the system will balk from boosting even if the
grace period is overdue when the currently running task
is looping within an RCU read-side critical section.
There is no point in boosting in this case, because
boosting a running task won't make it run any faster.
o "gt" is the number of times that the system balked
from boosting because, although there were blocked tasks,
none of them were preventing the current grace period
from completing.
o "bt" is the number of times that the system balked
from boosting because boosting was already in progress.
o "b" is the number of times that the system balked from
boosting because boosting had already completed for
the grace period in question.
o "ny" is the number of times that the system balked from
boosting because it was not yet time to start boosting
the grace period in question.
o "nos" is the number of times that the system balked from
boosting for inexplicable ("not otherwise specified")
reasons. This can actually happen due to races involving
increments of the jiffies counter.
o In the line beginning with "exp balk", the fields are as follows:
o "bt" is the number of times that the system balked from
boosting because there were no blocked tasks to boost.
o "nos" is the number of times that the system balked from
boosting for inexplicable ("not otherwise specified")
reasons.

22
Documentation/RCU/whatisRCU.txt
View File

@ -842,9 +842,7 @@ SRCU: Critical sections Grace period Barrier
srcu_read_lock synchronize_srcu srcu_barrier
srcu_read_unlock call_srcu
srcu_read_lock_raw synchronize_srcu_expedited
srcu_read_unlock_raw
srcu_dereference
srcu_dereference synchronize_srcu_expedited
SRCU: Initialization/cleanup
init_srcu_struct
@ -865,38 +863,32 @@ list can be helpful:
a. Will readers need to block? If so, you need SRCU.
b. Is it necessary to start a read-side critical section in a
hardirq handler or exception handler, and then to complete
this read-side critical section in the task that was
interrupted? If so, you need SRCU's srcu_read_lock_raw() and
srcu_read_unlock_raw() primitives.
c. What about the -rt patchset? If readers would need to block
b. What about the -rt patchset? If readers would need to block
in an non-rt kernel, you need SRCU. If readers would block
in a -rt kernel, but not in a non-rt kernel, SRCU is not
necessary.
d. Do you need to treat NMI handlers, hardirq handlers,
c. Do you need to treat NMI handlers, hardirq handlers,
and code segments with preemption disabled (whether
via preempt_disable(), local_irq_save(), local_bh_disable(),
or some other mechanism) as if they were explicit RCU readers?
If so, RCU-sched is the only choice that will work for you.
e. Do you need RCU grace periods to complete even in the face
d. Do you need RCU grace periods to complete even in the face
of softirq monopolization of one or more of the CPUs? For
example, is your code subject to network-based denial-of-service
attacks? If so, you need RCU-bh.
f. Is your workload too update-intensive for normal use of
e. Is your workload too update-intensive for normal use of
RCU, but inappropriate for other synchronization mechanisms?
If so, consider SLAB_DESTROY_BY_RCU. But please be careful!
g. Do you need read-side critical sections that are respected
f. Do you need read-side critical sections that are respected
even though they are in the middle of the idle loop, during
user-mode execution, or on an offlined CPU? If so, SRCU is the
only choice that will work for you.
h. Otherwise, use RCU.
g. Otherwise, use RCU.
Of course, this all assumes that you have determined that RCU is in fact
the right tool for your job.

4
Documentation/accounting/getdelays.c
View File

@ -272,7 +272,7 @@ int main(int argc, char *argv[])
char *logfile = NULL;
int loop = 0;
int containerset = 0;
char containerpath[1024];
char *containerpath = NULL;
int cfd = 0;
int forking = 0;
sigset_t sigset;
@ -299,7 +299,7 @@ int main(int argc, char *argv[])
break;
case 'C':
containerset = 1;
strncpy(containerpath, optarg, strlen(optarg) + 1);
containerpath = optarg;
break;
case 'w':
logfile = strdup(optarg);

9
Documentation/acpi/apei/einj.txt
View File

@ -47,11 +47,16 @@ directory apei/einj. The following files are provided.
- param1
This file is used to set the first error parameter value. Effect of
parameter depends on error_type specified.
parameter depends on error_type specified. For example, if error
type is memory related type, the param1 should be a valid physical
memory address.
- param2
This file is used to set the second error parameter value. Effect of
parameter depends on error_type specified.
parameter depends on error_type specified. For example, if error
type is memory related type, the param2 should be a physical memory
address mask. Linux requires page or narrower granularity, say,
0xfffffffffffff000.
- notrigger
The EINJ mechanism is a two step process. First inject the error, then

395
Documentation/acpi/namespace.txt Normal file
View File

@ -0,0 +1,395 @@
ACPI Device Tree - Representation of ACPI Namespace
Copyright (C) 2013, Intel Corporation
Author: Lv Zheng <lv.zheng@intel.com>
Abstract:
The Linux ACPI subsystem converts ACPI namespace objects into a Linux
device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon
receiving ACPI hotplug notification events. For each device object in this
hierarchy there is a corresponding symbolic link in the
/sys/bus/acpi/devices.
This document illustrates the structure of the ACPI device tree.
Credit:
Thanks for the help from Zhang Rui <rui.zhang@intel.com> and Rafael J.
Wysocki <rafael.j.wysocki@intel.com>.
1. ACPI Definition Blocks
The ACPI firmware sets up RSDP (Root System Description Pointer) in the
system memory address space pointing to the XSDT (Extended System
Description Table). The XSDT always points to the FADT (Fixed ACPI
Description Table) using its first entry, the data within the FADT
includes various fixed-length entries that describe fixed ACPI features
of the hardware. The FADT contains a pointer to the DSDT
(Differentiated System Descripition Table). The XSDT also contains
entries pointing to possibly multiple SSDTs (Secondary System
Description Table).
The DSDT and SSDT data is organized in data structures called definition
blocks that contain definitions of various objects, including ACPI
control methods, encoded in AML (ACPI Machine Language). The data block
of the DSDT along with the contents of SSDTs represents a hierarchical
data structure called the ACPI namespace whose topology reflects the
structure of the underlying hardware platform.
The relationships between ACPI System Definition Tables described above
are illustrated in the following diagram.
+---------+ +-------+ +--------+ +------------------------+
| RSDP | +->| XSDT | +->| FADT | | +-------------------+ |
+---------+ | +-------+ | +--------+ +-|->| DSDT | |
| Pointer | | | Entry |-+ | ...... | | | +-------------------+ |
+---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | |
| Pointer |-+ | ..... | | ...... | | +-------------------+ |
+---------+ +-------+ +--------+ | +-------------------+ |
| Entry |------------------|->| SSDT | |
+- - - -+ | +-------------------| |
| Entry | - - - - - - - -+ | | Definition Blocks | |
+- - - -+ | | +-------------------+ |
| | +- - - - - - - - - -+ |
+-|->| SSDT | |
| +-------------------+ |
| | Definition Blocks | |
| +- - - - - - - - - -+ |
+------------------------+
|
OSPM Loading |
\|/
+----------------+
| ACPI Namespace |
+----------------+
Figure 1. ACPI Definition Blocks
NOTE: RSDP can also contain a pointer to the RSDT (Root System
Description Table). Platforms provide RSDT to enable
compatibility with ACPI 1.0 operating systems. The OS is expected
to use XSDT, if present.
2. Example ACPI Namespace
All definition blocks are loaded into a single namespace. The namespace
is a hierarchy of objects identified by names and paths.
The following naming conventions apply to object names in the ACPI
namespace:
1. All names are 32 bits long.
2. The first byte of a name must be one of 'A' - 'Z', '_'.
3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0'
- '9', '_'.
4. Names starting with '_' are reserved by the ACPI specification.
5. The '\' symbol represents the root of the namespace (i.e. names
prepended with '\' are relative to the namespace root).
6. The '^' symbol represents the parent of the current namespace node
(i.e. names prepended with '^' are relative to the parent of the
current namespace node).
The figure below shows an example ACPI namespace.
+------+
| \ | Root
+------+
|
| +------+
+-| _PR | Scope(_PR): the processor namespace
| +------+
| |
| | +------+
| +-| CPU0 | Processor(CPU0): the first processor
| +------+
|
| +------+
+-| _SB | Scope(_SB): the system bus namespace
| +------+
| |
| | +------+
| +-| LID0 | Device(LID0); the lid device
| | +------+
| | |
| | | +------+
| | +-| _HID | Name(_HID, "PNP0C0D"): the hardware ID
| | | +------+
| | |
| | | +------+
| | +-| _STA | Method(_STA): the status control method
| | +------+
| |
| | +------+
| +-| PCI0 | Device(PCI0); the PCI root bridge
| +------+
| |
| | +------+
| +-| _HID | Name(_HID, "PNP0A08"): the hardware ID
| | +------+
| |
| | +------+
| +-| _CID | Name(_CID, "PNP0A03"): the compatible ID
| | +------+
| |
| | +------+
| +-| RP03 | Scope(RP03): the PCI0 power scope
| | +------+
| | |
| | | +------+
| | +-| PXP3 | PowerResource(PXP3): the PCI0 power resource
| | +------+
| |
| | +------+
| +-| GFX0 | Device(GFX0): the graphics adapter
| +------+
| |
| | +------+
| +-| _ADR | Name(_ADR, 0x00020000): the PCI bus address
| | +------+
| |
| | +------+
| +-| DD01 | Device(DD01): the LCD output device
| +------+
| |
| | +------+
| +-| _BCL | Method(_BCL): the backlight control method
| +------+
|
| +------+
+-| _TZ | Scope(_TZ): the thermal zone namespace
| +------+
| |
| | +------+
| +-| FN00 | PowerResource(FN00): the FAN0 power resource
| | +------+
| |
| | +------+
| +-| FAN0 | Device(FAN0): the FAN0 cooling device
| | +------+
| | |
| | | +------+
| | +-| _HID | Name(_HID, "PNP0A0B"): the hardware ID
| | +------+
| |
| | +------+
| +-| TZ00 | ThermalZone(TZ00); the FAN thermal zone
| +------+
|
| +------+
+-| _GPE | Scope(_GPE): the GPE namespace
+------+
Figure 2. Example ACPI Namespace
3. Linux ACPI Device Objects
The Linux kernel's core ACPI subsystem creates struct acpi_device
objects for ACPI namespace objects representing devices, power resources
processors, thermal zones. Those objects are exported to user space via
sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The
format of their names is <bus_id:instance>, where 'bus_id' refers to the
ACPI namespace representation of the given object and 'instance' is used
for distinguishing different object of the same 'bus_id' (it is
two-digit decimal representation of an unsigned integer).
The value of 'bus_id' depends on the type of the object whose name it is
part of as listed in the table below.
+---+-----------------+-------+----------+
| | Object/Feature | Table | bus_id |
+---+-----------------+-------+----------+
| N | Root | xSDT | LNXSYSTM |
+---+-----------------+-------+----------+
| N | Device | xSDT | _HID |
+---+-----------------+-------+----------+
| N | Processor | xSDT | LNXCPU |
+---+-----------------+-------+----------+
| N | ThermalZone | xSDT | LNXTHERM |
+---+-----------------+-------+----------+
| N | PowerResource | xSDT | LNXPOWER |
+---+-----------------+-------+----------+
| N | Other Devices | xSDT | device |
+---+-----------------+-------+----------+
| F | PWR_BUTTON | FADT | LNXPWRBN |
+---+-----------------+-------+----------+
| F | SLP_BUTTON | FADT | LNXSLPBN |
+---+-----------------+-------+----------+
| M | Video Extension | xSDT | LNXVIDEO |
+---+-----------------+-------+----------+
| M | ATA Controller | xSDT | LNXIOBAY |
+---+-----------------+-------+----------+
| M | Docking Station | xSDT | LNXDOCK |
+---+-----------------+-------+----------+
Table 1. ACPI Namespace Objects Mapping
The following rules apply when creating struct acpi_device objects on
the basis of the contents of ACPI System Description Tables (as
indicated by the letter in the first column and the notation in the
second column of the table above):
N:
The object's source is an ACPI namespace node (as indicated by the
named object's type in the second column). In that case the object's
directory in sysfs will contain the 'path' attribute whose value is
the full path to the node from the namespace root.
struct acpi_device objects are created for the ACPI namespace nodes
whose _STA control methods return PRESENT or FUNCTIONING. The power
resource nodes or nodes without _STA are assumed to be both PRESENT
and FUNCTIONING.
F:
The struct acpi_device object is created for a fixed hardware
feature (as indicated by the fixed feature flag's name in the second
column), so its sysfs directory will not contain the 'path'
attribute.
M:
The struct acpi_device object is created for an ACPI namespace node
with specific control methods (as indicated by the ACPI defined
device's type in the second column). The 'path' attribute containing
its namespace path will be present in its sysfs directory. For
example, if the _BCL method is present for an ACPI namespace node, a
struct acpi_device object with LNXVIDEO 'bus_id' will be created for
it.
The third column of the above table indicates which ACPI System
Description Tables contain information used for the creation of the
struct acpi_device objects represented by the given row (xSDT means DSDT
or SSDT).
The forth column of the above table indicates the 'bus_id' generation
rule of the struct acpi_device object:
_HID:
_HID in the last column of the table means that the object's bus_id
is derived from the _HID/_CID identification objects present under
the corresponding ACPI namespace node. The object's sysfs directory
will then contain the 'hid' and 'modalias' attributes that can be
used to retrieve the _HID and _CIDs of that object.
LNXxxxxx:
The 'modalias' attribute is also present for struct acpi_device
objects having bus_id of the "LNXxxxxx" form (pseudo devices), in
which cases it contains the bus_id string itself.
device:
'device' in the last column of the table indicates that the object's
bus_id cannot be determined from _HID/_CID of the corresponding
ACPI namespace node, although that object represents a device (for
example, it may be a PCI device with _ADR defined and without _HID
or _CID). In that case the string 'device' will be used as the
object's bus_id.
4. Linux ACPI Physical Device Glue
ACPI device (i.e. struct acpi_device) objects may be linked to other
objects in the Linux' device hierarchy that represent "physical" devices
(for example, devices on the PCI bus). If that happens, it means that
the ACPI device object is a "companion" of a device otherwise
represented in a different way and is used (1) to provide configuration
information on that device which cannot be obtained by other means and
(2) to do specific things to the device with the help of its ACPI
control methods. One ACPI device object may be linked this way to
multiple "physical" devices.
If an ACPI device object is linked to a "physical" device, its sysfs
directory contains the "physical_node" symbolic link to the sysfs
directory of the target device object. In turn, the target device's
sysfs directory will then contain the "firmware_node" symbolic link to
the sysfs directory of the companion ACPI device object.
The linking mechanism relies on device identification provided by the
ACPI namespace. For example, if there's an ACPI namespace object
representing a PCI device (i.e. a device object under an ACPI namespace
object representing a PCI bridge) whose _ADR returns 0x00020000 and the
bus number of the parent PCI bridge is 0, the sysfs directory
representing the struct acpi_device object created for that ACPI
namespace object will contain the 'physical_node' symbolic link to the
/sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the
corresponding PCI device.
The linking mechanism is generally bus-specific. The core of its
implementation is located in the drivers/acpi/glue.c file, but there are
complementary parts depending on the bus types in question located
elsewhere. For example, the PCI-specific part of it is located in
drivers/pci/pci-acpi.c.
5. Example Linux ACPI Device Tree
The sysfs hierarchy of struct acpi_device objects corresponding to the
example ACPI namespace illustrated in Figure 2 with the addition of
fixed PWR_BUTTON/SLP_BUTTON devices is shown below.
+--------------+---+-----------------+
| LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: |
+--------------+---+-----------------+
|
| +-------------+-----+----------------+
+-| LNXPWRBN:00 | N/A | acpi:LNXPWRBN: |
| +-------------+-----+----------------+
|
| +-------------+-----+----------------+
+-| LNXSLPBN:00 | N/A | acpi:LNXSLPBN: |
| +-------------+-----+----------------+
|
| +-----------+------------+--------------+
+-| LNXCPU:00 | \_PR_.CPU0 | acpi:LNXCPU: |
| +-----------+------------+--------------+
|
| +-------------+-------+----------------+
+-| LNXSYBUS:00 | \_SB_ | acpi:LNXSYBUS: |
| +-------------+-------+----------------+
| |
| | +- - - - - - - +- - - - - - +- - - - - - - -+
| +-| * PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
| | +- - - - - - - +- - - - - - +- - - - - - - -+
| |
| | +------------+------------+-----------------------+
| +-| PNP0A08:00 | \_SB_.PCI0 | acpi:PNP0A08:PNP0A03: |
| +------------+------------+-----------------------+
| |
| | +-----------+-----------------+-----+
| +-| device:00 | \_SB_.PCI0.RP03 | N/A |
| | +-----------+-----------------+-----+
| | |
| | | +-------------+----------------------+----------------+
| | +-| LNXPOWER:00 | \_SB_.PCI0.RP03.PXP3 | acpi:LNXPOWER: |
| | +-------------+----------------------+----------------+
| |
| | +-------------+-----------------+----------------+
| +-| LNXVIDEO:00 | \_SB_.PCI0.GFX0 | acpi:LNXVIDEO: |
| +-------------+-----------------+----------------+
| |
| | +-----------+-----------------+-----+
| +-| device:01 | \_SB_.PCI0.DD01 | N/A |
| +-----------+-----------------+-----+
|
| +-------------+-------+----------------+
+-| LNXSYBUS:01 | \_TZ_ | acpi:LNXSYBUS: |
+-------------+-------+----------------+
|
| +-------------+------------+----------------+
+-| LNXPOWER:0a | \_TZ_.FN00 | acpi:LNXPOWER: |
| +-------------+------------+----------------+
|
| +------------+------------+---------------+
+-| PNP0C0B:00 | \_TZ_.FAN0 | acpi:PNP0C0B: |
| +------------+------------+---------------+
|
| +-------------+------------+----------------+
+-| LNXTHERM:00 | \_TZ_.TZ00 | acpi:LNXTHERM: |
+-------------+------------+----------------+
Figure 3. Example Linux ACPI Device Tree
NOTE: Each node is represented as "object/path/modalias", where:
1. 'object' is the name of the object's directory in sysfs.
2. 'path' is the ACPI namespace path of the corresponding
ACPI namespace object, as returned by the object's 'path'
sysfs attribute.
3. 'modalias' is the value of the object's 'modalias' sysfs
attribute (as described earlier in this document).
NOTE: N/A indicates the device object does not have the 'path' or the
'modalias' attribute.
NOTE: The PNP0C0D device listed above is highlighted (marked by "*")
to indicate it will be created only when its _STA methods return
PRESENT or FUNCTIONING.

106
Documentation/acpi/video_extension.txt Normal file
View File

@ -0,0 +1,106 @@
ACPI video extensions
~~~~~~~~~~~~~~~~~~~~~
This driver implement the ACPI Extensions For Display Adapters for
integrated graphics devices on motherboard, as specified in ACPI 2.0
Specification, Appendix B, allowing to perform some basic control like
defining the video POST device, retrieving EDID information or to
setup a video output, etc. Note that this is an ref. implementation
only. It may or may not work for your integrated video device.
The ACPI video driver does 3 things regarding backlight control:
1 Export a sysfs interface for user space to control backlight level
If the ACPI table has a video device, and acpi_backlight=vendor kernel
command line is not present, the driver will register a backlight device
and set the required backlight operation structure for it for the sysfs
interface control. For every registered class device, there will be a
directory named acpi_videoX under /sys/class/backlight.
The backlight sysfs interface has a standard definition here:
Documentation/ABI/stable/sysfs-class-backlight.
And what ACPI video driver does is:
actual_brightness: on read, control method _BQC will be evaluated to
get the brightness level the firmware thinks it is at;
bl_power: not implemented, will set the current brightness instead;
brightness: on write, control method _BCM will run to set the requested
brightness level;
max_brightness: Derived from the _BCL package(see below);
type: firmware
Note that ACPI video backlight driver will always use index for
brightness, actual_brightness and max_brightness. So if we have
the following _BCL package:
Method (_BCL, 0, NotSerialized)
{
Return (Package (0x0C)
{
0x64,
0x32,
0x0A,
0x14,
0x1E,
0x28,
0x32,
0x3C,
0x46,
0x50,
0x5A,
0x64
})
}
The first two levels are for when laptop are on AC or on battery and are
not used by Linux currently. The remaining 10 levels are supported levels
that we can choose from. The applicable index values are from 0 (that
corresponds to the 0x0A brightness value) to 9 (that corresponds to the
0x64 brightness value) inclusive. Each of those index values is regarded
as a "brightness level" indicator. Thus from the user space perspective
the range of available brightness levels is from 0 to 9 (max_brightness)
inclusive.
2 Notify user space about hotkey event
There are generally two cases for hotkey event reporting:
i) For some laptops, when user presses the hotkey, a scancode will be
generated and sent to user space through the input device created by
the keyboard driver as a key type input event, with proper remap, the
following key code will appear to user space:
EV_KEY, KEY_BRIGHTNESSUP
EV_KEY, KEY_BRIGHTNESSDOWN
etc.
For this case, ACPI video driver does not need to do anything(actually,
it doesn't even know this happened).
ii) For some laptops, the press of the hotkey will not generate the
scancode, instead, firmware will notify the video device ACPI node
about the event. The event value is defined in the ACPI spec. ACPI
video driver will generate an key type input event according to the
notify value it received and send the event to user space through the
input device it created:
event keycode
0x86 KEY_BRIGHTNESSUP
0x87 KEY_BRIGHTNESSDOWN
etc.
so this would lead to the same effect as case i) now.
Once user space tool receives this event, it can modify the backlight
level through the sysfs interface.
3 Change backlight level in the kernel
This works for machines covered by case ii) in Section 2. Once the driver
received a notification, it will set the backlight level accordingly. This does
not affect the sending of event to user space, they are always sent to user
space regardless of whether or not the video module controls the backlight level
directly. This behaviour can be controlled through the brightness_switch_enabled
module parameter as documented in kernel-parameters.txt. It is recommended to
disable this behaviour once a GUI environment starts up and wants to have full
control of the backlight level.

7
Documentation/arm64/memory.txt
View File

@ -73,3 +73,10 @@ Translation table lookup with 64KB pages:
| | +--------------------------> [41:29] L2 index (only 38:29 used)
| +-------------------------------> [47:42] L1 index (not used)
+-------------------------------------------------> [63] TTBR0/1
When using KVM, the hypervisor maps kernel pages in EL2, at a fixed
offset from the kernel VA (top 24bits of the kernel VA set to zero):
Start End Size Use
-----------------------------------------------------------------------
0000004000000000 0000007fffffffff 256GB kernel objects mapped in HYP

2
Documentation/cgroups/cpusets.txt
View File

@ -373,7 +373,7 @@ can become very uneven.
1.7 What is sched_load_balance ?
--------------------------------
The kernel scheduler (kernel/sched.c) automatically load balances
The kernel scheduler (kernel/sched/core.c) automatically load balances
tasks. If one CPU is underutilized, kernel code running on that
CPU will look for tasks on other more overloaded CPUs and move those
tasks to itself, within the constraints of such placement mechanisms

7
Documentation/cgroups/memory.txt
View File

@ -834,10 +834,9 @@ Test:
12. TODO
1. Add support for accounting huge pages (as a separate controller)
2. Make per-cgroup scanner reclaim not-shared pages first
3. Teach controller to account for shared-pages
4. Start reclamation in the background when the limit is
1. Make per-cgroup scanner reclaim not-shared pages first
2. Teach controller to account for shared-pages
3. Start reclamation in the background when the limit is
not yet hit but the usage is getting closer
Summary

10
Documentation/cpu-freq/cpu-drivers.txt
View File

@ -186,7 +186,7 @@ As most cpufreq processors only allow for being set to a few specific
frequencies, a "frequency table" with some functions might assist in
some work of the processor driver. Such a "frequency table" consists
of an array of struct cpufreq_frequency_table entries, with any value in
"index" you want to use, and the corresponding frequency in
"driver_data" you want to use, and the corresponding frequency in
"frequency". At the end of the table, you need to add a
cpufreq_frequency_table entry with frequency set to CPUFREQ_TABLE_END. And
if you want to skip one entry in the table, set the frequency to
@ -214,10 +214,4 @@ int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
is the corresponding frequency table helper for the ->target
stage. Just pass the values to this function, and the unsigned int
index returns the number of the frequency table entry which contains
the frequency the CPU shall be set to. PLEASE NOTE: This is not the
"index" which is in this cpufreq_table_entry.index, but instead
cpufreq_table[index]. So, the new frequency is
cpufreq_table[index].frequency, and the value you stored into the
frequency table "index" field is
cpufreq_table[index].index.
the frequency the CPU shall be set to.

6
Documentation/cpu-hotplug.txt
View File

@ -370,8 +370,10 @@ A: There is no clear spec defined way from ACPI that can give us that
CPUs in MADT as hotpluggable CPUS. In the case there are no disabled CPUS
we assume 1/2 the number of CPUs currently present can be hotplugged.
Caveat: Today's ACPI MADT can only provide 256 entries since the apicid field
in MADT is only 8 bits.
Caveat: ACPI MADT can only provide 256 entries in systems with only ACPI 2.0c
or earlier ACPI version supported, because the apicid field in MADT is only
8 bits. From ACPI 3.0, this limitation was removed since the apicid field
was extended to 32 bits with x2APIC introduced.
User Space Notification

1
Documentation/crypto/async-tx-api.txt
View File

@ -222,5 +222,4 @@ drivers/dma/: location for offload engine drivers
include/linux/async_tx.h: core header file for the async_tx api
crypto/async_tx/async_tx.c: async_tx interface to dmaengine and common code
crypto/async_tx/async_memcpy.c: copy offload
crypto/async_tx/async_memset.c: memory fill offload
crypto/async_tx/async_xor.c: xor and xor zero sum offload

3
Documentation/devices.txt
View File

@ -100,8 +100,7 @@ Your cooperation is appreciated.
10 = /dev/aio Asynchronous I/O notification interface
11 = /dev/kmsg Writes to this come out as printk's, reads
export the buffered printk records.
12 = /dev/oldmem Used by crashdump kernels to access
the memory of the kernel that crashed.
12 = /dev/oldmem OBSOLETE - replaced by /proc/vmcore
1 block RAM disk
0 = /dev/ram0 First RAM disk

3
Documentation/devicetree/bindings/arm/l2cc.txt
View File

@ -16,6 +16,9 @@ Required properties:
performs the same operation).
"marvell,"aurora-outer-cache: Marvell Controller designed to be
compatible with the ARM one with outer cache mode.
"bcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
offset needs to be added to the address before passing down to the L2
cache controller
- cache-unified : Specifies the cache is a unified cache.
- cache-level : Should be set to 2 for a level 2 cache.
- reg : Physical base address and size of cache controller's memory mapped

5
Documentation/devicetree/bindings/ata/ahci-platform.txt
View File

@ -12,6 +12,11 @@ Optional properties:
- calxeda,port-phys: phandle-combophy and lane assignment, which maps each
SATA port to a combophy and a lane within that
combophy
- calxeda,sgpio-gpio: phandle-gpio bank, bit offset, and default on or off,
which indicates that the driver supports SGPIO
indicator lights using the indicated GPIOs
- calxeda,led-order : a u32 array that map port numbers to offsets within the
SGPIO bitstream.
- dma-coherent : Present if dma operations are coherent
Example:

24
Documentation/devicetree/bindings/clock/nspire-clock.txt Normal file
View File

@ -0,0 +1,24 @@
TI-NSPIRE Clocks
Required properties:
- compatible: Valid compatible properties include:
"lsi,nspire-cx-ahb-divider" for the AHB divider in the CX model
"lsi,nspire-classic-ahb-divider" for the AHB divider in the older model
"lsi,nspire-cx-clock" for the base clock in the CX model
"lsi,nspire-classic-clock" for the base clock in the older model
- reg: Physical base address of the controller and length of memory mapped
region.
Optional:
- clocks: For the "nspire-*-ahb-divider" compatible clocks, this is the parent
clock where it divides the rate from.
Example:
ahb_clk {
#clock-cells = <0>;
compatible = "lsi,nspire-cx-clock";
reg = <0x900B0000 0x4>;
clocks = <&base_clk>;
};

74
Documentation/devicetree/bindings/clock/rockchip.txt Normal file
View File

@ -0,0 +1,74 @@
Device Tree Clock bindings for arch-rockchip
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
== Gate clocks ==
The gate registers form a continuos block which makes the dt node
structure a matter of taste, as either all gates can be put into
one gate clock spanning all registers or they can be divided into
the 10 individual gates containing 16 clocks each.
The code supports both approaches.
Required properties:
- compatible : "rockchip,rk2928-gate-clk"
- reg : shall be the control register address(es) for the clock.
- #clock-cells : from common clock binding; shall be set to 1
- clock-output-names : the corresponding gate names that the clock controls
- clocks : should contain the parent clock for each individual gate,
therefore the number of clocks elements should match the number of
clock-output-names
Example using multiple gate clocks:
clk_gates0: gate-clk@200000d0 {
compatible = "rockchip,rk2928-gate-clk";
reg = <0x200000d0 0x4>;
clocks = <&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>;
clock-output-names =
"gate_core_periph", "gate_cpu_gpll",
"gate_ddrphy", "gate_aclk_cpu",
"gate_hclk_cpu", "gate_pclk_cpu",
"gate_atclk_cpu", "gate_i2s0",
"gate_i2s0_frac", "gate_i2s1",
"gate_i2s1_frac", "gate_i2s2",
"gate_i2s2_frac", "gate_spdif",
"gate_spdif_frac", "gate_testclk";
#clock-cells = <1>;
};
clk_gates1: gate-clk@200000d4 {
compatible = "rockchip,rk2928-gate-clk";
reg = <0x200000d4 0x4>;
clocks = <&xin24m>, <&xin24m>,
<&xin24m>, <&dummy>,
<&dummy>, <&xin24m>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>;
clock-output-names =
"gate_timer0", "gate_timer1",
"gate_timer2", "gate_jtag",
"gate_aclk_lcdc1_src", "gate_otgphy0",
"gate_otgphy1", "gate_ddr_gpll",
"gate_uart0", "gate_frac_uart0",
"gate_uart1", "gate_frac_uart1",
"gate_uart2", "gate_frac_uart2",
"gate_uart3", "gate_frac_uart3";
#clock-cells = <1>;
};

5
Documentation/devicetree/bindings/clock/silabs,si5351.txt
View File

@ -44,6 +44,11 @@ Optional child node properties:
- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
divider.
- silabs,pll-master: boolean, multisynth can change pll frequency.
- silabs,disable-state : clock output disable state, shall be
0 = clock output is driven LOW when disabled
1 = clock output is driven HIGH when disabled
2 = clock output is FLOATING (HIGH-Z) when disabled
3 = clock output is NEVER disabled
==Example==

117
Documentation/devicetree/bindings/clock/sunxi.txt
View File

@ -12,22 +12,30 @@ Required properties:
"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-ahb-gates-clk" - for the AHB gates on A10
"allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
"allwinner,sun4i-apb0-clk" - for the APB0 clock
"allwinner,sun4i-apb0-gates-clk" - for the APB0 gates
"allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
"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
"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
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
"allwinner,*-gates-clk" where it shall be set to 1
Additionally, "allwinner,sun4i-*-gates-clk" clocks require:
Additionally, "allwinner,*-gates-clk" clocks require:
- clock-output-names : the corresponding gate names that the clock controls
Clock consumers should specify the desired clocks they use with a
"clocks" phandle cell. Consumers that are using a gated clock should
provide an additional ID in their clock property. The values of this
ID are documented in sunxi/<soc>-gates.txt.
For example:
osc24M: osc24M@01c20050 {
@ -50,102 +58,3 @@ cpu: cpu@01c20054 {
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

93
Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt Normal file
View File

@ -0,0 +1,93 @@
Gate clock outputs
------------------
* 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_FE1 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

58
Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt Normal file
View File

@ -0,0 +1,58 @@
Gate clock outputs
------------------
* AXI gates ("allwinner,sun4i-axi-gates-clk")
DRAM 0
* AHB gates ("allwinner,sun5i-a13-ahb-gates-clk")
USBOTG 0
EHCI 1
OHCI 2
SS 5
DMA 6
BIST 7
MMC0 8
MMC1 9
MMC2 10
NAND 13
SDRAM 14
SPI0 20
SPI1 21
SPI2 22
STIMER 28
VE 32
LCD 36
CSI 40
DE_BE 44
DE_FE 46
IEP 51
MALI400 52
* APB0 gates ("allwinner,sun5i-a13-apb0-gates-clk")
CODEC 0
PIO 5
IR 6
* APB1 gates ("allwinner,sun5i-a13-apb1-gates-clk")
I2C0 0
I2C1 1
I2C2 2
UART1 17
UART3 19

2
Documentation/devicetree/bindings/clock/vt8500.txt
View File

@ -8,6 +8,8 @@ Required properties:
- compatible : shall be one of the following:
"via,vt8500-pll-clock" - for a VT8500/WM8505 PLL clock
"wm,wm8650-pll-clock" - for a WM8650 PLL clock
"wm,wm8750-pll-clock" - for a WM8750 PLL clock
"wm,wm8850-pll-clock" - for a WM8850 PLL clock
"via,vt8500-device-clock" - for a VT/WM device clock
Required properties for PLL clocks:

48
Documentation/devicetree/bindings/gpio/gpio-xilinx.txt Normal file
View File

@ -0,0 +1,48 @@
Xilinx plb/axi GPIO controller
Dual channel GPIO controller with configurable number of pins
(from 1 to 32 per channel). Every pin can be configured as
input/output/tristate. Both channels share the same global IRQ but
local interrupts can be enabled on channel basis.
Required properties:
- compatible : Should be "xlnx,xps-gpio-1.00.a"
- reg : Address and length of the register set for the device
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- gpio-controller : Marks the device node as a GPIO controller.
Optional properties:
- interrupts : Interrupt mapping for GPIO IRQ.
- interrupt-parent : Phandle for the interrupt controller that
services interrupts for this device.
- xlnx,all-inputs : if n-th bit is setup, GPIO-n is input
- xlnx,dout-default : if n-th bit is 1, GPIO-n default value is 1
- xlnx,gpio-width : gpio width
- xlnx,tri-default : if n-th bit is 1, GPIO-n is in tristate mode
- xlnx,is-dual : if 1, controller also uses the second channel
- xlnx,all-inputs-2 : as above but for the second channel
- xlnx,dout-default-2 : as above but the second channel
- xlnx,gpio2-width : as above but for the second channel
- xlnx,tri-default-2 : as above but for the second channel
Example:
gpio: gpio@40000000 {
#gpio-cells = <2>;
compatible = "xlnx,xps-gpio-1.00.a";
gpio-controller ;
interrupt-parent = <&microblaze_0_intc>;
interrupts = < 6 2 >;
reg = < 0x40000000 0x10000 >;
xlnx,all-inputs = <0x0>;
xlnx,all-inputs-2 = <0x0>;
xlnx,dout-default = <0x0>;
xlnx,dout-default-2 = <0x0>;
xlnx,gpio-width = <0x2>;
xlnx,gpio2-width = <0x2>;
xlnx,interrupt-present = <0x1>;
xlnx,is-dual = <0x1>;
xlnx,tri-default = <0xffffffff>;
xlnx,tri-default-2 = <0xffffffff>;
} ;

47
Documentation/devicetree/bindings/hwmon/g762.txt Normal file
View File

@ -0,0 +1,47 @@
GMT G762/G763 PWM Fan controller
Required node properties:
- "compatible": must be either "gmt,g762" or "gmt,g763"
- "reg": I2C bus address of the device
- "clocks": a fixed clock providing input clock frequency
on CLK pin of the chip.
Optional properties:
- "fan_startv": fan startup voltage. Accepted values are 0, 1, 2 and 3.
The higher the more.
- "pwm_polarity": pwm polarity. Accepted values are 0 (positive duty)
and 1 (negative duty).
- "fan_gear_mode": fan gear mode. Supported values are 0, 1 and 2.
If an optional property is not set in .dts file, then current value is kept
unmodified (e.g. u-boot installed value).
Additional information on operational parameters for the device is available
in Documentation/hwmon/g762. A detailed datasheet for the device is available
at http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf.
Example g762 node:
clocks {
#address-cells = <1>;
#size-cells = <0>;
g762_clk: fixedclk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <8192>;
}
}
g762: g762@3e {
compatible = "gmt,g762";
reg = <0x3e>;
clocks = <&g762_clk>
fan_gear_mode = <0>; /* chip default */
fan_startv = <1>; /* chip default */
pwm_polarity = <0>; /* chip default */
};

22
Documentation/devicetree/bindings/i2c/ina2xx.txt Normal file
View File

@ -0,0 +1,22 @@
ina2xx properties
Required properties:
- compatible: Must be one of the following:
- "ti,ina219" for ina219
- "ti,ina220" for ina220
- "ti,ina226" for ina226
- "ti,ina230" for ina230
- reg: I2C address
Optional properties:
- shunt-resistor
Shunt resistor value in micro-Ohm
Example:
ina220@44 {
compatible = "ti,ina220";
reg = <0x44>;
shunt-resistor = <1000>;
};

38
Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt Normal file
View File

@ -0,0 +1,38 @@
TB10x Top Level Interrupt Controller
====================================
The Abilis TB10x SOC contains a custom interrupt controller. It performs
one-to-one mapping of external interrupt sources to CPU interrupts and
provides support for reconfigurable trigger modes.
Required properties
-------------------
- compatible: Should be "abilis,tb10x-ictl"
- reg: specifies physical base address and size of register range.
- interrupt-congroller: Identifies the node as an interrupt controller.
- #interrupt cells: Specifies the number of cells used to encode an interrupt
source connected to this controller. The value shall be 2.
- interrupt-parent: Specifies the parent interrupt controller.
- interrupts: Specifies the list of interrupt lines which are handled by
the interrupt controller in the parent controller's notation. Interrupts
are mapped one-to-one to parent interrupts.
Example
-------
intc: interrupt-controller { /* Parent interrupt controller */
interrupt-controller;
#interrupt-cells = <1>; /* For example below */
/* ... */
};
tb10x_ictl: pic@2000 { /* TB10x interrupt controller */
compatible = "abilis,tb10x-ictl";
reg = <0x2000 0x20>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&intc>;
interrupts = <5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29 30 31>;
};

48
Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt Normal file
View File

@ -0,0 +1,48 @@
Marvell Orion SoC interrupt controllers
* Main interrupt controller
Required properties:
- compatible: shall be "marvell,orion-intc"
- reg: base address(es) of interrupt registers starting with CAUSE register
- interrupt-controller: identifies the node as an interrupt controller
- #interrupt-cells: number of cells to encode an interrupt source, shall be 1
The interrupt sources map to the corresponding bits in the interrupt
registers, i.e.
- 0 maps to bit 0 of first base address,
- 1 maps to bit 1 of first base address,
- 32 maps to bit 0 of second base address, and so on.
Example:
intc: interrupt-controller {
compatible = "marvell,orion-intc";
interrupt-controller;
#interrupt-cells = <1>;
/* Dove has 64 first level interrupts */
reg = <0x20200 0x10>, <0x20210 0x10>;
};
* Bridge interrupt controller
Required properties:
- compatible: shall be "marvell,orion-bridge-intc"
- reg: base address of bridge interrupt registers starting with CAUSE register
- interrupts: bridge interrupt of the main interrupt controller
- interrupt-controller: identifies the node as an interrupt controller
- #interrupt-cells: number of cells to encode an interrupt source, shall be 1
Optional properties:
- marvell,#interrupts: number of interrupts provided by bridge interrupt
controller, defaults to 32 if not set
Example:
bridge_intc: interrupt-controller {
compatible = "marvell,orion-bridge-intc";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x20110 0x8>;
interrupts = <0>;
/* Dove bridge provides 5 interrupts */
marvell,#interrupts = <5>;
};

147
Documentation/devicetree/bindings/leds/leds-lp55xx.txt Normal file
View File

@ -0,0 +1,147 @@
Binding for TI/National Semiconductor LP55xx Led Drivers
Required properties:
- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562"
- reg: I2C slave address
- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)
Each child has own specific current settings
- led-cur: Current setting at each led channel (mA x10, 0 if led is not connected)
- max-cur: Maximun current at each led channel.
Optional properties:
- label: Used for naming LEDs
Alternatively, each child can have specific channel name
- chan-name: Name of each channel name
example 1) LP5521
3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0',
'lp5521_pri:channel1' and 'lp5521_pri:channel2'
lp5521@32 {
compatible = "national,lp5521";
reg = <0x32>;
label = "lp5521_pri";
clock-mode = /bits/ 8 <2>;
chan0 {
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
chan1 {
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
chan2 {
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
};
example 2) LP5523
9 LED channels with specific name. Internal clock used.
The I2C slave address is configurable with ASEL1 and ASEL0 pins.
Available addresses are 32/33/34/35h.
ASEL1 ASEL0 Address
-------------------------
GND GND 32h
GND VEN 33h
VEN GND 34h
VEN VEN 35h
lp5523@32 {
compatible = "national,lp5523";
reg = <0x32>;
clock-mode = /bits/ 8 <1>;
chan0 {
chan-name = "d1";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan1 {
chan-name = "d2";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan2 {
chan-name = "d3";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan3 {
chan-name = "d4";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan4 {
chan-name = "d5";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan5 {
chan-name = "d6";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan6 {
chan-name = "d7";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan7 {
chan-name = "d8";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan8 {
chan-name = "d9";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
};
example 3) LP5562
4 channels are defined.
lp5562@30 {
compatible = "ti,lp5562";
reg = <0x30>;
clock-mode = /bits/8 <2>;
chan0 {
chan-name = "R";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
chan1 {
chan-name = "G";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
chan2 {
chan-name = "B";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
chan3 {
chan-name = "W";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
};

62
Documentation/devicetree/bindings/mfd/arizona.txt Normal file
View File

@ -0,0 +1,62 @@
Wolfson Arizona class audio SoCs
These devices are audio SoCs with extensive digital capabilites and a range
of analogue I/O.
Required properties:
- compatible : one of the following chip-specific strings:
"wlf,wm5102"
"wlf,wm5110"
- reg : I2C slave address when connected using I2C, chip select number when
using SPI.
- interrupts : The interrupt line the /IRQ signal for the device is
connected to.
- interrupt-controller : Arizona class devices contain interrupt controllers
and may provide interrupt services to other devices.
- interrupt-parent : The parent interrupt controller.
- #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
The first cell is the IRQ number.
The second cell is the flags, encoded as the trigger masks from
Documentation/devicetree/bindings/interrupts.txt
- gpio-controller : Indicates this device is a GPIO controller.
- #gpio-cells : Must be 2. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- AVDD1-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply,
SPKVDDL-supply, SPKVDDR-supply : power supplies for the device, as covered
in Documentation/devicetree/bindings/regulator/regulator.txt
Optional properties:
- wlf,reset : GPIO specifier for the GPIO controlling /RESET
- wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
- wlf,gpio-defaults : A list of GPIO configuration register values. If
absent, no configuration of these registers is performed. If any
entry has a value that is out of range for a 16 bit register then
the chip default will be used. If present exactly five values must
be specified.
Example:
codec: wm5102@1a {
compatible = "wlf,wm5102";
reg = <0x1a>;
interrupts = <347>;
#interrupt-cells = <2>;
interrupt-parent = <&gic>;
gpio-controller;
#gpio-cells = <2>;
wlf,gpio-defaults = <
0x00000000, /* AIF1TXLRCLK */
0xffffffff,
0xffffffff,
0xffffffff,
0xffffffff,
>;
};

55
Documentation/devicetree/bindings/mfd/max77693.txt Normal file
View File

@ -0,0 +1,55 @@
Maxim MAX77693 multi-function device
MAX77693 is a Multifunction device with the following submodules:
- PMIC,
- CHARGER,
- LED,
- MUIC,
- HAPTIC
It is interfaced to host controller using i2c.
This document describes the bindings for the mfd device.
Required properties:
- compatible : Must be "maxim,max77693".
- reg : Specifies the i2c slave address of PMIC block.
- interrupts : This i2c device has an IRQ line connected to the main SoC.
- interrupt-parent : The parent interrupt controller.
Optional properties:
- regulators : The regulators of max77693 have to be instantiated under subnod
named "regulators" using the following format.
regulators {
regualtor-compatible = ESAFEOUT1/ESAFEOUT2/CHARGER
standard regulator constratints[*].
};
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
Example:
max77693@66 {
compatible = "maxim,max77693";
reg = <0x66>;
interrupt-parent = <&gpx1>;
interrupts = <5 2>;
regulators {
esafeout@1 {
regulator-compatible = "ESAFEOUT1";
regulator-name = "ESAFEOUT1";
regulator-boot-on;
};
esafeout@2 {
regulator-compatible = "ESAFEOUT2";
regulator-name = "ESAFEOUT2";
};
charger@0 {
regulator-compatible = "CHARGER";
regulator-name = "CHARGER";
regulator-min-microamp = <60000>;
regulator-max-microamp = <2580000>;
regulator-boot-on;
};
};
};

41
Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt Normal file
View File

@ -0,0 +1,41 @@
Freescale Vybrid VF610 IOMUX Controller
Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
and usage.
Required properties:
- compatible: "fsl,vf610-iomuxc"
- fsl,pins: two integers array, represents a group of pins mux and config
setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is
a pin working on a specific function, CONFIG is the pad setting value
such as pull-up, speed, ode for this pin. Please refer to Vybrid VF610
datasheet for the valid pad config settings.
CONFIG bits definition:
PAD_CTL_SPEED_LOW (1 << 12)
PAD_CTL_SPEED_MED (2 << 12)
PAD_CTL_SPEED_HIGH (3 << 12)
PAD_CTL_SRE_FAST (1 << 11)
PAD_CTL_SRE_SLOW (0 << 11)
PAD_CTL_ODE (1 << 10)
PAD_CTL_HYS (1 << 9)
PAD_CTL_DSE_DISABLE (0 << 6)
PAD_CTL_DSE_150ohm (1 << 6)
PAD_CTL_DSE_75ohm (2 << 6)
PAD_CTL_DSE_50ohm (3 << 6)
PAD_CTL_DSE_37ohm (4 << 6)
PAD_CTL_DSE_30ohm (5 << 6)
PAD_CTL_DSE_25ohm (6 << 6)
PAD_CTL_DSE_20ohm (7 << 6)
PAD_CTL_PUS_100K_DOWN (0 << 4)
PAD_CTL_PUS_47K_UP (1 << 4)
PAD_CTL_PUS_100K_UP (2 << 4)
PAD_CTL_PUS_22K_UP (3 << 4)
PAD_CTL_PKE (1 << 3)
PAD_CTL_PUE (1 << 2)
PAD_CTL_OBE_ENABLE (1 << 1)
PAD_CTL_IBE_ENABLE (1 << 0)
PAD_CTL_OBE_IBE_ENABLE (3 << 0)
Please refer to vf610-pinfunc.h in device tree source folder
for all available PIN_FUNC_ID for Vybrid VF610.

127
Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt Normal file
View File

@ -0,0 +1,127 @@
ImgTec TZ1090 PDC pin controller
Required properties:
- compatible: "img,tz1090-pdc-pinctrl"
- reg: Should contain the register physical address and length of the
SOC_GPIO_CONTROL registers in the PDC register region.
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
TZ1090-PDC's pin configuration nodes act as a container for an abitrary number
of subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration
parameters, such as pull-up, drive strength, etc.
The name of each subnode is not important; all subnodes should be enumerated
and processed purely based on their content.
Each subnode only affects those parameters that are explicitly listed. In
other words, a subnode that lists a mux function but no pin configuration
parameters implies no information about any pin configuration parameters.
Similarly, a pin subnode that describes a pullup parameter implies no
information about e.g. the mux function. For this reason, even seemingly boolean
values are actually tristates in this binding: unspecified, off, or on.
Unspecified is represented as an absent property, and off/on are represented as
integer values 0 and 1.
Required subnode-properties:
- tz1090,pins : An array of strings. Each string contains the name of a pin or
group. Valid values for these names are listed below.
Optional subnode-properties:
- tz1090,function: A string containing the name of the function to mux to the
pin or group. Valid values for function names are listed below, including
which pingroups can be muxed to them.
- supported generic pinconfig properties (for further details see
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt):
- bias-disable
- bias-high-impedance
- bias-bus-hold
- bias-pull-up
- bias-pull-down
- input-schmitt-enable
- input-schmitt-disable
- drive-strength: Integer, control drive strength of pins in mA.
2: 2mA
4: 4mA
8: 8mA
12: 12mA
- low-power-enable: Flag, power-on-start weak pull-down for invalid power.
- low-power-disable: Flag, power-on-start weak pull-down disabled.
Note that many of these properties are only valid for certain specific pins
or groups. See the TZ1090 TRM for complete details regarding which groups
support which functionality. The Linux pinctrl driver may also be a useful
reference.
Valid values for pin and group names are:
pins:
These all support bias-high-impediance, bias-pull-up, bias-pull-down, and
bias-bus-hold (which can also be provided to any of the groups below to set
it for all gpio pins in that group).
gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data, ext_power.
mux groups:
These all support function.
gpio0
pins: gpio0.
function: ir_mod_stable_out.
gpio1
pins: gpio1.
function: ir_mod_power_out.
drive groups:
These support input-schmitt-enable, input-schmitt-disable,
drive-strength, low-power-enable, and low-power-disable.
pdc
pins: gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data,
ext_power.
Example:
pinctrl_pdc: pinctrl@02006500 {
#gpio-range-cells = <3>;
compatible = "img,tz1090-pdc-pinctrl";
reg = <0x02006500 0x100>;
};
Example board file extracts:
&pinctrl_pdc {
pinctrl-names = "default";
pinctrl-0 = <&syswake_default>;
syswake_default: syswakes {
syswake_cfg {
tz1090,pins = "sys_wake0",
"sys_wake1",
"sys_wake2";
pull-up;
};
};
irmod_default: irmod {
gpio0_cfg {
tz1090,pins = "gpio0";
tz1090,function = "ir_mod_stable_out";
};
gpio1_cfg {
tz1090,pins = "gpio1";
tz1090,function = "ir_mod_power_out";
};
};
};
ir: ir@02006200 {
pinctrl-names = "default";
pinctrl-0 = <&irmod_default>;
};

227
Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt Normal file
View File

@ -0,0 +1,227 @@
ImgTec TZ1090 pin controller
Required properties:
- compatible: "img,tz1090-pinctrl"
- reg: Should contain the register physical address and length of the pad
configuration registers (CR_PADS_* and CR_IF_CTL0).
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
TZ1090's pin configuration nodes act as a container for an abitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration
parameters, such as pull-up, drive strength, etc.
The name of each subnode is not important; all subnodes should be enumerated
and processed purely based on their content.
Each subnode only affects those parameters that are explicitly listed. In
other words, a subnode that lists a mux function but no pin configuration
parameters implies no information about any pin configuration parameters.
Similarly, a pin subnode that describes a pullup parameter implies no
information about e.g. the mux function. For this reason, even seemingly boolean
values are actually tristates in this binding: unspecified, off, or on.
Unspecified is represented as an absent property, and off/on are represented as
integer values 0 and 1.
Required subnode-properties:
- tz1090,pins : An array of strings. Each string contains the name of a pin or
group. Valid values for these names are listed below.
Optional subnode-properties:
- tz1090,function: A string containing the name of the function to mux to the
pin or group. Valid values for function names are listed below, including
which pingroups can be muxed to them.
- supported generic pinconfig properties (for further details see
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt):
- bias-disable
- bias-high-impedance
- bias-bus-hold
- bias-pull-up
- bias-pull-down
- input-schmitt-enable
- input-schmitt-disable
- drive-strength: Integer, control drive strength of pins in mA.
2: 2mA
4: 4mA
8: 8mA
12: 12mA
Note that many of these properties are only valid for certain specific pins
or groups. See the TZ1090 TRM for complete details regarding which groups
support which functionality. The Linux pinctrl driver may also be a useful
reference.
Valid values for pin and group names are:
gpio pins:
These all support bias-high-impediance, bias-pull-up, bias-pull-down, and
bias-bus-hold (which can also be provided to any of the groups below to set
it for all pins in that group).
They also all support the some form of muxing. Any pins which are contained
in one of the mux groups (see below) can be muxed only to the functions
supported by the mux group. All other pins can be muxed to the "perip"
function which which enables them with their intended peripheral.
Different pins in the same mux group cannot be muxed to different functions,
however it is possible to mux only a subset of the pins in a mux group to a
particular function and leave the remaining pins unmuxed. This is useful if
the board connects certain pins in a group to other devices to be controlled
by GPIO, and you don't want the usual peripheral to have any control of the
pin.
ant_sel0, ant_sel1, gain0, gain1, gain2, gain3, gain4, gain5, gain6, gain7,
i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2, i2s_lrclk_out,
i2s_mclk, pa_on, pdm_a, pdm_b, pdm_c, pdm_d, pll_on, rx_hp, rx_on,
scb0_sclk, scb0_sdat, scb1_sclk, scb1_sdat, scb2_sclk, scb2_sdat, sdh_cd,
sdh_clk_in, sdh_wp, sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3,
spi0_cs0, spi0_cs1, spi0_cs2, spi0_din, spi0_dout, spi0_mclk, spi1_cs0,
spi1_cs1, spi1_cs2, spi1_din, spi1_dout, spi1_mclk, tft_blank_ls, tft_blue0,
tft_blue1, tft_blue2, tft_blue3, tft_blue4, tft_blue5, tft_blue6, tft_blue7,
tft_green0, tft_green1, tft_green2, tft_green3, tft_green4, tft_green5,
tft_green6, tft_green7, tft_hsync_nr, tft_panelclk, tft_pwrsave, tft_red0,
tft_red1, tft_red2, tft_red3, tft_red4, tft_red5, tft_red6, tft_red7,
tft_vd12acb, tft_vdden_gd, tft_vsync_ns, tx_on, uart0_cts, uart0_rts,
uart0_rxd, uart0_txd, uart1_rxd, uart1_txd.
bias-high-impediance: supported.
bias-pull-up: supported.
bias-pull-down: supported.
bias-bus-hold: supported.
function: perip or those supported by pin's mux group.
other pins:
These other pins are part of various pin groups below, but can't be
controlled as GPIOs. They do however support bias-high-impediance,
bias-pull-up, bias-pull-down, and bias-bus-hold (which can also be provided
to any of the groups below to set it for all pins in that group).
clk_out0, clk_out1, tck, tdi, tdo, tms, trst.
bias-high-impediance: supported.
bias-pull-up: supported.
bias-pull-down: supported.
bias-bus-hold: supported.
mux groups:
These all support function, and some support drive configs.
afe
pins: tx_on, rx_on, pll_on, pa_on, rx_hp, ant_sel0,
ant_sel1, gain0, gain1, gain2, gain3, gain4,
gain5, gain6, gain7.
function: afe, ts_out_0.
input-schmitt-enable: supported.
input-schmitt-disable: supported.
drive-strength: supported.
pdm_d
pins: pdm_d.
function: pdm_dac, usb_vbus.
sdh
pins: sdh_cd, sdh_wp, sdh_clk_in.
function: sdh, sdio.
sdio
pins: sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2,
sdio_d3.
function: sdio, sdh.
spi1_cs2
pins: spi1_cs2.
function: spi1_cs2, usb_vbus.
tft
pins: tft_red0, tft_red1, tft_red2, tft_red3,
tft_red4, tft_red5, tft_red6, tft_red7,
tft_green0, tft_green1, tft_green2, tft_green3,
tft_green4, tft_green5, tft_green6, tft_green7,
tft_blue0, tft_blue1, tft_blue2, tft_blue3,
tft_blue4, tft_blue5, tft_blue6, tft_blue7,
tft_vdden_gd, tft_panelclk, tft_blank_ls,
tft_vsync_ns, tft_hsync_nr, tft_vd12acb,
tft_pwrsave.
function: tft, ext_dac, not_iqadc_stb, iqdac_stb, ts_out_1,
lcd_trace, phy_ringosc.
input-schmitt-enable: supported.
input-schmitt-disable: supported.
drive-strength: supported.
drive groups:
These all support input-schmitt-enable, input-schmitt-disable,
and drive-strength.
jtag
pins: tck, trst, tdi, tdo, tms.
scb1
pins: scb1_sdat, scb1_sclk.
scb2
pins: scb2_sdat, scb2_sclk.
spi0
pins: spi0_mclk, spi0_cs0, spi0_cs1, spi0_cs2, spi0_dout, spi0_din.
spi1
pins: spi1_mclk, spi1_cs0, spi1_cs1, spi1_cs2, spi1_dout, spi1_din.
uart
pins: uart0_txd, uart0_rxd, uart0_rts, uart0_cts,
uart1_txd, uart1_rxd.
drive_i2s
pins: clk_out1, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2,
i2s_lrclk_out, i2s_bclk_out, i2s_mclk.
drive_pdm
pins: clk_out0, pdm_b, pdm_a.
drive_scb0
pins: scb0_sclk, scb0_sdat, pdm_d, pdm_c.
drive_sdio
pins: sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3,
sdh_wp, sdh_cd, sdh_clk_in.
convenience groups:
These are just convenient groupings of pins and don't support any drive
configs.
uart0
pins: uart0_cts, uart0_rts, uart0_rxd, uart0_txd.
uart1
pins: uart1_rxd, uart1_txd.
scb0
pins: scb0_sclk, scb0_sdat.
i2s
pins: i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2,
i2s_lrclk_out, i2s_mclk.
Example:
pinctrl: pinctrl@02005800 {
#gpio-range-cells = <3>;
compatible = "img,tz1090-pinctrl";
reg = <0x02005800 0xe4>;
};
Example board file extract:
&pinctrl {
uart0_default: uart0 {
uart0_cfg {
tz1090,pins = "uart0_rxd",
"uart0_txd";
tz1090,function = "perip";
};
};
tft_default: tft {
tft_cfg {
tz1090,pins = "tft";
tz1090,function = "tft";
};
};
};
uart@02004b00 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_default>;
};

49
Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
View File

@ -10,29 +10,31 @@ Required properties:
Available mpp pins/groups and functions:
Note: brackets (x) are not part of the mpp name for marvell,function and given
only for more detailed description in this document.
Note: pmu* also allows for Power Management functions listed below
name pins functions
================================================================================
mpp0 0 gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm)
mpp1 1 gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm)
mpp0 0 gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm), pmu*
mpp1 1 gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm), pmu*
mpp2 2 gpio, pmu, uart2(txd), sdio0(buspwr), sata(prsnt),
uart1(rts)
uart1(rts), pmu*
mpp3 3 gpio, pmu, uart2(rxd), sdio0(ledctrl), sata(act),
uart1(cts), lcd-spi(cs1)
mpp4 4 gpio, pmu, uart3(rts), sdio1(cd), spi1(miso)
mpp5 5 gpio, pmu, uart3(cts), sdio1(wp), spi1(cs)
mpp6 6 gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi)
mpp7 7 gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck)
mpp8 8 gpio, pmu, watchdog(rstout)
mpp9 9 gpio, pmu, pex1(clkreq)
mpp10 10 gpio, pmu, ssp(sclk)
uart1(cts), lcd-spi(cs1), pmu*
mpp4 4 gpio, pmu, uart3(rts), sdio1(cd), spi1(miso), pmu*
mpp5 5 gpio, pmu, uart3(cts), sdio1(wp), spi1(cs), pmu*
mpp6 6 gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi), pmu*
mpp7 7 gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck), pmu*
mpp8 8 gpio, pmu, watchdog(rstout), pmu*
mpp9 9 gpio, pmu, pex1(clkreq), pmu*
mpp10 10 gpio, pmu, ssp(sclk), pmu*
mpp11 11 gpio, pmu, sata(prsnt), sata-1(act), sdio0(ledctrl),
sdio1(ledctrl), pex0(clkreq)
mpp12 12 gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd), sata(act)
sdio1(ledctrl), pex0(clkreq), pmu*
mpp12 12 gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd),
sata(act), pmu*
mpp13 13 gpio, pmu, uart2(cts), audio1(extclk), sdio1(wp),
ssp(extclk)
mpp14 14 gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd)
mpp15 15 gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm)
ssp(extclk), pmu*
mpp14 14 gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd), pmu*
mpp15 15 gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm), pmu*
mpp16 16 gpio, uart3(rts), sdio0(cd), ac97(sdi1), lcd-spi(cs1)
mpp17 17 gpio, uart3(cts), sdio0(wp), ac97(sdi2), twsi(sda),
ac97-1(sysclko)
@ -57,6 +59,21 @@ mpp_nand 64-71 gpo, nand
audio0 - i2s, ac97
twsi - none, opt1, opt2, opt3
Power Management functions (pmu*):
pmu-nc Pin not driven by any PM function
pmu-low Pin driven low (0)
pmu-high Pin driven high (1)
pmic(sdi) Pin is used for PMIC SDI
cpu-pwr-down Pin is used for CPU_PWRDWN
standby-pwr-down Pin is used for STBY_PWRDWN
core-pwr-good Pin is used for CORE_PWR_GOOD (Pins 0-7 only)
cpu-pwr-good Pin is used for CPU_PWR_GOOD (Pins 8-15 only)
bat-fault Pin is used for BATTERY_FAULT
ext0-wakeup Pin is used for EXT0_WU
ext1-wakeup Pin is used for EXT0_WU
ext2-wakeup Pin is used for EXT0_WU
pmu-blink Pin is used for blink function
Notes:
* group "mpp_audio1" allows the following functions and gpio pins:
- gpio : gpio on pins 52-57

48
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
View File

@ -126,3 +126,51 @@ device; they may be grandchildren, for example. Whether this is legal, and
whether there is any interaction between the child and intermediate parent
nodes, is again defined entirely by the binding for the individual pin
controller device.
== Using generic pinconfig options ==
Generic pinconfig parameters can be used by defining a separate node containing
the applicable parameters (and optional values), like:
pcfg_pull_up: pcfg_pull_up {
bias-pull-up;
drive-strength = <20>;
};
This node should then be referenced in the appropriate pinctrl node as a phandle
and parsed in the driver using the pinconf_generic_parse_dt_config function.
Supported configuration parameters are:
bias-disable - disable any pin bias
bias-high-impedance - high impedance mode ("third-state", "floating")
bias-bus-hold - latch weakly
bias-pull-up - pull up the pin
bias-pull-down - pull down the pin
bias-pull-pin-default - use pin-default pull state
drive-push-pull - drive actively high and low
drive-open-drain - drive with open drain
drive-open-source - drive with open source
drive-strength - sink or source at most X mA
input-schmitt-enable - enable schmitt-trigger mode
input-schmitt-disable - disable schmitt-trigger mode
input-debounce - debounce mode with debound time X
low-power-enable - enable low power mode
low-power-disable - disable low power mode
output-low - set the pin to output mode with low level
output-high - set the pin to output mode with high level
Arguments for parameters:
- bias-pull-up, -down and -pin-default take as optional argument on hardware
supporting it the pull strength in Ohm. bias-disable will disable the pull.
- drive-strength takes as argument the target strength in mA.
- input-debounce takes the debounce time in usec as argument
or 0 to disable debouncing
All parameters not listed here, do not take an argument.
More in-depth documentation on these parameters can be found in
<include/linux/pinctrl/pinconfig-generic.h>

3
Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
View File

@ -18,7 +18,8 @@ Optional properties:
pin functions is ignored
- pinctrl-single,bit-per-mux : boolean to indicate that one register controls
more than one pin
more than one pin, for which "pinctrl-single,function-mask" property specifies
position mask of 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

110
Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt Normal file
View File

@ -0,0 +1,110 @@
*ST pin controller.
Each multi-function pin is controlled, driven and routed through the
PIO multiplexing block. Each pin supports GPIO functionality (ALT0)
and multiple alternate functions(ALT1 - ALTx) that directly connect
the pin to different hardware blocks.
When a pin is in GPIO mode, Output Enable (OE), Open Drain(OD), and
Pull Up (PU) are driven by the related PIO block.
ST pinctrl driver controls PIO multiplexing block and also interacts with
gpio driver to configure a pin.
Required properties: (PIO multiplexing block)
- compatible : should be "st,<SOC>-<pio-block>-pinctrl"
like st,stih415-sbc-pinctrl, st,stih415-front-pinctrl and so on.
- gpio-controller : Indicates this device is a GPIO controller
- #gpio-cells : Should be one. The first cell is the pin number.
- st,retime-pin-mask : Should be mask to specify which pins can be retimed.
If the property is not present, it is assumed that all the pins in the
bank are capable of retiming. Retiming is mainly used to improve the
IO timing margins of external synchronous interfaces.
- st,bank-name : Should be a name string for this bank as
specified in datasheet.
- st,syscfg : Should be a phandle of the syscfg node.
Example:
pin-controller-sbc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "st,stih415-sbc-pinctrl";
st,syscfg = <&syscfg_sbc>;
ranges = <0 0xfe610000 0x5000>;
PIO0: gpio@fe610000 {
gpio-controller;
#gpio-cells = <1>;
reg = <0 0x100>;
st,bank-name = "PIO0";
};
...
pin-functions nodes follow...
};
Contents of function subnode node:
----------------------
Required properties for pin configuration node:
- st,pins : Child node with list of pins with configuration.
Below is the format of how each pin conf should look like.
<bank offset mux mode rt_type rt_delay rt_clk>
Every PIO is represented with 4-7 parameters depending on retime configuration.
Each parameter is explained as below.
-bank : Should be bank phandle to which this PIO belongs.
-offset : Offset in the PIO bank.
-mux : Should be alternate function number associated this pin.
Use same numbers from datasheet.
-mode :pin configuration is selected from one of the below values.
IN
IN_PU
OUT
BIDIR
BIDIR_PU
-rt_type Retiming Configuration for the pin.
Possible retime configuration are:
------- -------------
value args
------- -------------
NICLK <delay> <clk>
ICLK_IO <delay> <clk>
BYPASS <delay>
DE_IO <delay> <clk>
SE_ICLK_IO <delay> <clk>
SE_NICLK_IO <delay> <clk>
- delay is retime delay in pico seconds as mentioned in data sheet.
- rt_clk :clk to be use for retime.
Possible values are:
CLK_A
CLK_B
CLK_C
CLK_D
Example of mmcclk pin which is a bi-direction pull pu with retime config
as non inverted clock retimed with CLK_B and delay of 0 pico seconds:
pin-controller {
...
mmc0 {
pinctrl_mmc: mmc {
st,pins {
mmcclk = <&PIO13 4 ALT4 BIDIR_PU NICLK 0 CLK_B>;
...
};
};
...
};
};
sdhci0:sdhci@fe810000{
...
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_mmc>;
};

153
Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt Normal file
View File

@ -0,0 +1,153 @@
* Renesas Pin Function Controller (GPIO and Pin Mux/Config)
The Pin Function Controller (PFC) is a Pin Mux/Config controller. On SH7372,
SH73A0, R8A73A4 and R8A7740 it also acts as a GPIO controller.
Pin Control
-----------
Required Properties:
- compatible: should be one of the following.
- "renesas,pfc-r8a73a4": for R8A73A4 (R-Mobile APE6) compatible pin-controller.
- "renesas,pfc-r8a7740": for R8A7740 (R-Mobile A1) compatible pin-controller.
- "renesas,pfc-r8a7778": for R8A7778 (R-Mobile M1) compatible pin-controller.
- "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller.
- "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller.
- "renesas,pfc-sh7372": for SH7372 (SH-Mobile AP4) compatible pin-controller.
- "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller.
- reg: Base address and length of each memory resource used by the pin
controller hardware module.
Optional properties:
- #gpio-range-cells: Mandatory when the PFC doesn't handle GPIO, forbidden
otherwise. Should be 3.
The PFC node also acts as a container for pin configuration nodes. Please refer
to pinctrl-bindings.txt in this directory for the definition of the term "pin
configuration node" and for the common pinctrl bindings used by client devices.
Each pin configuration node represents a desired configuration for a pin, a
pin group, or a list of pins or pin groups. The configuration can include the
function to select on those pin(s) and pin configuration parameters (such as
pull-up and pull-down).
Pin configuration nodes contain pin configuration properties, either directly
or grouped in child subnodes. Both pin muxing and configuration parameters can
be grouped in that way and referenced as a single pin configuration node by
client devices.
A configuration node or subnode must reference at least one pin (through the
pins or pin groups properties) and contain at least a function or one
configuration parameter. When the function is present only pin groups can be
used to reference pins.
All pin configuration nodes and subnodes names are ignored. All of those nodes
are parsed through phandles and processed purely based on their content.
Pin Configuration Node Properties:
- renesas,pins : An array of strings, each string containing the name of a pin.
- renesas,groups : An array of strings, each string containing the name of a pin
group.
- renesas,function: A string containing the name of the function to mux to the
pin group(s) specified by the renesas,groups property
Valid values for pin, group and function names can be found in the group and
function arrays of the PFC data file corresponding to the SoC
(drivers/pinctrl/sh-pfc/pfc-*.c)
The pin configuration parameters use the generic pinconf bindings defined in
pinctrl-bindings.txt in this directory. The supported parameters are
bias-disable, bias-pull-up and bias-pull-down.
GPIO
----
On SH7372, SH73A0, R8A73A4 and R8A7740 the PFC node is also a GPIO controller
node.
Required Properties:
- gpio-controller: Marks the device node as a gpio controller.
- #gpio-cells: Should be 2. The first cell is the GPIO number and the second
cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the
GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
The syntax of the gpio specifier used by client nodes should be the following
with values derived from the SoC user manual.
<[phandle of the gpio controller node]
[pin number within the gpio controller]
[flags]>
On other mach-shmobile platforms GPIO is handled by the gpio-rcar driver.
Please refer to Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
for documentation of the GPIO device tree bindings on those platforms.
Examples
--------
Example 1: SH73A0 (SH-Mobile AG5) pin controller node
pfc: pfc@e6050000 {
compatible = "renesas,pfc-sh73a0";
reg = <0xe6050000 0x8000>,
<0xe605801c 0x1c>;
gpio-controller;
#gpio-cells = <2>;
};
Example 2: A GPIO LED node that references a GPIO
#include <dt-bindings/gpio/gpio.h>
leds {
compatible = "gpio-leds";
led1 {
gpios = <&pfc 20 GPIO_ACTIVE_LOW>;
};
};
Example 3: KZM-A9-GT (SH-Mobile AG5) default pin state hog and pin control maps
for the MMCIF and SCIFA4 devices
&pfc {
pinctrl-0 = <&scifa4_pins>;
pinctrl-names = "default";
mmcif_pins: mmcif {
mux {
renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0";
renesas,function = "mmc0";
};
cfg {
renesas,groups = "mmc0_data8_0";
renesas,pins = "PORT279";
bias-pull-up;
};
};
scifa4_pins: scifa4 {
renesas,groups = "scifa4_data", "scifa4_ctrl";
renesas,function = "scifa4";
};
};
Example 4: KZM-A9-GT (SH-Mobile AG5) default pin state for the MMCIF device
&mmcif {
pinctrl-0 = <&mmcif_pins>;
pinctrl-names = "default";
bus-width = <8>;
vmmc-supply = <&reg_1p8v>;
status = "okay";
};

97
Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt Normal file
View File

@ -0,0 +1,97 @@
* Rockchip Pinmux Controller
The Rockchip Pinmux Controller, enables the IC
to share one PAD to several functional blocks. The sharing is done by
multiplexing the PAD input/output signals. For each PAD there are up to
4 muxing options with option 0 being the use as a GPIO.
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
The Rockchip pin configuration node is a node of a group of pins which can be
used for a specific device or function. This node represents both mux and
config of the pins in that group. The 'pins' selects the function mode(also
named pin mode) this pin can work on and the 'config' configures various pad
settings such as pull-up, etc.
The pins are grouped into up to 5 individual pin banks which need to be
defined as gpio sub-nodes of the pinmux controller.
Required properties for iomux controller:
- compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl"
"rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl"
Required properties for gpio sub nodes:
- compatible: "rockchip,gpio-bank"
- reg: register of the gpio bank (different than the iomux registerset)
- interrupts: base interrupt of the gpio bank in the interrupt controller
- clocks: clock that drives this bank
- gpio-controller: identifies the node as a gpio controller and pin bank.
- #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
binding is used, the amount of cells must be specified as 2. See generic
GPIO binding documentation for description of particular cells.
- interrupt-controller: identifies the controller node as interrupt-parent.
- #interrupt-cells: the value of this property should be 2 and the interrupt
cells should use the standard two-cell scheme described in
bindings/interrupt-controller/interrupts.txt
Required properties for pin configuration node:
- rockchip,pins: 3 integers array, represents a group of pins mux and config
setting. The format is rockchip,pins = <PIN_BANK PIN_BANK_IDX MUX &phandle>.
The MUX 0 means gpio and MUX 1 to 3 mean the specific device function.
The phandle of a node containing the generic pinconfig options
to use, as described in pinctrl-bindings.txt in this directory.
Examples:
#include <dt-bindings/pinctrl/rockchip.h>
...
pinctrl@20008000 {
compatible = "rockchip,rk3066a-pinctrl";
reg = <0x20008000 0x150>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
gpio0: gpio0@20034000 {
compatible = "rockchip,gpio-bank";
reg = <0x20034000 0x100>;
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk_gates8 9>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
...
pcfg_pull_default: pcfg_pull_default {
bias-pull-pin-default
};
uart2 {
uart2_xfer: uart2-xfer {
rockchip,pins = <RK_GPIO1 8 1 &pcfg_pull_default>,
<RK_GPIO1 9 1 &pcfg_pull_default>;
};
};
};
uart2: serial@20064000 {
compatible = "snps,dw-apb-uart";
reg = <0x20064000 0x400>;
interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <1>;
clocks = <&mux_uart2>;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&uart2_xfer>;
};

352
Documentation/devicetree/bindings/pinctrl/ste,abx500.txt Normal file
View File

@ -0,0 +1,352 @@
ST Ericsson abx500 pinmux controller
Required properties:
- compatible: "stericsson,ab8500-gpio", "stericsson,ab8540-gpio",
"stericsson,ab8505-gpio", "stericsson,ab9540-gpio",
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
ST Ericsson's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration
parameters, such as input, output, pull up, pull down...
The name of each subnode is not important; all subnodes should be enumerated
and processed purely based on their content.
Required subnode-properties:
- ste,pins : An array of strings. Each string contains the name of a pin or
group.
Optional subnode-properties:
- ste,function: A string containing the name of the function to mux to the
pin or group.
- generic pin configuration option to use. Example :
default_cfg {
ste,pins = "GPIO1";
bias-disable;
};
- ste,config: Handle of pin configuration node containing the generic
pinconfig options to use, as described in pinctrl-bindings.txt in
this directory. Example :
pcfg_bias_disable: pcfg_bias_disable {
bias-disable;
};
default_cfg {
ste,pins = "GPIO1";
ste.config = <&pcfg_bias_disable>;
};
Example board file extract:
&pinctrl_abx500 {
pinctrl-names = "default";
pinctrl-0 = <&sysclkreq2_default_mode>, <&sysclkreq3_default_mode>, <&gpio3_default_mode>, <&sysclkreq6_default_mode>, <&pwmout1_default_mode>, <&pwmout2_default_mode>, <&pwmout3_default_mode>, <&adi1_default_mode>, <&dmic12_default_mode>, <&dmic34_default_mode>, <&dmic56_default_mode>, <&sysclkreq5_default_mode>, <&batremn_default_mode>, <&service_default_mode>, <&pwrctrl0_default_mode>, <&pwrctrl1_default_mode>, <&pwmextvibra1_default_mode>, <&pwmextvibra2_default_mode>, <&gpio51_default_mode>, <&gpio52_default_mode>, <&gpio53_default_mode>, <&gpio54_default_mode>, <&pdmclkdat_default_mode>;
sysclkreq2 {
sysclkreq2_default_mode: sysclkreq2_default {
default_mux {
ste,function = "sysclkreq";
ste,pins = "sysclkreq2_d_1";
};
default_cfg {
ste,pins = "GPIO1";
bias-disable;
};
};
};
sysclkreq3 {
sysclkreq3_default_mode: sysclkreq3_default {
default_mux {
ste,function = "sysclkreq";
ste,pins = "sysclkreq3_d_1";
};
default_cfg {
ste,pins = "GPIO2";
output-low;
};
};
};
gpio3 {
gpio3_default_mode: gpio3_default {
default_mux {
ste,function = "gpio";
ste,pins = "gpio3_a_1";
};
default_cfg {
ste,pins = "GPIO3";
output-low;
};
};
};
sysclkreq6 {
sysclkreq6_default_mode: sysclkreq6_default {
default_mux {
ste,function = "sysclkreq";
ste,pins = "sysclkreq6_d_1";
};
default_cfg {
ste,pins = "GPIO4";
bias-disable;
};
};
};
pwmout1 {
pwmout1_default_mode: pwmout1_default {
default_mux {
ste,function = "pwmout";
ste,pins = "pwmout1_d_1";
};
default_cfg {
ste,pins = "GPIO14";
output-low;
};
};
};
pwmout2 {
pwmout2_default_mode: pwmout2_default {
pwmout2_default_mux {
ste,function = "pwmout";
ste,pins = "pwmout2_d_1";
};
pwmout2_default_cfg {
ste,pins = "GPIO15";
output-low;
};
};
};
pwmout3 {
pwmout3_default_mode: pwmout3_default {
pwmout3_default_mux {
ste,function = "pwmout";
ste,pins = "pwmout3_d_1";
};
pwmout3_default_cfg {
ste,pins = "GPIO16";
output-low;
};
};
};
adi1 {
adi1_default_mode: adi1_default {
adi1_default_mux {
ste,function = "adi1";
ste,pins = "adi1_d_1";
};
adi1_default_cfg1 {
ste,pins = "GPIO17","GPIO19","GPIO20";
bias-disable;
};
adi1_default_cfg2 {
ste,pins = "GPIO18";
output-low;
};
};
};
dmic12 {
dmic12_default_mode: dmic12_default {
dmic12_default_mux {
ste,function = "dmic";
ste,pins = "dmic12_d_1";
};
dmic12_default_cfg1 {
ste,pins = "GPIO27";
output-low;
};
dmic12_default_cfg2 {
ste,pins = "GPIO28";
bias-disable;
};
};
};
dmic34 {
dmic34_default_mode: dmic34_default {
dmic34_default_mux {
ste,function = "dmic";
ste,pins = "dmic34_d_1";
};
dmic34_default_cfg1 {
ste,pins = "GPIO29";
output-low;
};
dmic34_default_cfg2 {
ste,pins = "GPIO30";
bias-disable;{
};
};
};
dmic56 {
dmic56_default_mode: dmic56_default {
dmic56_default_mux {
ste,function = "dmic";
ste,pins = "dmic56_d_1";
};
dmic56_default_cfg1 {
ste,pins = "GPIO31";
output-low;
};
dmic56_default_cfg2 {
ste,pins = "GPIO32";
bias-disable;
};
};
};
sysclkreq5 {
sysclkreq5_default_mode: sysclkreq5_default {
sysclkreq5_default_mux {
ste,function = "sysclkreq";
ste,pins = "sysclkreq5_d_1";
};
sysclkreq5_default_cfg {
ste,pins = "GPIO42";
output-low;
};
};
};
batremn {
batremn_default_mode: batremn_default {
batremn_default_mux {
ste,function = "batremn";
ste,pins = "batremn_d_1";
};
batremn_default_cfg {
ste,pins = "GPIO43";
bias-disable;
};
};
};
service {
service_default_mode: service_default {
service_default_mux {
ste,function = "service";
ste,pins = "service_d_1";
};
service_default_cfg {
ste,pins = "GPIO44";
bias-disable;
};
};
};
pwrctrl0 {
pwrctrl0_default_mux: pwrctrl0_mux {
pwrctrl0_default_mux {
ste,function = "pwrctrl";
ste,pins = "pwrctrl0_d_1";
};
};
pwrctrl0_default_mode: pwrctrl0_default {
pwrctrl0_default_cfg {
ste,pins = "GPIO45";
bias-disable;
};
};
};
pwrctrl1 {
pwrctrl1_default_mux: pwrctrl1_mux {
pwrctrl1_default_mux {
ste,function = "pwrctrl";
ste,pins = "pwrctrl1_d_1";
};
};
pwrctrl1_default_mode: pwrctrl1_default {
pwrctrl1_default_cfg {
ste,pins = "GPIO46";
bias-disable;
};
};
};
pwmextvibra1 {
pwmextvibra1_default_mode: pwmextvibra1_default {
pwmextvibra1_default_mux {
ste,function = "pwmextvibra";
ste,pins = "pwmextvibra1_d_1";
};
pwmextvibra1_default_cfg {
ste,pins = "GPIO47";
bias-disable;
};
};
};
pwmextvibra2 {
pwmextvibra2_default_mode: pwmextvibra2_default {
pwmextvibra2_default_mux {
ste,function = "pwmextvibra";
ste,pins = "pwmextvibra2_d_1";
};
pwmextvibra1_default_cfg {
ste,pins = "GPIO48";
bias-disable;
};
};
};
gpio51 {
gpio51_default_mode: gpio51_default {
gpio51_default_mux {
ste,function = "gpio";
ste,pins = "gpio51_a_1";
};
gpio51_default_cfg {
ste,pins = "GPIO51";
output-low;
};
};
};
gpio52 {
gpio52_default_mode: gpio52_default {
gpio52_default_mux {
ste,function = "gpio";
ste,pins = "gpio52_a_1";
};
gpio52_default_cfg {
ste,pins = "GPIO52";
bias-pull-down;
};
};
};
gpio53 {
gpio53_default_mode: gpio53_default {
gpio53_default_mux {
ste,function = "gpio";
ste,pins = "gpio53_a_1";
};
gpio53_default_cfg {
ste,pins = "GPIO53";
bias-pull-down;
};
};
};
gpio54 {
gpio54_default_mode: gpio54_default {
gpio54_default_mux {
ste,function = "gpio";
ste,pins = "gpio54_a_1";
};
gpio54_default_cfg {
ste,pins = "GPIO54";
output-low;
};
};
};
pdmclkdat {
pdmclkdat_default_mode: pdmclkdat_default {
pdmclkdat_default_mux {
ste,function = "pdm";
ste,pins = "pdmclkdat_d_1";
};
pdmclkdat_default_cfg {
ste,pins = "GPIO55", "GPIO56";
bias-disable;
};
};
};
};

20
Documentation/devicetree/bindings/pps/pps-gpio.txt Normal file
View File

@ -0,0 +1,20 @@
Device-Tree Bindings for a PPS Signal on GPIO
These properties describe a PPS (pulse-per-second) signal connected to
a GPIO pin.
Required properties:
- compatible: should be "pps-gpio"
- gpios: one PPS GPIO in the format described by ../gpio/gpio.txt
Optional properties:
- assert-falling-edge: when present, assert is indicated by a falling edge
(instead of by a rising edge)
Example:
pps {
compatible = "pps-gpio";
gpios = <&gpio2 6 0>;
assert-falling-edge;
};

160
Documentation/devicetree/bindings/regulator/lp872x.txt Normal file
View File

@ -0,0 +1,160 @@
Binding for TI/National Semiconductor LP872x Driver
Required properties:
- compatible: "ti,lp8720" or "ti,lp8725"
- reg: I2C slave address. 0x7d = LP8720, 0x7a = LP8725
Optional properties:
- ti,general-config: the value of LP872X_GENERAL_CFG register (u8)
(LP8720)
bit[2]: BUCK output voltage control by external DVS pin or register
1 = external pin, 0 = bit7 of register 08h
bit[1]: sleep control by external DVS pin or register
1 = external pin, 0 = bit6 of register 08h
bit[0]: time step unit(usec). 1 = 25, 0 = 50
(LP8725)
bit[7:6]: time step unit(usec). 00 = 32, 01 = 64, 10 = 128, 11 = 256
bit[4]: BUCK2 enable control. 1 = enable, 0 = disable
bit[3]: BUCK2 output voltage register address. 1 = 0Ah, 0 = 0Bh
bit[2]: BUCK1 output voltage control by external DVS pin or register
1 = register 08h, 0 = DVS
bit[1]: LDO sleep control. 1 = sleep mode, 0 = normal
bit[0]: BUCK1 enable control, 1 = enable, 0 = disable
For more details, please see the datasheet.
- ti,update-config: define it when LP872X_GENERAL_CFG register should be set
- ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices.
- ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
- ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
Sub nodes for regulator_init_data
LP8720 has maximum 6 nodes. (child name: ldo1 ~ 5 and buck)
LP8725 has maximum 9 nodes. (child name: ldo1 ~ 5, lilo1,2 and buck1,2)
For more details, please see the following binding document.
(Documentation/devicetree/bindings/regulator/regulator.txt)
Datasheet
- LP8720: http://www.ti.com/lit/ds/symlink/lp8720.pdf
- LP8725: http://www.ti.com/lit/ds/symlink/lp8725.pdf
Example 1) LP8720
lp8720@7d {
compatible = "ti,lp8720";
reg = <0x7d>;
/* external DVS pin used, timestep is 25usec */
ti,general-config = /bits/ 8 <0x03>;
ti,update-config;
/*
* The dvs-gpio depends on the processor environment.
* For example, following GPIO specifier means GPIO134 in OMAP4.
*/
ti,dvs-gpio = <&gpio5 6 0>;
ti,dvs-vsel = /bits/ 8 <1>; /* SEL_V2 */
ti,dvs-state = /bits/ 8 <1>; /* DVS_HIGH */
vaf: ldo1 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vmmc: ldo2 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vcam_io: ldo3 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
};
vcam_core: ldo4 {
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <2850000>;
regulator-boot-on;
};
vcam: ldo5 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vcc: buck {
regulator-name = "VBUCK";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <2300000>;
};
};
Example 2) LP8725
lp8725@7a {
compatible = "ti,lp8725";
reg = <0x7a>;
/* Enable BUCK1,2, no DVS, normal LDO mode, timestep is 256usec */
ti,general-config = /bits/ 8 <0xdd>;
ti,update-config;
vcam_io: ldo1 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vcam_core: ldo2 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vcam: ldo3 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vcmmb_io: ldo4 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
};
vcmmb_core: ldo5 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
};
vaux1: lilo1 {
regulator-name = "VAUX1";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3300000>;
};
vaux2: lilo2 {
regulator-name = "VAUX2";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3300000>;
};
vcc1: buck1 {
regulator-name = "VBUCK1";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3000000>;
regulator-min-microamp = <460000>;
regulator-max-microamp = <1370000>;
regulator-boot-on;
};
vcc2: buck2 {
regulator-name = "VBUCK2";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3000000>;
regulator-min-microamp = <460000>;
regulator-max-microamp = <1370000>;
regulator-boot-on;
};
};

21
Documentation/devicetree/bindings/regulator/max8973-regulator.txt Normal file
View File

@ -0,0 +1,21 @@
* Maxim MAX8973 Voltage Regulator
Required properties:
- compatible: must be "maxim,max8973"
- reg: the i2c slave address of the regulator. It should be 0x1b.
Any standard regulator properties can be used to configure the single max8973
DCDC.
Example:
max8973@1b {
compatible = "maxim,max8973";
reg = <0x1b>;
regulator-min-microvolt = <935000>;
regulator-max-microvolt = <1200000>;
regulator-boot-on;
regulator-always-on;
};

1
Documentation/devicetree/bindings/regulator/regulator.txt
View File

@ -9,6 +9,7 @@ Optional properties:
- regulator-max-microamp: largest current consumers may set
- regulator-always-on: boolean, regulator should never be disabled
- regulator-boot-on: bootloader/firmware enabled regulator
- regulator-allow-bypass: allow the regulator to go into bypass mode
- <name>-supply: phandle to the parent supply/regulator node
- regulator-ramp-delay: ramp delay for regulator(in uV/uS)

128
Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt Normal file
View File

@ -0,0 +1,128 @@
Adaptive Body Bias(ABB) SoC internal LDO regulator for Texas Instruments SoCs
Required Properties:
- compatible: Should be one of:
- "ti,abb-v1" for older SoCs like OMAP3
- "ti,abb-v2" for newer SoCs like OMAP4, OMAP5
- reg: Address and length of the register set for the device. It contains
the information of registers in the same order as described by reg-names
- reg-names: Should contain the reg names
- "base-address" - contains base address of ABB module
- "int-address" - contains address of interrupt register for ABB module
(also see Optional properties)
- #address-cell: should be 0
- #size-cell: should be 0
- clocks: should point to the clock node used by ABB module
- ti,settling-time: Settling time in uSecs from SoC documentation for ABB module
to settle down(target time for SR2_WTCNT_VALUE).
- ti,clock-cycles: SoC specific data about count of system ti,clock-cycles used for
computing settling time from SoC Documentation for ABB module(clock
cycles for SR2_WTCNT_VALUE).
- ti,tranxdone-status-mask: Mask to the int-register to write-to-clear mask
indicating LDO tranxdone (operation complete).
- ti,abb_info: An array of 6-tuples u32 items providing information about ABB
configuration needed per operational voltage of the device.
Each item consists of the following in the same order:
volt: voltage in uV - Only used to index ABB information.
ABB mode: one of the following:
0-bypass
1-Forward Body Bias(FBB)
3-Reverse Body Bias(RBB)
efuse: (see Optional properties)
RBB enable efuse Mask: (See Optional properties)
FBB enable efuse Mask: (See Optional properties)
Vset value efuse Mask: (See Optional properties)
NOTE: If more than 1 entry is present, then regulator is setup to change
voltage, allowing for various modes to be selected indexed off
the regulator. Further, ABB LDOs are considered always-on by
default.
Optional Properties:
- reg-names: In addition to the required properties, the following are optional
- "efuse-address" - Contains efuse base address used to pick up ABB info.
- "ldo-address" - Contains address of ABB LDO overide register address.
"efuse-address" is required for this.
- ti,ldovbb-vset-mask - Required if ldo-address is set, mask for LDO override
register to provide override vset value.
- ti,ldovbb-override-mask - Required if ldo-address is set, mask for LDO
override register to enable override vset value.
- ti,abb_opp_sel: Addendum to the description in required properties
efuse: Mandatory if 'efuse-address' register is defined. Provides offset
from efuse-address to pick up ABB characteristics. Set to 0 if
'efuse-address' is not defined.
RBB enable efuse Mask: Optional if 'efuse-address' register is defined.
'ABB mode' is force set to RBB mode if value at "efuse-address"
+ efuse maps to RBB mask. Set to 0 to ignore this.
FBB enable efuse Mask: Optional if 'efuse-address' register is defined.
'ABB mode' is force set to FBB mode if value at "efuse-address"
+ efuse maps to FBB mask (valid only if RBB mask does not match)
Set to 0 to ignore this.
Vset value efuse Mask: Mandatory if ldo-address is set. Picks up from
efuse the value to set in 'ti,ldovbb-vset-mask' at ldo-address.
Example #1: Simplest configuration (no efuse data, hard coded ABB table):
abb_x: regulator-abb-x {
compatible = "ti,abb-v1";
regulator-name = "abb_x";
#address-cell = <0>;
#size-cells = <0>;
reg = <0x483072f0 0x8>, <0x48306818 0x4>;
reg-names = "base-address", "int-address";
ti,tranxdone-status-mask = <0x4000000>;
clocks = <&sysclk>;
ti,settling-time = <30>;
ti,clock-cycles = <8>;
ti,abb_info = <
/* uV ABB efuse rbb_m fbb_m vset_m */
1012500 0 0 0 0 0 /* Bypass */
1200000 3 0 0 0 0 /* RBB mandatory */
1320000 1 0 0 0 0 /* FBB mandatory */
>;
};
Example #2: Efuse bits contain ABB mode setting (no LDO override capability)
abb_y: regulator-abb-y {
compatible = "ti,abb-v2";
regulator-name = "abb_y";
#address-cell = <0>;
#size-cells = <0>;
reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>, <0x4A002268 0x8>;
reg-names = "base-address", "int-address", "efuse-address";
ti,tranxdone-status-mask = <0x4000000>;
clocks = <&sysclk>;
ti,settling-time = <50>;
ti,clock-cycles = <16>;
ti,abb_info = <
/* uV ABB efuse rbb_m fbb_m vset_m */
975000 0 0 0 0 0 /* Bypass */
1012500 0 0 0x40000 0 0 /* RBB optional */
1200000 0 0x4 0 0x40000 0 /* FBB optional */
1320000 1 0 0 0 0 /* FBB mandatory */
>;
};
Example #3: Efuse bits contain ABB mode setting and LDO override capability
abb_z: regulator-abb-z {
compatible = "ti,abb-v2";
regulator-name = "abb_z";
#address-cell = <0>;
#size-cells = <0>;
reg = <0x4ae07ce4 0x8>, <0x4ae06010 0x4>,
<0x4a002194 0x8>, <0x4ae0C314 0x4>;
reg-names = "base-address", "int-address",
"efuse-address", "ldo-address";
ti,tranxdone-status-mask = <0x8000000>;
/* LDOVBBMM_MUX_CTRL */
ti,ldovbb-override-mask = <0x400>;
/* LDOVBBMM_VSET_OUT */
ti,ldovbb-vset-mask = <0x1F>;
clocks = <&sysclk>;
ti,settling-time = <50>;
ti,clock-cycles = <16>;
ti,abb_info = <
/* uV ABB efuse rbb_m fbb_m vset_m */
975000 0 0 0 0 0 /* Bypass */
1200000 0 0x4 0 0x40000 0x1f00 /* FBB optional, vset */
>;
};

35
Documentation/devicetree/bindings/sound/adi,adau1701.txt Normal file
View File

@ -0,0 +1,35 @@
Analog Devices ADAU1701
Required properties:
- compatible: Should contain "adi,adau1701"
- reg: The i2c address. Value depends on the state of ADDR0
and ADDR1, as wired in hardware.
Optional properties:
- reset-gpio: A GPIO spec to define which pin is connected to the
chip's !RESET pin. If specified, the driver will
assert a hardware reset at probe time.
- adi,pll-mode-gpios: An array of two GPIO specs to describe the GPIOs
the ADAU's PLL config pins are connected to.
The state of the pins are set according to the
configured clock divider on ASoC side before the
firmware is loaded.
- adi,pin-config: An array of 12 numerical values selecting one of the
pin configurations as described in the datasheet,
table 53. Note that the value of this property has
to be prefixed with '/bits/ 8'.
Examples:
i2c_bus {
adau1701@34 {
compatible = "adi,adau1701";
reg = <0x34>;
reset-gpio = <&gpio 23 0>;
adi,pll-mode-gpios = <&gpio 24 0 &gpio 25 0>;
adi,pin-config = /bits/ 8 <0x4 0x7 0x5 0x5 0x4 0x4
0x4 0x4 0x4 0x4 0x4 0x4>;
};
};

46
Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt Normal file
View File

@ -0,0 +1,46 @@
Freescale i.MX audio complex with WM8962 codec
Required properties:
- compatible : "fsl,imx-audio-wm8962"
- model : The user-visible name of this sound complex
- ssi-controller : The phandle of the i.MX SSI controller
- audio-codec : The phandle of the WM8962 audio codec
- audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
the second being the connection's source. Valid names could be power
supplies, WM8962 pins, and the jacks on the board:
Power supplies:
* Mic Bias
Board connectors:
* Mic Jack
* Headphone Jack
* Ext Spk
- mux-int-port : The internal port of the i.MX audio muxer (AUDMUX)
- mux-ext-port : The external port of the i.MX audio muxer
Note: The AUDMUX port numbering should start at 1, which is consistent with
hardware manual.
Example:
sound {
compatible = "fsl,imx6q-sabresd-wm8962",
"fsl,imx-audio-wm8962";
model = "wm8962-audio";
ssi-controller = <&ssi2>;
audio-codec = <&codec>;
audio-routing =
"Headphone Jack", "HPOUTL",
"Headphone Jack", "HPOUTR",
"Ext Spk", "SPKOUTL",
"Ext Spk", "SPKOUTR",
"MICBIAS", "AMIC",
"IN3R", "MICBIAS",
"DMIC", "MICBIAS",
"DMICDAT", "DMIC";
mux-int-port = <2>;
mux-ext-port = <3>;
};

17
Documentation/devicetree/bindings/sound/mxs-saif.txt
View File

@ -3,8 +3,11 @@
Required properties:
- compatible: Should be "fsl,<chip>-saif"
- reg: Should contain registers location and length
- interrupts: Should contain ERROR and DMA interrupts
- fsl,saif-dma-channel: APBX DMA channel for the SAIF
- interrupts: Should contain ERROR interrupt number
- dmas: DMA specifier, consisting of a phandle to DMA controller node
and SAIF DMA channel ID.
Refer to dma.txt and fsl-mxs-dma.txt for details.
- dma-names: Must be "rx-tx".
Optional properties:
- fsl,saif-master: phandle to the master SAIF. It's only required for
@ -23,14 +26,16 @@ aliases {
saif0: saif@80042000 {
compatible = "fsl,imx28-saif";
reg = <0x80042000 2000>;
interrupts = <59 80>;
fsl,saif-dma-channel = <4>;
interrupts = <59>;
dmas = <&dma_apbx 4>;
dma-names = "rx-tx";
};
saif1: saif@80046000 {
compatible = "fsl,imx28-saif";
reg = <0x80046000 2000>;
interrupts = <58 81>;
fsl,saif-dma-channel = <5>;
interrupts = <58>;
dmas = <&dma_apbx 5>;
dma-names = "rx-tx";
fsl,saif-master = <&saif0>;
};

71
Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt Normal file
View File

@ -0,0 +1,71 @@
NVIDIA Tegra audio complex, with RT5640 CODEC
Required properties:
- compatible : "nvidia,tegra-audio-rt5640"
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
"pll_a" (The Tegra clock of that name),
"pll_a_out0" (The Tegra clock of that name),
"mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
- nvidia,model : The user-visible name of this sound complex.
- nvidia,audio-routing : A list of the connections between audio components.
Each entry is a pair of strings, the first being the connection's sink,
the second being the connection's source. Valid names for sources and
sinks are the RT5640's pins, and the jacks on the board:
RT5640 pins:
* DMIC1
* DMIC2
* MICBIAS1
* IN1P
* IN1R
* IN2P
* IN2R
* HPOL
* HPOR
* LOUTL
* LOUTR
* MONOP
* MONON
* SPOLP
* SPOLN
* SPORP
* SPORN
Board connectors:
* Headphones
* Speakers
- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's
connected to the CODEC.
- nvidia,audio-codec : The phandle of the RT5640 audio codec. This binding
assumes that AIF1 on the CODEC is connected to Tegra.
Optional properties:
- nvidia,hp-det-gpios : The GPIO that detects headphones are plugged in
Example:
sound {
compatible = "nvidia,tegra-audio-rt5640-dalmore",
"nvidia,tegra-audio-rt5640";
nvidia,model = "NVIDIA Tegra Dalmore";
nvidia,audio-routing =
"Headphones", "HPOR",
"Headphones", "HPOL",
"Speakers", "SPORP",
"Speakers", "SPORN",
"Speakers", "SPOLP",
"Speakers", "SPOLN";
nvidia,i2s-controller = <&tegra_i2s1>;
nvidia,audio-codec = <&rt5640>;
nvidia,hp-det-gpios = <&gpio 143 0>; /* GPIO PR7 */
clocks = <&tegra_car 216>, <&tegra_car 217>, <&tegra_car 120>;
clock-names = "pll_a", "pll_a_out0", "mclk";
};

30
Documentation/devicetree/bindings/sound/rt5640.txt Normal file
View File

@ -0,0 +1,30 @@
RT5640 audio CODEC
This device supports I2C only.
Required properties:
- compatible : "realtek,rt5640".
- reg : The I2C address of the device.
- interrupts : The CODEC's interrupt output.
Optional properties:
- realtek,in1-differential
- realtek,in2-differential
Boolean. Indicate MIC1/2 input are differential, rather than single-ended.
- realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin.
Example:
rt5640 {
compatible = "realtek,rt5640";
reg = <0x1c>;
interrupt-parent = <&gpio>;
interrupts = <TEGRA_GPIO(W, 3) GPIO_ACTIVE_HIGH>;
realtek,ldo1-en-gpios =
<&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
};

3
Documentation/devicetree/bindings/sound/sgtl5000.txt
View File

@ -5,9 +5,12 @@ Required properties:
- reg : the I2C address of the device
- clocks : the clock provider of SYS_MCLK
Example:
codec: sgtl5000@0a {
compatible = "fsl,sgtl5000";
reg = <0x0a>;
clocks = <&clks 150>;
};

10
Documentation/devicetree/bindings/sound/spdif-receiver.txt Normal file
View File

@ -0,0 +1,10 @@
Device-Tree bindings for dummy spdif receiver
Required properties:
- compatible: should be "linux,spdif-dir".
Example node:
codec: spdif-receiver {
compatible = "linux,spdif-dir";
};

10
Documentation/devicetree/bindings/sound/spdif-transmitter.txt Normal file
View File

@ -0,0 +1,10 @@
Device-Tree bindings for dummy spdif transmitter
Required properties:
- compatible: should be "linux,spdif-dit".
Example node:
codec: spdif-transmitter {
compatible = "linux,spdif-dit";
};

20
Documentation/devicetree/bindings/sound/ssm2518.txt Normal file
View File

@ -0,0 +1,20 @@
SSM2518 audio amplifier
This device supports I2C only.
Required properties:
- compatible : Must be "adi,ssm2518"
- reg : the I2C address of the device. This will either be 0x34 (ADDR pin low)
or 0x35 (ADDR pin high)
Optional properties:
- gpios : GPIO connected to the nSD pin. If the property is not present it is
assumed that the nSD pin is hardwired to always on.
Example:
ssm2518: ssm2518@34 {
compatible = "adi,ssm2518";
reg = <0x34>;
gpios = <&gpio 5 0>;
};

11
Documentation/devicetree/bindings/sound/ti,tas5086.txt
View File

@ -20,6 +20,17 @@ Optional properties:
When not specified, the hardware default of 1300ms
is retained.
- ti,mid-z-channel-X: Boolean properties, X being a number from 1 to 6.
If given, channel X will start with the Mid-Z start
sequence, otherwise the default Low-Z scheme is used.
The correct configuration depends on how the power
stages connected to the PWM output pins work. Not all
power stages are compatible to Mid-Z - please refer
to the datasheets for more details.
Most systems should not set any of these properties.
Examples:
i2c_bus {

23
Documentation/devicetree/bindings/sound/wm8962.txt
View File

@ -8,9 +8,32 @@ Required properties:
- reg : the I2C address of the device.
Optional properties:
- spk-mono: This is a boolean property. If present, the SPK_MONO bit
of R51 (Class D Control 2) gets set, indicating that the speaker is
in mono mode.
- mic-cfg : Default register value for R48 (Additional Control 4).
If absent, the default should be the register default.
- gpio-cfg : A list of GPIO configuration register values. The list must
be 6 entries long. If absent, no configuration of these registers is
performed. And note that only the value within [0x0, 0xffff] is valid.
Any other value is regarded as setting the GPIO register by its reset
value 0x0.
Example:
codec: wm8962@1a {
compatible = "wlf,wm8962";
reg = <0x1a>;
gpio-cfg = <
0x0000 /* 0:Default */
0x0000 /* 1:Default */
0x0013 /* 2:FN_DMICCLK */
0x0000 /* 3:Default */
0x8014 /* 4:FN_DMICCDAT */
0x0000 /* 5:Default */
>;
};

27
Documentation/devicetree/bindings/spi/omap-spi.txt
View File

@ -10,7 +10,18 @@ Required properties:
input. The default is D0 as input and
D1 as output.
Example:
Optional properties:
- dmas: List of DMA specifiers with the controller specific format
as described in the generic DMA client binding. A tx and rx
specifier is required for each chip select.
- dma-names: List of DMA request names. These strings correspond
1:1 with the DMA specifiers listed in dmas. The string naming
is to be "rxN" and "txN" for RX and TX requests,
respectively, where N equals the chip select number.
Examples:
[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = <1>;
@ -20,3 +31,17 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = <4>;
};
[generic DMA request binding]
mcspi1: mcspi@1 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "ti,omap4-mcspi";
ti,hwmods = "mcspi1";
ti,spi-num-cs = <2>;
dmas = <&edma 42
&edma 43
&edma 44
&edma 45>;
dma-names = "tx0", "rx0", "tx1", "rx1";
};

35
Documentation/filesystems/Locking
View File

@ -11,10 +11,8 @@ be able to use diff(1).
prototypes:
int (*d_revalidate)(struct dentry *, unsigned int);
int (*d_weak_revalidate)(struct dentry *, unsigned int);
int (*d_hash)(const struct dentry *, const struct inode *,
struct qstr *);
int (*d_compare)(const struct dentry *, const struct inode *,
const struct dentry *, const struct inode *,
int (*d_hash)(const struct dentry *, struct qstr *);
int (*d_compare)(const struct dentry *, const struct dentry *,
unsigned int, const char *, const struct qstr *);
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
@ -66,6 +64,7 @@ prototypes:
int (*atomic_open)(struct inode *, struct dentry *,
struct file *, unsigned open_flag,
umode_t create_mode, int *opened);
int (*tmpfile) (struct inode *, struct dentry *, umode_t);
locking rules:
all may block
@ -93,6 +92,7 @@ removexattr: yes
fiemap: no
update_time: no
atomic_open: yes
tmpfile: no
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
victim.
@ -344,25 +344,38 @@ prototypes:
locking rules:
file_lock_lock may block
inode->i_lock may block
fl_copy_lock: yes no
fl_release_private: maybe no
----------------------- lock_manager_operations ---------------------------
prototypes:
int (*lm_compare_owner)(struct file_lock *, struct file_lock *);
unsigned long (*lm_owner_key)(struct file_lock *);
void (*lm_notify)(struct file_lock *); /* unblock callback */
int (*lm_grant)(struct file_lock *, struct file_lock *, int);
void (*lm_break)(struct file_lock *); /* break_lease callback */
int (*lm_change)(struct file_lock **, int);
locking rules:
file_lock_lock may block
lm_compare_owner: yes no
lm_notify: yes no
lm_grant: no no
lm_break: yes no
lm_change yes no
inode->i_lock blocked_lock_lock may block
lm_compare_owner: yes[1] maybe no
lm_owner_key yes[1] yes no
lm_notify: yes yes no
lm_grant: no no no
lm_break: yes no no
lm_change yes no no
[1]: ->lm_compare_owner and ->lm_owner_key are generally called with
*an* inode->i_lock held. It may not be the i_lock of the inode
associated with either file_lock argument! This is the case with deadlock
detection, since the code has to chase down the owners of locks that may
be entirely unrelated to the one on which the lock is being acquired.
For deadlock detection however, the blocked_lock_lock is also held. The
fact that these locks are held ensures that the file_locks do not
disappear out from under you while doing the comparison or generating an
owner key.
--------------------------- buffer_head -----------------------------------
prototypes:

7
Documentation/filesystems/proc.txt
View File

@ -473,7 +473,8 @@ This file is only present if the CONFIG_MMU kernel configuration option is
enabled.
The /proc/PID/clear_refs is used to reset the PG_Referenced and ACCESSED/YOUNG
bits on both physical and virtual pages associated with a process.
bits on both physical and virtual pages associated with a process, and the
soft-dirty bit on pte (see Documentation/vm/soft-dirty.txt for details).
To clear the bits for all the pages associated with the process
> echo 1 > /proc/PID/clear_refs
@ -482,6 +483,10 @@ To clear the bits for the anonymous pages associated with the process
To clear the bits for the file mapped pages associated with the process
> echo 3 > /proc/PID/clear_refs
To clear the soft-dirty bit
> echo 4 > /proc/PID/clear_refs
Any other value written to /proc/PID/clear_refs will have no effect.
The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags

49
Documentation/filesystems/vfs.txt
View File

@ -360,6 +360,8 @@ struct inode_operations {
int (*removexattr) (struct dentry *, const char *);
void (*update_time)(struct inode *, struct timespec *, int);
int (*atomic_open)(struct inode *, struct dentry *,
int (*tmpfile) (struct inode *, struct dentry *, umode_t);
} ____cacheline_aligned;
struct file *, unsigned open_flag,
umode_t create_mode, int *opened);
};
@ -472,6 +474,9 @@ otherwise noted.
component is negative or needs lookup. Cached positive dentries are
still handled by f_op->open().
tmpfile: called in the end of O_TMPFILE open(). Optional, equivalent to
atomically creating, opening and unlinking a file in given directory.
The Address Space Object
========================
@ -554,7 +559,6 @@ your filesystem. The following members are defined:
struct address_space_operations {
int (*writepage)(struct page *page, struct writeback_control *wbc);
int (*readpage)(struct file *, struct page *);
int (*sync_page)(struct page *);
int (*writepages)(struct address_space *, struct writeback_control *);
int (*set_page_dirty)(struct page *page);
int (*readpages)(struct file *filp, struct address_space *mapping,
@ -576,6 +580,9 @@ struct address_space_operations {
/* migrate the contents of a page to the specified target */
int (*migratepage) (struct page *, struct page *);
int (*launder_page) (struct page *);
int (*is_partially_uptodate) (struct page *, read_descriptor_t *,
unsigned long);
void (*is_dirty_writeback) (struct page *, bool *, bool *);
int (*error_remove_page) (struct mapping *mapping, struct page *page);
int (*swap_activate)(struct file *);
int (*swap_deactivate)(struct file *);
@ -607,13 +614,6 @@ struct address_space_operations {
In this case, the page will be relocated, relocked and if
that all succeeds, ->readpage will be called again.
sync_page: called by the VM to notify the backing store to perform all
queued I/O operations for a page. I/O operations for other pages
associated with this address_space object may also be performed.
This function is optional and is called only for pages with
PG_Writeback set while waiting for the writeback to complete.
writepages: called by the VM to write out pages associated with the
address_space object. If wbc->sync_mode is WBC_SYNC_ALL, then
the writeback_control will specify a range of pages that must be
@ -742,6 +742,20 @@ struct address_space_operations {
prevent redirtying the page, it is kept locked during the whole
operation.
is_partially_uptodate: Called by the VM when reading a file through the
pagecache when the underlying blocksize != pagesize. If the required
block is up to date then the read can complete without needing the IO
to bring the whole page up to date.
is_dirty_writeback: Called by the VM when attempting to reclaim a page.
The VM uses dirty and writeback information to determine if it needs
to stall to allow flushers a chance to complete some IO. Ordinarily
it can use PageDirty and PageWriteback but some filesystems have
more complex state (unstable pages in NFS prevent reclaim) or
do not set those flags due to locking problems (jbd). This callback
allows a filesystem to indicate to the VM if a page should be
treated as dirty or writeback for the purposes of stalling.
error_remove_page: normally set to generic_error_remove_page if truncation
is ok for this address space. Used for memory failure handling.
Setting this implies you deal with pages going away under you,
@ -901,10 +915,8 @@ defined:
struct dentry_operations {
int (*d_revalidate)(struct dentry *, unsigned int);
int (*d_weak_revalidate)(struct dentry *, unsigned int);
int (*d_hash)(const struct dentry *, const struct inode *,
struct qstr *);
int (*d_compare)(const struct dentry *, const struct inode *,
const struct dentry *, const struct inode *,
int (*d_hash)(const struct dentry *, struct qstr *);
int (*d_compare)(const struct dentry *, const struct dentry *,
unsigned int, const char *, const struct qstr *);
int (*d_delete)(const struct dentry *);
void (*d_release)(struct dentry *);
@ -949,25 +961,24 @@ struct dentry_operations {
d_hash: called when the VFS adds a dentry to the hash table. The first
dentry passed to d_hash is the parent directory that the name is
to be hashed into. The inode is the dentry's inode.
to be hashed into.
Same locking and synchronisation rules as d_compare regarding
what is safe to dereference etc.
d_compare: called to compare a dentry name with a given name. The first
dentry is the parent of the dentry to be compared, the second is
the parent's inode, then the dentry and inode (may be NULL) of the
child dentry. len and name string are properties of the dentry to be
compared. qstr is the name to compare it with.
the child dentry. len and name string are properties of the dentry
to be compared. qstr is the name to compare it with.
Must be constant and idempotent, and should not take locks if
possible, and should not or store into the dentry or inodes.
Should not dereference pointers outside the dentry or inodes without
possible, and should not or store into the dentry.
Should not dereference pointers outside the dentry without
lots of care (eg. d_parent, d_inode, d_name should not be used).
However, our vfsmount is pinned, and RCU held, so the dentries and
inodes won't disappear, neither will our sb or filesystem module.
->i_sb and ->d_sb may be used.
->d_sb may be used.
It is a tricky calling convention because it needs to be called under
"rcu-walk", ie. without any locks or references on things.

144
Documentation/hwmon/ds1621
View File

@ -2,16 +2,30 @@ Kernel driver ds1621
====================
Supported chips:
* Dallas Semiconductor DS1621
* Dallas Semiconductor / Maxim Integrated DS1621
Prefix: 'ds1621'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Dallas Semiconductor website
http://www.dalsemi.com/
Addresses scanned: none
Datasheet: Publicly available from www.maximintegrated.com
* Dallas Semiconductor DS1625
Prefix: 'ds1621'
Addresses scanned: I2C 0x48 - 0x4f
Datasheet: Publicly available at the Dallas Semiconductor website
http://www.dalsemi.com/
Prefix: 'ds1625'
Addresses scanned: none
Datasheet: Publicly available from www.datasheetarchive.com
* Maxim Integrated DS1631
Prefix: 'ds1631'
Addresses scanned: none
Datasheet: Publicly available from www.maximintegrated.com
* Maxim Integrated DS1721
Prefix: 'ds1721'
Addresses scanned: none
Datasheet: Publicly available from www.maximintegrated.com
* Maxim Integrated DS1731
Prefix: 'ds1731'
Addresses scanned: none
Datasheet: Publicly available from www.maximintegrated.com
Authors:
Christian W. Zuckschwerdt <zany@triq.net>
@ -59,5 +73,115 @@ any of the limits have ever been met or exceeded since last power-up or
reset. Be aware: When testing, it showed that the status of Tout can change
with neither of the alarms set.
Temperature conversion of the DS1621 takes up to 1000ms; internal access to
non-volatile registers may last for 10ms or below.
Since there is no version or vendor identification register, there is
no unique identification for these devices. Therefore, explicit device
instantiation is required for correct device identification and functionality
(one device per address in this address range: 0x48..0x4f).
The DS1625 is pin compatible and functionally equivalent with the DS1621,
but the DS1621 is meant to replace it. The DS1631, DS1721, and DS1731 are
also pin compatible with the DS1621 and provide multi-resolution support.
Additionally, the DS1721 data sheet says the temperature flags (THF and TLF)
are used internally, however, these flags do get set and cleared as the actual
temperature crosses the min or max settings (which by default are set to 75
and 80 degrees respectively).
Temperature Conversion:
-----------------------
DS1621 - 750ms (older devices may take up to 1000ms)
DS1625 - 500ms
DS1631 - 93ms..750ms for 9..12 bits resolution, respectively.
DS1721 - 93ms..750ms for 9..12 bits resolution, respectively.
DS1731 - 93ms..750ms for 9..12 bits resolution, respectively.
Note:
On the DS1621, internal access to non-volatile registers may last for 10ms
or less (unverified on the other devices).
Temperature Accuracy:
---------------------
DS1621: +/- 0.5 degree Celsius (from 0 to +70 degrees)
DS1625: +/- 0.5 degree Celsius (from 0 to +70 degrees)
DS1631: +/- 0.5 degree Celsius (from 0 to +70 degrees)
DS1721: +/- 1.0 degree Celsius (from -10 to +85 degrees)
DS1731: +/- 1.0 degree Celsius (from -10 to +85 degrees)
Note:
Please refer to the device datasheets for accuracy at other temperatures.
Temperature Resolution:
-----------------------
As mentioned above, the DS1631, DS1721, and DS1731 provide multi-resolution
support, which is achieved via the R0 and R1 config register bits, where:
R0..R1
------
0 0 => 9 bits, 0.5 degrees Celcius
1 0 => 10 bits, 0.25 degrees Celcius
0 1 => 11 bits, 0.125 degrees Celcius
1 1 => 12 bits, 0.0625 degrees Celcius
Note:
At initial device power-on, the default resolution is set to 12-bits.
The resolution mode for the DS1631, DS1721, or DS1731 can be changed from
userspace, via the device 'update_interval' sysfs attribute. This attribute
will normalize the range of input values to the device maximum resolution
values defined in the datasheet as follows:
Resolution Conversion Time Input Range
(C/LSB) (msec) (msec)
------------------------------------------------
0.5 93.75 0....94
0.25 187.5 95...187
0.125 375 188..375
0.0625 750 376..infinity
------------------------------------------------
The following examples show how the 'update_interval' attribute can be
used to change the conversion time:
$ cat update_interval
750
$ cat temp1_input
22062
$
$ echo 300 > update_interval
$ cat update_interval
375
$ cat temp1_input
22125
$
$ echo 150 > update_interval
$ cat update_interval
188
$ cat temp1_input
22250
$
$ echo 1 > update_interval
$ cat update_interval
94
$ cat temp1_input
22000
$
$ echo 1000 > update_interval
$ cat update_interval
750
$ cat temp1_input
22062
$
As shown, the ds1621 driver automatically adjusts the 'update_interval'
user input, via a step function. Reading back the 'update_interval' value
after a write operation provides the conversion time used by the device.
Mathematically, the resolution can be derived from the conversion time
via the following function:
g(x) = 0.5 * [minimum_conversion_time/x]
where:
-> 'x' = the output from 'update_interval'
-> 'g(x)' = the resolution in degrees C per LSB.
-> 93.75ms = minimum conversion time

65
Documentation/hwmon/g762 Normal file
View File

@ -0,0 +1,65 @@
Kernel driver g762
==================
The GMT G762 Fan Speed PWM Controller is connected directly to a fan
and performs closed-loop or open-loop control of the fan speed. Two
modes - PWM or DC - are supported by the device.
For additional information, a detailed datasheet is available at
http://natisbad.org/NAS/ref/GMT_EDS-762_763-080710-0.2.pdf. sysfs
bindings are described in Documentation/hwmon/sysfs-interface.
The following entries are available to the user in a subdirectory of
/sys/bus/i2c/drivers/g762/ to control the operation of the device.
This can be done manually using the following entries but is usually
done via a userland daemon like fancontrol.
Note that those entries do not provide ways to setup the specific
hardware characteristics of the system (reference clock, pulses per
fan revolution, ...); Those can be modified via devicetree bindings
documented in Documentation/devicetree/bindings/hwmon/g762.txt or
using a specific platform_data structure in board initialization
file (see include/linux/platform_data/g762.h).
fan1_target: set desired fan speed. This only makes sense in closed-loop
fan speed control (i.e. when pwm1_enable is set to 2).
fan1_input: provide current fan rotation value in RPM as reported by
the fan to the device.
fan1_div: fan clock divisor. Supported value are 1, 2, 4 and 8.
fan1_pulses: number of pulses per fan revolution. Supported values
are 2 and 4.
fan1_fault: reports fan failure, i.e. no transition on fan gear pin for
about 0.7s (if the fan is not voluntarily set off).
fan1_alarm: in closed-loop control mode, if fan RPM value is 25% out
of the programmed value for over 6 seconds 'fan1_alarm' is
set to 1.
pwm1_enable: set current fan speed control mode i.e. 1 for manual fan
speed control (open-loop) via pwm1 described below, 2 for
automatic fan speed control (closed-loop) via fan1_target
above.
pwm1_mode: set or get fan driving mode: 1 for PWM mode, 0 for DC mode.
pwm1: get or set PWM fan control value in open-loop mode. This is an
integer value between 0 and 255. 0 stops the fan, 255 makes
it run at full speed.
Both in PWM mode ('pwm1_mode' set to 1) and DC mode ('pwm1_mode' set to 0),
when current fan speed control mode is open-loop ('pwm1_enable' set to 1),
the fan speed is programmed by setting a value between 0 and 255 via 'pwm1'
entry (0 stops the fan, 255 makes it run at full speed). In closed-loop mode
('pwm1_enable' set to 2), the expected rotation speed in RPM can be passed to
the chip via 'fan1_target'. In closed-loop mode, the target speed is compared
with current speed (available via 'fan1_input') by the device and a feedback
is performed to match that target value. The fan speed value is computed
based on the parameters associated with the physical characteristics of the
system: a reference clock source frequency, a number of pulses per fan
revolution, etc.
Note that the driver will update its values at most once per second.

4
Documentation/hwmon/ina2xx
View File

@ -44,4 +44,6 @@ The INA226 monitors both a shunt voltage drop and bus supply voltage.
The INA230 is a high or low side current shunt and power monitor with an I2C
interface. The INA230 monitors both a shunt voltage drop and bus supply voltage.
The shunt value in micro-ohms can be set via platform data.
The shunt value in micro-ohms can be set via platform data or device tree.
Please refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
if the device tree is used.

2
Documentation/i2c/busses/i2c-piix4
View File

@ -13,7 +13,7 @@ Supported adapters:
* AMD SP5100 (SB700 derivative found on some server mainboards)
Datasheet: Publicly available at the AMD website
http://support.amd.com/us/Embedded_TechDocs/44413.pdf
* AMD Hudson-2
* AMD Hudson-2, CZ
Datasheet: Not publicly available
* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
Datasheet: Publicly available at the SMSC website http://www.smsc.com

1
Documentation/ioctl/ioctl-number.txt
View File

@ -72,6 +72,7 @@ Code Seq#(hex) Include File Comments
0x06 all linux/lp.h
0x09 all linux/raid/md_u.h
0x10 00-0F drivers/char/s390/vmcp.h
0x10 10-1F arch/s390/include/uapi/sclp_ctl.h
0x12 all linux/fs.h
linux/blkpg.h
0x1b all InfiniBand Subsystem <http://infiniband.sourceforge.net/>

31
Documentation/kdump/kdump.txt
View File

@ -47,19 +47,12 @@ parameter. Optionally the size of the ELF header can also be passed
when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax.
With the dump-capture kernel, you can access the memory image, or "old
memory," in two ways:
- Through a /dev/oldmem device interface. A capture utility can read the
device file and write out the memory in raw format. This is a raw dump
of memory. Analysis and capture tools must be intelligent enough to
determine where to look for the right information.
- Through /proc/vmcore. This exports the dump as an ELF-format file that
you can write out using file copy commands such as cp or scp. Further,
you can use analysis tools such as the GNU Debugger (GDB) and the Crash
tool to debug the dump file. This method ensures that the dump pages are
correctly ordered.
With the dump-capture kernel, you can access the memory image through
/proc/vmcore. This exports the dump as an ELF-format file that you can
write out using file copy commands such as cp or scp. Further, you can
use analysis tools such as the GNU Debugger (GDB) and the Crash tool to
debug the dump file. This method ensures that the dump pages are correctly
ordered.
Setup and Installation
@ -423,18 +416,6 @@ the following command:
cp /proc/vmcore <dump-file>
You can also access dumped memory as a /dev/oldmem device for a linear
and raw view. To create the device, use the following command:
mknod /dev/oldmem c 1 12
Use the dd command with suitable options for count, bs, and skip to
access specific portions of the dump.
To see the entire memory, use the following command:
dd if=/dev/oldmem of=oldmem.001
Analysis
========

38
Documentation/kernel-parameters.txt
View File

@ -1129,11 +1129,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
The builtin appraise policy appraises all files
owned by uid=0.
ima_audit= [IMA]
Format: { "0" | "1" }
0 -- integrity auditing messages. (Default)
1 -- enable informational integrity auditing messages.
ima_hash= [IMA]
Format: { "sha1" | "md5" }
default: "sha1"
@ -1158,6 +1153,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
Format: <irq>
int_pln_enable [x86] Enable power limit notification interrupt
integrity_audit=[IMA]
Format: { "0" | "1" }
0 -- basic integrity auditing messages. (Default)
1 -- additional integrity auditing messages.
intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option
on
Enable intel iommu driver.
@ -1456,6 +1458,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
* dump_id: dump IDENTIFY data.
* atapi_dmadir: Enable ATAPI DMADIR bridge support
If there are multiple matching configurations changing
the same attribute, the last one is used.
@ -3229,6 +3233,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
video= [FB] Frame buffer configuration
See Documentation/fb/modedb.txt.
video.brightness_switch_enabled= [0,1]
If set to 1, on receiving an ACPI notify event
generated by hotkey, video driver will adjust brightness
level and then send out the event to user space through
the allocated input device; If set to 0, video driver
will only send out the event without touching backlight
brightness level.
default: 1
virtio_mmio.device=
[VMMIO] Memory mapped virtio (platform) device.
@ -3341,6 +3354,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
that this also can be controlled per-workqueue for
workqueues visible under /sys/bus/workqueue/.
workqueue.power_efficient
Per-cpu workqueues are generally preferred because
they show better performance thanks to cache
locality; unfortunately, per-cpu workqueues tend to
be more power hungry than unbound workqueues.
Enabling this makes the per-cpu workqueues which
were observed to contribute significantly to power
consumption unbound, leading to measurably lower
power usage at the cost of small performance
overhead.
The default value of this parameter is determined by
the config option CONFIG_WQ_POWER_EFFICIENT_DEFAULT.
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
default x2apic cluster mode on platforms
supporting x2apic.

47
Documentation/kernel-per-CPU-kthreads.txt
View File

@ -157,6 +157,53 @@ RCU_SOFTIRQ: Do at least one of the following:
calls and by forcing both kernel threads and interrupts
to execute elsewhere.
Name: kworker/%u:%d%s (cpu, id, priority)
Purpose: Execute workqueue requests
To reduce its OS jitter, do any of the following:
1. Run your workload at a real-time priority, which will allow
preempting the kworker daemons.
2. Do any of the following needed to avoid jitter that your
application cannot tolerate:
a. Build your kernel with CONFIG_SLUB=y rather than
CONFIG_SLAB=y, thus avoiding the slab allocator's periodic
use of each CPU's workqueues to run its cache_reap()
function.
b. Avoid using oprofile, thus avoiding OS jitter from
wq_sync_buffer().
c. Limit your CPU frequency so that a CPU-frequency
governor is not required, possibly enlisting the aid of
special heatsinks or other cooling technologies. If done
correctly, and if you CPU architecture permits, you should
be able to build your kernel with CONFIG_CPU_FREQ=n to
avoid the CPU-frequency governor periodically running
on each CPU, including cs_dbs_timer() and od_dbs_timer().
WARNING: Please check your CPU specifications to
make sure that this is safe on your particular system.
d. It is not possible to entirely get rid of OS jitter
from vmstat_update() on CONFIG_SMP=y systems, but you
can decrease its frequency by writing a large value to
/proc/sys/vm/stat_interval. The default value is HZ,
for an interval of one second. Of course, larger values
will make your virtual-memory statistics update more
slowly. Of course, you can also run your workload at
a real-time priority, thus preempting vmstat_update().
e. If running on high-end powerpc servers, build with
CONFIG_PPC_RTAS_DAEMON=n. This prevents the RTAS
daemon from running on each CPU every second or so.
(This will require editing Kconfig files and will defeat
this platform's RAS functionality.) This avoids jitter
due to the rtas_event_scan() function.
WARNING: Please check your CPU specifications to
make sure that this is safe on your particular system.
f. If running on Cell Processor, build your kernel with
CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from
spu_gov_work().
WARNING: Please check your CPU specifications to
make sure that this is safe on your particular system.
g. If running on PowerMAC, build your kernel with
CONFIG_PMAC_RACKMETER=n to disable the CPU-meter,
avoiding OS jitter from rackmeter_do_timer().
Name: rcuc/%u
Purpose: Execute RCU callbacks in CONFIG_RCU_BOOST=y kernels.
To reduce its OS jitter, do at least one of the following:

39
Documentation/pinctrl.txt
View File

@ -203,15 +203,8 @@ using a certain resistor value - pull up and pull down - so that the pin has a
stable value when nothing is driving the rail it is connected to, or when it's
unconnected.
Pin configuration can be programmed either using the explicit APIs described
immediately below, or by adding configuration entries into the mapping table;
see section "Board/machine configuration" below.
For example, a platform may do the following to pull up a pin to VDD:
#include <linux/pinctrl/consumer.h>
ret = pin_config_set("foo-dev", "FOO_GPIO_PIN", PLATFORM_X_PULL_UP);
Pin configuration can be programmed by adding configuration entries into the
mapping table; see section "Board/machine configuration" below.
The format and meaning of the configuration parameter, PLATFORM_X_PULL_UP
above, is entirely defined by the pin controller driver.
@ -350,6 +343,23 @@ chip b:
- GPIO range : [48 .. 55]
- pin range : [64 .. 71]
The above examples assume the mapping between the GPIOs and pins is
linear. If the mapping is sparse or haphazard, an array of arbitrary pin
numbers can be encoded in the range like this:
static const unsigned range_pins[] = { 14, 1, 22, 17, 10, 8, 6, 2 };
static struct pinctrl_gpio_range gpio_range = {
.name = "chip",
.id = 0,
.base = 32,
.pins = &range_pins,
.npins = ARRAY_SIZE(range_pins),
.gc = &chip;
};
In this case the pin_base property will be ignored.
When GPIO-specific functions in the pin control subsystem are called, these
ranges will be used to look up the appropriate pin controller by inspecting
and matching the pin to the pin ranges across all controllers. When a
@ -357,9 +367,9 @@ pin controller handling the matching range is found, GPIO-specific functions
will be called on that specific pin controller.
For all functionalities dealing with pin biasing, pin muxing etc, the pin
controller subsystem will subtract the range's .base offset from the passed
in gpio number, and add the ranges's .pin_base offset to retrive a pin number.
After that, the subsystem passes it on to the pin control driver, so the driver
controller subsystem will look up the corresponding pin number from the passed
in gpio number, and use the range's internals to retrive a pin number. After
that, the subsystem passes it on to the pin control driver, so the driver
will get an pin number into its handled number range. Further it is also passed
the range ID value, so that the pin controller knows which range it should
deal with.
@ -368,6 +378,7 @@ Calling pinctrl_add_gpio_range from pinctrl driver is DEPRECATED. Please see
section 2.1 of Documentation/devicetree/bindings/gpio/gpio.txt on how to bind
pinctrl and gpio drivers.
PINMUX interfaces
=================
@ -1226,8 +1237,8 @@ setting up the config and muxing for the pins right before the device is
probing, nevertheless orthogonal to the GPIO subsystem.
But there are also situations where it makes sense for the GPIO subsystem
to communicate directly with with the pinctrl subsystem, using the latter
as a back-end. This is when the GPIO driver may call out to the functions
to communicate directly with the pinctrl subsystem, using the latter as a
back-end. This is when the GPIO driver may call out to the functions
described in the section "Pin control interaction with the GPIO subsystem"
above. This only involves per-pin multiplexing, and will be completely
hidden behind the gpio_*() function namespace. In this case, the driver

50
Documentation/power/pm_qos_interface.txt
View File

@ -7,7 +7,7 @@ one of the parameters.
Two different PM QoS frameworks are available:
1. PM QoS classes for cpu_dma_latency, network_latency, network_throughput.
2. the per-device PM QoS framework provides the API to manage the per-device latency
constraints.
constraints and PM QoS flags.
Each parameters have defined units:
* latency: usec
@ -86,13 +86,17 @@ To remove the user mode request for a target value simply close the device
node.
2. PM QoS per-device latency framework
2. PM QoS per-device latency and flags framework
For each device, there are two lists of PM QoS requests. One is maintained
along with the aggregated target of latency value and the other is for PM QoS
flags. Values are updated in response to changes of the request list.
Target latency value is simply the minimum of the request values held in the
parameter list elements. The PM QoS flags aggregate value is a gather (bitwise
OR) of all list elements' values. Two device PM QoS flags are defined currently:
PM_QOS_FLAG_NO_POWER_OFF and PM_QOS_FLAG_REMOTE_WAKEUP.
For each device a list of performance requests is maintained along with
an aggregated target value. The aggregated target value is updated with
changes to the request list or elements of the list. Typically the
aggregated target value is simply the max or min of the request values held
in the parameter list elements.
Note: the aggregated target value is implemented as an atomic variable so that
reading the aggregated value does not require any locking mechanism.
@ -119,6 +123,38 @@ the request.
s32 dev_pm_qos_read_value(device):
Returns the aggregated value for a given device's constraints list.
enum pm_qos_flags_status dev_pm_qos_flags(device, mask)
Check PM QoS flags of the given device against the given mask of flags.
The meaning of the return values is as follows:
PM_QOS_FLAGS_ALL: All flags from the mask are set
PM_QOS_FLAGS_SOME: Some flags from the mask are set
PM_QOS_FLAGS_NONE: No flags from the mask are set
PM_QOS_FLAGS_UNDEFINED: The device's PM QoS structure has not been
initialized or the list of requests is empty.
int dev_pm_qos_add_ancestor_request(dev, handle, value)
Add a PM QoS request for the first direct ancestor of the given device whose
power.ignore_children flag is unset.
int dev_pm_qos_expose_latency_limit(device, value)
Add a request to the device's PM QoS list of latency constraints and create
a sysfs attribute pm_qos_resume_latency_us under the device's power directory
allowing user space to manipulate that request.
void dev_pm_qos_hide_latency_limit(device)
Drop the request added by dev_pm_qos_expose_latency_limit() from the device's
PM QoS list of latency constraints and remove sysfs attribute pm_qos_resume_latency_us
from the device's power directory.
int dev_pm_qos_expose_flags(device, value)
Add a request to the device's PM QoS list of flags and create sysfs attributes
pm_qos_no_power_off and pm_qos_remote_wakeup under the device's power directory
allowing user space to change these flags' value.
void dev_pm_qos_hide_flags(device)
Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS list
of flags and remove sysfs attributes pm_qos_no_power_off and pm_qos_remote_wakeup
under the device's power directory.
Notification mechanisms:
The per-device PM QoS framework has 2 different and distinct notification trees:

20
Documentation/power/runtime_pm.txt
View File

@ -144,8 +144,12 @@ The action performed by the idle callback is totally dependent on the subsystem
(or driver) in question, but the expected and recommended action is to check
if the device can be suspended (i.e. if all of the conditions necessary for
suspending the device are satisfied) and to queue up a suspend request for the
device in that case. The value returned by this callback is ignored by the PM
core.
device in that case. If there is no idle callback, or if the callback returns
0, then the PM core will attempt to carry out a runtime suspend of the device;
in essence, it will call pm_runtime_suspend() directly. To prevent this (for
example, if the callback routine has started a delayed suspend), the routine
should return a non-zero value. Negative error return codes are ignored by the
PM core.
The helper functions provided by the PM core, described in Section 4, guarantee
that the following constraints are met with respect to runtime PM callbacks for
@ -301,9 +305,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
removing the device from device hierarchy
int pm_runtime_idle(struct device *dev);
- execute the subsystem-level idle callback for the device; returns 0 on
success or error code on failure, where -EINPROGRESS means that
->runtime_idle() is already being executed
- execute the subsystem-level idle callback for the device; returns an
error code on failure, where -EINPROGRESS means that ->runtime_idle() is
already being executed; if there is no callback or the callback returns 0
then run pm_runtime_suspend(dev) and return its result
int pm_runtime_suspend(struct device *dev);
- execute the subsystem-level suspend callback for the device; returns 0 on
@ -660,11 +665,6 @@ Subsystems may wish to conserve code space by using the set of generic power
management callbacks provided by the PM core, defined in
driver/base/power/generic_ops.c:
int pm_generic_runtime_idle(struct device *dev);
- invoke the ->runtime_idle() callback provided by the driver of this
device, if defined, and call pm_runtime_suspend() for this device if the
return value is 0 or the callback is not defined
int pm_generic_runtime_suspend(struct device *dev);
- invoke the ->runtime_suspend() callback provided by the driver of this
device and return its result, or return -EINVAL if not defined

37
Documentation/power/video_extension.txt
View File

@ -1,37 +0,0 @@
ACPI video extensions
~~~~~~~~~~~~~~~~~~~~~
This driver implement the ACPI Extensions For Display Adapters for
integrated graphics devices on motherboard, as specified in ACPI 2.0
Specification, Appendix B, allowing to perform some basic control like
defining the video POST device, retrieving EDID information or to
setup a video output, etc. Note that this is an ref. implementation
only. It may or may not work for your integrated video device.
Interfaces exposed to userland through /proc/acpi/video:
VGA/info : display the supported video bus device capability like Video ROM, CRT/LCD/TV.
VGA/ROM : Used to get a copy of the display devices' ROM data (up to 4k).
VGA/POST_info : Used to determine what options are implemented.
VGA/POST : Used to get/set POST device.
VGA/DOS : Used to get/set ownership of output switching:
Please refer ACPI spec B.4.1 _DOS
VGA/CRT : CRT output
VGA/LCD : LCD output
VGA/TVO : TV output
VGA/*/brightness : Used to get/set brightness of output device
Notify event through /proc/acpi/event:
#define ACPI_VIDEO_NOTIFY_SWITCH 0x80
#define ACPI_VIDEO_NOTIFY_PROBE 0x81
#define ACPI_VIDEO_NOTIFY_CYCLE 0x82
#define ACPI_VIDEO_NOTIFY_NEXT_OUTPUT 0x83
#define ACPI_VIDEO_NOTIFY_PREV_OUTPUT 0x84
#define ACPI_VIDEO_NOTIFY_CYCLE_BRIGHTNESS 0x82
#define ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS 0x83
#define ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS 0x84
#define ACPI_VIDEO_NOTIFY_ZERO_BRIGHTNESS 0x85
#define ACPI_VIDEO_NOTIFY_DISPLAY_OFF 0x86

98
Documentation/rapidio/rapidio.txt
View File

@ -73,28 +73,44 @@ data structure. This structure includes lists of all devices and local master
ports that form the same network. It also contains a pointer to the default
master port that is used to communicate with devices within the network.
2.5 Device Drivers
RapidIO device-specific drivers follow Linux Kernel Driver Model and are
intended to support specific RapidIO devices attached to the RapidIO network.
2.6 Subsystem Interfaces
RapidIO interconnect specification defines features that may be used to provide
one or more common service layers for all participating RapidIO devices. These
common services may act separately from device-specific drivers or be used by
device-specific drivers. Example of such service provider is the RIONET driver
which implements Ethernet-over-RapidIO interface. Because only one driver can be
registered for a device, all common RapidIO services have to be registered as
subsystem interfaces. This allows to have multiple common services attached to
the same device without blocking attachment of a device-specific driver.
3. Subsystem Initialization
---------------------------
In order to initialize the RapidIO subsystem, a platform must initialize and
register at least one master port within the RapidIO network. To register mport
within the subsystem controller driver initialization code calls function
within the subsystem controller driver's initialization code calls function
rio_register_mport() for each available master port.
RapidIO subsystem uses subsys_initcall() or device_initcall() to perform
controller initialization (depending on controller device type).
After all active master ports are registered with a RapidIO subsystem,
an enumeration and/or discovery routine may be called automatically or
by user-space command.
RapidIO subsystem can be configured to be built as a statically linked or
modular component of the kernel (see details below).
4. Enumeration and Discovery
----------------------------
4.1 Overview
------------
RapidIO subsystem configuration options allow users to specify enumeration and
RapidIO subsystem configuration options allow users to build enumeration and
discovery methods as statically linked components or loadable modules.
An enumeration/discovery method implementation and available input parameters
define how any given method can be attached to available RapidIO mports:
@ -115,8 +131,8 @@ several methods to initiate an enumeration and/or discovery process:
endpoint waits for enumeration to be completed. If the specified timeout
expires the discovery process is terminated without obtaining RapidIO network
information. NOTE: a timed out discovery process may be restarted later using
a user-space command as it is described later if the given endpoint was
enumerated successfully.
a user-space command as it is described below (if the given endpoint was
enumerated successfully).
(b) Statically linked enumeration and discovery process can be started by
a command from user space. This initiation method provides more flexibility
@ -138,15 +154,42 @@ When a network scan process is started it calls an enumeration or discovery
routine depending on the configured role of a master port: host or agent.
Enumeration is performed by a master port if it is configured as a host port by
assigning a host device ID greater than or equal to zero. A host device ID is
assigned to a master port through the kernel command line parameter "riohdid=",
or can be configured in a platform-specific manner. If the host device ID for
a specific master port is set to -1, the discovery process will be performed
for it.
assigning a host destination ID greater than or equal to zero. The host
destination ID can be assigned to a master port using various methods depending
on RapidIO subsystem build configuration:
(a) For a statically linked RapidIO subsystem core use command line parameter
"rapidio.hdid=" with a list of destination ID assignments in order of mport
device registration. For example, in a system with two RapidIO controllers
the command line parameter "rapidio.hdid=-1,7" will result in assignment of
the host destination ID=7 to the second RapidIO controller, while the first
one will be assigned destination ID=-1.
(b) If the RapidIO subsystem core is built as a loadable module, in addition
to the method shown above, the host destination ID(s) can be specified using
traditional methods of passing module parameter "hdid=" during its loading:
- from command line: "modprobe rapidio hdid=-1,7", or
- from modprobe configuration file using configuration command "options",
like in this example: "options rapidio hdid=-1,7". An example of modprobe
configuration file is provided in the section below.
NOTES:
(i) if "hdid=" parameter is omitted all available mport will be assigned
destination ID = -1;
(ii) the "hdid=" parameter in systems with multiple mports can have
destination ID assignments omitted from the end of list (default = -1).
If the host device ID for a specific master port is set to -1, the discovery
process will be performed for it.
The enumeration and discovery routines use RapidIO maintenance transactions
to access the configuration space of devices.
NOTE: If RapidIO switch-specific device drivers are built as loadable modules
they must be loaded before enumeration/discovery process starts.
This requirement is cased by the fact that enumeration/discovery methods invoke
vendor-specific callbacks on early stages.
4.2 Automatic Start of Enumeration and Discovery
------------------------------------------------
@ -266,7 +309,36 @@ method's module initialization routine calls rio_register_scan() to attach
an enumerator to a specified mport device (or devices). The basic enumerator
implementation demonstrates this process.
5. References
4.6 Using Loadable RapidIO Switch Drivers
-----------------------------------------
In the case when RapidIO switch drivers are built as loadable modules a user
must ensure that they are loaded before the enumeration/discovery starts.
This process can be automated by specifying pre- or post- dependencies in the
RapidIO-specific modprobe configuration file as shown in the example below.
File /etc/modprobe.d/rapidio.conf:
----------------------------------
# Configure RapidIO subsystem modules
# Set enumerator host destination ID (overrides kernel command line option)
options rapidio hdid=-1,2
# Load RapidIO switch drivers immediately after rapidio core module was loaded
softdep rapidio post: idt_gen2 idtcps tsi57x
# OR :
# Load RapidIO switch drivers just before rio-scan enumerator module is loaded
softdep rio-scan pre: idt_gen2 idtcps tsi57x
--------------------------
NOTE: In the example above, one of "softdep" commands must be removed or
commented out to keep required module loading sequence.
A. References
-------------
[1] RapidIO Trade Association. RapidIO Interconnect Specifications.

1
Documentation/rapidio/sysfs.txt
View File

@ -40,6 +40,7 @@ device_rev - returns the device revision level
(see 4.1 for switch specific details)
lprev - returns name of previous device (switch) on the path to the device
that that owns this attribute
modalias - returns the device modalias
In addition to the files listed above, each device has a binary attribute file
that allows read/write access to the device configuration registers using

2
Documentation/rt-mutex-design.txt
View File

@ -384,7 +384,7 @@ priority back.
__rt_mutex_adjust_prio examines the result of rt_mutex_getprio, and if the
result does not equal the task's current priority, then rt_mutex_setprio
is called to adjust the priority of the task to the new priority.
Note that rt_mutex_setprio is defined in kernel/sched.c to implement the
Note that rt_mutex_setprio is defined in kernel/sched/core.c to implement the
actual change in priority.
It is interesting to note that __rt_mutex_adjust_prio can either increase

7
Documentation/rtc.txt
View File

@ -153,9 +153,10 @@ since_epoch: The number of seconds since the epoch according to the RTC
time: RTC-provided time
wakealarm: The time at which the clock will generate a system wakeup
event. This is a one shot wakeup event, so must be reset
after wake if a daily wakeup is required. Format is either
seconds since the epoch or, if there's a leading +, seconds
in the future.
after wake if a daily wakeup is required. Format is seconds since
the epoch by default, or if there's a leading +, seconds in the
future, or if there is a leading +=, seconds ahead of the current
alarm.
IOCTL INTERFACE
---------------

4
Documentation/scheduler/sched-domains.txt
View File

@ -25,7 +25,7 @@ is treated as one entity. The load of a group is defined as the sum of the
load of each of its member CPUs, and only when the load of a group becomes
out of balance are tasks moved between groups.
In kernel/sched.c, trigger_load_balance() is run periodically on each CPU
In kernel/sched/core.c, trigger_load_balance() is run periodically on each CPU
through scheduler_tick(). It raises a softirq after the next regularly scheduled
rebalancing event for the current runqueue has arrived. The actual load
balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run
@ -62,7 +62,7 @@ struct sched_domain fields, SD_FLAG_*, SD_*_INIT to get an idea of
the specifics and what to tune.
Architectures may retain the regular override the default SD_*_INIT flags
while using the generic domain builder in kernel/sched.c if they wish to
while using the generic domain builder in kernel/sched/core.c if they wish to
retain the traditional SMT->SMP->NUMA topology (or some subset of that). This
can be done by #define'ing ARCH_HASH_SCHED_TUNE.

6
Documentation/sound/alsa/HD-Audio-Models.txt
View File

@ -21,7 +21,7 @@ ALC267/268
==========
inv-dmic Inverted internal mic workaround
ALC269/270/275/276/280/282
ALC269/270/275/276/28x/29x
======
laptop-amic Laptops with analog-mic input
laptop-dmic Laptops with digital-mic input
@ -32,7 +32,7 @@ ALC269/270/275/276/280/282
dell-headset-multi Headset jack, which can also be used as mic-in
dell-headset-dock Headset jack (without mic-in), and also dock I/O
ALC662/663/272
ALC66x/67x/892
==============
mario Chromebook mario model fixup
asus-mode1 ASUS
@ -50,7 +50,7 @@ ALC680
======
N/A
ALC882/883/885/888/889
ALC88x/898/1150
======================
acer-aspire-4930g Acer Aspire 4930G/5930G/6530G/6930G/7730G
acer-aspire-8930g Acer Aspire 8330G/6935G

2
Documentation/spinlocks.txt
View File

@ -137,7 +137,7 @@ don't block on each other (and thus there is no dead-lock wrt interrupts.
But when you do the write-lock, you have to use the irq-safe version.
For an example of being clever with rw-locks, see the "waitqueue_lock"
handling in kernel/sched.c - nothing ever _changes_ a wait-queue from
handling in kernel/sched/core.c - nothing ever _changes_ a wait-queue from
within an interrupt, they only read the queue in order to know whom to
wake up. So read-locks are safe (which is good: they are very common
indeed), while write-locks need to protect themselves against interrupts.

50
Documentation/sysctl/kernel.txt
View File

@ -70,12 +70,12 @@ show up in /proc/sys/kernel:
- shmall
- shmmax [ sysv ipc ]
- shmmni
- softlockup_thresh
- stop-a [ SPARC only ]
- sysrq ==> Documentation/sysrq.txt
- tainted
- threads-max
- unknown_nmi_panic
- watchdog_thresh
- version
==============================================================
@ -427,6 +427,32 @@ This file shows up if CONFIG_DEBUG_STACKOVERFLOW is enabled.
==============================================================
perf_cpu_time_max_percent:
Hints to the kernel how much CPU time it should be allowed to
use to handle perf sampling events. If the perf subsystem
is informed that its samples are exceeding this limit, it
will drop its sampling frequency to attempt to reduce its CPU
usage.
Some perf sampling happens in NMIs. If these samples
unexpectedly take too long to execute, the NMIs can become
stacked up next to each other so much that nothing else is
allowed to execute.
0: disable the mechanism. Do not monitor or correct perf's
sampling rate no matter how CPU time it takes.
1-100: attempt to throttle perf's sample rate to this
percentage of CPU. Note: the kernel calculates an
"expected" length of each sample event. 100 here means
100% of that expected length. Even if this is set to
100, you may still see sample throttling if this
length is exceeded. Set to 0 if you truly do not care
how much CPU is consumed.
==============================================================
pid_max:
@ -604,15 +630,6 @@ without users and with a dead originative process will be destroyed.
==============================================================
softlockup_thresh:
This value can be used to lower the softlockup tolerance threshold. The
default threshold is 60 seconds. If a cpu is locked up for 60 seconds,
the kernel complains. Valid values are 1-60 seconds. Setting this
tunable to zero will disable the softlockup detection altogether.
==============================================================
tainted:
Non-zero if the kernel has been tainted. Numeric values, which
@ -648,3 +665,16 @@ that time, kernel debugging information is displayed on console.
NMI switch that most IA32 servers have fires unknown NMI up, for
example. If a system hangs up, try pressing the NMI switch.
==============================================================
watchdog_thresh:
This value can be used to control the frequency of hrtimer and NMI
events and the soft and hard lockup thresholds. The default threshold
is 10 seconds.
The softlockup threshold is (2 * watchdog_thresh). Setting this
tunable to zero will disable lockup detection altogether.
==============================================================

79
Documentation/timers/NO_HZ.txt
View File

@ -7,21 +7,59 @@ efficiency and reducing OS jitter. Reducing OS jitter is important for
some types of computationally intensive high-performance computing (HPC)
applications and for real-time applications.
There are two main contexts in which the number of scheduling-clock
interrupts can be reduced compared to the old-school approach of sending
a scheduling-clock interrupt to all CPUs every jiffy whether they need
it or not (CONFIG_HZ_PERIODIC=y or CONFIG_NO_HZ=n for older kernels):
There are three main ways of managing scheduling-clock interrupts
(also known as "scheduling-clock ticks" or simply "ticks"):
1. Idle CPUs (CONFIG_NO_HZ_IDLE=y or CONFIG_NO_HZ=y for older kernels).
1. Never omit scheduling-clock ticks (CONFIG_HZ_PERIODIC=y or
CONFIG_NO_HZ=n for older kernels). You normally will -not-
want to choose this option.
2. CPUs having only one runnable task (CONFIG_NO_HZ_FULL=y).
2. Omit scheduling-clock ticks on idle CPUs (CONFIG_NO_HZ_IDLE=y or
CONFIG_NO_HZ=y for older kernels). This is the most common
approach, and should be the default.
These two cases are described in the following two sections, followed
3. Omit scheduling-clock ticks on CPUs that are either idle or that
have only one runnable task (CONFIG_NO_HZ_FULL=y). Unless you
are running realtime applications or certain types of HPC
workloads, you will normally -not- want this option.
These three cases are described in the following three sections, followed
by a third section on RCU-specific considerations and a fourth and final
section listing known issues.
IDLE CPUs
NEVER OMIT SCHEDULING-CLOCK TICKS
Very old versions of Linux from the 1990s and the very early 2000s
are incapable of omitting scheduling-clock ticks. It turns out that
there are some situations where this old-school approach is still the
right approach, for example, in heavy workloads with lots of tasks
that use short bursts of CPU, where there are very frequent idle
periods, but where these idle periods are also quite short (tens or
hundreds of microseconds). For these types of workloads, scheduling
clock interrupts will normally be delivered any way because there
will frequently be multiple runnable tasks per CPU. In these cases,
attempting to turn off the scheduling clock interrupt will have no effect
other than increasing the overhead of switching to and from idle and
transitioning between user and kernel execution.
This mode of operation can be selected using CONFIG_HZ_PERIODIC=y (or
CONFIG_NO_HZ=n for older kernels).
However, if you are instead running a light workload with long idle
periods, failing to omit scheduling-clock interrupts will result in
excessive power consumption. This is especially bad on battery-powered
devices, where it results in extremely short battery lifetimes. If you
are running light workloads, you should therefore read the following
section.
In addition, if you are running either a real-time workload or an HPC
workload with short iterations, the scheduling-clock interrupts can
degrade your applications performance. If this describes your workload,
you should read the following two sections.
OMIT SCHEDULING-CLOCK TICKS FOR IDLE CPUs
If a CPU is idle, there is little point in sending it a scheduling-clock
interrupt. After all, the primary purpose of a scheduling-clock interrupt
@ -59,10 +97,12 @@ By default, CONFIG_NO_HZ_IDLE=y kernels boot with "nohz=on", enabling
dyntick-idle mode.
CPUs WITH ONLY ONE RUNNABLE TASK
OMIT SCHEDULING-CLOCK TICKS FOR CPUs WITH ONLY ONE RUNNABLE TASK
If a CPU has only one runnable task, there is little point in sending it
a scheduling-clock interrupt because there is no other task to switch to.
Note that omitting scheduling-clock ticks for CPUs with only one runnable
task implies also omitting them for idle CPUs.
The CONFIG_NO_HZ_FULL=y Kconfig option causes the kernel to avoid
sending scheduling-clock interrupts to CPUs with a single runnable task,
@ -238,6 +278,11 @@ o Adaptive-ticks does not do anything unless there is only one
single runnable SCHED_FIFO task and multiple runnable SCHED_OTHER
tasks, even though these interrupts are unnecessary.
And even when there are multiple runnable tasks on a given CPU,
there is little point in interrupting that CPU until the current
running task's timeslice expires, which is almost always way
longer than the time of the next scheduling-clock interrupt.
Better handling of these sorts of situations is future work.
o A reboot is required to reconfigure both adaptive idle and RCU
@ -268,6 +313,16 @@ o Unless all CPUs are idle, at least one CPU must keep the
scheduling-clock interrupt going in order to support accurate
timekeeping.
o If there are adaptive-ticks CPUs, there will be at least one
CPU keeping the scheduling-clock interrupt going, even if all
CPUs are otherwise idle.
o If there might potentially be some adaptive-ticks CPUs, there
will be at least one CPU keeping the scheduling-clock interrupt
going, even if all CPUs are otherwise idle.
Better handling of this situation is ongoing work.
o Some process-handling operations still require the occasional
scheduling-clock tick. These operations include calculating CPU
load, maintaining sched average, computing CFS entity vruntime,
computing avenrun, and carrying out load balancing. They are
currently accommodated by scheduling-clock tick every second
or so. On-going work will eliminate the need even for these
infrequent scheduling-clock ticks.

43
Documentation/trace/events-nmi.txt Normal file
View File

@ -0,0 +1,43 @@
NMI Trace Events
These events normally show up here:
/sys/kernel/debug/tracing/events/nmi
--
nmi_handler:
You might want to use this tracepoint if you suspect that your
NMI handlers are hogging large amounts of CPU time. The kernel
will warn if it sees long-running handlers:
INFO: NMI handler took too long to run: 9.207 msecs
and this tracepoint will allow you to drill down and get some
more details.
Let's say you suspect that perf_event_nmi_handler() is causing
you some problems and you only want to trace that handler
specifically. You need to find its address:
$ grep perf_event_nmi_handler /proc/kallsyms
ffffffff81625600 t perf_event_nmi_handler
Let's also say you are only interested in when that function is
really hogging a lot of CPU time, like a millisecond at a time.
Note that the kernel's output is in milliseconds, but the input
to the filter is in nanoseconds! You can filter on 'delta_ns':
cd /sys/kernel/debug/tracing/events/nmi/nmi_handler
echo 'handler==0xffffffff81625600 && delta_ns>1000000' > filter
echo 1 > enable
Your output would then look like:
$ cat /sys/kernel/debug/tracing/trace_pipe
<idle>-0 [000] d.h3 505.397558: nmi_handler: perf_event_nmi_handler() delta_ns: 3236765 handled: 1
<idle>-0 [000] d.h3 505.805893: nmi_handler: perf_event_nmi_handler() delta_ns: 3174234 handled: 1
<idle>-0 [000] d.h3 506.158206: nmi_handler: perf_event_nmi_handler() delta_ns: 3084642 handled: 1
<idle>-0 [000] d.h3 506.334346: nmi_handler: perf_event_nmi_handler() delta_ns: 3080351 handled: 1

31
Documentation/trace/events-power.txt
View File

@ -63,3 +63,34 @@ power_domain_target "%s state=%lu cpu_id=%lu"
The first parameter gives the power domain name (e.g. "mpu_pwrdm").
The second parameter is the power domain target state.
4. PM QoS events
================
The PM QoS events are used for QoS add/update/remove request and for
target/flags update.
pm_qos_add_request "pm_qos_class=%s value=%d"
pm_qos_update_request "pm_qos_class=%s value=%d"
pm_qos_remove_request "pm_qos_class=%s value=%d"
pm_qos_update_request_timeout "pm_qos_class=%s value=%d, timeout_us=%ld"
The first parameter gives the QoS class name (e.g. "CPU_DMA_LATENCY").
The second parameter is value to be added/updated/removed.
The third parameter is timeout value in usec.
pm_qos_update_target "action=%s prev_value=%d curr_value=%d"
pm_qos_update_flags "action=%s prev_value=0x%x curr_value=0x%x"
The first parameter gives the QoS action name (e.g. "ADD_REQ").
The second parameter is the previous QoS value.
The third parameter is the current QoS value to update.
And, there are also events used for device PM QoS add/update/remove request.
dev_pm_qos_add_request "device=%s type=%s new_value=%d"
dev_pm_qos_update_request "device=%s type=%s new_value=%d"
dev_pm_qos_remove_request "device=%s type=%s new_value=%d"
The first parameter gives the device name which tries to add/update/remove
QoS requests.
The second parameter gives the request type (e.g. "DEV_PM_QOS_LATENCY").
The third parameter is value to be added/updated/removed.

66
Documentation/virtual/kvm/api.txt
View File

@ -280,7 +280,7 @@ kvm_run' (see below).
4.11 KVM_GET_REGS
Capability: basic
Architectures: all except ARM
Architectures: all except ARM, arm64
Type: vcpu ioctl
Parameters: struct kvm_regs (out)
Returns: 0 on success, -1 on error
@ -301,7 +301,7 @@ struct kvm_regs {
4.12 KVM_SET_REGS
Capability: basic
Architectures: all except ARM
Architectures: all except ARM, arm64
Type: vcpu ioctl
Parameters: struct kvm_regs (in)
Returns: 0 on success, -1 on error
@ -587,7 +587,7 @@ struct kvm_fpu {
4.24 KVM_CREATE_IRQCHIP
Capability: KVM_CAP_IRQCHIP
Architectures: x86, ia64, ARM
Architectures: x86, ia64, ARM, arm64
Type: vm ioctl
Parameters: none
Returns: 0 on success, -1 on error
@ -595,14 +595,14 @@ Returns: 0 on success, -1 on error
Creates an interrupt controller model in the kernel. On x86, creates a virtual
ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
only go to the IOAPIC. On ia64, a IOSAPIC is created. On ARM, a GIC is
only go to the IOAPIC. On ia64, a IOSAPIC is created. On ARM/arm64, a GIC is
created.
4.25 KVM_IRQ_LINE
Capability: KVM_CAP_IRQCHIP
Architectures: x86, ia64, arm
Architectures: x86, ia64, arm, arm64
Type: vm ioctl
Parameters: struct kvm_irq_level
Returns: 0 on success, -1 on error
@ -612,9 +612,10 @@ On some architectures it is required that an interrupt controller model has
been previously created with KVM_CREATE_IRQCHIP. Note that edge-triggered
interrupts require the level to be set to 1 and then back to 0.
ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip
(GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for
specific cpus. The irq field is interpreted like this:
ARM/arm64 can signal an interrupt either at the CPU level, or at the
in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to
use PPIs designated for specific cpus. The irq field is interpreted
like this:
 bits: | 31 ... 24 | 23 ... 16 | 15 ... 0 |
field: | irq_type | vcpu_index | irq_id |
@ -1831,6 +1832,22 @@ ARM 32-bit VFP control registers have the following id bit patterns:
ARM 64-bit FP registers have the following id bit patterns:
0x4030 0000 0012 0 <regno:12>
arm64 registers are mapped using the lower 32 bits. The upper 16 of
that is the register group type, or coprocessor number:
arm64 core/FP-SIMD registers have the following id bit patterns. Note
that the size of the access is variable, as the kvm_regs structure
contains elements ranging from 32 to 128 bits. The index is a 32bit
value in the kvm_regs structure seen as a 32bit array.
0x60x0 0000 0010 <index into the kvm_regs struct:16>
arm64 CCSIDR registers are demultiplexed by CSSELR value:
0x6020 0000 0011 00 <csselr:8>
arm64 system registers have the following id bit patterns:
0x6030 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3>
4.69 KVM_GET_ONE_REG
Capability: KVM_CAP_ONE_REG
@ -2261,10 +2278,10 @@ return indicates the attribute is implemented. It does not necessarily
indicate that the attribute can be read or written in the device's
current state. "addr" is ignored.
4.77 KVM_ARM_VCPU_INIT
4.82 KVM_ARM_VCPU_INIT
Capability: basic
Architectures: arm
Architectures: arm, arm64
Type: vcpu ioctl
Parameters: struct struct kvm_vcpu_init (in)
Returns: 0 on success; -1 on error
@ -2283,12 +2300,14 @@ should be created before this ioctl is invoked.
Possible features:
- KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state.
Depends on KVM_CAP_ARM_PSCI.
- KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
4.78 KVM_GET_REG_LIST
4.83 KVM_GET_REG_LIST
Capability: basic
Architectures: arm
Architectures: arm, arm64
Type: vcpu ioctl
Parameters: struct kvm_reg_list (in/out)
Returns: 0 on success; -1 on error
@ -2305,10 +2324,10 @@ This ioctl returns the guest registers that are supported for the
KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
4.80 KVM_ARM_SET_DEVICE_ADDR
4.84 KVM_ARM_SET_DEVICE_ADDR
Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
Architectures: arm
Architectures: arm, arm64
Type: vm ioctl
Parameters: struct kvm_arm_device_address (in)
Returns: 0 on success, -1 on error
@ -2329,20 +2348,21 @@ can access emulated or directly exposed devices, which the host kernel needs
to know about. The id field is an architecture specific identifier for a
specific device.
ARM divides the id field into two parts, a device id and an address type id
specific to the individual device.
ARM/arm64 divides the id field into two parts, a device id and an
address type id specific to the individual device.
 bits: | 63 ... 32 | 31 ... 16 | 15 ... 0 |
field: | 0x00000000 | device id | addr type id |
ARM currently only require this when using the in-kernel GIC support for the
hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2 as the device id. When
setting the base address for the guest's mapping of the VGIC virtual CPU
and distributor interface, the ioctl must be called after calling
KVM_CREATE_IRQCHIP, but before calling KVM_RUN on any of the VCPUs. Calling
this ioctl twice for any of the base addresses will return -EEXIST.
ARM/arm64 currently only require this when using the in-kernel GIC
support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2
as the device id. When setting the base address for the guest's
mapping of the VGIC virtual CPU and distributor interface, the ioctl
must be called after calling KVM_CREATE_IRQCHIP, but before calling
KVM_RUN on any of the VCPUs. Calling this ioctl twice for any of the
base addresses will return -EEXIST.
4.82 KVM_PPC_RTAS_DEFINE_TOKEN
4.85 KVM_PPC_RTAS_DEFINE_TOKEN
Capability: KVM_CAP_PPC_RTAS
Architectures: ppc

91
Documentation/virtual/kvm/mmu.txt
View File

@ -191,12 +191,12 @@ Shadow pages contain the following information:
A counter keeping track of how many hardware registers (guest cr3 or
pdptrs) are now pointing at the page. While this counter is nonzero, the
page cannot be destroyed. See role.invalid.
multimapped:
Whether there exist multiple sptes pointing at this page.
parent_pte/parent_ptes:
If multimapped is zero, parent_pte points at the single spte that points at
this page's spt. Otherwise, parent_ptes points at a data structure
with a list of parent_ptes.
parent_ptes:
The reverse mapping for the pte/ptes pointing at this page's spt. If
parent_ptes bit 0 is zero, only one spte points at this pages and
parent_ptes points at this single spte, otherwise, there exists multiple
sptes pointing at this page and (parent_ptes & ~0x1) points at a data
structure with a list of parent_ptes.
unsync:
If true, then the translations in this page may not match the guest's
translation. This is equivalent to the state of the tlb when a pte is
@ -210,6 +210,24 @@ Shadow pages contain the following information:
A bitmap indicating which sptes in spt point (directly or indirectly) at
pages that may be unsynchronized. Used to quickly locate all unsychronized
pages reachable from a given page.
mmu_valid_gen:
Generation number of the page. It is compared with kvm->arch.mmu_valid_gen
during hash table lookup, and used to skip invalidated shadow pages (see
"Zapping all pages" below.)
clear_spte_count:
Only present on 32-bit hosts, where a 64-bit spte cannot be written
atomically. The reader uses this while running out of the MMU lock
to detect in-progress updates and retry them until the writer has
finished the write.
write_flooding_count:
A guest may write to a page table many times, causing a lot of
emulations if the page needs to be write-protected (see "Synchronized
and unsynchronized pages" below). Leaf pages can be unsynchronized
so that they do not trigger frequent emulation, but this is not
possible for non-leafs. This field counts the number of emulations
since the last time the page table was actually used; if emulation
is triggered too frequently on this page, KVM will unmap the page
to avoid emulation in the future.
Reverse map
===========
@ -258,14 +276,26 @@ This is the most complicated event. The cause of a page fault can be:
Handling a page fault is performed as follows:
- if the RSV bit of the error code is set, the page fault is caused by guest
accessing MMIO and cached MMIO information is available.
- walk shadow page table
- check for valid generation number in the spte (see "Fast invalidation of
MMIO sptes" below)
- cache the information to vcpu->arch.mmio_gva, vcpu->arch.access and
vcpu->arch.mmio_gfn, and call the emulator
- If both P bit and R/W bit of error code are set, this could possibly
be handled as a "fast page fault" (fixed without taking the MMU lock). See
the description in Documentation/virtual/kvm/locking.txt.
- if needed, walk the guest page tables to determine the guest translation
(gva->gpa or ngpa->gpa)
- if permissions are insufficient, reflect the fault back to the guest
- determine the host page
- if this is an mmio request, there is no host page; call the emulator
to emulate the instruction instead
- if this is an mmio request, there is no host page; cache the info to
vcpu->arch.mmio_gva, vcpu->arch.access and vcpu->arch.mmio_gfn
- walk the shadow page table to find the spte for the translation,
instantiating missing intermediate page tables as necessary
- If this is an mmio request, cache the mmio info to the spte and set some
reserved bit on the spte (see callers of kvm_mmu_set_mmio_spte_mask)
- try to unsynchronize the page
- if successful, we can let the guest continue and modify the gpte
- emulate the instruction
@ -351,6 +381,51 @@ causes its write_count to be incremented, thus preventing instantiation of
a large spte. The frames at the end of an unaligned memory slot have
artificially inflated ->write_counts so they can never be instantiated.
Zapping all pages (page generation count)
=========================================
For the large memory guests, walking and zapping all pages is really slow
(because there are a lot of pages), and also blocks memory accesses of
all VCPUs because it needs to hold the MMU lock.
To make it be more scalable, kvm maintains a global generation number
which is stored in kvm->arch.mmu_valid_gen. Every shadow page stores
the current global generation-number into sp->mmu_valid_gen when it
is created. Pages with a mismatching generation number are "obsolete".
When KVM need zap all shadow pages sptes, it just simply increases the global
generation-number then reload root shadow pages on all vcpus. As the VCPUs
create new shadow page tables, the old pages are not used because of the
mismatching generation number.
KVM then walks through all pages and zaps obsolete pages. While the zap
operation needs to take the MMU lock, the lock can be released periodically
so that the VCPUs can make progress.
Fast invalidation of MMIO sptes
===============================
As mentioned in "Reaction to events" above, kvm will cache MMIO
information in leaf sptes. When a new memslot is added or an existing
memslot is changed, this information may become stale and needs to be
invalidated. This also needs to hold the MMU lock while walking all
shadow pages, and is made more scalable with a similar technique.
MMIO sptes have a few spare bits, which are used to store a
generation number. The global generation number is stored in
kvm_memslots(kvm)->generation, and increased whenever guest memory info
changes. This generation number is distinct from the one described in
the previous section.
When KVM finds an MMIO spte, it checks the generation number of the spte.
If the generation number of the spte does not equal the global generation
number, it will ignore the cached MMIO information and handle the page
fault through the slow path.
Since only 19 bits are used to store generation-number on mmio spte, all
pages are zapped when there is an overflow.
Further reading
===============

4
Documentation/virtual/uml/UserModeLinux-HOWTO.txt
View File

@ -3127,7 +3127,7 @@
at process_kern.c:156
#3 0x1006a052 in switch_to (prev=0x50072000, next=0x507e8000, last=0x50072000)
at process_kern.c:161
#4 0x10001d12 in schedule () at sched.c:777
#4 0x10001d12 in schedule () at core.c:777
#5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71
#6 0x1006aa10 in __down_failed () at semaphore.c:157
#7 0x1006c5d8 in segv_handler (sc=0x5006e940) at trap_user.c:174
@ -3191,7 +3191,7 @@
at process_kern.c:161
161 _switch_to(prev, next);
(gdb)
#4 0x10001d12 in schedule () at sched.c:777
#4 0x10001d12 in schedule () at core.c:777
777 switch_to(prev, next, prev);
(gdb)
#5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71

Some files were not shown because too many files have changed in this diff Show More