hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'linus' into perf/urgent 

Merge dependencies to apply a fix.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar 2013-11-14 08:28:30 +01:00
parent d969135aae f0d55cc1a6
commit 555a098af6
3971 changed files with 167350 additions and 77621 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
CREDITS
View File

@ -2576,7 +2576,7 @@ S: Toronto, Ontario
S: Canada
N: Zwane Mwaikambo
E: zwane@arm.linux.org.uk
E: zwanem@gmail.com
D: Various driver hacking
D: Lowlevel x86 kernel hacking
D: General debugging
@ -2895,6 +2895,11 @@ S: Framewood Road
S: Wexham SL3 6PJ
S: United Kingdom
N: Richard Purdie
E: rpurdie@rpsys.net
D: Backlight subsystem maintainer
S: United Kingdom
N: Daniel Quinlan
E: quinlan@pathname.com
W: http://www.pathname.com/~quinlan/
@ -3152,6 +3157,11 @@ N: Dipankar Sarma
E: dipankar@in.ibm.com
D: RCU
N: Yoshinori Sato
E: ysato@users.sourceforge.jp
D: uClinux for Renesas H8/300 (H8300)
D: http://uclinux-h8.sourceforge.jp/
N: Hannu Savolainen
E: hannu@opensound.com
D: Maintainer of the sound drivers until 2.1.x days.

13
Documentation/ABI/README
View File

@ -72,3 +72,16 @@ kernel tree without going through the obsolete state first.
It's up to the developer to place their interfaces in the category they
wish for it to start out in.
Notable bits of non-ABI, which should not under any circumstances be considered
stable:
- Kconfig. Userspace should not rely on the presence or absence of any
particular Kconfig symbol, in /proc/config.gz, in the copy of .config
commonly installed to /boot, or in any invocation of the kernel build
process.
- Kernel-internal symbols. Do not rely on the presence, absence, location, or
type of any kernel symbol, either in System.map files or the kernel binary
itself. See Documentation/stable_api_nonsense.txt.

2
Documentation/ABI/testing/sysfs-class-mtd
View File

@ -104,7 +104,7 @@ Description:
One of the following ASCII strings, representing the device
type:
absent, ram, rom, nor, nand, dataflash, ubi, unknown
absent, ram, rom, nor, nand, mlc-nand, dataflash, ubi, unknown
What: /sys/class/mtd/mtdX/writesize
Date: April 2009

4
Documentation/ABI/testing/sysfs-class-net-batman-adv
View File

@ -1,13 +1,13 @@
What: /sys/class/net/<iface>/batman-adv/iface_status
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Indicates the status of <iface> as it is seen by batman.
What: /sys/class/net/<iface>/batman-adv/mesh_iface
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
The /sys/class/net/<iface>/batman-adv/mesh_iface file
displays the batman mesh interface this <iface>

34
Documentation/ABI/testing/sysfs-class-net-mesh
View File

@ -1,22 +1,23 @@
What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Indicates whether the batman protocol messages of the
mesh <mesh_iface> shall be aggregated or not.
What: /sys/class/net/<mesh_iface>/mesh/ap_isolation
What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation
Date: May 2011
Contact: Antonio Quartulli <ordex@autistici.org>
Contact: Antonio Quartulli <antonio@meshcoding.com>
Description:
Indicates whether the data traffic going from a
wireless client to another wireless client will be
silently dropped.
silently dropped. <vlan_subdir> is empty when referring
to the untagged lan.
What: /sys/class/net/<mesh_iface>/mesh/bonding
Date: June 2010
Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Contact: Simon Wunderlich <sw@simonwunderlich.de>
Description:
Indicates whether the data traffic going through the
mesh will be sent using multiple interfaces at the
@ -24,7 +25,7 @@ Description:
What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance
Date: November 2011
Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Contact: Simon Wunderlich <sw@simonwunderlich.de>
Description:
Indicates whether the bridge loop avoidance feature
is enabled. This feature detects and avoids loops
@ -41,21 +42,21 @@ Description:
What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
Date: October 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the bandwidth which is propagated by this
node if gw_mode was set to 'server'.
What: /sys/class/net/<mesh_iface>/mesh/gw_mode
Date: October 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the state of the gateway features. Can be
either 'off', 'client' or 'server'.
What: /sys/class/net/<mesh_iface>/mesh/gw_sel_class
Date: October 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the selection criteria this node will use
to choose a gateway if gw_mode was set to 'client'.
@ -77,25 +78,14 @@ Description:
What: /sys/class/net/<mesh_iface>/mesh/orig_interval
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the interval in milliseconds in which batman
sends its protocol messages.
What: /sys/class/net/<mesh_iface>/mesh/routing_algo
Date: Dec 2011
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the routing procotol this mesh instance
uses to find the optimal paths through the mesh.
What: /sys/class/net/<mesh_iface>/mesh/vis_mode
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Description:
Each batman node only maintains information about its
own local neighborhood, therefore generating graphs
showing the topology of the entire mesh is not easily
feasible without having a central instance to collect
the local topologies from all nodes. This file allows
to activate the collecting (server) mode.

152
Documentation/ABI/testing/sysfs-class-powercap Normal file
View File

@ -0,0 +1,152 @@
What: /sys/class/powercap/
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
The powercap/ class sub directory belongs to the power cap
subsystem. Refer to
Documentation/power/powercap/powercap.txt for details.
What: /sys/class/powercap/<control type>
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
A <control type> is a unique name under /sys/class/powercap.
Here <control type> determines how the power is going to be
controlled. A <control type> can contain multiple power zones.
What: /sys/class/powercap/<control type>/enabled
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
This allows to enable/disable power capping for a "control type".
This status affects every power zone using this "control_type.
What: /sys/class/powercap/<control type>/<power zone>
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
A power zone is a single or a collection of devices, which can
be independently monitored and controlled. A power zone sysfs
entry is qualified with the name of the <control type>.
E.g. intel-rapl:0:1:1.
What: /sys/class/powercap/<control type>/<power zone>/<child power zone>
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Power zones may be organized in a hierarchy in which child
power zones provide monitoring and control for a subset of
devices under the parent. For example, if there is a parent
power zone for a whole CPU package, each CPU core in it can
be a child power zone.
What: /sys/class/powercap/.../<power zone>/name
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Specifies the name of this power zone.
What: /sys/class/powercap/.../<power zone>/energy_uj
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Current energy counter in micro-joules. Write "0" to reset.
If the counter can not be reset, then this attribute is
read-only.
What: /sys/class/powercap/.../<power zone>/max_energy_range_uj
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Range of the above energy counter in micro-joules.
What: /sys/class/powercap/.../<power zone>/power_uw
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Current power in micro-watts.
What: /sys/class/powercap/.../<power zone>/max_power_range_uw
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Range of the above power value in micro-watts.
What: /sys/class/powercap/.../<power zone>/constraint_X_name
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Each power zone can define one or more constraints. Each
constraint can have an optional name. Here "X" can have values
from 0 to max integer.
What: /sys/class/powercap/.../<power zone>/constraint_X_power_limit_uw
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Power limit in micro-watts should be applicable for
the time window specified by "constraint_X_time_window_us".
Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/.../<power zone>/constraint_X_time_window_us
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Time window in micro seconds. This is used along with
constraint_X_power_limit_uw to define a power constraint.
Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/<control type>/.../constraint_X_max_power_uw
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Maximum allowed power in micro watts for this constraint.
Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/<control type>/.../constraint_X_min_power_uw
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Minimum allowed power in micro watts for this constraint.
Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/.../<power zone>/constraint_X_max_time_window_us
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Maximum allowed time window in micro seconds for this
constraint. Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/.../<power zone>/constraint_X_min_time_window_us
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Minimum allowed time window in micro seconds for this
constraint. Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/.../<power zone>/enabled
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description
This allows to enable/disable power capping at power zone level.
This applies to current power zone and its children.

37
Documentation/DMA-API-HOWTO.txt
View File

@ -101,14 +101,23 @@ style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.
The query is performed via a call to dma_set_mask():
The query is performed via a call to dma_set_mask_and_coherent():
int dma_set_mask(struct device *dev, u64 mask);
int dma_set_mask_and_coherent(struct device *dev, u64 mask);
The query for consistent allocations is performed via a call to
dma_set_coherent_mask():
which will query the mask for both streaming and coherent APIs together.
If you have some special requirements, then the following two separate
queries can be used instead:
int dma_set_coherent_mask(struct device *dev, u64 mask);
The query for streaming mappings is performed via a call to
dma_set_mask():
int dma_set_mask(struct device *dev, u64 mask);
The query for consistent allocations is performed via a call
to dma_set_coherent_mask():
int dma_set_coherent_mask(struct device *dev, u64 mask);
Here, dev is a pointer to the device struct of your device, and mask
is a bit mask describing which bits of an address your device
@ -137,7 +146,7 @@ exactly why.
The standard 32-bit addressing device would do something like this:
if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
printk(KERN_WARNING
"mydev: No suitable DMA available.\n");
goto ignore_this_device;
@ -171,22 +180,20 @@ the case would look like this:
int using_dac, consistent_using_dac;
if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
consistent_using_dac = 1;
dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
} else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
} else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
consistent_using_dac = 0;
dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
} else {
printk(KERN_WARNING
"mydev: No suitable DMA available.\n");
goto ignore_this_device;
}
dma_set_coherent_mask() will always be able to set the same or a
smaller mask as dma_set_mask(). However for the rare case that a
The coherent coherent mask will always be able to set the same or a
smaller mask as the streaming mask. However for the rare case that a
device driver only uses consistent allocations, one would have to
check the return value from dma_set_coherent_mask().
@ -199,9 +206,9 @@ address you might do something like:
goto ignore_this_device;
}
When dma_set_mask() is successful, and returns zero, the kernel saves
away this mask you have provided. The kernel will use this
information later when you make DMA mappings.
When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
returns zero, the kernel saves away this mask you have provided. The
kernel will use this information later when you make DMA mappings.
There is a case which we are aware of at this time, which is worth
mentioning in this documentation. If your device supports multiple

8
Documentation/DMA-API.txt
View File

@ -141,6 +141,14 @@ won't change the current mask settings. It is more intended as an
internal API for use by the platform than an external API for use by
driver writers.
int
dma_set_mask_and_coherent(struct device *dev, u64 mask)
Checks to see if the mask is possible and updates the device
streaming and coherent DMA mask parameters if it is.
Returns: 0 if successful and a negative error if not.
int
dma_set_mask(struct device *dev, u64 mask)

4
Documentation/DocBook/80211.tmpl
View File

@ -152,8 +152,8 @@
!Finclude/net/cfg80211.h cfg80211_scan_request
!Finclude/net/cfg80211.h cfg80211_scan_done
!Finclude/net/cfg80211.h cfg80211_bss
!Finclude/net/cfg80211.h cfg80211_inform_bss_frame
!Finclude/net/cfg80211.h cfg80211_inform_bss
!Finclude/net/cfg80211.h cfg80211_inform_bss_width_frame
!Finclude/net/cfg80211.h cfg80211_inform_bss_width
!Finclude/net/cfg80211.h cfg80211_unlink_bss
!Finclude/net/cfg80211.h cfg80211_find_ie
!Finclude/net/cfg80211.h ieee80211_bss_get_ie

2
Documentation/DocBook/mtdnand.tmpl
View File

@ -1222,8 +1222,6 @@ in this page</entry>
#define NAND_BBT_VERSION 0x00000100
/* Create a bbt if none axists */
#define NAND_BBT_CREATE 0x00000200
/* Search good / bad pattern through all pages of a block */
#define NAND_BBT_SCANALLPAGES 0x00000400
/* Write bbt if neccecary */
#define NAND_BBT_WRITE 0x00001000
/* Read and write back block contents when writing bbt */

8
Documentation/PCI/pci.txt
View File

@ -525,8 +525,9 @@ corresponding register block for you.
6. Other interesting functions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pci_find_slot() Find pci_dev corresponding to given bus and
slot numbers.
pci_get_domain_bus_and_slot() Find pci_dev corresponding to given domain,
bus and slot and number. If the device is
found, its reference count is increased.
pci_set_power_state() Set PCI Power Management state (0=D0 ... 3=D3)
pci_find_capability() Find specified capability in device's capability
list.
@ -582,7 +583,8 @@ having sane locking.
pci_find_device() Superseded by pci_get_device()
pci_find_subsys() Superseded by pci_get_subsys()
pci_find_slot() Superseded by pci_get_slot()
pci_find_slot() Superseded by pci_get_domain_bus_and_slot()
pci_get_slot() Superseded by pci_get_domain_bus_and_slot()
The alternative is the traditional PCI device driver that walks PCI

26
Documentation/acpi/enumeration.txt
View File

@ -295,10 +295,6 @@ These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
specifies the path to the controller. In order to use these GPIOs in Linux
we need to translate them to the Linux GPIO numbers.
The driver can do this by including <linux/acpi_gpio.h> and then calling
acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
negative errno if there was no translation found.
In a simple case of just getting the Linux GPIO number from device
resources one can use acpi_get_gpio_by_index() helper function. It takes
pointer to the device and index of the GpioIo/GpioInt descriptor in the
@ -322,3 +318,25 @@ suitable to the gpiolib before passing them.
In case of GpioInt resource an additional call to gpio_to_irq() must be
done before calling request_irq().
Note that the above API is ACPI specific and not recommended for drivers
that need to support non-ACPI systems. The recommended way is to use
the descriptor based GPIO interfaces. The above example looks like this
when converted to the GPIO desc:
#include <linux/gpio/consumer.h>
...
struct gpio_desc *irq_desc, *power_desc;
irq_desc = gpiod_get_index(dev, NULL, 1);
if (IS_ERR(irq_desc))
/* handle error */
power_desc = gpiod_get_index(dev, NULL, 0);
if (IS_ERR(power_desc))
/* handle error */
/* Now we can use the GPIO descriptors */
See also Documentation/gpio.txt.

5
Documentation/backlight/lp855x-driver.txt
View File

@ -4,7 +4,8 @@ Kernel driver lp855x
Backlight driver for LP855x ICs
Supported chips:
Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
LP8557
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
@ -24,7 +25,7 @@ Value : pwm based or register based
2) chip_id
The lp855x chip id.
Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
Value : lp8550/lp8551/lp8552/lp8553/lp8555/lp8556/lp8557
Platform data for lp855x
------------------------

6
Documentation/blockdev/floppy.txt
View File

@ -39,15 +39,15 @@ Module configuration options
============================
If you use the floppy driver as a module, use the following syntax:
modprobe floppy <options>
modprobe floppy floppy="<options>"
Example:
modprobe floppy omnibook messages
modprobe floppy floppy="omnibook messages"
If you need certain options enabled every time you load the floppy driver,
you can put:
options floppy omnibook messages
options floppy floppy="omnibook messages"
in a configuration file in /etc/modprobe.d/.

10
Documentation/cgroups/memory.txt
View File

@ -573,15 +573,19 @@ an memcg since the pages are allowed to be allocated from any physical
node. One of the use cases is evaluating application performance by
combining this information with the application's CPU allocation.
We export "total", "file", "anon" and "unevictable" pages per-node for
each memcg. The ouput format of memory.numa_stat is:
Each memcg's numa_stat file includes "total", "file", "anon" and "unevictable"
per-node page counts including "hierarchical_<counter>" which sums up all
hierarchical children's values in addition to the memcg's own value.
The ouput format of memory.numa_stat is:
total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
hierarchical_<counter>=<counter pages> N0=<node 0 pages> N1=<node 1 pages> ...
And we have total = file + anon + unevictable.
The "total" count is sum of file + anon + unevictable.
6. Hierarchy support

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

@ -23,8 +23,8 @@ Contents:
1.1 Initialization
1.2 Per-CPU Initialization
1.3 verify
1.4 target or setpolicy?
1.5 target
1.4 target/target_index or setpolicy?
1.5 target/target_index
1.6 setpolicy
2. Frequency Table Helpers
@ -56,7 +56,8 @@ cpufreq_driver.init - A pointer to the per-CPU initialization
cpufreq_driver.verify - A pointer to a "verification" function.
cpufreq_driver.setpolicy _or_
cpufreq_driver.target - See below on the differences.
cpufreq_driver.target/
target_index - See below on the differences.
And optionally
@ -66,7 +67,7 @@ cpufreq_driver.resume - A pointer to a per-CPU resume function
which is called with interrupts disabled
and _before_ the pre-suspend frequency
and/or policy is restored by a call to
->target or ->setpolicy.
->target/target_index or ->setpolicy.
cpufreq_driver.attr - A pointer to a NULL-terminated list of
"struct freq_attr" which allow to
@ -103,8 +104,8 @@ policy->governor must contain the "default policy" for
this CPU. A few moments later,
cpufreq_driver.verify and either
cpufreq_driver.setpolicy or
cpufreq_driver.target is called with
these values.
cpufreq_driver.target/target_index is called
with these values.
For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the
frequency table helpers might be helpful. See the section 2 for more information
@ -133,20 +134,28 @@ range) is within policy->min and policy->max. If necessary, increase
policy->max first, and only if this is no solution, decrease policy->min.
1.4 target or setpolicy?
1.4 target/target_index or setpolicy?
----------------------------
Most cpufreq drivers or even most cpu frequency scaling algorithms
only allow the CPU to be set to one frequency. For these, you use the
->target call.
->target/target_index call.
Some cpufreq-capable processors switch the frequency between certain
limits on their own. These shall use the ->setpolicy call
1.4. target
1.4. target/target_index
-------------
The target_index call has two arguments: struct cpufreq_policy *policy,
and unsigned int index (into the exposed frequency table).
The CPUfreq driver must set the new frequency when called here. The
actual frequency must be determined by freq_table[index].frequency.
Deprecated:
----------
The target call has three arguments: struct cpufreq_policy *policy,
unsigned int target_frequency, unsigned int relation.

4
Documentation/cpu-freq/governors.txt
View File

@ -40,7 +40,7 @@ Most cpufreq drivers (in fact, all except one, longrun) or even most
cpu frequency scaling algorithms only offer the CPU to be set to one
frequency. In order to offer dynamic frequency scaling, the cpufreq
core must be able to tell these drivers of a "target frequency". So
these specific drivers will be transformed to offer a "->target"
these specific drivers will be transformed to offer a "->target/target_index"
call instead of the existing "->setpolicy" call. For "longrun", all
stays the same, though.
@ -71,7 +71,7 @@ CPU can be set to switch independently | CPU can only be set
/ the limits of policy->{min,max}
/ \
/ \
Using the ->setpolicy call, Using the ->target call,
Using the ->setpolicy call, Using the ->target/target_index call,
the limits and the the frequency closest
"policy" is set. to target_freq is set.
It is assured that it

2
Documentation/cpu-hotplug.txt
View File

@ -5,7 +5,7 @@
Rusty Russell <rusty@rustcorp.com.au>
Srivatsa Vaddagiri <vatsa@in.ibm.com>
i386:
Zwane Mwaikambo <zwane@arm.linux.org.uk>
Zwane Mwaikambo <zwanem@gmail.com>
ppc64:
Nathan Lynch <nathanl@austin.ibm.com>
Joel Schopp <jschopp@austin.ibm.com>

1
Documentation/cpuidle/governor.txt
View File

@ -25,5 +25,4 @@ kernel configuration and platform will be selected by cpuidle.
Interfaces:
extern int cpuidle_register_governor(struct cpuidle_governor *gov);
extern void cpuidle_unregister_governor(struct cpuidle_governor *gov);
struct cpuidle_governor

6
Documentation/device-mapper/cache-policies.txt
View File

@ -30,8 +30,10 @@ multiqueue
This policy is the default.
The multiqueue policy has two sets of 16 queues: one set for entries
waiting for the cache and another one for those in the cache.
The multiqueue policy has three sets of 16 queues: one set for entries
waiting for the cache and another two for those in the cache (a set for
clean entries and a set for dirty entries).
Cache entries in the queues are aged based on logical time. Entry into
the cache is based on variable thresholds and queue selection is based
on hit count on entry. The policy aims to take different cache miss

57
Documentation/device-mapper/cache.txt
View File

@ -68,10 +68,11 @@ So large block sizes are bad because they waste cache space. And small
block sizes are bad because they increase the amount of metadata (both
in core and on disk).
Writeback/writethrough
----------------------
Cache operating modes
---------------------
The cache has two modes, writeback and writethrough.
The cache has three operating modes: writeback, writethrough and
passthrough.
If writeback, the default, is selected then a write to a block that is
cached will go only to the cache and the block will be marked dirty in
@ -81,8 +82,31 @@ If writethrough is selected then a write to a cached block will not
complete until it has hit both the origin and cache devices. Clean
blocks should remain clean.
If passthrough is selected, useful when the cache contents are not known
to be coherent with the origin device, then all reads are served from
the origin device (all reads miss the cache) and all writes are
forwarded to the origin device; additionally, write hits cause cache
block invalidates. To enable passthrough mode the cache must be clean.
Passthrough mode allows a cache device to be activated without having to
worry about coherency. Coherency that exists is maintained, although
the cache will gradually cool as writes take place. If the coherency of
the cache can later be verified, or established through use of the
"invalidate_cblocks" message, the cache device can be transitioned to
writethrough or writeback mode while still warm. Otherwise, the cache
contents can be discarded prior to transitioning to the desired
operating mode.
A simple cleaner policy is provided, which will clean (write back) all
dirty blocks in a cache. Useful for decommissioning a cache.
dirty blocks in a cache. Useful for decommissioning a cache or when
shrinking a cache. Shrinking the cache's fast device requires all cache
blocks, in the area of the cache being removed, to be clean. If the
area being removed from the cache still contains dirty blocks the resize
will fail. Care must be taken to never reduce the volume used for the
cache's fast device until the cache is clean. This is of particular
importance if writeback mode is used. Writethrough and passthrough
modes already maintain a clean cache. Future support to partially clean
the cache, above a specified threshold, will allow for keeping the cache
warm and in writeback mode during resize.
Migration throttling
--------------------
@ -161,7 +185,7 @@ Constructor
block size : cache unit size in sectors
#feature args : number of feature arguments passed
feature args : writethrough. (The default is writeback.)
feature args : writethrough or passthrough (The default is writeback.)
policy : the replacement policy to use
#policy args : an even number of arguments corresponding to
@ -177,6 +201,13 @@ Optional feature arguments are:
back cache block contents later for performance reasons,
so they may differ from the corresponding origin blocks.
passthrough : a degraded mode useful for various cache coherency
situations (e.g., rolling back snapshots of
underlying storage). Reads and writes always go to
the origin. If a write goes to a cached origin
block, then the cache block is invalidated.
To enable passthrough mode the cache must be clean.
A policy called 'default' is always registered. This is an alias for
the policy we currently think is giving best all round performance.
@ -231,12 +262,26 @@ The message format is:
E.g.
dmsetup message my_cache 0 sequential_threshold 1024
Invalidation is removing an entry from the cache without writing it
back. Cache blocks can be invalidated via the invalidate_cblocks
message, which takes an arbitrary number of cblock ranges. Each cblock
must be expressed as a decimal value, in the future a variant message
that takes cblock ranges expressed in hexidecimal may be needed to
better support efficient invalidation of larger caches. The cache must
be in passthrough mode when invalidate_cblocks is used.
invalidate_cblocks [<cblock>|<cblock begin>-<cblock end>]*
E.g.
dmsetup message my_cache 0 invalidate_cblocks 2345 3456-4567 5678-6789
Examples
========
The test suite can be found here:
https://github.com/jthornber/thinp-test-suite
https://github.com/jthornber/device-mapper-test-suite
dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \
/dev/mapper/ssd /dev/mapper/origin 512 1 writeback default 0'

