Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-11-11 22:51:42 +00:00
Code Issues Packages Projects Releases Wiki Activity

Few clock fixes, a runtime PM fix, and pinctrl-single fix along

Browse Source 
with few other fixes that popped up during the merge window.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.15 (GNU/Linux)
 
 iQIcBAABAgAGBQJShlFZAAoJEBvUPslcq6VzqhsP/Rrk0QYGfOysjNa+6rvCBcqL
 +eupoQvhgRC8W3XkXlRPcfatoOWNy9aPxJXgHcuMMQNdOdtKlhXUyOFPseNOuZrb
 rJcvQNrbMrOv4yP4ZgknKvk8kbDLdJfcdd1LChOsIZW2X0wdrAljzlEehl0YB5ZU
 HdxxmLaNleqJfUwtrXVMPdQiS+FggrvYzDmXeEqpASXH7fnBLHOs8hrK3lMY4g2T
 t9JFAzqeHWONUcZoIy0LvgxhmG6P/5nIgyvq9vD17Hd+xkQeJM0GdLRDgOdWxuIC
 3yADWwWoVdeJ+bge+lVItNSnewb5tlSaybwu5Oqxze2o7DXysLPC2IdCUT9NwADz
 j4Wbqv6GdLdhylI7STZRIfznAQ/k16DLZj8xLVF1UOtDN8aq/UcPqNPVUr83Vhgs
 n7bDQFillCY1FWpQPA/AWDUg++dMT0nz7w6a3dfxPjzeaJuDL1hN2yMXbaoMBMcI
 i+DAnmxxEwLDGtCNLO5o0iw8xkL7GhE1jwaQp7YQpXcax4ImN4WZy8g2vT3J1iHQ
 027vzFE+pUp08AoB+Ug5dPr+UDPqE6EJIc9G5F0x7euL7SC0DuEAld/CPzr/nUgN
 g3lfQq/1vmtUVnmGUKoJHv0ysROLGOgdUx897oSdgLw+3F79KiB5g7SnJCOFEnGC
 kLwouf9DjMhPwudW75X+
 =4fww
 -----END PGP SIGNATURE-----

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

Few clock fixes, a runtime PM fix, and pinctrl-single fix along
with few other fixes that popped up during the merge window.

* tag 'omap-for-v3.13/fixes-for-merge-window-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: Fix build for dra7xx without omap4 and 5
  ARM: OMAP2+: omap_device: maintain sane runtime pm status around suspend/resume
  doc: devicetree: Add bindings documentation for omap-des driver
  ARM: dts: doc: Document missing compatible property for omap-sham driver
  ARM: OMAP3: Beagle: fix return value check in beagle_opp_init()
  ARM: OMAP: devicetree: fix SPI node compatible property syntax items
  pinctrl: single: call pcs_soc->rearm() whenever IRQ mask is changed
  ARM: OMAP2+: smsc911x: fix return value check in gpmc_smsc911x_init()
  + sync with newer trunk
This commit is contained in:
Olof Johansson 2013-11-15 15:17:59 -08:00
commit 6886059f2e
1742 changed files with 55834 additions and 33018 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
CREDITS
View File

@ -3152,6 +3152,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.

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

@ -87,7 +87,10 @@ X!Iinclude/linux/kobject.h
!Ekernel/printk/printk.c
!Ekernel/panic.c
!Ekernel/sys.c
!Ekernel/rcupdate.c
!Ekernel/rcu/srcu.c
!Ekernel/rcu/tree.c
!Ekernel/rcu/tree_plugin.h
!Ekernel/rcu/update.c
</sect1>
<sect1><title>Device Resource Management</title>

64
Documentation/DocBook/genericirq.tmpl
View File

