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

Merge branches 'for-3.8/upstream-fixes', 'for-3.9/hid-sensor', 'for-3.9/hidraw' and 'for-3.9/i2c-hid' into for-linus 

Conflicts:
	drivers/hid/i2c-hid/i2c-hid.c
This commit is contained in:
Jiri Kosina 2013-02-21 10:42:39 +01:00
parent befde0226a 0d1e4b024f 0f690ccf56 92241e67c0
commit 539cf54bdd
5746 changed files with 270786 additions and 90297 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -60,7 +60,6 @@ modules.builtin
# Generated include files
#
include/config
include/linux/version.h
include/generated
arch/*/include/generated

2
Documentation/00-INDEX
View File

@ -136,8 +136,6 @@ fault-injection/
- dir with docs about the fault injection capabilities infrastructure.
fb/
- directory with info on the frame buffer graphics abstraction layer.
feature-removal-schedule.txt
- list of files and features that are going to be removed.
filesystems/
- info on the vfs and the various filesystems that Linux supports.
firmware_class/

3
Documentation/ABI/README
View File

@ -36,9 +36,6 @@ The different levels of stability are:
the kernel, but are marked to be removed at some later point in
time. The description of the interface will document the reason
why it is obsolete and when it can be expected to be removed.
The file Documentation/feature-removal-schedule.txt may describe
some of these interfaces, giving a schedule for when they will
be removed.
removed/
This directory contains a list of the old interfaces that have

96
Documentation/ABI/stable/sysfs-devices-node
View File

@ -1,7 +1,101 @@
What: /sys/devices/system/node/possible
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Nodes that could be possibly become online at some point.
What: /sys/devices/system/node/online
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Nodes that are online.
What: /sys/devices/system/node/has_normal_memory
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Nodes that have regular memory.
What: /sys/devices/system/node/has_cpu
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Nodes that have one or more CPUs.
What: /sys/devices/system/node/has_high_memory
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Nodes that have regular or high memory.
Depends on CONFIG_HIGHMEM.
What: /sys/devices/system/node/nodeX
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
When CONFIG_NUMA is enabled, this is a directory containing
information on node X such as what CPUs are local to the
node.
node. Each file is detailed next.
What: /sys/devices/system/node/nodeX/cpumap
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
The node's cpumap.
What: /sys/devices/system/node/nodeX/cpulist
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
The CPUs associated to the node.
What: /sys/devices/system/node/nodeX/meminfo
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Provides information about the node's distribution and memory
utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.txt
What: /sys/devices/system/node/nodeX/numastat
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
The node's hit/miss statistics, in units of pages.
See Documentation/numastat.txt
What: /sys/devices/system/node/nodeX/distance
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Distance between the node and all the other nodes
in the system.
What: /sys/devices/system/node/nodeX/vmstat
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
The node's zoned virtual memory statistics.
This is a superset of numastat.
What: /sys/devices/system/node/nodeX/compact
Date: February 2010
Contact: Mel Gorman <mel@csn.ul.ie>
Description:
When this file is written to, all memory within that node
will be compacted. When it completes, memory will be freed
into blocks which have as many contiguous pages as possible
What: /sys/devices/system/node/nodeX/scan_unevictable_pages
Date: October 2008
Contact: Lee Schermerhorn <lee.schermerhorn@hp.com>
Description:
When set, it triggers scanning the node's unevictable lists
and move any pages that have become evictable onto the respective
zone's inactive list. See mm/vmscan.c
What: /sys/devices/system/node/nodeX/hugepages/hugepages-<size>/
Date: December 2009
Contact: Lee Schermerhorn <lee.schermerhorn@hp.com>
Description:
The node's huge page size control/query attributes.
See Documentation/vm/hugetlbpage.txt

156
Documentation/ABI/stable/sysfs-driver-ib_srp Normal file
View File

@ -0,0 +1,156 @@
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/add_target
Date: January 2, 2006
KernelVersion: 2.6.15
Contact: linux-rdma@vger.kernel.org
Description: Interface for making ib_srp connect to a new target.
One can request ib_srp to connect to a new target by writing
a comma-separated list of login parameters to this sysfs
attribute. The supported parameters are:
* id_ext, a 16-digit hexadecimal number specifying the eight
byte identifier extension in the 16-byte SRP target port
identifier. The target port identifier is sent by ib_srp
to the target in the SRP_LOGIN_REQ request.
* ioc_guid, a 16-digit hexadecimal number specifying the eight
byte I/O controller GUID portion of the 16-byte target port
identifier.
* dgid, a 32-digit hexadecimal number specifying the
destination GID.
* pkey, a four-digit hexadecimal number specifying the
InfiniBand partition key.
* service_id, a 16-digit hexadecimal number specifying the
InfiniBand service ID used to establish communication with
the SRP target. How to find out the value of the service ID
is specified in the documentation of the SRP target.
* max_sect, a decimal number specifying the maximum number of
512-byte sectors to be transferred via a single SCSI command.
* max_cmd_per_lun, a decimal number specifying the maximum
number of outstanding commands for a single LUN.
* io_class, a hexadecimal number specifying the SRP I/O class.
Must be either 0xff00 (rev 10) or 0x0100 (rev 16a). The I/O
class defines the format of the SRP initiator and target
port identifiers.
* initiator_ext, a 16-digit hexadecimal number specifying the
identifier extension portion of the SRP initiator port
identifier. This data is sent by the initiator to the target
in the SRP_LOGIN_REQ request.
* cmd_sg_entries, a number in the range 1..255 that specifies
the maximum number of data buffer descriptors stored in the
SRP_CMD information unit itself. With allow_ext_sg=0 the
parameter cmd_sg_entries defines the maximum S/G list length
for a single SRP_CMD, and commands whose S/G list length
exceeds this limit after S/G list collapsing will fail.
* allow_ext_sg, whether ib_srp is allowed to include a partial
memory descriptor list in an SRP_CMD instead of the entire
list. If a partial memory descriptor list has been included
in an SRP_CMD the remaining memory descriptors are
communicated from initiator to target via an additional RDMA
transfer. Setting allow_ext_sg to 1 increases the maximum
amount of data that can be transferred between initiator and
target via a single SCSI command. Since not all SRP target
implementations support partial memory descriptor lists the
default value for this option is 0.
* sg_tablesize, a number in the range 1..2048 specifying the
maximum S/G list length the SCSI layer is allowed to pass to
ib_srp. Specifying a value that exceeds cmd_sg_entries is
only safe with partial memory descriptor list support enabled
(allow_ext_sg=1).
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
Date: January 2, 2006
KernelVersion: 2.6.15
Contact: linux-rdma@vger.kernel.org
Description: HCA name (<hca>).
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/port
Date: January 2, 2006
KernelVersion: 2.6.15
Contact: linux-rdma@vger.kernel.org
Description: HCA port number (<port_number>).
What: /sys/class/scsi_host/host<n>/allow_ext_sg
Date: May 19, 2011
KernelVersion: 2.6.39
Contact: linux-rdma@vger.kernel.org
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>/cmd_sg_entries
Date: May 19, 2011
KernelVersion: 2.6.39
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>/dgid
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: InfiniBand destination GID used for communication with the SRP
target. Differs from orig_dgid if port redirection has happened.
What: /sys/class/scsi_host/host<n>/id_ext
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: Eight-byte identifier extension portion of the 16-byte target
port identifier.
What: /sys/class/scsi_host/host<n>/ioc_guid
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: Eight-byte I/O controller GUID portion of the 16-byte target
port identifier.
What: /sys/class/scsi_host/host<n>/local_ib_device
Date: November 29, 2006
KernelVersion: 2.6.19
Contact: linux-rdma@vger.kernel.org
Description: Name of the InfiniBand HCA used for communicating with the
SRP target.
What: /sys/class/scsi_host/host<n>/local_ib_port
Date: November 29, 2006
KernelVersion: 2.6.19
Contact: linux-rdma@vger.kernel.org
Description: Number of the HCA port used for communicating with the
SRP target.
What: /sys/class/scsi_host/host<n>/orig_dgid
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: InfiniBand destination GID specified in the parameters
written to the add_target sysfs attribute.
What: /sys/class/scsi_host/host<n>/pkey
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: A 16-bit number representing the InfiniBand partition key used
for communication with the SRP target.
What: /sys/class/scsi_host/host<n>/req_lim
Date: October 20, 2010
KernelVersion: 2.6.36
Contact: linux-rdma@vger.kernel.org
Description: Number of requests ib_srp can send to the target before it has
to wait for more credits. For more information see also the
SRP credit algorithm in the SRP specification.
What: /sys/class/scsi_host/host<n>/service_id
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: InfiniBand service ID used for establishing communication with
the SRP target.
What: /sys/class/scsi_host/host<n>/zero_req_lim
Date: September 20, 2006
KernelVersion: 2.6.18
Contact: linux-rdma@vger.kernel.org
Description: Number of times the initiator had to wait before sending a
request to the target because it ran out of credits. For more
information see also the SRP credit algorithm in the SRP
specification.

19
Documentation/ABI/stable/sysfs-transport-srp Normal file
View File

@ -0,0 +1,19 @@
What: /sys/class/srp_remote_ports/port-<h>:<n>/delete
Date: June 1, 2012
KernelVersion: 3.7
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
Description: Instructs an SRP initiator to disconnect from a target and to
remove all LUNs imported from that target.
What: /sys/class/srp_remote_ports/port-<h>:<n>/port_id
Date: June 27, 2007
KernelVersion: 2.6.24
Contact: linux-scsi@vger.kernel.org
Description: 16-byte local SRP port identifier in hexadecimal format. An
example: 4c:49:4e:55:58:20:56:49:4f:00:00:00:00:00:00:00.
What: /sys/class/srp_remote_ports/port-<h>:<n>/roles
Date: June 27, 2007
KernelVersion: 2.6.24
Contact: linux-scsi@vger.kernel.org
Description: Role of the remote port. Either "SRP Initiator" or "SRP Target".

3
Documentation/ABI/testing/ima_policy
View File

@ -23,7 +23,7 @@ Description:
lsm: [[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
base: func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK]
base: func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK][MODULE_CHECK]
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
fsmagic:= hex value
uid:= decimal value
@ -53,6 +53,7 @@ Description:
measure func=BPRM_CHECK
measure func=FILE_MMAP mask=MAY_EXEC
measure func=FILE_CHECK mask=MAY_READ uid=0
measure func=MODULE_CHECK uid=0
appraise fowner=0
The default policy measures all executables in bprm_check,

34
Documentation/ABI/testing/sysfs-bus-pci
View File

@ -222,3 +222,37 @@ Description:
satisfied too. Reading this attribute will show the current
value of d3cold_allowed bit. Writing this attribute will set
the value of d3cold_allowed bit.
What: /sys/bus/pci/devices/.../sriov_totalvfs
Date: November 2012
Contact: Donald Dutile <ddutile@redhat.com>
Description:
This file appears when a physical PCIe device supports SR-IOV.
Userspace applications can read this file to determine the
maximum number of Virtual Functions (VFs) a PCIe physical
function (PF) can support. Typically, this is the value reported
in the PF's SR-IOV extended capability structure's TotalVFs
element. Drivers have the ability at probe time to reduce the
value read from this file via the pci_sriov_set_totalvfs()
function.
What: /sys/bus/pci/devices/.../sriov_numvfs
Date: November 2012
Contact: Donald Dutile <ddutile@redhat.com>
Description:
This file appears when a physical PCIe device supports SR-IOV.
Userspace applications can read and write to this file to
determine and control the enablement or disablement of Virtual
Functions (VFs) on the physical function (PF). A read of this
file will return the number of VFs that are enabled on this PF.
A number written to this file will enable the specified
number of VFs. A userspace application would typically read the
file and check that the value is zero, and then write the number
of VFs that should be enabled on the PF; the value written
should be less than or equal to the value in the sriov_totalvfs
file. A userspace application wanting to disable the VFs would
write a zero to this file. The core ensures that valid values
are written to this file, and returns errors when values are not
valid. For example, writing a 2 to this file when sriov_numvfs
is not 0 and not 2 already will return an error. Writing a 10
when the value of sriov_totalvfs is 8 will return an error.

4
Documentation/ABI/testing/sysfs-bus-rbd
View File

@ -70,6 +70,10 @@ snap_*
A directory per each snapshot
parent
Information identifying the pool, image, and snapshot id for
the parent image in a layered rbd image (format 2 only).
Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
-------------------------------------------------------------

7
Documentation/ABI/testing/sysfs-devices-node
View File

@ -1,7 +0,0 @@
What: /sys/devices/system/node/nodeX/compact
Date: February 2010
Contact: Mel Gorman <mel@csn.ul.ie>
Description:
When this file is written to, all memory within that node
will be compacted. When it completes, memory will be freed
into blocks which have as many contiguous pages as possible

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

@ -468,11 +468,46 @@ To map a single region, you do:
size_t size = buffer->len;
dma_handle = dma_map_single(dev, addr, size, direction);
if (dma_mapping_error(dma_handle)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling;
}
and to unmap it:
dma_unmap_single(dev, dma_handle, size, direction);
You should call dma_mapping_error() as dma_map_single() could fail and return
error. Not all dma implementations support dma_mapping_error() interface.
However, it is a good practice to call dma_mapping_error() interface, which
will invoke the generic mapping error check interface. Doing so will ensure
that the mapping code will work correctly on all dma implementations without
any dependency on the specifics of the underlying implementation. Using the
returned address without checking for errors could result in failures ranging
from panics to silent data corruption. Couple of example of incorrect ways to
check for errors that make assumptions about the underlying dma implementation
are as follows and these are applicable to dma_map_page() as well.
Incorrect example 1:
dma_addr_t dma_handle;
dma_handle = dma_map_single(dev, addr, size, direction);
if ((dma_handle & 0xffff != 0) || (dma_handle >= 0x1000000)) {
goto map_error;
}
Incorrect example 2:
dma_addr_t dma_handle;
dma_handle = dma_map_single(dev, addr, size, direction);
if (dma_handle == DMA_ERROR_CODE) {
goto map_error;
}
You should call dma_unmap_single when the DMA activity is finished, e.g.
from the interrupt which told you that the DMA transfer is done.
@ -489,6 +524,14 @@ Specifically:
size_t size = buffer->len;
dma_handle = dma_map_page(dev, page, offset, size, direction);
if (dma_mapping_error(dma_handle)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling;
}
...
@ -496,6 +539,12 @@ Specifically:
Here, "offset" means byte offset within the given page.
You should call dma_mapping_error() as dma_map_page() could fail and return
error as outlined under the dma_map_single() discussion.
You should call dma_unmap_page when the DMA activity is finished, e.g.
from the interrupt which told you that the DMA transfer is done.
With scatterlists, you map a region gathered from several regions by:
int i, count = dma_map_sg(dev, sglist, nents, direction);
@ -578,6 +627,14 @@ to use the dma_sync_*() interfaces.
dma_addr_t mapping;
mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE);
if (dma_mapping_error(dma_handle)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling;
}
cp->rx_buf = buffer;
cp->rx_len = len;
@ -658,6 +715,75 @@ failure can be determined by:
* delay and try again later or
* reset driver.
*/
goto map_error_handling;
}
- unmap pages that are already mapped, when mapping error occurs in the middle
of a multiple page mapping attempt. These example are applicable to
dma_map_page() as well.
Example 1:
dma_addr_t dma_handle1;
dma_addr_t dma_handle2;
dma_handle1 = dma_map_single(dev, addr, size, direction);
if (dma_mapping_error(dev, dma_handle1)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling1;
}
dma_handle2 = dma_map_single(dev, addr, size, direction);
if (dma_mapping_error(dev, dma_handle2)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling2;
}
...
map_error_handling2:
dma_unmap_single(dma_handle1);
map_error_handling1:
Example 2: (if buffers are allocated a loop, unmap all mapped buffers when
mapping error is detected in the middle)
dma_addr_t dma_addr;
dma_addr_t array[DMA_BUFFERS];
int save_index = 0;
for (i = 0; i < DMA_BUFFERS; i++) {
...
dma_addr = dma_map_single(dev, addr, size, direction);
if (dma_mapping_error(dev, dma_addr)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling;
}
array[i].dma_addr = dma_addr;
save_index++;
}
...
map_error_handling:
for (i = 0; i < save_index; i++) {
...
dma_unmap_single(array[i].dma_addr);
}
Networking drivers must call dev_kfree_skb to free the socket buffer