11
Documentation/device-mapper/dm-crypt.txt
View File

@ -4,12 +4,15 @@ dm-crypt
Device-Mapper's "crypt" target provides transparent encryption of block devices
using the kernel crypto API.
For a more detailed description of supported parameters see:
http://code.google.com/p/cryptsetup/wiki/DMCrypt
Parameters: <cipher> <key> <iv_offset> <device path> \
<offset> [<#opt_params> <opt_params>]
<cipher>
Encryption cipher and an optional IV generation mode.
(In format cipher[:keycount]-chainmode-ivopts:ivmode).
(In format cipher[:keycount]-chainmode-ivmode[:ivopts]).
Examples:
des
aes-cbc-essiv:sha256
@ -19,7 +22,11 @@ Parameters: <cipher> <key> <iv_offset> <device path> \
<key>
Key used for encryption. It is encoded as a hexadecimal number.
You can only use key sizes that are valid for the selected cipher.
You can only use key sizes that are valid for the selected cipher
in combination with the selected iv mode.
Note that for some iv modes the key string can contain additional
keys (for example IV seed) so the key contains more parts concatenated
into a single string.
<keycount>
Multi-key compatibility mode. You can define <keycount> keys and

1
Documentation/devices.txt
View File

@ -414,6 +414,7 @@ Your cooperation is appreciated.
200 = /dev/net/tun TAP/TUN network device
201 = /dev/button/gulpb Transmeta GULP-B buttons
202 = /dev/emd/ctl Enhanced Metadisk RAID (EMD) control
203 = /dev/cuse Cuse (character device in user-space)
204 = /dev/video/em8300 EM8300 DVD decoder control
205 = /dev/video/em8300_mv EM8300 DVD decoder video
206 = /dev/video/em8300_ma EM8300 DVD decoder audio

393
Documentation/devicetree/bindings/arm/cpus.txt
View File

@ -1,77 +1,384 @@
* ARM CPUs binding description
=================
ARM CPUs bindings
=================
The device tree allows to describe the layout of CPUs in a system through
the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
defining properties for every cpu.
Bindings for CPU nodes follow the ePAPR standard, available from:
Bindings for CPU nodes follow the ePAPR v1.1 standard, available from:
http://devicetree.org
https://www.power.org/documentation/epapr-version-1-1/
For the ARM architecture every CPU node must contain the following properties:
with updates for 32-bit and 64-bit ARM systems provided in this document.
- device_type: must be "cpu"
- reg: property matching the CPU MPIDR[23:0] register bits
reg[31:24] bits must be set to 0
- compatible: should be one of:
"arm,arm1020"
"arm,arm1020e"
"arm,arm1022"
"arm,arm1026"
"arm,arm720"
"arm,arm740"
"arm,arm7tdmi"
"arm,arm920"
"arm,arm922"
"arm,arm925"
"arm,arm926"
"arm,arm940"
"arm,arm946"
"arm,arm9tdmi"
"arm,cortex-a5"
"arm,cortex-a7"
"arm,cortex-a8"
"arm,cortex-a9"
"arm,cortex-a15"
"arm,arm1136"
"arm,arm1156"
"arm,arm1176"
"arm,arm11mpcore"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
"marvell,feroceon"
"marvell,mohawk"
"marvell,xsc3"
"marvell,xscale"
================================
Convention used in this document
================================
Example:
This document follows the conventions described in the ePAPR v1.1, with
the addition:
- square brackets define bitfields, eg reg[7:0] value of the bitfield in
the reg property contained in bits 7 down to 0
=====================================
cpus and cpu node bindings definition
=====================================
The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu
nodes to be present and contain the properties described below.
- cpus node
Description: Container of cpu nodes
The node name must be "cpus".
A cpus node must define the following properties:
- #address-cells
Usage: required
Value type: <u32>
Definition depends on ARM architecture version and
configuration:
# On uniprocessor ARM architectures previous to v7
value must be 1, to enable a simple enumeration
scheme for processors that do not have a HW CPU
identification register.
# On 32-bit ARM 11 MPcore, ARM v7 or later systems
value must be 1, that corresponds to CPUID/MPIDR
registers sizes.
# On ARM v8 64-bit systems value should be set to 2,
that corresponds to the MPIDR_EL1 register size.
If MPIDR_EL1[63:32] value is equal to 0 on all CPUs
in the system, #address-cells can be set to 1, since
MPIDR_EL1[63:32] bits are not used for CPUs
identification.
- #size-cells
Usage: required
Value type: <u32>
Definition: must be set to 0
- cpu node
Description: Describes a CPU in an ARM based system
PROPERTIES
- device_type
Usage: required
Value type: <string>
Definition: must be "cpu"
- reg
Usage and definition depend on ARM architecture version and
configuration:
# On uniprocessor ARM architectures previous to v7
this property is required and must be set to 0.
# On ARM 11 MPcore based systems this property is
required and matches the CPUID[11:0] register bits.
Bits [11:0] in the reg cell must be set to
bits [11:0] in CPU ID register.
All other bits in the reg cell must be set to 0.
# On 32-bit ARM v7 or later systems this property is
required and matches the CPU MPIDR[23:0] register
bits.
Bits [23:0] in the reg cell must be set to
bits [23:0] in MPIDR.
All other bits in the reg cell must be set to 0.
# On ARM v8 64-bit systems this property is required
and matches the MPIDR_EL1 register affinity bits.
* If cpus node's #address-cells property is set to 2
The first reg cell bits [7:0] must be set to
bits [39:32] of MPIDR_EL1.
The second reg cell bits [23:0] must be set to
bits [23:0] of MPIDR_EL1.
* If cpus node's #address-cells property is set to 1
The reg cell bits [23:0] must be set to bits [23:0]
of MPIDR_EL1.
All other bits in the reg cells must be set to 0.
- compatible:
Usage: required
Value type: <string>
Definition: should be one of:
"arm,arm710t"
"arm,arm720t"
"arm,arm740t"
"arm,arm7ej-s"
"arm,arm7tdmi"
"arm,arm7tdmi-s"
"arm,arm9es"
"arm,arm9ej-s"
"arm,arm920t"
"arm,arm922t"
"arm,arm925"
"arm,arm926e-s"
"arm,arm926ej-s"
"arm,arm940t"
"arm,arm946e-s"
"arm,arm966e-s"
"arm,arm968e-s"
"arm,arm9tdmi"
"arm,arm1020e"
"arm,arm1020t"
"arm,arm1022e"
"arm,arm1026ej-s"
"arm,arm1136j-s"
"arm,arm1136jf-s"
"arm,arm1156t2-s"
"arm,arm1156t2f-s"
"arm,arm1176jzf"
"arm,arm1176jz-s"
"arm,arm1176jzf-s"
"arm,arm11mpcore"
"arm,cortex-a5"
"arm,cortex-a7"
"arm,cortex-a8"
"arm,cortex-a9"
"arm,cortex-a15"
"arm,cortex-a53"
"arm,cortex-a57"
"arm,cortex-m0"
"arm,cortex-m0+"
"arm,cortex-m1"
"arm,cortex-m3"
"arm,cortex-m4"
"arm,cortex-r4"
"arm,cortex-r5"
"arm,cortex-r7"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
"marvell,feroceon"
"marvell,mohawk"
"marvell,pj4a"
"marvell,pj4b"
"marvell,sheeva-v5"
"qcom,krait"
"qcom,scorpion"
- enable-method
Value type: <stringlist>
Usage and definition depend on ARM architecture version.
# On ARM v8 64-bit this property is required and must
be one of:
"spin-table"
"psci"
# On ARM 32-bit systems this property is optional.
- cpu-release-addr
Usage: required for systems that have an "enable-method"
property value of "spin-table".
Value type: <prop-encoded-array>
Definition:
# On ARM v8 64-bit systems must be a two cell
property identifying a 64-bit zero-initialised
memory location.
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
#size-cells = <0>;
#address-cells = <1>;
CPU0: cpu@0 {
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
};
CPU1: cpu@1 {
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
};
CPU2: cpu@100 {
cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
};
CPU3: cpu@101 {
cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
};
};
Example 2 (Cortex-A8 uniprocessor 32-bit system):
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a8";
reg = <0x0>;
};
};
Example 3 (ARM 926EJ-S uniprocessor 32-bit system):
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu@0 {
device_type = "cpu";
compatible = "arm,arm926ej-s";
reg = <0x0>;
};
};
Example 4 (ARM Cortex-A57 64-bit system):
cpus {
#size-cells = <0>;
#address-cells = <2>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
};

474
Documentation/devicetree/bindings/arm/topology.txt Normal file
View File

@ -0,0 +1,474 @@
===========================================
ARM topology binding description
===========================================
===========================================
1 - Introduction
===========================================
In an ARM system, the hierarchy of CPUs is defined through three entities that
are used to describe the layout of physical CPUs in the system:
- cluster
- core
- thread
The cpu nodes (bindings defined in [1]) represent the devices that
correspond to physical CPUs and are to be mapped to the hierarchy levels.
The bottom hierarchy level sits at core or thread level depending on whether
symmetric multi-threading (SMT) is supported or not.
For instance in a system where CPUs support SMT, "cpu" nodes represent all
threads existing in the system and map to the hierarchy level "thread" above.
In systems where SMT is not supported "cpu" nodes represent all cores present
in the system and map to the hierarchy level "core" above.
ARM topology bindings allow one to associate cpu nodes with hierarchical groups
corresponding to the system hierarchy; syntactically they are defined as device
tree nodes.
The remainder of this document provides the topology bindings for ARM, based
on the ePAPR standard, available from:
http://www.power.org/documentation/epapr-version-1-1/
If not stated otherwise, whenever a reference to a cpu node phandle is made its
value must point to a cpu node compliant with the cpu node bindings as
documented in [1].
A topology description containing phandles to cpu nodes that are not compliant
with bindings standardized in [1] is therefore considered invalid.
===========================================
2 - cpu-map node
===========================================
The ARM CPU topology is defined within the cpu-map node, which is a direct
child of the cpus node and provides a container where the actual topology
nodes are listed.
- cpu-map node
Usage: Optional - On ARM SMP systems provide CPUs topology to the OS.
ARM uniprocessor systems do not require a topology
description and therefore should not define a
cpu-map node.
Description: The cpu-map node is just a container node where its
subnodes describe the CPU topology.
Node name must be "cpu-map".
The cpu-map node's parent node must be the cpus node.
The cpu-map node's child nodes can be:
- one or more cluster nodes
Any other configuration is considered invalid.
The cpu-map node can only contain three types of child nodes:
- cluster node
- core node
- thread node
whose bindings are described in paragraph 3.
The nodes describing the CPU topology (cluster/core/thread) can only be
defined within the cpu-map node.
Any other configuration is consider invalid and therefore must be ignored.
===========================================
2.1 - cpu-map child nodes naming convention
===========================================
cpu-map child nodes must follow a naming convention where the node name
must be "clusterN", "coreN", "threadN" depending on the node type (ie
cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
are siblings within a single common parent node must be given a unique and
sequential N value, starting from 0).
cpu-map child nodes which do not share a common parent node can have the same
name (ie same number N as other cpu-map child nodes at different device tree
levels) since name uniqueness will be guaranteed by the device tree hierarchy.
===========================================
3 - cluster/core/thread node bindings
===========================================
Bindings for cluster/cpu/thread nodes are defined as follows:
- cluster node
Description: must be declared within a cpu-map node, one node
per cluster. A system can contain several layers of
clustering and cluster nodes can be contained in parent
cluster nodes.
The cluster node name must be "clusterN" as described in 2.1 above.
A cluster node can not be a leaf node.
A cluster node's child nodes must be:
- one or more cluster nodes; or
- one or more core nodes
Any other configuration is considered invalid.
- core node
Description: must be declared in a cluster node, one node per core in
the cluster. If the system does not support SMT, core
nodes are leaf nodes, otherwise they become containers of
thread nodes.
The core node name must be "coreN" as described in 2.1 above.
A core node must be a leaf node if SMT is not supported.
Properties for core nodes that are leaf nodes:
- cpu
Usage: required
Value type: <phandle>
Definition: a phandle to the cpu node that corresponds to the
core node.
If a core node is not a leaf node (CPUs supporting SMT) a core node's
child nodes can be:
- one or more thread nodes
Any other configuration is considered invalid.
- thread node
Description: must be declared in a core node, one node per thread
in the core if the system supports SMT. Thread nodes are
always leaf nodes in the device tree.
The thread node name must be "threadN" as described in 2.1 above.
A thread node must be a leaf node.
A thread node must contain the following property:
- cpu
Usage: required
Value type: <phandle>
Definition: a phandle to the cpu node that corresponds to
the thread node.
===========================================
4 - Example dts
===========================================
Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
cpus {
#size-cells = <0>;
#address-cells = <2>;
cpu-map {
cluster0 {
cluster0 {
core0 {
thread0 {
cpu = <&CPU0>;
};
thread1 {
cpu = <&CPU1>;
};
};
core1 {
thread0 {
cpu = <&CPU2>;
};
thread1 {
cpu = <&CPU3>;
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <&CPU4>;
};
thread1 {
cpu = <&CPU5>;
};
};
core1 {
thread0 {
cpu = <&CPU6>;
};
thread1 {
cpu = <&CPU7>;
};
};
};
};
cluster1 {
cluster0 {
core0 {
thread0 {
cpu = <&CPU8>;
};
thread1 {
cpu = <&CPU9>;
};
};
core1 {
thread0 {
cpu = <&CPU10>;
};
thread1 {
cpu = <&CPU11>;
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <&CPU12>;
};
thread1 {
cpu = <&CPU13>;
};
};
core1 {
thread0 {
cpu = <&CPU14>;
};
thread1 {
cpu = <&CPU15>;
};
};
};
};
};
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU4: cpu@10000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU5: cpu@10001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU6: cpu@10100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU7: cpu@10101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU8: cpu@100000000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU9: cpu@100000001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU10: cpu@100000100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU11: cpu@100000101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU12: cpu@100010000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU13: cpu@100010001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU14: cpu@100010100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU15: cpu@100010101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
};
Example 2 (ARM 32-bit, dual-cluster, 8-cpu system, no SMT):
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu-map {
cluster0 {
core0 {
cpu = <&CPU0>;
};
core1 {
cpu = <&CPU1>;
};
core2 {
cpu = <&CPU2>;
};
core3 {
cpu = <&CPU3>;
};
};
cluster1 {
core0 {
cpu = <&CPU4>;
};
core1 {
cpu = <&CPU5>;
};
core2 {
cpu = <&CPU6>;
};
core3 {
cpu = <&CPU7>;
};
};
};
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
};
CPU2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
};
CPU3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
};
CPU4: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
};
CPU5: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
};
CPU6: cpu@102 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
};
CPU7: cpu@103 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
};
};
===============================================================================
[1] ARM Linux kernel documentation
Documentation/devicetree/bindings/arm/cpus.txt

11
Documentation/devicetree/bindings/clock/efm32-clock.txt Normal file
View File

@ -0,0 +1,11 @@
* Clock bindings for Energy Micro efm32 Giant Gecko's Clock Management Unit
Required properties:
- compatible: Should be "efm32gg,cmu"
- reg: Base address and length of the register set
- interrupts: Interrupt used by the CMU
- #clock-cells: Should be <1>
The clock consumer should specify the desired clock by having the clock ID in
its "clocks" phandle cell. The header efm32-clk.h contains a list of available
IDs.

29
Documentation/devicetree/bindings/clock/keystone-gate.txt Normal file
View File

@ -0,0 +1,29 @@
Status: Unstable - ABI compatibility may be broken in the future
Binding for Keystone gate control driver which uses PSC controller IP.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "ti,keystone,psc-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : parent clock phandle
- reg : psc control and domain address address space
- reg-names : psc control and domain registers
- domain-id : psc domain id needed to check the transition state register
Optional properties:
- clock-output-names : From common clock binding to override the
default output clock name
Example:
clkusb: clkusb {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk16>;
clock-output-names = "usb";
reg = <0x02350008 0xb00>, <0x02350000 0x400>;
reg-names = "control", "domain";
domain-id = <0>;
};

84
Documentation/devicetree/bindings/clock/keystone-pll.txt Normal file
View File

@ -0,0 +1,84 @@
Status: Unstable - ABI compatibility may be broken in the future
Binding for keystone PLLs. The main PLL IP typically has a multiplier,
a divider and a post divider. The additional PLL IPs like ARMPLL, DDRPLL
and PAPLL are controlled by the memory mapped register where as the Main
PLL is controlled by a PLL controller registers along with memory mapped
registers.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- #clock-cells : from common clock binding; shall be set to 0.
- compatible : shall be "ti,keystone,main-pll-clock" or "ti,keystone,pll-clock"
- clocks : parent clock phandle
- reg - pll control0 and pll multipler registers
- reg-names : control and multiplier. The multiplier is applicable only for
main pll clock
- fixed-postdiv : fixed post divider value
Example:
mainpllclk: mainpllclk@2310110 {
#clock-cells = <0>;
compatible = "ti,keystone,main-pll-clock";
clocks = <&refclkmain>;
reg = <0x02620350 4>, <0x02310110 4>;
reg-names = "control", "multiplier";
fixed-postdiv = <2>;
};
papllclk: papllclk@2620358 {
#clock-cells = <0>;
compatible = "ti,keystone,pll-clock";
clocks = <&refclkmain>;
clock-output-names = "pa-pll-clk";
reg = <0x02620358 4>;
reg-names = "control";
fixed-postdiv = <6>;
};
Required properties:
- #clock-cells : from common clock binding; shall be set to 0.
- compatible : shall be "ti,keystone,pll-mux-clock"
- clocks : link phandles of parent clocks
- reg - pll mux register
- bit-shift : number of bits to shift the bit-mask
- bit-mask : arbitrary bitmask for programming the mux
Optional properties:
- clock-output-names : From common clock binding.
Example:
mainmuxclk: mainmuxclk@2310108 {
#clock-cells = <0>;
compatible = "ti,keystone,pll-mux-clock";
clocks = <&mainpllclk>, <&refclkmain>;
reg = <0x02310108 4>;
bit-shift = <23>;
bit-mask = <1>;
clock-output-names = "mainmuxclk";
};
Required properties:
- #clock-cells : from common clock binding; shall be set to 0.
- compatible : shall be "ti,keystone,pll-divider-clock"
- clocks : parent clock phandle
- reg - pll mux register
- bit-shift : number of bits to shift the bit-mask
- bit-mask : arbitrary bitmask for programming the divider
Optional properties:
- clock-output-names : From common clock binding.
Example:
gemtraceclk: gemtraceclk@2310120 {
#clock-cells = <0>;
compatible = "ti,keystone,pll-divider-clock";
clocks = <&mainmuxclk>;
reg = <0x02310120 4>;
bit-shift = <0>;
bit-mask = <8>;
clock-output-names = "gemtraceclk";
};

111
Documentation/devicetree/bindings/clock/xgene.txt Normal file
View File

@ -0,0 +1,111 @@
Device Tree Clock bindings for APM X-Gene
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be one of the following:
"apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock
"apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock
"apm,xgene-device-clock" - for a X-Gene device clock
Required properties for SoC or PCP PLL clocks:
- reg : shall be the physical PLL register address for the pll clock.
- clocks : shall be the input parent clock phandle for the clock. This should
be the reference clock.
- #clock-cells : shall be set to 1.
- clock-output-names : shall be the name of the PLL referenced by derive
clock.
Optional properties for PLL clocks:
- clock-names : shall be the name of the PLL. If missing, use the device name.
Required properties for device clocks:
- reg : shall be a list of address and length pairs describing the CSR
reset and/or the divider. Either may be omitted, but at least
one must be present.
- reg-names : shall be a string list describing the reg resource. This
may include "csr-reg" and/or "div-reg". If this property
is not present, the reg property is assumed to describe
only "csr-reg".
- clocks : shall be the input parent clock phandle for the clock.
- #clock-cells : shall be set to 1.
- clock-output-names : shall be the name of the device referenced.
Optional properties for device clocks:
- clock-names : shall be the name of the device clock. If missing, use the
device name.
- csr-offset : Offset to the CSR reset register from the reset address base.
Default is 0.
- csr-mask : CSR reset mask bit. Default is 0xF.
- enable-offset : Offset to the enable register from the reset address base.
Default is 0x8.
- enable-mask : CSR enable mask bit. Default is 0xF.
- divider-offset : Offset to the divider CSR register from the divider base.
Default is 0x0.
- divider-width : Width of the divider register. Default is 0.
- divider-shift : Bit shift of the divider register. Default is 0.
For example:
pcppll: pcppll@17000100 {
compatible = "apm,xgene-pcppll-clock";
#clock-cells = <1>;
clocks = <&refclk 0>;
clock-names = "pcppll";
reg = <0x0 0x17000100 0x0 0x1000>;
clock-output-names = "pcppll";
type = <0>;
};
socpll: socpll@17000120 {
compatible = "apm,xgene-socpll-clock";
#clock-cells = <1>;
clocks = <&refclk 0>;
clock-names = "socpll";
reg = <0x0 0x17000120 0x0 0x1000>;
clock-output-names = "socpll";
type = <1>;
};
qmlclk: qmlclk {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
clocks = <&socplldiv2 0>;
clock-names = "qmlclk";
reg = <0x0 0x1703C000 0x0 0x1000>;
reg-name = "csr-reg";
clock-output-names = "qmlclk";
};
ethclk: ethclk {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
clocks = <&socplldiv2 0>;
clock-names = "ethclk";
reg = <0x0 0x17000000 0x0 0x1000>;
reg-names = "div-reg";
divider-offset = <0x238>;
divider-width = <0x9>;
divider-shift = <0x0>;
clock-output-names = "ethclk";
};
apbclk: apbclk {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
clocks = <&ahbclk 0>;
clock-names = "apbclk";
reg = <0x0 0x1F2AC000 0x0 0x1000
0x0 0x1F2AC000 0x0 0x1000>;
reg-names = "csr-reg", "div-reg";
csr-offset = <0x0>;
csr-mask = <0x200>;
enable-offset = <0x8>;
enable-mask = <0x200>;
divider-offset = <0x10>;
divider-width = <0x2>;
divider-shift = <0x0>;
flags = <0x8>;
clock-output-names = "apbclk";
};

36
Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt Normal file
View File

@ -0,0 +1,36 @@
* Abilis TB10x GPIO controller
Required Properties:
- compatible: Should be "abilis,tb10x-gpio"
- reg: Address and length of the register set for the device
- gpio-controller: Marks the device node as a gpio controller.
- #gpio-cells: Should be <2>. The first cell is the pin number and the
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted).
- abilis,ngpio: the number of GPIO pins this driver controls.
Optional Properties:
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells: Should be <1>. Interrupts are triggered on both edges.
- interrupts: Defines the interrupt line connecting this GPIO controller to
its parent interrupt controller.
- interrupt-parent: Defines the parent interrupt controller.
GPIO ranges are specified as described in
Documentation/devicetree/bindings/gpio/gpio.txt
Example:
gpioa: gpio@FF140000 {
compatible = "abilis,tb10x-gpio";
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&tb10x_ictl>;
interrupts = <27 2>;
reg = <0xFF140000 0x1000>;
gpio-controller;
#gpio-cells = <2>;
abilis,ngpio = <3>;
gpio-ranges = <&iomux 0 0 0>;
gpio-ranges-group-names = "gpioa_pins";
};

