forked from Minki/linux
Merge branch 'x86/vt-d' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu into x86/apic-picks
Required to apply Jiangs x86 irq handling rework without creating a nightmare of conflicts. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This commit is contained in:
commit
8ab7913675
@ -55,12 +55,12 @@ Description: Interface for making ib_srp connect to a new target.
|
||||
only safe with partial memory descriptor list support enabled
|
||||
(allow_ext_sg=1).
|
||||
* comp_vector, a number in the range 0..n-1 specifying the
|
||||
MSI-X completion vector. Some HCA's allocate multiple (n)
|
||||
MSI-X vectors per HCA port. If the IRQ affinity masks of
|
||||
these interrupts have been configured such that each MSI-X
|
||||
interrupt is handled by a different CPU then the comp_vector
|
||||
parameter can be used to spread the SRP completion workload
|
||||
over multiple CPU's.
|
||||
MSI-X completion vector of the first RDMA channel. Some
|
||||
HCA's allocate multiple (n) MSI-X vectors per HCA port. If
|
||||
the IRQ affinity masks of these interrupts have been
|
||||
configured such that each MSI-X interrupt is handled by a
|
||||
different CPU then the comp_vector parameter can be used to
|
||||
spread the SRP completion workload over multiple CPU's.
|
||||
* tl_retry_count, a number in the range 2..7 specifying the
|
||||
IB RC retry count.
|
||||
* queue_size, the maximum number of commands that the
|
||||
@ -88,6 +88,13 @@ Description: Whether ib_srp is allowed to include a partial memory
|
||||
descriptor list in an SRP_CMD when communicating with an SRP
|
||||
target.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/ch_count
|
||||
Date: April 1, 2015
|
||||
KernelVersion: 3.19
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Number of RDMA channels used for communication with the SRP
|
||||
target.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/cmd_sg_entries
|
||||
Date: May 19, 2011
|
||||
KernelVersion: 2.6.39
|
||||
@ -95,6 +102,12 @@ Contact: linux-rdma@vger.kernel.org
|
||||
Description: Maximum number of data buffer descriptors that may be sent to
|
||||
the target in a single SRP_CMD request.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/comp_vector
|
||||
Date: September 2, 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: linux-rdma@vger.kernel.org
|
||||
Description: Completion vector used for the first RDMA channel.
|
||||
|
||||
What: /sys/class/scsi_host/host<n>/dgid
|
||||
Date: June 17, 2006
|
||||
KernelVersion: 2.6.17
|
||||
|
@ -151,3 +151,74 @@ used and no descriptor gets allocated it is very important to make sure
|
||||
that the driver using the simple domain call irq_create_mapping()
|
||||
before any irq_find_mapping() since the latter will actually work
|
||||
for the static IRQ assignment case.
|
||||
|
||||
==== Hierarchy IRQ domain ====
|
||||
On some architectures, there may be multiple interrupt controllers
|
||||
involved in delivering an interrupt from the device to the target CPU.
|
||||
Let's look at a typical interrupt delivering path on x86 platforms:
|
||||
|
||||
Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU
|
||||
|
||||
There are three interrupt controllers involved:
|
||||
1) IOAPIC controller
|
||||
2) Interrupt remapping controller
|
||||
3) Local APIC controller
|
||||
|
||||
To support such a hardware topology and make software architecture match
|
||||
hardware architecture, an irq_domain data structure is built for each
|
||||
interrupt controller and those irq_domains are organized into hierarchy.
|
||||
When building irq_domain hierarchy, the irq_domain near to the device is
|
||||
child and the irq_domain near to CPU is parent. So a hierarchy structure
|
||||
as below will be built for the example above.
|
||||
CPU Vector irq_domain (root irq_domain to manage CPU vectors)
|
||||
^
|
||||
|
|
||||
Interrupt Remapping irq_domain (manage irq_remapping entries)
|
||||
^
|
||||
|
|
||||
IOAPIC irq_domain (manage IOAPIC delivery entries/pins)
|
||||
|
||||
There are four major interfaces to use hierarchy irq_domain:
|
||||
1) irq_domain_alloc_irqs(): allocate IRQ descriptors and interrupt
|
||||
controller related resources to deliver these interrupts.
|
||||
2) irq_domain_free_irqs(): free IRQ descriptors and interrupt controller
|
||||
related resources associated with these interrupts.
|
||||
3) irq_domain_activate_irq(): activate interrupt controller hardware to
|
||||
deliver the interrupt.
|
||||
3) irq_domain_deactivate_irq(): deactivate interrupt controller hardware
|
||||
to stop delivering the interrupt.
|
||||
|
||||
Following changes are needed to support hierarchy irq_domain.
|
||||
1) a new field 'parent' is added to struct irq_domain; it's used to
|
||||
maintain irq_domain hierarchy information.
|
||||
2) a new field 'parent_data' is added to struct irq_data; it's used to
|
||||
build hierarchy irq_data to match hierarchy irq_domains. The irq_data
|
||||
is used to store irq_domain pointer and hardware irq number.
|
||||
3) new callbacks are added to struct irq_domain_ops to support hierarchy
|
||||
irq_domain operations.
|
||||
|
||||
With support of hierarchy irq_domain and hierarchy irq_data ready, an
|
||||
irq_domain structure is built for each interrupt controller, and an
|
||||
irq_data structure is allocated for each irq_domain associated with an
|
||||
IRQ. Now we could go one step further to support stacked(hierarchy)
|
||||
irq_chip. That is, an irq_chip is associated with each irq_data along
|
||||
the hierarchy. A child irq_chip may implement a required action by
|
||||
itself or by cooperating with its parent irq_chip.
|
||||
|
||||
With stacked irq_chip, interrupt controller driver only needs to deal
|
||||
with the hardware managed by itself and may ask for services from its
|
||||
parent irq_chip when needed. So we could achieve a much cleaner
|
||||
software architecture.
|
||||
|
||||
For an interrupt controller driver to support hierarchy irq_domain, it
|
||||
needs to:
|
||||
1) Implement irq_domain_ops.alloc and irq_domain_ops.free
|
||||
2) Optionally implement irq_domain_ops.activate and
|
||||
irq_domain_ops.deactivate.
|
||||
3) Optionally implement an irq_chip to manage the interrupt controller
|
||||
hardware.
|
||||
4) No need to implement irq_domain_ops.map and irq_domain_ops.unmap,
|
||||
they are unused with hierarchy irq_domain.
|
||||
|
||||
Hierarchy irq_domain may also be used to support other architectures,
|
||||
such as ARM, ARM64 etc.
|
||||
|
@ -36,7 +36,7 @@ o How can the updater tell when a grace period has completed
|
||||
executed in user mode, or executed in the idle loop, we can
|
||||
safely free up that item.
|
||||
|
||||
Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the
|
||||
Preemptible variants of RCU (CONFIG_PREEMPT_RCU) get the
|
||||
same effect, but require that the readers manipulate CPU-local
|
||||
counters. These counters allow limited types of blocking within
|
||||
RCU read-side critical sections. SRCU also uses CPU-local
|
||||
@ -81,7 +81,7 @@ o I hear that RCU is patented? What is with that?
|
||||
o I hear that RCU needs work in order to support realtime kernels?
|
||||
|
||||
This work is largely completed. Realtime-friendly RCU can be
|
||||
enabled via the CONFIG_TREE_PREEMPT_RCU kernel configuration
|
||||
enabled via the CONFIG_PREEMPT_RCU kernel configuration
|
||||
parameter. However, work is in progress for enabling priority
|
||||
boosting of preempted RCU read-side critical sections. This is
|
||||
needed if you have CPU-bound realtime threads.
|
||||
|
@ -26,12 +26,6 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
|
||||
Stall-warning messages may be enabled and disabled completely via
|
||||
/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress.
|
||||
|
||||
CONFIG_RCU_CPU_STALL_VERBOSE
|
||||
|
||||
This kernel configuration parameter causes the stall warning to
|
||||
also dump the stacks of any tasks that are blocking the current
|
||||
RCU-preempt grace period.
|
||||
|
||||
CONFIG_RCU_CPU_STALL_INFO
|
||||
|
||||
This kernel configuration parameter causes the stall warning to
|
||||
@ -77,7 +71,7 @@ This message indicates that CPU 5 detected that it was causing a stall,
|
||||
and that the stall was affecting RCU-sched. This message will normally be
|
||||
followed by a stack dump of the offending CPU. On TREE_RCU kernel builds,
|
||||
RCU and RCU-sched are implemented by the same underlying mechanism,
|
||||
while on TREE_PREEMPT_RCU kernel builds, RCU is instead implemented
|
||||
while on PREEMPT_RCU kernel builds, RCU is instead implemented
|
||||
by rcu_preempt_state.
|
||||
|
||||
On the other hand, if the offending CPU fails to print out a stall-warning
|
||||
@ -89,7 +83,7 @@ INFO: rcu_bh_state detected stalls on CPUs/tasks: { 3 5 } (detected by 2, 2502 j
|
||||
This message indicates that CPU 2 detected that CPUs 3 and 5 were both
|
||||
causing stalls, and that the stall was affecting RCU-bh. This message
|
||||
will normally be followed by stack dumps for each CPU. Please note that
|
||||
TREE_PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,
|
||||
PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,
|
||||
and that the tasks will be indicated by PID, for example, "P3421".
|
||||
It is even possible for a rcu_preempt_state stall to be caused by both
|
||||
CPUs -and- tasks, in which case the offending CPUs and tasks will all
|
||||
@ -205,10 +199,10 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
|
||||
o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
|
||||
is running at a higher priority than the RCU softirq threads.
|
||||
This will prevent RCU callbacks from ever being invoked,
|
||||
and in a CONFIG_TREE_PREEMPT_RCU kernel will further prevent
|
||||
and in a CONFIG_PREEMPT_RCU kernel will further prevent
|
||||
RCU grace periods from ever completing. Either way, the
|
||||
system will eventually run out of memory and hang. In the
|
||||
CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning
|
||||
CONFIG_PREEMPT_RCU case, you might see stall-warning
|
||||
messages.
|
||||
|
||||
o A hardware or software issue shuts off the scheduler-clock
|
||||
|
@ -8,7 +8,7 @@ The following sections describe the debugfs files and formats, first
|
||||
for rcutree and next for rcutiny.
|
||||
|
||||
|
||||
CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats
|
||||
CONFIG_TREE_RCU and CONFIG_PREEMPT_RCU debugfs Files and Formats
|
||||
|
||||
These implementations of RCU provide several debugfs directories under the
|
||||
top-level directory "rcu":
|
||||
@ -18,7 +18,7 @@ rcu/rcu_preempt
|
||||
rcu/rcu_sched
|
||||
|
||||
Each directory contains files for the corresponding flavor of RCU.
|
||||
Note that rcu/rcu_preempt is only present for CONFIG_TREE_PREEMPT_RCU.
|
||||
Note that rcu/rcu_preempt is only present for CONFIG_PREEMPT_RCU.
|
||||
For CONFIG_TREE_RCU, the RCU flavor maps onto the RCU-sched flavor,
|
||||
so that activity for both appears in rcu/rcu_sched.
|
||||
|
||||
|
@ -137,7 +137,7 @@ rcu_read_lock()
|
||||
Used by a reader to inform the reclaimer that the reader is
|
||||
entering an RCU read-side critical section. It is illegal
|
||||
to block while in an RCU read-side critical section, though
|
||||
kernels built with CONFIG_TREE_PREEMPT_RCU can preempt RCU
|
||||
kernels built with CONFIG_PREEMPT_RCU can preempt RCU
|
||||
read-side critical sections. Any RCU-protected data structure
|
||||
accessed during an RCU read-side critical section is guaranteed to
|
||||
remain unreclaimed for the full duration of that critical section.
|
||||
|
@ -7,32 +7,14 @@ world, which changes the way some things have to be initialized. This makes
|
||||
a need to provide an interface for such platforms to specify available firmware
|
||||
operations and call them when needed.
|
||||
|
||||
Firmware operations can be specified using struct firmware_ops
|
||||
|
||||
struct firmware_ops {
|
||||
/*
|
||||
* Enters CPU idle mode
|
||||
*/
|
||||
int (*do_idle)(void);
|
||||
/*
|
||||
* Sets boot address of specified physical CPU
|
||||
*/
|
||||
int (*set_cpu_boot_addr)(int cpu, unsigned long boot_addr);
|
||||
/*
|
||||
* Boots specified physical CPU
|
||||
*/
|
||||
int (*cpu_boot)(int cpu);
|
||||
/*
|
||||
* Initializes L2 cache
|
||||
*/
|
||||
int (*l2x0_init)(void);
|
||||
};
|
||||
|
||||
and then registered with register_firmware_ops function
|
||||
Firmware operations can be specified by filling in a struct firmware_ops
|
||||
with appropriate callbacks and then registering it with register_firmware_ops()
|
||||
function.
|
||||
|
||||
void register_firmware_ops(const struct firmware_ops *ops)
|
||||
|
||||
the ops pointer must be non-NULL.
|
||||
The ops pointer must be non-NULL. More information about struct firmware_ops
|
||||
and its members can be found in arch/arm/include/asm/firmware.h header.
|
||||
|
||||
There is a default, empty set of operations provided, so there is no need to
|
||||
set anything if platform does not require firmware operations.
|
||||
|
@ -37,16 +37,26 @@ SunXi family
|
||||
http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
|
||||
|
||||
- Allwinner A23
|
||||
+ Not Supported
|
||||
+ Datasheet
|
||||
http://dl.linux-sunxi.org/A23/A23%20Datasheet%20V1.0%2020130830.pdf
|
||||
+ User Manual
|
||||
http://dl.linux-sunxi.org/A23/A23%20User%20Manual%20V1.0%2020130830.pdf
|
||||
|
||||
* Quad ARM Cortex-A7 based SoCs
|
||||
- Allwinner A31 (sun6i)
|
||||
+ Datasheet
|
||||
http://dl.linux-sunxi.org/A31/A31%20Datasheet%20-%20v1.00%20(2012-12-24).pdf
|
||||
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20datasheet%20V1.3%2020131106.pdf
|
||||
+ User Manual
|
||||
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20user%20manual%20V1.1%2020130630.pdf
|
||||
|
||||
- Allwinner A31s (sun6i)
|
||||
+ Not Supported
|
||||
+ Datasheet
|
||||
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20datasheet%20V1.3%2020131106.pdf
|
||||
+ User Manual
|
||||
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20User%20Manual%20%20V1.0%2020130322.pdf
|
||||
|
||||
* Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
|
||||
- Allwinner A80
|
||||
+ Not Supported
|
||||
+ Datasheet
|
||||
http://dl.linux-sunxi.org/A80/A80_Datasheet_Revision_1.0_0404.pdf
|
||||
|
45
Documentation/arm64/legacy_instructions.txt
Normal file
45
Documentation/arm64/legacy_instructions.txt
Normal file
@ -0,0 +1,45 @@
|
||||
The arm64 port of the Linux kernel provides infrastructure to support
|
||||
emulation of instructions which have been deprecated, or obsoleted in
|
||||
the architecture. The infrastructure code uses undefined instruction
|
||||
hooks to support emulation. Where available it also allows turning on
|
||||
the instruction execution in hardware.
|
||||
|
||||
The emulation mode can be controlled by writing to sysctl nodes
|
||||
(/proc/sys/abi). The following explains the different execution
|
||||
behaviours and the corresponding values of the sysctl nodes -
|
||||
|
||||
* Undef
|
||||
Value: 0
|
||||
Generates undefined instruction abort. Default for instructions that
|
||||
have been obsoleted in the architecture, e.g., SWP
|
||||
|
||||
* Emulate
|
||||
Value: 1
|
||||
Uses software emulation. To aid migration of software, in this mode
|
||||
usage of emulated instruction is traced as well as rate limited
|
||||
warnings are issued. This is the default for deprecated
|
||||
instructions, .e.g., CP15 barriers
|
||||
|
||||
* Hardware Execution
|
||||
Value: 2
|
||||
Although marked as deprecated, some implementations may support the
|
||||
enabling/disabling of hardware support for the execution of these
|
||||
instructions. Using hardware execution generally provides better
|
||||
performance, but at the loss of ability to gather runtime statistics
|
||||
about the use of the deprecated instructions.
|
||||
|
||||
The default mode depends on the status of the instruction in the
|
||||
architecture. Deprecated instructions should default to emulation
|
||||
while obsolete instructions must be undefined by default.
|
||||
|
||||
Supported legacy instructions
|
||||
-----------------------------
|
||||
* SWP{B}
|
||||
Node: /proc/sys/abi/swp
|
||||
Status: Obsolete
|
||||
Default: Undef (0)
|
||||
|
||||
* CP15 Barriers
|
||||
Node: /proc/sys/abi/cp15_barrier
|
||||
Status: Deprecated
|
||||
Default: Emulate (1)
|
@ -7,12 +7,13 @@
|
||||
maintainers on how to implement atomic counter, bitops, and spinlock
|
||||
interfaces properly.
|
||||
|
||||
The atomic_t type should be defined as a signed integer.
|
||||
Also, it should be made opaque such that any kind of cast to a normal
|
||||
C integer type will fail. Something like the following should
|
||||
suffice:
|
||||
The atomic_t type should be defined as a signed integer and
|
||||
the atomic_long_t type as a signed long integer. Also, they should
|
||||
be made opaque such that any kind of cast to a normal C integer type
|
||||
will fail. Something like the following should suffice:
|
||||
|
||||
typedef struct { int counter; } atomic_t;
|
||||
typedef struct { long counter; } atomic_long_t;
|
||||
|
||||
Historically, counter has been declared volatile. This is now discouraged.
|
||||
See Documentation/volatile-considered-harmful.txt for the complete rationale.
|
||||
@ -37,6 +38,9 @@ initializer is used before runtime. If the initializer is used at runtime, a
|
||||
proper implicit or explicit read memory barrier is needed before reading the
|
||||
value with atomic_read from another thread.
|
||||
|
||||
As with all of the atomic_ interfaces, replace the leading "atomic_"
|
||||
with "atomic_long_" to operate on atomic_long_t.
|
||||
|
||||
The second interface can be used at runtime, as in:
|
||||
|
||||
struct foo { atomic_t counter; };
|
||||
|
@ -827,10 +827,6 @@ but in the event of any barrier requests in the tag queue we need to ensure
|
||||
that requests are restarted in the order they were queue. This may happen
|
||||
if the driver needs to use blk_queue_invalidate_tags().
|
||||
|
||||
Tagging also defines a new request flag, REQ_QUEUED. This is set whenever
|
||||
a request is currently tagged. You should not use this flag directly,
|
||||
blk_rq_tagged(rq) is the portable way to do so.
|
||||
|
||||
3.3 I/O Submission
|
||||
|
||||
The routine submit_bio() is used to submit a single io. Higher level i/o
|
||||
|
@ -47,20 +47,26 @@ Message and constructor argument pairs are:
|
||||
'discard_promote_adjustment <value>'
|
||||
|
||||
The sequential threshold indicates the number of contiguous I/Os
|
||||
required before a stream is treated as sequential. The random threshold
|
||||
required before a stream is treated as sequential. Once a stream is
|
||||
considered sequential it will bypass the cache. The random threshold
|
||||
is the number of intervening non-contiguous I/Os that must be seen
|
||||
before the stream is treated as random again.
|
||||
|
||||
The sequential and random thresholds default to 512 and 4 respectively.
|
||||
|
||||
Large, sequential ios are probably better left on the origin device
|
||||
since spindles tend to have good bandwidth. The io_tracker counts
|
||||
contiguous I/Os to try to spot when the io is in one of these sequential
|
||||
modes.
|
||||
Large, sequential I/Os are probably better left on the origin device
|
||||
since spindles tend to have good sequential I/O bandwidth. The
|
||||
io_tracker counts contiguous I/Os to try to spot when the I/O is in one
|
||||
of these sequential modes. But there are use-cases for wanting to
|
||||
promote sequential blocks to the cache (e.g. fast application startup).
|
||||
If sequential threshold is set to 0 the sequential I/O detection is
|
||||
disabled and sequential I/O will no longer implicitly bypass the cache.
|
||||
Setting the random threshold to 0 does _not_ disable the random I/O
|
||||
stream detection.
|
||||
|
||||
Internally the mq policy maintains a promotion threshold variable. If
|
||||
the hit count of a block not in the cache goes above this threshold it
|
||||
gets promoted to the cache. The read, write and discard promote adjustment
|
||||
Internally the mq policy determines a promotion threshold. If the hit
|
||||
count of a block not in the cache goes above this threshold it gets
|
||||
promoted to the cache. The read, write and discard promote adjustment
|
||||
tunables allow you to tweak the promotion threshold by adding a small
|
||||
value based on the io type. They default to 4, 8 and 1 respectively.
|
||||
If you're trying to quickly warm a new cache device you may wish to
|
||||
|
@ -2,7 +2,9 @@ Amlogic MesonX device tree bindings
|
||||
-------------------------------------------
|
||||
|
||||
Boards with the Amlogic Meson6 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,meson6"
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible = "amlogic,meson6";
|
||||
Boards with the Amlogic Meson8 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,meson8";
|
||||
|
@ -22,6 +22,14 @@ to deliver its interrupts via SPIs.
|
||||
- always-on : a boolean property. If present, the timer is powered through an
|
||||
always-on power domain, therefore it never loses context.
|
||||
|
||||
** Optional properties:
|
||||
|
||||
- arm,cpu-registers-not-fw-configured : Firmware does not initialize
|
||||
any of the generic timer CPU registers, which contain their
|
||||
architecturally-defined reset values. Only supported for 32-bit
|
||||
systems which follow the ARMv7 architected reset values.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
timer {
|
||||
|
@ -92,3 +92,68 @@ Required nodes:
|
||||
- core-module: the root node to the Versatile platforms must have
|
||||
a core-module with regs and the compatible strings
|
||||
"arm,core-module-versatile", "syscon"
|
||||
|
||||
ARM RealView Boards
|
||||
-------------------
|
||||
The RealView boards cover tailored evaluation boards that are used to explore
|
||||
the ARM11 and Cortex A-8 and Cortex A-9 processors.
|
||||
|
||||
Required properties (in root node):
|
||||
/* RealView Emulation Baseboard */
|
||||
compatible = "arm,realview-eb";
|
||||
/* RealView Platform Baseboard for ARM1176JZF-S */
|
||||
compatible = "arm,realview-pb1176";
|
||||
/* RealView Platform Baseboard for ARM11 MPCore */
|
||||
compatible = "arm,realview-pb11mp";
|
||||
/* RealView Platform Baseboard for Cortex A-8 */
|
||||
compatible = "arm,realview-pba8";
|
||||
/* RealView Platform Baseboard Explore for Cortex A-9 */
|
||||
compatible = "arm,realview-pbx";
|
||||
|
||||
Required nodes:
|
||||
|
||||
- soc: some node of the RealView platforms must be the SoC
|
||||
node that contain the SoC-specific devices, withe the compatible
|
||||
string set to one of these tuples:
|
||||
"arm,realview-eb-soc", "simple-bus"
|
||||
"arm,realview-pb1176-soc", "simple-bus"
|
||||
"arm,realview-pb11mp-soc", "simple-bus"
|
||||
"arm,realview-pba8-soc", "simple-bus"
|
||||
"arm,realview-pbx-soc", "simple-bus"
|
||||
|
||||
- syscon: some subnode of the RealView SoC node must be a
|
||||
system controller node pointing to the control registers,
|
||||
with the compatible string set to one of these tuples:
|
||||
"arm,realview-eb-syscon", "syscon"
|
||||
"arm,realview-pb1176-syscon", "syscon"
|
||||
"arm,realview-pb11mp-syscon", "syscon"
|
||||
"arm,realview-pba8-syscon", "syscon"
|
||||
"arm,realview-pbx-syscon", "syscon"
|
||||
|
||||
Required properties for the system controller:
|
||||
- regs: the location and size of the system controller registers,
|
||||
one range of 0x1000 bytes.
|
||||
|
||||
Example:
|
||||
|
||||
/dts-v1/;
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include "skeleton.dtsi"
|
||||
|
||||
/ {
|
||||
model = "ARM RealView PB1176 with device tree";
|
||||
compatible = "arm,realview-pb1176";
|
||||
|
||||
soc {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "arm,realview-pb1176-soc", "simple-bus";
|
||||
ranges;
|
||||
|
||||
syscon: syscon@10000000 {
|
||||
compatible = "arm,realview-syscon", "syscon";
|
||||
reg = <0x10000000 0x1000>;
|
||||
};
|
||||
|
||||
};
|
||||
};
|
||||
|
31
Documentation/devicetree/bindings/arm/bcm/cygnus.txt
Normal file
31
Documentation/devicetree/bindings/arm/bcm/cygnus.txt
Normal file
@ -0,0 +1,31 @@
|
||||
Broadcom Cygnus device tree bindings
|
||||
------------------------------------
|
||||
|
||||
|
||||
Boards with Cygnus SoCs shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
BCM11300
|
||||
compatible = "brcm,bcm11300", "brcm,cygnus";
|
||||
|
||||
BCM11320
|
||||
compatible = "brcm,bcm11320", "brcm,cygnus";
|
||||
|
||||
BCM11350
|
||||
compatible = "brcm,bcm11350", "brcm,cygnus";
|
||||
|
||||
BCM11360
|
||||
compatible = "brcm,bcm11360", "brcm,cygnus";
|
||||
|
||||
BCM58300
|
||||
compatible = "brcm,bcm58300", "brcm,cygnus";
|
||||
|
||||
BCM58302
|
||||
compatible = "brcm,bcm58302", "brcm,cygnus";
|
||||
|
||||
BCM58303
|
||||
compatible = "brcm,bcm58303", "brcm,cygnus";
|
||||
|
||||
BCM58305
|
||||
compatible = "brcm,bcm58305", "brcm,cygnus";
|
@ -227,6 +227,15 @@ nodes to be present and contain the properties described below.
|
||||
# List of phandles to idle state nodes supported
|
||||
by this cpu [3].
|
||||
|
||||
- rockchip,pmu
|
||||
Usage: optional for systems that have an "enable-method"
|
||||
property value of "rockchip,rk3066-smp"
|
||||
While optional, it is the preferred way to get access to
|
||||
the cpu-core power-domains.
|
||||
Value type: <phandle>
|
||||
Definition: Specifies the syscon node controlling the cpu core
|
||||
power domains.
|
||||
|
||||
Example 1 (dual-cluster big.LITTLE system 32-bit):
|
||||
|
||||
cpus {
|
||||
|
@ -74,3 +74,41 @@ Required root node properties:
|
||||
i.MX6q generic board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6q";
|
||||
|
||||
|
||||
Freescale LS1021A Platform Device Tree Bindings
|
||||
------------------------------------------------
|
||||
|
||||
Required root node compatible properties:
|
||||
- compatible = "fsl,ls1021a";
|
||||
|
||||
Freescale LS1021A SoC-specific Device Tree Bindings
|
||||
-------------------------------------------
|
||||
|
||||
Freescale SCFG
|
||||
SCFG is the supplemental configuration unit, that provides SoC specific
|
||||
configuration and status registers for the chip. Such as getting PEX port
|
||||
status.
|
||||
Required properties:
|
||||
- compatible: should be "fsl,ls1021a-scfg"
|
||||
- reg: should contain base address and length of SCFG memory-mapped registers
|
||||
|
||||
Example:
|
||||
scfg: scfg@1570000 {
|
||||
compatible = "fsl,ls1021a-scfg";
|
||||
reg = <0x0 0x1570000 0x0 0x10000>;
|
||||
};
|
||||
|
||||
Freescale DCFG
|
||||
DCFG is the device configuration unit, that provides general purpose
|
||||
configuration and status for the device. Such as setting the secondary
|
||||
core start address and release the secondary core from holdoff and startup.
|
||||
Required properties:
|
||||
- compatible: should be "fsl,ls1021a-dcfg"
|
||||
- reg : should contain base address and length of DCFG memory-mapped registers
|
||||
|
||||
Example:
|
||||
dcfg: dcfg@1ee0000 {
|
||||
compatible = "fsl,ls1021a-dcfg";
|
||||
reg = <0x0 0x1ee0000 0x0 0x10000>;
|
||||
};
|
||||
|
@ -17,6 +17,7 @@ Main node required properties:
|
||||
"arm,cortex-a7-gic"
|
||||
"arm,arm11mp-gic"
|
||||
"brcm,brahma-b15-gic"
|
||||
"arm,arm1176jzf-devchip-gic"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
interrupt source. The type shall be a <u32> and the value shall be 3.
|
||||
|
@ -106,11 +106,21 @@ Required subnode-properties:
|
||||
- groups: a list of strings describing the group names.
|
||||
- function: a string describing the function used to mux the groups.
|
||||
|
||||
* Reset controller binding
|
||||
|
||||
A reset controller is part of the chip control registers set. The chip control
|
||||
node also provides the reset. The register set is not at the same offset between
|
||||
Berlin SoCs.
|
||||
|
||||
Required property:
|
||||
- #reset-cells: must be set to 2
|
||||
|
||||
Example:
|
||||
|
||||
chip: chip-control@ea0000 {
|
||||
compatible = "marvell,berlin2-chip-ctrl";
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <2>;
|
||||
reg = <0xea0000 0x400>;
|
||||
clocks = <&refclk>, <&externaldev 0>;
|
||||
clock-names = "refclk", "video_ext0";
|
||||
|
@ -1,10 +1,14 @@
|
||||
Mediatek MT6589 Platforms Device Tree Bindings
|
||||
MediaTek mt65xx & mt81xx Platforms Device Tree Bindings
|
||||
|
||||
Boards with a SoC of the Mediatek MT6589 shall have the following property:
|
||||
Boards with a MediaTek mt65xx/mt81xx SoC shall have the following property:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible: must contain "mediatek,mt6589"
|
||||
compatible: Must contain one of
|
||||
"mediatek,mt6589"
|
||||
"mediatek,mt6592"
|
||||
"mediatek,mt8127"
|
||||
"mediatek,mt8135"
|
||||
|
||||
|
||||
Supported boards:
|
||||
@ -12,3 +16,12 @@ Supported boards:
|
||||
- bq Aquaris5 smart phone:
|
||||
Required root node properties:
|
||||
- compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
|
||||
- Evaluation board for MT6592:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
|
||||
- MTK mt8127 tablet moose EVB:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
|
||||
- MTK mt8135 tablet EVB:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt8135-evbp1", "mediatek,mt8135";
|
||||
|
@ -132,6 +132,9 @@ Boards:
|
||||
- AM335X Bone : Low cost community board
|
||||
compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
|
||||
|
||||
- AM335X OrionLXm : Substation Automation Platform
|
||||
compatible = "novatech,am335x-lxm", "ti,am33xx"
|
||||
|
||||
- OMAP5 EVM : Evaluation Module
|
||||
compatible = "ti,omap5-evm", "ti,omap5"
|
||||
|
||||
|
@ -1,6 +1,10 @@
|
||||
Rockchip platforms device tree bindings
|
||||
---------------------------------------
|
||||
|
||||
- MarsBoard RK3066 board:
|
||||
Required root node properties:
|
||||
- compatible = "haoyu,marsboard-rk3066", "rockchip,rk3066a";
|
||||
|
||||
- bq Curie 2 tablet:
|
||||
Required root node properties:
|
||||
- compatible = "mundoreader,bq-curie2", "rockchip,rk3066a";
|
||||
|
@ -1,11 +1,20 @@
|
||||
* Samsung's Exynos4210 based SMDKV310 evaluation board
|
||||
|
||||
SMDKV310 evaluation board is based on Samsung's Exynos4210 SoC.
|
||||
* Samsung's Exynos SoC based boards
|
||||
|
||||
Required root node properties:
|
||||
- compatible = should be one or more of the following.
|
||||
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
|
||||
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
|
||||
- "samsung,monk" - for Exynos3250-based Samsung Simband board.
|
||||
- "samsung,rinato" - for Exynos3250-based Samsung Gear2 board.
|
||||
- "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board.
|
||||
- "samsung,trats" - for Exynos4210-based Tizen Reference board.
|
||||
- "samsung,universal_c210" - for Exynos4210-based Samsung board.
|
||||
- "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board.
|
||||
- "samsung,trats2" - for Exynos4412-based Tizen Reference board.
|
||||
- "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board.
|
||||
- "samsung,xyref5260" - for Exynos5260-based Samsung board.
|
||||
- "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board.
|
||||
- "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board.
|
||||
- "samsung,sd5v1" - for Exynos5440-based Samsung board.
|
||||
- "samsung,ssdk5440" - for Exynos5440-based Samsung board.
|
||||
|
||||
Optional:
|
||||
- firmware node, specifying presence and type of secure firmware:
|
||||
|
@ -10,6 +10,12 @@ Required root node property: src
|
||||
|
||||
Boards with the Nomadik SoC include:
|
||||
|
||||
Nomadik NHK-15 board manufactured by ST Microelectronics:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible="st,nomadik-nhk-15";
|
||||
|
||||
S8815 "MiniKit" manufactured by Calao Systems:
|
||||
|
||||
Required root node property:
|
||||
|
12
Documentation/devicetree/bindings/arm/sunxi.txt
Normal file
12
Documentation/devicetree/bindings/arm/sunxi.txt
Normal file
@ -0,0 +1,12 @@
|
||||
Allwinner sunXi Platforms Device Tree Bindings
|
||||
|
||||
Each device tree must specify which Allwinner SoC it uses,
|
||||
using one of the following compatible strings:
|
||||
|
||||
allwinner,sun4i-a10
|
||||
allwinner,sun5i-a10s
|
||||
allwinner,sun5i-a13
|
||||
allwinner,sun6i-a31
|
||||
allwinner,sun7i-a20
|
||||
allwinner,sun8i-a23
|
||||
allwinner,sun9i-a80
|
35
Documentation/devicetree/bindings/arm/ux500/power_domain.txt
Normal file
35
Documentation/devicetree/bindings/arm/ux500/power_domain.txt
Normal file
@ -0,0 +1,35 @@
|
||||
* ST-Ericsson UX500 PM Domains
|
||||
|
||||
UX500 supports multiple PM domains which are used to gate power to one or
|
||||
more peripherals on the SOC.
|
||||
|
||||
The implementation of PM domains for UX500 are based upon the generic PM domain
|
||||
and use the corresponding DT bindings.
|
||||
|
||||
==PM domain providers==
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "stericsson,ux500-pm-domains".
|
||||
- #power-domain-cells : Number of cells in a power domain specifier, must be 1.
|
||||
|
||||
Example:
|
||||
pm_domains: pm_domains0 {
|
||||
compatible = "stericsson,ux500-pm-domains";
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
==PM domain consumers==
|
||||
|
||||
Required properties:
|
||||
- power-domains: A phandle and PM domain specifier. Below are the list of
|
||||
valid specifiers:
|
||||
|
||||
Index Specifier
|
||||
----- ---------
|
||||
0 DOMAIN_VAPE
|
||||
|
||||
Example:
|
||||
sdi0_per1@80126000 {
|
||||
compatible = "arm,pl18x", "arm,primecell";
|
||||
power-domains = <&pm_domains DOMAIN_VAPE>
|
||||
};
|
@ -3,8 +3,10 @@
|
||||
Required properties:
|
||||
- compatible : should contain one of the following:
|
||||
- "renesas,sata-r8a7779" for R-Car H1
|
||||
- "renesas,sata-r8a7790" for R-Car H2
|
||||
- "renesas,sata-r8a7791" for R-Car M2
|
||||
- "renesas,sata-r8a7790-es1" for R-Car H2 ES1
|
||||
- "renesas,sata-r8a7790" for R-Car H2 other than ES1
|
||||
- "renesas,sata-r8a7791" for R-Car M2-W
|
||||
- "renesas,sata-r8a7793" for R-Car M2-N
|
||||
- reg : address and length of the SATA registers;
|
||||
- interrupts : must consist of one interrupt specifier.
|
||||
|
||||
|
@ -2,7 +2,11 @@ Broadcom GISB bus Arbiter controller
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: should be "brcm,gisb-arb"
|
||||
- compatible:
|
||||
"brcm,gisb-arb" or "brcm,bcm7445-gisb-arb" for 28nm chips
|
||||
"brcm,bcm7435-gisb-arb" for newer 40nm chips
|
||||
"brcm,bcm7400-gisb-arb" for older 40nm chips and all 65nm chips
|
||||
"brcm,bcm7038-gisb-arb" for 130nm chips
|
||||
- reg: specifies the base physical address and size of the registers
|
||||
- interrupt-parent: specifies the phandle to the parent interrupt controller
|
||||
this arbiter gets interrupt line from
|
||||
|
@ -48,9 +48,12 @@ Required properties:
|
||||
- compatible: Should be set to "marvell,mbus-controller".
|
||||
|
||||
- reg: Device's register space.
|
||||
Two entries are expected (see the examples below):
|
||||
the first one controls the devices decoding window and
|
||||
the second one controls the SDRAM decoding window.
|
||||
Two or three entries are expected (see the examples below):
|
||||
the first one controls the devices decoding window,
|
||||
the second one controls the SDRAM decoding window and
|
||||
the third controls the MBus bridge (only with the
|
||||
marvell,armada370-mbus and marvell,armadaxp-mbus
|
||||
compatible strings)
|
||||
|
||||
Example:
|
||||
|
||||
@ -67,7 +70,7 @@ Example:
|
||||
|
||||
mbusc: mbus-controller@20000 {
|
||||
compatible = "marvell,mbus-controller";
|
||||
reg = <0x20000 0x100>, <0x20180 0x20>;
|
||||
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
|
||||
};
|
||||
|
||||
/* more children ...*/
|
||||
@ -126,7 +129,7 @@ are skipped.
|
||||
|
||||
mbusc: mbus-controller@20000 {
|
||||
compatible = "marvell,mbus-controller";
|
||||
reg = <0x20000 0x100>, <0x20180 0x20>;
|
||||
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
|
||||
};
|
||||
|
||||
/* more children ...*/
|
||||
@ -170,7 +173,7 @@ Using this macro, the above example would be:
|
||||
|
||||
mbusc: mbus-controller@20000 {
|
||||
compatible = "marvell,mbus-controller";
|
||||
reg = <0x20000 0x100>, <0x20180 0x20>;
|
||||
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
|
||||
};
|
||||
|
||||
/* other children */
|
||||
@ -266,7 +269,7 @@ See the example below, where a more complete device tree is shown:
|
||||
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
|
||||
|
||||
mbusc: mbus-controller@20000 {
|
||||
reg = <0x20000 0x100>, <0x20180 0x20>;
|
||||
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
|
||||
};
|
||||
|
||||
interrupt-controller@20000 {
|
||||
|
34
Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
Normal file
34
Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
Normal file
@ -0,0 +1,34 @@
|
||||
Broadcom Cygnus Clocks
|
||||
|
||||
This binding uses the common clock binding:
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Currently various "fixed" clocks are declared for peripheral drivers that use
|
||||
the common clock framework to reference their core clocks. Proper support of
|
||||
these clocks will be added later
|
||||
|
||||
Device tree example:
|
||||
|
||||
clocks {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
|
||||
osc: oscillator {
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <1>;
|
||||
clock-frequency = <25000000>;
|
||||
};
|
||||
|
||||
apb_clk: apb_clk {
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <1000000000>;
|
||||
};
|
||||
|
||||
periph_clk: periph_clk {
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <500000000>;
|
||||
};
|
||||
};
|
@ -5,6 +5,19 @@ Required properties:
|
||||
- reg: Address and length of the register set
|
||||
- #clock-cells: Should be <1>
|
||||
|
||||
Optional properties:
|
||||
- clocks: list of clock identifiers which are external input clocks to the
|
||||
given clock controller. Please refer the next section to find
|
||||
the input clocks for a given controller.
|
||||
- clock-names: list of names of clocks which are exteral input clocks to the
|
||||
given clock controller.
|
||||
|
||||
Input clocks for top clock controller:
|
||||
- sxosc (external crystal oscillator 32KHz, recommended)
|
||||
- fxosc (external crystal oscillator 24MHz, recommended)
|
||||
- audio_ext
|
||||
- enet_ext
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. See include/dt-bindings/clock/vf610-clock.h
|
||||
for the full list of VF610 clock IDs.
|
||||
@ -15,6 +28,8 @@ clks: ccm@4006b000 {
|
||||
compatible = "fsl,vf610-ccm";
|
||||
reg = <0x4006b000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
clocks = <&sxosc>, <&fxosc>;
|
||||
clock-names = "sxosc", "fxosc";
|
||||
};
|
||||
|
||||
uart1: serial@40028000 {
|
||||
|
@ -25,7 +25,7 @@ Required child node properties:
|
||||
- compatible: It should be either "xlnx,axi-vdma-mm2s-channel" or
|
||||
"xlnx,axi-vdma-s2mm-channel".
|
||||
- interrupts: Should contain per channel VDMA interrupts.
|
||||
- xlnx,data-width: Should contain the stream data width, take values
|
||||
- xlnx,datawidth: Should contain the stream data width, take values
|
||||
{32,64...1024}.
|
||||
|
||||
Optional child node properties:
|
||||
|
39
Documentation/devicetree/bindings/hwmon/ltc2978.txt
Normal file
39
Documentation/devicetree/bindings/hwmon/ltc2978.txt
Normal file
@ -0,0 +1,39 @@
|
||||
ltc2978
|
||||
|
||||
Required properties:
|
||||
- compatible: should contain one of:
|
||||
* "lltc,ltc2974"
|
||||
* "lltc,ltc2977"
|
||||
* "lltc,ltc2978"
|
||||
* "lltc,ltc3880"
|
||||
* "lltc,ltc3883"
|
||||
* "lltc,ltm4676"
|
||||
- reg: I2C slave address
|
||||
|
||||
Optional properties:
|
||||
- regulators: A node that houses a sub-node for each regulator controlled by
|
||||
the device. Each sub-node is identified using the node's name, with valid
|
||||
values listed below. The content of each sub-node is defined by the
|
||||
standard binding for regulators; see regulator.txt.
|
||||
|
||||
Valid names of regulators depend on number of supplies supported per device:
|
||||
* ltc2974 : vout0 - vout3
|
||||
* ltc2977 : vout0 - vout7
|
||||
* ltc2978 : vout0 - vout7
|
||||
* ltc3880 : vout0 - vout1
|
||||
* ltc3883 : vout0
|
||||
* ltm4676 : vout0 - vout1
|
||||
|
||||
Example:
|
||||
ltc2978@5e {
|
||||
compatible = "lltc,ltc2978";
|
||||
reg = <0x5e>;
|
||||
regulators {
|
||||
vout0 {
|
||||
regulator-name = "FPGA-2.5V";
|
||||
};
|
||||
vout2 {
|
||||
regulator-name = "FPGA-1.5V";
|
||||
};
|
||||
};
|
||||
};
|
@ -32,6 +32,7 @@ Optional properties:
|
||||
specified, default value is 0.
|
||||
- samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not
|
||||
specified, the default value in Hz is 100000.
|
||||
- samsung,sysreg-phandle - handle to syscon used to control the system registers
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -56,6 +56,8 @@ gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire In
|
||||
infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
|
||||
infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz)
|
||||
isl,isl12057 Intersil ISL12057 I2C RTC Chip
|
||||
isil,isl29028 (deprecated, use isl)
|
||||
isl,isl29028 Intersil ISL29028 Ambient Light and Proximity Sensor
|
||||
maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
|
||||
maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
|
||||
maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface
|
||||
|
@ -13,7 +13,12 @@ Such an interrupt controller has the following hardware design:
|
||||
or if they will output an interrupt signal at this 2nd level interrupt
|
||||
controller, in particular for UARTs
|
||||
|
||||
- not all 32-bits within the interrupt controller actually map to an interrupt
|
||||
- typically has one 32-bit enable word and one 32-bit status word, but on
|
||||
some hardware may have more than one enable/status pair
|
||||
|
||||
- no atomic set/clear operations
|
||||
|
||||
- not all bits within the interrupt controller actually map to an interrupt
|
||||
|
||||
The typical hardware layout for this controller is represented below:
|
||||
|
||||
@ -48,7 +53,9 @@ The typical hardware layout for this controller is represented below:
|
||||
Required properties:
|
||||
|
||||
- compatible: should be "brcm,bcm7120-l2-intc"
|
||||
- reg: specifies the base physical address and size of the registers
|
||||
- reg: specifies the base physical address and size of the registers;
|
||||
multiple pairs may be specified, with the first pair handling IRQ offsets
|
||||
0..31 and the second pair handling 32..63
|
||||
- interrupt-controller: identifies the node as an interrupt controller
|
||||
- #interrupt-cells: specifies the number of cells needed to encode an interrupt
|
||||
source, should be 1.
|
||||
@ -59,18 +66,21 @@ Required properties:
|
||||
- brcm,int-map-mask: 32-bits bit mask describing how many and which interrupts
|
||||
are wired to this 2nd level interrupt controller, and how they match their
|
||||
respective interrupt parents. Should match exactly the number of interrupts
|
||||
specified in the 'interrupts' property.
|
||||
specified in the 'interrupts' property, multiplied by the number of
|
||||
enable/status register pairs implemented by this controller. For
|
||||
multiple parent IRQs with multiple enable/status words, this looks like:
|
||||
<irq0_w0 irq0_w1 irq1_w0 irq1_w1 ...>
|
||||
|
||||
Optional properties:
|
||||
|
||||
- brcm,irq-can-wake: if present, this means the L2 controller can be used as a
|
||||
wakeup source for system suspend/resume.
|
||||
|
||||
- brcm,int-fwd-mask: if present, a 32-bits bit mask to configure for the
|
||||
interrupts which have a mux gate, typically UARTs. Setting these bits will
|
||||
make their respective interrupts outputs bypass this 2nd level interrupt
|
||||
controller completely, it completely transparent for the interrupt controller
|
||||
parent
|
||||
- brcm,int-fwd-mask: if present, a bit mask to configure the interrupts which
|
||||
have a mux gate, typically UARTs. Setting these bits will make their
|
||||
respective interrupt outputs bypass this 2nd level interrupt controller
|
||||
completely; it is completely transparent for the interrupt controller
|
||||
parent. This should have one 32-bit word per enable/status pair.
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -30,10 +30,6 @@ 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
|
||||
-----------------------------
|
||||
|
||||
|
@ -0,0 +1,21 @@
|
||||
Device Tree bindings for MVEBU SDRAM controllers
|
||||
|
||||
The Marvell EBU SoCs all have a SDRAM controller. The SDRAM controller
|
||||
differs from one SoC variant to another, but they also share a number
|
||||
of commonalities.
|
||||
|
||||
For now, this Device Tree binding documentation only documents the
|
||||
Armada XP SDRAM controller.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: for Armada XP, "marvell,armada-xp-sdram-controller"
|
||||
- reg: a resource specifier for the register space, which should
|
||||
include all SDRAM controller registers as per the datasheet.
|
||||
|
||||
Example:
|
||||
|
||||
sdramc@1400 {
|
||||
compatible = "marvell,armada-xp-sdram-controller";
|
||||
reg = <0x1400 0x500>;
|
||||
};
|
@ -0,0 +1,36 @@
|
||||
NVIDIA Tegra Memory Controller device tree bindings
|
||||
===================================================
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "nvidia,tegra<chip>-mc"
|
||||
- reg: Physical base address and length of the controller's registers.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- mc: the module's clock input
|
||||
- interrupts: The interrupt outputs from the controller.
|
||||
- #iommu-cells: Should be 1. The single cell of the IOMMU specifier defines
|
||||
the SWGROUP of the master.
|
||||
|
||||
This device implements an IOMMU that complies with the generic IOMMU binding.
|
||||
See ../iommu/iommu.txt for details.
|
||||
|
||||
Example:
|
||||
--------
|
||||
|
||||
mc: memory-controller@0,70019000 {
|
||||
compatible = "nvidia,tegra124-mc";
|
||||
reg = <0x0 0x70019000 0x0 0x1000>;
|
||||
clocks = <&tegra_car TEGRA124_CLK_MC>;
|
||||
clock-names = "mc";
|
||||
|
||||
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
#iommu-cells = <1>;
|
||||
};
|
||||
|
||||
sdhci@0,700b0000 {
|
||||
compatible = "nvidia,tegra124-sdhci";
|
||||
...
|
||||
iommus = <&mc TEGRA_SWGROUP_SDMMC1A>;
|
||||
};
|
51
Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
Normal file
51
Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
Normal file
@ -0,0 +1,51 @@
|
||||
Device-Tree bindings for Atmel's HLCDC (High LCD Controller) MFD driver
|
||||
|
||||
Required properties:
|
||||
- compatible: value should be one of the following:
|
||||
"atmel,sama5d3-hlcdc"
|
||||
- reg: base address and size of the HLCDC device registers.
|
||||
- clock-names: the name of the 3 clocks requested by the HLCDC device.
|
||||
Should contain "periph_clk", "sys_clk" and "slow_clk".
|
||||
- clocks: should contain the 3 clocks requested by the HLCDC device.
|
||||
- interrupts: should contain the description of the HLCDC interrupt line
|
||||
|
||||
The HLCDC IP exposes two subdevices:
|
||||
- a PWM chip: see ../pwm/atmel-hlcdc-pwm.txt
|
||||
- a Display Controller: see ../drm/atmel-hlcdc-dc.txt
|
||||
|
||||
Example:
|
||||
|
||||
hlcdc: hlcdc@f0030000 {
|
||||
compatible = "atmel,sama5d3-hlcdc";
|
||||
reg = <0xf0030000 0x2000>;
|
||||
clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>;
|
||||
clock-names = "periph_clk","sys_clk", "slow_clk";
|
||||
interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
|
||||
status = "disabled";
|
||||
|
||||
hlcdc-display-controller {
|
||||
compatible = "atmel,hlcdc-display-controller";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0>;
|
||||
|
||||
hlcdc_panel_output: endpoint@0 {
|
||||
reg = <0>;
|
||||
remote-endpoint = <&panel_input>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
hlcdc_pwm: hlcdc-pwm {
|
||||
compatible = "atmel,hlcdc-pwm";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_lcd_pwm>;
|
||||
#pwm-cells = <3>;
|
||||
};
|
||||
};
|
@ -34,6 +34,12 @@ to get matched with their hardware counterparts as follow:
|
||||
-BUCKn : for BUCKs, where n can lie in range 1 to 9.
|
||||
example: BUCK1, BUCK5, BUCK9.
|
||||
|
||||
Regulators which can be turned off during system suspend:
|
||||
-LDOn : 2, 6-8, 10-12, 14-16,
|
||||
-BUCKn : 1-4.
|
||||
Use standard regulator bindings for it ('regulator-off-in-suspend').
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
max77686@09 {
|
||||
|
@ -27,6 +27,20 @@ Optional properties:
|
||||
|
||||
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
|
||||
- haptic : The MAX77693 haptic device utilises a PWM controlled motor to provide
|
||||
users with tactile feedback. PWM period and duty-cycle are varied in
|
||||
order to provide the approprite level of feedback.
|
||||
|
||||
Required properties:
|
||||
- compatible : Must be "maxim,max77693-hpatic"
|
||||
- haptic-supply : power supply for the haptic motor
|
||||
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
- pwms : phandle to the physical PWM(Pulse Width Modulation) device.
|
||||
PWM properties should be named "pwms". And number of cell is different
|
||||
for each pwm device.
|
||||
To get more informations, please refer to documentaion.
|
||||
[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
|
||||
|
||||
Example:
|
||||
max77693@66 {
|
||||
compatible = "maxim,max77693";
|
||||
@ -52,4 +66,11 @@ Example:
|
||||
regulator-boot-on;
|
||||
};
|
||||
};
|
||||
|
||||
haptic {
|
||||
compatible = "maxim,max77693-haptic";
|
||||
haptic-supply = <&haptic_supply>;
|
||||
pwms = <&pwm 0 40000 0>;
|
||||
pwm-names = "haptic";
|
||||
};
|
||||
};
|
||||
|
@ -1,5 +1,5 @@
|
||||
|
||||
* Samsung S2MPS11, S2MPS14 and S2MPU02 Voltage and Current Regulator
|
||||
* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator
|
||||
|
||||
The Samsung S2MPS11 is a multi-function device which includes voltage and
|
||||
current regulators, RTC, charger controller and other sub-blocks. It is
|
||||
@ -7,8 +7,8 @@ interfaced to the host controller using an I2C interface. Each sub-block is
|
||||
addressed by the host system using different I2C slave addresses.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps14-pmic"
|
||||
or "samsung,s2mpu02-pmic".
|
||||
- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic"
|
||||
or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic".
|
||||
- reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
|
||||
|
||||
Optional properties:
|
||||
@ -17,8 +17,8 @@ Optional properties:
|
||||
- interrupts: Interrupt specifiers for interrupt sources.
|
||||
|
||||
Optional nodes:
|
||||
- clocks: s2mps11 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz
|
||||
outputs, so to register these as clocks with common clock framework
|
||||
- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768
|
||||
KHz outputs, so to register these as clocks with common clock framework
|
||||
instantiate a sub-node named "clocks". It uses the common clock binding
|
||||
documented in :
|
||||
[Documentation/devicetree/bindings/clock/clock-bindings.txt]
|
||||
@ -30,12 +30,12 @@ Optional nodes:
|
||||
the clock which they consume.
|
||||
Clock ID Devices
|
||||
----------------------------------------------------------
|
||||
32KhzAP 0 S2MPS11, S2MPS14, S5M8767
|
||||
32KhzCP 1 S2MPS11, S5M8767
|
||||
32KhzBT 2 S2MPS11, S2MPS14, S5M8767
|
||||
32KhzAP 0 S2MPS11, S2MPS13, S2MPS14, S5M8767
|
||||
32KhzCP 1 S2MPS11, S2MPS13, S5M8767
|
||||
32KhzBT 2 S2MPS11, S2MPS13, S2MPS14, S5M8767
|
||||
|
||||
- compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps14-clk",
|
||||
"samsung,s5m8767-clk"
|
||||
- compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk",
|
||||
"samsung,s2mps14-clk", "samsung,s5m8767-clk"
|
||||
|
||||
- regulators: The regulators of s2mps11 that have to be instantiated should be
|
||||
included in a sub-node named 'regulators'. Regulator nodes included in this
|
||||
@ -81,12 +81,14 @@ as per the datasheet of s2mps11.
|
||||
- LDOn
|
||||
- valid values for n are:
|
||||
- S2MPS11: 1 to 38
|
||||
- S2MPS13: 1 to 40
|
||||
- S2MPS14: 1 to 25
|
||||
- S2MPU02: 1 to 28
|
||||
- Example: LDO1, LDO2, LDO28
|
||||
- BUCKn
|
||||
- valid values for n are:
|
||||
- S2MPS11: 1 to 10
|
||||
- S2MPS13: 1 to 10
|
||||
- S2MPS14: 1 to 5
|
||||
- S2MPU02: 1 to 7
|
||||
- Example: BUCK1, BUCK2, BUCK9
|
||||
|
@ -18,6 +18,10 @@ Required Properties:
|
||||
specific extensions.
|
||||
- "samsung,exynos5420-dw-mshc": for controllers with Samsung Exynos5420
|
||||
specific extensions.
|
||||
- "samsung,exynos7-dw-mshc": for controllers with Samsung Exynos7
|
||||
specific extensions.
|
||||
- "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7
|
||||
specific extensions having an SMU.
|
||||
|
||||
* samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
|
||||
unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
|
||||
|
29
Documentation/devicetree/bindings/mmc/img-dw-mshc.txt
Normal file
29
Documentation/devicetree/bindings/mmc/img-dw-mshc.txt
Normal file
@ -0,0 +1,29 @@
|
||||
* Imagination specific extensions to the Synopsys Designware Mobile Storage
|
||||
Host Controller
|
||||
|
||||
The Synopsys designware mobile storage host controller is used to interface
|
||||
a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
|
||||
differences between the core Synopsys dw mshc controller properties described
|
||||
by synopsys-dw-mshc.txt and the properties used by the Imagination specific
|
||||
extensions to the Synopsys Designware Mobile Storage Host Controller.
|
||||
|
||||
Required Properties:
|
||||
|
||||
* compatible: should be
|
||||
- "img,pistachio-dw-mshc": for Pistachio SoCs
|
||||
|
||||
Example:
|
||||
|
||||
mmc@18142000 {
|
||||
compatible = "img,pistachio-dw-mshc";
|
||||
reg = <0x18142000 0x400>;
|
||||
interrupts = <GIC_SHARED 39 IRQ_TYPE_LEVEL_HIGH>;
|
||||
|
||||
clocks = <&system_clk>, <&sdhost_clk>;
|
||||
clock-names = "biu", "ciu";
|
||||
|
||||
fifo-depth = <0x20>;
|
||||
bus-width = <4>;
|
||||
num-slots = <1>;
|
||||
disable-wp;
|
||||
};
|
@ -12,6 +12,10 @@ Required properties:
|
||||
* for "marvell,armada-380-sdhci", two register areas. The first one
|
||||
for the SDHCI registers themselves, and the second one for the
|
||||
AXI/Mbus bridge registers of the SDHCI unit.
|
||||
- clocks: Array of clocks required for SDHCI; requires at least one for
|
||||
I/O clock.
|
||||
- clock-names: Array of names corresponding to clocks property; shall be
|
||||
"io" for I/O clock and "core" for optional core clock.
|
||||
|
||||
Optional properties:
|
||||
- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning.
|
||||
@ -23,6 +27,8 @@ sdhci@d4280800 {
|
||||
reg = <0xd4280800 0x800>;
|
||||
bus-width = <8>;
|
||||
interrupts = <27>;
|
||||
clocks = <&chip CLKID_SDIO1XIN>, <&chip CLKID_SDIO1>;
|
||||
clock-names = "io", "core";
|
||||
non-removable;
|
||||
mrvl,clk-delay-cycles = <31>;
|
||||
};
|
||||
@ -32,5 +38,6 @@ sdhci@d8000 {
|
||||
reg = <0xd8000 0x1000>, <0xdc000 0x100>;
|
||||
interrupts = <0 25 0x4>;
|
||||
clocks = <&gateclk 17>;
|
||||
clock-names = "io";
|
||||
mrvl,clk-delay-cycles = <0x1F>;
|
||||
};
|
||||
|
62
Documentation/devicetree/bindings/nios2/nios2.txt
Normal file
62
Documentation/devicetree/bindings/nios2/nios2.txt
Normal file
@ -0,0 +1,62 @@
|
||||
* Nios II Processor Binding
|
||||
|
||||
This binding specifies what properties available in the device tree
|
||||
representation of a Nios II Processor Core.
|
||||
|
||||
Users can use sopc2dts tool for generating device tree sources (dts) from a
|
||||
Qsys system. See more detail in: http://www.alterawiki.com/wiki/Sopc2dts
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Compatible property value should be "altr,nios2-1.0".
|
||||
- reg: Contains CPU index.
|
||||
- interrupt-controller: Specifies that the node is an interrupt controller
|
||||
- #interrupt-cells: Specifies the number of cells needed to encode an
|
||||
interrupt source, should be 1.
|
||||
- clock-frequency: Contains the clock frequency for CPU, in Hz.
|
||||
- dcache-line-size: Contains data cache line size.
|
||||
- icache-line-size: Contains instruction line size.
|
||||
- dcache-size: Contains data cache size.
|
||||
- icache-size: Contains instruction cache size.
|
||||
- altr,pid-num-bits: Specifies the number of bits to use to represent the process
|
||||
identifier (PID).
|
||||
- altr,tlb-num-ways: Specifies the number of set-associativity ways in the TLB.
|
||||
- altr,tlb-num-entries: Specifies the number of entries in the TLB.
|
||||
- altr,tlb-ptr-sz: Specifies size of TLB pointer.
|
||||
- altr,has-mul: Specifies CPU hardware multipy support, should be 1.
|
||||
- altr,has-mmu: Specifies CPU support MMU support, should be 1.
|
||||
- altr,has-initda: Specifies CPU support initda instruction, should be 1.
|
||||
- altr,reset-addr: Specifies CPU reset address
|
||||
- altr,fast-tlb-miss-addr: Specifies CPU fast TLB miss exception address
|
||||
- altr,exception-addr: Specifies CPU exception address
|
||||
|
||||
Optional properties:
|
||||
- altr,has-div: Specifies CPU hardware divide support
|
||||
- altr,implementation: Nios II core implementation, this should be "fast";
|
||||
|
||||
Example:
|
||||
|
||||
cpu@0x0 {
|
||||
device_type = "cpu";
|
||||
compatible = "altr,nios2-1.0";
|
||||
reg = <0>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
clock-frequency = <125000000>;
|
||||
dcache-line-size = <32>;
|
||||
icache-line-size = <32>;
|
||||
dcache-size = <32768>;
|
||||
icache-size = <32768>;
|
||||
altr,implementation = "fast";
|
||||
altr,pid-num-bits = <8>;
|
||||
altr,tlb-num-ways = <16>;
|
||||
altr,tlb-num-entries = <128>;
|
||||
altr,tlb-ptr-sz = <7>;
|
||||
altr,has-div = <1>;
|
||||
altr,has-mul = <1>;
|
||||
altr,reset-addr = <0xc2800000>;
|
||||
altr,fast-tlb-miss-addr = <0xc7fff400>;
|
||||
altr,exception-addr = <0xd0000020>;
|
||||
altr,has-initda = <1>;
|
||||
altr,has-mmu = <1>;
|
||||
};
|
19
Documentation/devicetree/bindings/nios2/timer.txt
Normal file
19
Documentation/devicetree/bindings/nios2/timer.txt
Normal file
@ -0,0 +1,19 @@
|
||||
Altera Timer
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "altr,timer-1.0"
|
||||
- reg : Specifies base physical address and size of the registers.
|
||||
- interrupt-parent: phandle of the interrupt controller
|
||||
- interrupts : Should contain the timer interrupt number
|
||||
- clock-frequency : The frequency of the clock that drives the counter, in Hz.
|
||||
|
||||
Example:
|
||||
|
||||
timer {
|
||||
compatible = "altr,timer-1.0";
|
||||
reg = <0x00400000 0x00000020>;
|
||||
interrupt-parent = <&cpu>;
|
||||
interrupts = <11>;
|
||||
clock-frequency = <125000000>;
|
||||
};
|
@ -7,3 +7,14 @@ And for the interrupt mapping part:
|
||||
|
||||
Open Firmware Recommended Practice: Interrupt Mapping
|
||||
http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf
|
||||
|
||||
Additionally to the properties specified in the above standards a host bridge
|
||||
driver implementation may support the following properties:
|
||||
|
||||
- linux,pci-domain:
|
||||
If present this property assigns a fixed PCI domain number to a host bridge,
|
||||
otherwise an unstable (across boots) unique number will be assigned.
|
||||
It is required to either not set this property at all or set it for all
|
||||
host bridges in the system, otherwise potentially conflicting domain numbers
|
||||
may be assigned to root buses behind different host bridges. The domain
|
||||
number for each host bridge in the system must be unique.
|
||||
|
@ -9,7 +9,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
TZ1090-PDC's pin configuration nodes act as a container for an abitrary number
|
||||
TZ1090-PDC's pin configuration nodes act as a container for an arbitrary number
|
||||
of subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those pin(s)/group(s), and various pin configuration
|
||||
|
@ -9,7 +9,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
TZ1090's pin configuration nodes act as a container for an abitrary number of
|
||||
TZ1090's pin configuration nodes act as a container for an arbitrary number of
|
||||
subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those pin(s)/group(s), and various pin configuration
|
||||
|
@ -9,7 +9,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
Lantiq's pin configuration nodes act as a container for an abitrary number of
|
||||
Lantiq's pin configuration nodes act as a container for an arbitrary number of
|
||||
subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those group(s), and two pin configuration parameters:
|
||||
|
@ -9,7 +9,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
Lantiq's pin configuration nodes act as a container for an abitrary number of
|
||||
Lantiq's pin configuration nodes act as a container for an arbitrary number of
|
||||
subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those group(s), and two pin configuration parameters:
|
||||
|
@ -9,7 +9,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
Tegra's pin configuration nodes act as a container for an abitrary number of
|
||||
Tegra's pin configuration nodes act as a container for an arbitrary number of
|
||||
subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those pin(s)/group(s), and various pin configuration
|
||||
|
@ -13,7 +13,7 @@ Optional properties:
|
||||
Please refer to pinctrl-bindings.txt in this directory for details of the common
|
||||
pinctrl bindings used by client devices.
|
||||
|
||||
SiRFprimaII's pinmux nodes act as a container for an abitrary number of subnodes.
|
||||
SiRFprimaII's pinmux nodes act as a container for an arbitrary number of subnodes.
|
||||
Each of these subnodes represents some desired configuration for a group of pins.
|
||||
|
||||
Required subnode-properties:
|
||||
|
@ -32,7 +32,7 @@ Required properties:
|
||||
Please refer to pinctrl-bindings.txt in this directory for details of the common
|
||||
pinctrl bindings used by client devices.
|
||||
|
||||
SPEAr's pinmux nodes act as a container for an abitrary number of subnodes. Each
|
||||
SPEAr's pinmux nodes act as a container for an arbitrary number of subnodes. Each
|
||||
of these subnodes represents muxing for a pin, a group, or a list of pins or
|
||||
groups.
|
||||
|
||||
|
@ -18,7 +18,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
Qualcomm's pin configuration nodes act as a container for an abitrary number of
|
||||
Qualcomm's pin configuration nodes act as a container for an arbitrary number of
|
||||
subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those pin(s)/group(s), and various pin configuration
|
||||
|
@ -47,7 +47,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
The pin configuration nodes act as a container for an abitrary number of
|
||||
The pin configuration nodes act as a container for an arbitrary number of
|
||||
subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those pin(s)/group(s), and various pin configuration
|
||||
|
@ -18,7 +18,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
Qualcomm's pin configuration nodes act as a container for an abitrary number of
|
||||
Qualcomm's pin configuration nodes act as a container for an arbitrary number of
|
||||
subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those pin(s)/group(s), and various pin configuration
|
||||
|
@ -47,7 +47,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
The pin configuration nodes act as a container for an abitrary number of
|
||||
The pin configuration nodes act as a container for an arbitrary number of
|
||||
subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those pin(s)/group(s), and various pin configuration
|
||||
|
@ -18,7 +18,7 @@ Please refer to pinctrl-bindings.txt in this directory for details of the
|
||||
common pinctrl bindings used by client devices, including the meaning of the
|
||||
phrase "pin configuration node".
|
||||
|
||||
Qualcomm's pin configuration nodes act as a container for an abitrary number of
|
||||
Qualcomm's pin configuration nodes act as a container for an arbitrary number of
|
||||
subnodes. Each of these subnodes represents some desired configuration for a
|
||||
pin, a group, or a list of pins or groups. This configuration can include the
|
||||
mux function to select on those pin(s)/group(s), and various pin configuration
|
||||
|
18
Documentation/devicetree/bindings/power/power-controller.txt
Normal file
18
Documentation/devicetree/bindings/power/power-controller.txt
Normal file
@ -0,0 +1,18 @@
|
||||
* Generic system power control capability
|
||||
|
||||
Power-management integrated circuits or miscellaneous hardware components are
|
||||
sometimes able to control the system power. The device driver associated with these
|
||||
components might need to define this capability, which tells the kernel that
|
||||
it can be used to switch off the system. The corresponding device must have the
|
||||
standard property "system-power-controller" in its device node. This property
|
||||
marks the device as able to control the system power. In order to test if this
|
||||
property is found programmatically, use the helper function
|
||||
"of_device_is_system_power_controller" from of.h .
|
||||
|
||||
Example:
|
||||
|
||||
act8846: act8846@5 {
|
||||
compatible = "active-semi,act8846";
|
||||
status = "okay";
|
||||
system-power-controller;
|
||||
}
|
@ -0,0 +1,23 @@
|
||||
i.mx6 Poweroff Driver
|
||||
|
||||
SNVS_LPCR in SNVS module can power off the whole system by pull
|
||||
PMIC_ON_REQ low if PMIC_ON_REQ is connected with external PMIC.
|
||||
If you don't want to use PMIC_ON_REQ as power on/off control,
|
||||
please set status='disabled' to disable this driver.
|
||||
|
||||
Required Properties:
|
||||
-compatible: "fsl,sec-v4.0-poweroff"
|
||||
-reg: Specifies the physical address of the SNVS_LPCR register
|
||||
|
||||
Example:
|
||||
snvs@020cc000 {
|
||||
compatible = "fsl,sec-v4.0-mon", "simple-bus";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0x020cc000 0x4000>;
|
||||
.....
|
||||
snvs_poweroff: snvs-poweroff@38 {
|
||||
compatible = "fsl,sec-v4.0-poweroff";
|
||||
reg = <0x38 0x4>;
|
||||
};
|
||||
}
|
@ -5,6 +5,10 @@ Required properties:
|
||||
- compatible: "active-semi,act8846" or "active-semi,act8865"
|
||||
- reg: I2C slave address
|
||||
|
||||
Optional properties:
|
||||
- system-power-controller: Telling whether or not this pmic is controlling
|
||||
the system power. See Documentation/devicetree/bindings/power/power-controller.txt .
|
||||
|
||||
Any standard regulator properties can be used to configure the single regulator.
|
||||
|
||||
The valid names for regulators are:
|
||||
|
@ -25,6 +25,29 @@ with their hardware counterparts as follow. The valid names are:
|
||||
example: LDO1, LDO2, LDO35.
|
||||
-BUCKn : for BUCKs, where n can lie in range 1 to 10.
|
||||
example: BUCK1, BUCK5, BUCK10.
|
||||
|
||||
The max77802 regulator supports two different operating modes: Normal and Low
|
||||
Power Mode. Some regulators support the modes to be changed at startup or by
|
||||
the consumers during normal operation while others only support to change the
|
||||
mode during system suspend. The standard regulator suspend states binding can
|
||||
be used to configure the regulator operating mode.
|
||||
|
||||
The regulators that support the standard "regulator-initial-mode" property,
|
||||
changing their mode during normal operation are: LDOs 1, 3, 20 and 21.
|
||||
|
||||
The possible values for "regulator-initial-mode" and "regulator-mode" are:
|
||||
1: Normal regulator voltage output mode.
|
||||
3: Low Power which reduces the quiescent current down to only 1uA
|
||||
|
||||
The list of valid modes are defined in the dt-bindings/clock/maxim,max77802.h
|
||||
header and can be included by device tree source files.
|
||||
|
||||
The standard "regulator-mode" property can only be used for regulators that
|
||||
support changing their mode to Low Power Mode during suspend. These regulators
|
||||
are: BUCKs 2-4 and LDOs 1-35. Also, it only takes effect if the regulator has
|
||||
been enabled for the given suspend state using "regulator-on-in-suspend" and
|
||||
has not been disabled for that state using "regulator-off-in-suspend".
|
||||
|
||||
Example:
|
||||
|
||||
max77802@09 {
|
||||
@ -36,11 +59,23 @@ Example:
|
||||
#size-cells = <0>;
|
||||
|
||||
regulators {
|
||||
ldo1_reg: LDO1 {
|
||||
regulator-name = "vdd_1v0";
|
||||
regulator-min-microvolt = <1000000>;
|
||||
regulator-max-microvolt = <1000000>;
|
||||
regulator-always-on;
|
||||
regulator-initial-mode = <MAX77802_OPMODE_LP>;
|
||||
};
|
||||
|
||||
ldo11_reg: LDO11 {
|
||||
regulator-name = "vdd_ldo11";
|
||||
regulator-min-microvolt = <1900000>;
|
||||
regulator-max-microvolt = <1900000>;
|
||||
regulator-always-on;
|
||||
regulator-state-mem {
|
||||
regulator-on-in-suspend;
|
||||
regulator-mode = <MAX77802_OPMODE_LP>;
|
||||
};
|
||||
};
|
||||
|
||||
buck1_reg: BUCK1 {
|
||||
|
@ -19,6 +19,24 @@ Optional properties:
|
||||
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.
|
||||
- regulator-state-mem sub-root node for Suspend-to-RAM mode
|
||||
: suspend to memory, the device goes to sleep, but all data stored in memory,
|
||||
only some external interrupt can wake the device.
|
||||
- regulator-state-disk sub-root node for Suspend-to-DISK mode
|
||||
: suspend to disk, this state operates similarly to Suspend-to-RAM,
|
||||
but includes a final step of writing memory contents to disk.
|
||||
- regulator-state-[mem/disk] node has following common properties:
|
||||
- regulator-on-in-suspend: regulator should be on in suspend state.
|
||||
- regulator-off-in-suspend: regulator should be off in suspend state.
|
||||
- regulator-suspend-microvolt: regulator should be set to this voltage
|
||||
in suspend.
|
||||
- regulator-mode: operating mode in the given suspend state.
|
||||
The set of possible operating modes depends on the capabilities of
|
||||
every hardware so the valid modes are documented on each regulator
|
||||
device tree binding document.
|
||||
- regulator-initial-mode: initial operating mode. The set of possible operating
|
||||
modes depends on the capabilities of every hardware so each device binding
|
||||
documentation explains which values the regulator supports.
|
||||
|
||||
Deprecated properties:
|
||||
- regulator-compatible: If a regulator chip contains multiple
|
||||
@ -34,6 +52,10 @@ Example:
|
||||
regulator-max-microvolt = <2500000>;
|
||||
regulator-always-on;
|
||||
vin-supply = <&vin>;
|
||||
|
||||
regulator-state-mem {
|
||||
regulator-on-in-suspend;
|
||||
};
|
||||
};
|
||||
|
||||
Regulator Consumers:
|
||||
|
@ -1,6 +1,7 @@
|
||||
SKY81452 voltage regulator
|
||||
|
||||
Required properties:
|
||||
- regulator node named lout.
|
||||
- any required generic properties defined in regulator.txt
|
||||
|
||||
Optional properties:
|
||||
@ -9,8 +10,9 @@ Optional properties:
|
||||
Example:
|
||||
|
||||
regulator {
|
||||
/* generic regulator properties */
|
||||
regulator-name = "touch_en";
|
||||
regulator-min-microvolt = <4500000>;
|
||||
regulator-max-microvolt = <8000000>;
|
||||
lout {
|
||||
regulator-name = "sky81452-lout";
|
||||
regulator-min-microvolt = <4500000>;
|
||||
regulator-max-microvolt = <8000000>;
|
||||
};
|
||||
};
|
||||
|
@ -0,0 +1,42 @@
|
||||
STMicroelectronics STi family Sysconfig Picophy SoftReset Controller
|
||||
=============================================================================
|
||||
|
||||
This binding describes a reset controller device that is used to enable and
|
||||
disable on-chip PicoPHY USB2 phy(s) using "softreset" control bits found in
|
||||
the STi family SoC system configuration registers.
|
||||
|
||||
The actual action taken when softreset is asserted is hardware dependent.
|
||||
However, when asserted it may not be possible to access the hardware's
|
||||
registers and after an assert/deassert sequence the hardware's previous state
|
||||
may no longer be valid.
|
||||
|
||||
Please refer to Documentation/devicetree/bindings/reset/reset.txt
|
||||
for common reset controller binding usage.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "st,stih407-picophyreset"
|
||||
- #reset-cells: 1, see below
|
||||
|
||||
Example:
|
||||
|
||||
picophyreset: picophyreset-controller {
|
||||
compatible = "st,stih407-picophyreset";
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
Specifying picophyreset control of devices
|
||||
=======================================
|
||||
|
||||
Device nodes should specify the reset channel required in their "resets"
|
||||
property, containing a phandle to the picophyreset device node and an
|
||||
index specifying which channel to use, as described in
|
||||
Documentation/devicetree/bindings/reset/reset.txt.
|
||||
|
||||
Example:
|
||||
|
||||
usb2_picophy0: usbpicophy@0 {
|
||||
resets = <&picophyreset STIH407_PICOPHY0_RESET>;
|
||||
};
|
||||
|
||||
Macro definitions for the supported reset channels can be found in:
|
||||
include/dt-bindings/reset-controller/stih407-resets.h
|
23
Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt
Normal file
23
Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt
Normal file
@ -0,0 +1,23 @@
|
||||
Atmel AT91SAM9260 Real Time Timer
|
||||
|
||||
Required properties:
|
||||
- compatible: should be: "atmel,at91sam9260-rtt"
|
||||
- reg: should encode the memory region of the RTT controller
|
||||
- interrupts: rtt alarm/event interrupt
|
||||
- clocks: should contain the 32 KHz slow clk that will drive the RTT block.
|
||||
- atmel,rtt-rtc-time-reg: should encode the GPBR register used to store
|
||||
the time base when the RTT is used as an RTC.
|
||||
The first cell should point to the GPBR node and the second one
|
||||
encode the offset within the GPBR block (or in other words, the
|
||||
GPBR register used to store the time base).
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
rtt@fffffd20 {
|
||||
compatible = "atmel,at91sam9260-rtt";
|
||||
reg = <0xfffffd20 0x10>;
|
||||
interrupts = <1 4 7>;
|
||||
clocks = <&clk32k>;
|
||||
atmel,rtt-rtc-time-reg = <&gpbr 0x0>;
|
||||
};
|
@ -7,7 +7,10 @@ Required properties:
|
||||
- "renesas,thermal-r8a73a4" (R-Mobile AP6)
|
||||
- "renesas,thermal-r8a7779" (R-Car H1)
|
||||
- "renesas,thermal-r8a7790" (R-Car H2)
|
||||
- "renesas,thermal-r8a7791" (R-Car M2)
|
||||
- "renesas,thermal-r8a7791" (R-Car M2-W)
|
||||
- "renesas,thermal-r8a7792" (R-Car V2H)
|
||||
- "renesas,thermal-r8a7793" (R-Car M2-N)
|
||||
- "renesas,thermal-r8a7794" (R-Car E2)
|
||||
- reg : Address range of the thermal registers.
|
||||
The 1st reg will be recognized as common register
|
||||
if it has "interrupts".
|
||||
|
@ -2,8 +2,10 @@ Marvell Armada 370 and Armada XP Timers
|
||||
---------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be either "marvell,armada-370-timer" or
|
||||
"marvell,armada-xp-timer" as appropriate.
|
||||
- compatible: Should be one of the following
|
||||
"marvell,armada-370-timer",
|
||||
"marvell,armada-375-timer",
|
||||
"marvell,armada-xp-timer".
|
||||
- interrupts: Should contain the list of Global Timer interrupts and
|
||||
then local timer interrupts
|
||||
- reg: Should contain location and length for timers register. First
|
||||
@ -13,7 +15,8 @@ Required properties:
|
||||
Clocks required for compatible = "marvell,armada-370-timer":
|
||||
- clocks : Must contain a single entry describing the clock input
|
||||
|
||||
Clocks required for compatible = "marvell,armada-xp-timer":
|
||||
Clocks required for compatibles = "marvell,armada-xp-timer",
|
||||
"marvell,armada-375-timer":
|
||||
- clocks : Must contain an entry for each entry in clock-names.
|
||||
- clock-names : Must include the following entries:
|
||||
"nbclk" (L2/coherency fabric clock),
|
||||
|
@ -1,4 +1,4 @@
|
||||
* Renesas R-Car Multi-Function Timer Pulse Unit 2 (MTU2)
|
||||
* Renesas Multi-Function Timer Pulse Unit 2 (MTU2)
|
||||
|
||||
The MTU2 is a multi-purpose, multi-channel timer/counter with configurable
|
||||
clock inputs and programmable compare match.
|
||||
|
@ -1,4 +1,4 @@
|
||||
* Renesas R-Car Timer Unit (TMU)
|
||||
* Renesas R-Mobile/R-Car Timer Unit (TMU)
|
||||
|
||||
The TMU is a 32-bit timer/counter with configurable clock inputs and
|
||||
programmable compare match.
|
||||
@ -9,6 +9,8 @@ are independent. The TMU hardware supports up to three channels.
|
||||
Required Properties:
|
||||
|
||||
- compatible: must contain one or more of the following:
|
||||
- "renesas,tmu-r8a7740" for the r8a7740 TMU
|
||||
- "renesas,tmu-r8a7778" for the r8a7778 TMU
|
||||
- "renesas,tmu-r8a7779" for the r8a7779 TMU
|
||||
- "renesas,tmu" for any TMU.
|
||||
This is a fallback for the above renesas,tmu-* entries
|
||||
|
@ -34,12 +34,14 @@ chipidea Chipidea, Inc
|
||||
chrp Common Hardware Reference Platform
|
||||
chunghwa Chunghwa Picture Tubes Ltd.
|
||||
cirrus Cirrus Logic, Inc.
|
||||
cnm Chips&Media, Inc.
|
||||
cortina Cortina Systems, Inc.
|
||||
crystalfontz Crystalfontz America, Inc.
|
||||
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
|
||||
davicom DAVICOM Semiconductor, Inc.
|
||||
denx Denx Software Engineering
|
||||
digi Digi International Inc.
|
||||
digilent Diglent, Inc.
|
||||
dlg Dialog Semiconductor
|
||||
dlink D-Link Corporation
|
||||
dmo Data Modul AG
|
||||
@ -77,6 +79,7 @@ innolux Innolux Corporation
|
||||
intel Intel Corporation
|
||||
intercontrol Inter Control Group
|
||||
isee ISEE 2007 S.L.
|
||||
isil Intersil (deprecated, use isl)
|
||||
isl Intersil
|
||||
karo Ka-Ro electronics GmbH
|
||||
keymile Keymile GmbH
|
||||
@ -90,8 +93,10 @@ lltc Linear Technology Corporation
|
||||
marvell Marvell Technology Group Ltd.
|
||||
maxim Maxim Integrated Products
|
||||
mediatek MediaTek Inc.
|
||||
merrii Merrii Technology Co., Ltd.
|
||||
micrel Micrel Inc.
|
||||
microchip Microchip Technology Inc.
|
||||
micron Micron Technology Inc.
|
||||
mitsubishi Mitsubishi Electric Corporation
|
||||
mosaixtech Mosaix Technologies, Inc.
|
||||
moxa Moxa
|
||||
@ -127,6 +132,7 @@ renesas Renesas Electronics Corporation
|
||||
ricoh Ricoh Co. Ltd.
|
||||
rockchip Fuzhou Rockchip Electronics Co., Ltd
|
||||
samsung Samsung Semiconductor
|
||||
sandisk Sandisk Corporation
|
||||
sbs Smart Battery System
|
||||
schindler Schindler
|
||||
seagate Seagate Technology PLC
|
||||
@ -138,7 +144,7 @@ silergy Silergy Corp.
|
||||
sirf SiRF Technology, Inc.
|
||||
sitronix Sitronix Technology Corporation
|
||||
smsc Standard Microsystems Corporation
|
||||
snps Synopsys, Inc.
|
||||
snps Synopsys, Inc.
|
||||
solidrun SolidRun
|
||||
sony Sony Corporation
|
||||
spansion Spansion Inc.
|
||||
@ -146,6 +152,7 @@ st STMicroelectronics
|
||||
ste ST-Ericsson
|
||||
stericsson ST-Ericsson
|
||||
synology Synology, Inc.
|
||||
tbs TBS Technologies
|
||||
thine THine Electronics, Inc.
|
||||
ti Texas Instruments
|
||||
tlm Trusted Logic Mobility
|
||||
|
17
Documentation/devicetree/bindings/w1/omap-hdq.txt
Normal file
17
Documentation/devicetree/bindings/w1/omap-hdq.txt
Normal file
@ -0,0 +1,17 @@
|
||||
* OMAP HDQ One wire bus master controller
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "ti,omap3-1w"
|
||||
- reg : Address and length of the register set for the device
|
||||
- interrupts : interrupt line.
|
||||
- ti,hwmods : "hdq1w"
|
||||
|
||||
Example:
|
||||
|
||||
- From omap3.dtsi
|
||||
hdqw1w: 1w@480b2000 {
|
||||
compatible = "ti,omap3-1w";
|
||||
reg = <0x480b2000 0x1000>;
|
||||
interrupts = <58>;
|
||||
ti,hwmods = "hdq1w";
|
||||
};
|
@ -17,6 +17,18 @@ For "marvell,armada-375-wdt" and "marvell,armada-380-wdt":
|
||||
- reg : A third entry is mandatory and should contain the
|
||||
shared mask/unmask RSTOUT address.
|
||||
|
||||
Clocks required for compatibles = "marvell,orion-wdt",
|
||||
"marvell,armada-370-wdt":
|
||||
- clocks : Must contain a single entry describing the clock input
|
||||
|
||||
Clocks required for compatibles = "marvell,armada-xp-wdt"
|
||||
"marvell,armada-375-wdt"
|
||||
"marvell,armada-380-wdt":
|
||||
- clocks : Must contain an entry for each entry in clock-names.
|
||||
- clock-names : Must include the following entries:
|
||||
"nbclk" (L2/coherency fabric clock),
|
||||
"fixed" (Reference 25 MHz fixed-clock).
|
||||
|
||||
Optional properties:
|
||||
|
||||
- interrupts : Contains the IRQ for watchdog expiration
|
||||
@ -30,4 +42,5 @@ Example:
|
||||
interrupts = <3>;
|
||||
timeout-sec = <10>;
|
||||
status = "okay";
|
||||
clocks = <&gate_clk 7>;
|
||||
};
|
||||
|
@ -64,7 +64,7 @@ is formed.
|
||||
At mount time, the two directories given as mount options "lowerdir" and
|
||||
"upperdir" are combined into a merged directory:
|
||||
|
||||
mount -t overlayfs overlayfs -olowerdir=/lower,upperdir=/upper,\
|
||||
mount -t overlay overlay -olowerdir=/lower,upperdir=/upper,\
|
||||
workdir=/work /merged
|
||||
|
||||
The "workdir" needs to be an empty directory on the same filesystem
|
||||
|
@ -53,6 +53,11 @@ Supported chips:
|
||||
http://www.ti.com/product/tmp75
|
||||
http://www.ti.com/product/tmp175
|
||||
http://www.ti.com/product/tmp275
|
||||
* NXP LM75B
|
||||
Prefix: 'lm75b'
|
||||
Addresses scanned: none
|
||||
Datasheet: Publicly available at the NXP website
|
||||
http://www.nxp.com/documents/data_sheet/LM75B.pdf
|
||||
|
||||
Author: Frodo Looijaard <frodol@dds.nl>
|
||||
|
||||
|
@ -2,6 +2,10 @@ Kernel driver lm95234
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* National Semiconductor / Texas Instruments LM95233
|
||||
Addresses scanned: I2C 0x18, 0x2a, 0x2b
|
||||
Datasheet: Publicly available at the Texas Instruments website
|
||||
http://www.ti.com/product/lm95233
|
||||
* National Semiconductor / Texas Instruments LM95234
|
||||
Addresses scanned: I2C 0x18, 0x4d, 0x4e
|
||||
Datasheet: Publicly available at the Texas Instruments website
|
||||
@ -13,11 +17,12 @@ Author: Guenter Roeck <linux@roeck-us.net>
|
||||
Description
|
||||
-----------
|
||||
|
||||
LM95234 is an 11-bit digital temperature sensor with a 2-wire System Management
|
||||
Bus (SMBus) interface and TrueTherm technology that can very accurately monitor
|
||||
the temperature of four remote diodes as well as its own temperature.
|
||||
The four remote diodes can be external devices such as microprocessors,
|
||||
graphics processors or diode-connected 2N3904s. The LM95234's TruTherm
|
||||
LM95233 and LM95234 are 11-bit digital temperature sensors with a 2-wire
|
||||
System Management Bus (SMBus) interface and TrueTherm technology
|
||||
that can very accurately monitor the temperature of two (LM95233)
|
||||
or four (LM95234) remote diodes as well as its own temperature.
|
||||
The remote diodes can be external devices such as microprocessors,
|
||||
graphics processors or diode-connected 2N3904s. The chip's TruTherm
|
||||
beta compensation technology allows sensing of 90 nm or 65 nm process
|
||||
thermal diodes accurately.
|
||||
|
||||
|
@ -2,10 +2,14 @@ Kernel driver lm95245
|
||||
==================
|
||||
|
||||
Supported chips:
|
||||
* National Semiconductor LM95245
|
||||
* TI LM95235
|
||||
Addresses scanned: I2C 0x18, 0x29, 0x4c
|
||||
Datasheet: Publicly available at the TI website
|
||||
http://www.ti.com/lit/ds/symlink/lm95235.pdf
|
||||
* TI / National Semiconductor LM95245
|
||||
Addresses scanned: I2C 0x18, 0x19, 0x29, 0x4c, 0x4d
|
||||
Datasheet: Publicly available at the National Semiconductor website
|
||||
http://www.national.com/mpf/LM/LM95245.html
|
||||
Datasheet: Publicly available at the TI website
|
||||
http://www.ti.com/lit/ds/symlink/lm95245.pdf
|
||||
|
||||
|
||||
Author: Alexander Stein <alexander.stein@systec-electronic.com>
|
||||
@ -13,10 +17,10 @@ Author: Alexander Stein <alexander.stein@systec-electronic.com>
|
||||
Description
|
||||
-----------
|
||||
|
||||
The LM95245 is an 11-bit digital temperature sensor with a 2-wire System
|
||||
LM95235 and LM95245 are 11-bit digital temperature sensors with a 2-wire System
|
||||
Management Bus (SMBus) interface and TruTherm technology that can monitor
|
||||
the temperature of a remote diode as well as its own temperature.
|
||||
The LM95245 can be used to very accurately monitor the temperature of
|
||||
The chips can be used to very accurately monitor the temperature of
|
||||
external devices such as microprocessors.
|
||||
|
||||
All temperature values are given in millidegrees Celsius. Local temperature
|
||||
|
@ -8,11 +8,15 @@ Kernel driver NCT6775
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Nuvoton NCT6102D/NCT6104D/NCT6106D
|
||||
Prefix: 'nct6106'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: Available from the Nuvoton web site
|
||||
* Nuvoton NCT5572D/NCT6771F/NCT6772F/NCT6775F/W83677HG-I
|
||||
Prefix: 'nct6775'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: Available from Nuvoton upon request
|
||||
* Nuvoton NCT5577D/NCT6776D/NCT6776F
|
||||
* Nuvoton NCT5573D/NCT5577D/NCT6776D/NCT6776F
|
||||
Prefix: 'nct6776'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: Available from Nuvoton upon request
|
||||
@ -20,6 +24,14 @@ Supported chips:
|
||||
Prefix: 'nct6779'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: Available from Nuvoton upon request
|
||||
* Nuvoton NCT6791D
|
||||
Prefix: 'nct6791'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: Available from Nuvoton upon request
|
||||
* Nuvoton NCT6792D
|
||||
Prefix: 'nct6792'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: Available from Nuvoton upon request
|
||||
|
||||
Authors:
|
||||
Guenter Roeck <linux@roeck-us.net>
|
||||
|
32
Documentation/hwmon/nct7802
Normal file
32
Documentation/hwmon/nct7802
Normal file
@ -0,0 +1,32 @@
|
||||
Kernel driver nct7802
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Nuvoton NCT7802Y
|
||||
Prefix: 'nct7802'
|
||||
Addresses scanned: I2C 0x28..0x2f
|
||||
Datasheet: Available from Nuvoton web site
|
||||
|
||||
Authors:
|
||||
Guenter Roeck <linux@roeck-us.net>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Nuvoton NCT7802Y hardware monitoring
|
||||
chip. NCT7802Y supports 6 temperature sensors, 5 voltage sensors, and 3 fan
|
||||
speed sensors.
|
||||
|
||||
The chip also supports intelligent fan speed control. This functionality is
|
||||
not currently supported by the driver.
|
||||
|
||||
Tested Boards and BIOS Versions
|
||||
-------------------------------
|
||||
|
||||
The driver has been reported to work with the following boards and
|
||||
BIOS versions.
|
||||
|
||||
Board BIOS version
|
||||
---------------------------------------------------------------
|
||||
Kontron COMe-bSC2 CHR2E934.001.GGO
|
||||
Kontron COMe-bIP2 CCR2E212
|
@ -18,6 +18,10 @@ Supported chips:
|
||||
Prefix: 'tmp432'
|
||||
Addresses scanned: I2C 0x4c, 0x4d
|
||||
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp432.html
|
||||
* Texas Instruments TMP435
|
||||
Prefix: 'tmp435'
|
||||
Addresses scanned: I2C 0x37, 0x48 - 0x4f
|
||||
Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp435.html
|
||||
|
||||
Authors:
|
||||
Hans de Goede <hdegoede@redhat.com>
|
||||
@ -27,8 +31,8 @@ Description
|
||||
-----------
|
||||
|
||||
This driver implements support for Texas Instruments TMP401, TMP411,
|
||||
TMP431, and TMP432 chips. These chips implement one or two remote and
|
||||
one local temperature sensors. Temperature is measured in degrees
|
||||
TMP431, TMP432 and TMP435 chips. These chips implement one or two remote
|
||||
and one local temperature sensors. Temperature is measured in degrees
|
||||
Celsius. Resolution of the remote sensor is 0.0625 degree. Local
|
||||
sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not
|
||||
supported by the driver so far, so using the default resolution of 0.5
|
||||
|
@ -38,22 +38,38 @@ Contents
|
||||
7.2.1 Status packet
|
||||
7.2.2 Head packet
|
||||
7.2.3 Motion packet
|
||||
8. Trackpoint (for Hardware version 3 and 4)
|
||||
8.1 Registers
|
||||
8.2 Native relative mode 6 byte packet format
|
||||
8.2.1 Status Packet
|
||||
|
||||
|
||||
|
||||
1. Introduction
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Currently the Linux Elantech touchpad driver is aware of two different
|
||||
hardware versions unimaginatively called version 1 and version 2. Version 1
|
||||
is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to
|
||||
be introduced with the EeePC and uses 6 bytes per packet, and provides
|
||||
additional features such as position of two fingers, and width of the touch.
|
||||
Currently the Linux Elantech touchpad driver is aware of four different
|
||||
hardware versions unimaginatively called version 1,version 2, version 3
|
||||
and version 4. Version 1 is found in "older" laptops and uses 4 bytes per
|
||||
packet. Version 2 seems to be introduced with the EeePC and uses 6 bytes
|
||||
per packet, and provides additional features such as position of two fingers,
|
||||
and width of the touch. Hardware version 3 uses 6 bytes per packet (and
|
||||
for 2 fingers the concatenation of two 6 bytes packets) and allows tracking
|
||||
of up to 3 fingers. Hardware version 4 uses 6 bytes per packet, and can
|
||||
combine a status packet with multiple head or motion packets. Hardware version
|
||||
4 allows tracking up to 5 fingers.
|
||||
|
||||
Some Hardware version 3 and version 4 also have a trackpoint which uses a
|
||||
separate packet format. It is also 6 bytes per packet.
|
||||
|
||||
The driver tries to support both hardware versions and should be compatible
|
||||
with the Xorg Synaptics touchpad driver and its graphical configuration
|
||||
utilities.
|
||||
|
||||
Note that a mouse button is also associated with either the touchpad or the
|
||||
trackpoint when a trackpoint is available. Disabling the Touchpad in xorg
|
||||
(TouchPadOff=0) will also disable the buttons associated with the touchpad.
|
||||
|
||||
Additionally the operation of the touchpad can be altered by adjusting the
|
||||
contents of some of its internal registers. These registers are represented
|
||||
by the driver as sysfs entries under /sys/bus/serio/drivers/psmouse/serio?
|
||||
@ -78,7 +94,7 @@ completeness sake.
|
||||
2. Extra knobs
|
||||
~~~~~~~~~~~
|
||||
|
||||
Currently the Linux Elantech touchpad driver provides two extra knobs under
|
||||
Currently the Linux Elantech touchpad driver provides three extra knobs under
|
||||
/sys/bus/serio/drivers/psmouse/serio? for the user.
|
||||
|
||||
* debug
|
||||
@ -112,6 +128,20 @@ Currently the Linux Elantech touchpad driver provides two extra knobs under
|
||||
data consistency checking can be done. For now checking is disabled by
|
||||
default. Currently even turning it on will do nothing.
|
||||
|
||||
* crc_enabled
|
||||
|
||||
Sets crc_enabled to 0/1. The name "crc_enabled" is the official name of
|
||||
this integrity check, even though it is not an actual cyclic redundancy
|
||||
check.
|
||||
|
||||
Depending on the state of crc_enabled, certain basic data integrity
|
||||
verification is done by the driver on hardware version 3 and 4. The
|
||||
driver will reject any packet that appears corrupted. Using this knob,
|
||||
The state of crc_enabled can be altered with this knob.
|
||||
|
||||
Reading the crc_enabled value will show the active value. Echoing
|
||||
"0" or "1" to this file will set the state to "0" or "1".
|
||||
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
3. Differentiating hardware versions
|
||||
@ -746,3 +776,42 @@ byte 5:
|
||||
|
||||
byte 0 ~ 2 for one finger
|
||||
byte 3 ~ 5 for another
|
||||
|
||||
|
||||
8. Trackpoint (for Hardware version 3 and 4)
|
||||
=========================================
|
||||
8.1 Registers
|
||||
~~~~~~~~~
|
||||
No special registers have been identified.
|
||||
|
||||
8.2 Native relative mode 6 byte packet format
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
8.2.1 Status Packet
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
byte 0:
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
0 0 sx sy 0 M R L
|
||||
byte 1:
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
~sx 0 0 0 0 0 0 0
|
||||
byte 2:
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
~sy 0 0 0 0 0 0 0
|
||||
byte 3:
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
0 0 ~sy ~sx 0 1 1 0
|
||||
byte 4:
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
x7 x6 x5 x4 x3 x2 x1 x0
|
||||
byte 5:
|
||||
bit 7 6 5 4 3 2 1 0
|
||||
y7 y6 y5 y4 y3 y2 y1 y0
|
||||
|
||||
|
||||
x and y are written in two's complement spread
|
||||
over 9 bits with sx/sy the relative top bit and
|
||||
x7..x0 and y7..y0 the lower bits.
|
||||
~sx is the inverse of sx, ~sy is the inverse of sy.
|
||||
The sign of y is opposite to what the input driver
|
||||
expects for a relative movement
|
||||
|
@ -2940,6 +2940,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
quiescent states. Units are jiffies, minimum
|
||||
value is one, and maximum value is HZ.
|
||||
|
||||
rcutree.kthread_prio= [KNL,BOOT]
|
||||
Set the SCHED_FIFO priority of the RCU
|
||||
per-CPU kthreads (rcuc/N). This value is also
|
||||
used for the priority of the RCU boost threads
|
||||
(rcub/N). Valid values are 1-99 and the default
|
||||
is 1 (the least-favored priority).
|
||||
|
||||
rcutree.rcu_nocb_leader_stride= [KNL]
|
||||
Set the number of NOCB kthread groups, which
|
||||
defaults to the square root of the number of
|
||||
@ -3089,6 +3096,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
messages. Disable with a value less than or equal
|
||||
to zero.
|
||||
|
||||
rcupdate.rcu_self_test= [KNL]
|
||||
Run the RCU early boot self tests
|
||||
|
||||
rcupdate.rcu_self_test_bh= [KNL]
|
||||
Run the RCU bh early boot self tests
|
||||
|
||||
rcupdate.rcu_self_test_sched= [KNL]
|
||||
Run the RCU sched early boot self tests
|
||||
|
||||
rdinit= [KNL]
|
||||
Format: <full_path>
|
||||
Run specified binary instead of /init from the ramdisk,
|
||||
@ -3621,7 +3637,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
|
||||
usb-storage.delay_use=
|
||||
[UMS] The delay in seconds before a new device is
|
||||
scanned for Logical Units (default 5).
|
||||
scanned for Logical Units (default 1).
|
||||
|
||||
usb-storage.quirks=
|
||||
[UMS] A list of quirks entries to supplement or
|
||||
|
166
Documentation/locking/lglock.txt
Normal file
166
Documentation/locking/lglock.txt
Normal file
@ -0,0 +1,166 @@
|
||||
lglock - local/global locks for mostly local access patterns
|
||||
------------------------------------------------------------
|
||||
|
||||
Origin: Nick Piggin's VFS scalability series introduced during
|
||||
2.6.35++ [1] [2]
|
||||
Location: kernel/locking/lglock.c
|
||||
include/linux/lglock.h
|
||||
Users: currently only the VFS and stop_machine related code
|
||||
|
||||
Design Goal:
|
||||
------------
|
||||
|
||||
Improve scalability of globally used large data sets that are
|
||||
distributed over all CPUs as per_cpu elements.
|
||||
|
||||
To manage global data structures that are partitioned over all CPUs
|
||||
as per_cpu elements but can be mostly handled by CPU local actions
|
||||
lglock will be used where the majority of accesses are cpu local
|
||||
reading and occasional cpu local writing with very infrequent
|
||||
global write access.
|
||||
|
||||
|
||||
* deal with things locally whenever possible
|
||||
- very fast access to the local per_cpu data
|
||||
- reasonably fast access to specific per_cpu data on a different
|
||||
CPU
|
||||
* while making global action possible when needed
|
||||
- by expensive access to all CPUs locks - effectively
|
||||
resulting in a globally visible critical section.
|
||||
|
||||
Design:
|
||||
-------
|
||||
|
||||
Basically it is an array of per_cpu spinlocks with the
|
||||
lg_local_lock/unlock accessing the local CPUs lock object and the
|
||||
lg_local_lock_cpu/unlock_cpu accessing a remote CPUs lock object
|
||||
the lg_local_lock has to disable preemption as migration protection so
|
||||
that the reference to the local CPUs lock does not go out of scope.
|
||||
Due to the lg_local_lock/unlock only touching cpu-local resources it
|
||||
is fast. Taking the local lock on a different CPU will be more
|
||||
expensive but still relatively cheap.
|
||||
|
||||
One can relax the migration constraints by acquiring the current
|
||||
CPUs lock with lg_local_lock_cpu, remember the cpu, and release that
|
||||
lock at the end of the critical section even if migrated. This should
|
||||
give most of the performance benefits without inhibiting migration
|
||||
though needs careful considerations for nesting of lglocks and
|
||||
consideration of deadlocks with lg_global_lock.
|
||||
|
||||
The lg_global_lock/unlock locks all underlying spinlocks of all
|
||||
possible CPUs (including those off-line). The preemption disable/enable
|
||||
are needed in the non-RT kernels to prevent deadlocks like:
|
||||
|
||||
on cpu 1
|
||||
|
||||
task A task B
|
||||
lg_global_lock
|
||||
got cpu 0 lock
|
||||
<<<< preempt <<<<
|
||||
lg_local_lock_cpu for cpu 0
|
||||
spin on cpu 0 lock
|
||||
|
||||
On -RT this deadlock scenario is resolved by the arch_spin_locks in the
|
||||
lglocks being replaced by rt_mutexes which resolve the above deadlock
|
||||
by boosting the lock-holder.
|
||||
|
||||
|
||||
Implementation:
|
||||
---------------
|
||||
|
||||
The initial lglock implementation from Nick Piggin used some complex
|
||||
macros to generate the lglock/brlock in lglock.h - they were later
|
||||
turned into a set of functions by Andi Kleen [7]. The change to functions
|
||||
was motivated by the presence of multiple lock users and also by them
|
||||
being easier to maintain than the generating macros. This change to
|
||||
functions is also the basis to eliminated the restriction of not
|
||||
being initializeable in kernel modules (the remaining problem is that
|
||||
locks are not explicitly initialized - see lockdep-design.txt)
|
||||
|
||||
Declaration and initialization:
|
||||
-------------------------------
|
||||
|
||||
#include <linux/lglock.h>
|
||||
|
||||
DEFINE_LGLOCK(name)
|
||||
or:
|
||||
DEFINE_STATIC_LGLOCK(name);
|
||||
|
||||
lg_lock_init(&name, "lockdep_name_string");
|
||||
|
||||
on UP this is mapped to DEFINE_SPINLOCK(name) in both cases, note
|
||||
also that as of 3.18-rc6 all declaration in use are of the _STATIC_
|
||||
variant (and it seems that the non-static was never in use).
|
||||
lg_lock_init is initializing the lockdep map only.
|
||||
|
||||
Usage:
|
||||
------
|
||||
|
||||
From the locking semantics it is a spinlock. It could be called a
|
||||
locality aware spinlock. lg_local_* behaves like a per_cpu
|
||||
spinlock and lg_global_* like a global spinlock.
|
||||
No surprises in the API.
|
||||
|
||||
lg_local_lock(*lglock);
|
||||
access to protected per_cpu object on this CPU
|
||||
lg_local_unlock(*lglock);
|
||||
|
||||
lg_local_lock_cpu(*lglock, cpu);
|
||||
access to protected per_cpu object on other CPU cpu
|
||||
lg_local_unlock_cpu(*lglock, cpu);
|
||||
|
||||
lg_global_lock(*lglock);
|
||||
access all protected per_cpu objects on all CPUs
|
||||
lg_global_unlock(*lglock);
|
||||
|
||||
There are no _trylock variants of the lglocks.
|
||||
|
||||
Note that the lg_global_lock/unlock has to iterate over all possible
|
||||
CPUs rather than the actually present CPUs or a CPU could go off-line
|
||||
with a held lock [4] and that makes it very expensive. A discussion on
|
||||
these issues can be found at [5]
|
||||
|
||||
Constraints:
|
||||
------------
|
||||
|
||||
* currently the declaration of lglocks in kernel modules is not
|
||||
possible, though this should be doable with little change.
|
||||
* lglocks are not recursive.
|
||||
* suitable for code that can do most operations on the CPU local
|
||||
data and will very rarely need the global lock
|
||||
* lg_global_lock/unlock is *very* expensive and does not scale
|
||||
* on UP systems all lg_* primitives are simply spinlocks
|
||||
* in PREEMPT_RT the spinlock becomes an rt-mutex and can sleep but
|
||||
does not change the tasks state while sleeping [6].
|
||||
* in PREEMPT_RT the preempt_disable/enable in lg_local_lock/unlock
|
||||
is downgraded to a migrate_disable/enable, the other
|
||||
preempt_disable/enable are downgraded to barriers [6].
|
||||
The deadlock noted for non-RT above is resolved due to rt_mutexes
|
||||
boosting the lock-holder in this case which arch_spin_locks do
|
||||
not do.
|
||||
|
||||
lglocks were designed for very specific problems in the VFS and probably
|
||||
only are the right answer in these corner cases. Any new user that looks
|
||||
at lglocks probably wants to look at the seqlock and RCU alternatives as
|
||||
her first choice. There are also efforts to resolve the RCU issues that
|
||||
currently prevent using RCU in place of view remaining lglocks.
|
||||
|
||||
Note on brlock history:
|
||||
-----------------------
|
||||
|
||||
The 'Big Reader' read-write spinlocks were originally introduced by
|
||||
Ingo Molnar in 2000 (2.4/2.5 kernel series) and removed in 2003. They
|
||||
later were introduced by the VFS scalability patch set in 2.6 series
|
||||
again as the "big reader lock" brlock [2] variant of lglock which has
|
||||
been replaced by seqlock primitives or by RCU based primitives in the
|
||||
3.13 kernel series as was suggested in [3] in 2003. The brlock was
|
||||
entirely removed in the 3.13 kernel series.
|
||||
|
||||
Link: 1 http://lkml.org/lkml/2010/8/2/81
|
||||
Link: 2 http://lwn.net/Articles/401738/
|
||||
Link: 3 http://lkml.org/lkml/2003/3/9/205
|
||||
Link: 4 https://lkml.org/lkml/2011/8/24/185
|
||||
Link: 5 http://lkml.org/lkml/2011/12/18/189
|
||||
Link: 6 https://www.kernel.org/pub/linux/kernel/projects/rt/
|
||||
patch series - lglocks-rt.patch.patch
|
||||
Link: 7 http://lkml.org/lkml/2012/3/5/26
|
@ -121,22 +121,22 @@ For example, consider the following sequence of events:
|
||||
The set of accesses as seen by the memory system in the middle can be arranged
|
||||
in 24 different combinations:
|
||||
|
||||
STORE A=3, STORE B=4, x=LOAD A->3, y=LOAD B->4
|
||||
STORE A=3, STORE B=4, y=LOAD B->4, x=LOAD A->3
|
||||
STORE A=3, x=LOAD A->3, STORE B=4, y=LOAD B->4
|
||||
STORE A=3, x=LOAD A->3, y=LOAD B->2, STORE B=4
|
||||
STORE A=3, y=LOAD B->2, STORE B=4, x=LOAD A->3
|
||||
STORE A=3, y=LOAD B->2, x=LOAD A->3, STORE B=4
|
||||
STORE B=4, STORE A=3, x=LOAD A->3, y=LOAD B->4
|
||||
STORE A=3, STORE B=4, y=LOAD A->3, x=LOAD B->4
|
||||
STORE A=3, STORE B=4, x=LOAD B->4, y=LOAD A->3
|
||||
STORE A=3, y=LOAD A->3, STORE B=4, x=LOAD B->4
|
||||
STORE A=3, y=LOAD A->3, x=LOAD B->2, STORE B=4
|
||||
STORE A=3, x=LOAD B->2, STORE B=4, y=LOAD A->3
|
||||
STORE A=3, x=LOAD B->2, y=LOAD A->3, STORE B=4
|
||||
STORE B=4, STORE A=3, y=LOAD A->3, x=LOAD B->4
|
||||
STORE B=4, ...
|
||||
...
|
||||
|
||||
and can thus result in four different combinations of values:
|
||||
|
||||
x == 1, y == 2
|
||||
x == 1, y == 4
|
||||
x == 3, y == 2
|
||||
x == 3, y == 4
|
||||
x == 2, y == 1
|
||||
x == 2, y == 3
|
||||
x == 4, y == 1
|
||||
x == 4, y == 3
|
||||
|
||||
|
||||
Furthermore, the stores committed by a CPU to the memory system may not be
|
||||
@ -694,6 +694,24 @@ Please note once again that the stores to 'b' differ. If they were
|
||||
identical, as noted earlier, the compiler could pull this store outside
|
||||
of the 'if' statement.
|
||||
|
||||
You must also be careful not to rely too much on boolean short-circuit
|
||||
evaluation. Consider this example:
|
||||
|
||||
q = ACCESS_ONCE(a);
|
||||
if (a || 1 > 0)
|
||||
ACCESS_ONCE(b) = 1;
|
||||
|
||||
Because the second condition is always true, the compiler can transform
|
||||
this example as following, defeating control dependency:
|
||||
|
||||
q = ACCESS_ONCE(a);
|
||||
ACCESS_ONCE(b) = 1;
|
||||
|
||||
This example underscores the need to ensure that the compiler cannot
|
||||
out-guess your code. More generally, although ACCESS_ONCE() does force
|
||||
the compiler to actually emit code for a given load, it does not force
|
||||
the compiler to use the results.
|
||||
|
||||
Finally, control dependencies do -not- provide transitivity. This is
|
||||
demonstrated by two related examples, with the initial values of
|
||||
x and y both being zero:
|
||||
@ -2465,10 +2483,15 @@ functions:
|
||||
Please refer to the PCI specification for more information on interactions
|
||||
between PCI transactions.
|
||||
|
||||
(*) readX_relaxed()
|
||||
(*) readX_relaxed(), writeX_relaxed()
|
||||
|
||||
These are similar to readX(), but are not guaranteed to be ordered in any
|
||||
way. Be aware that there is no I/O read barrier available.
|
||||
These are similar to readX() and writeX(), but provide weaker memory
|
||||
ordering guarantees. Specifically, they do not guarantee ordering with
|
||||
respect to normal memory accesses (e.g. DMA buffers) nor do they guarantee
|
||||
ordering with respect to LOCK or UNLOCK operations. If the latter is
|
||||
required, an mmiowb() barrier can be used. Note that relaxed accesses to
|
||||
the same peripheral are guaranteed to be ordered with respect to each
|
||||
other.
|
||||
|
||||
(*) ioreadX(), iowriteX()
|
||||
|
||||
|
@ -56,6 +56,13 @@ ip_forward_use_pmtu - BOOLEAN
|
||||
0 - disabled
|
||||
1 - enabled
|
||||
|
||||
fwmark_reflect - BOOLEAN
|
||||
Controls the fwmark of kernel-generated IPv4 reply packets that are not
|
||||
associated with a socket for example, TCP RSTs or ICMP echo replies).
|
||||
If unset, these packets have a fwmark of zero. If set, they have the
|
||||
fwmark of the packet they are replying to.
|
||||
Default: 0
|
||||
|
||||
route/max_size - INTEGER
|
||||
Maximum number of routes allowed in the kernel. Increase
|
||||
this when using large numbers of interfaces and/or routes.
|
||||
@ -1201,6 +1208,13 @@ conf/all/forwarding - BOOLEAN
|
||||
proxy_ndp - BOOLEAN
|
||||
Do proxy ndp.
|
||||
|
||||
fwmark_reflect - BOOLEAN
|
||||
Controls the fwmark of kernel-generated IPv6 reply packets that are not
|
||||
associated with a socket for example, TCP RSTs or ICMPv6 echo replies).
|
||||
If unset, these packets have a fwmark of zero. If set, they have the
|
||||
fwmark of the packet they are replying to.
|
||||
Default: 0
|
||||
|
||||
conf/interface/*:
|
||||
Change special settings per interface.
|
||||
|
||||
|
@ -136,7 +136,7 @@ SOF_TIMESTAMPING_OPT_ID:
|
||||
|
||||
This option is implemented only for transmit timestamps. There, the
|
||||
timestamp is always looped along with a struct sock_extended_err.
|
||||
The option modifies field ee_info to pass an id that is unique
|
||||
The option modifies field ee_data to pass an id that is unique
|
||||
among all possibly concurrently outstanding timestamp requests for
|
||||
that socket. In practice, it is a monotonically increasing u32
|
||||
(that wraps).
|
||||
|
23
Documentation/nios2/README
Normal file
23
Documentation/nios2/README
Normal file
@ -0,0 +1,23 @@
|
||||
Linux on the Nios II architecture
|
||||
=================================
|
||||
|
||||
This is a port of Linux to Nios II (nios2) processor.
|
||||
|
||||
In order to compile for Nios II, you need a version of GCC with support for the generic
|
||||
system call ABI. Please see this link for more information on how compiling and booting
|
||||
software for the Nios II platform:
|
||||
http://www.rocketboards.org/foswiki/Documentation/NiosIILinuxUserManual
|
||||
|
||||
For reference, please see the following link:
|
||||
http://www.altera.com/literature/lit-nio2.jsp
|
||||
|
||||
What is Nios II?
|
||||
================
|
||||
Nios II is a 32-bit embedded-processor architecture designed specifically for the
|
||||
Altera family of FPGAs. In order to support Linux, Nios II needs to be configured
|
||||
with MMU and hardware multiplier enabled.
|
||||
|
||||
Nios II ABI
|
||||
===========
|
||||
Please refer to chapter "Application Binary Interface" in Nios II Processor Reference
|
||||
Handbook.
|
@ -226,9 +226,6 @@ static int register_sas_ha(struct my_sas_ha *my_ha)
|
||||
my_ha->sas_ha.lldd_dev_found = my_dev_found;
|
||||
my_ha->sas_ha.lldd_dev_gone = my_dev_gone;
|
||||
|
||||
my_ha->sas_ha.lldd_max_execute_num = lldd_max_execute_num; (1)
|
||||
|
||||
my_ha->sas_ha.lldd_queue_size = ha_can_queue;
|
||||
my_ha->sas_ha.lldd_execute_task = my_execute_task;
|
||||
|
||||
my_ha->sas_ha.lldd_abort_task = my_abort_task;
|
||||
@ -247,28 +244,6 @@ static int register_sas_ha(struct my_sas_ha *my_ha)
|
||||
return sas_register_ha(&my_ha->sas_ha);
|
||||
}
|
||||
|
||||
(1) This is normally a LLDD parameter, something of the
|
||||
lines of a task collector. What it tells the SAS Layer is
|
||||
whether the SAS layer should run in Direct Mode (default:
|
||||
value 0 or 1) or Task Collector Mode (value greater than 1).
|
||||
|
||||
In Direct Mode, the SAS Layer calls Execute Task as soon as
|
||||
it has a command to send to the SDS, _and_ this is a single
|
||||
command, i.e. not linked.
|
||||
|
||||
Some hardware (e.g. aic94xx) has the capability to DMA more
|
||||
than one task at a time (interrupt) from host memory. Task
|
||||
Collector Mode is an optional feature for HAs which support
|
||||
this in their hardware. (Again, it is completely optional
|
||||
even if your hardware supports it.)
|
||||
|
||||
In Task Collector Mode, the SAS Layer would do _natural_
|
||||
coalescing of tasks and at the appropriate moment it would
|
||||
call your driver to DMA more than one task in a single HA
|
||||
interrupt. DMBS may want to use this by insmod/modprobe
|
||||
setting the lldd_max_execute_num to something greater than
|
||||
1.
|
||||
|
||||
(2) SAS 1.1 does not define I_T Nexus Reset TMF.
|
||||
|
||||
Events
|
||||
@ -325,71 +300,22 @@ PHYE_SPINUP_HOLD -- SATA is present, COMWAKE not sent.
|
||||
|
||||
The Execute Command SCSI RPC:
|
||||
|
||||
int (*lldd_execute_task)(struct sas_task *, int num,
|
||||
unsigned long gfp_flags);
|
||||
int (*lldd_execute_task)(struct sas_task *, gfp_t gfp_flags);
|
||||
|
||||
Used to queue a task to the SAS LLDD. @task is the tasks to
|
||||
be executed. @num should be the number of tasks being
|
||||
queued at this function call (they are linked listed via
|
||||
task::list), @gfp_mask should be the gfp_mask defining the
|
||||
context of the caller.
|
||||
Used to queue a task to the SAS LLDD. @task is the task to be executed.
|
||||
@gfp_mask is the gfp_mask defining the context of the caller.
|
||||
|
||||
This function should implement the Execute Command SCSI RPC,
|
||||
or if you're sending a SCSI Task as linked commands, you
|
||||
should also use this function.
|
||||
|
||||
That is, when lldd_execute_task() is called, the command(s)
|
||||
That is, when lldd_execute_task() is called, the command
|
||||
go out on the transport *immediately*. There is *no*
|
||||
queuing of any sort and at any level in a SAS LLDD.
|
||||
|
||||
The use of task::list is two-fold, one for linked commands,
|
||||
the other discussed below.
|
||||
|
||||
It is possible to queue up more than one task at a time, by
|
||||
initializing the list element of struct sas_task, and
|
||||
passing the number of tasks enlisted in this manner in num.
|
||||
|
||||
Returns: -SAS_QUEUE_FULL, -ENOMEM, nothing was queued;
|
||||
0, the task(s) were queued.
|
||||
|
||||
If you want to pass num > 1, then either
|
||||
A) you're the only caller of this function and keep track
|
||||
of what you've queued to the LLDD, or
|
||||
B) you know what you're doing and have a strategy of
|
||||
retrying.
|
||||
|
||||
As opposed to queuing one task at a time (function call),
|
||||
batch queuing of tasks, by having num > 1, greatly
|
||||
simplifies LLDD code, sequencer code, and _hardware design_,
|
||||
and has some performance advantages in certain situations
|
||||
(DBMS).
|
||||
|
||||
The LLDD advertises if it can take more than one command at
|
||||
a time at lldd_execute_task(), by setting the
|
||||
lldd_max_execute_num parameter (controlled by "collector"
|
||||
module parameter in aic94xx SAS LLDD).
|
||||
|
||||
You should leave this to the default 1, unless you know what
|
||||
you're doing.
|
||||
|
||||
This is a function of the LLDD, to which the SAS layer can
|
||||
cater to.
|
||||
|
||||
int lldd_queue_size
|
||||
The host adapter's queue size. This is the maximum
|
||||
number of commands the lldd can have pending to domain
|
||||
devices on behalf of all upper layers submitting through
|
||||
lldd_execute_task().
|
||||
|
||||
You really want to set this to something (much) larger than
|
||||
1.
|
||||
|
||||
This _really_ has absolutely nothing to do with queuing.
|
||||
There is no queuing in SAS LLDDs.
|
||||
|
||||
struct sas_task {
|
||||
dev -- the device this task is destined to
|
||||
list -- must be initialized (INIT_LIST_HEAD)
|
||||
task_proto -- _one_ of enum sas_proto
|
||||
scatter -- pointer to scatter gather list array
|
||||
num_scatter -- number of elements in scatter
|
||||
|
@ -149,7 +149,7 @@ scsi_add_host() ---->
|
||||
scsi_scan_host() -------+
|
||||
|
|
||||
slave_alloc()
|
||||
slave_configure() --> scsi_adjust_queue_depth()
|
||||
slave_configure() --> scsi_change_queue_depth()
|
||||
|
|
||||
slave_alloc()
|
||||
slave_configure()
|
||||
@ -159,7 +159,7 @@ scsi_scan_host() -------+
|
||||
------------------------------------------------------------
|
||||
|
||||
If the LLD wants to adjust the default queue settings, it can invoke
|
||||
scsi_adjust_queue_depth() in its slave_configure() routine.
|
||||
scsi_change_queue_depth() in its slave_configure() routine.
|
||||
|
||||
*** For scsi devices that the mid level tries to scan but do not
|
||||
respond, a slave_alloc(), slave_destroy() pair is called.
|
||||
@ -203,7 +203,7 @@ LLD mid level LLD
|
||||
scsi_add_device() ------+
|
||||
|
|
||||
slave_alloc()
|
||||
slave_configure() [--> scsi_adjust_queue_depth()]
|
||||
slave_configure() [--> scsi_change_queue_depth()]
|
||||
------------------------------------------------------------
|
||||
|
||||
In a similar fashion, an LLD may become aware that a SCSI device has been
|
||||
@ -261,7 +261,7 @@ init_this_scsi_driver() ----+
|
||||
| scsi_register()
|
||||
|
|
||||
slave_alloc()
|
||||
slave_configure() --> scsi_adjust_queue_depth()
|
||||
slave_configure() --> scsi_change_queue_depth()
|
||||
slave_alloc() ***
|
||||
slave_destroy() ***
|
||||
|
|
||||
@ -271,9 +271,9 @@ init_this_scsi_driver() ----+
|
||||
slave_destroy() ***
|
||||
------------------------------------------------------------
|
||||
|
||||
The mid level invokes scsi_adjust_queue_depth() with tagged queuing off and
|
||||
"cmd_per_lun" for that host as the queue length. These settings can be
|
||||
overridden by a slave_configure() supplied by the LLD.
|
||||
The mid level invokes scsi_change_queue_depth() with "cmd_per_lun" for that
|
||||
host as the queue length. These settings can be overridden by a
|
||||
slave_configure() supplied by the LLD.
|
||||
|
||||
*** For scsi devices that the mid level tries to scan but do not
|
||||
respond, a slave_alloc(), slave_destroy() pair is called.
|
||||
@ -366,13 +366,11 @@ is initialized. The functions below are listed alphabetically and their
|
||||
names all start with "scsi_".
|
||||
|
||||
Summary:
|
||||
scsi_activate_tcq - turn on tag command queueing
|
||||
scsi_add_device - creates new scsi device (lu) instance
|
||||
scsi_add_host - perform sysfs registration and set up transport class
|
||||
scsi_adjust_queue_depth - change the queue depth on a SCSI device
|
||||
scsi_change_queue_depth - change the queue depth on a SCSI device
|
||||
scsi_bios_ptable - return copy of block device's partition table
|
||||
scsi_block_requests - prevent further commands being queued to given host
|
||||
scsi_deactivate_tcq - turn off tag command queueing
|
||||
scsi_host_alloc - return a new scsi_host instance whose refcount==1
|
||||
scsi_host_get - increments Scsi_Host instance's refcount
|
||||
scsi_host_put - decrements Scsi_Host instance's refcount (free if 0)
|
||||
@ -389,24 +387,6 @@ Summary:
|
||||
|
||||
Details:
|
||||
|
||||
/**
|
||||
* scsi_activate_tcq - turn on tag command queueing ("ordered" task attribute)
|
||||
* @sdev: device to turn on TCQ for
|
||||
* @depth: queue depth
|
||||
*
|
||||
* Returns nothing
|
||||
*
|
||||
* Might block: no
|
||||
*
|
||||
* Notes: Eventually, it is hoped depth would be the maximum depth
|
||||
* the device could cope with and the real queue depth
|
||||
* would be adjustable from 0 to depth.
|
||||
*
|
||||
* Defined (inline) in: include/scsi/scsi_tcq.h
|
||||
**/
|
||||
void scsi_activate_tcq(struct scsi_device *sdev, int depth)
|
||||
|
||||
|
||||
/**
|
||||
* scsi_add_device - creates new scsi device (lu) instance
|
||||
* @shost: pointer to scsi host instance
|
||||
@ -456,11 +436,8 @@ int scsi_add_host(struct Scsi_Host *shost, struct device * dev)
|
||||
|
||||
|
||||
/**
|
||||
* scsi_adjust_queue_depth - allow LLD to change queue depth on a SCSI device
|
||||
* scsi_change_queue_depth - allow LLD to change queue depth on a SCSI device
|
||||
* @sdev: pointer to SCSI device to change queue depth on
|
||||
* @tagged: 0 - no tagged queuing
|
||||
* MSG_SIMPLE_TAG - simple tagged queuing
|
||||
* MSG_ORDERED_TAG - ordered tagged queuing
|
||||
* @tags Number of tags allowed if tagged queuing enabled,
|
||||
* or number of commands the LLD can queue up
|
||||
* in non-tagged mode (as per cmd_per_lun).
|
||||
@ -471,15 +448,12 @@ int scsi_add_host(struct Scsi_Host *shost, struct device * dev)
|
||||
*
|
||||
* Notes: Can be invoked any time on a SCSI device controlled by this
|
||||
* LLD. [Specifically during and after slave_configure() and prior to
|
||||
* slave_destroy().] Can safely be invoked from interrupt code. Actual
|
||||
* queue depth change may be delayed until the next command is being
|
||||
* processed. See also scsi_activate_tcq() and scsi_deactivate_tcq().
|
||||
* slave_destroy().] Can safely be invoked from interrupt code.
|
||||
*
|
||||
* Defined in: drivers/scsi/scsi.c [see source code for more notes]
|
||||
*
|
||||
**/
|
||||
void scsi_adjust_queue_depth(struct scsi_device * sdev, int tagged,
|
||||
int tags)
|
||||
int scsi_change_queue_depth(struct scsi_device *sdev, int tags)
|
||||
|
||||
|
||||
/**
|
||||
@ -514,20 +488,6 @@ unsigned char *scsi_bios_ptable(struct block_device *dev)
|
||||
void scsi_block_requests(struct Scsi_Host * shost)
|
||||
|
||||
|
||||
/**
|
||||
* scsi_deactivate_tcq - turn off tag command queueing
|
||||
* @sdev: device to turn off TCQ for
|
||||
* @depth: queue depth (stored in sdev)
|
||||
*
|
||||
* Returns nothing
|
||||
*
|
||||
* Might block: no
|
||||
*
|
||||
* Defined (inline) in: include/scsi/scsi_tcq.h
|
||||
**/
|
||||
void scsi_deactivate_tcq(struct scsi_device *sdev, int depth)
|
||||
|
||||
|
||||
/**
|
||||
* scsi_host_alloc - create a scsi host adapter instance and perform basic
|
||||
* initialization.
|
||||
@ -1254,7 +1214,7 @@ of interest:
|
||||
for disk firmware uploads.
|
||||
cmd_per_lun - maximum number of commands that can be queued on devices
|
||||
controlled by the host. Overridden by LLD calls to
|
||||
scsi_adjust_queue_depth().
|
||||
scsi_change_queue_depth().
|
||||
unchecked_isa_dma - 1=>only use bottom 16 MB of ram (ISA DMA addressing
|
||||
restriction), 0=>can use full 32 bit (or better) DMA
|
||||
address space
|
||||
@ -1294,7 +1254,7 @@ struct scsi_cmnd
|
||||
Instances of this structure convey SCSI commands to the LLD and responses
|
||||
back to the mid level. The SCSI mid level will ensure that no more SCSI
|
||||
commands become queued against the LLD than are indicated by
|
||||
scsi_adjust_queue_depth() (or struct Scsi_Host::cmd_per_lun). There will
|
||||
scsi_change_queue_depth() (or struct Scsi_Host::cmd_per_lun). There will
|
||||
be at least one instance of struct scsi_cmnd available for each SCSI device.
|
||||
Members of interest:
|
||||
cmnd - array containing SCSI command
|
||||
|
@ -506,9 +506,11 @@ user does not request data that far.)
|
||||
|
||||
DEBUGGING HINTS
|
||||
|
||||
To enable debugging messages, edit st.c and #define DEBUG 1. As seen
|
||||
above, debugging can be switched off with an ioctl if debugging is
|
||||
compiled into the driver. The debugging output is not voluminous.
|
||||
Debugging code is now compiled in by default but debugging is turned off
|
||||
with the kernel module parameter debug_flag defaulting to 0. Debugging
|
||||
can still be switched on and off with an ioctl. To enable debug at
|
||||
module load time add debug_flag=1 to the module load options, the
|
||||
debugging output is not voluminous.
|
||||
|
||||
If the tape seems to hang, I would be very interested to hear where
|
||||
the driver is waiting. With the command 'ps -l' you can see the state
|
||||
|
21
Documentation/scsi/wd719x.txt
Normal file
21
Documentation/scsi/wd719x.txt
Normal file
@ -0,0 +1,21 @@
|
||||
Driver for Western Digital WD7193, WD7197 and WD7296 SCSI cards
|
||||
---------------------------------------------------------------
|
||||
|
||||
The card requires firmware that can be cut out of the Windows NT driver that
|
||||
can be downloaded from WD at:
|
||||
http://support.wdc.com/product/download.asp?groupid=801&sid=27&lang=en
|
||||
|
||||
There is no license anywhere in the file or on the page - so the firmware
|
||||
probably cannot be added to linux-firmware.
|
||||
|
||||
This script downloads and extracts the firmware, creating wd719x-risc.bin and
|
||||
d719x-wcs.bin files. Put them in /lib/firmware/.
|
||||
|
||||
#!/bin/sh
|
||||
wget http://support.wdc.com/download/archive/pciscsi.exe
|
||||
lha xi pciscsi.exe pci-scsi.exe
|
||||
lha xi pci-scsi.exe nt/wd7296a.sys
|
||||
rm pci-scsi.exe
|
||||
dd if=wd7296a.sys of=wd719x-risc.bin bs=1 skip=5760 count=14336
|
||||
dd if=wd7296a.sys of=wd719x-wcs.bin bs=1 skip=20096 count=514
|
||||
rm wd7296a.sys
|
@ -221,12 +221,11 @@ ccs_out_mode: specify the allowed video output crop/compose/scaling combination
|
||||
key, not quality.
|
||||
|
||||
multiplanar: select whether each device instance supports multi-planar formats,
|
||||
and thus the V4L2 multi-planar API. By default the first device instance
|
||||
is single-planar, the second multi-planar, and it keeps alternating.
|
||||
and thus the V4L2 multi-planar API. By default device instances are
|
||||
single-planar.
|
||||
|
||||
This module option can override that for each instance. Values are:
|
||||
|
||||
0: use alternating single and multi-planar devices.
|
||||
1: this is a single-planar instance.
|
||||
2: this is a multi-planar instance.
|
||||
|
||||
@ -975,9 +974,8 @@ is set, then the alpha component is only used for the color red and set to
|
||||
0 otherwise.
|
||||
|
||||
The driver has to be configured to support the multiplanar formats. By default
|
||||
the first driver instance is single-planar, the second is multi-planar, and it
|
||||
keeps alternating. This can be changed by setting the multiplanar module option,
|
||||
see section 1 for more details on that option.
|
||||
the driver instances are single-planar. This can be changed by setting the
|
||||
multiplanar module option, see section 1 for more details on that option.
|
||||
|
||||
If the driver instance is using the multiplanar formats/API, then the first
|
||||
single planar format (YUYV) and the multiplanar NV16M and NV61M formats the
|
||||
@ -1021,7 +1019,7 @@ the output overlay for the video output, turn on video looping and capture
|
||||
to see the blended framebuffer overlay that's being written to by the second
|
||||
instance. This setup would require the following commands:
|
||||
|
||||
$ sudo modprobe vivid n_devs=2 node_types=0x10101,0x1 multiplanar=1,1
|
||||
$ sudo modprobe vivid n_devs=2 node_types=0x10101,0x1
|
||||
$ v4l2-ctl -d1 --find-fb
|
||||
/dev/fb1 is the framebuffer associated with base address 0x12800000
|
||||
$ sudo v4l2-ctl -d2 --set-fbuf fb=1
|
||||
|
234
Documentation/x86/intel_mpx.txt
Normal file
234
Documentation/x86/intel_mpx.txt
Normal file
@ -0,0 +1,234 @@
|
||||
1. Intel(R) MPX Overview
|
||||
========================
|
||||
|
||||
Intel(R) Memory Protection Extensions (Intel(R) MPX) is a new capability
|
||||
introduced into Intel Architecture. Intel MPX provides hardware features
|
||||
that can be used in conjunction with compiler changes to check memory
|
||||
references, for those references whose compile-time normal intentions are
|
||||
usurped at runtime due to buffer overflow or underflow.
|
||||
|
||||
For more information, please refer to Intel(R) Architecture Instruction
|
||||
Set Extensions Programming Reference, Chapter 9: Intel(R) Memory Protection
|
||||
Extensions.
|
||||
|
||||
Note: Currently no hardware with MPX ISA is available but it is always
|
||||
possible to use SDE (Intel(R) Software Development Emulator) instead, which
|
||||
can be downloaded from
|
||||
http://software.intel.com/en-us/articles/intel-software-development-emulator
|
||||
|
||||
|
||||
2. How to get the advantage of MPX
|
||||
==================================
|
||||
|
||||
For MPX to work, changes are required in the kernel, binutils and compiler.
|
||||
No source changes are required for applications, just a recompile.
|
||||
|
||||
There are a lot of moving parts of this to all work right. The following
|
||||
is how we expect the compiler, application and kernel to work together.
|
||||
|
||||
1) Application developer compiles with -fmpx. The compiler will add the
|
||||
instrumentation as well as some setup code called early after the app
|
||||
starts. New instruction prefixes are noops for old CPUs.
|
||||
2) That setup code allocates (virtual) space for the "bounds directory",
|
||||
points the "bndcfgu" register to the directory and notifies the kernel
|
||||
(via the new prctl(PR_MPX_ENABLE_MANAGEMENT)) that the app will be using
|
||||
MPX.
|
||||
3) The kernel detects that the CPU has MPX, allows the new prctl() to
|
||||
succeed, and notes the location of the bounds directory. Userspace is
|
||||
expected to keep the bounds directory at that locationWe note it
|
||||
instead of reading it each time because the 'xsave' operation needed
|
||||
to access the bounds directory register is an expensive operation.
|
||||
4) If the application needs to spill bounds out of the 4 registers, it
|
||||
issues a bndstx instruction. Since the bounds directory is empty at
|
||||
this point, a bounds fault (#BR) is raised, the kernel allocates a
|
||||
bounds table (in the user address space) and makes the relevant entry
|
||||
in the bounds directory point to the new table.
|
||||
5) If the application violates the bounds specified in the bounds registers,
|
||||
a separate kind of #BR is raised which will deliver a signal with
|
||||
information about the violation in the 'struct siginfo'.
|
||||
6) Whenever memory is freed, we know that it can no longer contain valid
|
||||
pointers, and we attempt to free the associated space in the bounds
|
||||
tables. If an entire table becomes unused, we will attempt to free
|
||||
the table and remove the entry in the directory.
|
||||
|
||||
To summarize, there are essentially three things interacting here:
|
||||
|
||||
GCC with -fmpx:
|
||||
* enables annotation of code with MPX instructions and prefixes
|
||||
* inserts code early in the application to call in to the "gcc runtime"
|
||||
GCC MPX Runtime:
|
||||
* Checks for hardware MPX support in cpuid leaf
|
||||
* allocates virtual space for the bounds directory (malloc() essentially)
|
||||
* points the hardware BNDCFGU register at the directory
|
||||
* calls a new prctl(PR_MPX_ENABLE_MANAGEMENT) to notify the kernel to
|
||||
start managing the bounds directories
|
||||
Kernel MPX Code:
|
||||
* Checks for hardware MPX support in cpuid leaf
|
||||
* Handles #BR exceptions and sends SIGSEGV to the app when it violates
|
||||
bounds, like during a buffer overflow.
|
||||
* When bounds are spilled in to an unallocated bounds table, the kernel
|
||||
notices in the #BR exception, allocates the virtual space, then
|
||||
updates the bounds directory to point to the new table. It keeps
|
||||
special track of the memory with a VM_MPX flag.
|
||||
* Frees unused bounds tables at the time that the memory they described
|
||||
is unmapped.
|
||||
|
||||
|
||||
3. How does MPX kernel code work
|
||||
================================
|
||||
|
||||
Handling #BR faults caused by MPX
|
||||
---------------------------------
|
||||
|
||||
When MPX is enabled, there are 2 new situations that can generate
|
||||
#BR faults.
|
||||
* new bounds tables (BT) need to be allocated to save bounds.
|
||||
* bounds violation caused by MPX instructions.
|
||||
|
||||
We hook #BR handler to handle these two new situations.
|
||||
|
||||
On-demand kernel allocation of bounds tables
|
||||
--------------------------------------------
|
||||
|
||||
MPX only has 4 hardware registers for storing bounds information. If
|
||||
MPX-enabled code needs more than these 4 registers, it needs to spill
|
||||
them somewhere. It has two special instructions for this which allow
|
||||
the bounds to be moved between the bounds registers and some new "bounds
|
||||
tables".
|
||||
|
||||
#BR exceptions are a new class of exceptions just for MPX. They are
|
||||
similar conceptually to a page fault and will be raised by the MPX
|
||||
hardware during both bounds violations or when the tables are not
|
||||
present. The kernel handles those #BR exceptions for not-present tables
|
||||
by carving the space out of the normal processes address space and then
|
||||
pointing the bounds-directory over to it.
|
||||
|
||||
The tables need to be accessed and controlled by userspace because
|
||||
the instructions for moving bounds in and out of them are extremely
|
||||
frequent. They potentially happen every time a register points to
|
||||
memory. Any direct kernel involvement (like a syscall) to access the
|
||||
tables would obviously destroy performance.
|
||||
|
||||
Why not do this in userspace? MPX does not strictly require anything in
|
||||
the kernel. It can theoretically be done completely from userspace. Here
|
||||
are a few ways this could be done. We don't think any of them are practical
|
||||
in the real-world, but here they are.
|
||||
|
||||
Q: Can virtual space simply be reserved for the bounds tables so that we
|
||||
never have to allocate them?
|
||||
A: MPX-enabled application will possibly create a lot of bounds tables in
|
||||
process address space to save bounds information. These tables can take
|
||||
up huge swaths of memory (as much as 80% of the memory on the system)
|
||||
even if we clean them up aggressively. In the worst-case scenario, the
|
||||
tables can be 4x the size of the data structure being tracked. IOW, a
|
||||
1-page structure can require 4 bounds-table pages. An X-GB virtual
|
||||
area needs 4*X GB of virtual space, plus 2GB for the bounds directory.
|
||||
If we were to preallocate them for the 128TB of user virtual address
|
||||
space, we would need to reserve 512TB+2GB, which is larger than the
|
||||
entire virtual address space today. This means they can not be reserved
|
||||
ahead of time. Also, a single process's pre-popualated bounds directory
|
||||
consumes 2GB of virtual *AND* physical memory. IOW, it's completely
|
||||
infeasible to prepopulate bounds directories.
|
||||
|
||||
Q: Can we preallocate bounds table space at the same time memory is
|
||||
allocated which might contain pointers that might eventually need
|
||||
bounds tables?
|
||||
A: This would work if we could hook the site of each and every memory
|
||||
allocation syscall. This can be done for small, constrained applications.
|
||||
But, it isn't practical at a larger scale since a given app has no
|
||||
way of controlling how all the parts of the app might allocate memory
|
||||
(think libraries). The kernel is really the only place to intercept
|
||||
these calls.
|
||||
|
||||
Q: Could a bounds fault be handed to userspace and the tables allocated
|
||||
there in a signal handler intead of in the kernel?
|
||||
A: mmap() is not on the list of safe async handler functions and even
|
||||
if mmap() would work it still requires locking or nasty tricks to
|
||||
keep track of the allocation state there.
|
||||
|
||||
Having ruled out all of the userspace-only approaches for managing
|
||||
bounds tables that we could think of, we create them on demand in
|
||||
the kernel.
|
||||
|
||||
Decoding MPX instructions
|
||||
-------------------------
|
||||
|
||||
If a #BR is generated due to a bounds violation caused by MPX.
|
||||
We need to decode MPX instructions to get violation address and
|
||||
set this address into extended struct siginfo.
|
||||
|
||||
The _sigfault feild of struct siginfo is extended as follow:
|
||||
|
||||
87 /* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
|
||||
88 struct {
|
||||
89 void __user *_addr; /* faulting insn/memory ref. */
|
||||
90 #ifdef __ARCH_SI_TRAPNO
|
||||
91 int _trapno; /* TRAP # which caused the signal */
|
||||
92 #endif
|
||||
93 short _addr_lsb; /* LSB of the reported address */
|
||||
94 struct {
|
||||
95 void __user *_lower;
|
||||
96 void __user *_upper;
|
||||
97 } _addr_bnd;
|
||||
98 } _sigfault;
|
||||
|
||||
The '_addr' field refers to violation address, and new '_addr_and'
|
||||
field refers to the upper/lower bounds when a #BR is caused.
|
||||
|
||||
Glibc will be also updated to support this new siginfo. So user
|
||||
can get violation address and bounds when bounds violations occur.
|
||||
|
||||
Cleanup unused bounds tables
|
||||
----------------------------
|
||||
|
||||
When a BNDSTX instruction attempts to save bounds to a bounds directory
|
||||
entry marked as invalid, a #BR is generated. This is an indication that
|
||||
no bounds table exists for this entry. In this case the fault handler
|
||||
will allocate a new bounds table on demand.
|
||||
|
||||
Since the kernel allocated those tables on-demand without userspace
|
||||
knowledge, it is also responsible for freeing them when the associated
|
||||
mappings go away.
|
||||
|
||||
Here, the solution for this issue is to hook do_munmap() to check
|
||||
whether one process is MPX enabled. If yes, those bounds tables covered
|
||||
in the virtual address region which is being unmapped will be freed also.
|
||||
|
||||
Adding new prctl commands
|
||||
-------------------------
|
||||
|
||||
Two new prctl commands are added to enable and disable MPX bounds tables
|
||||
management in kernel.
|
||||
|
||||
155 #define PR_MPX_ENABLE_MANAGEMENT 43
|
||||
156 #define PR_MPX_DISABLE_MANAGEMENT 44
|
||||
|
||||
Runtime library in userspace is responsible for allocation of bounds
|
||||
directory. So kernel have to use XSAVE instruction to get the base
|
||||
of bounds directory from BNDCFG register.
|
||||
|
||||
But XSAVE is expected to be very expensive. In order to do performance
|
||||
optimization, we have to get the base of bounds directory and save it
|
||||
into struct mm_struct to be used in future during PR_MPX_ENABLE_MANAGEMENT
|
||||
command execution.
|
||||
|
||||
|
||||
4. Special rules
|
||||
================
|
||||
|
||||
1) If userspace is requesting help from the kernel to do the management
|
||||
of bounds tables, it may not create or modify entries in the bounds directory.
|
||||
|
||||
Certainly users can allocate bounds tables and forcibly point the bounds
|
||||
directory at them through XSAVE instruction, and then set valid bit
|
||||
of bounds entry to have this entry valid. But, the kernel will decline
|
||||
to assist in managing these tables.
|
||||
|
||||
2) Userspace may not take multiple bounds directory entries and point
|
||||
them at the same bounds table.
|
||||
|
||||
This is allowed architecturally. See more information "Intel(R) Architecture
|
||||
Instruction Set Extensions Programming Reference" (9.3.4).
|
||||
|
||||
However, if users did this, the kernel might be fooled in to unmaping an
|
||||
in-use bounds table since it does not recognize sharing.
|
174
MAINTAINERS
174
MAINTAINERS
@ -861,6 +861,7 @@ W: http://maxim.org.za/at91_26.html
|
||||
W: http://www.linux4sam.org
|
||||
S: Supported
|
||||
F: arch/arm/mach-at91/
|
||||
F: include/soc/at91/
|
||||
F: arch/arm/boot/dts/at91*.dts
|
||||
F: arch/arm/boot/dts/at91*.dtsi
|
||||
F: arch/arm/boot/dts/sama*.dts
|
||||
@ -1308,30 +1309,22 @@ F: drivers/*/*rockchip*
|
||||
F: drivers/*/*/*rockchip*
|
||||
F: sound/soc/rockchip/
|
||||
|
||||
ARM/SAMSUNG ARM ARCHITECTURES
|
||||
M: Ben Dooks <ben-linux@fluff.org>
|
||||
M: Kukjin Kim <kgene.kim@samsung.com>
|
||||
ARM/SAMSUNG EXYNOS ARM ARCHITECTURES
|
||||
M: Kukjin Kim <kgene@kernel.org>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
|
||||
W: http://www.fluff.org/ben/linux/
|
||||
S: Maintained
|
||||
F: arch/arm/boot/dts/s3c*
|
||||
F: arch/arm/boot/dts/exynos*
|
||||
F: arch/arm/plat-samsung/
|
||||
F: arch/arm/mach-s3c24*/
|
||||
F: arch/arm/mach-s3c64xx/
|
||||
F: arch/arm/mach-s5p*/
|
||||
F: arch/arm/mach-exynos*/
|
||||
F: drivers/*/*s3c2410*
|
||||
F: drivers/*/*/*s3c2410*
|
||||
F: drivers/spi/spi-s3c*
|
||||
F: sound/soc/samsung/*
|
||||
|
||||
ARM/S5P EXYNOS ARM ARCHITECTURES
|
||||
M: Kukjin Kim <kgene.kim@samsung.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-s5p*/
|
||||
F: arch/arm/mach-exynos*/
|
||||
N: exynos
|
||||
|
||||
ARM/SAMSUNG MOBILE MACHINE SUPPORT
|
||||
@ -1381,12 +1374,12 @@ F: arch/arm/boot/dts/sh*
|
||||
F: arch/arm/configs/ape6evm_defconfig
|
||||
F: arch/arm/configs/armadillo800eva_defconfig
|
||||
F: arch/arm/configs/bockw_defconfig
|
||||
F: arch/arm/configs/koelsch_defconfig
|
||||
F: arch/arm/configs/kzm9g_defconfig
|
||||
F: arch/arm/configs/lager_defconfig
|
||||
F: arch/arm/configs/mackerel_defconfig
|
||||
F: arch/arm/configs/marzen_defconfig
|
||||
F: arch/arm/configs/shmobile_defconfig
|
||||
F: arch/arm/include/debug/renesas-scif.S
|
||||
F: arch/arm/mach-shmobile/
|
||||
F: drivers/sh/
|
||||
|
||||
@ -1430,6 +1423,7 @@ F: drivers/tty/serial/st-asc.c
|
||||
F: drivers/usb/dwc3/dwc3-st.c
|
||||
F: drivers/usb/host/ehci-st.c
|
||||
F: drivers/usb/host/ohci-st.c
|
||||
F: drivers/ata/ahci_st.c
|
||||
|
||||
ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
@ -1503,6 +1497,19 @@ S: Maintained
|
||||
F: drivers/clk/ux500/
|
||||
F: include/linux/platform_data/clk-ux500.h
|
||||
|
||||
ARM/VERSATILE EXPRESS PLATFORM
|
||||
M: Liviu Dudau <liviu.dudau@arm.com>
|
||||
M: Sudeep Holla <sudeep.holla@arm.com>
|
||||
M: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/boot/dts/vexpress*
|
||||
F: arch/arm/mach-vexpress/
|
||||
F: */*/vexpress*
|
||||
F: */*/*/vexpress*
|
||||
F: drivers/clk/versatile/clk-vexpress-osc.c
|
||||
F: drivers/clocksource/versatile.c
|
||||
|
||||
ARM/VFP SUPPORT
|
||||
M: Russell King <linux@arm.linux.org.uk>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
@ -1543,6 +1550,7 @@ F: arch/arm/mach-pxa/include/mach/z2.h
|
||||
|
||||
ARM/ZYNQ ARCHITECTURE
|
||||
M: Michal Simek <michal.simek@xilinx.com>
|
||||
R: Sören Brinkmann <soren.brinkmann@xilinx.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
W: http://wiki.xilinx.com
|
||||
T: git git://git.xilinx.com/linux-xlnx.git
|
||||
@ -1827,7 +1835,7 @@ F: include/net/ax25.h
|
||||
F: net/ax25/
|
||||
|
||||
AZ6007 DVB DRIVER
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
@ -2071,8 +2079,9 @@ F: drivers/clocksource/bcm_kona_timer.c
|
||||
|
||||
BROADCOM BCM2835 ARM ARCHITECTURE
|
||||
M: Stephen Warren <swarren@wwwdotorg.org>
|
||||
M: Lee Jones <lee@kernel.org>
|
||||
L: linux-rpi-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-rpi.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
|
||||
S: Maintained
|
||||
N: bcm2835
|
||||
|
||||
@ -2095,10 +2104,13 @@ F: arch/arm/include/debug/bcm63xx.S
|
||||
BROADCOM BCM7XXX ARM ARCHITECTURE
|
||||
M: Marc Carino <marc.ceeeee@gmail.com>
|
||||
M: Brian Norris <computersforpeace@gmail.com>
|
||||
M: Gregory Fong <gregory.0xf0@gmail.com>
|
||||
M: Florian Fainelli <f.fainelli@gmail.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-bcm/*brcmstb*
|
||||
F: arch/arm/boot/dts/bcm7*.dts*
|
||||
F: drivers/bus/brcmstb_gisb.c
|
||||
|
||||
BROADCOM TG3 GIGABIT ETHERNET DRIVER
|
||||
M: Prashant Sreedharan <prashant@broadcom.com>
|
||||
@ -2129,6 +2141,20 @@ L: linux-scsi@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/scsi/bnx2i/
|
||||
|
||||
BROADCOM CYGNUS/IPROC ARM ARCHITECTURE
|
||||
M: Ray Jui <rjui@broadcom.com>
|
||||
M: Scott Branden <sbranden@broadcom.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
L: bcm-kernel-feedback-list@broadcom.com
|
||||
T: git git://git.github.com/brcm/linux.git
|
||||
S: Maintained
|
||||
N: iproc
|
||||
N: cygnus
|
||||
N: bcm9113*
|
||||
N: bcm9583*
|
||||
N: bcm583*
|
||||
N: bcm113*
|
||||
|
||||
BROADCOM KONA GPIO DRIVER
|
||||
M: Ray Jui <rjui@broadcom.com>
|
||||
L: bcm-kernel-feedback-list@broadcom.com
|
||||
@ -2196,7 +2222,7 @@ F: Documentation/filesystems/btrfs.txt
|
||||
F: fs/btrfs/
|
||||
|
||||
BTTV VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
@ -2717,7 +2743,7 @@ F: drivers/media/common/cx2341x*
|
||||
F: include/media/cx2341x*
|
||||
|
||||
CX88 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
@ -2742,6 +2768,13 @@ W: http://www.chelsio.com
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/chelsio/cxgb3/
|
||||
|
||||
CXGB3 ISCSI DRIVER (CXGB3I)
|
||||
M: Karen Xie <kxie@chelsio.com>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
W: http://www.chelsio.com
|
||||
S: Supported
|
||||
F: drivers/scsi/cxgbi/cxgb3i
|
||||
|
||||
CXGB3 IWARP RNIC DRIVER (IW_CXGB3)
|
||||
M: Steve Wise <swise@chelsio.com>
|
||||
L: linux-rdma@vger.kernel.org
|
||||
@ -2756,6 +2789,13 @@ W: http://www.chelsio.com
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/chelsio/cxgb4/
|
||||
|
||||
CXGB4 ISCSI DRIVER (CXGB4I)
|
||||
M: Karen Xie <kxie@chelsio.com>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
W: http://www.chelsio.com
|
||||
S: Supported
|
||||
F: drivers/scsi/cxgbi/cxgb4i
|
||||
|
||||
CXGB4 IWARP RNIC DRIVER (IW_CXGB4)
|
||||
M: Steve Wise <swise@chelsio.com>
|
||||
L: linux-rdma@vger.kernel.org
|
||||
@ -2846,11 +2886,10 @@ F: Documentation/networking/dmfe.txt
|
||||
F: drivers/net/ethernet/dec/tulip/dmfe.c
|
||||
|
||||
DC390/AM53C974 SCSI driver
|
||||
M: Kurt Garloff <garloff@suse.de>
|
||||
W: http://www.garloff.de/kurt/linux/dc390/
|
||||
M: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
|
||||
M: Hannes Reinecke <hare@suse.de>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/scsi/tmscsim.*
|
||||
F: drivers/scsi/am53c974.c
|
||||
|
||||
DC395x SCSI driver
|
||||
M: Oliver Neukum <oliver@neukum.org>
|
||||
@ -3386,7 +3425,7 @@ F: fs/ecryptfs/
|
||||
EDAC-CORE
|
||||
M: Doug Thompson <dougthompson@xmission.com>
|
||||
M: Borislav Petkov <bp@alien8.de>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Supported
|
||||
@ -3435,7 +3474,7 @@ S: Maintained
|
||||
F: drivers/edac/e7xxx_edac.c
|
||||
|
||||
EDAC-GHES
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
@ -3463,21 +3502,21 @@ S: Maintained
|
||||
F: drivers/edac/i5000_edac.c
|
||||
|
||||
EDAC-I5400
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
F: drivers/edac/i5400_edac.c
|
||||
|
||||
EDAC-I7300
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
F: drivers/edac/i7300_edac.c
|
||||
|
||||
EDAC-I7CORE
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
@ -3520,7 +3559,7 @@ S: Maintained
|
||||
F: drivers/edac/r82600_edac.c
|
||||
|
||||
EDAC-SBRIDGE
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
@ -3580,7 +3619,7 @@ S: Maintained
|
||||
F: drivers/net/ethernet/ibm/ehea/
|
||||
|
||||
EM28XX VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
@ -4714,6 +4753,7 @@ L: linux-iio@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/iio/
|
||||
F: drivers/staging/iio/
|
||||
F: include/linux/iio/
|
||||
|
||||
IKANOS/ADI EAGLE ADSL USB DRIVER
|
||||
M: Matthieu Castet <castet.matthieu@free.fr>
|
||||
@ -5945,7 +5985,7 @@ S: Maintained
|
||||
F: drivers/media/radio/radio-maxiradio*
|
||||
|
||||
MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
P: LinuxTV.org Project
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
@ -5974,10 +6014,13 @@ W: http://linuxtv.org
|
||||
S: Odd Fixes
|
||||
F: drivers/media/parport/pms*
|
||||
|
||||
MEGARAID SCSI DRIVERS
|
||||
M: Neela Syam Kolli <megaraidlinux@lsi.com>
|
||||
MEGARAID SCSI/SAS DRIVERS
|
||||
M: Kashyap Desai <kashyap.desai@avagotech.com>
|
||||
M: Sumit Saxena <sumit.saxena@avagotech.com>
|
||||
M: Uday Lingala <uday.lingala@avagotech.com>
|
||||
L: megaraidlinux.pdl@avagotech.com
|
||||
L: linux-scsi@vger.kernel.org
|
||||
W: http://megaraid.lsilogic.com
|
||||
W: http://www.lsi.com
|
||||
S: Maintained
|
||||
F: Documentation/scsi/megaraid.txt
|
||||
F: drivers/scsi/megaraid.*
|
||||
@ -6288,7 +6331,6 @@ F: drivers/scsi/g_NCR5380.*
|
||||
F: drivers/scsi/g_NCR5380_mmio.c
|
||||
F: drivers/scsi/mac_scsi.*
|
||||
F: drivers/scsi/pas16.*
|
||||
F: drivers/scsi/sun3_NCR5380.c
|
||||
F: drivers/scsi/sun3_scsi.*
|
||||
F: drivers/scsi/sun3_scsi_vme.c
|
||||
F: drivers/scsi/t128.*
|
||||
@ -6544,6 +6586,13 @@ S: Maintained
|
||||
F: Documentation/scsi/NinjaSCSI.txt
|
||||
F: drivers/scsi/nsp32*
|
||||
|
||||
NIOS2 ARCHITECTURE
|
||||
M: Ley Foon Tan <lftan@altera.com>
|
||||
L: nios2-dev@lists.rocketboards.org (moderated for non-subscribers)
|
||||
T: git git://git.rocketboards.org/linux-socfpga.git
|
||||
S: Maintained
|
||||
F: arch/nios2/
|
||||
|
||||
NTB DRIVER
|
||||
M: Jon Mason <jdmason@kudzu.us>
|
||||
M: Dave Jiang <dave.jiang@intel.com>
|
||||
@ -6594,6 +6643,23 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
|
||||
S: Maintained
|
||||
F: arch/arm/*omap*/
|
||||
F: drivers/i2c/busses/i2c-omap.c
|
||||
F: drivers/irqchip/irq-omap-intc.c
|
||||
F: drivers/mfd/*omap*.c
|
||||
F: drivers/mfd/menelaus.c
|
||||
F: drivers/mfd/palmas.c
|
||||
F: drivers/mfd/tps65217.c
|
||||
F: drivers/mfd/tps65218.c
|
||||
F: drivers/mfd/tps65910.c
|
||||
F: drivers/mfd/twl-core.[ch]
|
||||
F: drivers/mfd/twl4030*.c
|
||||
F: drivers/mfd/twl6030*.c
|
||||
F: drivers/mfd/twl6040*.c
|
||||
F: drivers/regulator/palmas-regulator*.c
|
||||
F: drivers/regulator/pbias-regulator.c
|
||||
F: drivers/regulator/tps65217-regulator.c
|
||||
F: drivers/regulator/tps65218-regulator.c
|
||||
F: drivers/regulator/tps65910-regulator.c
|
||||
F: drivers/regulator/twl-regulator.c
|
||||
F: include/linux/i2c-omap.h
|
||||
|
||||
OMAP DEVICE TREE SUPPORT
|
||||
@ -6604,6 +6670,9 @@ L: devicetree@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/arm/boot/dts/*omap*
|
||||
F: arch/arm/boot/dts/*am3*
|
||||
F: arch/arm/boot/dts/*am4*
|
||||
F: arch/arm/boot/dts/*am5*
|
||||
F: arch/arm/boot/dts/*dra7*
|
||||
|
||||
OMAP CLOCK FRAMEWORK SUPPORT
|
||||
M: Paul Walmsley <paul@pwsan.com>
|
||||
@ -6633,6 +6702,14 @@ L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: sound/soc/omap/
|
||||
|
||||
OMAP GENERAL PURPOSE MEMORY CONTROLLER SUPPORT
|
||||
M: Roger Quadros <rogerq@ti.com>
|
||||
M: Tony Lindgren <tony@atomide.com>
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/memory/omap-gpmc.c
|
||||
F: arch/arm/mach-omap2/*gpmc*
|
||||
|
||||
OMAP FRAMEBUFFER SUPPORT
|
||||
M: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
@ -6851,11 +6928,12 @@ F: drivers/scsi/osd/
|
||||
F: include/scsi/osd_*
|
||||
F: fs/exofs/
|
||||
|
||||
OVERLAYFS FILESYSTEM
|
||||
OVERLAY FILESYSTEM
|
||||
M: Miklos Szeredi <miklos@szeredi.hu>
|
||||
L: linux-fsdevel@vger.kernel.org
|
||||
L: linux-unionfs@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git
|
||||
S: Supported
|
||||
F: fs/overlayfs/*
|
||||
F: fs/overlayfs/
|
||||
F: Documentation/filesystems/overlayfs.txt
|
||||
|
||||
P54 WIRELESS DRIVER
|
||||
@ -7179,6 +7257,7 @@ F: drivers/crypto/picoxcell*
|
||||
|
||||
PIN CONTROL SUBSYSTEM
|
||||
M: Linus Walleij <linus.walleij@linaro.org>
|
||||
L: linux-gpio@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/pinctrl/
|
||||
F: include/linux/pinctrl/
|
||||
@ -7974,7 +8053,7 @@ S: Odd Fixes
|
||||
F: drivers/media/i2c/saa6588*
|
||||
|
||||
SAA7134 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
@ -8432,7 +8511,7 @@ S: Maintained
|
||||
F: drivers/media/radio/si4713/radio-usb-si4713.c
|
||||
|
||||
SIANO DVB DRIVER
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
@ -8483,7 +8562,6 @@ F: arch/arm/mach-s3c24xx/bast-irq.c
|
||||
TI DAVINCI MACHINE SUPPORT
|
||||
M: Sekhar Nori <nsekhar@ti.com>
|
||||
M: Kevin Hilman <khilman@deeprootsystems.com>
|
||||
L: davinci-linux-open-source@linux.davincidsp.com (moderated for non-subscribers)
|
||||
T: git git://gitorious.org/linux-davinci/linux-davinci.git
|
||||
Q: http://patchwork.kernel.org/project/linux-davinci/list/
|
||||
S: Supported
|
||||
@ -8493,7 +8571,6 @@ F: drivers/i2c/busses/i2c-davinci.c
|
||||
TI DAVINCI SERIES MEDIA DRIVER
|
||||
M: Lad, Prabhakar <prabhakar.csengg@gmail.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
L: davinci-linux-open-source@linux.davincidsp.com (moderated for non-subscribers)
|
||||
W: http://linuxtv.org/
|
||||
Q: http://patchwork.linuxtv.org/project/linux-media/list/
|
||||
T: git git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git
|
||||
@ -8645,7 +8722,9 @@ S: Maintained
|
||||
F: drivers/leds/leds-net48xx.c
|
||||
|
||||
SOFTLOGIC 6x10 MPEG CODEC
|
||||
M: Ismael Luceno <ismael.luceno@corp.bluecherry.net>
|
||||
M: Bluecherry Maintainers <maintainers@bluecherrydvr.com>
|
||||
M: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
|
||||
M: Andrey Utkin <andrey.krieger.utkin@gmail.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/media/pci/solo6x10/
|
||||
@ -9119,7 +9198,7 @@ S: Maintained
|
||||
F: drivers/media/i2c/tda9840*
|
||||
|
||||
TEA5761 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
@ -9127,7 +9206,7 @@ S: Odd fixes
|
||||
F: drivers/media/tuners/tea5761.*
|
||||
|
||||
TEA5767 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
@ -9439,7 +9518,7 @@ F: include/linux/shmem_fs.h
|
||||
F: mm/shmem.c
|
||||
|
||||
TM6000 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
@ -9703,11 +9782,6 @@ S: Maintained
|
||||
F: Documentation/hid/hiddev.txt
|
||||
F: drivers/hid/usbhid/
|
||||
|
||||
USB/IP DRIVERS
|
||||
L: linux-usb@vger.kernel.org
|
||||
S: Orphan
|
||||
F: drivers/staging/usbip/
|
||||
|
||||
USB ISP116X DRIVER
|
||||
M: Olav Kongas <ok@artecdesign.ee>
|
||||
L: linux-usb@vger.kernel.org
|
||||
@ -10265,7 +10339,7 @@ S: Maintained
|
||||
F: arch/x86/kernel/cpu/mcheck/*
|
||||
|
||||
XC2028/3028 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
M: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
7
Makefile
7
Makefile
@ -1,7 +1,7 @@
|
||||
VERSION = 3
|
||||
PATCHLEVEL = 18
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION = -rc3
|
||||
EXTRAVERSION =
|
||||
NAME = Diseased Newt
|
||||
|
||||
# *DOCUMENTATION*
|
||||
@ -297,7 +297,7 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
|
||||
|
||||
HOSTCC = gcc
|
||||
HOSTCXX = g++
|
||||
HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
|
||||
HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
|
||||
HOSTCXXFLAGS = -O2
|
||||
|
||||
ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
|
||||
@ -401,7 +401,8 @@ KBUILD_CPPFLAGS := -D__KERNEL__
|
||||
KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
|
||||
-fno-strict-aliasing -fno-common \
|
||||
-Werror-implicit-function-declaration \
|
||||
-Wno-format-security
|
||||
-Wno-format-security \
|
||||
-std=gnu89
|
||||
|
||||
KBUILD_AFLAGS_KERNEL :=
|
||||
KBUILD_CFLAGS_KERNEL :=
|
||||
|
@ -13,8 +13,6 @@
|
||||
#include <asm/byteorder.h>
|
||||
#include <asm/page.h>
|
||||
|
||||
#define PCI_IOBASE ((void __iomem *)0)
|
||||
|
||||
extern void __iomem *ioremap(unsigned long physaddr, unsigned long size);
|
||||
extern void __iomem *ioremap_prot(phys_addr_t offset, unsigned long size,
|
||||
unsigned long flags);
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user