12
Documentation/DMA-API.txt
View File

@ -678,3 +678,15 @@ out of dma_debug_entries. These entries are preallocated at boot. The number
of preallocated entries is defined per architecture. If it is too low for you
boot with 'dma_debug_entries=<your_desired_number>' to overwrite the
architectural default.
void debug_dmap_mapping_error(struct device *dev, dma_addr_t dma_addr);
dma-debug interface debug_dma_mapping_error() to debug drivers that fail
to check dma mapping errors on addresses returned by dma_map_single() and
dma_map_page() interfaces. This interface clears a flag set by
debug_dma_map_page() to indicate that dma_mapping_error() has been called by
the driver. When driver does unmap, debug_dma_unmap() checks the flag and if
this flag is still set, prints warning message that includes call trace that
leads up to the unmap. This interface can be called from dma_mapping_error()
routines to enable dma mapping error check debugging.

9
Documentation/DMA-attributes.txt
View File

@ -91,3 +91,12 @@ transferred to 'device' domain. This attribute can be also used for
dma_unmap_{single,page,sg} functions family to force buffer to stay in
device domain after releasing a mapping for it. Use this attribute with
care!
DMA_ATTR_FORCE_CONTIGUOUS
-------------------------
By default DMA-mapping subsystem is allowed to assemble the buffer
allocated by dma_alloc_attrs() function from individual pages if it can
be mapped as contiguous chunk into device dma address space. By
specifing this attribute the allocated buffer is forced to be contiguous
also in physical memory.

39
Documentation/DocBook/drm.tmpl
View File

@ -1141,23 +1141,13 @@ int max_width, max_height;</synopsis>
the <methodname>page_flip</methodname> operation will be called with a
non-NULL <parameter>event</parameter> argument pointing to a
<structname>drm_pending_vblank_event</structname> instance. Upon page
flip completion the driver must fill the
<parameter>event</parameter>::<structfield>event</structfield>
<structfield>sequence</structfield>, <structfield>tv_sec</structfield>
and <structfield>tv_usec</structfield> fields with the associated
vertical blanking count and timestamp, add the event to the
<parameter>drm_file</parameter> list of events to be signaled, and wake
up any waiting process. This can be performed with
flip completion the driver must call <methodname>drm_send_vblank_event</methodname>
to fill in the event and send to wake up any waiting processes.
This can be performed with
<programlisting><![CDATA[
struct timeval now;
event->event.sequence = drm_vblank_count_and_time(..., &now);
event->event.tv_sec = now.tv_sec;
event->event.tv_usec = now.tv_usec;
spin_lock_irqsave(&dev->event_lock, flags);
list_add_tail(&event->base.link, &event->base.file_priv->event_list);
wake_up_interruptible(&event->base.file_priv->event_wait);
...
drm_send_vblank_event(dev, pipe, event);
spin_unlock_irqrestore(&dev->event_lock, flags);
]]></programlisting>
</para>
@ -1621,10 +1611,10 @@ void intel_crt_init(struct drm_device *dev)
</sect2>
</sect1>
<!-- Internals: mid-layer helper functions -->
<!-- Internals: kms helper functions -->
<sect1>
<title>Mid-layer Helper Functions</title>
<title>Mode Setting Helper Functions</title>
<para>
The CRTC, encoder and connector functions provided by the drivers
implement the DRM API. They're called by the DRM core and ioctl handlers
@ -2106,6 +2096,21 @@ void intel_crt_init(struct drm_device *dev)
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Modeset Helper Functions Reference</title>
!Edrivers/gpu/drm/drm_crtc_helper.c
</sect2>
<sect2>
<title>fbdev Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
</sect2>
<sect2>
<title>Display Port Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
!Iinclude/drm/drm_dp_helper.h
!Edrivers/gpu/drm/drm_dp_helper.c
</sect2>
</sect1>
<!-- Internals: vertical blanking -->

3
Documentation/DocBook/kernel-api.tmpl
View File

@ -58,6 +58,9 @@
<sect1><title>String Conversions</title>
!Elib/vsprintf.c
!Finclude/linux/kernel.h kstrtol
!Finclude/linux/kernel.h kstrtoul
!Elib/kstrtox.c
</sect1>
<sect1><title>String Manipulation</title>
<!-- All functions are exported at now

7
Documentation/DocBook/media/v4l/compat.xml
View File

@ -2586,6 +2586,13 @@ ioctls.</para>
<para>Vendor and device specific media bus pixel formats.
<xref linkend="v4l2-mbus-vendor-spec-fmts" />.</para>
</listitem>
<listitem>
<para>Importing DMABUF file descriptors as a new IO method described
in <xref linkend="dmabuf" />.</para>
</listitem>
<listitem>
<para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para>
</listitem>
</itemizedlist>
</section>

6
Documentation/DocBook/media/v4l/driver.xml
View File

@ -116,7 +116,7 @@ my_suspend (struct pci_dev * pci_dev,
return 0; /* a negative value on error, 0 on success. */
}
static void __devexit
static void
my_remove (struct pci_dev * pci_dev)
{
my_device *my = pci_get_drvdata (pci_dev);
@ -124,7 +124,7 @@ my_remove (struct pci_dev * pci_dev)
/* Describe me. */
}
static int __devinit
static int
my_probe (struct pci_dev * pci_dev,
const struct pci_device_id * pci_id)
{
@ -157,7 +157,7 @@ my_pci_driver = {
.id_table = my_pci_device_ids,
.probe = my_probe,
.remove = __devexit_p (my_remove),
.remove = my_remove,
/* Power management functions. */
.suspend = my_suspend,

188
Documentation/DocBook/media/v4l/io.xml
View File

@ -331,7 +331,7 @@ application until one or more buffers can be dequeued. By default
outgoing queue. When the <constant>O_NONBLOCK</constant> flag was
given to the &func-open; function, <constant>VIDIOC_DQBUF</constant>
returns immediately with an &EAGAIN; when no buffer is available. The
&func-select; or &func-poll; function are always available.</para>
&func-select; or &func-poll; functions are always available.</para>
<para>To start and stop capturing or output applications call the
&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note
@ -472,6 +472,165 @@ rest should be evident.</para>
</footnote></para>
</section>
<section id="dmabuf">
<title>Streaming I/O (DMA buffer importing)</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>The DMABUF framework provides a generic method for sharing buffers
between multiple devices. Device drivers that support DMABUF can export a DMA
buffer to userspace as a file descriptor (known as the exporter role), import a
DMA buffer from userspace using a file descriptor previously exported for a
different or the same device (known as the importer role), or both. This
section describes the DMABUF importer role API in V4L2.</para>
<para>Refer to <link linked="vidioc-expbuf"> DMABUF exporting </link> for
details about exporting V4L2 buffers as DMABUF file descriptors.</para>
<para>Input and output devices support the streaming I/O method when the
<constant>V4L2_CAP_STREAMING</constant> flag in the
<structfield>capabilities</structfield> field of &v4l2-capability; returned by
the &VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through
DMABUF file descriptors is supported is determined by calling the
&VIDIOC-REQBUFS; ioctl with the memory type set to
<constant>V4L2_MEMORY_DMABUF</constant>.</para>
<para>This I/O method is dedicated to sharing DMA buffers between different
devices, which may be V4L devices or other video-related devices (e.g. DRM).
Buffers (planes) are allocated by a driver on behalf of an application. Next,
these buffers are exported to the application as file descriptors using an API
which is specific for an allocator driver. Only such file descriptor are
exchanged. The descriptors and meta-information are passed in &v4l2-buffer; (or
in &v4l2-plane; in the multi-planar API case). The driver must be switched
into DMABUF I/O mode by calling the &VIDIOC-REQBUFS; with the desired buffer
type.</para>
<example>
<title>Initiating streaming I/O with DMABUF file descriptors</title>
<programlisting>
&v4l2-requestbuffers; reqbuf;
memset(&amp;reqbuf, 0, sizeof (reqbuf));
reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
reqbuf.memory = V4L2_MEMORY_DMABUF;
reqbuf.count = 1;
if (ioctl(fd, &VIDIOC-REQBUFS;, &amp;reqbuf) == -1) {
if (errno == EINVAL)
printf("Video capturing or DMABUF streaming is not supported\n");
else
perror("VIDIOC_REQBUFS");
exit(EXIT_FAILURE);
}
</programlisting>
</example>
<para>The buffer (plane) file descriptor is passed on the fly with the
&VIDIOC-QBUF; ioctl. In case of multiplanar buffers, every plane can be
associated with a different DMABUF descriptor. Although buffers are commonly
cycled, applications can pass a different DMABUF descriptor at each
<constant>VIDIOC_QBUF</constant> call.</para>
<example>
<title>Queueing DMABUF using single plane API</title>
<programlisting>
int buffer_queue(int v4lfd, int index, int dmafd)
{
&v4l2-buffer; buf;
memset(&amp;buf, 0, sizeof buf);
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
buf.memory = V4L2_MEMORY_DMABUF;
buf.index = index;
buf.m.fd = dmafd;
if (ioctl(v4lfd, &VIDIOC-QBUF;, &amp;buf) == -1) {
perror("VIDIOC_QBUF");
return -1;
}
return 0;
}
</programlisting>
</example>
<example>
<title>Queueing DMABUF using multi plane API</title>
<programlisting>
int buffer_queue_mp(int v4lfd, int index, int dmafd[], int n_planes)
{
&v4l2-buffer; buf;
&v4l2-plane; planes[VIDEO_MAX_PLANES];
int i;
memset(&amp;buf, 0, sizeof buf);
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
buf.memory = V4L2_MEMORY_DMABUF;
buf.index = index;
buf.m.planes = planes;
buf.length = n_planes;
memset(&amp;planes, 0, sizeof planes);
for (i = 0; i &lt; n_planes; ++i)
buf.m.planes[i].m.fd = dmafd[i];
if (ioctl(v4lfd, &VIDIOC-QBUF;, &amp;buf) == -1) {
perror("VIDIOC_QBUF");
return -1;
}
return 0;
}
</programlisting>
</example>
<para>Captured or displayed buffers are dequeued with the
&VIDIOC-DQBUF; ioctl. The driver can unlock the buffer at any
time between the completion of the DMA and this ioctl. The memory is
also unlocked when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or
when the device is closed.</para>
<para>For capturing applications it is customary to enqueue a
number of empty buffers, to start capturing and enter the read loop.
Here the application waits until a filled buffer can be dequeued, and
re-enqueues the buffer when the data is no longer needed. Output
applications fill and enqueue buffers, when enough buffers are stacked
up output is started. In the write loop, when the application
runs out of free buffers it must wait until an empty buffer can be
dequeued and reused. Two methods exist to suspend execution of the
application until one or more buffers can be dequeued. By default
<constant>VIDIOC_DQBUF</constant> blocks when no buffer is in the
outgoing queue. When the <constant>O_NONBLOCK</constant> flag was
given to the &func-open; function, <constant>VIDIOC_DQBUF</constant>
returns immediately with an &EAGAIN; when no buffer is available. The
&func-select; and &func-poll; functions are always available.</para>
<para>To start and stop capturing or displaying applications call the
&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctls. Note that
<constant>VIDIOC_STREAMOFF</constant> removes all buffers from both queues and
unlocks all buffers as a side effect. Since there is no notion of doing
anything "now" on a multitasking system, if an application needs to synchronize
with another event it should examine the &v4l2-buffer;
<structfield>timestamp</structfield> of captured buffers, or set the field
before enqueuing buffers for output.</para>
<para>Drivers implementing DMABUF importing I/O must support the
<constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>,
<constant>VIDIOC_DQBUF</constant>, <constant>VIDIOC_STREAMON</constant> and
<constant>VIDIOC_STREAMOFF</constant> ioctls, and the
<function>select()</function> and <function>poll()</function> functions.</para>
</section>
<section id="async">
<title>Asynchronous I/O</title>
@ -672,6 +831,14 @@ memory, set by the application. See <xref linkend="userp" /> for details.
in the <structfield>length</structfield> field of this
<structname>v4l2_buffer</structname> structure.</entry>
</row>
<row>
<entry></entry>
<entry>int</entry>
<entry><structfield>fd</structfield></entry>
<entry>For the single-plane API and when
<structfield>memory</structfield> is <constant>V4L2_MEMORY_DMABUF</constant> this
is the file descriptor associated with a DMABUF buffer.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>length</structfield></entry>
@ -743,6 +910,15 @@ should set this to 0.</entry>
pointer to the memory allocated for this plane by an application.
</entry>
</row>
<row>
<entry></entry>
<entry>int</entry>
<entry><structfield>fd</structfield></entry>
<entry>When the memory type in the containing &v4l2-buffer; is
<constant>V4L2_MEMORY_DMABUF</constant>, this is a file
descriptor associated with a DMABUF buffer, similar to the
<structfield>fd</structfield> field in &v4l2-buffer;.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>data_offset</structfield></entry>
@ -923,7 +1099,7 @@ application. Drivers set or clear this flag when the
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry>
<entry>0x0400</entry>
<entry>0x0800</entry>
<entry>Caches do not have to be invalidated for this buffer.
Typically applications shall use this flag if the data captured in the buffer
is not going to be touched by the CPU, instead the buffer will, probably, be
@ -932,7 +1108,7 @@ passed on to a DMA-capable hardware unit for further processing or output.
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry>
<entry>0x0800</entry>
<entry>0x1000</entry>
<entry>Caches do not have to be cleaned for this buffer.
Typically applications shall use this flag for output buffers if the data
in this buffer has not been created by the CPU but by some DMA-capable unit,
@ -964,6 +1140,12 @@ pointer</link> I/O.</entry>
<entry>3</entry>
<entry>[to do]</entry>
</row>
<row>
<entry><constant>V4L2_MEMORY_DMABUF</constant></entry>
<entry>4</entry>
<entry>The buffer is used for <link linkend="dmabuf">DMA shared
buffer</link> I/O.</entry>
</row>
</tbody>
</tgroup>
</table>

1
Documentation/DocBook/media/v4l/v4l2.xml
View File

@ -543,6 +543,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-enuminput;
&sub-enumoutput;
&sub-enumstd;
&sub-expbuf;
&sub-g-audio;
&sub-g-audioout;
&sub-g-crop;

16
Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
View File

@ -6,7 +6,8 @@
<refnamediv>
<refname>VIDIOC_CREATE_BUFS</refname>
<refpurpose>Create buffers for Memory Mapped or User Pointer I/O</refpurpose>
<refpurpose>Create buffers for Memory Mapped or User Pointer or DMA Buffer
I/O</refpurpose>
</refnamediv>
<refsynopsisdiv>
@ -55,11 +56,11 @@
</note>
<para>This ioctl is used to create buffers for <link linkend="mmap">memory
mapped</link> or <link linkend="userp">user pointer</link>
I/O. It can be used as an alternative or in addition to the
<constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter control over buffers
is required. This ioctl can be called multiple times to create buffers of
different sizes.</para>
mapped</link> or <link linkend="userp">user pointer</link> or <link
linkend="dmabuf">DMA buffer</link> I/O. It can be used as an alternative or in
addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter
control over buffers is required. This ioctl can be called multiple times to
create buffers of different sizes.</para>
<para>To allocate device buffers applications initialize relevant fields of
the <structname>v4l2_create_buffers</structname> structure. They set the
@ -109,7 +110,8 @@ information.</para>
<entry>__u32</entry>
<entry><structfield>memory</structfield></entry>
<entry>Applications set this field to
<constant>V4L2_MEMORY_MMAP</constant> or
<constant>V4L2_MEMORY_MMAP</constant>,
<constant>V4L2_MEMORY_DMABUF</constant> or
<constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory"
/></entry>
</row>

212
Documentation/DocBook/media/v4l/vidioc-expbuf.xml Normal file
View File

@ -0,0 +1,212 @@
<refentry id="vidioc-expbuf">
<refmeta>
<refentrytitle>ioctl VIDIOC_EXPBUF</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_EXPBUF</refname>
<refpurpose>Export a buffer as a DMABUF file descriptor.</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_exportbuffer *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_EXPBUF</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>This ioctl is an extension to the <link linkend="mmap">memory
mapping</link> I/O method, therefore it is available only for
<constant>V4L2_MEMORY_MMAP</constant> buffers. It can be used to export a
buffer as a DMABUF file at any time after buffers have been allocated with the
&VIDIOC-REQBUFS; ioctl.</para>
<para> To export a buffer, applications fill &v4l2-exportbuffer;. The
<structfield> type </structfield> field is set to the same buffer type as was
previously used with &v4l2-requestbuffers;<structfield> type </structfield>.
Applications must also set the <structfield> index </structfield> field. Valid
index numbers range from zero to the number of buffers allocated with
&VIDIOC-REQBUFS; (&v4l2-requestbuffers;<structfield> count </structfield>)
minus one. For the multi-planar API, applications set the <structfield> plane
</structfield> field to the index of the plane to be exported. Valid planes
range from zero to the maximal number of valid planes for the currently active
format. For the single-planar API, applications must set <structfield> plane
</structfield> to zero. Additional flags may be posted in the <structfield>
flags </structfield> field. Refer to a manual for open() for details.
Currently only O_CLOEXEC is supported. All other fields must be set to zero.
In the case of multi-planar API, every plane is exported separately using
multiple <constant> VIDIOC_EXPBUF </constant> calls. </para>
<para> After calling <constant>VIDIOC_EXPBUF</constant> the <structfield> fd
</structfield> field will be set by a driver. This is a DMABUF file
descriptor. The application may pass it to other DMABUF-aware devices. Refer to
<link linkend="dmabuf">DMABUF importing</link> for details about importing
DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it
is no longer used to allow the associated memory to be reclaimed. </para>
</refsect1>
<refsect1>
<section>
<title>Examples</title>
<example>
<title>Exporting a buffer.</title>
<programlisting>
int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
{
&v4l2-exportbuffer; expbuf;
memset(&amp;expbuf, 0, sizeof(expbuf));
expbuf.type = bt;
expbuf.index = index;
if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &amp;expbuf) == -1) {
perror("VIDIOC_EXPBUF");
return -1;
}
*dmafd = expbuf.fd;
return 0;
}
</programlisting>
</example>
<example>
<title>Exporting a buffer using the multi-planar API.</title>
<programlisting>
int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
int dmafd[], int n_planes)
{
int i;
for (i = 0; i &lt; n_planes; ++i) {
&v4l2-exportbuffer; expbuf;
memset(&amp;expbuf, 0, sizeof(expbuf));
expbuf.type = bt;
expbuf.index = index;
expbuf.plane = i;
if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &amp;expbuf) == -1) {
perror("VIDIOC_EXPBUF");
while (i)
close(dmafd[--i]);
return -1;
}
dmafd[i] = expbuf.fd;
}
return 0;
}
</programlisting>
</example>
</section>
</refsect1>
<refsect1>
<table pgwide="1" frame="none" id="v4l2-exportbuffer">
<title>struct <structname>v4l2_exportbuffer</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>Type of the buffer, same as &v4l2-format;
<structfield>type</structfield> or &v4l2-requestbuffers;
<structfield>type</structfield>, set by the application. See <xref
linkend="v4l2-buf-type" /></entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>Number of the buffer, set by the application. This field is
only used for <link linkend="mmap">memory mapping</link> I/O and can range from
zero to the number of buffers allocated with the &VIDIOC-REQBUFS; and/or
&VIDIOC-CREATE-BUFS; ioctls. </entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>plane</structfield></entry>
<entry>Index of the plane to be exported when using the
multi-planar API. Otherwise this value must be set to zero. </entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Flags for the newly created file, currently only <constant>
O_CLOEXEC </constant> is supported, refer to the manual of open() for more
details.</entry>
</row>
<row>
<entry>__s32</entry>
<entry><structfield>fd</structfield></entry>
<entry>The DMABUF file descriptor associated with a buffer. Set by
the driver.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved[11]</structfield></entry>
<entry>Reserved field for future use. Must be set to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>A queue is not in MMAP mode or DMABUF exporting is not
supported or <structfield> flags </structfield> or <structfield> type
</structfield> or <structfield> index </structfield> or <structfield> plane
</structfield> fields are invalid.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