@ -87,7 +87,7 @@
<chapter id="rationale">
<title>Rationale</title>
<para>
The original implementation of interrupt handling in Linux is using
The original implementation of interrupt handling in Linux uses
the __do_IRQ() super-handler, which is able to deal with every
type of interrupt logic.
</para>
@ -111,19 +111,19 @@
</itemizedlist>
</para>
<para>
This split implementation of highlevel IRQ handlers allows us to
This split implementation of high-level IRQ handlers allows us to
optimize the flow of the interrupt handling for each specific
interrupt type. This reduces complexity in that particular codepath
interrupt type. This reduces complexity in that particular code path
and allows the optimized handling of a given type.
</para>
<para>
The original general IRQ implementation used hw_interrupt_type
structures and their ->ack(), ->end() [etc.] callbacks to
differentiate the flow control in the super-handler. This leads to
a mix of flow logic and lowlevel hardware logic, and it also leads
to unnecessary code duplication: for example in i386, there is a
ioapic_level_irq and a ioapic_edge_irq irq-type which share many
of the lowlevel details but have different flow handling.
a mix of flow logic and low-level hardware logic, and it also leads
to unnecessary code duplication: for example in i386, there is an
ioapic_level_irq and an ioapic_edge_irq IRQ-type which share many
of the low-level details but have different flow handling.
</para>
<para>
A more natural abstraction is the clean separation of the
@ -132,23 +132,23 @@
<para>
Analysing a couple of architecture's IRQ subsystem implementations
reveals that most of them can use a generic set of 'irq flow'
methods and only need to add the chip level specific code.
methods and only need to add the chip-level specific code.
The separation is also valuable for (sub)architectures
which need specific quirks in the irq flow itself but not in the
chip-details - and thus provides a more transparent IRQ subsystem
which need specific quirks in the IRQ flow itself but not in the
chip details - and thus provides a more transparent IRQ subsystem
design.
</para>
<para>
Each interrupt descriptor is assigned its own highlevel flow
Each interrupt descriptor is assigned its own high-level flow
handler, which is normally one of the generic
implementations. (This highlevel flow handler implementation also
implementations. (This high-level flow handler implementation also
makes it simple to provide demultiplexing handlers which can be
found in embedded platforms on various architectures.)
</para>
<para>
The separation makes the generic interrupt handling layer more
flexible and extensible. For example, an (sub)architecture can
use a generic irq-flow implementation for 'level type' interrupts
use a generic IRQ-flow implementation for 'level type' interrupts
and add a (sub)architecture specific 'edge type' implementation.
</para>
<para>
@ -172,9 +172,9 @@
<para>
There are three main levels of abstraction in the interrupt code:
<orderedlist>
<listitem><para>Highlevel driver API</para></listitem>
<listitem><para>Highlevel IRQ flow handlers</para></listitem>
<listitem><para>Chiplevel hardware encapsulation</para></listitem>
<listitem><para>High-level driver API</para></listitem>
<listitem><para>High-level IRQ flow handlers</para></listitem>
<listitem><para>Chip-level hardware encapsulation</para></listitem>
</orderedlist>
</para>
<sect1 id="Interrupt_control_flow">
@ -189,16 +189,16 @@
which are assigned to this interrupt.
</para>
<para>
Whenever an interrupt triggers, the lowlevel arch code calls into
the generic interrupt code by calling desc->handle_irq().
This highlevel IRQ handling function only uses desc->irq_data.chip
Whenever an interrupt triggers, the low-level architecture code calls
into the generic interrupt code by calling desc->handle_irq().
This high-level IRQ handling function only uses desc->irq_data.chip
primitives referenced by the assigned chip descriptor structure.
</para>
</sect1>
<sect1 id="Highlevel_Driver_API">
<title>Highlevel Driver API</title>
<title>High-level Driver API</title>
<para>
The highlevel Driver API consists of following functions:
The high-level Driver API consists of following functions:
<itemizedlist>
<listitem><para>request_irq()</para></listitem>
<listitem><para>free_irq()</para></listitem>
@ -216,7 +216,7 @@
</para>
</sect1>
<sect1 id="Highlevel_IRQ_flow_handlers">
<title>Highlevel IRQ flow handlers</title>
<title>High-level IRQ flow handlers</title>
<para>
The generic layer provides a set of pre-defined irq-flow methods:
<itemizedlist>
@ -228,7 +228,7 @@
<listitem><para>handle_edge_eoi_irq</para></listitem>
<listitem><para>handle_bad_irq</para></listitem>
</itemizedlist>
The interrupt flow handlers (either predefined or architecture
The interrupt flow handlers (either pre-defined or architecture
specific) are assigned to specific interrupts by the architecture
either during bootup or during device initialization.
</para>
@ -297,7 +297,7 @@ desc->irq_data.chip->irq_unmask();
<para>
handle_fasteoi_irq provides a generic implementation
for interrupts, which only need an EOI at the end of
the handler
the handler.
</para>
<para>
The following control flow is implemented (simplified excerpt):
@ -394,7 +394,7 @@ if (desc->irq_data.chip->irq_eoi)
The generic functions are intended for 'clean' architectures and chips,
which have no platform-specific IRQ handling quirks. If an architecture
needs to implement quirks on the 'flow' level then it can do so by
overriding the highlevel irq-flow handler.
overriding the high-level irq-flow handler.
</para>
</sect2>
<sect2 id="Delayed_interrupt_disable">
@ -419,9 +419,9 @@ if (desc->irq_data.chip->irq_eoi)
</sect2>
</sect1>
<sect1 id="Chiplevel_hardware_encapsulation">
<title>Chiplevel hardware encapsulation</title>
<title>Chip-level hardware encapsulation</title>
<para>
The chip level hardware descriptor structure irq_chip
The chip-level hardware descriptor structure irq_chip
contains all the direct chip relevant functions, which
can be utilized by the irq flow implementations.
<itemizedlist>
@ -429,14 +429,14 @@ if (desc->irq_data.chip->irq_eoi)
<listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem>
<listitem><para>irq_mask()</para></listitem>
<listitem><para>irq_unmask()</para></listitem>
<listitem><para>irq_eoi() - Optional, required for eoi flow handlers</para></listitem>
<listitem><para>irq_eoi() - Optional, required for EOI flow handlers</para></listitem>
<listitem><para>irq_retrigger() - Optional</para></listitem>
<listitem><para>irq_set_type() - Optional</para></listitem>
<listitem><para>irq_set_wake() - Optional</para></listitem>
</itemizedlist>
These primitives are strictly intended to mean what they say: ack means
ACK, masking means masking of an IRQ line, etc. It is up to the flow
handler(s) to use these basic units of lowlevel functionality.
handler(s) to use these basic units of low-level functionality.
</para>
</sect1>
</chapter>
@ -445,7 +445,7 @@ if (desc->irq_data.chip->irq_eoi)
<title>__do_IRQ entry point</title>
<para>
The original implementation __do_IRQ() was an alternative entry
point for all types of interrupts. It not longer exists.
point for all types of interrupts. It no longer exists.
</para>
<para>
This handler turned out to be not suitable for all
@ -468,11 +468,11 @@ if (desc->irq_data.chip->irq_eoi)
<chapter id="genericchip">
<title>Generic interrupt chip</title>
<para>
To avoid copies of identical implementations of irq chips the
To avoid copies of identical implementations of IRQ chips the
core provides a configurable generic interrupt chip
implementation. Developers should check carefuly whether the
generic chip fits their needs before implementing the same
functionality slightly different themself.
functionality slightly differently themselves.
</para>
!Ekernel/irq/generic-chip.c
</chapter>

4
Documentation/RCU/checklist.txt
View File

@ -202,8 +202,8 @@ over a rather long period of time, but improvements are always welcome!
updater uses call_rcu_sched() or synchronize_sched(), then
the corresponding readers must disable preemption, possibly
by calling rcu_read_lock_sched() and rcu_read_unlock_sched().
If the updater uses synchronize_srcu() or call_srcu(),
the the corresponding readers must use srcu_read_lock() and
If the updater uses synchronize_srcu() or call_srcu(), then
the corresponding readers must use srcu_read_lock() and
srcu_read_unlock(), and with the same srcu_struct. The rules for
the expedited primitives are the same as for their non-expedited
counterparts. Mixing things up will result in confusion and

22
Documentation/RCU/stallwarn.txt
View File

@ -12,12 +12,12 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
This kernel configuration parameter defines the period of time
that RCU will wait from the beginning of a grace period until it
issues an RCU CPU stall warning. This time period is normally
sixty seconds.
21 seconds.
This configuration parameter may be changed at runtime via the
/sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
this parameter is checked only at the beginning of a cycle.
So if you are 30 seconds into a 70-second stall, setting this
So if you are 10 seconds into a 40-second stall, setting this
sysfs parameter to (say) five will shorten the timeout for the
-next- stall, or the following warning for the current stall
(assuming the stall lasts long enough). It will not affect the
@ -32,7 +32,7 @@ CONFIG_RCU_CPU_STALL_VERBOSE
also dump the stacks of any tasks that are blocking the current
RCU-preempt grace period.
RCU_CPU_STALL_INFO
CONFIG_RCU_CPU_STALL_INFO
This kernel configuration parameter causes the stall warning to
print out additional per-CPU diagnostic information, including
@ -43,7 +43,8 @@ RCU_STALL_DELAY_DELTA
Although the lockdep facility is extremely useful, it does add
some overhead. Therefore, under CONFIG_PROVE_RCU, the
RCU_STALL_DELAY_DELTA macro allows five extra seconds before
giving an RCU CPU stall warning message.
giving an RCU CPU stall warning message. (This is a cpp
macro, not a kernel configuration parameter.)
RCU_STALL_RAT_DELAY
@ -52,7 +53,8 @@ RCU_STALL_RAT_DELAY
However, if the offending CPU does not detect its own stall in
the number of jiffies specified by RCU_STALL_RAT_DELAY, then
some other CPU will complain. This delay is normally set to
two jiffies.
two jiffies. (This is a cpp macro, not a kernel configuration
parameter.)
When a CPU detects that it is stalling, it will print a message similar
to the following:
@ -86,7 +88,12 @@ printing, there will be a spurious stall-warning message:
INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffies)
This is rare, but does happen from time to time in real life.
This is rare, but does happen from time to time in real life. It is also
possible for a zero-jiffy stall to be flagged in this case, depending
on how the stall warning and the grace-period initialization happen to
interact. Please note that it is not possible to entirely eliminate this
sort of false positive without resorting to things like stop_machine(),
which is overkill for this sort of problem.
If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
more information is printed with the stall-warning message, for example:
@ -216,4 +223,5 @@ that portion of the stack which remains the same from trace to trace.
If you can reliably trigger the stall, ftrace can be quite helpful.
RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE
and with RCU's event tracing.
and with RCU's event tracing. For information on RCU's event tracing,
see include/trace/events/rcu.h.

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.

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";
};

30
Documentation/devicetree/bindings/crypto/omap-des.txt Normal file
View File

@ -0,0 +1,30 @@
OMAP SoC DES crypto Module
Required properties:
- compatible : Should contain "ti,omap4-des"
- ti,hwmods: Name of the hwmod associated with the DES module
- reg : Offset and length of the register set for the module
- interrupts : the interrupt-specifier for the DES module
- clocks : A phandle to the functional clock node of the DES module
corresponding to each entry in clock-names
- clock-names : Name of the functional clock, should be "fck"
Optional properties:
- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
Documentation/devicetree/bindings/dma/dma.txt
Each entry corresponds to an entry in dma-names
- dma-names: DMA request names should include "tx" and "rx" if present
Example:
/* DRA7xx SoC */
des: des@480a5000 {
compatible = "ti,omap4-des";
ti,hwmods = "des";
reg = <0x480a5000 0xa0>;
interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&sdma 117>, <&sdma 116>;
dma-names = "tx", "rx";
clocks = <&l3_iclk_div>;
clock-names = "fck";
};

2
Documentation/devicetree/bindings/crypto/omap-sham.txt
View File