52
Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt Normal file
View File

@ -0,0 +1,52 @@
Broadcom Kona Family GPIO
=========================
This GPIO driver is used in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
The Broadcom GPIO Controller IP can be configured prior to synthesis to
support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The
GPIO controller only supports edge, not level, triggering of interrupts.
Required properties
-------------------
- compatible: "brcm,bcm11351-gpio", "brcm,kona-gpio"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller. There is one GPIO
interrupt per GPIO bank. The number of interrupts listed depends on the
number of GPIO banks on the SoC. The interrupts must be ordered by bank,
starting with bank 0. There is always a 1:1 mapping between banks and
IRQs.
- #gpio-cells: Should be <2>. The first cell is the pin number, the second
cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
See also "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt.
- #interrupt-cells: Should be <2>. The first cell is the GPIO number. The
second cell is used to specify flags. The following subset of flags is
supported:
- trigger type (bits[1:0]):
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
3 = low-to-high or high-to-low edge triggered
Valid values are 1, 2, 3
See also .../devicetree/bindings/interrupt-controller/interrupts.txt.
- gpio-controller: Marks the device node as a GPIO controller.
- interrupt-controller: Marks the device node as an interrupt controller.
Example:
gpio: gpio@35003000 {
compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio";
reg = <0x35003000 0x800>;
interrupts =
<GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH
GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
#interrupt-cells = <2>;
gpio-controller;
interrupt-controller;
};

71
Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt Normal file
View File

@ -0,0 +1,71 @@
* PCF857x-compatible I/O expanders
The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be
driven high by a pull-up current source or driven low to ground. This combines
the direction and output level into a single bit per line, which can't be read
back. We can't actually know at initialization time whether a line is configured
(a) as output and driving the signal low/high, or (b) as input and reporting a
low/high value, without knowing the last value written since the chip came out
of reset (if any). The only reliable solution for setting up line direction is
thus to do it explicitly.
Required Properties:
- compatible: should be one of the following.
- "maxim,max7328": For the Maxim MAX7378
- "maxim,max7329": For the Maxim MAX7329
- "nxp,pca8574": For the NXP PCA8574
- "nxp,pca8575": For the NXP PCA8575
- "nxp,pca9670": For the NXP PCA9670
- "nxp,pca9671": For the NXP PCA9671
- "nxp,pca9672": For the NXP PCA9672
- "nxp,pca9673": For the NXP PCA9673
- "nxp,pca9674": For the NXP PCA9674
- "nxp,pca9675": For the NXP PCA9675
- "nxp,pcf8574": For the NXP PCF8574
- "nxp,pcf8574a": For the NXP PCF8574A
- "nxp,pcf8575": For the NXP PCF8575
- "ti,tca9554": For the TI TCA9554
- reg: I2C slave address.
- 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.
Optional Properties:
- lines-initial-states: Bitmask that specifies the initial state of each
line. When a bit is set to zero, the corresponding line will be initialized to
the input (pulled-up) state. When the bit is set to one, the line will be
initialized the the low-level output state. If the property is not specified
all lines will be initialized to the input state.
The I/O expander can detect input state changes, and thus optionally act as
an interrupt controller. When the expander interrupt line is connected all the
following properties must be set. For more information please see the
interrupt controller device tree bindings documentation available at
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: Number of cells to encode an interrupt source, shall be 2.
- interrupt-parent: phandle of the parent interrupt controller.
- interrupts: Interrupt specifier for the controllers interrupt.
Please refer to gpio.txt in this directory for details of the common GPIO
bindings used by client devices.
Example: PCF8575 I/O expander node
pcf8575: gpio@20 {
compatible = "nxp,pcf8575";
reg = <0x20>;
interrupt-parent = <&irqpin2>;
interrupts = <3 0>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};

40
Documentation/devicetree/bindings/gpio/gpio.txt
View File

@ -87,8 +87,10 @@ controllers. The gpio-ranges property described below represents this, and
contains information structures as follows:
gpio-range-list ::= <single-gpio-range> [gpio-range-list]
single-gpio-range ::=
single-gpio-range ::= <numeric-gpio-range> | <named-gpio-range>
numeric-gpio-range ::=
<pinctrl-phandle> <gpio-base> <pinctrl-base> <count>
named-gpio-range ::= <pinctrl-phandle> <gpio-base> '<0 0>'
gpio-phandle : phandle to pin controller node.
gpio-base : Base GPIO ID in the GPIO controller
pinctrl-base : Base pinctrl pin ID in the pin controller
@ -97,6 +99,19 @@ contains information structures as follows:
The "pin controller node" mentioned above must conform to the bindings
described in ../pinctrl/pinctrl-bindings.txt.
In case named gpio ranges are used (ranges with both <pinctrl-base> and
<count> set to 0), the property gpio-ranges-group-names contains one string
for every single-gpio-range in gpio-ranges:
gpiorange-names-list ::= <gpiorange-name> [gpiorange-names-list]
gpiorange-name : Name of the pingroup associated to the GPIO range in
the respective pin controller.
Elements of gpiorange-names-list corresponding to numeric ranges contain
the empty string. Elements of gpiorange-names-list corresponding to named
ranges contain the name of a pin group defined in the respective pin
controller. The number of pins/GPIOs in the range is the number of pins in
that pin group.
Previous versions of this binding required all pin controller nodes that
were referenced by any gpio-ranges property to contain a property named
#gpio-range-cells with value <3>. This requirement is now deprecated.
@ -104,7 +119,7 @@ However, that property may still exist in older device trees for
compatibility reasons, and would still be required even in new device
trees that need to be compatible with older software.
Example:
Example 1:
qe_pio_e: gpio-controller@1460 {
#gpio-cells = <2>;
@ -117,3 +132,24 @@ Example:
Here, a single GPIO controller has GPIOs 0..9 routed to pin controller
pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's
pins 50..59.
Example 2:
gpio_pio_i: gpio-controller@14B0 {
#gpio-cells = <2>;
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
reg = <0x1480 0x18>;
gpio-controller;
gpio-ranges = <&pinctrl1 0 20 10>,
<&pinctrl2 10 0 0>,
<&pinctrl1 15 0 10>,
<&pinctrl2 25 0 0>;
gpio-ranges-group-names = "",
"foo",
"",
"bar";
};
Here, three GPIO ranges are defined wrt. two pin controllers. pinctrl1 GPIO
ranges are defined using pin numbers whereas the GPIO ranges wrt. pinctrl2
are named "foo" and "bar".

29
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
View File

@ -4,16 +4,33 @@ Specifying interrupt information for devices
1) Interrupt client nodes
-------------------------
Nodes that describe devices which generate interrupts must contain an
"interrupts" property. This property must contain a list of interrupt
specifiers, one per output interrupt. The format of the interrupt specifier is
determined by the interrupt controller to which the interrupts are routed; see
section 2 below for details.
Nodes that describe devices which generate interrupts must contain an either an
"interrupts" property or an "interrupts-extended" property. These properties
contain a list of interrupt specifiers, one per output interrupt. The format of
the interrupt specifier is determined by the interrupt controller to which the
interrupts are routed; see section 2 below for details.
Example:
interrupt-parent = <&intc1>;
interrupts = <5 0>, <6 0>;
The "interrupt-parent" property is used to specify the controller to which
interrupts are routed and contains a single phandle referring to the interrupt
controller node. This property is inherited, so it may be specified in an
interrupt client node or in any of its parent nodes.
interrupt client node or in any of its parent nodes. Interrupts listed in the
"interrupts" property are always in reference to the node's interrupt parent.
The "interrupts-extended" property is a special form for use when a node needs
to reference multiple interrupt parents. Each entry in this property contains
both the parent phandle and the interrupt specifier. "interrupts-extended"
should only be used when a device has multiple interrupt parents.
Example:
interrupts-extended = <&intc1 5 1>, <&intc2 1 0>;
A device node may contain either "interrupts" or "interrupts-extended", but not
both. If both properties are present, then the operating system should log an
error and use only the data in "interrupts".
2) Interrupt controller nodes
-----------------------------

11
Documentation/devicetree/bindings/leds/leds-lp55xx.txt
View File