17
Documentation/DocBook/media/v4l/vidioc-qbuf.xml
View File

@ -109,6 +109,23 @@ they cannot be swapped out to disk. Buffers remain locked until
dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is
called, or until the device is closed.</para>
<para>To enqueue a <link linkend="dmabuf">DMABUF</link> buffer applications
set the <structfield>memory</structfield> field to
<constant>V4L2_MEMORY_DMABUF</constant> and the <structfield>m.fd</structfield>
field to a file descriptor associated with a DMABUF buffer. When the
multi-planar API is used the <structfield>m.fd</structfield> fields of the
passed array of &v4l2-plane; have to be used instead. When
<constant>VIDIOC_QBUF</constant> is called with a pointer to this structure the
driver sets the <constant>V4L2_BUF_FLAG_QUEUED</constant> flag and clears the
<constant>V4L2_BUF_FLAG_MAPPED</constant> and
<constant>V4L2_BUF_FLAG_DONE</constant> flags in the
<structfield>flags</structfield> field, or it returns an error code. This
ioctl locks the buffer. Locking a buffer means passing it to a driver for a
hardware access (usually DMA). If an application accesses (reads/writes) a
locked buffer then the result is undefined. Buffers remain locked until
dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is called, or
until the device is closed.</para>
<para>Applications call the <constant>VIDIOC_DQBUF</constant>
ioctl to dequeue a filled (capturing) or displayed (output) buffer
from the driver's outgoing queue. They just set the

47
Documentation/DocBook/media/v4l/vidioc-reqbufs.xml
View File

@ -48,28 +48,30 @@
<refsect1>
<title>Description</title>
<para>This ioctl is used to initiate <link linkend="mmap">memory
mapped</link> or <link linkend="userp">user pointer</link>
I/O. Memory mapped buffers are located in device memory and must be
allocated with this ioctl before they can be mapped into the
application's address space. User buffers are allocated by
applications themselves, and this ioctl is merely used to switch the
driver into user pointer I/O mode and to setup some internal structures.</para>
<para>This ioctl is used to initiate <link linkend="mmap">memory mapped</link>,
<link linkend="userp">user pointer</link> or <link
linkend="dmabuf">DMABUF</link> based I/O. Memory mapped buffers are located in
device memory and must be allocated with this ioctl before they can be mapped
into the application's address space. User buffers are allocated by
applications themselves, and this ioctl is merely used to switch the driver
into user pointer I/O mode and to setup some internal structures.
Similarly, DMABUF buffers are allocated by applications through a device
driver, and this ioctl only configures the driver into DMABUF I/O mode without
performing any direct allocation.</para>
<para>To allocate device buffers applications initialize all
fields of the <structname>v4l2_requestbuffers</structname> structure.
They set the <structfield>type</structfield> field to the respective
stream or buffer type, the <structfield>count</structfield> field to
the desired number of buffers, <structfield>memory</structfield>
must be set to the requested I/O method and the <structfield>reserved</structfield> array
must be zeroed. When the ioctl
is called with a pointer to this structure the driver will attempt to allocate
the requested number of buffers and it stores the actual number
allocated in the <structfield>count</structfield> field. It can be
smaller than the number requested, even zero, when the driver runs out
of free memory. A larger number is also possible when the driver requires
more buffers to function correctly. For example video output requires at least two buffers,
one displayed and one filled by the application.</para>
<para>To allocate device buffers applications initialize all fields of the
<structname>v4l2_requestbuffers</structname> structure. They set the
<structfield>type</structfield> field to the respective stream or buffer type,
the <structfield>count</structfield> field to the desired number of buffers,
<structfield>memory</structfield> must be set to the requested I/O method and
the <structfield>reserved</structfield> array must be zeroed. When the ioctl is
called with a pointer to this structure the driver will attempt to allocate the
requested number of buffers and it stores the actual number allocated in the
<structfield>count</structfield> field. It can be smaller than the number
requested, even zero, when the driver runs out of free memory. A larger number
is also possible when the driver requires more buffers to function correctly.
For example video output requires at least two buffers, one displayed and one
filled by the application.</para>
<para>When the I/O method is not supported the ioctl
returns an &EINVAL;.</para>
@ -102,7 +104,8 @@ as the &v4l2-format; <structfield>type</structfield> field. See <xref
<entry>__u32</entry>
<entry><structfield>memory</structfield></entry>
<entry>Applications set this field to
<constant>V4L2_MEMORY_MMAP</constant> or
<constant>V4L2_MEMORY_MMAP</constant>,
<constant>V4L2_MEMORY_DMABUF</constant> or
<constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory"
/>.</entry>
</row>

54
Documentation/PCI/pci-iov-howto.txt
View File

@ -2,6 +2,9 @@
Copyright (C) 2009 Intel Corporation
Yu Zhao <yu.zhao@intel.com>
Update: November 2012
-- sysfs-based SRIOV enable-/disable-ment
Donald Dutile <ddutile@redhat.com>
1. Overview
@ -24,10 +27,21 @@ real existing PCI device.
2.1 How can I enable SR-IOV capability
The device driver (PF driver) will control the enabling and disabling
of the capability via API provided by SR-IOV core. If the hardware
has SR-IOV capability, loading its PF driver would enable it and all
VFs associated with the PF.
Multiple methods are available for SR-IOV enablement.
In the first method, the device driver (PF driver) will control the
enabling and disabling of the capability via API provided by SR-IOV core.
If the hardware has SR-IOV capability, loading its PF driver would
enable it and all VFs associated with the PF. Some PF drivers require
a module parameter to be set to determine the number of VFs to enable.
In the second method, a write to the sysfs file sriov_numvfs will
enable and disable the VFs associated with a PCIe PF. This method
enables per-PF, VF enable/disable values versus the first method,
which applies to all PFs of the same device. Additionally, the
PCI SRIOV core support ensures that enable/disable operations are
valid to reduce duplication in multiple drivers for the same
checks, e.g., check numvfs == 0 if enabling VFs, ensure
numvfs <= totalvfs.
The second method is the recommended method for new/future VF devices.
2.2 How can I use the Virtual Functions
@ -40,20 +54,29 @@ requires device driver that is same as a normal PCI device's.
3.1 SR-IOV API
To enable SR-IOV capability:
(a) For the first method, in the driver:
int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn);
'nr_virtfn' is number of VFs to be enabled.
(b) For the second method, from sysfs:
echo 'nr_virtfn' > \
/sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs
To disable SR-IOV capability:
(a) For the first method, in the driver:
void pci_disable_sriov(struct pci_dev *dev);
(b) For the second method, from sysfs:
echo 0 > \
/sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs
To notify SR-IOV core of Virtual Function Migration:
(a) In the driver:
irqreturn_t pci_sriov_migration(struct pci_dev *dev);
3.2 Usage example
Following piece of code illustrates the usage of the SR-IOV API.
static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
static int dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
pci_enable_sriov(dev, NR_VIRTFN);
@ -62,7 +85,7 @@ static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *
return 0;
}
static void __devexit dev_remove(struct pci_dev *dev)
static void dev_remove(struct pci_dev *dev)
{
pci_disable_sriov(dev);
@ -88,12 +111,29 @@ static void dev_shutdown(struct pci_dev *dev)
...
}
static int dev_sriov_configure(struct pci_dev *dev, int numvfs)
{
if (numvfs > 0) {
...
pci_enable_sriov(dev, numvfs);
...
return numvfs;
}
if (numvfs == 0) {
....
pci_disable_sriov(dev);
...
return 0;
}
}
static struct pci_driver dev_driver = {
.name = "SR-IOV Physical Function driver",
.id_table = dev_id_table,
.probe = dev_probe,
.remove = __devexit_p(dev_remove),
.remove = dev_remove,
.suspend = dev_suspend,
.resume = dev_resume,
.shutdown = dev_shutdown,
.sriov_configure = dev_sriov_configure,
};

20
Documentation/PCI/pci.txt
View File

@ -183,12 +183,6 @@ Please mark the initialization and cleanup functions where appropriate
initializes.
__exit Exit code. Ignored for non-modular drivers.
__devinit Device initialization code.
Identical to __init if the kernel is not compiled
with CONFIG_HOTPLUG, normal function otherwise.
__devexit The same for __exit.
Tips on when/where to use the above attributes:
o The module_init()/module_exit() functions (and all
initialization functions called _only_ from these)
@ -196,20 +190,6 @@ Tips on when/where to use the above attributes:
o Do not mark the struct pci_driver.
o The ID table array should be marked __devinitconst; this is done
automatically if the table is declared with DEFINE_PCI_DEVICE_TABLE().
o The probe() and remove() functions should be marked __devinit
and __devexit respectively. All initialization functions
exclusively called by the probe() routine, can be marked __devinit.
Ditto for remove() and __devexit.
o If mydriver_remove() is marked with __devexit(), then all address
references to mydriver_remove must use __devexit_p(mydriver_remove)
(in the struct pci_driver declaration for example).
__devexit_p() will generate the function name _or_ NULL if the
function will be discarded. For an example, see drivers/net/tg3.c.
o Do NOT mark a function if you are not sure which mark to use.
Better to not mark the function than mark the function wrong.

2
Documentation/acpi/enumeration.txt
View File

@ -185,7 +185,7 @@ input driver:
.acpi_match_table ACPI_PTR(mpu3050_acpi_match),
},
.probe = mpu3050_probe,
.remove = __devexit_p(mpu3050_remove),
.remove = mpu3050_remove,
.id_table = mpu3050_ids,
};

94
Documentation/acpi/initrd_table_override.txt Normal file
View File

@ -0,0 +1,94 @@
Overriding ACPI tables via initrd
=================================
1) Introduction (What is this about)
2) What is this for
3) How does it work
4) References (Where to retrieve userspace tools)
1) What is this about
---------------------
If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible to
override nearly any ACPI table provided by the BIOS with an instrumented,
modified one.
For a full list of ACPI tables that can be overridden, take a look at
the char *table_sigs[MAX_ACPI_SIGNATURE]; definition in drivers/acpi/osl.c
All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should
be overridable, except:
- ACPI_SIG_RSDP (has a signature of 6 bytes)
- ACPI_SIG_FACS (does not have an ordinary ACPI table header)
Both could get implemented as well.
2) What is this for
-------------------
Please keep in mind that this is a debug option.
ACPI tables should not get overridden for productive use.
If BIOS ACPI tables are overridden the kernel will get tainted with the
TAINT_OVERRIDDEN_ACPI_TABLE flag.
Complain to your platform/BIOS vendor if you find a bug which is so sever
that a workaround is not accepted in the Linux kernel.
Still, it can and should be enabled in any kernel, because:
- There is no functional change with not instrumented initrds
- It provides a powerful feature to easily debug and test ACPI BIOS table
compatibility with the Linux kernel.
3) How does it work
-------------------
# Extract the machine's ACPI tables:
cd /tmp
acpidump >acpidump
acpixtract -a acpidump
# Disassemble, modify and recompile them:
iasl -d *.dat
# For example add this statement into a _PRT (PCI Routing Table) function
# of the DSDT:
Store("HELLO WORLD", debug)
iasl -sa dsdt.dsl
# Add the raw ACPI tables to an uncompressed cpio archive.
# They must be put into a /kernel/firmware/acpi directory inside the
# cpio archive.
# The uncompressed cpio archive must be the first.
# Other, typically compressed cpio archives, must be
# concatenated on top of the uncompressed one.
mkdir -p kernel/firmware/acpi
cp dsdt.aml kernel/firmware/acpi
# A maximum of: #define ACPI_OVERRIDE_TABLES 10
# tables are currently allowed (see osl.c):
iasl -sa facp.dsl
iasl -sa ssdt1.dsl
cp facp.aml kernel/firmware/acpi
cp ssdt1.aml kernel/firmware/acpi
# Create the uncompressed cpio archive and concatenate the original initrd
# on top:
find kernel | cpio -H newc --create > /boot/instrumented_initrd
cat /boot/initrd >>/boot/instrumented_initrd
# reboot with increased acpi debug level, e.g. boot params:
acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF
# and check your syslog:
[ 1.268089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 1.272091] [ACPI Debug] String [0x0B] "HELLO WORLD"
iasl is able to disassemble and recompile quite a lot different,
also static ACPI tables.
4) Where to retrieve userspace tools
------------------------------------
iasl and acpixtract are part of Intel's ACPICA project:
http://acpica.org/
and should be packaged by distributions (for example in the acpica package
on SUSE).
acpidump can be found in Len Browns pmtools:
ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump
This tool is also part of the acpica package on SUSE.
Alternatively, used ACPI tables can be retrieved via sysfs in latest kernels:
/sys/firmware/acpi/tables