@ -6,7 +6,7 @@ Required properties:
SHAM versions:
- "ti,omap2-sham" for OMAP2 & OMAP3.
- "ti,omap4-sham" for OMAP4 and AM33XX.
Note that these two versions are incompatible.
- "ti,omap5-sham" for OMAP5, DRA7 and AM43XX.
- ti,hwmods: Name of the hwmod associated with the SHAM module
- reg : Offset and length of the register set for the module
- interrupts : the interrupt-specifier for the SHAM module.

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 {

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>;
};

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

@ -2,8 +2,8 @@ OMAP2+ McSPI device
Required properties:
- compatible :
- "ti,omap2-spi" for OMAP2 & OMAP3.
- "ti,omap4-spi" for OMAP4+.
- "ti,omap2-mcspi" for OMAP2 & OMAP3.
- "ti,omap4-mcspi" for OMAP4+.
- ti,spi-num-cs : Number of chipselect supported by the instance.
- ti,hwmods: Name of the hwmod associated to the McSPI
- ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as

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

23
Documentation/devicetree/bindings/timer/efm32,timer.txt Normal file
View File

@ -0,0 +1,23 @@
* EFM32 timer hardware
The efm32 Giant Gecko SoCs come with four 16 bit timers. Two counters can be
connected to form a 32 bit counter. Each timer has three Compare/Capture
channels and can be used as PWM or Quadrature Decoder. Available clock sources
are the cpu's HFPERCLK (with a 10-bit prescaler) or an external pin.
Required properties:
- compatible : Should be efm32,timer
- reg : Address and length of the register set
- clocks : Should contain a reference to the HFPERCLK
Optional properties:
- interrupts : Reference to the timer interrupt
Example:
timer@40010c00 {
compatible = "efm32,timer";
reg = <0x40010c00 0x400>;
interrupts = <14>;
clocks = <&cmu clk_HFPERCLKTIMER3>;
};

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

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()

0
Documentation/x86/efi-stub.txt → Documentation/efi-stub.txt
View File

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!

109
Documentation/kernel-parameters.txt
View File

@ -847,6 +847,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
earlyprintk= [X86,SH,BLACKFIN,ARM]
earlyprintk=vga
earlyprintk=efi
earlyprintk=xen
earlyprintk=serial[,ttySn[,baudrate]]
earlyprintk=serial[,0x...[,baudrate]]
@ -860,7 +861,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Append ",keep" to not disable it when the real console
takes over.
Only vga or serial or usb debug port at a time.
Only one of vga, efi, serial, or usb debug port can
be used at a time.
Currently only ttyS0 and ttyS1 may be specified by
name. Other I/O ports may be explicitly specified
@ -874,8 +876,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Interaction with the standard serial driver is not
very good.
The VGA output is eventually overwritten by the real
console.
The VGA and EFI output is eventually overwritten by
the real console.
The xen output can only be used by Xen PV guests.
@ -2599,7 +2601,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
ramdisk_size= [RAM] Sizes of RAM disks in kilobytes
See Documentation/blockdev/ramdisk.txt.
rcu_nocbs= [KNL,BOOT]
rcu_nocbs= [KNL]
In kernels built with CONFIG_RCU_NOCB_CPU=y, set
the specified list of CPUs to be no-callback CPUs.
Invocation of these CPUs' RCU callbacks will
@ -2612,7 +2614,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
real-time workloads. It can also improve energy
efficiency for asymmetric multiprocessors.
rcu_nocb_poll [KNL,BOOT]
rcu_nocb_poll [KNL]
Rather than requiring that offloaded CPUs
(specified by rcu_nocbs= above) explicitly
awaken the corresponding "rcuoN" kthreads,
@ -2623,126 +2625,145 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
energy efficiency by requiring that the kthreads
periodically wake up to do the polling.
rcutree.blimit= [KNL,BOOT]
rcutree.blimit= [KNL]
Set maximum number of finished RCU callbacks to process
in one batch.
rcutree.fanout_leaf= [KNL,BOOT]
rcutree.rcu_fanout_leaf= [KNL]
Increase the number of CPUs assigned to each
leaf rcu_node structure. Useful for very large
systems.
rcutree.jiffies_till_first_fqs= [KNL,BOOT]
rcutree.jiffies_till_first_fqs= [KNL]
Set delay from grace-period initialization to
first attempt to force quiescent states.
Units are jiffies, minimum value is zero,
and maximum value is HZ.
rcutree.jiffies_till_next_fqs= [KNL,BOOT]
rcutree.jiffies_till_next_fqs= [KNL]
Set delay between subsequent attempts to force
quiescent states. Units are jiffies, minimum
value is one, and maximum value is HZ.
rcutree.qhimark= [KNL,BOOT]
rcutree.qhimark= [KNL]
Set threshold of queued
RCU callbacks over which batch limiting is disabled.
rcutree.qlowmark= [KNL,BOOT]
rcutree.qlowmark= [KNL]
Set threshold of queued RCU callbacks below which
batch limiting is re-enabled.
rcutree.rcu_cpu_stall_suppress= [KNL,BOOT]
Suppress RCU CPU stall warning messages.
rcutree.rcu_cpu_stall_timeout= [KNL,BOOT]
Set timeout for RCU CPU stall warning messages.
rcutree.rcu_idle_gp_delay= [KNL,BOOT]
rcutree.rcu_idle_gp_delay= [KNL]
Set wakeup interval for idle CPUs that have
RCU callbacks (RCU_FAST_NO_HZ=y).
rcutree.rcu_idle_lazy_gp_delay= [KNL,BOOT]
rcutree.rcu_idle_lazy_gp_delay= [KNL]
Set wakeup interval for idle CPUs that have
only "lazy" RCU callbacks (RCU_FAST_NO_HZ=y).
Lazy RCU callbacks are those which RCU can
prove do nothing more than free memory.
rcutorture.fqs_duration= [KNL,BOOT]
rcutorture.fqs_duration= [KNL]
Set duration of force_quiescent_state bursts.
rcutorture.fqs_holdoff= [KNL,BOOT]
rcutorture.fqs_holdoff= [KNL]
Set holdoff time within force_quiescent_state bursts.
rcutorture.fqs_stutter= [KNL,BOOT]
rcutorture.fqs_stutter= [KNL]
Set wait time between force_quiescent_state bursts.
rcutorture.irqreader= [KNL,BOOT]
Test RCU readers from irq handlers.
rcutorture.gp_exp= [KNL]
Use expedited update-side primitives.
rcutorture.n_barrier_cbs= [KNL,BOOT]
rcutorture.gp_normal= [KNL]
Use normal (non-expedited) update-side primitives.
If both gp_exp and gp_normal are set, do both.
If neither gp_exp nor gp_normal are set, still
do both.
rcutorture.n_barrier_cbs= [KNL]
Set callbacks/threads for rcu_barrier() testing.
rcutorture.nfakewriters= [KNL,BOOT]
rcutorture.nfakewriters= [KNL]
Set number of concurrent RCU writers. These just
stress RCU, they don't participate in the actual
test, hence the "fake".
rcutorture.nreaders= [KNL,BOOT]
rcutorture.nreaders= [KNL]
Set number of RCU readers.
rcutorture.onoff_holdoff= [KNL,BOOT]
rcutorture.object_debug= [KNL]
Enable debug-object double-call_rcu() testing.
rcutorture.onoff_holdoff= [KNL]
Set time (s) after boot for CPU-hotplug testing.
rcutorture.onoff_interval= [KNL,BOOT]
rcutorture.onoff_interval= [KNL]
Set time (s) between CPU-hotplug operations, or
zero to disable CPU-hotplug testing.
rcutorture.shuffle_interval= [KNL,BOOT]
rcutorture.rcutorture_runnable= [BOOT]
Start rcutorture running at boot time.
rcutorture.shuffle_interval= [KNL]
Set task-shuffle interval (s). Shuffling tasks
allows some CPUs to go into dyntick-idle mode
during the rcutorture test.
rcutorture.shutdown_secs= [KNL,BOOT]
rcutorture.shutdown_secs= [KNL]
Set time (s) after boot system shutdown. This
is useful for hands-off automated testing.
rcutorture.stall_cpu= [KNL,BOOT]
rcutorture.stall_cpu= [KNL]
Duration of CPU stall (s) to test RCU CPU stall
warnings, zero to disable.
rcutorture.stall_cpu_holdoff= [KNL,BOOT]
rcutorture.stall_cpu_holdoff= [KNL]
Time to wait (s) after boot before inducing stall.
rcutorture.stat_interval= [KNL,BOOT]
rcutorture.stat_interval= [KNL]
Time (s) between statistics printk()s.
rcutorture.stutter= [KNL,BOOT]
rcutorture.stutter= [KNL]
Time (s) to stutter testing, for example, specifying
five seconds causes the test to run for five seconds,
wait for five seconds, and so on. This tests RCU's
ability to transition abruptly to and from idle.
rcutorture.test_boost= [KNL,BOOT]
rcutorture.test_boost= [KNL]
Test RCU priority boosting? 0=no, 1=maybe, 2=yes.
"Maybe" means test if the RCU implementation
under test support RCU priority boosting.
rcutorture.test_boost_duration= [KNL,BOOT]
rcutorture.test_boost_duration= [KNL]
Duration (s) of each individual boost test.
rcutorture.test_boost_interval= [KNL,BOOT]
rcutorture.test_boost_interval= [KNL]
Interval (s) between each boost test.
rcutorture.test_no_idle_hz= [KNL,BOOT]
rcutorture.test_no_idle_hz= [KNL]
Test RCU's dyntick-idle handling. See also the
rcutorture.shuffle_interval parameter.
rcutorture.torture_type= [KNL,BOOT]
rcutorture.torture_type= [KNL]
Specify the RCU implementation to test.
rcutorture.verbose= [KNL,BOOT]
rcutorture.verbose= [KNL]
Enable additional printk() statements.
rcupdate.rcu_expedited= [KNL]
Use expedited grace-period primitives, for
example, synchronize_rcu_expedited() instead
of synchronize_rcu(). This reduces latency,
but can increase CPU utilization, degrade
real-time latency, and degrade energy efficiency.
rcupdate.rcu_cpu_stall_suppress= [KNL]
Suppress RCU CPU stall warning messages.
rcupdate.rcu_cpu_stall_timeout= [KNL]
Set timeout for RCU CPU stall warning messages.
rdinit= [KNL]
Format: <full_path>
Run specified binary instead of /init from the ramdisk,
@ -3471,11 +3492,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
default x2apic cluster mode on platforms
supporting x2apic.
x86_mrst_timer= [X86-32,APBT]
Choose timer option for x86 Moorestown MID platform.
x86_intel_mid_timer= [X86-32,APBT]
Choose timer option for x86 Intel MID platform.
Two valid options are apbt timer only and lapic timer
plus one apbt timer for broadcast timer.
x86_mrst_timer=apbt_only | lapic_and_apbt
x86_intel_mid_timer=apbt_only | lapic_and_apbt
xen_emul_unplug= [HW,X86,XEN]
Unplug Xen emulated devices

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