@ -10,6 +10,7 @@ Each child has own specific current settings
- max-cur: Maximun current at each led channel.
Optional properties:
- enable-gpio: GPIO attached to the chip's enable pin
- label: Used for naming LEDs
- pwr-sel: LP8501 specific property. Power selection for output channels.
0: D1~9 are connected to VDD
@ -17,12 +18,15 @@ Optional properties:
2: D1~6 with VOUT, D7~9 with VDD
3: D1~9 are connected to VOUT
Alternatively, each child can have specific channel name
- chan-name: Name of each channel name
Alternatively, each child can have a specific channel name and trigger:
- chan-name (optional): name of channel
- linux,default-trigger (optional): see
Documentation/devicetree/bindings/leds/common.txt
example 1) LP5521
3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0',
'lp5521_pri:channel1' and 'lp5521_pri:channel2'
'lp5521_pri:channel1' and 'lp5521_pri:channel2', with a heartbeat trigger
on channel 0.
lp5521@32 {
compatible = "national,lp5521";
@ -33,6 +37,7 @@ lp5521@32 {
chan0 {
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
linux,default-trigger = "heartbeat";
};
chan1 {

16
Documentation/devicetree/bindings/mtd/gpmc-nand.txt
View File

@ -22,10 +22,10 @@ Optional properties:
width of 8 is assumed.
- ti,nand-ecc-opt: A string setting the ECC layout to use. One of:
"sw" Software method (default)
"hw" Hardware method
"hw-romcode" gpmc hamming mode method & romcode layout
"sw" <deprecated> use "ham1" instead
"hw" <deprecated> use "ham1" instead
"hw-romcode" <deprecated> use "ham1" instead
"ham1" 1-bit Hamming ecc code
"bch4" 4-bit BCH ecc code
"bch8" 8-bit BCH ecc code
@ -36,8 +36,12 @@ Optional properties:
"prefetch-dma" Prefetch enabled sDMA mode
"prefetch-irq" Prefetch enabled irq mode
- elm_id: Specifies elm device node. This is required to support BCH
error correction using ELM module.
- elm_id: <deprecated> use "ti,elm-id" instead
- ti,elm-id: Specifies phandle of the ELM devicetree node.
ELM is an on-chip hardware engine on TI SoC which is used for
locating ECC errors for BCHx algorithms. SoC devices which have
ELM hardware engines should specify this device node in .dtsi
Using ELM for ECC error correction frees some CPU cycles.
For inline partiton table parsing (optional):

28
Documentation/devicetree/bindings/net/cpsw-phy-sel.txt Normal file
View File

@ -0,0 +1,28 @@
TI CPSW Phy mode Selection Device Tree Bindings
-----------------------------------------------
Required properties:
- compatible : Should be "ti,am3352-cpsw-phy-sel"
- reg : physical base address and size of the cpsw
registers map
- reg-names : names of the register map given in "reg" node
Optional properties:
-rmii-clock-ext : If present, the driver will configure the RMII
interface to external clock usage
Examples:
phy_sel: cpsw-phy-sel@44e10650 {
compatible = "ti,am3352-cpsw-phy-sel";
reg= <0x44e10650 0x4>;
reg-names = "gmii-sel";
};
(or)
phy_sel: cpsw-phy-sel@44e10650 {
compatible = "ti,am3352-cpsw-phy-sel";
reg= <0x44e10650 0x4>;
reg-names = "gmii-sel";
rmii-clock-ext;
};

7
Documentation/devicetree/bindings/pci/designware-pcie.txt
View File

@ -3,7 +3,7 @@
Required properties:
- compatible: should contain "snps,dw-pcie" to identify the
core, plus an identifier for the specific instance, such
as "samsung,exynos5440-pcie".
as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
- reg: base addresses and lengths of the pcie controller,
the phy controller, additional register for the phy controller.
- interrupts: interrupt values for level interrupt,
@ -21,6 +21,11 @@ Required properties:
- num-lanes: number of lanes to use
- reset-gpio: gpio pin number of power good signal
Optional properties for fsl,imx6q-pcie
- power-on-gpio: gpio pin number of power-enable signal
- wake-up-gpio: gpio pin number of incoming wakeup signal
- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
Example:
SoC specific DT Entry:

80
Documentation/devicetree/bindings/pinctrl/abilis,tb10x-iomux.txt Normal file
View File

@ -0,0 +1,80 @@
Abilis Systems TB10x pin controller
===================================
Required properties
-------------------
- compatible: should be "abilis,tb10x-iomux";
- reg: should contain the physical address and size of the pin controller's
register range.
Function definitions
--------------------
Functions are defined (and referenced) by sub-nodes of the pin controller.
Every sub-node defines exactly one function (implying a set of pins).
Every function is associated to one named pin group inside the pin controller
driver and these names are used to associate pin group predefinitions to pin
controller sub-nodes.
Required function definition subnode properties:
- abilis,function: should be set to the name of the function's pin group.
The following pin groups are available:
- GPIO ports: gpioa, gpiob, gpioc, gpiod, gpioe, gpiof, gpiog,
gpioh, gpioi, gpioj, gpiok, gpiol, gpiom, gpion
- Serial TS input ports: mis0, mis1, mis2, mis3, mis4, mis5, mis6, mis7
- Parallel TS input ports: mip1, mip3, mip5, mip7
- Serial TS output ports: mos0, mos1, mos2, mos3
- Parallel TS output port: mop
- CI+ port: ciplus
- CableCard (Mcard) port: mcard
- Smart card ports: stc0, stc1
- UART ports: uart0, uart1
- SPI ports: spi1, spi3
- JTAG: jtag
All other ports of the chip are not multiplexed and thus not managed by this
driver.
GPIO ranges definition
----------------------
The named pin groups of GPIO ports can be used to define GPIO ranges as
explained in Documentation/devicetree/bindings/gpio/gpio.txt.
Example
-------
iomux: iomux@FF10601c {
compatible = "abilis,tb10x-iomux";
reg = <0xFF10601c 0x4>;
pctl_gpio_a: pctl-gpio-a {
abilis,function = "gpioa";
};
pctl_uart0: pctl-uart0 {
abilis,function = "uart0";
};
};
uart@FF100000 {
compatible = "snps,dw-apb-uart";
reg = <0xFF100000 0x100>;
clock-frequency = <166666666>;
interrupts = <25 1>;
reg-shift = <2>;
reg-io-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <&pctl_uart0>;
};
gpioa: gpio@FF140000 {
compatible = "abilis,tb10x-gpio";
reg = <0xFF140000 0x1000>;
gpio-controller;
#gpio-cells = <2>;
ngpio = <3>;
gpio-ranges = <&iomux 0 0>;
gpio-ranges-group-names = "gpioa";
};

2
Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
View File

@ -18,7 +18,7 @@ mode) this pin can work on and the 'config' configures various pad settings
such as pull-up, multi drive, etc.
Required properties for iomux controller:
- compatible: "atmel,at91rm9200-pinctrl"
- compatible: "atmel,at91rm9200-pinctrl" or "atmel,at91sam9x5-pinctrl"
- atmel,mux-mask: array of mask (periph per bank) to describe if a pin can be
configured in this periph mode. All the periph and bank need to be describe.

37
Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
View File

@ -22,11 +22,12 @@ Required properties for iomux controller:
Please refer to each fsl,<soc>-pinctrl.txt binding doc for supported SoCs.
Required properties for pin configuration node:
- 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, which consists of a tuple of
<mux_reg conf_reg input_reg mux_val input_val>. CONFIG is the pad setting
value like pull-up on this pin.
- fsl,pins: each entry consists of 6 integers and represents the mux and config
setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val
input_val> are specified using a PIN_FUNC_ID macro, which can be found in
imx*-pinfunc.h under device tree source folder. The last integer CONFIG is
the pad setting value like pull-up on this pin. And that's why fsl,pins entry
looks like <PIN_FUNC_ID CONFIG> in the example below.
Bits used for CONFIG:
NO_PAD_CTL(1 << 31): indicate this pin does not need config.
@ -72,17 +73,18 @@ iomuxc@020e0000 {
/* shared pinctrl settings */
usdhc4 {
pinctrl_usdhc4_1: usdhc4grp-1 {
fsl,pins = <1386 0x17059 /* MX6Q_PAD_SD4_CMD__USDHC4_CMD */
1392 0x10059 /* MX6Q_PAD_SD4_CLK__USDHC4_CLK */
1462 0x17059 /* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */
1470 0x17059 /* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */
1478 0x17059 /* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */
1486 0x17059 /* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */
1493 0x17059 /* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */
1501 0x17059 /* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */
1509 0x17059 /* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */
1517 0x17059>; /* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */
};
fsl,pins = <
MX6QDL_PAD_SD4_CMD__SD4_CMD 0x17059
MX6QDL_PAD_SD4_CLK__SD4_CLK 0x10059
MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059
MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059
MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059
MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059
MX6QDL_PAD_SD4_DAT4__SD4_DATA4 0x17059
MX6QDL_PAD_SD4_DAT5__SD4_DATA5 0x17059
MX6QDL_PAD_SD4_DAT6__SD4_DATA6 0x17059
MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
>;
};
....
};
@ -90,6 +92,3 @@ Refer to the IOMUXC controller chapter in imx6q datasheet,
0x17059 means enable hysteresis, 47KOhm Pull Up, 50Mhz speed,
80Ohm driver strength and Fast Slew Rate.
User should refer to each SoC spec to set the correct value.
TODO: when dtc macro support is available, we can change above raw data
to dt macro which can get better readability in dts file.

99
Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt Normal file
View File

@ -0,0 +1,99 @@
* Freescale IMX27 IOMUX Controller
Required properties:
- compatible: "fsl,imx27-iomuxc"
The iomuxc driver node should define subnodes containing of pinctrl configuration subnodes.
Required properties for pin configuration node:
- fsl,pins: three integers array, represents a group of pins mux and config
setting. The format is fsl,pins = <PIN MUX_ID CONFIG>.
PIN is an integer between 0 and 0xbf. imx27 has 6 ports with 32 configurable
configurable pins each. PIN is PORT * 32 + PORT_PIN, PORT_PIN is the pin
number on the specific port (between 0 and 31).
MUX_ID is
function + (direction << 2) + (gpio_oconf << 4) + (gpio_iconfa << 8) + (gpio_iconfb << 10)
function value is used to select the pin function.
Possible values:
0 - Primary function
1 - Alternate function
2 - GPIO
Registers: GIUS (GPIO In Use), GPR (General Purpose Register)
direction defines the data direction of the pin.
Possible values:
0 - Input
1 - Output
Register: DDIR
gpio_oconf configures the gpio submodule output signal. This does not
have any effect unless GPIO function is selected. A/B/C_IN are output
signals of function blocks A,B and C. Specific function blocks are
described in the reference manual.
Possible values:
0 - A_IN
1 - B_IN
2 - C_IN
3 - Data Register
Registers: OCR1, OCR2
gpio_iconfa/b configures the gpio submodule input to functionblocks A and
B. GPIO function should be selected if this is configured.
Possible values:
0 - GPIO_IN
1 - Interrupt Status Register
2 - Pulldown
3 - Pullup
Registers ICONFA1, ICONFA2, ICONFB1 and ICONFB2
CONFIG can be 0 or 1, meaning Pullup disable/enable.
Example:
iomuxc: iomuxc@10015000 {
compatible = "fsl,imx27-iomuxc";
reg = <0x10015000 0x600>;
uart {
pinctrl_uart1: uart-1 {
fsl,pins = <
0x8c 0x004 0x0 /* UART1_TXD__UART1_TXD */
0x8d 0x000 0x0 /* UART1_RXD__UART1_RXD */
0x8e 0x004 0x0 /* UART1_CTS__UART1_CTS */
0x8f 0x000 0x0 /* UART1_RTS__UART1_RTS */
>;
};
...
};
};
For convenience there are macros defined in imx27-pinfunc.h which provide PIN
and MUX_ID. They are structured as MX27_PAD_<Pad name>__<Signal name>. The names
are defined in the i.MX27 reference manual.
The above example using macros:
iomuxc: iomuxc@10015000 {
compatible = "fsl,imx27-iomuxc";
reg = <0x10015000 0x600>;
uart {
pinctrl_uart1: uart-1 {
fsl,pins = <
MX27_PAD_UART1_TXD__UART1_TXD 0x0
MX27_PAD_UART1_RXD__UART1_RXD 0x0
MX27_PAD_UART1_CTS__UART1_CTS 0x0
MX27_PAD_UART1_RTS__UART1_RTS 0x0
>;
};
...
};
};

2
Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
View File

@ -41,7 +41,7 @@ pinctrl-bindings.txt:
Required: pins
Options: function, bias-disable, bias-pull-up, bias-pull-down,
bias-pin-default, drive-open-drain.
drive-open-drain.
Note that many of these properties are only valid for certain specific pins.
See the Palmas device datasheet for complete details regarding which pins

46
Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
View File

@ -21,10 +21,13 @@ 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"
- reg: first element is the general register space of the iomux controller
second element is the separate pull register space of the rk3188
Required properties for gpio sub nodes:
- compatible: "rockchip,gpio-bank"
- compatible: "rockchip,gpio-bank", "rockchip,rk3188-gpio-bank0"
- reg: register of the gpio bank (different than the iomux registerset)
second element: separate pull register for rk3188 bank0
- 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.
@ -95,3 +98,44 @@ uart2: serial@20064000 {
pinctrl-names = "default";
pinctrl-0 = <&uart2_xfer>;
};
Example for rk3188:
pinctrl@20008000 {
compatible = "rockchip,rk3188-pinctrl";
reg = <0x20008000 0xa0>,
<0x20008164 0x1a0>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
gpio0: gpio0@0x2000a000 {
compatible = "rockchip,rk3188-gpio-bank0";
reg = <0x2000a000 0x100>,
<0x20004064 0x8>;
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk_gates8 9>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio1: gpio1@0x2003c000 {
compatible = "rockchip,gpio-bank";
reg = <0x2003c000 0x100>;
interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk_gates8 10>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
...
};

91
Documentation/devicetree/bindings/regulator/as3722-regulator.txt Normal file
View File

@ -0,0 +1,91 @@
Regulator of AMS AS3722 PMIC.
Name of the regulator subnode must be "regulators".
Optional properties:
--------------------
The input supply of regulators are the optional properties on the
regulator node. The AS3722 is having 7 DCDC step-down regulators as
sd[0-6], 10 LDOs as ldo[0-7], ldo[9-11]. The input supply of these
regulators are provided through following properties:
vsup-sd2-supply: Input supply for SD2.
vsup-sd3-supply: Input supply for SD3.
vsup-sd4-supply: Input supply for SD4.
vsup-sd5-supply: Input supply for SD5.
vin-ldo0-supply: Input supply for LDO0.
vin-ldo1-6-supply: Input supply for LDO1 and LDO6.
vin-ldo2-5-7-supply: Input supply for LDO2, LDO5 and LDO7.
vin-ldo3-4-supply: Input supply for LDO3 and LDO4.
vin-ldo9-10-supply: Input supply for LDO9 and LDO10.
vin-ldo11-supply: Input supply for LDO11.
Optional nodes:
--------------
- regulators : Must contain a sub-node per regulator from the list below.
Each sub-node should contain the constraints and initialization
information for that regulator. See regulator.txt for a
description of standard properties for these sub-nodes.
Additional custom properties are listed below.
sd[0-6], ldo[0-7], ldo[9-11].
Optional sub-node properties:
----------------------------
ams,ext-control: External control of the rail. The option of
this properties will tell which external input is
controlling this rail. Valid values are 0, 1, 2 ad 3.
0: There is no external control of this rail.
1: Rail is controlled by ENABLE1 input pin.
2: Rail is controlled by ENABLE2 input pin.
3: Rail is controlled by ENABLE3 input pin.
ams,enable-tracking: Enable tracking with SD1, only supported
by LDO3.
Example:
-------
ams3722: ams3722 {
compatible = "ams,as3722";
reg = <0x40>;
...
regulators {
vsup-sd2-supply = <...>;
...
sd0 {
regulator-name = "vdd_cpu";
regulator-min-microvolt = <700000>;
regulator-max-microvolt = <1400000>;
regulator-always-on;
ams,ext-control = <2>;
};
sd1 {
regulator-name = "vdd_core";
regulator-min-microvolt = <700000>;
regulator-max-microvolt = <1400000>;
regulator-always-on;
ams,ext-control = <1>;
};
sd2 {
regulator-name = "vddio_ddr";
regulator-min-microvolt = <1350000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
};
sd4 {
regulator-name = "avdd-hdmi-pex";
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1050000>;
regulator-always-on;
};
sd5 {
regulator-name = "vdd-1v8";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
....
};
};

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

@ -0,0 +1,21 @@
* Dialog Semiconductor DA9210 Voltage Regulator
Required properties:
- compatible: must be "diasemi,da9210"
- reg: the i2c slave address of the regulator. It should be 0x68.
Any standard regulator properties can be used to configure the single da9210
DCDC.
Example:
da9210@68 {
compatible = "diasemi,da9210";
reg = <0x68>;
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <1000000>;
regulator-boot-on;
regulator-always-on;
};

12
Documentation/devicetree/bindings/regulator/palmas-pmic.txt
View File

@ -26,11 +26,17 @@ Optional nodes:
For ti,palmas-pmic - smps12, smps123, smps3 depending on OTP,
smps45, smps457, smps7 depending on variant, smps6, smps[8-9],
smps10_out2, smps10_out1, do[1-9], ldoln, ldousb.
smps10_out2, smps10_out1, ldo[1-9], ldoln, ldousb.
Optional sub-node properties:
ti,warm-reset - maintain voltage during warm reset(boolean)
ti,roof-floor - control voltage selection by pin(boolean)
ti,roof-floor - This takes as optional argument on platform supporting
the rail from desired external control. If there is no argument then
it will be assume that it is controlled by NSLEEP pin.
The valid value for external pins are:
ENABLE1 then 1,
ENABLE2 then 2 or
NSLEEP then 3.
ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
2 - eco, 3 - forced pwm
ti,smps-range - OTP has the wrong range set for the hardware so override
@ -61,7 +67,7 @@ pmic {
regulator-always-on;
regulator-boot-on;
ti,warm-reset;
ti,roof-floor;
ti,roof-floor = <1>; /* ENABLE1 control */
ti,mode-sleep = <0>;
ti,smps-range = <1>;
};

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

@ -14,6 +14,11 @@ Optional properties:
- regulator-ramp-delay: ramp delay for regulator(in uV/uS)
For hardwares which support disabling ramp rate, it should be explicitly
intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
- regulator-enable-ramp-delay: The time taken, in microseconds, for the supply
rail to reach the target voltage, plus/minus whatever tolerance the board
design requires. This property describes the total system ramp time
required due to the combination of internal ramping of the regulator itself,
and board design issues such as trace capacitance and load on the supply.
Deprecated properties:
- regulator-compatible: If a regulator chip contains multiple

22
Documentation/devicetree/bindings/sound/cs42l73.txt Normal file
View File

@ -0,0 +1,22 @@
CS42L73 audio CODEC
Required properties:
- compatible : "cirrus,cs42l73"
- reg : the I2C address of the device for I2C
Optional properties:
- reset_gpio : a GPIO spec for the reset pin.
- chgfreq : Charge Pump Frequency values 0x00-0x0F
Example:
codec: cs42l73@4a {
compatible = "cirrus,cs42l73";
reg = <0x4a>;
reset_gpio = <&gpio 10 0>;
chgfreq = <0x05>;
};

42
Documentation/devicetree/bindings/sound/davinci-evm-audio.txt Normal file
View File

@ -0,0 +1,42 @@
* Texas Instruments SoC audio setups with TLV320AIC3X Codec
Required properties:
- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx
- ti,model : The user-visible name of this sound complex.
- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
- ti,mcasp-controller : The phandle of the McASP controller
- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec
- ti,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 codec's pins, and the jacks on the board:
Board connectors:
* Headphone Jack
* Line Out
* Mic Jack
* Line In
Example:
sound {
compatible = "ti,da830-evm-audio";
ti,model = "DA830 EVM";
ti,audio-codec = <&tlv320aic3x>;
ti,mcasp-controller = <&mcasp1>;
ti,codec-clock-rate = <12000000>;
ti,audio-routing =
"Headphone Jack", "HPLOUT",
"Headphone Jack", "HPROUT",
"Line Out", "LLOUT",
"Line Out", "RLOUT",
"MIC3L", "Mic Bias 2V",
"MIC3R", "Mic Bias 2V",
"Mic Bias 2V", "Mic Jack",
"LINE1L", "Line In",
"LINE2L", "Line In",
"LINE1R", "Line In",
"LINE2R", "Line In";
};

41
Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
View File

@ -4,17 +4,25 @@ Required properties:
- compatible :
"ti,dm646x-mcasp-audio" : for DM646x platforms
"ti,da830-mcasp-audio" : for both DA830 & DA850 platforms
"ti,omap2-mcasp-audio" : for OMAP2 platforms (TI81xx, AM33xx)
- reg : Should contain McASP registers offset and length
- interrupts : Interrupt number for McASP
- op-mode : I2S/DIT ops mode.
- tdm-slots : Slots for TDM operation.
- num-serializer : Serializers used by McASP.
- serial-dir : A list of serializer pin mode. The list number should be equal
to "num-serializer" parameter. Each entry is a number indication
serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX)
"ti,am33xx-mcasp-audio" : for AM33xx platforms (AM33xx, TI81xx)
- reg : Should contain reg specifiers for the entries in the reg-names property.
- reg-names : Should contain:
* "mpu" for the main registers (required). For compatibility with
existing software, it is recommended this is the first entry.
* "dat" for separate data port register access (optional).
- op-mode : I2S/DIT ops mode. 0 for I2S mode. 1 for DIT mode used for S/PDIF,
IEC60958-1, and AES-3 formats.
- tdm-slots : Slots for TDM operation. Indicates number of channels transmitted
or received over one serializer.
- serial-dir : A list of serializer configuration. Each entry is a number
indication for serializer pin direction.
(0 - INACTIVE, 1 - TX, 2 - RX)
- dmas: two element list of DMA controller phandles and DMA request line
ordered pairs.
- dma-names: identifier string for each DMA request line in the dmas property.
These strings correspond 1:1 with the ordered pairs in dmas. The dma
identifiers must be "rx" and "tx".
Optional properties:
@ -23,18 +31,23 @@ Optional properties:
- rx-num-evt : FIFO levels.
- sram-size-playback : size of sram to be allocated during playback
- sram-size-capture : size of sram to be allocated during capture
- interrupts : Interrupt numbers for McASP, currently not used by the driver
- interrupt-names : Known interrupt names are "tx" and "rx"
- pinctrl-0: Should specify pin control group used for this controller.
- pinctrl-names: Should contain only one value - "default", for more details
please refer to pinctrl-bindings.txt
Example:
mcasp0: mcasp0@1d00000 {
compatible = "ti,da830-mcasp-audio";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x100000 0x3000>;
interrupts = <82 83>;
reg-names "mpu";
interrupts = <82>, <83>;
interrupts-names = "tx", "rx";
op-mode = <0>; /* MCASP_IIS_MODE */
tdm-slots = <2>;
num-serializer = <16>;
serial-dir = <
0 0 0 0 /* 0: INACTIVE, 1: TX, 2: RX */
0 0 0 0

26
Documentation/devicetree/bindings/sound/tlv320aic3x.txt
View File

@ -24,10 +24,36 @@ Optional properties:
3 - MICBIAS output is connected to AVDD,
If this node is not mentioned or if the value is incorrect, then MicBias
is powered down.
- AVDD-supply, IOVDD-supply, DRVDD-supply, DVDD-supply : power supplies for the
device as covered in Documentation/devicetree/bindings/regulator/regulator.txt
CODEC output pins:
* LLOUT
* RLOUT
* MONO_LOUT
* HPLOUT
* HPROUT
* HPLCOM
* HPRCOM
CODEC input pins:
* MIC3L
* MIC3R
* LINE1L
* LINE2L
* LINE1R
* LINE2R
The pins can be used in referring sound node's audio-routing property.
Example:
tlv320aic3x: tlv320aic3x@1b {
compatible = "ti,tlv320aic3x";
reg = <0x1b>;
AVDD-supply = <&regulator>;
IOVDD-supply = <&regulator>;
DRVDD-supply = <&regulator>;
DVDD-supply = <&regulator>;
};

27
Documentation/devicetree/bindings/sound/tpa6130a2.txt Normal file
View File

@ -0,0 +1,27 @@
Texas Instruments - tpa6130a2 Codec module
The tpa6130a2 serial control bus communicates through I2C protocols
Required properties:
- compatible - "string" - One of:
"ti,tpa6130a2" - TPA6130A2
"ti,tpa6140a2" - TPA6140A2
- reg - <int> - I2C slave address
- Vdd-supply - <phandle> - power supply regulator
Optional properties:
- power-gpio - gpio pin to power the device
Example:
tpa6130a2: tpa6130a2@60 {
compatible = "ti,tpa6130a2";
reg = <0x60>;
Vdd-supply = <&vmmc2>;
power-gpio = <&gpio4 2 GPIO_ACTIVE_HIGH>;
};

7
Documentation/devicetree/bindings/spi/sh-hspi.txt Normal file
View File

@ -0,0 +1,7 @@
Renesas HSPI.
Required properties:
- compatible : "renesas,hspi"
- reg : Offset and length of the register set for the device
- interrupts : interrupt line used by HSPI

9
Documentation/devicetree/bindings/vendor-prefixes.txt
View File

@ -12,12 +12,15 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC)
apm Applied Micro Circuits Corporation (APM)
arm ARM Ltd.
atmel Atmel Corporation
auo AU Optronics Corporation
avago Avago Technologies
bosch Bosch Sensortec GmbH
brcm Broadcom Corporation
capella Capella Microsystems, Inc
cavium Cavium, Inc.
cdns Cadence Design Systems Inc.
chrp Common Hardware Reference Platform
chunghwa Chunghwa Picture Tubes Ltd.
cirrus Cirrus Logic, Inc.
cortina Cortina Systems, Inc.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
@ -46,6 +49,8 @@ nintendo Nintendo
nvidia NVIDIA
nxp NXP Semiconductors
onnn ON Semiconductor Corp.
panasonic Panasonic Corporation
phytec PHYTEC Messtechnik GmbH
picochip Picochip Ltd
powervr PowerVR (deprecated, use img)
qca Qualcomm Atheros, Inc.
@ -65,12 +70,12 @@ snps Synopsys, Inc.
st STMicroelectronics
ste ST-Ericsson
stericsson ST-Ericsson
toumaz Toumaz
ti Texas Instruments
toshiba Toshiba Corporation
toumaz Toumaz
v3 V3 Semiconductor
via VIA Technologies, Inc.
winbond Winbond Electronics corp.
wlf Wolfson Microelectronics
wm Wondermedia Technologies, Inc.
winbond Winbond Electronics corp.
xlnx Xilinx

75
Documentation/devicetree/bindings/video/atmel,lcdc.txt Normal file
View File

@ -0,0 +1,75 @@
Atmel LCDC Framebuffer
-----------------------------------------------------
Required properties:
- compatible :
"atmel,at91sam9261-lcdc" ,
"atmel,at91sam9263-lcdc" ,
"atmel,at91sam9g10-lcdc" ,
"atmel,at91sam9g45-lcdc" ,
"atmel,at91sam9g45es-lcdc" ,
"atmel,at91sam9rl-lcdc" ,
"atmel,at32ap-lcdc"
- reg : Should contain 1 register ranges(address and length)
- interrupts : framebuffer controller interrupt
- display: a phandle pointing to the display node
Required nodes:
- display: a display node is required to initialize the lcd panel
This should be in the board dts.
- default-mode: a videomode within the display with timing parameters
as specified below.
Example:
fb0: fb@0x00500000 {
compatible = "atmel,at91sam9g45-lcdc";
reg = <0x00500000 0x1000>;
interrupts = <23 3 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fb>;
display = <&display0>;
status = "okay";
#address-cells = <1>;
#size-cells = <1>;
};
Atmel LCDC Display
-----------------------------------------------------
Required properties (as per of_videomode_helper):
- atmel,dmacon: dma controler configuration
- atmel,lcdcon2: lcd controler configuration
- atmel,guard-time: lcd guard time (Delay in frame periods)
- bits-per-pixel: lcd panel bit-depth.
Optional properties (as per of_videomode_helper):
- atmel,lcdcon-backlight: enable backlight
- atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG"
- atmel,power-control-gpio: gpio to power on or off the LCD (as many as needed)
Example:
display0: display {
bits-per-pixel = <32>;
atmel,lcdcon-backlight;
atmel,dmacon = <0x1>;
atmel,lcdcon2 = <0x80008002>;
atmel,guard-time = <9>;
atmel,lcd-wiring-mode = <1>;
display-timings {
native-mode = <&timing0>;
timing0: timing0 {
clock-frequency = <9000000>;
hactive = <480>;
vactive = <272>;
hback-porch = <1>;
hfront-porch = <1>;
vback-porch = <40>;
vfront-porch = <1>;
hsync-len = <45>;
vsync-len = <1>;
};
};
};

29
Documentation/devicetree/bindings/video/backlight/lp855x.txt
View File

@ -2,7 +2,7 @@ lp855x bindings
Required properties:
- compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553",
"ti,lp8556", "ti,lp8557"
"ti,lp8555", "ti,lp8556", "ti,lp8557"
- reg: I2C slave address (u8)
- dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device.
@ -15,6 +15,33 @@ Optional properties:
Example:
/* LP8555 */
backlight@2c {
compatible = "ti,lp8555";
reg = <0x2c>;
dev-ctrl = /bits/ 8 <0x00>;
pwm-period = <10000>;
/* 4V OV, 4 output LED0 string enabled */
rom_14h {
rom-addr = /bits/ 8 <0x14>;
rom-val = /bits/ 8 <0xcf>;
};
/* Heavy smoothing, 24ms ramp time step */
rom_15h {
rom-addr = /bits/ 8 <0x15>;
rom-val = /bits/ 8 <0xc7>;
};
/* 4 output LED1 string enabled */
rom_19h {
rom-addr = /bits/ 8 <0x19>;
rom-val = /bits/ 8 <0x0f>;
};
};
/* LP8556 */
backlight@2c {
compatible = "ti,lp8556";

4
Documentation/driver-model/devres.txt
View File

@ -283,6 +283,7 @@ REGULATOR
devm_regulator_get()
devm_regulator_put()
devm_regulator_bulk_get()
devm_regulator_register()
CLOCK
devm_clk_get()
@ -302,3 +303,6 @@ PHY
SLAVE DMA ENGINE
devm_acpi_dma_controller_register()
SPI
devm_spi_register_master()

31
Documentation/filesystems/directory-locking
View File

@ -2,6 +2,10 @@
kinds of locks - per-inode (->i_mutex) and per-filesystem
(->s_vfs_rename_mutex).
When taking the i_mutex on multiple non-directory objects, we
always acquire the locks in order by increasing address. We'll call
that "inode pointer" order in the following.
For our purposes all operations fall in 5 classes:
1) read access. Locking rules: caller locks directory we are accessing.
@ -12,8 +16,9 @@ kinds of locks - per-inode (->i_mutex) and per-filesystem
locks victim and calls the method.
4) rename() that is _not_ cross-directory. Locking rules: caller locks
the parent, finds source and target, if target already exists - locks it
and then calls the method.
the parent and finds source and target. If target already exists, lock
it. If source is a non-directory, lock it. If that means we need to
lock both, lock them in inode pointer order.
5) link creation. Locking rules:
* lock parent
@ -30,7 +35,9 @@ rules:
fail with -ENOTEMPTY
* if new parent is equal to or is a descendent of source
fail with -ELOOP
* if target exists - lock it.
* If target exists, lock it. If source is a non-directory, lock
it. In case that means we need to lock both source and target,
do so in inode pointer order.
* call the method.
@ -56,9 +63,11 @@ objects - A < B iff A is an ancestor of B.
renames will be blocked on filesystem lock and we don't start changing
the order until we had acquired all locks).
(3) any operation holds at most one lock on non-directory object and
that lock is acquired after all other locks. (Proof: see descriptions
of operations).
(3) locks on non-directory objects are acquired only after locks on
directory objects, and are acquired in inode pointer order.
(Proof: all operations but renames take lock on at most one
non-directory object, except renames, which take locks on source and
target in inode pointer order in the case they are not directories.)
Now consider the minimal deadlock. Each process is blocked on
attempt to acquire some lock and already holds at least one lock. Let's
@ -66,9 +75,13 @@ consider the set of contended locks. First of all, filesystem lock is
not contended, since any process blocked on it is not holding any locks.
Thus all processes are blocked on ->i_mutex.
Non-directory objects are not contended due to (3). Thus link
creation can't be a part of deadlock - it can't be blocked on source
and it means that it doesn't hold any locks.
By (3), any process holding a non-directory lock can only be
waiting on another non-directory lock with a larger address. Therefore
the process holding the "largest" such lock can always make progress, and
non-directory objects are not included in the set of contended locks.
Thus link creation can't be a part of deadlock - it can't be
blocked on source and it means that it doesn't hold any locks.
Any contended object is either held by cross-directory rename or
has a child that is also contended. Indeed, suppose that it is held by

7
Documentation/filesystems/f2fs.txt
View File

@ -119,6 +119,7 @@ active_logs=%u Support configuring the number of active logs. In the
Default number is 6.
disable_ext_identify Disable the extension list configured by mkfs, so f2fs
does not aware of cold files such as media files.
inline_xattr Enable the inline xattrs feature.
================================================================================
DEBUGFS ENTRIES
@ -164,6 +165,12 @@ Files in /sys/fs/f2fs/<devname>
gc_idle = 1 will select the Cost Benefit approach
& setting gc_idle = 2 will select the greedy aproach.
reclaim_segments This parameter controls the number of prefree
segments to be reclaimed. If the number of prefree
segments is larger than this number, f2fs tries to
conduct checkpoint to reclaim the prefree segments
to free segments. By default, 100 segments, 200MB.
================================================================================
USAGE
================================================================================

8
Documentation/filesystems/porting
View File

@ -455,3 +455,11 @@ in your dentry operations instead.
vfs_follow_link has been removed. Filesystems must use nd_set_link
from ->follow_link for normal symlinks, or nd_jump_link for magic
/proc/<pid> style links.
--
[mandatory]
iget5_locked()/ilookup5()/ilookup5_nowait() test() callback used to be
called with both ->i_lock and inode_hash_lock held; the former is *not*
taken anymore, so verify that your callbacks do not rely on it (none
of the in-tree instances did). inode_hash_lock is still held,
of course, so they are still serialized wrt removal from inode hash,
as well as wrt set() callback of iget5_locked().

1
Documentation/filesystems/proc.txt
View File

@ -460,6 +460,7 @@ manner. The codes are the following:
nl - non-linear mapping
ar - architecture specific flag
dd - do not include area into core dump
sd - soft-dirty flag
mm - mixed map area
hg - huge page advise flag
nh - no-huge page advise flag

2
Documentation/filesystems/vfat.txt
View File

@ -307,7 +307,7 @@ the following:
<proceeding files...>
<slot #3, id = 0x43, characters = "h is long">
<slot #2, id = 0x02, characters = "xtension which">
<slot #2, id = 0x02, characters = "xtension whic">
<slot #1, id = 0x01, characters = "My Big File.E">
<directory entry, name = "MYBIGFIL.EXT">

4
Documentation/gcov.txt
View File

@ -50,6 +50,10 @@ Configure the kernel with:
CONFIG_DEBUG_FS=y
CONFIG_GCOV_KERNEL=y
select the gcc's gcov format, default is autodetect based on gcc version:
CONFIG_GCOV_FORMAT_AUTODETECT=y
and to get coverage data for the entire kernel:
CONFIG_GCOV_PROFILE_ALL=y

20
Documentation/hwmon/lm25066
View File

@ -8,6 +8,11 @@ Supported chips:
Datasheets:
http://www.ti.com/lit/gpn/lm25056
http://www.ti.com/lit/gpn/lm25056a
* TI LM25063
Prefix: 'lm25063'
Addresses scanned: -
Datasheet:
To be announced
* National Semiconductor LM25066
Prefix: 'lm25066'
Addresses scanned: -
@ -32,7 +37,7 @@ Description
-----------
This driver supports hardware montoring for National Semiconductor / TI LM25056,
LM25066, LM5064, and LM5064 Power Management, Monitoring, Control, and
LM25063, LM25066, LM5064, and LM5066 Power Management, Monitoring, Control, and
Protection ICs.
The driver is a client driver to the core PMBus driver. Please see
@ -64,8 +69,12 @@ in1_input Measured input voltage.
in1_average Average measured input voltage.
in1_min Minimum input voltage.
in1_max Maximum input voltage.
in1_crit Critical high input voltage (LM25063 only).
in1_lcrit Critical low input voltage (LM25063 only).
in1_min_alarm Input voltage low alarm.
in1_max_alarm Input voltage high alarm.
in1_lcrit_alarm Input voltage critical low alarm (LM25063 only).
in1_crit_alarm Input voltage critical high alarm. (LM25063 only).
in2_label "vmon"
in2_input Measured voltage on VAUX pin
@ -80,12 +89,16 @@ in3_input Measured output voltage.
in3_average Average measured output voltage.
in3_min Minimum output voltage.
in3_min_alarm Output voltage low alarm.
in3_highest Historical minimum output voltage (LM25063 only).
in3_lowest Historical maximum output voltage (LM25063 only).
curr1_label "iin"
curr1_input Measured input current.
curr1_average Average measured input current.
curr1_max Maximum input current.
curr1_crit Critical input current (LM25063 only).
curr1_max_alarm Input current high alarm.
curr1_crit_alarm Input current critical high alarm (LM25063 only).
power1_label "pin"
power1_input Measured input power.
@ -95,6 +108,11 @@ power1_alarm Input power alarm
power1_input_highest Historical maximum power.
power1_reset_history Write any value to reset maximum power history.
power2_label "pout". LM25063 only.
power2_input Measured output power.
power2_max Maximum output power limit.
power2_crit Critical output power limit.
temp1_input Measured temperature.
temp1_max Maximum temperature.
temp1_crit Critical high temperature.

44
Documentation/hwmon/ltc2978
View File

@ -6,10 +6,15 @@ Supported chips:
Prefix: 'ltc2974'
Addresses scanned: -
Datasheet: http://www.linear.com/product/ltc2974
* Linear Technology LTC2978
* Linear Technology LTC2977
Prefix: 'ltc2977'
Addresses scanned: -
Datasheet: http://www.linear.com/product/ltc2977
* Linear Technology LTC2978, LTC2978A
Prefix: 'ltc2978'
Addresses scanned: -
Datasheet: http://www.linear.com/product/ltc2978
http://www.linear.com/product/ltc2978a
* Linear Technology LTC3880
Prefix: 'ltc3880'
Addresses scanned: -
@ -26,8 +31,9 @@ Description
-----------
LTC2974 is a quad digital power supply manager. LTC2978 is an octal power supply
monitor. LTC3880 is a dual output poly-phase step-down DC/DC controller. LTC3883
is a single phase step-down DC/DC controller.
monitor. LTC2977 is a pin compatible replacement for LTC2978. LTC3880 is a dual
output poly-phase step-down DC/DC controller. LTC3883 is a single phase
step-down DC/DC controller.
Usage Notes
@ -49,21 +55,25 @@ Sysfs attributes
in1_label "vin"
in1_input Measured input voltage.
in1_min Minimum input voltage.
in1_max Maximum input voltage. LTC2974 and LTC2978 only.
in1_lcrit Critical minimum input voltage. LTC2974 and LTC2978
only.
in1_max Maximum input voltage.
LTC2974, LTC2977, and LTC2978 only.
in1_lcrit Critical minimum input voltage.
LTC2974, LTC2977, and LTC2978 only.
in1_crit Critical maximum input voltage.
in1_min_alarm Input voltage low alarm.
in1_max_alarm Input voltage high alarm. LTC2974 and LTC2978 only.
in1_lcrit_alarm Input voltage critical low alarm. LTC2974 and LTC2978
only.
in1_max_alarm Input voltage high alarm.
LTC2974, LTC2977, and LTC2978 only.
in1_lcrit_alarm Input voltage critical low alarm.
LTC2974, LTC2977, and LTC2978 only.
in1_crit_alarm Input voltage critical high alarm.
in1_lowest Lowest input voltage. LTC2974 and LTC2978 only.
in1_lowest Lowest input voltage.
LTC2974, LTC2977, and LTC2978 only.
in1_highest Highest input voltage.
in1_reset_history Reset input voltage history.
in[N]_label "vout[1-8]".
LTC2974: N=2-5
LTC2977: N=2-9
LTC2978: N=2-9
LTC3880: N=2-3
LTC3883: N=2
@ -83,21 +93,23 @@ in[N]_reset_history Reset output voltage history.
temp[N]_input Measured temperature.
On LTC2974, temp[1-4] report external temperatures,
and temp5 reports the chip temperature.
On LTC2978, only one temperature measurement is
supported and reports the chip temperature.
On LTC2977 and LTC2978, only one temperature measurement
is supported and reports the chip temperature.
On LTC3880, temp1 and temp2 report external
temperatures, and temp3 reports the chip temperature.
On LTC3883, temp1 reports an external temperature,
and temp2 reports the chip temperature.
temp[N]_min Mimimum temperature. LTC2974 and LTC2978 only.
temp[N]_min Mimimum temperature. LTC2974, LCT2977, and LTC2978 only.
temp[N]_max Maximum temperature.
temp[N]_lcrit Critical low temperature.
temp[N]_crit Critical high temperature.
temp[N]_min_alarm Temperature low alarm. LTC2974 and LTC2978 only.
temp[N]_min_alarm Temperature low alarm.
LTC2974, LTC2977, and LTC2978 only.
temp[N]_max_alarm Temperature high alarm.
temp[N]_lcrit_alarm Temperature critical low alarm.
temp[N]_crit_alarm Temperature critical high alarm.
temp[N]_lowest Lowest measured temperature. LTC2974 and LTC2978 only.
temp[N]_lowest Lowest measured temperature.
LTC2974, LTC2977, and LTC2978 only.
Not supported for chip temperature sensor on LTC2974.
temp[N]_highest Highest measured temperature. Not supported for chip
temperature sensor on LTC2974.
@ -109,6 +121,7 @@ power1_input Measured input power.
power[N]_label "pout[1-4]".
LTC2974: N=1-4
LTC2977: Not supported
LTC2978: Not supported
LTC3880: N=1-2
LTC3883: N=2
@ -123,6 +136,7 @@ curr1_reset_history Reset input current history. LTC3883 only.
curr[N]_label "iout[1-4]".
LTC2974: N=1-4
LTC2977: not supported
LTC2978: not supported
LTC3880: N=2-3
LTC3883: N=2

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

@ -138,6 +138,7 @@ Code Seq#(hex) Include File Comments
'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict!
'H' C0-DF net/bluetooth/bnep/bnep.h conflict!
'H' F1 linux/hid-roccat.h <mailto:erazor_de@users.sourceforge.net>
'H' F8-FA sound/firewire.h
'I' all linux/isdn.h conflict!
'I' 00-0F drivers/isdn/divert/isdn_divert.h conflict!
'I' 40-4F linux/mISDNif.h conflict!

6
Documentation/kernel-parameters.txt
View File

@ -1070,6 +1070,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
VIA, nVidia)
verbose: show contents of HPET registers during setup
hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET
registers. Default set by CONFIG_HPET_MMAP_DEFAULT.
hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
On x86-64 and powerpc, this option can be specified
@ -1775,6 +1778,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
that the amount of memory usable for all allocations
is not too small.
movable_node [KNL,X86] Boot-time switch to enable the effects
of CONFIG_MOVABLE_NODE=y. See mm/Kconfig for details.
MTD_Partition= [MTD]
Format: <name>,<region-number>,<size>,<offset>