4
Documentation/aoe/aoe.txt
View File

@ -125,7 +125,9 @@ DRIVER OPTIONS
The aoe_deadsecs module parameter determines the maximum number of
seconds that the driver will wait for an AoE device to provide a
response to an AoE command. After aoe_deadsecs seconds have
elapsed, the AoE device will be marked as "down".
elapsed, the AoE device will be marked as "down". A value of zero
is supported for testing purposes and makes the aoe driver keep
trying AoE commands forever.
The aoe_maxout module parameter has a default of 128. This is the
maximum number of unresponded packets that will be sent to an AoE

10
Documentation/arm/OMAP/DSS
View File

@ -285,7 +285,10 @@ FB0 +-- GFX ---- LCD ---- LCD
Misc notes
----------
OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator.
OMAP FB allocates the framebuffer memory using the standard dma allocator. You
can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma
allocator, and if CMA is enabled, you use "cma=" kernel parameter to increase
the global memory area for CMA.
Using DSI DPLL to generate pixel clock it is possible produce the pixel clock
of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI.
@ -301,11 +304,6 @@ framebuffer parameters.
Kernel boot arguments
---------------------
vram=<size>[,<physaddr>]
- Amount of total VRAM to preallocate and optionally a physical start
memory address. For example, "10M". omapfb allocates memory for
framebuffers from VRAM.
omapfb.mode=<display>:<mode>[,...]
- Default video mode for specified displays. For example,
"dvi:800x400MR-24@60". See drivers/video/modedb.c.

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

@ -35,11 +35,8 @@ For supporting platform specific data, the lp855x platform data can be used.
* mode : Brightness control mode. PWM or register based.
* device_control : Value of DEVICE CONTROL register.
* initial_brightness : Initial value of backlight brightness.
* pwm_data : Platform specific pwm generation functions.
* period_ns : Platform specific PWM period value. unit is nano.
Only valid when brightness is pwm input mode.
Functions should be implemented by PWM driver.
- pwm_set_intensity() : set duty of PWM
- pwm_get_intensity() : get current duty of PWM
* load_new_rom_data :
0 : use default configuration data
1 : update values of eeprom or eprom registers on loading driver
@ -71,8 +68,5 @@ static struct lp855x_platform_data lp8556_pdata = {
.mode = PWM_BASED,
.device_control = PWM_CONFIG(LP8556),
.initial_brightness = INITIAL_BRT,
.pwm_data = {
.pwm_set_intensity = platform_pwm_set_intensity,
.pwm_get_intensity = platform_pwm_get_intensity,
},
.period_ns = 1000000,
};

2
Documentation/cgroups/cpusets.txt
View File

@ -218,7 +218,7 @@ and name space for cpusets, with a minimum of additional kernel code.
The cpus and mems files in the root (top_cpuset) cpuset are
read-only. The cpus file automatically tracks the value of
cpu_online_mask using a CPU hotplug notifier, and the mems file
automatically tracks the value of node_states[N_HIGH_MEMORY]--i.e.,
automatically tracks the value of node_states[N_MEMORY]--i.e.,
nodes with memory--using the cpuset_track_online_nodes() hook.

66
Documentation/cgroups/memory.txt
View File

@ -71,6 +71,11 @@ Brief summary of control files.
memory.oom_control # set/show oom controls.
memory.numa_stat # show the number of memory usage per numa node
memory.kmem.limit_in_bytes # set/show hard limit for kernel memory
memory.kmem.usage_in_bytes # show current kernel memory allocation
memory.kmem.failcnt # show the number of kernel memory usage hits limits
memory.kmem.max_usage_in_bytes # show max kernel memory usage recorded
memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory
memory.kmem.tcp.usage_in_bytes # show current tcp buf memory allocation
memory.kmem.tcp.failcnt # show the number of tcp buf memory usage hits limits
@ -268,20 +273,73 @@ the amount of kernel memory used by the system. Kernel memory is fundamentally
different than user memory, since it can't be swapped out, which makes it
possible to DoS the system by consuming too much of this precious resource.
Kernel memory won't be accounted at all until limit on a group is set. This
allows for existing setups to continue working without disruption. The limit
cannot be set if the cgroup have children, or if there are already tasks in the
cgroup. Attempting to set the limit under those conditions will return -EBUSY.
When use_hierarchy == 1 and a group is accounted, its children will
automatically be accounted regardless of their limit value.
After a group is first limited, it will be kept being accounted until it
is removed. The memory limitation itself, can of course be removed by writing
-1 to memory.kmem.limit_in_bytes. In this case, kmem will be accounted, but not
limited.
Kernel memory limits are not imposed for the root cgroup. Usage for the root
cgroup may or may not be accounted.
cgroup may or may not be accounted. The memory used is accumulated into
memory.kmem.usage_in_bytes, or in a separate counter when it makes sense.
(currently only for tcp).
The main "kmem" counter is fed into the main counter, so kmem charges will
also be visible from the user counter.
Currently no soft limit is implemented for kernel memory. It is future work
to trigger slab reclaim when those limits are reached.
2.7.1 Current Kernel Memory resources accounted
* stack pages: every process consumes some stack pages. By accounting into
kernel memory, we prevent new processes from being created when the kernel
memory usage is too high.
* slab pages: pages allocated by the SLAB or SLUB allocator are tracked. A copy
of each kmem_cache is created everytime the cache is touched by the first time
from inside the memcg. The creation is done lazily, so some objects can still be
skipped while the cache is being created. All objects in a slab page should
belong to the same memcg. This only fails to hold when a task is migrated to a
different memcg during the page allocation by the cache.
* sockets memory pressure: some sockets protocols have memory pressure
thresholds. The Memory Controller allows them to be controlled individually
per cgroup, instead of globally.
* tcp memory pressure: sockets memory pressure for the tcp protocol.
2.7.3 Common use cases
Because the "kmem" counter is fed to the main user counter, kernel memory can
never be limited completely independently of user memory. Say "U" is the user
limit, and "K" the kernel limit. There are three possible ways limits can be
set:
U != 0, K = unlimited:
This is the standard memcg limitation mechanism already present before kmem
accounting. Kernel memory is completely ignored.
U != 0, K < U:
Kernel memory is a subset of the user memory. This setup is useful in
deployments where the total amount of memory per-cgroup is overcommited.
Overcommiting kernel memory limits is definitely not recommended, since the
box can still run out of non-reclaimable memory.
In this case, the admin could set up K so that the sum of all groups is
never greater than the total memory, and freely set U at the cost of his
QoS.
U != 0, K >= U:
Since kmem charges will also be fed to the user counter and reclaim will be
triggered for the cgroup for both kinds of memory. This setup gives the
admin a unified view of memory, and it is also useful for people who just
want to track kernel memory usage.
3. User Interface
0. Configuration
@ -290,6 +348,7 @@ a. Enable CONFIG_CGROUPS
b. Enable CONFIG_RESOURCE_COUNTERS
c. Enable CONFIG_MEMCG
d. Enable CONFIG_MEMCG_SWAP (to use swap extension)
d. Enable CONFIG_MEMCG_KMEM (to use kmem extension)
1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
# mount -t tmpfs none /sys/fs/cgroup
@ -406,6 +465,11 @@ About use_hierarchy, see Section 6.
Because rmdir() moves all pages to parent, some out-of-use page caches can be
moved to the parent. If you want to avoid that, force_empty will be useful.
Also, note that when memory.kmem.limit_in_bytes is set the charges due to
kernel pages will still be seen. This is not considered a failure and the
write will still return success. In this case, it is expected that
memory.kmem.usage_in_bytes == memory.usage_in_bytes.
About use_hierarchy, see Section 6.
5.2 stat file

7
Documentation/cgroups/resource_counter.txt
View File

@ -83,16 +83,17 @@ to work with it.
res_counter->lock internally (it must be called with res_counter->lock
held). The force parameter indicates whether we can bypass the limit.
e. void res_counter_uncharge[_locked]
e. u64 res_counter_uncharge[_locked]
(struct res_counter *rc, unsigned long val)
When a resource is released (freed) it should be de-accounted
from the resource counter it was accounted to. This is called
"uncharging".
"uncharging". The return value of this function indicate the amount
of charges still present in the counter.
The _locked routines imply that the res_counter->lock is taken.
f. void res_counter_uncharge_until
f. u64 res_counter_uncharge_until
(struct res_counter *rc, struct res_counter *top,
unsinged long val)

1
Documentation/device-mapper/dm-raid.txt
View File

@ -141,3 +141,4 @@ Version History
1.2.0 Handle creation of arrays that contain failed devices.
1.3.0 Added support for RAID 10
1.3.1 Allow device replacement/rebuild for RAID 10
1.3.2 Fix/improve redundancy checking for RAID10

11
Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt Normal file
View File

@ -0,0 +1,11 @@
Altera SOCFPGA Reset Manager
Required properties:
- compatible : "altr,rst-mgr"
- reg : Should contain 1 register ranges(address and length)
Example:
rstmgr@ffd05000 {
compatible = "altr,rst-mgr";
reg = <0xffd05000 0x1000>;
};

11
Documentation/devicetree/bindings/arm/altera/socfpga-system.txt Normal file
View File

@ -0,0 +1,11 @@
Altera SOCFPGA System Manager
Required properties:
- compatible : "altr,sys-mgr"
- reg : Should contain 1 register ranges(address and length)
Example:
sysmgr@ffd08000 {
compatible = "altr,sys-mgr";
reg = <0xffd08000 0x1000>;
};

12
Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
View File

@ -6,9 +6,15 @@ Required properties:
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: The number of cells to define the interrupts. Should be 1.
The cell is the IRQ number
- reg: Should contain PMIC registers location and length. First pair
for the main interrupt registers, second pair for the per-CPU
interrupt registers
interrupt registers. For this last pair, to be compliant with SMP
support, the "virtual" must be use (For the record, these registers
automatically map to the interrupt controller registers of the
current CPU)
Example:
@ -18,6 +24,6 @@ Example:
#address-cells = <1>;
#size-cells = <1>;
interrupt-controller;
reg = <0xd0020000 0x1000>,
<0xd0021000 0x1000>;
reg = <0xd0020a00 0x1d0>,
<0xd0021070 0x58>;
};

20
Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt Normal file
View File

@ -0,0 +1,20 @@
Power Management Service Unit(PMSU)
-----------------------------------
Available on Marvell SOCs: Armada 370 and Armada XP
Required properties:
- compatible: "marvell,armada-370-xp-pmsu"
- reg: Should contain PMSU registers location and length. First pair
for the per-CPU SW Reset Control registers, second pair for the
Power Management Service Unit.
Example:
armada-370-xp-pmsu@d0022000 {
compatible = "marvell,armada-370-xp-pmsu";
reg = <0xd0022100 0x430>,
<0xd0020800 0x20>;
};

1
Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
View File

@ -5,6 +5,7 @@ Required properties:
- compatible: Should be "marvell,armada-370-xp-timer"
- interrupts: Should contain the list of Global Timer interrupts
- reg: Should contain the base address of the Global Timer registers
- clocks: clock driving the timer hardware
Optional properties:
- marvell,timer-25Mhz: Tells whether the Global timer supports the 25

21
Documentation/devicetree/bindings/arm/coherency-fabric.txt Normal file
View File

@ -0,0 +1,21 @@
Coherency fabric
----------------
Available on Marvell SOCs: Armada 370 and Armada XP
Required properties:
- compatible: "marvell,coherency-fabric"
- reg: Should contain coherency fabric registers location and
length. First pair for the coherency fabric registers, second pair
for the per-CPU fabric registers registers.
Example:
coherency-fabric@d0020200 {
compatible = "marvell,coherency-fabric";
reg = <0xd0020200 0xb0>,
<0xd0021810 0x1c>;
};

8
Documentation/devicetree/bindings/arm/davinci/nand.txt
View File