@ -181,12 +181,17 @@ To reduce its OS jitter, do any of the following:
make sure that this is safe on your particular system.
d. It is not possible to entirely get rid of OS jitter
from vmstat_update() on CONFIG_SMP=y systems, but you
can decrease its frequency by writing a large value to
/proc/sys/vm/stat_interval. The default value is HZ,
for an interval of one second. Of course, larger values
will make your virtual-memory statistics update more
slowly. Of course, you can also run your workload at
a real-time priority, thus preempting vmstat_update().
can decrease its frequency by writing a large value
to /proc/sys/vm/stat_interval. The default value is
HZ, for an interval of one second. Of course, larger
values will make your virtual-memory statistics update
more slowly. Of course, you can also run your workload
at a real-time priority, thus preempting vmstat_update(),
but if your workload is CPU-bound, this is a bad idea.
However, there is an RFC patch from Christoph Lameter
(based on an earlier one from Gilad Ben-Yossef) that
reduces or even eliminates vmstat overhead for some
workloads at https://lkml.org/lkml/2013/9/4/379.
e. If running on high-end powerpc servers, build with
CONFIG_PPC_RTAS_DAEMON=n. This prevents the RTAS
daemon from running on each CPU every second or so.

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:

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

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.

76
Documentation/sysctl/kernel.txt
View File

@ -355,6 +355,82 @@ utilize.
==============================================================
numa_balancing
Enables/disables automatic page fault based NUMA memory
balancing. Memory is moved automatically to nodes
that access it often.
Enables/disables automatic NUMA memory balancing. On NUMA machines, there
is a performance penalty if remote memory is accessed by a CPU. When this
feature is enabled the kernel samples what task thread is accessing memory
by periodically unmapping pages and later trapping a page fault. At the
time of the page fault, it is determined if the data being accessed should
be migrated to a local memory node.
The unmapping of pages and trapping faults incur additional overhead that
ideally is offset by improved memory locality but there is no universal
guarantee. If the target workload is already bound to NUMA nodes then this
feature should be disabled. Otherwise, if the system overhead from the
feature is too high then the rate the kernel samples for NUMA hinting
faults may be controlled by the numa_balancing_scan_period_min_ms,
numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms,
numa_balancing_scan_size_mb, numa_balancing_settle_count sysctls and
numa_balancing_migrate_deferred.
==============================================================
numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms,
numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb
Automatic NUMA balancing scans tasks address space and unmaps pages to
detect if pages are properly placed or if the data should be migrated to a
memory node local to where the task is running. Every "scan delay" the task
scans the next "scan size" number of pages in its address space. When the
end of the address space is reached the scanner restarts from the beginning.
In combination, the "scan delay" and "scan size" determine the scan rate.
When "scan delay" decreases, the scan rate increases. The scan delay and
hence the scan rate of every task is adaptive and depends on historical
behaviour. If pages are properly placed then the scan delay increases,
otherwise the scan delay decreases. The "scan size" is not adaptive but
the higher the "scan size", the higher the scan rate.
Higher scan rates incur higher system overhead as page faults must be
trapped and potentially data must be migrated. However, the higher the scan
rate, the more quickly a tasks memory is migrated to a local node if the
workload pattern changes and minimises performance impact due to remote
memory accesses. These sysctls control the thresholds for scan delays and
the number of pages scanned.
numa_balancing_scan_period_min_ms is the minimum time in milliseconds to
scan a tasks virtual memory. It effectively controls the maximum scanning
rate for each task.
numa_balancing_scan_delay_ms is the starting "scan delay" used for a task
when it initially forks.
numa_balancing_scan_period_max_ms is the maximum time in milliseconds to
scan a tasks virtual memory. It effectively controls the minimum scanning
rate for each task.
numa_balancing_scan_size_mb is how many megabytes worth of pages are
scanned for a given scan.
numa_balancing_settle_count is how many scan periods must complete before
the schedule balancer stops pushing the task towards a preferred node. This
gives the scheduler a chance to place the task on an alternative node if the
preferred node is overloaded.
numa_balancing_migrate_deferred is how many page migrations get skipped
unconditionally, after a page migration is skipped because a page is shared
with other tasks. This reduces page migration overhead, and determines
how much stronger the "move task near its memory" policy scheduler becomes,
versus the "move memory near its task" memory management policy, for workloads
with shared memory.
==============================================================
osrelease, ostype & version:
# cat osrelease

6
Documentation/trace/ftrace.txt
View File

@ -655,7 +655,11 @@ explains which is which.
read the irq flags variable, an 'X' will always
be printed here.
need-resched: 'N' task need_resched is set, '.' otherwise.
need-resched:
'N' both TIF_NEED_RESCHED and PREEMPT_NEED_RESCHED is set,
'n' only TIF_NEED_RESCHED is set,
'p' only PREEMPT_NEED_RESCHED is set,
'.' otherwise.
hardirq/softirq:
'H' - hard irq occurred inside a softirq.