7
Documentation/laptops/thinkpad-acpi.txt
View File

@ -1,7 +1,7 @@
ThinkPad ACPI Extras Driver
Version 0.24
December 11th, 2009
Version 0.25
October 16th, 2013
Borislav Deianov <borislav@users.sf.net>
Henrique de Moraes Holschuh <hmh@hmh.eng.br>
@ -741,6 +741,9 @@ compiled with the CONFIG_THINKPAD_ACPI_UNSAFE_LEDS option enabled.
Distributions must never enable this option. Individual users that
are aware of the consequences are welcome to enabling it.
Audio mute and microphone mute LEDs are supported, but currently not
visible to userspace. They are used by the snd-hda-intel audio driver.
procfs notes:
The available commands are:

54
Documentation/networking/batman-adv.txt
View File

@ -69,8 +69,7 @@ folder:
# aggregated_ogms gw_bandwidth log_level
# ap_isolation gw_mode orig_interval
# bonding gw_sel_class routing_algo
# bridge_loop_avoidance hop_penalty vis_mode
# fragmentation
# bridge_loop_avoidance hop_penalty fragmentation
There is a special folder for debugging information:
@ -78,7 +77,7 @@ There is a special folder for debugging information:
# ls /sys/kernel/debug/batman_adv/bat0/
# bla_backbone_table log transtable_global
# bla_claim_table originators transtable_local
# gateways socket vis_data
# gateways socket
Some of the files contain all sort of status information regard-
ing the mesh network. For example, you can view the table of
@ -127,51 +126,6 @@ ously assigned to interfaces now used by batman advanced, e.g.
# ifconfig eth0 0.0.0.0
VISUALIZATION
-------------
If you want topology visualization, at least one mesh node must
be configured as VIS-server:
# echo "server" > /sys/class/net/bat0/mesh/vis_mode
Each node is either configured as "server" or as "client" (de-
fault: "client"). Clients send their topology data to the server
next to them, and server synchronize with other servers. If there
is no server configured (default) within the mesh, no topology
information will be transmitted. With these "synchronizing
servers", there can be 1 or more vis servers sharing the same (or
at least very similar) data.
When configured as server, you can get a topology snapshot of
your mesh:
# cat /sys/kernel/debug/batman_adv/bat0/vis_data
This raw output is intended to be easily parsable and convertable
with other tools. Have a look at the batctl README if you want a
vis output in dot or json format for instance and how those out-
puts could then be visualised in an image.
The raw format consists of comma separated values per entry where
each entry is giving information about a certain source inter-
face. Each entry can/has to have the following values:
-> "mac" - mac address of an originator's source interface
(each line begins with it)
-> "TQ mac value" - src mac's link quality towards mac address
of a neighbor originator's interface which
is being used for routing
-> "TT mac" - TT announced by source mac
-> "PRIMARY" - this is a primary interface
-> "SEC mac" - secondary mac address of source
(requires preceding PRIMARY)
The TQ value has a range from 4 to 255 with 255 being the best.
The TT entries are showing which hosts are connected to the mesh
via bat0 or being bridged into the mesh network. The PRIMARY/SEC
values are only applied on primary interfaces
LOGGING/DEBUGGING
-----------------
@ -245,5 +199,5 @@ Mailing-list: b.a.t.m.a.n@open-mesh.org (optional subscription
You can also contact the Authors:
Marek Lindner <lindner_marek@yahoo.de>
Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Marek Lindner <mareklindner@neomailbox.ch>
Simon Wunderlich <sw@simonwunderlich.de>

75
Documentation/networking/bonding.txt
View File

@ -639,6 +639,15 @@ num_unsol_na
are generated by the ipv4 and ipv6 code and the numbers of
repetitions cannot be set independently.
packets_per_slave
Specify the number of packets to transmit through a slave before
moving to the next one. When set to 0 then a slave is chosen at
random.
The valid range is 0 - 65535; the default value is 1. This option
has effect only in balance-rr mode.
primary
A string (eth0, eth2, etc) specifying which slave is the
@ -743,21 +752,16 @@ xmit_hash_policy
protocol information to generate the hash.
Uses XOR of hardware MAC addresses and IP addresses to
generate the hash. The IPv4 formula is
generate the hash. The formula is
(((source IP XOR dest IP) AND 0xffff) XOR
( source MAC XOR destination MAC ))
modulo slave count
hash = source MAC XOR destination MAC
hash = hash XOR source IP XOR destination IP
hash = hash XOR (hash RSHIFT 16)
hash = hash XOR (hash RSHIFT 8)
And then hash is reduced modulo slave count.
The IPv6 formula is
hash = (source ip quad 2 XOR dest IP quad 2) XOR
(source ip quad 3 XOR dest IP quad 3) XOR
(source ip quad 4 XOR dest IP quad 4)
(((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
XOR (source MAC XOR destination MAC))
modulo slave count
If the protocol is IPv6 then the source and destination
addresses are first hashed using ipv6_addr_hash.
This algorithm will place all traffic to a particular
network peer on the same slave. For non-IP traffic,
@ -779,21 +783,16 @@ xmit_hash_policy
slaves, although a single connection will not span
multiple slaves.
The formula for unfragmented IPv4 TCP and UDP packets is
The formula for unfragmented TCP and UDP packets is
((source port XOR dest port) XOR
((source IP XOR dest IP) AND 0xffff)
modulo slave count
hash = source port, destination port (as in the header)
hash = hash XOR source IP XOR destination IP
hash = hash XOR (hash RSHIFT 16)
hash = hash XOR (hash RSHIFT 8)
And then hash is reduced modulo slave count.
The formula for unfragmented IPv6 TCP and UDP packets is
hash = (source port XOR dest port) XOR
((source ip quad 2 XOR dest IP quad 2) XOR
(source ip quad 3 XOR dest IP quad 3) XOR
(source ip quad 4 XOR dest IP quad 4))
((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
modulo slave count
If the protocol is IPv6 then the source and destination
addresses are first hashed using ipv6_addr_hash.
For fragmented TCP or UDP packets and all other IPv4 and
IPv6 protocol traffic, the source and destination port
@ -801,10 +800,6 @@ xmit_hash_policy
formula is the same as for the layer2 transmit hash
policy.
The IPv4 policy is intended to mimic the behavior of
certain switches, notably Cisco switches with PFC2 as
well as some Foundry and IBM products.
This algorithm is not fully 802.3ad compliant. A
single TCP or UDP conversation containing both
fragmented and unfragmented packets will see packets
@ -815,6 +810,26 @@ xmit_hash_policy
conversations. Other implementations of 802.3ad may
or may not tolerate this noncompliance.
encap2+3
This policy uses the same formula as layer2+3 but it
relies on skb_flow_dissect to obtain the header fields
which might result in the use of inner headers if an
encapsulation protocol is used. For example this will
improve the performance for tunnel users because the
packets will be distributed according to the encapsulated
flows.
encap3+4
This policy uses the same formula as layer3+4 but it
relies on skb_flow_dissect to obtain the header fields
which might result in the use of inner headers if an
encapsulation protocol is used. For example this will
improve the performance for tunnel users because the
packets will be distributed according to the encapsulated
flows.
The default value is layer2. This option was added in bonding
version 2.6.3. In earlier versions of bonding, this parameter
does not exist, and the layer2 policy is the only policy. The

217
Documentation/networking/can.txt
View File

@ -25,6 +25,12 @@ This file contains
4.1.5 RAW socket option CAN_RAW_FD_FRAMES
4.1.6 RAW socket returned message flags
4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
4.2.1 Broadcast Manager operations
4.2.2 Broadcast Manager message flags
4.2.3 Broadcast Manager transmission timers
4.2.4 Broadcast Manager message sequence transmission
4.2.5 Broadcast Manager receive filter timers
4.2.6 Broadcast Manager multiplex message receive filter
4.3 connected transport protocols (SOCK_SEQPACKET)
4.4 unconnected transport protocols (SOCK_DGRAM)
@ -593,6 +599,217 @@ solution for a couple of reasons:
In order to receive such messages, CAN_RAW_RECV_OWN_MSGS must be set.
4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
The Broadcast Manager protocol provides a command based configuration
interface to filter and send (e.g. cyclic) CAN messages in kernel space.
Receive filters can be used to down sample frequent messages; detect events
such as message contents changes, packet length changes, and do time-out
monitoring of received messages.
Periodic transmission tasks of CAN frames or a sequence of CAN frames can be
created and modified at runtime; both the message content and the two
possible transmit intervals can be altered.
A BCM socket is not intended for sending individual CAN frames using the
struct can_frame as known from the CAN_RAW socket. Instead a special BCM
configuration message is defined. The basic BCM configuration message used
to communicate with the broadcast manager and the available operations are
defined in the linux/can/bcm.h include. The BCM message consists of a
message header with a command ('opcode') followed by zero or more CAN frames.
The broadcast manager sends responses to user space in the same form:
struct bcm_msg_head {
__u32 opcode; /* command */
__u32 flags; /* special flags */
__u32 count; /* run 'count' times with ival1 */
struct timeval ival1, ival2; /* count and subsequent interval */
canid_t can_id; /* unique can_id for task */
__u32 nframes; /* number of can_frames following */
struct can_frame frames[0];
};
The aligned payload 'frames' uses the same basic CAN frame structure defined
at the beginning of section 4 and in the include/linux/can.h include. All
messages to the broadcast manager from user space have this structure.
Note a CAN_BCM socket must be connected instead of bound after socket
creation (example without error checking):
int s;
struct sockaddr_can addr;
struct ifreq ifr;
s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM);
strcpy(ifr.ifr_name, "can0");
ioctl(s, SIOCGIFINDEX, &ifr);
addr.can_family = AF_CAN;
addr.can_ifindex = ifr.ifr_ifindex;
connect(s, (struct sockaddr *)&addr, sizeof(addr))
(..)
The broadcast manager socket is able to handle any number of in flight
transmissions or receive filters concurrently. The different RX/TX jobs are
distinguished by the unique can_id in each BCM message. However additional
CAN_BCM sockets are recommended to communicate on multiple CAN interfaces.
When the broadcast manager socket is bound to 'any' CAN interface (=> the
interface index is set to zero) the configured receive filters apply to any
CAN interface unless the sendto() syscall is used to overrule the 'any' CAN
interface index. When using recvfrom() instead of read() to retrieve BCM
socket messages the originating CAN interface is provided in can_ifindex.
4.2.1 Broadcast Manager operations
The opcode defines the operation for the broadcast manager to carry out,
or details the broadcast managers response to several events, including
user requests.
Transmit Operations (user space to broadcast manager):
TX_SETUP: Create (cyclic) transmission task.
TX_DELETE: Remove (cyclic) transmission task, requires only can_id.
TX_READ: Read properties of (cyclic) transmission task for can_id.
TX_SEND: Send one CAN frame.
Transmit Responses (broadcast manager to user space):
TX_STATUS: Reply to TX_READ request (transmission task configuration).
TX_EXPIRED: Notification when counter finishes sending at initial interval
'ival1'. Requires the TX_COUNTEVT flag to be set at TX_SETUP.
Receive Operations (user space to broadcast manager):
RX_SETUP: Create RX content filter subscription.
RX_DELETE: Remove RX content filter subscription, requires only can_id.
RX_READ: Read properties of RX content filter subscription for can_id.
Receive Responses (broadcast manager to user space):
RX_STATUS: Reply to RX_READ request (filter task configuration).
RX_TIMEOUT: Cyclic message is detected to be absent (timer ival1 expired).
RX_CHANGED: BCM message with updated CAN frame (detected content change).
Sent on first message received or on receipt of revised CAN messages.
4.2.2 Broadcast Manager message flags
When sending a message to the broadcast manager the 'flags' element may
contain the following flag definitions which influence the behaviour:
SETTIMER: Set the values of ival1, ival2 and count
STARTTIMER: Start the timer with the actual values of ival1, ival2
and count. Starting the timer leads simultaneously to emit a CAN frame.
TX_COUNTEVT: Create the message TX_EXPIRED when count expires
TX_ANNOUNCE: A change of data by the process is emitted immediately.
TX_CP_CAN_ID: Copies the can_id from the message header to each
subsequent frame in frames. This is intended as usage simplification. For
TX tasks the unique can_id from the message header may differ from the
can_id(s) stored for transmission in the subsequent struct can_frame(s).
RX_FILTER_ID: Filter by can_id alone, no frames required (nframes=0).
RX_CHECK_DLC: A change of the DLC leads to an RX_CHANGED.
RX_NO_AUTOTIMER: Prevent automatically starting the timeout monitor.
RX_ANNOUNCE_RESUME: If passed at RX_SETUP and a receive timeout occured, a
RX_CHANGED message will be generated when the (cyclic) receive restarts.
TX_RESET_MULTI_IDX: Reset the index for the multiple frame transmission.
RX_RTR_FRAME: Send reply for RTR-request (placed in op->frames[0]).
4.2.3 Broadcast Manager transmission timers
Periodic transmission configurations may use up to two interval timers.
In this case the BCM sends a number of messages ('count') at an interval
'ival1', then continuing to send at another given interval 'ival2'. When
only one timer is needed 'count' is set to zero and only 'ival2' is used.
When SET_TIMER and START_TIMER flag were set the timers are activated.
The timer values can be altered at runtime when only SET_TIMER is set.
4.2.4 Broadcast Manager message sequence transmission
Up to 256 CAN frames can be transmitted in a sequence in the case of a cyclic
TX task configuration. The number of CAN frames is provided in the 'nframes'
element of the BCM message head. The defined number of CAN frames are added
as array to the TX_SETUP BCM configuration message.
/* create a struct to set up a sequence of four CAN frames */
struct {
struct bcm_msg_head msg_head;
struct can_frame frame[4];
} mytxmsg;
(..)
mytxmsg.nframes = 4;
(..)
write(s, &mytxmsg, sizeof(mytxmsg));
With every transmission the index in the array of CAN frames is increased
and set to zero at index overflow.
4.2.5 Broadcast Manager receive filter timers
The timer values ival1 or ival2 may be set to non-zero values at RX_SETUP.
When the SET_TIMER flag is set the timers are enabled:
ival1: Send RX_TIMEOUT when a received message is not received again within
the given time. When START_TIMER is set at RX_SETUP the timeout detection
is activated directly - even without a former CAN frame reception.
ival2: Throttle the received message rate down to the value of ival2. This
is useful to reduce messages for the application when the signal inside the
CAN frame is stateless as state changes within the ival2 periode may get
lost.
4.2.6 Broadcast Manager multiplex message receive filter
To filter for content changes in multiplex message sequences an array of more
than one CAN frames can be passed in a RX_SETUP configuration message. The
data bytes of the first CAN frame contain the mask of relevant bits that
have to match in the subsequent CAN frames with the received CAN frame.
If one of the subsequent CAN frames is matching the bits in that frame data
mark the relevant content to be compared with the previous received content.
Up to 257 CAN frames (multiplex filter bit mask CAN frame plus 256 CAN
filters) can be added as array to the TX_SETUP BCM configuration message.
/* usually used to clear CAN frame data[] - beware of endian problems! */
#define U64_DATA(p) (*(unsigned long long*)(p)->data)
struct {
struct bcm_msg_head msg_head;
struct can_frame frame[5];
} msg;
msg.msg_head.opcode = RX_SETUP;
msg.msg_head.can_id = 0x42;
msg.msg_head.flags = 0;
msg.msg_head.nframes = 5;
U64_DATA(&msg.frame[0]) = 0xFF00000000000000ULL; /* MUX mask */
U64_DATA(&msg.frame[1]) = 0x01000000000000FFULL; /* data mask (MUX 0x01) */
U64_DATA(&msg.frame[2]) = 0x0200FFFF000000FFULL; /* data mask (MUX 0x02) */
U64_DATA(&msg.frame[3]) = 0x330000FFFFFF0003ULL; /* data mask (MUX 0x33) */
U64_DATA(&msg.frame[4]) = 0x4F07FC0FF0000000ULL; /* data mask (MUX 0x4F) */
write(s, &msg, sizeof(msg));
4.3 connected transport protocols (SOCK_SEQPACKET)
4.4 unconnected transport protocols (SOCK_DGRAM)

15
Documentation/networking/ip-sysctl.txt
View File

@ -267,17 +267,6 @@ tcp_max_orphans - INTEGER
more aggressively. Let me to remind again: each orphan eats
up to ~64K of unswappable memory.
tcp_max_ssthresh - INTEGER
Limited Slow-Start for TCP with large congestion windows (cwnd) defined in
RFC3742. Limited slow-start is a mechanism to limit growth of the cwnd
on the region where cwnd is larger than tcp_max_ssthresh. TCP increases cwnd
by at most tcp_max_ssthresh segments, and by at least tcp_max_ssthresh/2
segments per RTT when the cwnd is above tcp_max_ssthresh.
If TCP connection increased cwnd to thousands (or tens of thousands) segments,
and thousands of packets were being dropped during slow-start, you can set
tcp_max_ssthresh to improve performance for new TCP connection.
Default: 0 (off)
tcp_max_syn_backlog - INTEGER
Maximal number of remembered connection requests, which have not
received an acknowledgment from connecting client.
@ -451,7 +440,7 @@ tcp_fastopen - INTEGER
connect() to perform a TCP handshake automatically.
The values (bitmap) are
1: Enables sending data in the opening SYN on the client.
1: Enables sending data in the opening SYN on the client w/ MSG_FASTOPEN.
2: Enables TCP Fast Open on the server side, i.e., allowing data in
a SYN packet to be accepted and passed to the application before
3-way hand shake finishes.
@ -464,7 +453,7 @@ tcp_fastopen - INTEGER
different ways of setting max_qlen without the TCP_FASTOPEN socket
option.
Default: 0
Default: 1
Note that the client & server side Fast Open flags (1 and 2
respectively) must be also enabled before the rest of flags can take

10
Documentation/networking/netdevices.txt
View File

@ -10,12 +10,12 @@ network devices.
struct net_device allocation rules
==================================
Network device structures need to persist even after module is unloaded and
must be allocated with kmalloc. If device has registered successfully,
it will be freed on last use by free_netdev. This is required to handle the
pathologic case cleanly (example: rmmod mydriver </sys/class/net/myeth/mtu )
must be allocated with alloc_netdev_mqs() and friends.
If device has registered successfully, it will be freed on last use
by free_netdev(). This is required to handle the pathologic case cleanly
(example: rmmod mydriver </sys/class/net/myeth/mtu )
There are routines in net_init.c to handle the common cases of
alloc_etherdev, alloc_netdev. These reserve extra space for driver
alloc_netdev_mqs()/alloc_netdev() reserve extra space for driver
private data which gets freed when the network device is freed. If
separately allocated data is attached to the network device
(netdev_priv(dev)) then it is up to the module exit handler to free that.

7
Documentation/pinctrl.txt
View File

@ -358,7 +358,12 @@ static struct pinctrl_gpio_range gpio_range = {
.gc = &chip;
};
In this case the pin_base property will be ignored.
In this case the pin_base property will be ignored. If the name of a pin
group is known, the pins and npins elements of the above structure can be
initialised using the function pinctrl_get_group_pins(), e.g. for pin
group "foo":
pinctrl_get_group_pins(pctl, "foo", &gpio_range.pins, &gpio_range.npins);
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

108
Documentation/power/opp.txt
View File

@ -42,7 +42,7 @@ We can represent these as three OPPs as the following {Hz, uV} tuples:
OPP library provides a set of helper functions to organize and query the OPP
information. The library is located in drivers/base/power/opp.c and the header
is located in include/linux/opp.h. OPP library can be enabled by enabling
is located in include/linux/pm_opp.h. OPP library can be enabled by enabling
CONFIG_PM_OPP from power management menuconfig menu. OPP library depends on
CONFIG_PM as certain SoCs such as Texas Instrument's OMAP framework allows to
optionally boot at a certain OPP without needing cpufreq.
@ -71,14 +71,14 @@ operations until that OPP could be re-enabled if possible.
OPP library facilitates this concept in it's implementation. The following
operational functions operate only on available opps:
opp_find_freq_{ceil, floor}, opp_get_voltage, opp_get_freq, opp_get_opp_count
and opp_init_cpufreq_table
opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq, dev_pm_opp_get_opp_count
and dev_pm_opp_init_cpufreq_table
opp_find_freq_exact is meant to be used to find the opp pointer which can then
be used for opp_enable/disable functions to make an opp available as required.
dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer which can then
be used for dev_pm_opp_enable/disable functions to make an opp available as required.
WARNING: Users of OPP library should refresh their availability count using
get_opp_count if opp_enable/disable functions are invoked for a device, the
get_opp_count if dev_pm_opp_enable/disable functions are invoked for a device, the
exact mechanism to trigger these or the notification mechanism to other
dependent subsystems such as cpufreq are left to the discretion of the SoC
specific framework which uses the OPP library. Similar care needs to be taken
@ -96,24 +96,24 @@ using RCU read locks. The opp_find_freq_{exact,ceil,floor},
opp_get_{voltage, freq, opp_count} fall into this category.
opp_{add,enable,disable} are updaters which use mutex and implement it's own
RCU locking mechanisms. opp_init_cpufreq_table acts as an updater and uses
RCU locking mechanisms. dev_pm_opp_init_cpufreq_table acts as an updater and uses
mutex to implment RCU updater strategy. These functions should *NOT* be called
under RCU locks and other contexts that prevent blocking functions in RCU or
mutex operations from working.
2. Initial OPP List Registration
================================
The SoC implementation calls opp_add function iteratively to add OPPs per
The SoC implementation calls dev_pm_opp_add function iteratively to add OPPs per
device. It is expected that the SoC framework will register the OPP entries
optimally- typical numbers range to be less than 5. The list generated by
registering the OPPs is maintained by OPP library throughout the device
operation. The SoC framework can subsequently control the availability of the
OPPs dynamically using the opp_enable / disable functions.
OPPs dynamically using the dev_pm_opp_enable / disable functions.
opp_add - Add a new OPP for a specific domain represented by the device pointer.
dev_pm_opp_add - Add a new OPP for a specific domain represented by the device pointer.
The OPP is defined using the frequency and voltage. Once added, the OPP
is assumed to be available and control of it's availability can be done
with the opp_enable/disable functions. OPP library internally stores
with the dev_pm_opp_enable/disable functions. OPP library internally stores
and manages this information in the opp struct. This function may be
used by SoC framework to define a optimal list as per the demands of
SoC usage environment.
@ -124,7 +124,7 @@ opp_add - Add a new OPP for a specific domain represented by the device pointer.
soc_pm_init()
{
/* Do things */
r = opp_add(mpu_dev, 1000000, 900000);
r = dev_pm_opp_add(mpu_dev, 1000000, 900000);
if (!r) {
pr_err("%s: unable to register mpu opp(%d)\n", r);
goto no_cpufreq;
@ -143,44 +143,44 @@ functions return the matching pointer representing the opp if a match is
found, else returns error. These errors are expected to be handled by standard
error checks such as IS_ERR() and appropriate actions taken by the caller.
opp_find_freq_exact - Search for an OPP based on an *exact* frequency and
dev_pm_opp_find_freq_exact - Search for an OPP based on an *exact* frequency and
availability. This function is especially useful to enable an OPP which
is not available by default.
Example: In a case when SoC framework detects a situation where a
higher frequency could be made available, it can use this function to
find the OPP prior to call the opp_enable to actually make it available.
find the OPP prior to call the dev_pm_opp_enable to actually make it available.
rcu_read_lock();
opp = opp_find_freq_exact(dev, 1000000000, false);
opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false);
rcu_read_unlock();
/* dont operate on the pointer.. just do a sanity check.. */
if (IS_ERR(opp)) {
pr_err("frequency not disabled!\n");
/* trigger appropriate actions.. */
} else {
opp_enable(dev,1000000000);
dev_pm_opp_enable(dev,1000000000);
}
NOTE: This is the only search function that operates on OPPs which are
not available.
opp_find_freq_floor - Search for an available OPP which is *at most* the
dev_pm_opp_find_freq_floor - Search for an available OPP which is *at most* the
provided frequency. This function is useful while searching for a lesser
match OR operating on OPP information in the order of decreasing
frequency.
Example: To find the highest opp for a device:
freq = ULONG_MAX;
rcu_read_lock();
opp_find_freq_floor(dev, &freq);
dev_pm_opp_find_freq_floor(dev, &freq);
rcu_read_unlock();
opp_find_freq_ceil - Search for an available OPP which is *at least* the
dev_pm_opp_find_freq_ceil - Search for an available OPP which is *at least* the
provided frequency. This function is useful while searching for a
higher match OR operating on OPP information in the order of increasing
frequency.
Example 1: To find the lowest opp for a device:
freq = 0;
rcu_read_lock();
opp_find_freq_ceil(dev, &freq);
dev_pm_opp_find_freq_ceil(dev, &freq);
rcu_read_unlock();
Example 2: A simplified implementation of a SoC cpufreq_driver->target:
soc_cpufreq_target(..)
@ -188,7 +188,7 @@ opp_find_freq_ceil - Search for an available OPP which is *at least* the
/* Do stuff like policy checks etc. */
/* Find the best frequency match for the req */
rcu_read_lock();
opp = opp_find_freq_ceil(dev, &freq);
opp = dev_pm_opp_find_freq_ceil(dev, &freq);
rcu_read_unlock();
if (!IS_ERR(opp))
soc_switch_to_freq_voltage(freq);
@ -208,34 +208,34 @@ as thermal considerations (e.g. don't use OPPx until the temperature drops).
WARNING: Do not use these functions in interrupt context.
opp_enable - Make a OPP available for operation.
dev_pm_opp_enable - Make a OPP available for operation.
Example: Lets say that 1GHz OPP is to be made available only if the
SoC temperature is lower than a certain threshold. The SoC framework
implementation might choose to do something as follows:
if (cur_temp < temp_low_thresh) {
/* Enable 1GHz if it was disabled */
rcu_read_lock();
opp = opp_find_freq_exact(dev, 1000000000, false);
opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false);
rcu_read_unlock();
/* just error check */
if (!IS_ERR(opp))
ret = opp_enable(dev, 1000000000);
ret = dev_pm_opp_enable(dev, 1000000000);
else
goto try_something_else;
}
opp_disable - Make an OPP to be not available for operation
dev_pm_opp_disable - Make an OPP to be not available for operation
Example: Lets say that 1GHz OPP is to be disabled if the temperature
exceeds a threshold value. The SoC framework implementation might
choose to do something as follows:
if (cur_temp > temp_high_thresh) {
/* Disable 1GHz if it was enabled */
rcu_read_lock();
opp = opp_find_freq_exact(dev, 1000000000, true);
opp = dev_pm_opp_find_freq_exact(dev, 1000000000, true);
rcu_read_unlock();
/* just error check */
if (!IS_ERR(opp))
ret = opp_disable(dev, 1000000000);
ret = dev_pm_opp_disable(dev, 1000000000);
else
goto try_something_else;
}
@ -247,7 +247,7 @@ information from the OPP structure is necessary. Once an OPP pointer is
retrieved using the search functions, the following functions can be used by SoC
framework to retrieve the information represented inside the OPP layer.
opp_get_voltage - Retrieve the voltage represented by the opp pointer.
dev_pm_opp_get_voltage - Retrieve the voltage represented by the opp pointer.
Example: At a cpufreq transition to a different frequency, SoC
framework requires to set the voltage represented by the OPP using
the regulator framework to the Power Management chip providing the
@ -256,15 +256,15 @@ opp_get_voltage - Retrieve the voltage represented by the opp pointer.
{
/* do things */
rcu_read_lock();
opp = opp_find_freq_ceil(dev, &freq);
v = opp_get_voltage(opp);
opp = dev_pm_opp_find_freq_ceil(dev, &freq);
v = dev_pm_opp_get_voltage(opp);
rcu_read_unlock();
if (v)
regulator_set_voltage(.., v);
/* do other things */
}
opp_get_freq - Retrieve the freq represented by the opp pointer.
dev_pm_opp_get_freq - Retrieve the freq represented by the opp pointer.
Example: Lets say the SoC framework uses a couple of helper functions
we could pass opp pointers instead of doing additional parameters to
handle quiet a bit of data parameters.
@ -273,8 +273,8 @@ opp_get_freq - Retrieve the freq represented by the opp pointer.
/* do things.. */
max_freq = ULONG_MAX;
rcu_read_lock();
max_opp = opp_find_freq_floor(dev,&max_freq);
requested_opp = opp_find_freq_ceil(dev,&freq);
max_opp = dev_pm_opp_find_freq_floor(dev,&max_freq);
requested_opp = dev_pm_opp_find_freq_ceil(dev,&freq);
if (!IS_ERR(max_opp) && !IS_ERR(requested_opp))
r = soc_test_validity(max_opp, requested_opp);
rcu_read_unlock();
@ -282,25 +282,25 @@ opp_get_freq - Retrieve the freq represented by the opp pointer.
}
soc_test_validity(..)
{
if(opp_get_voltage(max_opp) < opp_get_voltage(requested_opp))
if(dev_pm_opp_get_voltage(max_opp) < dev_pm_opp_get_voltage(requested_opp))
return -EINVAL;
if(opp_get_freq(max_opp) < opp_get_freq(requested_opp))
if(dev_pm_opp_get_freq(max_opp) < dev_pm_opp_get_freq(requested_opp))
return -EINVAL;
/* do things.. */
}
opp_get_opp_count - Retrieve the number of available opps for a device
dev_pm_opp_get_opp_count - Retrieve the number of available opps for a device
Example: Lets say a co-processor in the SoC needs to know the available
frequencies in a table, the main processor can notify as following:
soc_notify_coproc_available_frequencies()
{
/* Do things */
rcu_read_lock();
num_available = opp_get_opp_count(dev);
num_available = dev_pm_opp_get_opp_count(dev);
speeds = kzalloc(sizeof(u32) * num_available, GFP_KERNEL);
/* populate the table in increasing order */
freq = 0;
while (!IS_ERR(opp = opp_find_freq_ceil(dev, &freq))) {
while (!IS_ERR(opp = dev_pm_opp_find_freq_ceil(dev, &freq))) {
speeds[i] = freq;
freq++;
i++;
@ -313,7 +313,7 @@ opp_get_opp_count - Retrieve the number of available opps for a device
6. Cpufreq Table Generation
===========================
opp_init_cpufreq_table - cpufreq framework typically is initialized with
dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with
cpufreq_frequency_table_cpuinfo which is provided with the list of
frequencies that are available for operation. This function provides
a ready to use conversion routine to translate the OPP layer's internal
@ -326,7 +326,7 @@ opp_init_cpufreq_table - cpufreq framework typically is initialized with
soc_pm_init()
{
/* Do things */
r = opp_init_cpufreq_table(dev, &freq_table);
r = dev_pm_opp_init_cpufreq_table(dev, &freq_table);
if (!r)
cpufreq_frequency_table_cpuinfo(policy, freq_table);
/* Do other things */
@ -336,7 +336,7 @@ opp_init_cpufreq_table - cpufreq framework typically is initialized with
addition to CONFIG_PM as power management feature is required to
dynamically scale voltage and frequency in a system.
opp_free_cpufreq_table - Free up the table allocated by opp_init_cpufreq_table
dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table
7. Data Structures
==================
@ -358,16 +358,16 @@ accessed by various functions as described above. However, the structures
representing the actual OPPs and domains are internal to the OPP library itself
to allow for suitable abstraction reusable across systems.
struct opp - The internal data structure of OPP library which is used to
struct dev_pm_opp - The internal data structure of OPP library which is used to
represent an OPP. In addition to the freq, voltage, availability
information, it also contains internal book keeping information required
for the OPP library to operate on. Pointer to this structure is
provided back to the users such as SoC framework to be used as a
identifier for OPP in the interactions with OPP layer.
WARNING: The struct opp pointer should not be parsed or modified by the
users. The defaults of for an instance is populated by opp_add, but the
availability of the OPP can be modified by opp_enable/disable functions.
WARNING: The struct dev_pm_opp pointer should not be parsed or modified by the
users. The defaults of for an instance is populated by dev_pm_opp_add, but the
availability of the OPP can be modified by dev_pm_opp_enable/disable functions.
struct device - This is used to identify a domain to the OPP layer. The
nature of the device and it's implementation is left to the user of
@ -377,19 +377,19 @@ Overall, in a simplistic view, the data structure operations is represented as
following:
Initialization / modification:
+-----+ /- opp_enable
opp_add --> | opp | <-------
| +-----+ \- opp_disable
+-----+ /- dev_pm_opp_enable
dev_pm_opp_add --> | opp | <-------
| +-----+ \- dev_pm_opp_disable
\-------> domain_info(device)
Search functions:
/-- opp_find_freq_ceil ---\ +-----+
domain_info<---- opp_find_freq_exact -----> | opp |
\-- opp_find_freq_floor ---/ +-----+
/-- dev_pm_opp_find_freq_ceil ---\ +-----+
domain_info<---- dev_pm_opp_find_freq_exact -----> | opp |
\-- dev_pm_opp_find_freq_floor ---/ +-----+
Retrieval functions:
+-----+ /- opp_get_voltage
+-----+ /- dev_pm_opp_get_voltage
| opp | <---
+-----+ \- opp_get_freq
+-----+ \- dev_pm_opp_get_freq
domain_info <- opp_get_opp_count
domain_info <- dev_pm_opp_get_opp_count

236
Documentation/power/powercap/powercap.txt Normal file
View File

@ -0,0 +1,236 @@
Power Capping Framework
==================================
The power capping framework provides a consistent interface between the kernel
and the user space that allows power capping drivers to expose the settings to
user space in a uniform way.
Terminology
=========================
The framework exposes power capping devices to user space via sysfs in the
form of a tree of objects. The objects at the root level of the tree represent
'control types', which correspond to different methods of power capping. For
example, the intel-rapl control type represents the Intel "Running Average
Power Limit" (RAPL) technology, whereas the 'idle-injection' control type
corresponds to the use of idle injection for controlling power.
Power zones represent different parts of the system, which can be controlled and
monitored using the power capping method determined by the control type the
given zone belongs to. They each contain attributes for monitoring power, as
well as controls represented in the form of power constraints. If the parts of
the system represented by different power zones are hierarchical (that is, one
bigger part consists of multiple smaller parts that each have their own power
controls), those power zones may also be organized in a hierarchy with one
parent power zone containing multiple subzones and so on to reflect the power
control topology of the system. In that case, it is possible to apply power
capping to a set of devices together using the parent power zone and if more
fine grained control is required, it can be applied through the subzones.
Example sysfs interface tree:
/sys/devices/virtual/powercap
??? intel-rapl
??? intel-rapl:0
?   ??? constraint_0_name
?   ??? constraint_0_power_limit_uw
?   ??? constraint_0_time_window_us
?   ??? constraint_1_name
?   ??? constraint_1_power_limit_uw
?   ??? constraint_1_time_window_us
?   ??? device -> ../../intel-rapl
?   ??? energy_uj
?   ??? intel-rapl:0:0
?   ?   ??? constraint_0_name
?   ?   ??? constraint_0_power_limit_uw
?   ?   ??? constraint_0_time_window_us
?   ?   ??? constraint_1_name
?   ?   ??? constraint_1_power_limit_uw
?   ?   ??? constraint_1_time_window_us
?   ?   ??? device -> ../../intel-rapl:0
?   ?   ??? energy_uj
?   ?   ??? max_energy_range_uj
?   ?   ??? name
?   ?   ??? enabled
?   ?   ??? power
?   ?   ?   ??? async
?   ?   ?   []
?   ?   ??? subsystem -> ../../../../../../class/power_cap
?   ?   ??? uevent
?   ??? intel-rapl:0:1
?   ?   ??? constraint_0_name
?   ?   ??? constraint_0_power_limit_uw
?   ?   ??? constraint_0_time_window_us
?   ?   ??? constraint_1_name
?   ?   ??? constraint_1_power_limit_uw
?   ?   ??? constraint_1_time_window_us
?   ?   ??? device -> ../../intel-rapl:0
?   ?   ??? energy_uj
?   ?   ??? max_energy_range_uj
?   ?   ??? name
?   ?   ??? enabled
?   ?   ??? power
?   ?   ?   ??? async
?   ?   ?   []
?   ?   ??? subsystem -> ../../../../../../class/power_cap
?   ?   ??? uevent
?   ??? max_energy_range_uj
?   ??? max_power_range_uw
?   ??? name
?   ??? enabled
?   ??? power
?   ?   ??? async
?   ?   []
?   ??? subsystem -> ../../../../../class/power_cap
?   ??? enabled
?   ??? uevent
??? intel-rapl:1
?   ??? constraint_0_name
?   ??? constraint_0_power_limit_uw
?   ??? constraint_0_time_window_us
?   ??? constraint_1_name
?   ??? constraint_1_power_limit_uw
?   ??? constraint_1_time_window_us
?   ??? device -> ../../intel-rapl
?   ??? energy_uj
?   ??? intel-rapl:1:0
?   ?   ??? constraint_0_name
?   ?   ??? constraint_0_power_limit_uw
?   ?   ??? constraint_0_time_window_us
?   ?   ??? constraint_1_name
?   ?   ??? constraint_1_power_limit_uw
?   ?   ??? constraint_1_time_window_us
?   ?   ??? device -> ../../intel-rapl:1
?   ?   ??? energy_uj
?   ?   ??? max_energy_range_uj
?   ?   ??? name
?   ?   ??? enabled
?   ?   ??? power
?   ?   ?   ??? async
?   ?   ?   []
?   ?   ??? subsystem -> ../../../../../../class/power_cap
?   ?   ??? uevent
?   ??? intel-rapl:1:1
?   ?   ??? constraint_0_name
?   ?   ??? constraint_0_power_limit_uw
?   ?   ??? constraint_0_time_window_us
?   ?   ??? constraint_1_name
?   ?   ??? constraint_1_power_limit_uw
?   ?   ??? constraint_1_time_window_us
?   ?   ??? device -> ../../intel-rapl:1
?   ?   ??? energy_uj
?   ?   ??? max_energy_range_uj
?   ?   ??? name
?   ?   ??? enabled
?   ?   ??? power
?   ?   ?   ??? async
?   ?   ?   []
?   ?   ??? subsystem -> ../../../../../../class/power_cap
?   ?   ??? uevent
?   ??? max_energy_range_uj
?   ??? max_power_range_uw
?   ??? name
?   ??? enabled
?   ??? power
?   ?   ??? async
?   ?   []
?   ??? subsystem -> ../../../../../class/power_cap
?   ??? uevent
??? power
?   ??? async
?   []
??? subsystem -> ../../../../class/power_cap
??? enabled
??? uevent
The above example illustrates a case in which the Intel RAPL technology,
available in Intel® IA-64 and IA-32 Processor Architectures, is used. There is one
control type called intel-rapl which contains two power zones, intel-rapl:0 and
intel-rapl:1, representing CPU packages. Each of these power zones contains
two subzones, intel-rapl:j:0 and intel-rapl:j:1 (j = 0, 1), representing the
"core" and the "uncore" parts of the given CPU package, respectively. All of
the zones and subzones contain energy monitoring attributes (energy_uj,
max_energy_range_uj) and constraint attributes (constraint_*) allowing controls
to be applied (the constraints in the 'package' power zones apply to the whole
CPU packages and the subzone constraints only apply to the respective parts of
the given package individually). Since Intel RAPL doesn't provide instantaneous
power value, there is no power_uw attribute.
In addition to that, each power zone contains a name attribute, allowing the
part of the system represented by that zone to be identified.
For example:
cat /sys/class/power_cap/intel-rapl/intel-rapl:0/name
package-0
The Intel RAPL technology allows two constraints, short term and long term,
with two different time windows to be applied to each power zone. Thus for
each zone there are 2 attributes representing the constraint names, 2 power
limits and 2 attributes representing the sizes of the time windows. Such that,
constraint_j_* attributes correspond to the jth constraint (j = 0,1).
For example:
constraint_0_name
constraint_0_power_limit_uw
constraint_0_time_window_us
constraint_1_name
constraint_1_power_limit_uw
constraint_1_time_window_us
Power Zone Attributes
=================================
Monitoring attributes
----------------------
energy_uj (rw): Current energy counter in micro joules. Write "0" to reset.
If the counter can not be reset, then this attribute is read only.
max_energy_range_uj (ro): Range of the above energy counter in micro-joules.
power_uw (ro): Current power in micro watts.
max_power_range_uw (ro): Range of the above power value in micro-watts.
name (ro): Name of this power zone.
It is possible that some domains have both power ranges and energy counter ranges;
however, only one is mandatory.
Constraints
----------------
constraint_X_power_limit_uw (rw): Power limit in micro watts, which should be
applicable for the time window specified by "constraint_X_time_window_us".
constraint_X_time_window_us (rw): Time window in micro seconds.
constraint_X_name (ro): An optional name of the constraint
constraint_X_max_power_uw(ro): Maximum allowed power in micro watts.
constraint_X_min_power_uw(ro): Minimum allowed power in micro watts.
constraint_X_max_time_window_us(ro): Maximum allowed time window in micro seconds.
constraint_X_min_time_window_us(ro): Minimum allowed time window in micro seconds.
Except power_limit_uw and time_window_us other fields are optional.
Common zone and control type attributes
----------------------------------------
enabled (rw): Enable/Disable controls at zone level or for all zones using
a control type.
Power Cap Client Driver Interface
==================================
The API summary:
Call powercap_register_control_type() to register control type object.
Call powercap_register_zone() to register a power zone (under a given
control type), either as a top-level power zone or as a subzone of another
power zone registered earlier.
The number of constraints in a power zone and the corresponding callbacks have
to be defined prior to calling powercap_register_zone() to register that zone.
To Free a power zone call powercap_unregister_zone().
To free a control type object call powercap_unregister_control_type().
Detailed API can be generated using kernel-doc on include/linux/powercap.h.

14
Documentation/power/runtime_pm.txt
View File

@ -145,11 +145,13 @@ The action performed by the idle callback is totally dependent on the subsystem
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. 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.
0, then the PM core will attempt to carry out a runtime suspend of the device,
also respecting devices configured for autosuspend. In essence this means a
call to pm_runtime_autosuspend() (do note that drivers needs to update the
device last busy mark, pm_runtime_mark_last_busy(), to control the delay under
this circumstance). To prevent this (for example, if the callback routine has
started a delayed suspend), the routine must 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
@ -308,7 +310,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
- 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
then run pm_runtime_autosuspend(dev) and return its result
int pm_runtime_suspend(struct device *dev);
- execute the subsystem-level suspend callback for the device; returns 0 on

65
Documentation/ptp/testptp.c
View File

@ -100,6 +100,11 @@ static long ppb_to_scaled_ppm(int ppb)
return (long) (ppb * 65.536);
}
static int64_t pctns(struct ptp_clock_time *t)
{
return t->sec * 1000000000LL + t->nsec;
}
static void usage(char *progname)
{
fprintf(stderr,
@ -112,6 +117,8 @@ static void usage(char *progname)
" -f val adjust the ptp clock frequency by 'val' ppb\n"
" -g get the ptp clock time\n"
" -h prints this message\n"
" -k val measure the time offset between system and phc clock\n"
" for 'val' times (Maximum 25)\n"
" -p val enable output with a period of 'val' nanoseconds\n"
" -P val enable or disable (val=1|0) the system clock PPS\n"
" -s set the ptp clock time from the system time\n"
@ -133,8 +140,12 @@ int main(int argc, char *argv[])
struct itimerspec timeout;
struct sigevent sigevent;
struct ptp_clock_time *pct;
struct ptp_sys_offset *sysoff;
char *progname;
int c, cnt, fd;
int i, c, cnt, fd;
char *device = DEVICE;
clockid_t clkid;
@ -144,14 +155,19 @@ int main(int argc, char *argv[])
int extts = 0;
int gettime = 0;
int oneshot = 0;
int pct_offset = 0;
int n_samples = 0;
int periodic = 0;
int perout = -1;
int pps = -1;
int settime = 0;
int64_t t1, t2, tp;
int64_t interval, offset;
progname = strrchr(argv[0], '/');
progname = progname ? 1+progname : argv[0];
while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) {
while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghk:p:P:sSt:v"))) {
switch (c) {
case 'a':
oneshot = atoi(optarg);
@ -174,6 +190,10 @@ int main(int argc, char *argv[])
case 'g':
gettime = 1;
break;
case 'k':
pct_offset = 1;
n_samples = atoi(optarg);
break;
case 'p':
perout = atoi(optarg);
break;
@ -376,6 +396,47 @@ int main(int argc, char *argv[])
}
}
if (pct_offset) {
if (n_samples <= 0 || n_samples > 25) {
puts("n_samples should be between 1 and 25");
usage(progname);
return -1;
}
sysoff = calloc(1, sizeof(*sysoff));
if (!sysoff) {
perror("calloc");
return -1;
}
sysoff->n_samples = n_samples;
if (ioctl(fd, PTP_SYS_OFFSET, sysoff))
perror("PTP_SYS_OFFSET");
else
puts("system and phc clock time offset request okay");
pct = &sysoff->ts[0];
for (i = 0; i < sysoff->n_samples; i++) {
t1 = pctns(pct+2*i);
tp = pctns(pct+2*i+1);
t2 = pctns(pct+2*i+2);
interval = t2 - t1;
offset = (t2 + t1) / 2 - tp;
printf("system time: %ld.%ld\n",
(pct+2*i)->sec, (pct+2*i)->nsec);
printf("phc time: %ld.%ld\n",
(pct+2*i+1)->sec, (pct+2*i+1)->nsec);
printf("system time: %ld.%ld\n",
(pct+2*i+2)->sec, (pct+2*i+2)->nsec);
printf("system/phc clock time offset is %ld ns\n"
"system clock time delay is %ld ns\n",
offset, interval);
}
free(sysoff);
}
close(fd);
return 0;
}

5
Documentation/scheduler/sched-arch.txt
View File

@ -65,11 +65,6 @@ Possible arch/ problems
Possible arch problems I found (and either tried to fix or didn't):
h8300 - Is such sleeping racy vs interrupts? (See #4a).
The H8/300 manual I found indicates yes, however disabling IRQs
over the sleep mean only NMIs can wake it up, so can't fix easily
without doing spin waiting.
ia64 - is safe_halt call racy vs interrupts? (does it sleep?) (See #4a)
sh64 - Is sleeping racy vs interrupts? (See #4a)

2
Documentation/sound/alsa/ALSA-Configuration.txt
View File

@ -616,7 +616,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
As default, snd-dummy drivers doesn't allocate the real buffers
but either ignores read/write or mmap a single dummy page to all
buffer pages, in order to save the resouces. If your apps need
buffer pages, in order to save the resources. If your apps need
the read/ written buffer data to be consistent, pass fake_buffer=0
option.

2
Documentation/sound/alsa/Audiophile-Usb.txt
View File

@ -232,7 +232,7 @@ The parameter can be given:
# modprobe snd-usb-audio index=1 device_setup=0x09
* Or while configuring the modules options in your modules configuration file
(tipically a .conf file in /etc/modprobe.d/ directory:
(typically a .conf file in /etc/modprobe.d/ directory:
alias snd-card-1 snd-usb-audio
options snd-usb-audio index=1 device_setup=0x09

2
Documentation/sound/alsa/CMIPCI.txt
View File

@ -87,7 +87,7 @@ with 4 channels,
and use the interleaved 4 channel data.
There are some control switchs affecting to the speaker connections:
There are some control switches affecting to the speaker connections:
"Line-In Mode" - an enum control to change the behavior of line-in
jack. Either "Line-In", "Rear Output" or "Bass Output" can

6
Documentation/sound/alsa/compress_offload.txt
View File

@ -217,12 +217,12 @@ Not supported:
would be enabled with ALSA kcontrols.
- Audio policy/resource management. This API does not provide any
hooks to query the utilization of the audio DSP, nor any premption
hooks to query the utilization of the audio DSP, nor any preemption
mechanisms.
- No notion of underun/overrun. Since the bytes written are compressed
- No notion of underrun/overrun. Since the bytes written are compressed
in nature and data written/read doesn't translate directly to
rendered output in time, this does not deal with underrun/overun and
rendered output in time, this does not deal with underrun/overrun and
maybe dealt in user-library
Credits:

380
Documentation/sound/alsa/soc/DPCM.txt Normal file
View File

@ -0,0 +1,380 @@
Dynamic PCM
===========
1. Description
==============
Dynamic PCM allows an ALSA PCM device to digitally route its PCM audio to
various digital endpoints during the PCM stream runtime. e.g. PCM0 can route
digital audio to I2S DAI0, I2S DAI1 or PDM DAI2. This is useful for on SoC DSP
drivers that expose several ALSA PCMs and can route to multiple DAIs.
The DPCM runtime routing is determined by the ALSA mixer settings in the same
way as the analog signal is routed in an ASoC codec driver. DPCM uses a DAPM
graph representing the DSP internal audio paths and uses the mixer settings to
determine the patch used by each ALSA PCM.
DPCM re-uses all the existing component codec, platform and DAI drivers without
any modifications.
Phone Audio System with SoC based DSP
-------------------------------------
Consider the following phone audio subsystem. This will be used in this
document for all examples :-
| Front End PCMs | SoC DSP | Back End DAIs | Audio devices |
*************
PCM0 <------------> * * <----DAI0-----> Codec Headset
* *
PCM1 <------------> * * <----DAI1-----> Codec Speakers
* DSP *
PCM2 <------------> * * <----DAI2-----> MODEM
* *
PCM3 <------------> * * <----DAI3-----> BT
* *
* * <----DAI4-----> DMIC
* *
* * <----DAI5-----> FM
*************
This diagram shows a simple smart phone audio subsystem. It supports Bluetooth,
FM digital radio, Speakers, Headset Jack, digital microphones and cellular
modem. This sound card exposes 4 DSP front end (FE) ALSA PCM devices and
supports 6 back end (BE) DAIs. Each FE PCM can digitally route audio data to any
of the BE DAIs. The FE PCM devices can also route audio to more than 1 BE DAI.
Example - DPCM Switching playback from DAI0 to DAI1
---------------------------------------------------
Audio is being played to the Headset. After a while the user removes the headset
and audio continues playing on the speakers.
Playback on PCM0 to Headset would look like :-
*************
PCM0 <============> * * <====DAI0=====> Codec Headset
* *
PCM1 <------------> * * <----DAI1-----> Codec Speakers
* DSP *
PCM2 <------------> * * <----DAI2-----> MODEM
* *
PCM3 <------------> * * <----DAI3-----> BT
* *
* * <----DAI4-----> DMIC
* *
* * <----DAI5-----> FM
*************
The headset is removed from the jack by user so the speakers must now be used :-
*************
PCM0 <============> * * <----DAI0-----> Codec Headset
* *
PCM1 <------------> * * <====DAI1=====> Codec Speakers
* DSP *
PCM2 <------------> * * <----DAI2-----> MODEM
* *
PCM3 <------------> * * <----DAI3-----> BT
* *
* * <----DAI4-----> DMIC
* *
* * <----DAI5-----> FM
*************
The audio driver processes this as follows :-
1) Machine driver receives Jack removal event.
2) Machine driver OR audio HAL disables the Headset path.
3) DPCM runs the PCM trigger(stop), hw_free(), shutdown() operations on DAI0
for headset since the path is now disabled.
4) Machine driver or audio HAL enables the speaker path.
5) DPCM runs the PCM ops for startup(), hw_params(), prepapre() and
trigger(start) for DAI1 Speakers since the path is enabled.
In this example, the machine driver or userspace audio HAL can alter the routing
and then DPCM will take care of managing the DAI PCM operations to either bring
the link up or down. Audio playback does not stop during this transition.
DPCM machine driver
===================
The DPCM enabled ASoC machine driver is similar to normal machine drivers
except that we also have to :-
1) Define the FE and BE DAI links.
2) Define any FE/BE PCM operations.
3) Define widget graph connections.
1 FE and BE DAI links
---------------------
| Front End PCMs | SoC DSP | Back End DAIs | Audio devices |
*************
PCM0 <------------> * * <----DAI0-----> Codec Headset
* *
PCM1 <------------> * * <----DAI1-----> Codec Speakers
* DSP *
PCM2 <------------> * * <----DAI2-----> MODEM
* *
PCM3 <------------> * * <----DAI3-----> BT
* *
* * <----DAI4-----> DMIC
* *
* * <----DAI5-----> FM
*************
For the example above we have to define 4 FE DAI links and 6 BE DAI links. The
FE DAI links are defined as follows :-
static struct snd_soc_dai_link machine_dais[] = {
{
.name = "PCM0 System",
.stream_name = "System Playback",
.cpu_dai_name = "System Pin",
.platform_name = "dsp-audio",
.codec_name = "snd-soc-dummy",
.codec_dai_name = "snd-soc-dummy-dai",
.dynamic = 1,
.trigger = {SND_SOC_DPCM_TRIGGER_POST, SND_SOC_DPCM_TRIGGER_POST},
.dpcm_playback = 1,
},
.....< other FE and BE DAI links here >
};
This FE DAI link is pretty similar to a regular DAI link except that we also
set the DAI link to a DPCM FE with the "dynamic = 1". The supported FE stream
directions should also be set with the "dpcm_playback" and "dpcm_capture"
flags. There is also an option to specify the ordering of the trigger call for
each FE. This allows the ASoC core to trigger the DSP before or after the other
components (as some DSPs have strong requirements for the ordering DAI/DSP
start and stop sequences).
The FE DAI above sets the codec and code DAIs to dummy devices since the BE is
dynamic and will change depending on runtime config.
The BE DAIs are configured as follows :-
static struct snd_soc_dai_link machine_dais[] = {
.....< FE DAI links here >
{
.name = "Codec Headset",
.cpu_dai_name = "ssp-dai.0",
.platform_name = "snd-soc-dummy",
.no_pcm = 1,
.codec_name = "rt5640.0-001c",
.codec_dai_name = "rt5640-aif1",
.ignore_suspend = 1,
.ignore_pmdown_time = 1,
.be_hw_params_fixup = hswult_ssp0_fixup,
.ops = &haswell_ops,
.dpcm_playback = 1,
.dpcm_capture = 1,
},
.....< other BE DAI links here >
};
This BE DAI link connects DAI0 to the codec (in this case RT5460 AIF1). It sets
the "no_pcm" flag to mark it has a BE and sets flags for supported stream
directions using "dpcm_playback" and "dpcm_capture" above.
The BE has also flags set for ignoring suspend and PM down time. This allows
the BE to work in a hostless mode where the host CPU is not transferring data
like a BT phone call :-
*************
PCM0 <------------> * * <----DAI0-----> Codec Headset
* *
PCM1 <------------> * * <----DAI1-----> Codec Speakers
* DSP *
PCM2 <------------> * * <====DAI2=====> MODEM
* *
PCM3 <------------> * * <====DAI3=====> BT
* *
* * <----DAI4-----> DMIC
* *
* * <----DAI5-----> FM
*************
This allows the host CPU to sleep whilst the DSP, MODEM DAI and the BT DAI are
still in operation.
A BE DAI link can also set the codec to a dummy device if the code is a device
that is managed externally.
Likewise a BE DAI can also set a dummy cpu DAI if the CPU DAI is managed by the
DSP firmware.
2 FE/BE PCM operations
----------------------
The BE above also exports some PCM operations and a "fixup" callback. The fixup
callback is used by the machine driver to (re)configure the DAI based upon the
FE hw params. i.e. the DSP may perform SRC or ASRC from the FE to BE.
e.g. DSP converts all FE hw params to run at fixed rate of 48k, 16bit, stereo for
DAI0. This means all FE hw_params have to be fixed in the machine driver for
DAI0 so that the DAI is running at desired configuration regardless of the FE
configuration.
static int dai0_fixup(struct snd_soc_pcm_runtime *rtd,
struct snd_pcm_hw_params *params)
{
struct snd_interval *rate = hw_param_interval(params,
SNDRV_PCM_HW_PARAM_RATE);
struct snd_interval *channels = hw_param_interval(params,
SNDRV_PCM_HW_PARAM_CHANNELS);
/* The DSP will covert the FE rate to 48k, stereo */
rate->min = rate->max = 48000;
channels->min = channels->max = 2;
/* set DAI0 to 16 bit */
snd_mask_set(&params->masks[SNDRV_PCM_HW_PARAM_FORMAT -
SNDRV_PCM_HW_PARAM_FIRST_MASK],
SNDRV_PCM_FORMAT_S16_LE);
return 0;
}
The other PCM operation are the same as for regular DAI links. Use as necessary.
3 Widget graph connections
--------------------------
The BE DAI links will normally be connected to the graph at initialisation time
by the ASoC DAPM core. However, if the BE codec or BE DAI is a dummy then this
has to be set explicitly in the driver :-
/* BE for codec Headset - DAI0 is dummy and managed by DSP FW */
{"DAI0 CODEC IN", NULL, "AIF1 Capture"},
{"AIF1 Playback", NULL, "DAI0 CODEC OUT"},
Writing a DPCM DSP driver
=========================
The DPCM DSP driver looks much like a standard platform class ASoC driver
combined with elements from a codec class driver. A DSP platform driver must
implement :-
1) Front End PCM DAIs - i.e. struct snd_soc_dai_driver.
2) DAPM graph showing DSP audio routing from FE DAIs to BEs.
3) DAPM widgets from DSP graph.
4) Mixers for gains, routing, etc.
5) DMA configuration.
6) BE AIF widgets.
Items 6 is important for routing the audio outside of the DSP. AIF need to be
defined for each BE and each stream direction. e.g for BE DAI0 above we would
have :-
SND_SOC_DAPM_AIF_IN("DAI0 RX", NULL, 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_OUT("DAI0 TX", NULL, 0, SND_SOC_NOPM, 0, 0),
The BE AIF are used to connect the DSP graph to the graphs for the other
component drivers (e.g. codec graph).
Hostless PCM streams
====================
A hostless PCM stream is a stream that is not routed through the host CPU. An
example of this would be a phone call from handset to modem.
*************
PCM0 <------------> * * <----DAI0-----> Codec Headset
* *
PCM1 <------------> * * <====DAI1=====> Codec Speakers/Mic
* DSP *
PCM2 <------------> * * <====DAI2=====> MODEM
* *
PCM3 <------------> * * <----DAI3-----> BT
* *
* * <----DAI4-----> DMIC
* *
* * <----DAI5-----> FM
*************
In this case the PCM data is routed via the DSP. The host CPU in this use case
is only used for control and can sleep during the runtime of the stream.
The host can control the hostless link either by :-
1) Configuring the link as a CODEC <-> CODEC style link. In this case the link
is enabled or disabled by the state of the DAPM graph. This usually means
there is a mixer control that can be used to connect or disconnect the path
between both DAIs.
2) Hostless FE. This FE has a virtual connection to the BE DAI links on the DAPM
graph. Control is then carried out by the FE as regular PCM operations.
This method gives more control over the DAI links, but requires much more
userspace code to control the link. Its recommended to use CODEC<->CODEC
unless your HW needs more fine grained sequencing of the PCM ops.
CODEC <-> CODEC link
--------------------
This DAI link is enabled when DAPM detects a valid path within the DAPM graph.
The machine driver sets some additional parameters to the DAI link i.e.
static const struct snd_soc_pcm_stream dai_params = {
.formats = SNDRV_PCM_FMTBIT_S32_LE,
.rate_min = 8000,
.rate_max = 8000,
.channels_min = 2,
.channels_max = 2,
};
static struct snd_soc_dai_link dais[] = {
< ... more DAI links above ... >
{
.name = "MODEM",
.stream_name = "MODEM",
.cpu_dai_name = "dai2",
.codec_dai_name = "modem-aif1",
.codec_name = "modem",
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
| SND_SOC_DAIFMT_CBM_CFM,
.params = &dai_params,
}
< ... more DAI links here ... >
These parameters are used to configure the DAI hw_params() when DAPM detects a
valid path and then calls the PCM operations to start the link. DAPM will also
call the appropriate PCM operations to disable the DAI when the path is no
longer valid.
Hostless FE
-----------
The DAI link(s) are enabled by a FE that does not read or write any PCM data.
This means creating a new FE that is connected with a virtual path to both
DAI links. The DAI links will be started when the FE PCM is started and stopped
when the FE PCM is stopped. Note that the FE PCM cannot read or write data in
this configuration.

46
Documentation/sound/alsa/soc/codec.txt
View File

@ -1,22 +1,23 @@
ASoC Codec Driver
=================
ASoC Codec Class Driver
=======================
The codec driver is generic and hardware independent code that configures the
codec to provide audio capture and playback. It should contain no code that is
specific to the target platform or machine. All platform and machine specific
code should be added to the platform and machine drivers respectively.
The codec class driver is generic and hardware independent code that configures
the codec, FM, MODEM, BT or external DSP to provide audio capture and playback.
It should contain no code that is specific to the target platform or machine.
All platform and machine specific code should be added to the platform and
machine drivers respectively.
Each codec driver *must* provide the following features:-
Each codec class driver *must* provide the following features:-
1) Codec DAI and PCM configuration
2) Codec control IO - using I2C, 3 Wire(SPI) or both APIs
2) Codec control IO - using RegMap API
3) Mixers and audio controls
4) Codec audio operations
5) DAPM description.
6) DAPM event handler.
Optionally, codec drivers can also provide:-
5) DAPM description.
6) DAPM event handler.
7) DAC Digital mute control.
Its probably best to use this guide in conjunction with the existing codec
@ -64,26 +65,9 @@ struct snd_soc_dai_driver wm8731_dai = {
2 - Codec control IO
--------------------
The codec can usually be controlled via an I2C or SPI style interface
(AC97 combines control with data in the DAI). The codec drivers provide
functions to read and write the codec registers along with supplying a
register cache:-
/* IO control data and register cache */
void *control_data; /* codec control (i2c/3wire) data */
void *reg_cache;
Codec read/write should do any data formatting and call the hardware
read write below to perform the IO. These functions are called by the
core and ALSA when performing DAPM or changing the mixer:-
unsigned int (*read)(struct snd_soc_codec *, unsigned int);
int (*write)(struct snd_soc_codec *, unsigned int, unsigned int);
Codec hardware IO functions - usually points to either the I2C, SPI or AC97
read/write:-
hw_write_t hw_write;
hw_read_t hw_read;
(AC97 combines control with data in the DAI). The codec driver should use the
Regmap API for all codec IO. Please see include/linux/regmap.h and existing
codec drivers for example regmap usage.
3 - Mixers and audio controls
@ -127,7 +111,7 @@ Defines a stereo enumerated control
4 - Codec Audio Operations
--------------------------
The codec driver also supports the following ALSA operations:-
The codec driver also supports the following ALSA PCM operations:-
/* SoC audio ops */
struct snd_soc_ops {

73
Documentation/sound/alsa/soc/dapm.txt
View File

@ -21,7 +21,7 @@ level power systems.
There are 4 power domains within DAPM
1. Codec domain - VREF, VMID (core codec and audio power)
1. Codec bias domain - VREF, VMID (core codec and audio power)
Usually controlled at codec probe/remove and suspend/resume, although
can be set at stream time if power is not needed for sidetone, etc.
@ -30,7 +30,7 @@ There are 4 power domains within DAPM
machine driver and responds to asynchronous events e.g when HP
are inserted
3. Path domain - audio susbsystem signal paths
3. Path domain - audio subsystem signal paths
Automatically set when mixer and mux settings are changed by the user.
e.g. alsamixer, amixer.
@ -63,14 +63,22 @@ Audio DAPM widgets fall into a number of types:-
o Line - Line Input/Output (and optional Jack)
o Speaker - Speaker
o Supply - Power or clock supply widget used by other widgets.
o Regulator - External regulator that supplies power to audio components.
o Clock - External clock that supplies clock to audio components.
o AIF IN - Audio Interface Input (with TDM slot mask).
o AIF OUT - Audio Interface Output (with TDM slot mask).
o Siggen - Signal Generator.
o DAI IN - Digital Audio Interface Input.
o DAI OUT - Digital Audio Interface Output.
o DAI Link - DAI Link between two DAI structures */
o Pre - Special PRE widget (exec before all others)
o Post - Special POST widget (exec after all others)
(Widgets are defined in include/sound/soc-dapm.h)
Widgets are usually added in the codec driver and the machine driver. There are
convenience macros defined in soc-dapm.h that can be used to quickly build a
list of widgets of the codecs and machines DAPM widgets.
Widgets can be added to the sound card by any of the component driver types.
There are convenience macros defined in soc-dapm.h that can be used to quickly
build a list of widgets of the codecs and machines DAPM widgets.
Most widgets have a name, register, shift and invert. Some widgets have extra
parameters for stream name and kcontrols.
@ -80,11 +88,13 @@ parameters for stream name and kcontrols.
-------------------------
Stream Widgets relate to the stream power domain and only consist of ADCs
(analog to digital converters) and DACs (digital to analog converters).
(analog to digital converters), DACs (digital to analog converters),
AIF IN and AIF OUT.
Stream widgets have the following format:-
SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert),
SND_SOC_DAPM_AIF_IN(name, stream, slot, reg, shift, invert)
NOTE: the stream name must match the corresponding stream name in your codec
snd_soc_codec_dai.
@ -94,6 +104,11 @@ e.g. stream widgets for HiFi playback and capture
SND_SOC_DAPM_DAC("HiFi DAC", "HiFi Playback", REG, 3, 1),
SND_SOC_DAPM_ADC("HiFi ADC", "HiFi Capture", REG, 2, 1),
e.g. stream widgets for AIF
SND_SOC_DAPM_AIF_IN("AIF1RX", "AIF1 Playback", 0, SND_SOC_NOPM, 0, 0),
SND_SOC_DAPM_AIF_OUT("AIF1TX", "AIF1 Capture", 0, SND_SOC_NOPM, 0, 0),
2.2 Path Domain Widgets
-----------------------
@ -121,12 +136,14 @@ If you dont want the mixer elements prefixed with the name of the mixer widget,
you can use SND_SOC_DAPM_MIXER_NAMED_CTL instead. the parameters are the same
as for SND_SOC_DAPM_MIXER.
2.3 Platform/Machine domain Widgets
-----------------------------------
2.3 Machine domain Widgets
--------------------------
Machine widgets are different from codec widgets in that they don't have a
codec register bit associated with them. A machine widget is assigned to each
machine audio component (non codec) that can be independently powered. e.g.
machine audio component (non codec or DSP) that can be independently
powered. e.g.
o Speaker Amp
o Microphone Bias
@ -146,12 +163,12 @@ static int spitz_mic_bias(struct snd_soc_dapm_widget* w, int event)
SND_SOC_DAPM_MIC("Mic Jack", spitz_mic_bias),
2.4 Codec Domain
----------------
2.4 Codec (BIAS) Domain
-----------------------
The codec power domain has no widgets and is handled by the codecs DAPM event
handler. This handler is called when the codec powerstate is changed wrt to any
stream event or by kernel PM events.
The codec bias power domain has no widgets and is handled by the codecs DAPM
event handler. This handler is called when the codec powerstate is changed wrt
to any stream event or by kernel PM events.
2.5 Virtual Widgets
@ -169,15 +186,16 @@ After all the widgets have been defined, they can then be added to the DAPM
subsystem individually with a call to snd_soc_dapm_new_control().
3. Codec Widget Interconnections
================================
3. Codec/DSP Widget Interconnections
====================================
Widgets are connected to each other within the codec and machine by audio paths
(called interconnections). Each interconnection must be defined in order to
create a map of all audio paths between widgets.
Widgets are connected to each other within the codec, platform and machine by
audio paths (called interconnections). Each interconnection must be defined in
order to create a map of all audio paths between widgets.
This is easiest with a diagram of the codec (and schematic of the machine audio
system), as it requires joining widgets together via their audio signal paths.
This is easiest with a diagram of the codec or DSP (and schematic of the machine
audio system), as it requires joining widgets together via their audio signal
paths.
e.g., from the WM8731 output mixer (wm8731.c)
@ -247,16 +265,9 @@ machine and includes the codec. e.g.
o Mic Jack
o Codec Pins
When a codec pin is NC it can be marked as not used with a call to
snd_soc_dapm_set_endpoint(codec, "Widget Name", 0);
The last argument is 0 for inactive and 1 for active. This way the pin and its
input widget will never be powered up and consume power.
This also applies to machine widgets. e.g. if a headphone is connected to a
jack then the jack can be marked active. If the headphone is removed, then
the headphone jack can be marked inactive.
Endpoints are added to the DAPM graph so that their usage can be determined in
order to save power. e.g. NC codecs pins will be switched OFF, unconnected
jacks can also be switched OFF.
5 DAPM Widget Events

6
Documentation/sound/alsa/soc/machine.txt
View File

@ -1,8 +1,10 @@
ASoC Machine Driver
===================
The ASoC machine (or board) driver is the code that glues together the platform
and codec drivers.
The ASoC machine (or board) driver is the code that glues together all the
component drivers (e.g. codecs, platforms and DAIs). It also describes the
relationships between each componnent which include audio paths, GPIOs,
interrupts, clocking, jacks and voltage regulators.
The machine driver can contain codec and platform specific code. It registers
the audio subsystem with the kernel as a platform device and is represented by

19
Documentation/sound/alsa/soc/platform.txt
View File

@ -1,9 +1,9 @@
ASoC Platform Driver
====================
An ASoC platform driver can be divided into audio DMA and SoC DAI configuration
and control. The platform drivers only target the SoC CPU and must have no board
specific code.
An ASoC platform driver class can be divided into audio DMA drivers, SoC DAI
drivers and DSP drivers. The platform drivers only target the SoC CPU and must
have no board specific code.
Audio DMA
=========
@ -64,3 +64,16 @@ Each SoC DAI driver must provide the following features:-
5) Suspend and resume (optional)
Please see codec.txt for a description of items 1 - 4.
SoC DSP Drivers
===============
Each SoC DSP driver usually supplies the following features :-
1) DAPM graph
2) Mixer controls
3) DMA IO to/from DSP buffers (if applicable)
4) Definition of DSP front end (FE) PCM devices.
Please see DPCM.txt for a description of item 4.