@ -23,6 +23,9 @@ Recommended properties :
- ti,davinci-nand-buswidth: buswidth 8 or 16
- ti,davinci-nand-use-bbt: use flash based bad block table support.
nand device bindings may contain additional sub-nodes describing
partitions of the address space. See partition.txt for more detail.
Example(da850 EVM ):
nand_cs3@62000000 {
compatible = "ti,davinci-nand";
@ -35,4 +38,9 @@ nand_cs3@62000000 {
ti,davinci-ecc-mode = "hw";
ti,davinci-ecc-bits = <4>;
ti,davinci-nand-use-bbt;
partition@180000 {
label = "ubifs";
reg = <0x180000 0x7e80000>;
};
};

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

@ -10,6 +10,12 @@ Required properties:
"arm,pl310-cache"
"arm,l220-cache"
"arm,l210-cache"
"marvell,aurora-system-cache": Marvell Controller designed to be
compatible with the ARM one, with system cache mode (meaning
maintenance operations on L1 are broadcasted to the L2 and L2
performs the same operation).
"marvell,"aurora-outer-cache: Marvell Controller designed to be
compatible with the ARM one with outer cache mode.
- cache-unified : Specifies the cache is a unified cache.
- cache-level : Should be set to 2 for a level 2 cache.
- reg : Physical base address and size of cache controller's memory mapped
@ -29,6 +35,9 @@ Optional properties:
filter. Addresses in the filter window are directed to the M1 port. Other
addresses will go to the M0 port.
- interrupts : 1 combined interrupt.
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
Example:

48
Documentation/devicetree/bindings/arm/spear/shirq.txt Normal file
View File

@ -0,0 +1,48 @@
* SPEAr Shared IRQ layer (shirq)
SPEAr3xx architecture includes shared/multiplexed irqs for certain set
of devices. The multiplexor provides a single interrupt to parent
interrupt controller (VIC) on behalf of a group of devices.
There can be multiple groups available on SPEAr3xx variants but not
exceeding 4. The number of devices in a group can differ, further they
may share same set of status/mask registers spanning across different
bit masks. Also in some cases the group may not have enable or other
registers. This makes software little complex.
A single node in the device tree is used to describe the shared
interrupt multiplexor (one node for all groups). A group in the
interrupt controller shares config/control registers with other groups.
For example, a 32-bit interrupt enable/disable config register can
accommodate upto 4 interrupt groups.
Required properties:
- compatible: should be, either of
- "st,spear300-shirq"
- "st,spear310-shirq"
- "st,spear320-shirq"
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: should be <1> which basically contains the offset
(starting from 0) of interrupts for all the groups.
- reg: Base address and size of shirq registers.
- interrupts: The list of interrupts generated by the groups which are
then connected to a parent interrupt controller. Each group is
associated with one of the interrupts, hence number of interrupts (to
parent) is equal to number of groups. The format of the interrupt
specifier depends in the interrupt parent controller.
Optional properties:
- interrupt-parent: pHandle of the parent interrupt controller, if not
inherited from the parent node.
Example:
The following is an example from the SPEAr320 SoC dtsi file.
shirq: interrupt-controller@0xb3000000 {
compatible = "st,spear320-shirq";
reg = <0xb3000000 0x1000>;
interrupts = <28 29 30 1>;
#interrupt-cells = <1>;
interrupt-controller;
};

5
Documentation/devicetree/bindings/clock/imx23-clock.txt
View File

@ -60,11 +60,6 @@ clks: clkctrl@80040000 {
compatible = "fsl,imx23-clkctrl";
reg = <0x80040000 0x2000>;
#clock-cells = <1>;
clock-output-names =
...
"uart", /* 32 */
...
"end_of_list";
};
auart0: serial@8006c000 {

4
Documentation/devicetree/bindings/clock/imx25-clock.txt
View File

@ -146,10 +146,6 @@ clks: ccm@53f80000 {
compatible = "fsl,imx25-ccm";
reg = <0x53f80000 0x4000>;
interrupts = <31>;
clock-output-names = ...
"uart_ipg",
"uart_serial",
...;
};
uart1: serial@43f90000 {

5
Documentation/devicetree/bindings/clock/imx28-clock.txt
View File

@ -83,11 +83,6 @@ clks: clkctrl@80040000 {
compatible = "fsl,imx28-clkctrl";
reg = <0x80040000 0x2000>;
#clock-cells = <1>;
clock-output-names =
...
"uart", /* 45 */
...
"end_of_list";
};
auart0: serial@8006a000 {

4
Documentation/devicetree/bindings/clock/imx6q-clock.txt
View File

@ -211,10 +211,6 @@ clks: ccm@020c4000 {
reg = <0x020c4000 0x4000>;
interrupts = <0 87 0x04 0 88 0x04>;
#clock-cells = <1>;
clock-output-names = ...
"uart_ipg",
"uart_serial",
...;
};
uart1: serial@02020000 {

47
Documentation/devicetree/bindings/clock/mvebu-core-clock.txt Normal file
View File

@ -0,0 +1,47 @@
* Core Clock bindings for Marvell MVEBU SoCs
Marvell MVEBU SoCs usually allow to determine core clock frequencies by
reading the Sample-At-Reset (SAR) register. The core clock consumer should
specify the desired clock by having the clock ID in its "clocks" phandle cell.
The following is a list of provided IDs and clock names on Armada 370/XP:
0 = tclk (Internal Bus clock)
1 = cpuclk (CPU clock)
2 = nbclk (L2 Cache clock)
3 = hclk (DRAM control clock)
4 = dramclk (DDR clock)
The following is a list of provided IDs and clock names on Kirkwood and Dove:
0 = tclk (Internal Bus clock)
1 = cpuclk (CPU0 clock)
2 = l2clk (L2 Cache clock derived from CPU0 clock)
3 = ddrclk (DDR controller clock derived from CPU0 clock)
Required properties:
- compatible : shall be one of the following:
"marvell,armada-370-core-clock" - For Armada 370 SoC core clocks
"marvell,armada-xp-core-clock" - For Armada XP SoC core clocks
"marvell,dove-core-clock" - for Dove SoC core clocks
"marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180)
"marvell,mv88f6180-core-clock" - for Kirkwood MV88f6180 SoC
- reg : shall be the register address of the Sample-At-Reset (SAR) register
- #clock-cells : from common clock binding; shall be set to 1
Optional properties:
- clock-output-names : from common clock binding; allows overwrite default clock
output names ("tclk", "cpuclk", "l2clk", "ddrclk")
Example:
core_clk: core-clocks@d0214 {
compatible = "marvell,dove-core-clock";
reg = <0xd0214 0x4>;
#clock-cells = <1>;
};
spi0: spi@10600 {
compatible = "marvell,orion-spi";
/* ... */
/* get tclk from core clock provider */
clocks = <&core_clk 0>;
};

21
Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt Normal file
View File

@ -0,0 +1,21 @@
Device Tree Clock bindings for cpu clock of Marvell EBU platforms
Required properties:
- compatible : shall be one of the following:
"marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
- reg : Address and length of the clock complex register set
- #clock-cells : should be set to 1.
- clocks : shall be the input parent clock phandle for the clock.
cpuclk: clock-complex@d0018700 {
#clock-cells = <1>;
compatible = "marvell,armada-xp-cpu-clock";
reg = <0xd0018700 0xA0>;
clocks = <&coreclk 1>;
}
cpu@0 {
compatible = "marvell,sheeva-v7";
reg = <0>;
clocks = <&cpuclk 0>;
};

119
Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt Normal file
View File

@ -0,0 +1,119 @@
* Gated Clock bindings for Marvell Orion SoCs
Marvell Dove and Kirkwood allow some peripheral clocks to be gated to save
some power. The clock consumer should specify the desired clock by having
the clock ID in its "clocks" phandle cell. The clock ID is directly mapped to
the corresponding clock gating control bit in HW to ease manual clock lookup
in datasheet.
The following is a list of provided IDs for Armada 370:
ID Clock Peripheral
-----------------------------------
0 Audio AC97 Cntrl
1 pex0_en PCIe 0 Clock out
2 pex1_en PCIe 1 Clock out
3 ge1 Gigabit Ethernet 1
4 ge0 Gigabit Ethernet 0
5 pex0 PCIe Cntrl 0
9 pex1 PCIe Cntrl 1
15 sata0 SATA Host 0
17 sdio SDHCI Host
25 tdm Time Division Mplx
28 ddr DDR Cntrl
30 sata1 SATA Host 0
The following is a list of provided IDs for Armada XP:
ID Clock Peripheral
-----------------------------------
0 audio Audio Cntrl
1 ge3 Gigabit Ethernet 3
2 ge2 Gigabit Ethernet 2
3 ge1 Gigabit Ethernet 1
4 ge0 Gigabit Ethernet 0
5 pex0 PCIe Cntrl 0
6 pex1 PCIe Cntrl 1
7 pex2 PCIe Cntrl 2
8 pex3 PCIe Cntrl 3
13 bp
14 sata0lnk
15 sata0 SATA Host 0
16 lcd LCD Cntrl
17 sdio SDHCI Host
18 usb0 USB Host 0
19 usb1 USB Host 1
20 usb2 USB Host 2
22 xor0 XOR DMA 0
23 crypto CESA engine
25 tdm Time Division Mplx
28 xor1 XOR DMA 1
29 sata1lnk
30 sata1 SATA Host 0
The following is a list of provided IDs for Dove:
ID Clock Peripheral
-----------------------------------
0 usb0 USB Host 0
1 usb1 USB Host 1
2 ge Gigabit Ethernet
3 sata SATA Host
4 pex0 PCIe Cntrl 0
5 pex1 PCIe Cntrl 1
8 sdio0 SDHCI Host 0
9 sdio1 SDHCI Host 1
10 nand NAND Cntrl
11 camera Camera Cntrl
12 i2s0 I2S Cntrl 0
13 i2s1 I2S Cntrl 1
15 crypto CESA engine
21 ac97 AC97 Cntrl
22 pdma Peripheral DMA
23 xor0 XOR DMA 0
24 xor1 XOR DMA 1
30 gephy Gigabit Ethernel PHY
Note: gephy(30) is implemented as a parent clock of ge(2)
The following is a list of provided IDs for Kirkwood:
ID Clock Peripheral
-----------------------------------
0 ge0 Gigabit Ethernet 0
2 pex0 PCIe Cntrl 0
3 usb0 USB Host 0
4 sdio SDIO Cntrl
5 tsu Transp. Stream Unit
6 dunit SDRAM Cntrl
7 runit Runit
8 xor0 XOR DMA 0
9 audio I2S Cntrl 0
14 sata0 SATA Host 0
15 sata1 SATA Host 1
16 xor1 XOR DMA 1
17 crypto CESA engine
18 pex1 PCIe Cntrl 1
19 ge1 Gigabit Ethernet 0
20 tdm Time Division Mplx
Required properties:
- compatible : shall be one of the following:
"marvell,dove-gating-clock" - for Dove SoC clock gating
"marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating
- reg : shall be the register address of the Clock Gating Control register
- #clock-cells : from common clock binding; shall be set to 1
Optional properties:
- clocks : default parent clock phandle (e.g. tclk)
Example:
gate_clk: clock-gating-control@d0038 {
compatible = "marvell,dove-gating-clock";
reg = <0xd0038 0x4>;
/* default parent clock is tclk */
clocks = <&core_clk 0>;
#clock-cells = <1>;
};
sdio0: sdio@92000 {
compatible = "marvell,dove-sdhci";
/* get clk gate bit 8 (sdio0) */
clocks = <&gate_clk 8>;
};

5
Documentation/devicetree/bindings/crypto/fsl-sec4.txt
View File

@ -54,7 +54,8 @@ PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v4.0"
Definition: Must include "fsl,sec-v4.0". Also includes SEC
ERA versions (optional) with which the device is compatible.
- #address-cells
Usage: required
@ -106,7 +107,7 @@ PROPERTIES
EXAMPLE
crypto@300000 {
compatible = "fsl,sec-v4.0";
compatible = "fsl,sec-v4.0", "fsl,sec-era-v2.0";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x300000 0x10000>;

40
Documentation/devicetree/bindings/dma/mv-xor.txt Normal file
View File

@ -0,0 +1,40 @@
* Marvell XOR engines
Required properties:
- compatible: Should be "marvell,orion-xor"
- reg: Should contain registers location and length (two sets)
the first set is the low registers, the second set the high
registers for the XOR engine.
- clocks: pointer to the reference clock
The DT node must also contains sub-nodes for each XOR channel that the
XOR engine has. Those sub-nodes have the following required
properties:
- interrupts: interrupt of the XOR channel
And the following optional properties:
- dmacap,memcpy to indicate that the XOR channel is capable of memcpy operations
- dmacap,memset to indicate that the XOR channel is capable of memset operations
- dmacap,xor to indicate that the XOR channel is capable of xor operations
Example:
xor@d0060900 {
compatible = "marvell,orion-xor";
reg = <0xd0060900 0x100
0xd0060b00 0x100>;
clocks = <&coreclk 0>;
status = "okay";
xor00 {
interrupts = <51>;
dmacap,memcpy;
dmacap,xor;
};
xor01 {
interrupts = <52>;
dmacap,memcpy;
dmacap,xor;
dmacap,memset;
};
};

20
Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
View File

@ -1,4 +1,19 @@
GPIO line that should be set high/low to power off a device
Driver a GPIO line that can be used to turn the power off.
The driver supports both level triggered and edge triggered power off.
At driver load time, the driver will request the given gpio line and
install a pm_power_off handler. If the optional properties 'input' is
not found, the GPIO line will be driven in the inactive
state. Otherwise its configured as an input.
When the pm_power_off is called, the gpio is configured as an output,
and drive active, so triggering a level triggered power off
condition. This will also cause an inactive->active edge condition, so
triggering positive edge triggered power off. After a delay of 100ms,
the GPIO is set to inactive, thus causing an active->inactive edge,
triggering negative edge triggered power off. After another 100ms
delay the GPIO is driver active again. If the power is still on and
the CPU still running after a 3000ms delay, a WARN_ON(1) is emitted.
Required properties:
- compatible : should be "gpio-poweroff".
@ -13,10 +28,9 @@ Optional properties:
property is not specified, the GPIO is initialized as an output in its
inactive state.
Examples:
gpio-poweroff {
compatible = "gpio-poweroff";
gpios = <&gpio 4 0>; /* GPIO 4 Active Low */
gpios = <&gpio 4 0>;
};

191
Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt Normal file
View File

@ -0,0 +1,191 @@
NVIDIA Tegra host1x
Required properties:
- compatible: "nvidia,tegra<chip>-host1x"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- #address-cells: The number of cells used to represent physical base addresses
in the host1x address space. Should be 1.
- #size-cells: The number of cells used to represent the size of an address
range in the host1x address space. Should be 1.
- ranges: The mapping of the host1x address space to the CPU address space.
The host1x top-level node defines a number of children, each representing one
of the following host1x client modules:
- mpe: video encoder
Required properties:
- compatible: "nvidia,tegra<chip>-mpe"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- vi: video input
Required properties:
- compatible: "nvidia,tegra<chip>-vi"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- epp: encoder pre-processor
Required properties:
- compatible: "nvidia,tegra<chip>-epp"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- isp: image signal processor
Required properties:
- compatible: "nvidia,tegra<chip>-isp"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- gr2d: 2D graphics engine
Required properties:
- compatible: "nvidia,tegra<chip>-gr2d"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- gr3d: 3D graphics engine
Required properties:
- compatible: "nvidia,tegra<chip>-gr3d"
- reg: Physical base address and length of the controller's registers.
- dc: display controller
Required properties:
- compatible: "nvidia,tegra<chip>-dc"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
Each display controller node has a child node, named "rgb", that represents
the RGB output associated with the controller. It can take the following
optional properties:
- nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- nvidia,edid: supplies a binary EDID blob
- hdmi: High Definition Multimedia Interface
Required properties:
- compatible: "nvidia,tegra<chip>-hdmi"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- vdd-supply: regulator for supply voltage
- pll-supply: regulator for PLL
Optional properties:
- nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- nvidia,edid: supplies a binary EDID blob
- tvo: TV encoder output
Required properties:
- compatible: "nvidia,tegra<chip>-tvo"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- dsi: display serial interface
Required properties:
- compatible: "nvidia,tegra<chip>-dsi"
- reg: Physical base address and length of the controller's registers.
Example:
/ {
...
host1x {
compatible = "nvidia,tegra20-host1x", "simple-bus";
reg = <0x50000000 0x00024000>;
interrupts = <0 65 0x04 /* mpcore syncpt */
0 67 0x04>; /* mpcore general */
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x54000000 0x54000000 0x04000000>;
mpe {
compatible = "nvidia,tegra20-mpe";
reg = <0x54040000 0x00040000>;
interrupts = <0 68 0x04>;
};
vi {
compatible = "nvidia,tegra20-vi";
reg = <0x54080000 0x00040000>;
interrupts = <0 69 0x04>;
};
epp {
compatible = "nvidia,tegra20-epp";
reg = <0x540c0000 0x00040000>;
interrupts = <0 70 0x04>;
};
isp {
compatible = "nvidia,tegra20-isp";
reg = <0x54100000 0x00040000>;
interrupts = <0 71 0x04>;
};
gr2d {
compatible = "nvidia,tegra20-gr2d";
reg = <0x54140000 0x00040000>;
interrupts = <0 72 0x04>;
};
gr3d {
compatible = "nvidia,tegra20-gr3d";
reg = <0x54180000 0x00040000>;
};
dc@54200000 {
compatible = "nvidia,tegra20-dc";
reg = <0x54200000 0x00040000>;
interrupts = <0 73 0x04>;
rgb {
status = "disabled";
};
};
dc@54240000 {
compatible = "nvidia,tegra20-dc";
reg = <0x54240000 0x00040000>;
interrupts = <0 74 0x04>;
rgb {
status = "disabled";
};
};
hdmi {
compatible = "nvidia,tegra20-hdmi";
reg = <0x54280000 0x00040000>;
interrupts = <0 75 0x04>;
status = "disabled";
};
tvo {
compatible = "nvidia,tegra20-tvo";
reg = <0x542c0000 0x00040000>;
interrupts = <0 76 0x04>;
status = "disabled";
};
dsi {
compatible = "nvidia,tegra20-dsi";
reg = <0x54300000 0x00040000>;
status = "disabled";
};
};
...
};

27
Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt Normal file
View File

@ -0,0 +1,27 @@
Device tree bindings for i2c-cbus-gpio driver
Required properties:
- compatible = "i2c-cbus-gpio";
- gpios: clk, dat, sel
- #address-cells = <1>;
- #size-cells = <0>;
Optional properties:
- child nodes conforming to i2c bus binding
Example:
i2c@0 {
compatible = "i2c-cbus-gpio";
gpios = <&gpio 66 0 /* clk */
&gpio 65 0 /* dat */
&gpio 64 0 /* sel */
>;
#address-cells = <1>;
#size-cells = <0>;
retu-mfd: retu@1 {
compatible = "retu-mfd";
reg = <0x1>;
};
};

81
Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt Normal file
View File

@ -0,0 +1,81 @@
GPIO-based I2C Bus Mux
This binding describes an I2C bus multiplexer that uses GPIOs to
route the I2C signals.
+-----+ +-----+
| dev | | dev |
+------------+ +-----+ +-----+
| SoC | | |
| | /--------+--------+
| +------+ | +------+ child bus A, on GPIO value set to 0
| | I2C |-|--| Mux |
| +------+ | +--+---+ child bus B, on GPIO value set to 1
| | | \----------+--------+--------+
| +------+ | | | | |
| | GPIO |-|-----+ +-----+ +-----+ +-----+
| +------+ | | dev | | dev | | dev |
+------------+ +-----+ +-----+ +-----+
Required properties:
- compatible: i2c-mux-gpio
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
port is connected to.
- mux-gpios: list of gpios used to control the muxer
* Standard I2C mux properties. See mux.txt in this directory.
* I2C child bus nodes. See mux.txt in this directory.
Optional properties:
- idle-state: value to set the muxer to when idle. When no value is
given, it defaults to the last value used.
For each i2c child node, an I2C child bus will be created. They will
be numbered based on their order in the device tree.
Whenever an access is made to a device on a child bus, the value set
in the revelant node's reg property will be output using the list of
GPIOs, the first in the list holding the least-significant value.
If an idle state is defined, using the idle-state (optional) property,
whenever an access is not being made to a device on a child bus, the
GPIOs will be set according to the idle value.
If an idle state is not defined, the most recently used value will be
left programmed into hardware whenever no access is being made to a
device on a child bus.
Example:
i2cmux {
compatible = "i2c-mux-gpio";
#address-cells = <1>;
#size-cells = <0>;
mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
i2c-parent = <&i2c1>;
i2c@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
ssd1307: oled@3c {
compatible = "solomon,ssd1307fb-i2c";
reg = <0x3c>;
pwms = <&pwm 4 3000>;
reset-gpios = <&gpio2 7 1>;
reset-active-low;
};
};
i2c@3 {
reg = <3>;
#address-cells = <1>;
#size-cells = <0>;
pca9555: pca9555@20 {
compatible = "nxp,pca9555";
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
};
};
};

2
Documentation/devicetree/bindings/i2c/i2c-ocores.txt
View File

@ -1,7 +1,7 @@
Device tree configuration for i2c-ocores
Required properties:
- compatible : "opencores,i2c-ocores"
- compatible : "opencores,i2c-ocores" or "aeroflexgaisler,i2cmst"
- reg : bus address start and address range size of device
- interrupts : interrupt number
- clock-frequency : frequency of bus clock in Hz

20
Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
View File

@ -13,11 +13,17 @@ Required properties:
- interrupts: interrupt number to the cpu.
- samsung,i2c-sda-delay: Delay (in ns) applied to data line (SDA) edges.
Required for all cases except "samsung,s3c2440-hdmiphy-i2c":
- Samsung GPIO variant (deprecated):
- gpios: The order of the gpios should be the following: <SDA, SCL>.
The gpio specifier depends on the gpio controller. Required in all
cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output
lines are permanently wired to the respective clienta
- Pinctrl variant (preferred, if available):
- pinctrl-0: Pin control group to be used for this controller.
- pinctrl-names: Should contain only one value - "default".
Optional properties:
- gpios: The order of the gpios should be the following: <SDA, SCL>.
The gpio specifier depends on the gpio controller. Required in all
cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output
lines are permanently wired to the respective client
- samsung,i2c-slave-addr: Slave address in multi-master enviroment. If not
specified, default value is 0.
- samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not
@ -31,8 +37,14 @@ Example:
interrupts = <345>;
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <100000>;
/* Samsung GPIO variant begins here */
gpios = <&gpd1 2 0 /* SDA */
&gpd1 3 0 /* SCL */>;
/* Samsung GPIO variant ends here */
/* Pinctrl variant begins here */
pinctrl-0 = <&i2c3_bus>;
pinctrl-names = "default";
/* Pinctrl variant ends here */
#address-cells = <1>;
#size-cells = <0>;

46
Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt Normal file
View File

@ -0,0 +1,46 @@
* GPIO driven matrix keypad device tree bindings
GPIO driven matrix keypad is used to interface a SoC with a matrix keypad.
The matrix keypad supports multiple row and column lines, a key can be
placed at each intersection of a unique row and a unique column. The matrix
keypad can sense a key-press and key-release by means of GPIO lines and
report the event using GPIO interrupts to the cpu.
Required Properties:
- compatible: Should be "gpio-matrix-keypad"
- row-gpios: List of gpios used as row lines. The gpio specifier
for this property depends on the gpio controller to
which these row lines are connected.
- col-gpios: List of gpios used as column lines. The gpio specifier
for this property depends on the gpio controller to
which these column lines are connected.
- linux,keymap: The definition can be found at
bindings/input/matrix-keymap.txt
Optional Properties:
- linux,no-autorepeat: do no enable autorepeat feature.
- linux,wakeup: use any event on keypad as wakeup event.
- debounce-delay-ms: debounce interval in milliseconds
- col-scan-delay-us: delay, measured in microseconds, that is needed
before we can scan keypad after activating column gpio
Example:
matrix-keypad {
compatible = "gpio-matrix-keypad";
debounce-delay-ms = <5>;
col-scan-delay-us = <2>;
row-gpios = <&gpio2 25 0
&gpio2 26 0
&gpio2 27 0>;
col-gpios = <&gpio2 21 0
&gpio2 22 0>;
linux,keymap = <0x0000008B
0x0100009E
0x02000069
0x0001006A
0x0101001C
0x0201006C>;
};

7
Documentation/devicetree/bindings/input/pwm-beeper.txt Normal file
View File

@ -0,0 +1,7 @@
* PWM beeper device tree bindings
Registers a PWM device as beeper.
Required properties:
- compatible: should be "pwm-beeper"
- pwms: phandle to the physical PWM device

39
Documentation/devicetree/bindings/input/stmpe-keypad.txt Normal file
View File

@ -0,0 +1,39 @@
* STMPE Keypad
Required properties:
- compatible : "st,stmpe-keypad"
- linux,keymap : See ./matrix-keymap.txt
Optional properties:
- debounce-interval : Debouncing interval time in milliseconds
- st,scan-count : Scanning cycles elapsed before key data is updated
- st,no-autorepeat : If specified device will not autorepeat
Example:
stmpe_keypad {
compatible = "st,stmpe-keypad";
debounce-interval = <64>;
st,scan-count = <8>;
st,no-autorepeat;
linux,keymap = <0x205006b
0x4010074
0x3050072
0x1030004
0x502006a
0x500000a
0x5008b
0x706001c
0x405000b
0x6070003
0x3040067
0x303006c
0x60400e7
0x602009e
0x4020073
0x5050002
0x4030069
0x3020008>;
};

8
Documentation/devicetree/bindings/input/tca8418_keypad.txt Normal file
View File

@ -0,0 +1,8 @@
Required properties:
- compatible: "ti,tca8418"
- reg: the I2C address
- interrupts: IRQ line number, should trigger on falling edge
- keypad,num-rows: The number of rows
- keypad,num-columns: The number of columns
- linux,keymap: Keys definitions, see keypad-matrix.

34
Documentation/devicetree/bindings/input/touchscreen/mms114.txt Normal file
View File

@ -0,0 +1,34 @@
* MELFAS MMS114 touchscreen controller
Required properties:
- compatible: must be "melfas,mms114"
- reg: I2C address of the chip
- interrupts: interrupt to which the chip is connected
- x-size: horizontal resolution of touchscreen
- y-size: vertical resolution of touchscreen
Optional properties:
- contact-threshold:
- moving-threshold:
- x-invert: invert X axis
- y-invert: invert Y axis
Example:
i2c@00000000 {
/* ... */
touchscreen@48 {
compatible = "melfas,mms114";
reg = <0x48>;
interrupts = <39 0>;
x-size = <720>;
y-size = <1280>;
contact-threshold = <10>;
moving-threshold = <10>;
x-invert;
y-invert;
};
/* ... */
};

43
Documentation/devicetree/bindings/input/touchscreen/stmpe.txt Normal file
View File

@ -0,0 +1,43 @@
STMPE Touchscreen
----------------
Required properties:
- compatible: "st,stmpe-ts"
Optional properties:
- st,sample-time: ADC converstion time in number of clock. (0 -> 36 clocks, 1 ->
44 clocks, 2 -> 56 clocks, 3 -> 64 clocks, 4 -> 80 clocks, 5 -> 96 clocks, 6
-> 144 clocks), recommended is 4.
- st,mod-12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
- st,ref-sel: ADC reference source (0 -> internal reference, 1 -> external
reference)
- st,adc-freq: ADC Clock speed (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 -> 6.5 MHz)
- st,ave-ctrl: Sample average control (0 -> 1 sample, 1 -> 2 samples, 2 -> 4
samples, 3 -> 8 samples)
- st,touch-det-delay: Touch detect interrupt delay (0 -> 10 us, 1 -> 50 us, 2 ->
100 us, 3 -> 500 us, 4-> 1 ms, 5 -> 5 ms, 6 -> 10 ms, 7 -> 50 ms) recommended
is 3
- st,settling: Panel driver settling time (0 -> 10 us, 1 -> 100 us, 2 -> 500 us, 3
-> 1 ms, 4 -> 5 ms, 5 -> 10 ms, 6 for 50 ms, 7 -> 100 ms) recommended is 2
- st,fraction-z: Length of the fractional part in z (fraction-z ([0..7]) = Count of
the fractional part) recommended is 7
- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA typical 35
mA max, 1 -> 50 mA typical 80 mA max)
Node name must be stmpe_touchscreen and should be child node of stmpe node to
which it belongs.
Example:
stmpe_touchscreen {
compatible = "st,stmpe-ts";
st,sample-time = <4>;
st,mod-12b = <1>;
st,ref-sel = <0>;
st,adc-freq = <1>;
st,ave-ctrl = <1>;
st,touch-det-delay = <2>;
st,settling = <2>;
st,fraction-z = <7>;
st,i-drive = <1>;
};

27
Documentation/devicetree/bindings/mfd/ab8500.txt
View File

@ -24,7 +24,32 @@ ab8500-bm : : : Battery Manager
ab8500-btemp : : : Battery Temperature
ab8500-charger : : : Battery Charger
ab8500-codec : : : Audio Codec
ab8500-fg : : : Fuel Gauge
ab8500-fg : : vddadc : Fuel Gauge
: NCONV_ACCU : : Accumulate N Sample Conversion
: BATT_OVV : : Battery Over Voltage
: LOW_BAT_F : : LOW threshold battery voltage
: CC_INT_CALIB : : Coulomb Counter Internal Calibration
: CCEOC : : Coulomb Counter End of Conversion
ab8500-btemp : : vtvout : Battery Temperature
: BAT_CTRL_INDB : : Battery Removal Indicator
: BTEMP_LOW : : Btemp < BtempLow, if battery temperature is lower than -10°C
: BTEMP_LOW_MEDIUM : : BtempLow < Btemp < BtempMedium,if battery temperature is between -10 and 0°C
: BTEMP_MEDIUM_HIGH : : BtempMedium < Btemp < BtempHigh,if battery temperature is between 0°C and“MaxTemp
: BTEMP_HIGH : : Btemp > BtempHigh, if battery temperature is higher than “MaxTemp
ab8500-charger : : vddadc : Charger interface
: MAIN_CH_UNPLUG_DET : : main charger unplug detection management (not in 8505)
: MAIN_CHARGE_PLUG_DET : : main charger plug detection management (not in 8505)
: MAIN_EXT_CH_NOT_OK : : main charger not OK
: MAIN_CH_TH_PROT_R : : Die temp is above main charger
: MAIN_CH_TH_PROT_F : : Die temp is below main charger
: VBUS_DET_F : : VBUS falling detected
: VBUS_DET_R : : VBUS rising detected
: USB_LINK_STATUS : : USB link status has changed
: USB_CH_TH_PROT_R : : Die temp is above usb charger
: USB_CH_TH_PROT_F : : Die temp is below usb charger
: USB_CHARGER_NOT_OKR : : allowed USB charger not ok detection
: VBUS_OVV : : Overvoltage on Vbus ball detected (USB charge is stopped)
: CH_WD_EXP : : Charger watchdog detected
ab8500-gpadc : HW_CONV_END : vddadc : Analogue to Digital Converter
SW_CONV_END : :
ab8500-gpio : : : GPIO Controller

28
Documentation/devicetree/bindings/mfd/stmpe.txt Normal file
View File

@ -0,0 +1,28 @@
* ST Microelectronics STMPE Multi-Functional Device
STMPE is an MFD device which may expose the following inbuilt devices: gpio,
keypad, touchscreen, adc, pwm, rotator.
Required properties:
- compatible : "st,stmpe[610|801|811|1601|2401|2403]"
- reg : I2C/SPI address of the device
Optional properties:
- interrupts : The interrupt outputs from the controller
- interrupt-controller : Marks the device node as an interrupt controller
- interrupt-parent : Specifies which IRQ controller we're connected to
- wakeup-source : Marks the input device as wakable
- st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
Example:
stmpe1601: stmpe1601@40 {
compatible = "st,stmpe1601";
reg = <0x40>;
interrupts = <26 0x4>;
interrupt-parent = <&gpio6>;
interrupt-controller;
wakeup-source;
st,autosleep-timeout = <1024>;
};

23
Documentation/devicetree/bindings/mtd/denali-nand.txt Normal file
View File

@ -0,0 +1,23 @@
* Denali NAND controller
Required properties:
- compatible : should be "denali,denali-nand-dt"
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
- interrupts : The interrupt number.
- dm-mask : DMA bit mask
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
Examples:
nand: nand@ff900000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "denali,denali-nand-dt";
reg = <0xff900000 0x100000>, <0xffb80000 0x10000>;
reg-names = "nand_data", "denali_reg";
interrupts = <0 144 4>;
dma-mask = <0xffffffff>;
};

49
Documentation/devicetree/bindings/mtd/flctl-nand.txt Normal file
View File

@ -0,0 +1,49 @@
FLCTL NAND controller
Required properties:
- compatible : "renesas,shmobile-flctl-sh7372"
- reg : Address range of the FLCTL
- interrupts : flste IRQ number
- nand-bus-width : bus width to NAND chip
Optional properties:
- dmas: DMA specifier(s)
- dma-names: name for each DMA specifier. Valid names are
"data_tx", "data_rx", "ecc_tx", "ecc_rx"
The DMA fields are not used yet in the driver but are listed here for
completing the bindings.
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
Example:
flctl@e6a30000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "renesas,shmobile-flctl-sh7372";
reg = <0xe6a30000 0x100>;
interrupts = <0x0d80>;
nand-bus-width = <16>;
dmas = <&dmac 1 /* data_tx */
&dmac 2;> /* data_rx */
dma-names = "data_tx", "data_rx";
system@0 {
label = "system";
reg = <0x0 0x8000000>;
};
userdata@8000000 {
label = "userdata";
reg = <0x8000000 0x10000000>;
};
cache@18000000 {
label = "cache";
reg = <0x18000000 0x8000000>;
};
};

12
Documentation/devicetree/bindings/mtd/fsmc-nand.txt
View File

@ -3,9 +3,7 @@
Required properties:
- compatible : "st,spear600-fsmc-nand"
- reg : Address range of the mtd chip
- reg-names: Should contain the reg names "fsmc_regs" and "nand_data"
- st,ale-off : Chip specific offset to ALE
- st,cle-off : Chip specific offset to CLE
- reg-names: Should contain the reg names "fsmc_regs", "nand_data", "nand_addr" and "nand_cmd"
Optional properties:
- bank-width : Width (in bytes) of the device. If not present, the width
@ -19,10 +17,10 @@ Example:
#address-cells = <1>;
#size-cells = <1>;
reg = <0xd1800000 0x1000 /* FSMC Register */
0xd2000000 0x4000>; /* NAND Base */
reg-names = "fsmc_regs", "nand_data";
st,ale-off = <0x20000>;
st,cle-off = <0x10000>;
0xd2000000 0x0010 /* NAND Base DATA */
0xd2020000 0x0010 /* NAND Base ADDR */
0xd2010000 0x0010>; /* NAND Base CMD */
reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd";
bank-width = <1>;
nand-skip-bbtscan;

29
Documentation/devicetree/bindings/mtd/m25p80.txt Normal file
View File

@ -0,0 +1,29 @@
* MTD SPI driver for ST M25Pxx (and similar) serial flash chips
Required properties:
- #address-cells, #size-cells : Must be present if the device has sub-nodes
representing partitions.
- compatible : Should be the manufacturer and the name of the chip. Bear in mind
the DT binding is not Linux-only, but in case of Linux, see the
"m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of
supported chips.
- reg : Chip-Select number
- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
Optional properties:
- m25p,fast-read : Use the "fast read" opcode to read data from the chip instead
of the usual "read" opcode. This opcode is not supported by
all chips and support for it can not be detected at runtime.
Refer to your chips' datasheet to check if this is supported
by your chip.
Example:
flash: m25p80@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "spansion,m25p80";
reg = <0>;
spi-max-frequency = <40000000>;
m25p,fast-read;
};

3
Documentation/devicetree/bindings/mtd/mtd-physmap.txt
View File

@ -23,6 +23,9 @@ file systems on embedded devices.
unaligned accesses as implemented in the JFFS2 code via memcpy().
By defining "no-unaligned-direct-access", the flash will not be
exposed directly to the MTD users (e.g. JFFS2) any more.
- linux,mtd-name: allow to specify the mtd name for retro capability with
physmap-flash drivers as boot loader pass the mtd partition via the old
device name physmap-flash.
For JEDEC compatible devices, the following additional properties
are defined:

23
Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt Normal file
View File

@ -0,0 +1,23 @@
* Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
Required properties:
- compatible: should be "marvell,armada-370-neta".
- reg: address and length of the register set for the device.
- interrupts: interrupt for the device
- phy: A phandle to a phy node defining the PHY address (as the reg
property, a single integer).
- phy-mode: The interface between the SoC and the PHY (a string that
of_get_phy_mode() can understand)
- clocks: a pointer to the reference clock for this device.
Example:
ethernet@d0070000 {
compatible = "marvell,armada-370-neta";
reg = <0xd0070000 0x2500>;
interrupts = <8>;
clocks = <&gate_clk 4>;
status = "okay";
phy = <&phy0>;
phy-mode = "rgmii-id";
};

35
Documentation/devicetree/bindings/net/marvell-orion-mdio.txt Normal file
View File

@ -0,0 +1,35 @@
* Marvell MDIO Ethernet Controller interface
The Ethernet controllers of the Marvel Kirkwood, Dove, Orion5x,
MV78xx0, Armada 370 and Armada XP have an identical unit that provides
an interface with the MDIO bus. This driver handles this MDIO
interface.
Required properties:
- compatible: "marvell,orion-mdio"
- reg: address and length of the SMI register
The child nodes of the MDIO driver are the individual PHY devices
connected to this MDIO bus. They must have a "reg" property given the
PHY address on the MDIO bus.
Example at the SoC level:
mdio {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,orion-mdio";
reg = <0xd0072004 0x4>;
};
And at the board level:
mdio {
phy0: ethernet-phy@0 {
reg = <0>;
};
phy1: ethernet-phy@1 {
reg = <1>;
};
}

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

@ -81,7 +81,8 @@ PA31 TXD4
Required properties for pin configuration node:
- atmel,pins: 4 integers array, represents a group of pins mux and config
setting. The format is atmel,pins = <PIN_BANK PIN_BANK_NUM PERIPH CONFIG>.
The PERIPH 0 means gpio.
The PERIPH 0 means gpio, PERIPH 1 is periph A, PERIPH 2 is periph B...
PIN_BANK 0 is pioA, PIN_BANK 1 is pioB...
Bits used for CONFIG:
PULL_UP (1 << 0): indicate this pin need a pull up.
@ -126,7 +127,7 @@ pinctrl@fffff400 {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
<1 14 0x1 0x0 /* PB14 periph A */
1 15 0x1 0x1>; /* PB15 periph with pullup */
1 15 0x1 0x1>; /* PB15 periph A with pullup */
};
};
};