27
MAINTAINERS
View File

@ -4439,6 +4439,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
@ -6971,7 +6977,7 @@ M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
F: Documentation/RCU/torture.txt
F: kernel/rcutorture.c
F: kernel/rcu/torture.c
RDC R-321X SoC
M: Florian Fainelli <florian@openwrt.org>
@ -6998,8 +7004,9 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
F: Documentation/RCU/
X: Documentation/RCU/torture.txt
F: include/linux/rcu*
F: kernel/rcu*
X: kernel/rcutorture.c
X: include/linux/srcu.h
F: kernel/rcu/
X: kernel/rcu/torture.c
REAL TIME CLOCK (RTC) SUBSYSTEM
M: Alessandro Zummo <a.zummo@towertech.it>
@ -7324,6 +7331,8 @@ S: Maintained
F: kernel/sched/
F: include/linux/sched.h
F: include/uapi/linux/sched.h
F: kernel/wait.c
F: include/linux/wait.h
SCORE ARCHITECTURE
M: Chen Liqin <liqin.linux@gmail.com>
@ -7686,8 +7695,8 @@ M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
W: http://www.rdrop.com/users/paulmck/RCU/
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
F: include/linux/srcu*
F: kernel/srcu*
F: include/linux/srcu.h
F: kernel/rcu/srcu.c
SMACK SECURITY MODULE
M: Casey Schaufler <casey@schaufler-ca.com>
@ -8703,14 +8712,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

22
arch/Kconfig
View File

@ -353,6 +353,18 @@ config HAVE_CONTEXT_TRACKING
config HAVE_VIRT_CPU_ACCOUNTING
bool
config HAVE_VIRT_CPU_ACCOUNTING_GEN
bool
default y if 64BIT
help
With VIRT_CPU_ACCOUNTING_GEN, cputime_t becomes 64-bit.
Before enabling this option, arch code must be audited
to ensure there are no races in concurrent read/write of
cputime_t. For example, reading/writing 64-bit cputime_t on
some 32-bit arches may require multiple accesses, so proper
locking is needed to protect against concurrent accesses.
config HAVE_IRQ_TIME_ACCOUNTING
bool
help
@ -390,6 +402,16 @@ config HAVE_UNDERSCORE_SYMBOL_PREFIX
Some architectures generate an _ in front of C symbols; things like
module loading and assembly files need to know about this.
config HAVE_IRQ_EXIT_ON_IRQ_STACK
bool
help
Architecture doesn't only execute the irq handler on the irq stack
but also irq_exit(). This way we can process softirqs on this irq
stack instead of switching to a new one when we call __do_softirq()
in the end of an hardirq.
This spares a stack switch and improves cache usage on softirq
processing.
#
# ABI hall of shame
#

1
arch/alpha/include/asm/Kbuild
View File

@ -3,3 +3,4 @@ generic-y += clkdev.h
generic-y += exec.h
generic-y += trace_clock.h
generic-y += preempt.h

1
arch/arc/include/asm/Kbuild
View File

@ -46,3 +46,4 @@ generic-y += ucontext.h
generic-y += user.h
generic-y += vga.h
generic-y += xor.h
generic-y += preempt.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;
}

6
arch/arc/kernel/setup.c
View File

@ -21,7 +21,6 @@
#include <asm/setup.h>
#include <asm/page.h>
#include <asm/irq.h>
#include <asm/prom.h>
#include <asm/unwind.h>
#include <asm/clk.h>
#include <asm/mach_desc.h>
@ -31,7 +30,7 @@
int running_on_hw = 1; /* vs. on ISS */
char __initdata command_line[COMMAND_LINE_SIZE];
struct machine_desc *machine_desc;
const struct machine_desc *machine_desc;
struct task_struct *_current_task[NR_CPUS]; /* For stack switching */
@ -345,8 +344,7 @@ void __init setup_arch(char **cmdline_p)
setup_arch_memory();
/* copy flat DT out of .init and then unflatten it */
copy_devtree();
unflatten_device_tree();
unflatten_and_copy_device_tree();
/* Can be issue if someone passes cmd line arg "ro"
* But that is unlikely so keeping it as it is

7
arch/arc/mm/init.c
View File

@ -125,10 +125,3 @@ void __init free_initrd_mem(unsigned long start, unsigned long end)
free_reserved_area((void *)start, (void *)end, -1, "initrd");
}
#endif
#ifdef CONFIG_OF_FLATTREE
void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
{
pr_err("%s(%llx, %llx)\n", __func__, start, end);
}
#endif /* CONFIG_OF_FLATTREE */

8
arch/arm/Kconfig
View File

@ -54,6 +54,7 @@ config ARM
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_UID16
select HAVE_VIRT_CPU_ACCOUNTING_GEN
select IRQ_FORCED_THREADING
select KTIME_SCALAR
select MODULES_USE_ELF_REL
@ -388,7 +389,6 @@ config ARCH_GEMINI
select CLKSRC_MMIO
select CPU_FA526
select GENERIC_CLOCKEVENTS
select NEED_MACH_GPIO_H
help
Support for the Cortina Systems Gemini family SoCs
@ -457,7 +457,7 @@ config ARCH_IOP32X
depends on MMU
select ARCH_REQUIRE_GPIOLIB
select CPU_XSCALE
select NEED_MACH_GPIO_H
select GPIO_IOP
select NEED_RET_TO_USER
select PCI
select PLAT_IOP
@ -470,7 +470,7 @@ config ARCH_IOP33X
depends on MMU
select ARCH_REQUIRE_GPIOLIB
select CPU_XSCALE
select NEED_MACH_GPIO_H
select GPIO_IOP
select NEED_RET_TO_USER
select PCI
select PLAT_IOP
@ -559,7 +559,6 @@ config ARCH_MMP
select GPIO_PXA
select IRQ_DOMAIN
select MULTI_IRQ_HANDLER
select NEED_MACH_GPIO_H
select PINCTRL
select PLAT_PXA
select SPARSE_IRQ
@ -622,7 +621,6 @@ config ARCH_PXA
select GPIO_PXA
select HAVE_IDE
select MULTI_IRQ_HANDLER
select NEED_MACH_GPIO_H
select PLAT_PXA
select SPARSE_IRQ
help

12
arch/arm/boot/dts/atlas6.dtsi
View File