25
Documentation/sysctl/kernel.txt
View File

@ -290,13 +290,24 @@ Default value is "/sbin/hotplug".
kptr_restrict:
This toggle indicates whether restrictions are placed on
exposing kernel addresses via /proc and other interfaces. When
kptr_restrict is set to (0), there are no restrictions. When
kptr_restrict is set to (1), the default, kernel pointers
printed using the %pK format specifier will be replaced with 0's
unless the user has CAP_SYSLOG. When kptr_restrict is set to
(2), kernel pointers printed using %pK will be replaced with 0's
regardless of privileges.
exposing kernel addresses via /proc and other interfaces.
When kptr_restrict is set to (0), the default, there are no restrictions.
When kptr_restrict is set to (1), kernel pointers printed using the %pK
format specifier will be replaced with 0's unless the user has CAP_SYSLOG
and effective user and group ids are equal to the real ids. This is
because %pK checks are done at read() time rather than open() time, so
if permissions are elevated between the open() and the read() (e.g via
a setuid binary) then %pK will not leak kernel pointers to unprivileged
users. Note, this is a temporary solution only. The correct long-term
solution is to do the permission checks at open() time. Consider removing
world read permissions from files that use %pK, and using dmesg_restrict
to protect against uses of %pK in dmesg(8) if leaking kernel pointer
values to unprivileged users is a concern.
When kptr_restrict is set to (2), kernel pointers printed using
%pK will be replaced with 0's regardless of privileges.
==============================================================