47
Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt Normal file
View File

@ -0,0 +1,47 @@
CSR SiRFprimaII pinmux controller
Required properties:
- compatible : "sirf,prima2-pinctrl"
- reg : Address range of the pinctrl registers
- interrupts : Interrupts used by every GPIO group
- gpio-controller : Indicates this device is a GPIO controller
- interrupt-controller : Marks the device node as an interrupt controller
Optional properties:
- sirf,pullups : if n-th bit of m-th bank is set, set a pullup on GPIO-n of bank m
- sirf,pulldowns : if n-th bit of m-th bank is set, set a pulldown on GPIO-n of bank m
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.
Each of these subnodes represents some desired configuration for a group of pins.
Required subnode-properties:
- sirf,pins : An array of strings. Each string contains the name of a group.
- sirf,function: A string containing the name of the function to mux to the
group.
Valid values for group and function names can be found from looking at the
group and function arrays in driver files:
drivers/pinctrl/pinctrl-sirf.c
For example, pinctrl might have subnodes like the following:
uart2_pins_a: uart2@0 {
uart {
sirf,pins = "uart2grp";
sirf,function = "uart2";
};
};
uart2_noflow_pins_a: uart2@1 {
uart {
sirf,pins = "uart2_nostreamctrlgrp";
sirf,function = "uart2_nostreamctrl";
};
};
For a specific board, if it wants to use uart2 without hardware flow control,
it can add the following to its board-specific .dts file.
uart2: uart@0xb0070000 {
pinctrl-names = "default";
pinctrl-0 = <&uart2_noflow_pins_a>;
}