@ -558,6 +558,18 @@
sirf,function = "usb1_utmi_drvbus";
};
};
usb1_dp_dn_pins_a: usb1_dp_dn@0 {
usb1_dp_dn {
sirf,pins = "usb1_dp_dngrp";
sirf,function = "usb1_dp_dn";
};
};
uart1_route_io_usb1_pins_a: uart1_route_io_usb1@0 {
uart1_route_io_usb1 {
sirf,pins = "uart1_route_io_usb1grp";
sirf,function = "uart1_route_io_usb1";
};
};
warm_rst_pins_a: warm_rst@0 {
warm_rst {
sirf,pins = "warm_rstgrp";

42
arch/arm/boot/dts/prima2.dtsi
View File

@ -388,6 +388,12 @@
sirf,function = "uart0";
};
};
uart0_noflow_pins_a: uart0@1 {
uart {
sirf,pins = "uart0_nostreamctrlgrp";
sirf,function = "uart0_nostreamctrl";
};
};
uart1_pins_a: uart1@0 {
uart {
sirf,pins = "uart1grp";
@ -526,18 +532,42 @@
sirf,function = "usp0";
};
};
usp0_uart_nostreamctrl_pins_a: usp0@1 {
usp0 {
sirf,pins =
"usp0_uart_nostreamctrl_grp";
sirf,function =
"usp0_uart_nostreamctrl";
};
};
usp1_pins_a: usp1@0 {
usp1 {
sirf,pins = "usp1grp";
sirf,function = "usp1";
};
};
usp1_uart_nostreamctrl_pins_a: usp1@1 {
usp1 {
sirf,pins =
"usp1_uart_nostreamctrl_grp";
sirf,function =
"usp1_uart_nostreamctrl";
};
};
usp2_pins_a: usp2@0 {
usp2 {
sirf,pins = "usp2grp";
sirf,function = "usp2";
};
};
usp2_uart_nostreamctrl_pins_a: usp2@1 {
usp2 {
sirf,pins =
"usp2_uart_nostreamctrl_grp";
sirf,function =
"usp2_uart_nostreamctrl";
};
};
usb0_utmi_drvbus_pins_a: usb0_utmi_drvbus@0 {
usb0_utmi_drvbus {
sirf,pins = "usb0_utmi_drvbusgrp";
@ -550,6 +580,18 @@
sirf,function = "usb1_utmi_drvbus";
};
};
usb1_dp_dn_pins_a: usb1_dp_dn@0 {
usb1_dp_dn {
sirf,pins = "usb1_dp_dngrp";
sirf,function = "usb1_dp_dn";
};
};
uart1_route_io_usb1_pins_a: uart1_route_io_usb1@0 {
uart1_route_io_usb1 {
sirf,pins = "uart1_route_io_usb1grp";
sirf,function = "uart1_route_io_usb1";
};
};
warm_rst_pins_a: warm_rst@0 {
warm_rst {
sirf,pins = "warm_rstgrp";

58
arch/arm/boot/dts/testcases/tests-interrupts.dtsi Normal file
View File

@ -0,0 +1,58 @@
/ {
testcase-data {
interrupts {
#address-cells = <1>;
#size-cells = <1>;
test_intc0: intc0 {
interrupt-controller;
#interrupt-cells = <1>;
};
test_intc1: intc1 {
interrupt-controller;
#interrupt-cells = <3>;
};
test_intc2: intc2 {
interrupt-controller;
#interrupt-cells = <2>;
};
test_intmap0: intmap0 {
#interrupt-cells = <1>;
#address-cells = <0>;
interrupt-map = <1 &test_intc0 9>,
<2 &test_intc1 10 11 12>,
<3 &test_intc2 13 14>,
<4 &test_intc2 15 16>;
};
test_intmap1: intmap1 {
#interrupt-cells = <2>;
interrupt-map = <0x5000 1 2 &test_intc0 15>;
};
interrupts0 {
interrupt-parent = <&test_intc0>;
interrupts = <1>, <2>, <3>, <4>;
};
interrupts1 {
interrupt-parent = <&test_intmap0>;
interrupts = <1>, <2>, <3>, <4>;
};
interrupts-extended0 {
reg = <0x5000 0x100>;
interrupts-extended = <&test_intc0 1>,
<&test_intc1 2 3 4>,
<&test_intc2 5 6>,
<&test_intmap0 1>,
<&test_intmap0 2>,
<&test_intmap0 3>,
<&test_intmap1 1 2>;
};
};
};
};

1
arch/arm/boot/dts/testcases/tests.dtsi
View File

@ -1 +1,2 @@
/include/ "tests-phandle.dtsi"
/include/ "tests-interrupts.dtsi"

2
arch/arm/boot/dts/versatile-ab.dts
View File

@ -185,7 +185,7 @@
mmc@5000 {
compatible = "arm,primecell";
reg = < 0x5000 0x1000>;
interrupts = <22 34>;
interrupts-extended = <&vic 22 &sic 2>;
};
kmi@6000 {
compatible = "arm,pl050", "arm,primecell";

2
arch/arm/boot/dts/versatile-pb.dts
View File

@ -41,7 +41,7 @@
mmc@b000 {
compatible = "arm,primecell";
reg = <0xb000 0x1000>;
interrupts = <23 34>;
interrupts-extended = <&vic 23 &sic 2>;
};
};
};

8
arch/arm/boot/dts/zynq-7000.dtsi
View File

@ -92,6 +92,14 @@
};
};
global_timer: timer@f8f00200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0xf8f00200 0x20>;
interrupts = <1 11 0x301>;
interrupt-parent = <&intc>;
clocks = <&clkc 4>;
};
ttc0: ttc0@f8001000 {
interrupt-parent = <&intc>;
interrupts = < 0 10 4 0 11 4 0 12 4 >;

1
arch/arm/include/asm/Kbuild
View File

@ -32,3 +32,4 @@ generic-y += termios.h
generic-y += timex.h
generic-y += trace_clock.h
generic-y += unaligned.h
generic-y += preempt.h

36
arch/arm/include/asm/arch_timer.h
View File

@ -87,17 +87,43 @@ static inline u64 arch_counter_get_cntvct(void)
return cval;
}
static inline void arch_counter_set_user_access(void)
static inline u32 arch_timer_get_cntkctl(void)
{
u32 cntkctl;
asm volatile("mrc p15, 0, %0, c14, c1, 0" : "=r" (cntkctl));
return cntkctl;
}
/* disable user access to everything */
cntkctl &= ~((3 << 8) | (7 << 0));
static inline void arch_timer_set_cntkctl(u32 cntkctl)
{
asm volatile("mcr p15, 0, %0, c14, c1, 0" : : "r" (cntkctl));
}
static inline void arch_counter_set_user_access(void)
{
u32 cntkctl = arch_timer_get_cntkctl();
/* Disable user access to both physical/virtual counters/timers */
/* Also disable virtual event stream */
cntkctl &= ~(ARCH_TIMER_USR_PT_ACCESS_EN
| ARCH_TIMER_USR_VT_ACCESS_EN
| ARCH_TIMER_VIRT_EVT_EN
| ARCH_TIMER_USR_VCT_ACCESS_EN
| ARCH_TIMER_USR_PCT_ACCESS_EN);
arch_timer_set_cntkctl(cntkctl);
}
static inline void arch_timer_evtstrm_enable(int divider)
{
u32 cntkctl = arch_timer_get_cntkctl();
cntkctl &= ~ARCH_TIMER_EVT_TRIGGER_MASK;
/* Set the divider and enable virtual event stream */
cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
| ARCH_TIMER_VIRT_EVT_EN;
arch_timer_set_cntkctl(cntkctl);
elf_hwcap |= HWCAP_EVTSTRM;
}
#endif
#endif

75
arch/arm/include/asm/hardware/iop3xx-gpio.h
View File

@ -1,75 +0,0 @@
/*
* arch/arm/include/asm/hardware/iop3xx-gpio.h
*
* IOP3xx GPIO wrappers
*
* Copyright (c) 2008 Arnaud Patard <arnaud.patard@rtp-net.org>
* Based on IXP4XX gpio.h file
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/
#ifndef __ASM_ARM_HARDWARE_IOP3XX_GPIO_H
#define __ASM_ARM_HARDWARE_IOP3XX_GPIO_H
#include <mach/hardware.h>
#include <asm-generic/gpio.h>
#define __ARM_GPIOLIB_COMPLEX
#define IOP3XX_N_GPIOS 8
static inline int gpio_get_value(unsigned gpio)
{
if (gpio > IOP3XX_N_GPIOS)
return __gpio_get_value(gpio);
return gpio_line_get(gpio);
}
static inline void gpio_set_value(unsigned gpio, int value)
{
if (gpio > IOP3XX_N_GPIOS) {
__gpio_set_value(gpio, value);
return;
}
gpio_line_set(gpio, value);
}
static inline int gpio_cansleep(unsigned gpio)
{
if (gpio < IOP3XX_N_GPIOS)
return 0;
else
return __gpio_cansleep(gpio);
}
/*
* The GPIOs are not generating any interrupt
* Note : manuals are not clear about this
*/
static inline int gpio_to_irq(int gpio)
{
return -EINVAL;
}
static inline int irq_to_gpio(int gpio)
{
return -EINVAL;
}
#endif