15
Documentation/sysctl/vm.txt
View File

@ -119,8 +119,11 @@ other appears as 0 when read.
dirty_background_ratio
Contains, as a percentage of total system memory, the number of pages at which
the background kernel flusher threads will start writing out dirty data.
Contains, as a percentage of total available memory that contains free pages
and reclaimable pages, the number of pages at which the background kernel
flusher threads will start writing out dirty data.
The total avaiable memory is not equal to total system memory.
==============================================================
@ -151,9 +154,11 @@ interval will be written out next time a flusher thread wakes up.
dirty_ratio
Contains, as a percentage of total system memory, the number of pages at which
a process which is generating disk writes will itself start writing out dirty
data.
Contains, as a percentage of total available memory that contains free pages
and reclaimable pages, the number of pages at which a process which is
generating disk writes will itself start writing out dirty data.
The total avaiable memory is not equal to total system memory.
==============================================================

5
Documentation/trace/tracepoints.txt
View File

@ -114,3 +114,8 @@ core kernel image or in modules.
If the tracepoint has to be used in kernel modules, an
EXPORT_TRACEPOINT_SYMBOL_GPL() or EXPORT_TRACEPOINT_SYMBOL() can be
used to export the defined tracepoints.
Note: The convenience macro TRACE_EVENT provides an alternative way to
define tracepoints. Check http://lwn.net/Articles/379903,
http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362
for a series of articles with more details.