16
Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt Normal file
View File

@ -0,0 +1,16 @@
=== AB8500 Battery Temperature Monitor Driver ===
The properties below describes the node for btemp driver.
Required Properties:
- compatible = Shall be: "stericsson,ab8500-btemp"
- battery = Shall be battery specific information
Example:
ab8500_btemp {
compatible = "stericsson,ab8500-btemp";
battery = <&ab8500_battery>;
};
For information on battery specific node, Ref:
Documentation/devicetree/bindings/power_supply/ab8500/fg.txt

16
Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt Normal file
View File

@ -0,0 +1,16 @@
=== AB8500 Charging Algorithm Driver ===
The properties below describes the node for chargalg driver.
Required Properties:
- compatible = Shall be: "stericsson,ab8500-chargalg"
- battery = Shall be battery specific information
Example:
ab8500_chargalg {
compatible = "stericsson,ab8500-chargalg";
battery = <&ab8500_battery>;
};
For information on battery specific node, Ref:
Documentation/devicetree/bindings/power_supply/ab8500/fg.txt

25
Documentation/devicetree/bindings/power_supply/ab8500/charger.txt Normal file
View File

@ -0,0 +1,25 @@
=== AB8500 Charger Driver ===
Required Properties:
- compatible = Shall be "stericsson,ab8500-charger"
- battery = Shall be battery specific information
Example:
ab8500_charger {
compatible = "stericsson,ab8500-charger";
battery = <&ab8500_battery>;
};
- vddadc-supply: Supply for USB and Main charger
Example:
ab8500-charger {
vddadc-supply = <&ab8500_ldo_tvout_reg>;
}
- autopower_cfg:
Boolean value depicting the presence of 'automatic poweron after powerloss'
Example:
ab8500-charger {
autopower_cfg;
};
For information on battery specific node, Ref:
Documentation/devicetree/bindings/power_supply/ab8500/fg.txt

58
Documentation/devicetree/bindings/power_supply/ab8500/fg.txt Normal file
View File

@ -0,0 +1,58 @@
=== AB8500 Fuel Gauge Driver ===
AB8500 is a mixed signal multimedia and power management
device comprising: power and energy-management-module,
wall-charger, usb-charger, audio codec, general purpose adc,
tvout, clock management and sim card interface.
Fuelgauge support is part of energy-management-modules, other
components of this module are:
main-charger, usb-combo-charger and battery-temperature-monitoring.
The properties below describes the node for fuelgauge driver.
Required Properties:
- compatible = This shall be: "stericsson,ab8500-fg"
- battery = Shall be battery specific information
Example:
ab8500_fg {
compatible = "stericsson,ab8500-fg";
battery = <&ab8500_battery>;
};
dependent node:
ab8500_battery: ab8500_battery {
};
This node will provide information on 'thermistor interface' and
'battery technology type' used.
Properties of this node are:
thermistor-on-batctrl:
A boolean value indicating thermistor interface to battery
Note:
'btemp' and 'batctrl' are the pins interfaced for battery temperature
measurement, 'btemp' signal is used when NTC(negative temperature
coefficient) resister is interfaced external to battery whereas
'batctrl' pin is used when NTC resister is internal to battery.
Example:
ab8500_battery: ab8500_battery {
thermistor-on-batctrl;
};
indicates: NTC resister is internal to battery, 'batctrl' is used
for thermal measurement.
The absence of property 'thermal-on-batctrl' indicates
NTC resister is external to battery and 'btemp' signal is used
for thermal measurement.
battery-type:
This shall be the battery manufacturing technology type,
allowed types are:
"UNKNOWN" "NiMH" "LION" "LIPO" "LiFe" "NiCd" "LiMn"
Example:
ab8500_battery: ab8500_battery {
stericsson,battery-type = "LIPO";
}

81
Documentation/devicetree/bindings/powerpc/fsl/raideng.txt Normal file
View File

@ -0,0 +1,81 @@
* Freescale 85xx RAID Engine nodes
RAID Engine nodes are defined to describe on-chip RAID accelerators. Each RAID
Engine should have a separate node.
Supported chips:
P5020, P5040
Required properties:
- compatible: Should contain "fsl,raideng-v1.0" as the value
This identifies RAID Engine block. 1 in 1.0 represents
major number whereas 0 represents minor number. The
version matches the hardware IP version.
- reg: offset and length of the register set for the device
- ranges: standard ranges property specifying the translation
between child address space and parent address space
Example:
/* P5020 */
raideng: raideng@320000 {
compatible = "fsl,raideng-v1.0";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x320000 0x10000>;
ranges = <0 0x320000 0x10000>;
};
There must be a sub-node for each job queue present in RAID Engine
This node must be a sub-node of the main RAID Engine node
- compatible: Should contain "fsl,raideng-v1.0-job-queue" as the value
This identifies the job queue interface
- reg: offset and length of the register set for job queue
- ranges: standard ranges property specifying the translation
between child address space and parent address space
Example:
/* P5020 */
raideng_jq0@1000 {
compatible = "fsl,raideng-v1.0-job-queue";
reg = <0x1000 0x1000>;
ranges = <0x0 0x1000 0x1000>;
};
There must be a sub-node for each job ring present in RAID Engine
This node must be a sub-node of job queue node
- compatible: Must contain "fsl,raideng-v1.0-job-ring" as the value
This identifies job ring. Should contain either
"fsl,raideng-v1.0-hp-ring" or "fsl,raideng-v1.0-lp-ring"
depending upon whether ring has high or low priority
- reg: offset and length of the register set for job ring
- interrupts: interrupt mapping for job ring IRQ
Optional property:
- fsl,liodn: Specifies the LIODN to be used for Job Ring. This
property is normally set by firmware. Value
is of 12-bits which is the LIODN number for this JR.
This property is used by the IOMMU (PAMU) to distinquish
transactions from this JR and than be able to do address
translation & protection accordingly.
Example:
/* P5020 */
raideng_jq0@1000 {
compatible = "fsl,raideng-v1.0-job-queue";
reg = <0x1000 0x1000>;
ranges = <0x0 0x1000 0x1000>;
raideng_jr0: jr@0 {
compatible = "fsl,raideng-v1.0-job-ring", "fsl,raideng-v1.0-hp-ring";
reg = <0x0 0x400>;
interrupts = <139 2 0 0>;
interrupt-parent = <&mpic>;
fsl,liodn = <0x41>;
};
};

23
Documentation/devicetree/bindings/pwm/pwm-tiecap.txt Normal file
View File

@ -0,0 +1,23 @@
TI SOC ECAP based APWM controller
Required properties:
- compatible: Must be "ti,am33xx-ecap"
- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
First cell specifies the per-chip index of the PWM to use, the second
cell is the period in nanoseconds and bit 0 in the third cell is used to
encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
to 1 for inverse polarity & set to 0 for normal polarity.
- reg: physical base address and size of the registers map.
Optional properties:
- ti,hwmods: Name of the hwmod associated to the ECAP:
"ecap<x>", <x> being the 0-based instance number from the HW spec
Example:
ecap0: ecap@0 {
compatible = "ti,am33xx-ecap";
#pwm-cells = <3>;
reg = <0x48300100 0x80>;
ti,hwmods = "ecap0";
};

23
Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt Normal file
View File

@ -0,0 +1,23 @@
TI SOC EHRPWM based PWM controller
Required properties:
- compatible : Must be "ti,am33xx-ehrpwm"
- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
First cell specifies the per-chip index of the PWM to use, the second
cell is the period in nanoseconds and bit 0 in the third cell is used to
encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
to 1 for inverse polarity & set to 0 for normal polarity.
- reg: physical base address and size of the registers map.
Optional properties:
- ti,hwmods: Name of the hwmod associated to the EHRPWM:
"ehrpwm<x>", <x> being the 0-based instance number from the HW spec
Example:
ehrpwm0: ehrpwm@0 {
compatible = "ti,am33xx-ehrpwm";
#pwm-cells = <3>;
reg = <0x48300200 0x100>;
ti,hwmods = "ehrpwm0";
};

31
Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt Normal file
View File

@ -0,0 +1,31 @@
TI SOC based PWM Subsystem
Required properties:
- compatible: Must be "ti,am33xx-pwmss";
- reg: physical base address and size of the registers map.
- address-cells: Specify the number of u32 entries needed in child nodes.
Should set to 1.
- size-cells: specify number of u32 entries needed to specify child nodes size
in reg property. Should set to 1.
- ranges: describes the address mapping of a memory-mapped bus. Should set to
physical address map of child's base address, physical address within
parent's address space and length of the address map. For am33xx,
3 set of child register maps present, ECAP register space, EQEP
register space, EHRPWM register space.
Also child nodes should also populated under PWMSS DT node.
Example:
pwmss0: pwmss@48300000 {
compatible = "ti,am33xx-pwmss";
reg = <0x48300000 0x10>;
ti,hwmods = "epwmss0";
#address-cells = <1>;
#size-cells = <1>;
status = "disabled";
ranges = <0x48300100 0x48300100 0x80 /* ECAP */
0x48300180 0x48300180 0x80 /* EQEP */
0x48300200 0x48300200 0x80>; /* EHRPWM */
/* child nodes go here */
};

17
Documentation/devicetree/bindings/pwm/pwm.txt
View File

@ -37,10 +37,21 @@ device:
pwm-names = "backlight";
};
Note that in the example above, specifying the "pwm-names" is redundant
because the name "backlight" would be used as fallback anyway.
pwm-specifier typically encodes the chip-relative PWM number and the PWM
period in nanoseconds. Note that in the example above, specifying the
"pwm-names" is redundant because the name "backlight" would be used as
fallback anyway.
period in nanoseconds.
Optionally, the pwm-specifier can encode a number of flags in a third cell:
- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
Example with optional PWM specifier for inverse polarity
bl: backlight {
pwms = <&pwm 0 5000000 1>;
pwm-names = "backlight";
};
2) PWM controller nodes
-----------------------

18
Documentation/devicetree/bindings/pwm/spear-pwm.txt Normal file
View File

@ -0,0 +1,18 @@
== ST SPEAr SoC PWM controller ==
Required properties:
- compatible: should be one of:
- "st,spear320-pwm"
- "st,spear1340-pwm"
- reg: physical base address and length of the controller's registers
- #pwm-cells: number of cells used to specify PWM which is fixed to 2 on
SPEAr. The first cell specifies the per-chip index of the PWM to use and
the second cell is the period in nanoseconds.
Example:
pwm: pwm@a8000000 {
compatible ="st,spear320-pwm";
reg = <0xa8000000 0x1000>;
#pwm-cells = <2>;
};