12
arch/arm/include/asm/hardware/iop3xx.h
View File

@ -18,16 +18,9 @@
/*
* IOP3XX GPIO handling
*/
#define GPIO_IN 0
#define GPIO_OUT 1
#define GPIO_LOW 0
#define GPIO_HIGH 1
#define IOP3XX_GPIO_LINE(x) (x)
#ifndef __ASSEMBLY__
extern void gpio_line_config(int line, int direction);
extern int gpio_line_get(int line);
extern void gpio_line_set(int line, int value);
extern int init_atu;
extern int iop3xx_get_init_atu(void);
#endif
@ -168,11 +161,6 @@ extern int iop3xx_get_init_atu(void);
/* PERCR0 DOESN'T EXIST - index from 1! */
#define IOP3XX_PERCR0 (volatile u32 *)IOP3XX_REG_ADDR(0x0710)
/* General Purpose I/O */
#define IOP3XX_GPOE (volatile u32 *)IOP3XX_GPIO_REG(0x0000)
#define IOP3XX_GPID (volatile u32 *)IOP3XX_GPIO_REG(0x0004)
#define IOP3XX_GPOD (volatile u32 *)IOP3XX_GPIO_REG(0x0008)
/* Timers */
#define IOP3XX_TU_TMR0 (volatile u32 *)IOP3XX_TIMER_REG(0x0000)
#define IOP3XX_TU_TMR1 (volatile u32 *)IOP3XX_TIMER_REG(0x0004)

2
arch/arm/include/asm/prom.h
View File

@ -11,8 +11,6 @@
#ifndef __ASMARM_PROM_H
#define __ASMARM_PROM_H
#define HAVE_ARCH_DEVTREE_FIXUPS
#ifdef CONFIG_OF
extern const struct machine_desc *setup_machine_fdt(unsigned int dt_phys);

1
arch/arm/include/uapi/asm/hwcap.h
View File

@ -26,5 +26,6 @@
#define HWCAP_VFPD32 (1 << 19) /* set if VFP has 32 regs (not 16) */
#define HWCAP_IDIV (HWCAP_IDIVA | HWCAP_IDIVT)
#define HWCAP_LPAE (1 << 20)
#define HWCAP_EVTSTRM (1 << 21)
#endif /* _UAPI__ASMARM_HWCAP_H */

14
arch/arm/kernel/arch_timer.c
View File

@ -11,7 +11,6 @@
#include <linux/init.h>
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/sched_clock.h>
#include <asm/delay.h>
@ -22,13 +21,6 @@ static unsigned long arch_timer_read_counter_long(void)
return arch_timer_read_counter();
}
static u32 sched_clock_mult __read_mostly;
static unsigned long long notrace arch_timer_sched_clock(void)
{
return arch_timer_read_counter() * sched_clock_mult;
}
static struct delay_timer arch_delay_timer;
static void __init arch_timer_delay_timer_register(void)
@ -48,11 +40,5 @@ int __init arch_timer_arch_init(void)
arch_timer_delay_timer_register();
/* Cache the sched_clock multiplier to save a divide in the hot path. */
sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
sched_clock_func = arch_timer_sched_clock;
pr_info("sched_clock: ARM arch timer >56 bits at %ukHz, resolution %uns\n",
arch_timer_rate / 1000, sched_clock_mult);
return 0;
}

57
arch/arm/kernel/devtree.c
View File