8
Documentation/vm/zswap.txt
View File

@ -8,7 +8,7 @@ significant performance improvement if reads from the compressed cache are
faster than reads from a swap device.
NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memory
reclaim. This interaction has not be fully explored on the large set of
reclaim. This interaction has not been fully explored on the large set of
potential configurations and workloads that exist. For this reason, zswap
is a work in progress and should be considered experimental.
@ -23,7 +23,7 @@ Some potential benefits:
    drastically reducing life-shortening writes.
Zswap evicts pages from compressed cache on an LRU basis to the backing swap
device when the compressed pool reaches it size limit. This requirement had
device when the compressed pool reaches its size limit. This requirement had
been identified in prior community discussions.
To enabled zswap, the "enabled" attribute must be set to 1 at boot time. e.g.
@ -37,7 +37,7 @@ the backing swap device in the case that the compressed pool is full.
Zswap makes use of zbud for the managing the compressed memory pool. Each
allocation in zbud is not directly accessible by address. Rather, a handle is
return by the allocation routine and that handle must be mapped before being
returned by the allocation routine and that handle must be mapped before being
accessed. The compressed memory pool grows on demand and shrinks as compressed
pages are freed. The pool is not preallocated.
@ -56,7 +56,7 @@ in the swap_map goes to 0) the swap code calls the zswap invalidate function,
via frontswap, to free the compressed entry.
Zswap seeks to be simple in its policies. Sysfs attributes allow for one user
controlled policies:
controlled policy:
* max_pool_percent - The maximum percentage of memory that the compressed
pool can occupy.

61
MAINTAINERS
View File

@ -253,6 +253,20 @@ F: drivers/pci/*acpi*
F: drivers/pci/*/*acpi*
F: drivers/pci/*/*/*acpi*
ACPI COMPONENT ARCHITECTURE (ACPICA)
M: Robert Moore <robert.moore@intel.com>
M: Lv Zheng <lv.zheng@intel.com>
M: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
L: linux-acpi@vger.kernel.org
L: devel@acpica.org
W: https://acpica.org/
W: https://github.com/acpica/acpica/
Q: https://patchwork.kernel.org/project/linux-acpi/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
S: Supported
F: drivers/acpi/acpica/
F: include/acpi/
ACPI FAN DRIVER
M: Zhang Rui <rui.zhang@intel.com>
L: linux-acpi@vger.kernel.org
@ -1661,16 +1675,15 @@ S: Maintained
F: drivers/net/wireless/b43legacy/
BACKLIGHT CLASS/SUBSYSTEM
M: Richard Purdie <rpurdie@rpsys.net>
M: Jingoo Han <jg1.han@samsung.com>
S: Maintained
F: drivers/video/backlight/
F: include/linux/backlight.h
BATMAN ADVANCED
M: Marek Lindner <lindner_marek@yahoo.de>
M: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
M: Antonio Quartulli <ordex@autistici.org>
M: Marek Lindner <mareklindner@neomailbox.ch>
M: Simon Wunderlich <sw@simonwunderlich.de>
M: Antonio Quartulli <antonio@meshcoding.com>
L: b.a.t.m.a.n@lists.open-mesh.org
W: http://www.open-mesh.org/
S: Maintained
@ -1823,7 +1836,7 @@ F: drivers/net/ethernet/broadcom/bnx2.*
F: drivers/net/ethernet/broadcom/bnx2_*
BROADCOM BNX2X 10 GIGABIT ETHERNET DRIVER
M: Eilon Greenstein <eilong@broadcom.com>
M: Ariel Elior <ariele@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/broadcom/bnx2x/
@ -1868,7 +1881,7 @@ S: Supported
F: drivers/net/wireless/brcm80211/
BROADCOM BNX2FC 10 GIGABIT FCOE DRIVER
M: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
M: Eddie Wai <eddie.wai@broadcom.com>
L: linux-scsi@vger.kernel.org
S: Supported
F: drivers/scsi/bnx2fc/
@ -2373,7 +2386,7 @@ F: kernel/cpuset.c
CRAMFS FILESYSTEM
W: http://sourceforge.net/projects/cramfs/
S: Orphan
S: Orphan / Obsolete
F: Documentation/filesystems/cramfs.txt
F: fs/cramfs/
@ -2648,6 +2661,7 @@ M: dm-devel@redhat.com
L: dm-devel@redhat.com
W: http://sources.redhat.com/dm
Q: http://patchwork.kernel.org/project/dm-devel/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
T: quilt http://people.redhat.com/agk/patches/linux/editing/
S: Maintained
F: Documentation/device-mapper/
@ -4440,6 +4454,12 @@ F: Documentation/networking/ixgbevf.txt
F: Documentation/networking/i40e.txt
F: drivers/net/ethernet/intel/
INTEL-MID GPIO DRIVER
M: David Cohen <david.a.cohen@linux.intel.com>
L: linux-gpio@vger.kernel.org
S: Maintained
F: drivers/gpio/gpio-intel-mid.c
INTEL PRO/WIRELESS 2100, 2200BG, 2915ABG NETWORK CONNECTION SUPPORT
M: Stanislav Yakovlev <stas.yakovlev@gmail.com>
L: linux-wireless@vger.kernel.org
@ -5369,7 +5389,7 @@ S: Orphan
F: drivers/net/wireless/libertas/
MARVELL MV643XX ETHERNET DRIVER
M: Lennert Buytenhek <buytenh@wantstofly.org>
M: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
L: netdev@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/marvell/mv643xx_eth.*
@ -6407,6 +6427,7 @@ S: Supported
F: Documentation/PCI/
F: drivers/pci/
F: include/linux/pci*
F: arch/x86/pci/
PCI DRIVER FOR NVIDIA TEGRA
M: Thierry Reding <thierry.reding@gmail.com>
@ -6415,6 +6436,12 @@ S: Supported
F: Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
F: drivers/pci/host/pci-tegra.c
PCI DRIVER FOR SAMSUNG EXYNOS
M: Jingoo Han <jg1.han@samsung.com>
L: linux-pci@vger.kernel.org
S: Maintained
F: drivers/pci/host/pci-exynos.c
PCMCIA SUBSYSTEM
P: Linux PCMCIA Team
L: linux-pcmcia@lists.infradead.org
@ -6885,6 +6912,14 @@ L: linux-hexagon@vger.kernel.org
S: Supported
F: arch/hexagon/
QUALCOMM WCN36XX WIRELESS DRIVER
M: Eugene Krasnikov <k.eugene.e@gmail.com>
L: wcn36xx@lists.infradead.org
W: http://wireless.kernel.org/en/users/Drivers/wcn36xx
T: git git://github.com/KrasnikovEugene/wcn36xx.git
S: Supported
F: drivers/net/wireless/ath/wcn36xx/
QUICKCAM PARALLEL PORT WEBCAMS
M: Hans Verkuil <hverkuil@xs4all.nl>
L: linux-media@vger.kernel.org
@ -7314,7 +7349,7 @@ S: Odd Fixes
F: drivers/media/usb/tlg2300/
SC1200 WDT DRIVER
M: Zwane Mwaikambo <zwane@arm.linux.org.uk>
M: Zwane Mwaikambo <zwanem@gmail.com>
S: Maintained
F: drivers/watchdog/sc1200wdt.c
@ -8707,14 +8742,6 @@ S: Maintained
F: arch/m68k/*/*_no.*
F: arch/m68k/include/asm/*_no.*
UCLINUX FOR RENESAS H8/300 (H8300)
M: Yoshinori Sato <ysato@users.sourceforge.jp>
W: http://uclinux-h8.sourceforge.jp/
S: Supported
F: arch/h8300/
F: drivers/ide/ide-h8300.c
F: drivers/net/ethernet/8390/ne-h8300.c
UDF FILESYSTEM
M: Jan Kara <jack@suse.cz>
S: Maintained

16
Makefile
View File

@ -720,6 +720,22 @@ mod_strip_cmd = true
endif # INSTALL_MOD_STRIP
export mod_strip_cmd
# Select initial ramdisk compression format, default is gzip(1).
# This shall be used by the dracut(8) tool while creating an initramfs image.
#
INITRD_COMPRESS=gzip
ifeq ($(CONFIG_RD_BZIP2), y)
INITRD_COMPRESS=bzip2
else ifeq ($(CONFIG_RD_LZMA), y)
INITRD_COMPRESS=lzma
else ifeq ($(CONFIG_RD_XZ), y)
INITRD_COMPRESS=xz
else ifeq ($(CONFIG_RD_LZO), y)
INITRD_COMPRESS=lzo
else ifeq ($(CONFIG_RD_LZ4), y)
INITRD_COMPRESS=lz4
endif
export INITRD_COMPRESS
ifdef CONFIG_MODULE_SIG_ALL
MODSECKEY = ./signing_key.priv

2
arch/alpha/include/uapi/asm/errno.h
View File

@ -43,7 +43,7 @@
#define EUSERS 68 /* Too many users */
#define EDQUOT 69 /* Quota exceeded */
#define ESTALE 70 /* Stale NFS file handle */
#define ESTALE 70 /* Stale file handle */
#define EREMOTE 71 /* Object is remote */
#define ENOLCK 77 /* No record locks available */

4
arch/alpha/include/uapi/asm/socket.h
View File

@ -81,6 +81,8 @@
#define SO_SELECT_ERR_QUEUE 45
#define SO_BUSY_POLL 46
#define SO_BUSY_POLL 46
#define SO_MAX_PACING_RATE 47
#endif /* _UAPI_ASM_SOCKET_H */

17
arch/arc/include/asm/mach_desc.h
View File

@ -51,22 +51,12 @@ struct machine_desc {
/*
* Current machine - only accessible during boot.
*/
extern struct machine_desc *machine_desc;
extern const struct machine_desc *machine_desc;
/*
* Machine type table - also only accessible during boot
*/
extern struct machine_desc __arch_info_begin[], __arch_info_end[];
#define for_each_machine_desc(p) \
for (p = __arch_info_begin; p < __arch_info_end; p++)
static inline struct machine_desc *default_machine_desc(void)
{
/* the default machine is the last one linked in */
if (__arch_info_end - 1 < __arch_info_begin)
return NULL;
return __arch_info_end - 1;
}
extern const struct machine_desc __arch_info_begin[], __arch_info_end[];
/*
* Set of macros to define architecture features.
@ -81,7 +71,6 @@ __attribute__((__section__(".arch.info.init"))) = { \
#define MACHINE_END \
};
extern struct machine_desc *setup_machine_fdt(void *dt);
extern void __init copy_devtree(void);
extern const struct machine_desc *setup_machine_fdt(void *dt);
#endif

14
arch/arc/include/asm/prom.h
View File

@ -1,14 +0,0 @@
/*
* Copyright (C) 2012 Synopsys, Inc. (www.synopsys.com)
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
#ifndef _ASM_ARC_PROM_H_
#define _ASM_ARC_PROM_H_
#define HAVE_ARCH_DEVTREE_FIXUPS
#endif

97
arch/arc/kernel/devtree.c
View File

@ -14,10 +14,22 @@
#include <linux/memblock.h>
#include <linux/of.h>
#include <linux/of_fdt.h>
#include <asm/prom.h>
#include <asm/clk.h>
#include <asm/mach_desc.h>
static const void * __init arch_get_next_mach(const char *const **match)
{
static const struct machine_desc *mdesc = __arch_info_begin;
const struct machine_desc *m = mdesc;
if (m >= __arch_info_end)
return NULL;
mdesc++;
*match = m->dt_compat;
return m;
}
/**
* setup_machine_fdt - Machine setup when an dtb was passed to the kernel
* @dt: virtual address pointer to dt blob
@ -25,93 +37,24 @@
* If a dtb was passed to the kernel, then use it to choose the correct
* machine_desc and to setup the system.
*/
struct machine_desc * __init setup_machine_fdt(void *dt)
const struct machine_desc * __init setup_machine_fdt(void *dt)
{
struct boot_param_header *devtree = dt;
struct machine_desc *mdesc = NULL, *mdesc_best = NULL;
unsigned int score, mdesc_score = ~1;
const struct machine_desc *mdesc;
unsigned long dt_root;
const char *model, *compat;
void *clk;
char manufacturer[16];
unsigned long len;
/* check device tree validity */
if (be32_to_cpu(devtree->magic) != OF_DT_HEADER)
if (!early_init_dt_scan(dt))
return NULL;
initial_boot_params = devtree;
dt_root = of_get_flat_dt_root();
/*
* The kernel could be multi-platform enabled, thus could have many
* "baked-in" machine descriptors. Search thru all for the best
* "compatible" string match.
*/
for_each_machine_desc(mdesc) {
score = of_flat_dt_match(dt_root, mdesc->dt_compat);
if (score > 0 && score < mdesc_score) {
mdesc_best = mdesc;
mdesc_score = score;
}
}
if (!mdesc_best) {
const char *prop;
long size;
pr_err("\n unrecognized device tree list:\n[ ");
prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
if (prop) {
while (size > 0) {
printk("'%s' ", prop);
size -= strlen(prop) + 1;
prop += strlen(prop) + 1;
}
}
printk("]\n\n");
mdesc = of_flat_dt_match_machine(NULL, arch_get_next_mach);
if (!mdesc)
machine_halt();
}
/* compat = "<manufacturer>,<model>" */
compat = mdesc_best->dt_compat[0];
model = strchr(compat, ',');
if (model)
model++;
strlcpy(manufacturer, compat, model ? model - compat : strlen(compat));
pr_info("Board \"%s\" from %s (Manufacturer)\n", model, manufacturer);
/* Retrieve various information from the /chosen node */
of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
/* Initialize {size,address}-cells info */
of_scan_flat_dt(early_init_dt_scan_root, NULL);
/* Setup memory, calling early_init_dt_add_memory_arch */
of_scan_flat_dt(early_init_dt_scan_memory, NULL);
dt_root = of_get_flat_dt_root();
clk = of_get_flat_dt_prop(dt_root, "clock-frequency", &len);
if (clk)
arc_set_core_freq(of_read_ulong(clk, len/4));
return mdesc_best;
}
/*
* Copy the flattened DT out of .init since unflattening doesn't copy strings
* and the normal DT APIs refs them from orig flat DT
*/
void __init copy_devtree(void)
{
void *alloc = early_init_dt_alloc_memory_arch(
be32_to_cpu(initial_boot_params->totalsize), 64);
if (alloc) {
memcpy(alloc, initial_boot_params,
be32_to_cpu(initial_boot_params->totalsize));
initial_boot_params = alloc;
}
return mdesc;
}

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