17
Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt Normal file
View File

@ -0,0 +1,17 @@
Texas Instruments TWL series PWM drivers
Supported PWMs:
On TWL4030 series: PWM1 and PWM2
On TWL6030 series: PWM0 and PWM1
Required properties:
- compatible: "ti,twl4030-pwm" or "ti,twl6030-pwm"
- #pwm-cells: should be 2. The first cell specifies the per-chip index
of the PWM to use and the second cell is the period in nanoseconds.
Example:
twl_pwm: pwm {
compatible = "ti,twl6030-pwm";
#pwm-cells = <2>;
};

17
Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt Normal file
View File

@ -0,0 +1,17 @@
Texas Instruments TWL series PWM drivers connected to LED terminals
Supported PWMs:
On TWL4030 series: PWMA and PWMB (connected to LEDA and LEDB terminals)
On TWL6030 series: LED PWM (mainly used as charging indicator LED)
Required properties:
- compatible: "ti,twl4030-pwmled" or "ti,twl6030-pwmled"
- #pwm-cells: should be 2. The first cell specifies the per-chip index
of the PWM to use and the second cell is the period in nanoseconds.
Example:
twl_pwmled: pwmled {
compatible = "ti,twl6030-pwmled";
#pwm-cells = <2>;
};

17
Documentation/devicetree/bindings/pwm/vt8500-pwm.txt Normal file
View File

@ -0,0 +1,17 @@
VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
Required properties:
- compatible: should be "via,vt8500-pwm"
- reg: physical base address and length of the controller's registers
- #pwm-cells: should be 2. The first cell specifies the per-chip index
of the PWM to use and the second cell is the period in nanoseconds.
- clocks: phandle to the PWM source clock
Example:
pwm1: pwm@d8220000 {
#pwm-cells = <2>;
compatible = "via,vt8500-pwm";
reg = <0xd8220000 0x1000>;
clocks = <&clkpwm>;
};

37
Documentation/devicetree/bindings/regulator/gpio-regulator.txt Normal file
View File

@ -0,0 +1,37 @@
GPIO controlled regulators
Required properties:
- compatible : Must be "regulator-gpio".
- states : Selection of available voltages and GPIO configs.
if there are no states, then use a fixed regulator
Optional properties:
- enable-gpio : GPIO to use to enable/disable the regulator.
- gpios : GPIO group used to control voltage.
- startup-delay-us : Startup time in microseconds.
- enable-active-high : Polarity of GPIO is active high (default is low).
Any property defined as part of the core regulator binding defined in
regulator.txt can also be used.
Example:
mmciv: gpio-regulator {
compatible = "regulator-gpio";
regulator-name = "mmci-gpio-supply";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <2600000>;
regulator-boot-on;
enable-gpio = <&gpio0 23 0x4>;
gpios = <&gpio0 24 0x4
&gpio0 25 0x4>;
states = <1800000 0x3
2200000 0x2
2600000 0x1
2900000 0x0>;
startup-delay-us = <100000>;
enable-active-high;
};

40
Documentation/devicetree/bindings/regulator/max8925-regulator.txt Normal file
View File

@ -0,0 +1,40 @@
Max8925 Voltage regulators
Required nodes:
-nodes:
- SDV1 for SDV SDV1
- SDV2 for SDV SDV2
- SDV3 for SDV SDV3
- LDO1 for LDO LDO1
- LDO2 for LDO LDO2
- LDO3 for LDO LDO3
- LDO4 for LDO LDO4
- LDO5 for LDO LDO5
- LDO6 for LDO LDO6
- LDO7 for LDO LDO7
- LDO8 for LDO LDO8
- LDO9 for LDO LDO9
- LDO10 for LDO LDO10
- LDO11 for LDO LDO11
- LDO12 for LDO LDO12
- LDO13 for LDO LDO13
- LDO14 for LDO LDO14
- LDO15 for LDO LDO15
- LDO16 for LDO LDO16
- LDO17 for LDO LDO17
- LDO18 for LDO LDO18
- LDO19 for LDO LDO19
- LDO20 for LDO LDO20
Optional properties:
- Any optional property defined in bindings/regulator/regulator.txt
Example:
SDV1 {
regulator-min-microvolt = <637500>;
regulator-max-microvolt = <1425000>;
regulator-boot-on;
regulator-always-on;
};

146
Documentation/devicetree/bindings/regulator/max8997-regulator.txt Normal file
View File

@ -0,0 +1,146 @@
* Maxim MAX8997 Voltage and Current Regulator
The Maxim MAX8997 is a multi-function device which includes volatage and
current regulators, rtc, charger controller and other sub-blocks. It is
interfaced to the host controller using a i2c interface. Each sub-block is
addressed by the host system using different i2c slave address. This document
describes the bindings for 'pmic' sub-block of max8997.
Required properties:
- compatible: Should be "maxim,max8997-pmic".
- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
- max8997,pmic-buck1-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
units for buck1 when changing voltage using gpio dvs. Refer to [1] below
for additional information.
- max8997,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
units for buck2 when changing voltage using gpio dvs. Refer to [1] below
for additional information.
- max8997,pmic-buck5-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
units for buck5 when changing voltage using gpio dvs. Refer to [1] below
for additional information.
[1] If none of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
property is specified, the 'max8997,pmic-buck[1/2/5]-dvs-voltage'
property should specify atleast one voltage level (which would be a
safe operating voltage).
If either of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
property is specified, then all the eigth voltage values for the
'max8997,pmic-buck[1/2/5]-dvs-voltage' should be specified.
Optional properties:
- interrupt-parent: Specifies the phandle of the interrupt controller to which
the interrupts from max8997 are delivered to.
- interrupts: Interrupt specifiers for two interrupt sources.
- First interrupt specifier is for 'irq1' interrupt.
- Second interrupt specifier is for 'alert' interrupt.
- max8997,pmic-buck1-uses-gpio-dvs: 'buck1' can be controlled by gpio dvs.
- max8997,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
- max8997,pmic-buck5-uses-gpio-dvs: 'buck5' can be controlled by gpio dvs.
Additional properties required if either of the optional properties are used:
- max8997,pmic-ignore-gpiodvs-side-effect: When GPIO-DVS mode is used for
multiple bucks, changing the voltage value of one of the bucks may affect
that of another buck, which is the side effect of the change (set_voltage).
Use this property to ignore such side effects and change the voltage.
- max8997,pmic-buck125-default-dvs-idx: Default voltage setting selected from
the possible 8 options selectable by the dvs gpios. The value of this
property should be between 0 and 7. If not specified or if out of range, the
default value of this property is set to 0.
- max8997,pmic-buck125-dvs-gpios: GPIO specifiers for three host gpio's used
for dvs. The format of the gpio specifier depends in the gpio controller.
Regulators: The regulators of max8997 that have to be instantiated should be
included in a sub-node named 'regulators'. Regulator nodes included in this
sub-node should be of the format as listed below.
regulator_name {
standard regulator bindings here
};
The following are the names of the regulators that the max8997 pmic block
supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
as per the datasheet of max8997.
- LDOn
- valid values for n are 1 to 18 and 21
- Example: LDO0, LD01, LDO2, LDO21
- BUCKn
- valid values for n are 1 to 7.
- Example: BUCK1, BUCK2, BUCK3, BUCK7
- ENVICHG: Battery Charging Current Monitor Output. This is a fixed
voltage type regulator
- ESAFEOUT1: (ldo19)
- ESAFEOUT2: (ld020)
- CHARGER_CV: main battery charger voltage control
- CHARGER: main battery charger current control
- CHARGER_TOPOFF: end of charge current threshold level
The bindings inside the regulator nodes use the standard regulator bindings
which are documented elsewhere.
Example:
max8997_pmic@66 {
compatible = "maxim,max8997-pmic";
interrupt-parent = <&wakeup_eint>;
reg = <0x66>;
interrupts = <4 0>, <3 0>;
max8997,pmic-buck1-uses-gpio-dvs;
max8997,pmic-buck2-uses-gpio-dvs;
max8997,pmic-buck5-uses-gpio-dvs;
max8997,pmic-ignore-gpiodvs-side-effect;
max8997,pmic-buck125-default-dvs-idx = <0>;
max8997,pmic-buck125-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */
<&gpx0 1 1 0 0>, /* SET2 */
<&gpx0 2 1 0 0>; /* SET3 */
max8997,pmic-buck1-dvs-voltage = <1350000>, <1300000>,
<1250000>, <1200000>,
<1150000>, <1100000>,
<1000000>, <950000>;
max8997,pmic-buck2-dvs-voltage = <1100000>, <1100000>,
<1100000>, <1100000>,
<1000000>, <1000000>,
<1000000>, <1000000>;
max8997,pmic-buck5-dvs-voltage = <1200000>, <1200000>,
<1200000>, <1200000>,
<1200000>, <1200000>,
<1200000>, <1200000>;
regulators {
ldo1_reg: LDO1 {
regulator-name = "VDD_ABB_3.3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
ldo2_reg: LDO2 {
regulator-name = "VDD_ALIVE_1.1V";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
};
buck1_reg: BUCK1 {
regulator-name = "VDD_ARM_1.2V";
regulator-min-microvolt = <950000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-boot-on;
};
};
};

4
Documentation/devicetree/bindings/regulator/tps65217.txt
View File

@ -11,6 +11,9 @@ Required properties:
using the standard binding for regulators found at
Documentation/devicetree/bindings/regulator/regulator.txt.
Optional properties:
- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
The valid names for regulators are:
tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
@ -20,6 +23,7 @@ Example:
tps: tps@24 {
compatible = "ti,tps65217";
ti,pmic-shutdown-controller;
regulators {
dcdc1_reg: dcdc1 {

32
Documentation/devicetree/bindings/regulator/vexpress.txt Normal file
View File

@ -0,0 +1,32 @@
Versatile Express voltage regulators
------------------------------------
Requires node properties:
- "compatible" value: "arm,vexpress-volt"
- "arm,vexpress-sysreg,func" when controlled via vexpress-sysreg
(see Documentation/devicetree/bindings/arm/vexpress-sysreg.txt
for more details)
Required regulator properties:
- "regulator-name"
- "regulator-always-on"
Optional regulator properties:
- "regulator-min-microvolt"
- "regulator-max-microvolt"
See Documentation/devicetree/bindings/regulator/regulator.txt
for more details about the regulator properties.
When no "regulator-[min|max]-microvolt" properties are defined,
the device is treated as fixed (or rather "read-only") regulator.
Example:
volt@0 {
compatible = "arm,vexpress-volt";
arm,vexpress-sysreg,func = <2 0>;
regulator-name = "Cores";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1050000>;
regulator-always-on;
};

17
Documentation/devicetree/bindings/rtc/imxdi-rtc.txt Normal file
View File

@ -0,0 +1,17 @@
* i.MX25 Real Time Clock controller
This binding supports the following chips: i.MX25, i.MX53
Required properties:
- compatible: should be: "fsl,imx25-rtc"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: rtc alarm interrupt
Example:
rtc@80056000 {
compatible = "fsl,imx53-rtc", "fsl,imx25-rtc";
reg = <0x80056000 2000>;
interrupts = <29>;
};

17
Documentation/devicetree/bindings/rtc/rtc-omap.txt Normal file
View File

@ -0,0 +1,17 @@
TI Real Time Clock
Required properties:
- compatible: "ti,da830-rtc"
- reg: Address range of rtc register set
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
Example:
rtc@1c23000 {
compatible = "ti,da830-rtc";
reg = <0x23000 0x1000>;
interrupts = <19
19>;
interrupt-parent = <&intc>;
};

26
Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt Normal file
View File

@ -0,0 +1,26 @@
NVIDIA Tegra20 SFLASH controller.
Required properties:
- compatible : should be "nvidia,tegra20-sflash".
- reg: Should contain SFLASH registers location and length.
- interrupts: Should contain SFLASH interrupts.
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
request selector for this SFLASH controller.
Recommended properties:
- spi-max-frequency: Definition as per
Documentation/devicetree/bindings/spi/spi-bus.txt
Example:
spi@7000c380 {
compatible = "nvidia,tegra20-sflash";
reg = <0x7000c380 0x80>;
interrupts = <0 39 0x04>;
nvidia,dma-request-selector = <&apbdma 16>;
spi-max-frequency = <25000000>;
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
};

26
Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt Normal file
View File

@ -0,0 +1,26 @@
NVIDIA Tegra20/Tegra30 SLINK controller.
Required properties:
- compatible : should be "nvidia,tegra20-slink", "nvidia,tegra30-slink".
- reg: Should contain SLINK registers location and length.
- interrupts: Should contain SLINK interrupts.
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
request selector for this SLINK controller.
Recommended properties:
- spi-max-frequency: Definition as per
Documentation/devicetree/bindings/spi/spi-bus.txt
Example:
spi@7000d600 {
compatible = "nvidia,tegra20-slink";
reg = <0x7000d600 0x200>;
interrupts = <0 82 0x04>;
nvidia,dma-request-selector = <&apbdma 16>;
spi-max-frequency = <25000000>;
#address-cells = <1>;
#size-cells = <0>;
status = "disabled";
};

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

@ -6,7 +6,9 @@ Required properties:
- "ti,omap4-spi" for OMAP4+.
- ti,spi-num-cs : Number of chipselect supported by the instance.
- ti,hwmods: Name of the hwmod associated to the McSPI
- ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as
input. The default is D0 as input and
D1 as output.
Example:

22
Documentation/devicetree/bindings/spi/spi-bus.txt
View File

@ -12,6 +12,7 @@ The SPI master node requires the following properties:
- #size-cells - should be zero.
- compatible - name of SPI bus controller following generic names
recommended practice.
- cs-gpios - (optional) gpios chip select.
No other properties are required in the SPI bus node. It is assumed
that a driver for an SPI bus device will understand that it is an SPI bus.
However, the binding does not attempt to define the specific method for
@ -24,6 +25,22 @@ support describing the chip select layout.
Optional property:
- num-cs : total number of chipselects
If cs-gpios is used the number of chip select will automatically increased
with max(cs-gpios > hw cs)
So if for example the controller has 2 CS lines, and the cs-gpios
property looks like this:
cs-gpios = <&gpio1 0 0> <0> <&gpio1 1 0> <&gpio1 2 0>;
Then it should be configured so that num_chipselect = 4 with the
following mapping:
cs0 : &gpio1 0 0
cs1 : native
cs2 : &gpio1 1 0
cs3 : &gpio1 2 0
SPI slave nodes must be children of the SPI master node and can
contain the following properties.
- reg - (required) chip select address of device.
@ -36,6 +53,11 @@ contain the following properties.
shifted clock phase (CPHA) mode
- spi-cs-high - (optional) Empty property indicating device requires
chip select active high
- spi-3wire - (optional) Empty property indicating device requires
3-wire mode.
If a gpio chipselect is used for the SPI slave the gpio number will be passed
via the cs_gpio
SPI example for an MPC5200 SPI bus:
spi@f00 {

26
Documentation/devicetree/bindings/spi/spi_atmel.txt Normal file
View File

@ -0,0 +1,26 @@
Atmel SPI device
Required properties:
- compatible : should be "atmel,at91rm9200-spi".
- reg: Address and length of the register set for the device
- interrupts: Should contain spi interrupt
- cs-gpios: chipselects
Example:
spi1: spi@fffcc000 {
compatible = "atmel,at91rm9200-spi";
reg = <0xfffcc000 0x4000>;
interrupts = <13 4 5>;
#address-cells = <1>;
#size-cells = <0>;
cs-gpios = <&pioB 3 0>;
status = "okay";
mmc-slot@0 {
compatible = "mmc-spi-slot";
reg = <0>;
gpios = <&pioC 4 0>; /* CD */
spi-max-frequency = <25000000>;
};
};

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