@ -174,6 +174,19 @@ bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
return (phys_id & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu);
}
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_phys: physical address of dt blob
@ -183,11 +196,7 @@ bool arch_match_cpu_phys_id(int cpu, u64 phys_id)
*/
const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
{
struct boot_param_header *devtree;
const struct machine_desc *mdesc, *mdesc_best = NULL;
unsigned int score, mdesc_score = ~1;
unsigned long dt_root;
const char *model;
#ifdef CONFIG_ARCH_MULTIPLATFORM
DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
@ -196,32 +205,20 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
mdesc_best = &__mach_desc_GENERIC_DT;
#endif
if (!dt_phys)
if (!dt_phys || !early_init_dt_scan(phys_to_virt(dt_phys)))
return NULL;
devtree = phys_to_virt(dt_phys);
mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
/* check device tree validity */
if (be32_to_cpu(devtree->magic) != OF_DT_HEADER)
return NULL;
/* Search the mdescs for the 'best' compatible value match */
initial_boot_params = devtree;
dt_root = of_get_flat_dt_root();
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) {
if (!mdesc) {
const char *prop;
long size;
unsigned long dt_root;
early_print("\nError: unrecognized/unsupported "
"device tree compatible list:\n[ ");
dt_root = of_get_flat_dt_root();
prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
while (size > 0) {
early_print("'%s' ", prop);
@ -233,22 +230,8 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
dump_machine_table(); /* does not return */
}
model = of_get_flat_dt_prop(dt_root, "model", NULL);
if (!model)
model = of_get_flat_dt_prop(dt_root, "compatible", NULL);
if (!model)
model = "<unknown>";
pr_info("Machine: %s, model: %s\n", mdesc_best->name, model);
/* 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);
/* Change machine number to match the mdesc we're using */
__machine_arch_type = mdesc_best->nr;
__machine_arch_type = mdesc->nr;
return mdesc_best;
return mdesc;
}

1
arch/arm/kernel/setup.c
View File

@ -975,6 +975,7 @@ static const char *hwcap_str[] = {
"idivt",
"vfpd32",
"lpae",
"evtstrm",
NULL
};

5
arch/arm/mach-bcm2835/bcm2835.c
View File

@ -14,7 +14,7 @@
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/irqchip/bcm2835.h>
#include <linux/irqchip.h>
#include <linux/of_address.h>
#include <linux/of_platform.h>
#include <linux/clk/bcm2835.h>
@ -130,8 +130,7 @@ static const char * const bcm2835_compat[] = {
DT_MACHINE_START(BCM2835, "BCM2835")
.map_io = bcm2835_map_io,
.init_irq = bcm2835_init_irq,
.handle_irq = bcm2835_handle_irq,
.init_irq = irqchip_init,
.init_machine = bcm2835_init,
.restart = bcm2835_restart,
.dt_compat = bcm2835_compat

2
arch/arm/mach-gemini/gpio.c
View File

@ -21,9 +21,9 @@
#include <mach/hardware.h>
#include <mach/irqs.h>
#include <mach/gpio.h>
#define GPIO_BASE(x) IO_ADDRESS(GEMINI_GPIO_BASE(x))
#define irq_to_gpio(x) ((x) - GPIO_IRQ_BASE)
/* GPIO registers definition */
#define GPIO_DATA_OUT 0x0

20
arch/arm/mach-gemini/include/mach/gpio.h
View File

@ -1,20 +0,0 @@
/*
* Gemini gpiolib specific defines
*
* Copyright (C) 2008-2009 Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
#ifndef __MACH_GPIO_H__
#define __MACH_GPIO_H__
#include <mach/irqs.h>
#define gpio_to_irq(x) ((x) + GPIO_IRQ_BASE)
#define irq_to_gpio(x) ((x) - GPIO_IRQ_BASE)
#endif /* __MACH_GPIO_H__ */

18
arch/arm/mach-integrator/pci_v3.c
View File

@ -808,22 +808,6 @@ static u8 __init pci_v3_swizzle(struct pci_dev *dev, u8 *pinp)
return pci_common_swizzle(dev, pinp);
}
static int __init pci_v3_map_irq_dt(const struct pci_dev *dev, u8 slot, u8 pin)
{
struct of_irq oirq;
int ret;
ret = of_irq_map_pci(dev, &oirq);
if (ret) {
dev_err(&dev->dev, "of_irq_map_pci() %d\n", ret);
/* Proper return code 0 == NO_IRQ */
return 0;
}
return irq_create_of_mapping(oirq.controller, oirq.specifier,
oirq.size);
}
static struct hw_pci pci_v3 __initdata = {
.swizzle = pci_v3_swizzle,
.setup = pci_v3_setup,
@ -914,7 +898,7 @@ static int __init pci_v3_probe(struct platform_device *pdev)
return -EINVAL;
}
pci_v3.map_irq = pci_v3_map_irq_dt;
pci_v3.map_irq = of_irq_parse_and_map_pci;
pci_common_init_dev(&pdev->dev, &pci_v3);
return 0;

2
arch/arm/mach-iop32x/em7210.c
View File

@ -32,6 +32,7 @@
#include <asm/mach/time.h>
#include <asm/mach-types.h>
#include <mach/time.h>
#include "gpio-iop32x.h"
static void __init em7210_timer_init(void)
{
@ -183,6 +184,7 @@ void em7210_power_off(void)
static void __init em7210_init_machine(void)
{
register_iop32x_gpio();
platform_device_register(&em7210_serial_device);
platform_device_register(&iop3xx_i2c0_device);
platform_device_register(&iop3xx_i2c1_device);

2
arch/arm/mach-iop32x/glantank.c
View File

@ -34,6 +34,7 @@
#include <asm/mach-types.h>
#include <asm/page.h>
#include <mach/time.h>
#include "gpio-iop32x.h"
/*
* GLAN Tank timer tick configuration.
@ -187,6 +188,7 @@ static void glantank_power_off(void)
static void __init glantank_init_machine(void)
{
register_iop32x_gpio();
platform_device_register(&iop3xx_i2c0_device);
platform_device_register(&iop3xx_i2c1_device);
platform_device_register(&glantank_flash_device);

10
arch/arm/mach-iop32x/gpio-iop32x.h Normal file
View File

@ -0,0 +1,10 @@
static struct resource iop32x_gpio_res[] = {
DEFINE_RES_MEM((IOP3XX_PERIPHERAL_PHYS_BASE + 0x07c4), 0x10),
};
static inline void register_iop32x_gpio(void)
{
platform_device_register_simple("gpio-iop", 0,
iop32x_gpio_res,
ARRAY_SIZE(iop32x_gpio_res));
}

6
arch/arm/mach-iop32x/include/mach/gpio.h
View File

@ -1,6 +0,0 @@
#ifndef __ASM_ARCH_IOP32X_GPIO_H
#define __ASM_ARCH_IOP32X_GPIO_H
#include <asm/hardware/iop3xx-gpio.h>
#endif

1
arch/arm/mach-iop32x/include/mach/iop32x.h
View File

@ -19,7 +19,6 @@
* Peripherals that are shared between the iop32x and iop33x but
* located at different addresses.
*/
#define IOP3XX_GPIO_REG(reg) (IOP3XX_PERIPHERAL_VIRT_BASE + 0x07c4 + (reg))
#define IOP3XX_TIMER_REG(reg) (IOP3XX_PERIPHERAL_VIRT_BASE + 0x07e0 + (reg))
#include <asm/hardware/iop3xx.h>

2
arch/arm/mach-iop32x/iq31244.c
View File

@ -37,6 +37,7 @@
#include <asm/page.h>
#include <asm/pgtable.h>
#include <mach/time.h>
#include "gpio-iop32x.h"
/*
* Until March of 2007 iq31244 platforms and ep80219 platforms shared the
@ -283,6 +284,7 @@ void ep80219_power_off(void)
static void __init iq31244_init_machine(void)
{
register_iop32x_gpio();
platform_device_register(&iop3xx_i2c0_device);
platform_device_register(&iop3xx_i2c1_device);
platform_device_register(&iq31244_flash_device);

2
arch/arm/mach-iop32x/iq80321.c
View File

@ -33,6 +33,7 @@
#include <asm/page.h>
#include <asm/pgtable.h>
#include <mach/time.h>
#include "gpio-iop32x.h"
/*
* IQ80321 timer tick configuration.
@ -170,6 +171,7 @@ static struct platform_device iq80321_serial_device = {
static void __init iq80321_init_machine(void)
{
register_iop32x_gpio();
platform_device_register(&iop3xx_i2c0_device);
platform_device_register(&iop3xx_i2c1_device);
platform_device_register(&iq80321_flash_device);

47
arch/arm/mach-iop32x/n2100.c
View File

@ -30,6 +30,7 @@
#include <linux/platform_device.h>
#include <linux/reboot.h>
#include <linux/io.h>
#include <linux/gpio.h>
#include <mach/hardware.h>
#include <asm/irq.h>
#include <asm/mach/arch.h>
@ -40,6 +41,7 @@
#include <asm/page.h>
#include <asm/pgtable.h>
#include <mach/time.h>
#include "gpio-iop32x.h"
/*
* N2100 timer tick configuration.
@ -288,8 +290,14 @@ static void n2100_power_off(void)
static void n2100_restart(enum reboot_mode mode, const char *cmd)
{
gpio_line_set(N2100_HARDWARE_RESET, GPIO_LOW);
gpio_line_config(N2100_HARDWARE_RESET, GPIO_OUT);
int ret;
ret = gpio_direction_output(N2100_HARDWARE_RESET, 0);
if (ret) {
pr_crit("could not drive reset GPIO low\n");
return;
}
/* Wait for reset to happen */
while (1)
;
}
@ -299,7 +307,7 @@ static struct timer_list power_button_poll_timer;
static void power_button_poll(unsigned long dummy)
{
if (gpio_line_get(N2100_POWER_BUTTON) == 0) {
if (gpio_get_value(N2100_POWER_BUTTON) == 0) {
ctrl_alt_del();
return;
}
@ -308,9 +316,37 @@ static void power_button_poll(unsigned long dummy)
add_timer(&power_button_poll_timer);
}
static int __init n2100_request_gpios(void)
{
int ret;
if (!machine_is_n2100())
return 0;
ret = gpio_request(N2100_HARDWARE_RESET, "reset");
if (ret)
pr_err("could not request reset GPIO\n");
ret = gpio_request(N2100_POWER_BUTTON, "power");
if (ret)
pr_err("could not request power GPIO\n");
else {
ret = gpio_direction_input(N2100_POWER_BUTTON);
if (ret)
pr_err("could not set power GPIO as input\n");
}
/* Set up power button poll timer */
init_timer(&power_button_poll_timer);
power_button_poll_timer.function = power_button_poll;
power_button_poll_timer.expires = jiffies + (HZ / 10);
add_timer(&power_button_poll_timer);
return 0;
}
device_initcall(n2100_request_gpios);
static void __init n2100_init_machine(void)
{
register_iop32x_gpio();
platform_device_register(&iop3xx_i2c0_device);
platform_device_register(&n2100_flash_device);
platform_device_register(&n2100_serial_device);
@ -321,11 +357,6 @@ static void __init n2100_init_machine(void)
ARRAY_SIZE(n2100_i2c_devices));
pm_power_off = n2100_power_off;
init_timer(&power_button_poll_timer);
power_button_poll_timer.function = power_button_poll;
power_button_poll_timer.expires = jiffies + (HZ / 10);
add_timer(&power_button_poll_timer);
}
MACHINE_START(N2100, "Thecus N2100")

6
arch/arm/mach-iop33x/include/mach/gpio.h
View File

@ -1,6 +0,0 @@
#ifndef __ASM_ARCH_IOP33X_GPIO_H
#define __ASM_ARCH_IOP33X_GPIO_H
#include <asm/hardware/iop3xx-gpio.h>
#endif

1
arch/arm/mach-iop33x/include/mach/iop33x.h
View File

@ -18,7 +18,6 @@
* Peripherals that are shared between the iop32x and iop33x but
* located at different addresses.
*/
#define IOP3XX_GPIO_REG(reg) (IOP3XX_PERIPHERAL_VIRT_BASE + 0x1780 + (reg))
#define IOP3XX_TIMER_REG(reg) (IOP3XX_PERIPHERAL_VIRT_BASE + 0x07d0 + (reg))
#include <asm/hardware/iop3xx.h>

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