redonkable/alistair23-linux
redonkable/alistair23-linux
1
0
Fork 0
Code Releases Activity

Linux 4.8-rc1

Browse source 
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJXp93XAAoJEHm+PkMAQRiGzZUH/RnuppC032UBAYfF8mut4OQ9
 0rY08q92u+FQ0VtJ+JhCJ7sd3/X1S6y4imqaasEl+iHGqyJvvVcGTdK5JGirLa4x
 DZk8d7SW2zIO0c6U6ccAqRg8/ZivPUcpOD/CxWgko6OF0HjOdeFx4Bi8kyLM1y/3
 Jfv1JAMknKva8AnZwLR159m7k7WEqsvAPtSYpvxZNloaSnnDiMmyvareOVwlzA28
 5MXkf4oGiS2FsV9W4s3nFriC9sAoGcVFe6OkbiwO9K2mSq/+ncEC60elS3lvrciP
 Nm41SclpGNjf40/22/kcb1hPSKPAiTkpmyLmjQ3ZtrHL0DunYBCb6SdmgYS3yPY=
 =Bn4Y
 -----END PGP SIGNATURE-----

Merge tag 'v4.8-rc1' into patchwork

Linux 4.8-rc1

* tag 'v4.8-rc1': (6093 commits)
  Linux 4.8-rc1
  block: rename bio bi_rw to bi_opf
  target: iblock_execute_sync_cache() should use bio_set_op_attrs()
  mm: make __swap_writepage() use bio_set_op_attrs()
  block/mm: make bdev_ops->rw_page() take a bool for read/write
  fs: return EPERM on immutable inode
  ramoops: use persistent_ram_free() instead of kfree() for freeing prz
  ramoops: use DT reserved-memory bindings
  NTB: ntb_hw_intel: use local variable pdev
  NTB: ntb_hw_intel: show BAR size in debugfs info
  ntb_test: Add a selftest script for the NTB subsystem
  ntb_perf: clear link_is_up flag when the link goes down.
  ntb_pingpong: Add a debugfs file to get the ping count
  ntb_tool: Add link status and files to debugfs
  ntb_tool: Postpone memory window initialization for the user
  ntb_perf: Wait for link before running test
  ntb_perf: Return results by reading the run file
  ntb_perf: Improve thread handling to increase robustness
  ntb_perf: Schedule based on time not on performance
  ntb_transport: Check the number of spads the hardware supports
  ...
This commit is contained in:
Mauro Carvalho Chehab 2016-08-08 07:30:25 -03:00
parent 69b17abf38 29b4817d40
commit b6aa392289
5551 changed files with 252537 additions and 95278 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
.cocciconfig Normal file
View file

@ -0,0 +1,3 @@
[spatch]
options = --timeout 200
options = --use-gitgrep

2
.gitignore vendored
View file

@ -37,6 +37,7 @@ modules.builtin
Module.symvers
*.dwo
*.su
*.c.[012]*.*
#
# Top-level generic files
@ -66,6 +67,7 @@ Module.symvers
#
!.gitignore
!.mailmap
!.cocciconfig
#
# Generated include files

15
.mailmap
View file

@ -92,9 +92,17 @@ Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com>
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Leonid I Ananiev <leonid.i.ananiev@intel.com>
Linas Vepstas <linas@austin.ibm.com>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
Mark Brown <broonie@sirena.org.uk>
Matthieu CASTET <castet.matthieu@free.fr>
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com> <mchehab@infradead.org> <mchehab@redhat.com> <m.chehab@samsung.com> <mchehab@osg.samsung.com> <mchehab@s-opensource.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@brturbo.com.br>
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@infradead.org>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@redhat.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <m.chehab@samsung.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@osg.samsung.com>
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@s-opensource.com>
Matt Ranostay <mranostay@gmail.com> Matthew Ranostay <mranostay@embeddedalley.com>
Matt Ranostay <mranostay@gmail.com> <matt.ranostay@intel.com>
Mayuresh Janorkar <mayur@ti.com>
@ -130,7 +138,10 @@ Santosh Shilimkar <santosh.shilimkar@oracle.org>
Sascha Hauer <s.hauer@pengutronix.de>
S.Çağlar Onur <caglar@pardus.org.tr>
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com> <shuah.khan@hp.com> <shuahkh@osg.samsung.com> <shuah.kh@samsung.com>
Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com>
Shuah Khan <shuah@kernel.org> <shuah.khan@hp.com>
Shuah Khan <shuah@kernel.org> <shuahkh@osg.samsung.com>
Shuah Khan <shuah@kernel.org> <shuah.kh@samsung.com>
Simon Kelley <simon@thekelleys.org.uk>
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
Stephen Hemminger <shemminger@osdl.org>

9
Documentation/ABI/testing/sysfs-class-pwm
View file

@ -77,3 +77,12 @@ Description:
Enable/disable the PWM signal.
0 is disabled
1 is enabled
What: /sys/class/pwm/pwmchipN/pwmX/capture
Date: June 2016
KernelVersion: 4.8
Contact: Lee Jones <lee.jones@linaro.org>
Description:
Capture information about a PWM signal. The output format is a
pair unsigned integers (period and duty cycle), separated by a
single space.

33
Documentation/DMA-API.txt
View file

@ -369,35 +369,32 @@ See also dma_map_single().
dma_addr_t
dma_map_single_attrs(struct device *dev, void *cpu_addr, size_t size,
enum dma_data_direction dir,
struct dma_attrs *attrs)
unsigned long attrs)
void
dma_unmap_single_attrs(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir,
struct dma_attrs *attrs)
unsigned long attrs)
int
dma_map_sg_attrs(struct device *dev, struct scatterlist *sgl,
int nents, enum dma_data_direction dir,
struct dma_attrs *attrs)
unsigned long attrs)
void
dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sgl,
int nents, enum dma_data_direction dir,
struct dma_attrs *attrs)
unsigned long attrs)
The four functions above are just like the counterpart functions
without the _attrs suffixes, except that they pass an optional
struct dma_attrs*.
struct dma_attrs encapsulates a set of "DMA attributes". For the
definition of struct dma_attrs see linux/dma-attrs.h.
dma_attrs.
The interpretation of DMA attributes is architecture-specific, and
each attribute should be documented in Documentation/DMA-attributes.txt.
If struct dma_attrs* is NULL, the semantics of each of these
functions is identical to those of the corresponding function
If dma_attrs are 0, the semantics of each of these functions
is identical to those of the corresponding function
without the _attrs suffix. As a result dma_map_single_attrs()
can generally replace dma_map_single(), etc.
@ -405,15 +402,15 @@ As an example of the use of the *_attrs functions, here's how
you could pass an attribute DMA_ATTR_FOO when mapping memory
for DMA:
#include <linux/dma-attrs.h>
/* DMA_ATTR_FOO should be defined in linux/dma-attrs.h and
#include <linux/dma-mapping.h>
/* DMA_ATTR_FOO should be defined in linux/dma-mapping.h and
* documented in Documentation/DMA-attributes.txt */
...
DEFINE_DMA_ATTRS(attrs);
dma_set_attr(DMA_ATTR_FOO, &attrs);
unsigned long attr;
attr |= DMA_ATTR_FOO;
....
n = dma_map_sg_attrs(dev, sg, nents, DMA_TO_DEVICE, &attr);
n = dma_map_sg_attrs(dev, sg, nents, DMA_TO_DEVICE, attr);
....
Architectures that care about DMA_ATTR_FOO would check for its
@ -422,12 +419,10 @@ routines, e.g.:
void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir,
struct dma_attrs *attrs)
unsigned long attrs)
{
....
int foo = dma_get_attr(DMA_ATTR_FOO, attrs);
....
if (foo)
if (attrs & DMA_ATTR_FOO)
/* twizzle the frobnozzle */
....

2
Documentation/DMA-attributes.txt
View file

@ -2,7 +2,7 @@
==============
This document describes the semantics of the DMA attributes that are
defined in linux/dma-attrs.h.
defined in linux/dma-mapping.h.
DMA_ATTR_WRITE_BARRIER
----------------------

25
Documentation/DocBook/Makefile
View file

@ -6,8 +6,6 @@
# To add a new book the only step required is to add the book to the
# list of DOCBOOKS.
ifeq ($(IGNORE_DOCBOOKS),)
DOCBOOKS := z8530book.xml device-drivers.xml \
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
writing_usb_driver.xml networking.xml \
@ -16,9 +14,17 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml gpu.xml w1.xml \
tracepoint.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
ifeq ($(DOCBOOKS),)
# Skip DocBook build if the user explicitly requested no DOCBOOKS.
.DEFAULT:
@echo " SKIP DocBook $@ target (DOCBOOKS=\"\" specified)."
else
###
# The build process is as follows (targets):
# (xmldocs) [by docproc]
@ -214,16 +220,7 @@ silent_gen_xml = :
-e "s/>/\\&gt;/g"; \
echo "</programlisting>") > $@
else
htmldocs:
pdfdocs:
psdocs:
xmldocs:
installmandocs:
endif # IGNORE_DOCBOOKS
endif # DOCBOOKS=""
###
# Help targets as used by the top-level makefile
@ -240,7 +237,7 @@ dochelp:
@echo ' make DOCBOOKS="s1.xml s2.xml" [target] Generate only docs s1.xml s2.xml'
@echo ' valid values for DOCBOOKS are: $(DOCBOOKS)'
@echo
@echo " make IGNORE_DOCBOOKS=1 [target] Don't generate docs from Docbook"
@echo " make DOCBOOKS=\"\" [target] Don't generate docs from Docbook"
@echo ' This is useful to generate only the ReST docs (Sphinx)'

6
Documentation/DocBook/device-drivers.tmpl
View file

@ -161,6 +161,10 @@ X!Edrivers/base/interface.c
!Iinclude/linux/fence.h
!Edrivers/dma-buf/seqno-fence.c
!Iinclude/linux/seqno-fence.h
!Edrivers/dma-buf/fence-array.c
!Iinclude/linux/fence-array.h
!Edrivers/dma-buf/reservation.c
!Iinclude/linux/reservation.h
!Edrivers/dma-buf/sync_file.c
!Iinclude/linux/sync_file.h
</sect2>
@ -484,7 +488,7 @@ X!Ilib/fonts/fonts.c
</para>
!Iinclude/linux/hsi/hsi.h
!Edrivers/hsi/hsi.c
!Edrivers/hsi/hsi_core.c
</chapter>
<chapter id="pwm">

3540
Documentation/DocBook/gpu.tmpl
View file

File diff suppressed because it is too large Load diff

4
Documentation/Makefile.sphinx
View file

@ -67,6 +67,8 @@ installmandocs:
cleandocs:
$(Q)rm -rf $(BUILDDIR)
endif # HAVE_SPHINX
dochelp:
@echo ' Linux kernel internal documentation in different formats (Sphinx):'
@echo ' htmldocs - HTML'
@ -74,5 +76,3 @@ dochelp:
@echo ' epubdocs - EPUB'
@echo ' xmldocs - XML'
@echo ' cleandocs - clean all generated files'
endif # HAVE_SPHINX

469
Documentation/PCI/MSI-HOWTO.txt
View file

@ -78,422 +78,111 @@ CONFIG_PCI_MSI option.
4.2 Using MSI
Most of the hard work is done for the driver in the PCI layer. It simply
has to request that the PCI layer set up the MSI capability for this
Most of the hard work is done for the driver in the PCI layer. The driver
simply has to request that the PCI layer set up the MSI capability for this
device.
4.2.1 pci_enable_msi
To automatically use MSI or MSI-X interrupt vectors, use the following
function:
int pci_enable_msi(struct pci_dev *dev)
int pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs,
unsigned int max_vecs, unsigned int flags);
A successful call allocates ONE interrupt to the device, regardless
of how many MSIs the device supports. The device is switched from
pin-based interrupt mode to MSI mode. The dev->irq number is changed
to a new number which represents the message signaled interrupt;
consequently, this function should be called before the driver calls
request_irq(), because an MSI is delivered via a vector that is
different from the vector of a pin-based interrupt.
which allocates up to max_vecs interrupt vectors for a PCI device. It
returns the number of vectors allocated or a negative error. If the device
has a requirements for a minimum number of vectors the driver can pass a
min_vecs argument set to this limit, and the PCI core will return -ENOSPC
if it can't meet the minimum number of vectors.
4.2.2 pci_enable_msi_range
The flags argument should normally be set to 0, but can be used to pass the
PCI_IRQ_NOMSI and PCI_IRQ_NOMSIX flag in case a device claims to support
MSI or MSI-X, but the support is broken, or to pass PCI_IRQ_NOLEGACY in
case the device does not support legacy interrupt lines.
int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
By default this function will spread the interrupts around the available
CPUs, but this feature can be disabled by passing the PCI_IRQ_NOAFFINITY
flag.
This function allows a device driver to request any number of MSI
interrupts within specified range from 'minvec' to 'maxvec'.
To get the Linux IRQ numbers passed to request_irq() and free_irq() and the
vectors, use the following function:
If this function returns a positive number it indicates the number of
MSI interrupts that have been successfully allocated. In this case
the device is switched from pin-based interrupt mode to MSI mode and
updates dev->irq to be the lowest of the new interrupts assigned to it.
The other interrupts assigned to the device are in the range dev->irq
to dev->irq + returned value - 1. Device driver can use the returned
number of successfully allocated MSI interrupts to further allocate
and initialize device resources.
int pci_irq_vector(struct pci_dev *dev, unsigned int nr);
If this function returns a negative number, it indicates an error and
the driver should not attempt to request any more MSI interrupts for
this device.
Any allocated resources should be freed before removing the device using
the following function:
This function should be called before the driver calls request_irq(),
because MSI interrupts are delivered via vectors that are different
from the vector of a pin-based interrupt.
void pci_free_irq_vectors(struct pci_dev *dev);
It is ideal if drivers can cope with a variable number of MSI interrupts;
there are many reasons why the platform may not be able to provide the
exact number that a driver asks for.
If a device supports both MSI-X and MSI capabilities, this API will use the
MSI-X facilities in preference to the MSI facilities. MSI-X supports any
number of interrupts between 1 and 2048. In contrast, MSI is restricted to
a maximum of 32 interrupts (and must be a power of two). In addition, the
MSI interrupt vectors must be allocated consecutively, so the system might
not be able to allocate as many vectors for MSI as it could for MSI-X. On
some platforms, MSI interrupts must all be targeted at the same set of CPUs
whereas MSI-X interrupts can all be targeted at different CPUs.
There could be devices that can not operate with just any number of MSI
interrupts within a range. See chapter 4.3.1.3 to get the idea how to
handle such devices for MSI-X - the same logic applies to MSI.
If a device supports neither MSI-X or MSI it will fall back to a single
legacy IRQ vector.
4.2.1.1 Maximum possible number of MSI interrupts
The typical usage of MSI or MSI-X interrupts is to allocate as many vectors
as possible, likely up to the limit supported by the device. If nvec is
larger than the number supported by the device it will automatically be
capped to the supported limit, so there is no need to query the number of
vectors supported beforehand:
The typical usage of MSI interrupts is to allocate as many vectors as
possible, likely up to the limit returned by pci_msi_vec_count() function:
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
{
return pci_enable_msi_range(pdev, 1, nvec);
}
Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive,
the value of 0 would be meaningless and could result in error.
Some devices have a minimal limit on number of MSI interrupts.
In this case the function could look like this:
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
{
return pci_enable_msi_range(pdev, FOO_DRIVER_MINIMUM_NVEC, nvec);
}
4.2.1.2 Exact number of MSI interrupts
nvec = pci_alloc_irq_vectors(pdev, 1, nvec, 0);
if (nvec < 0)
goto out_err;
If a driver is unable or unwilling to deal with a variable number of MSI
interrupts it could request a particular number of interrupts by passing
that number to pci_enable_msi_range() function as both 'minvec' and 'maxvec'
parameters:
interrupts it can request a particular number of interrupts by passing that
number to pci_alloc_irq_vectors() function as both 'min_vecs' and
'max_vecs' parameters:
static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
{
return pci_enable_msi_range(pdev, nvec, nvec);
}
ret = pci_alloc_irq_vectors(pdev, nvec, nvec, 0);
if (ret < 0)
goto out_err;
Note, unlike pci_enable_msi_exact() function, which could be also used to
enable a particular number of MSI-X interrupts, pci_enable_msi_range()
returns either a negative errno or 'nvec' (not negative errno or 0 - as
pci_enable_msi_exact() does).
The most notorious example of the request type described above is enabling
the single MSI mode for a device. It could be done by passing two 1s as
'min_vecs' and 'max_vecs':
4.2.1.3 Single MSI mode
ret = pci_alloc_irq_vectors(pdev, 1, 1, 0);
if (ret < 0)
goto out_err;
The most notorious example of the request type described above is
enabling the single MSI mode for a device. It could be done by passing
two 1s as 'minvec' and 'maxvec':
Some devices might not support using legacy line interrupts, in which case
the PCI_IRQ_NOLEGACY flag can be used to fail the request if the platform
can't provide MSI or MSI-X interrupts:
static int foo_driver_enable_single_msi(struct pci_dev *pdev)
{
return pci_enable_msi_range(pdev, 1, 1);
}
nvec = pci_alloc_irq_vectors(pdev, 1, nvec, PCI_IRQ_NOLEGACY);
if (nvec < 0)
goto out_err;
Note, unlike pci_enable_msi() function, which could be also used to
enable the single MSI mode, pci_enable_msi_range() returns either a
negative errno or 1 (not negative errno or 0 - as pci_enable_msi()
does).
4.3 Legacy APIs
4.2.3 pci_enable_msi_exact
The following old APIs to enable and disable MSI or MSI-X interrupts should
not be used in new code:
int pci_enable_msi_exact(struct pci_dev *dev, int nvec)
pci_enable_msi() /* deprecated */
pci_enable_msi_range() /* deprecated */
pci_enable_msi_exact() /* deprecated */
pci_disable_msi() /* deprecated */
pci_enable_msix_range() /* deprecated */
pci_enable_msix_exact() /* deprecated */
pci_disable_msix() /* deprecated */
This variation on pci_enable_msi_range() call allows a device driver to
request exactly 'nvec' MSIs.
Additionally there are APIs to provide the number of supported MSI or MSI-X
vectors: pci_msi_vec_count() and pci_msix_vec_count(). In general these
should be avoided in favor of letting pci_alloc_irq_vectors() cap the
number of vectors. If you have a legitimate special use case for the count
of vectors we might have to revisit that decision and add a
pci_nr_irq_vectors() helper that handles MSI and MSI-X transparently.
If this function returns a negative number, it indicates an error and
the driver should not attempt to request any more MSI interrupts for
this device.
4.4 Considerations when using MSIs
By contrast with pci_enable_msi_range() function, pci_enable_msi_exact()
returns zero in case of success, which indicates MSI interrupts have been
successfully allocated.
4.2.4 pci_disable_msi
void pci_disable_msi(struct pci_dev *dev)
This function should be used to undo the effect of pci_enable_msi_range().
Calling it restores dev->irq to the pin-based interrupt number and frees
the previously allocated MSIs. The interrupts may subsequently be assigned
to another device, so drivers should not cache the value of dev->irq.
Before calling this function, a device driver must always call free_irq()
on any interrupt for which it previously called request_irq().
Failure to do so results in a BUG_ON(), leaving the device with
MSI enabled and thus leaking its vector.
4.2.4 pci_msi_vec_count
int pci_msi_vec_count(struct pci_dev *dev)
This function could be used to retrieve the number of MSI vectors the
device requested (via the Multiple Message Capable register). The MSI
specification only allows the returned value to be a power of two,
up to a maximum of 2^5 (32).
If this function returns a negative number, it indicates the device is
not capable of sending MSIs.
If this function returns a positive number, it indicates the maximum
number of MSI interrupt vectors that could be allocated.
4.3 Using MSI-X
The MSI-X capability is much more flexible than the MSI capability.
It supports up to 2048 interrupts, each of which can be controlled
independently. To support this flexibility, drivers must use an array of
`struct msix_entry':
struct msix_entry {
u16 vector; /* kernel uses to write alloc vector */
u16 entry; /* driver uses to specify entry */
};
This allows for the device to use these interrupts in a sparse fashion;
for example, it could use interrupts 3 and 1027 and yet allocate only a
two-element array. The driver is expected to fill in the 'entry' value
in each element of the array to indicate for which entries the kernel
should assign interrupts; it is invalid to fill in two entries with the
same number.
4.3.1 pci_enable_msix_range
int pci_enable_msix_range(struct pci_dev *dev, struct msix_entry *entries,
int minvec, int maxvec)
Calling this function asks the PCI subsystem to allocate any number of
MSI-X interrupts within specified range from 'minvec' to 'maxvec'.
The 'entries' argument is a pointer to an array of msix_entry structs
which should be at least 'maxvec' entries in size.
On success, the device is switched into MSI-X mode and the function
returns the number of MSI-X interrupts that have been successfully
allocated. In this case the 'vector' member in entries numbered from
0 to the returned value - 1 is populated with the interrupt number;
the driver should then call request_irq() for each 'vector' that it
decides to use. The device driver is responsible for keeping track of the
interrupts assigned to the MSI-X vectors so it can free them again later.
Device driver can use the returned number of successfully allocated MSI-X
interrupts to further allocate and initialize device resources.
If this function returns a negative number, it indicates an error and
the driver should not attempt to allocate any more MSI-X interrupts for
this device.
This function, in contrast with pci_enable_msi_range(), does not adjust
dev->irq. The device will not generate interrupts for this interrupt
number once MSI-X is enabled.
Device drivers should normally call this function once per device
during the initialization phase.
It is ideal if drivers can cope with a variable number of MSI-X interrupts;
there are many reasons why the platform may not be able to provide the
exact number that a driver asks for.
There could be devices that can not operate with just any number of MSI-X
interrupts within a range. E.g., an network adapter might need let's say
four vectors per each queue it provides. Therefore, a number of MSI-X
interrupts allocated should be a multiple of four. In this case interface
pci_enable_msix_range() can not be used alone to request MSI-X interrupts
(since it can allocate any number within the range, without any notion of
the multiple of four) and the device driver should master a custom logic
to request the required number of MSI-X interrupts.
4.3.1.1 Maximum possible number of MSI-X interrupts
The typical usage of MSI-X interrupts is to allocate as many vectors as
possible, likely up to the limit returned by pci_msix_vec_count() function:
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
{
return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
1, nvec);
}
Note the value of 'minvec' parameter is 1. As 'minvec' is inclusive,
the value of 0 would be meaningless and could result in error.
Some devices have a minimal limit on number of MSI-X interrupts.
In this case the function could look like this:
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
{
return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
FOO_DRIVER_MINIMUM_NVEC, nvec);
}
4.3.1.2 Exact number of MSI-X interrupts
If a driver is unable or unwilling to deal with a variable number of MSI-X
interrupts it could request a particular number of interrupts by passing
that number to pci_enable_msix_range() function as both 'minvec' and 'maxvec'
parameters:
static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
{
return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
nvec, nvec);
}
Note, unlike pci_enable_msix_exact() function, which could be also used to
enable a particular number of MSI-X interrupts, pci_enable_msix_range()
returns either a negative errno or 'nvec' (not negative errno or 0 - as
pci_enable_msix_exact() does).
4.3.1.3 Specific requirements to the number of MSI-X interrupts
As noted above, there could be devices that can not operate with just any
number of MSI-X interrupts within a range. E.g., let's assume a device that
is only capable sending the number of MSI-X interrupts which is a power of
two. A routine that enables MSI-X mode for such device might look like this:
/*
* Assume 'minvec' and 'maxvec' are non-zero
*/
static int foo_driver_enable_msix(struct foo_adapter *adapter,
int minvec, int maxvec)
{
int rc;
minvec = roundup_pow_of_two(minvec);
maxvec = rounddown_pow_of_two(maxvec);
if (minvec > maxvec)
return -ERANGE;
retry:
rc = pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
maxvec, maxvec);
/*
* -ENOSPC is the only error code allowed to be analyzed
*/
if (rc == -ENOSPC) {
if (maxvec == 1)
return -ENOSPC;
maxvec /= 2;
if (minvec > maxvec)
return -ENOSPC;
goto retry;
}
return rc;
}
Note how pci_enable_msix_range() return value is analyzed for a fallback -
any error code other than -ENOSPC indicates a fatal error and should not
be retried.
4.3.2 pci_enable_msix_exact
int pci_enable_msix_exact(struct pci_dev *dev,
struct msix_entry *entries, int nvec)
This variation on pci_enable_msix_range() call allows a device driver to
request exactly 'nvec' MSI-Xs.
If this function returns a negative number, it indicates an error and
the driver should not attempt to allocate any more MSI-X interrupts for
this device.
By contrast with pci_enable_msix_range() function, pci_enable_msix_exact()
returns zero in case of success, which indicates MSI-X interrupts have been
successfully allocated.
Another version of a routine that enables MSI-X mode for a device with
specific requirements described in chapter 4.3.1.3 might look like this:
/*
* Assume 'minvec' and 'maxvec' are non-zero
*/
static int foo_driver_enable_msix(struct foo_adapter *adapter,
int minvec, int maxvec)
{
int rc;
minvec = roundup_pow_of_two(minvec);
maxvec = rounddown_pow_of_two(maxvec);
if (minvec > maxvec)
return -ERANGE;
retry:
rc = pci_enable_msix_exact(adapter->pdev,
adapter->msix_entries, maxvec);
/*
* -ENOSPC is the only error code allowed to be analyzed
*/
if (rc == -ENOSPC) {
if (maxvec == 1)
return -ENOSPC;
maxvec /= 2;
if (minvec > maxvec)
return -ENOSPC;
goto retry;
} else if (rc < 0) {
return rc;
}
return maxvec;
}
4.3.3 pci_disable_msix
void pci_disable_msix(struct pci_dev *dev)
This function should be used to undo the effect of pci_enable_msix_range().
It frees the previously allocated MSI-X interrupts. The interrupts may
subsequently be assigned to another device, so drivers should not cache
the value of the 'vector' elements over a call to pci_disable_msix().
Before calling this function, a device driver must always call free_irq()
on any interrupt for which it previously called request_irq().
Failure to do so results in a BUG_ON(), leaving the device with
MSI-X enabled and thus leaking its vector.
4.3.3 The MSI-X Table
The MSI-X capability specifies a BAR and offset within that BAR for the
MSI-X Table. This address is mapped by the PCI subsystem, and should not
be accessed directly by the device driver. If the driver wishes to
mask or unmask an interrupt, it should call disable_irq() / enable_irq().
4.3.4 pci_msix_vec_count
int pci_msix_vec_count(struct pci_dev *dev)
This function could be used to retrieve number of entries in the device
MSI-X table.
If this function returns a negative number, it indicates the device is
not capable of sending MSI-Xs.
If this function returns a positive number, it indicates the maximum
number of MSI-X interrupt vectors that could be allocated.
4.4 Handling devices implementing both MSI and MSI-X capabilities
If a device implements both MSI and MSI-X capabilities, it can
run in either MSI mode or MSI-X mode, but not both simultaneously.
This is a requirement of the PCI spec, and it is enforced by the
PCI layer. Calling pci_enable_msi_range() when MSI-X is already
enabled or pci_enable_msix_range() when MSI is already enabled
results in an error. If a device driver wishes to switch between MSI
and MSI-X at runtime, it must first quiesce the device, then switch
it back to pin-interrupt mode, before calling pci_enable_msi_range()
or pci_enable_msix_range() and resuming operation. This is not expected
to be a common operation but may be useful for debugging or testing
during development.
4.5 Considerations when using MSIs
4.5.1 Choosing between MSI-X and MSI
If your device supports both MSI-X and MSI capabilities, you should use
the MSI-X facilities in preference to the MSI facilities. As mentioned
above, MSI-X supports any number of interrupts between 1 and 2048.
In contrast, MSI is restricted to a maximum of 32 interrupts (and
must be a power of two). In addition, the MSI interrupt vectors must
be allocated consecutively, so the system might not be able to allocate
as many vectors for MSI as it could for MSI-X. On some platforms, MSI
interrupts must all be targeted at the same set of CPUs whereas MSI-X
interrupts can all be targeted at different CPUs.
4.5.2 Spinlocks
4.4.1 Spinlocks
Most device drivers have a per-device spinlock which is taken in the
interrupt handler. With pin-based interrupts or a single MSI, it is not
@ -505,7 +194,7 @@ acquire the spinlock. Such deadlocks can be avoided by using
spin_lock_irqsave() or spin_lock_irq() which disable local interrupts
and acquire the lock (see Documentation/DocBook/kernel-locking).
4.6 How to tell whether MSI/MSI-X is enabled on a device
4.5 How to tell whether MSI/MSI-X is enabled on a device
Using 'lspci -v' (as root) may show some devices with "MSI", "Message
Signalled Interrupts" or "MSI-X" capabilities. Each of these capabilities

10
Documentation/arm/Atmel/README
View file

@ -91,9 +91,15 @@ the Atmel website: http://www.atmel.com.
http://www.atmel.com/Images/Atmel-11238-32-bit-Cortex-A5-Microcontroller-SAMA5D4_Datasheet.pdf
- sama5d2 family
- sama5d27
- sama5d21
- sama5d22
- sama5d23
- sama5d24
- sama5d26
- sama5d27 (device superset)
- sama5d28 (device superset + environmental monitors)
+ Datasheet
Coming soon
http://www.atmel.com/Images/Atmel-11267-32-bit-Cortex-A5-Microcontroller-SAMA5D2_Datasheet.pdf
Linux kernel information

7
Documentation/binfmt_misc.txt
View file

@ -66,6 +66,13 @@ Here is what the fields mean:
This feature should be used with care as the interpreter
will run with root permissions when a setuid binary owned by root
is run with binfmt_misc.
'F' - fix binary. The usual behaviour of binfmt_misc is to spawn the
binary lazily when the misc format file is invoked. However,
this doesn't work very well in the face of mount namespaces and
changeroots, so the F mode opens the binary as soon as the
emulation is installed and uses the opened image to spawn the
emulator, meaning it is always available once installed,
regardless of how the environment changes.
There are some restrictions:

7
Documentation/block/biodoc.txt
View file

@ -269,7 +269,7 @@ Arjan's proposed request priority scheme allows higher levels some broad
requests which haven't aged too much on the queue. Potentially this priority
could even be exposed to applications in some manner, providing higher level
tunability. Time based aging avoids starvation of lower priority
requests. Some bits in the bi_rw flags field in the bio structure are
requests. Some bits in the bi_opf flags field in the bio structure are
intended to be used for this priority information.
@ -432,7 +432,7 @@ struct bio {
struct bio *bi_next; /* request queue link */
struct block_device *bi_bdev; /* target device */
unsigned long bi_flags; /* status, command, etc */
unsigned long bi_rw; /* low bits: r/w, high: priority */
unsigned long bi_opf; /* low bits: r/w, high: priority */
unsigned int bi_vcnt; /* how may bio_vec's */
struct bvec_iter bi_iter; /* current index into bio_vec array */
@ -1024,8 +1024,7 @@ could be on demand. For example wait_on_buffer sets the unplugging going
through sync_buffer() running blk_run_address_space(mapping). Or the caller
can do it explicity through blk_unplug(bdev). So in the read case,
the queue gets explicitly unplugged as part of waiting for completion on that
buffer. For page driven IO, the address space ->sync_page() takes care of
doing the blk_run_address_space().
buffer.
Aside:
This is kind of controversial territory, as it's not clear if plugging is

4
Documentation/cgroup-v1/cgroups.txt
View file

@ -2,7 +2,7 @@
-------
Written by Paul Menage <menage@google.com> based on
Documentation/cgroups/cpusets.txt
Documentation/cgroup-v1/cpusets.txt
Original copyright statements from cpusets.txt:
Portions Copyright (C) 2004 BULL SA.
@ -72,7 +72,7 @@ On their own, the only use for cgroups is for simple job
tracking. The intention is that other subsystems hook into the generic
cgroup support to provide new attributes for cgroups, such as
accounting/limiting the resources which processes in a cgroup can
access. For example, cpusets (see Documentation/cgroups/cpusets.txt) allow
access. For example, cpusets (see Documentation/cgroup-v1/cpusets.txt) allow
you to associate a set of CPUs and a set of memory nodes with the
tasks in each cgroup.

2
Documentation/cgroup-v1/cpusets.txt
View file

@ -48,7 +48,7 @@ hooks, beyond what is already present, required to manage dynamic
job placement on large systems.
Cpusets use the generic cgroup subsystem described in
Documentation/cgroups/cgroups.txt.
Documentation/cgroup-v1/cgroups.txt.
Requests by a task, using the sched_setaffinity(2) system call to
include CPUs in its CPU affinity mask, and using the mbind(2) and

8
Documentation/cgroup-v1/memcg_test.txt
View file

@ -6,7 +6,7 @@ Because VM is getting complex (one of reasons is memcg...), memcg's behavior
is complex. This is a document for memcg's internal behavior.
Please note that implementation details can be changed.
(*) Topics on API should be in Documentation/cgroups/memory.txt)
(*) Topics on API should be in Documentation/cgroup-v1/memory.txt)
0. How to record usage ?
2 objects are used.
@ -107,9 +107,9 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
8. LRU
Each memcg has its own private LRU. Now, its handling is under global
VM's control (means that it's handled under global zone->lru_lock).
VM's control (means that it's handled under global zone_lru_lock).
Almost all routines around memcg's LRU is called by global LRU's
list management functions under zone->lru_lock().
list management functions under zone_lru_lock().
A special function is mem_cgroup_isolate_pages(). This scans
memcg's private LRU and call __isolate_lru_page() to extract a page
@ -256,7 +256,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
You can see charges have been moved by reading *.usage_in_bytes or
memory.stat of both A and B.
See 8.2 of Documentation/cgroups/memory.txt to see what value should be
See 8.2 of Documentation/cgroup-v1/memory.txt to see what value should be
written to move_charge_at_immigrate.
9.10 Memory thresholds

4
Documentation/cgroup-v1/memory.txt
View file

@ -267,11 +267,11 @@ When oom event notifier is registered, event will be delivered.
Other lock order is following:
PG_locked.
mm->page_table_lock
zone->lru_lock
zone_lru_lock
lock_page_cgroup.
In many cases, just lock_page_cgroup() is called.
per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
zone->lru_lock, it has no lock of its own.
zone_lru_lock, it has no lock of its own.
2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM)

148
Documentation/coccinelle.txt
View file

@ -38,6 +38,15 @@ as a regular user, and install it with
sudo make install
Supplemental documentation
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For supplemental documentation refer to the wiki:
https://bottest.wiki.kernel.org/coccicheck
The wiki documentation always refers to the linux-next version of the script.
Using Coccinelle on the Linux kernel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -94,11 +103,26 @@ To enable verbose messages set the V= variable, for example:
make coccicheck MODE=report V=1
Coccinelle parallelization
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
By default, coccicheck tries to run as parallel as possible. To change
the parallelism, set the J= variable. For example, to run across 4 CPUs:
make coccicheck MODE=report J=4
As of Coccinelle 1.0.2 Coccinelle uses Ocaml parmap for parallelization,
if support for this is detected you will benefit from parmap parallelization.
When parmap is enabled coccicheck will enable dynamic load balancing by using
'--chunksize 1' argument, this ensures we keep feeding threads with work
one by one, so that we avoid the situation where most work gets done by only
a few threads. With dynamic load balancing, if a thread finishes early we keep
feeding it more work.
When parmap is enabled, if an error occurs in Coccinelle, this error
value is propagated back, the return value of the 'make coccicheck'
captures this return value.
Using Coccinelle with a single semantic patch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -142,15 +166,118 @@ semantic patch as shown in the previous section.
The "report" mode is the default. You can select another one with the
MODE variable explained above.
Debugging Coccinelle SmPL patches
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using coccicheck is best as it provides in the spatch command line
include options matching the options used when we compile the kernel.
You can learn what these options are by using V=1, you could then
manually run Coccinelle with debug options added.
Alternatively you can debug running Coccinelle against SmPL patches
by asking for stderr to be redirected to stderr, by default stderr
is redirected to /dev/null, if you'd like to capture stderr you
can specify the DEBUG_FILE="file.txt" option to coccicheck. For
instance:
rm -f cocci.err
make coccicheck COCCI=scripts/coccinelle/free/kfree.cocci MODE=report DEBUG_FILE=cocci.err
cat cocci.err
You can use SPFLAGS to add debugging flags, for instance you may want to
add both --profile --show-trying to SPFLAGS when debugging. For instance
you may want to use:
rm -f err.log
export COCCI=scripts/coccinelle/misc/irqf_oneshot.cocci
make coccicheck DEBUG_FILE="err.log" MODE=report SPFLAGS="--profile --show-trying" M=./drivers/mfd/arizona-irq.c
err.log will now have the profiling information, while stdout will
provide some progress information as Coccinelle moves forward with
work.
DEBUG_FILE support is only supported when using coccinelle >= 1.2.
.cocciconfig support
~~~~~~~~~~~~~~~~~~~~~~
Coccinelle supports reading .cocciconfig for default Coccinelle options that
should be used every time spatch is spawned, the order of precedence for
variables for .cocciconfig is as follows:
o Your current user's home directory is processed first
o Your directory from which spatch is called is processed next
o The directory provided with the --dir option is processed last, if used
Since coccicheck runs through make, it naturally runs from the kernel
proper dir, as such the second rule above would be implied for picking up a
.cocciconfig when using 'make coccicheck'.
'make coccicheck' also supports using M= targets.If you do not supply
any M= target, it is assumed you want to target the entire kernel.
The kernel coccicheck script has:
if [ "$KBUILD_EXTMOD" = "" ] ; then
OPTIONS="--dir $srctree $COCCIINCLUDE"
else
OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE"
fi
KBUILD_EXTMOD is set when an explicit target with M= is used. For both cases
the spatch --dir argument is used, as such third rule applies when whether M=
is used or not, and when M= is used the target directory can have its own
.cocciconfig file. When M= is not passed as an argument to coccicheck the
target directory is the same as the directory from where spatch was called.
If not using the kernel's coccicheck target, keep the above precedence
order logic of .cocciconfig reading. If using the kernel's coccicheck target,
override any of the kernel's .coccicheck's settings using SPFLAGS.
We help Coccinelle when used against Linux with a set of sensible defaults
options for Linux with our own Linux .cocciconfig. This hints to coccinelle
git can be used for 'git grep' queries over coccigrep. A timeout of 200
seconds should suffice for now.
The options picked up by coccinelle when reading a .cocciconfig do not appear
as arguments to spatch processes running on your system, to confirm what
options will be used by Coccinelle run:
spatch --print-options-only
You can override with your own preferred index option by using SPFLAGS. Take
note that when there are conflicting options Coccinelle takes precedence for
the last options passed. Using .cocciconfig is possible to use idutils, however
given the order of precedence followed by Coccinelle, since the kernel now
carries its own .cocciconfig, you will need to use SPFLAGS to use idutils if
desired. See below section "Additional flags" for more details on how to use
idutils.
Additional flags
~~~~~~~~~~~~~~~~~~
Additional flags can be passed to spatch through the SPFLAGS
variable.
variable. This works as Coccinelle respects the last flags
given to it when options are in conflict.
make SPFLAGS=--use-glimpse coccicheck
Coccinelle supports idutils as well but requires coccinelle >= 1.0.6.
When no ID file is specified coccinelle assumes your ID database file
is in the file .id-utils.index on the top level of the kernel, coccinelle
carries a script scripts/idutils_index.sh which creates the database with
mkid -i C --output .id-utils.index
If you have another database filename you can also just symlink with this
name.
make SPFLAGS=--use-idutils coccicheck
Alternatively you can specify the database filename explicitly, for
instance:
make SPFLAGS="--use-idutils /full-path/to/ID" coccicheck
See spatch --help to learn more about spatch options.
Note that the '--use-glimpse' and '--use-idutils' options
@ -159,6 +286,25 @@ thus active by default. However, by indexing the code with
one of these tools, and according to the cocci file used,
spatch could proceed the entire code base more quickly.
SmPL patch specific options
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SmPL patches can have their own requirements for options passed
to Coccinelle. SmPL patch specific options can be provided by
providing them at the top of the SmPL patch, for instance:
// Options: --no-includes --include-headers
SmPL patch Coccinelle requirements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As Coccinelle features get added some more advanced SmPL patches
may require newer versions of Coccinelle. If an SmPL patch requires
at least a version of Coccinelle, this can be specified as follows,
as an example if requiring at least Coccinelle >= 1.0.5:
// Requires: 1.0.5
Proposing new semantic patches
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2
Documentation/device-mapper/dm-flakey.txt
View file

@ -42,7 +42,7 @@ Optional feature parameters:
<direction>: Either 'r' to corrupt reads or 'w' to corrupt writes.
'w' is incompatible with drop_writes.
<value>: The value (from 0-255) to write.
<flags>: Perform the replacement only if bio->bi_rw has all the
<flags>: Perform the replacement only if bio->bi_opf has all the
selected flags set.
Examples:

34
Documentation/devicetree/bindings/arm/arm,scpi.txt
View file

@ -87,10 +87,33 @@ Required properties:
implementation for the IDs to use. For Juno
R0 and Juno R1 refer to [3].
Power domain bindings for the power domains based on SCPI Message Protocol
------------------------------------------------------------
This binding uses the generic power domain binding[4].
PM domain providers
===================
Required properties:
- #power-domain-cells : Should be 1. Contains the device or the power
domain ID value used by SCPI commands.
- num-domains: Total number of power domains provided by SCPI. This is
needed as the SCPI message protocol lacks a mechanism to
query this information at runtime.
PM domain consumers
===================
Required properties:
- power-domains : A phandle and PM domain specifier as defined by bindings of
the power controller specified by phandle.
[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/thermal/thermal.txt
[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
[4] Documentation/devicetree/bindings/power/power_domain.txt
Example:
@ -144,6 +167,12 @@ scpi_protocol: scpi@2e000000 {
compatible = "arm,scpi-sensors";
#thermal-sensor-cells = <1>;
};
scpi_devpd: scpi-power-domains {
compatible = "arm,scpi-power-domains";
num-domains = <2>;
#power-domain-cells = <1>;
};
};
cpu@0 {
@ -156,6 +185,7 @@ hdlcd@7ff60000 {
...
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scpi_clk 4>;
power-domains = <&scpi_devpd 1>;
};
thermal-zones {
@ -186,3 +216,7 @@ The thermal-sensors property in the soc_thermal node uses the
temperature sensor provided by SCP firmware to setup a thermal
zone. The ID "3" is the sensor identifier for the temperature sensor
as used by the firmware.
The num-domains property in scpi-power-domains domain specifies that
SCPI provides 2 power domains. The hdlcd node uses the power domain with
domain ID 1.

6
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method.txt
View file

@ -5,7 +5,7 @@ CPUs in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664
The enable method is specified by defining the following required
properties in the "cpus" device tree node:
properties in the "cpu" device tree node:
- enable-method = "brcm,bcm11351-cpu-method";
- secondary-boot-reg = <...>;
@ -19,8 +19,6 @@ Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
enable-method = "brcm,bcm11351-cpu-method";
secondary-boot-reg = <0x3500417c>;
cpu0: cpu@0 {
device_type = "cpu";
@ -32,5 +30,7 @@ Example:
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
enable-method = "brcm,bcm11351-cpu-method";
secondary-boot-reg = <0x3500417c>;
};
};

36
Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550-cpu-method.txt Normal file
View file

@ -0,0 +1,36 @@
Broadcom Kona Family CPU Enable Method
--------------------------------------
This binding defines the enable method used for starting secondary
CPUs in the following Broadcom SoCs:
BCM23550
The enable method is specified by defining the following required
properties in the "cpu" device tree node:
- enable-method = "brcm,bcm23550";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
enable-method = "brcm,bcm23550";
secondary-boot-reg = <0x3500417c>;
};
};

15
Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.txt Normal file
View file

@ -0,0 +1,15 @@
Broadcom BCM23550 device tree bindings
--------------------------------------
This document describes the device tree bindings for boards with the BCM23550
SoC.
Required root node property:
- compatible: brcm,bcm23550
Example:
/ {
model = "BCM23550 SoC";
compatible = "brcm,bcm23550";
[...]
}

4
Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt
View file

@ -30,6 +30,10 @@ Raspberry Pi 2 Model B
Required root node properties:
compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
Raspberry Pi 3 Model B
Required root node properties:
compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
Raspberry Pi Compute Module
Required root node properties:
compatible = "raspberrypi,compute-module", "brcm,bcm2835";

35
Documentation/devicetree/bindings/arm/coresight.txt
View file

@ -12,14 +12,33 @@ its hardware characteristcs.
* compatible: These have to be supplemented with "arm,primecell" as
drivers are using the AMBA bus interface. Possible values include:
- "arm,coresight-etb10", "arm,primecell";
- "arm,coresight-tpiu", "arm,primecell";
- "arm,coresight-tmc", "arm,primecell";
- "arm,coresight-funnel", "arm,primecell";
- "arm,coresight-etm3x", "arm,primecell";
- "arm,coresight-etm4x", "arm,primecell";
- "qcom,coresight-replicator1x", "arm,primecell";
- "arm,coresight-stm", "arm,primecell"; [1]
- Embedded Trace Buffer (version 1.0):
"arm,coresight-etb10", "arm,primecell";
- Trace Port Interface Unit:
"arm,coresight-tpiu", "arm,primecell";
- Trace Memory Controller, used for Embedded Trace Buffer(ETB),
Embedded Trace FIFO(ETF) and Embedded Trace Router(ETR)
configuration. The configuration mode (ETB, ETF, ETR) is
discovered at boot time when the device is probed.
"arm,coresight-tmc", "arm,primecell";
- Trace Funnel:
"arm,coresight-funnel", "arm,primecell";
- Embedded Trace Macrocell (version 3.x) and
Program Flow Trace Macrocell:
"arm,coresight-etm3x", "arm,primecell";
- Embedded Trace Macrocell (version 4.x):
"arm,coresight-etm4x", "arm,primecell";
- Qualcomm Configurable Replicator (version 1.x):
"qcom,coresight-replicator1x", "arm,primecell";
- System Trace Macrocell:
"arm,coresight-stm", "arm,primecell"; [1]
* reg: physical base address and length of the register
set(s) of the component.

3
Documentation/devicetree/bindings/arm/cpus.txt
View file

@ -193,6 +193,8 @@ nodes to be present and contain the properties described below.
"allwinner,sun6i-a31"
"allwinner,sun8i-a23"
"arm,realview-smp"
"brcm,bcm11351-cpu-method"
"brcm,bcm23550"
"brcm,bcm-nsp-smp"
"brcm,brahma-b15"
"marvell,armada-375-smp"
@ -204,6 +206,7 @@ nodes to be present and contain the properties described below.
"qcom,gcc-msm8660"
"qcom,kpss-acc-v1"
"qcom,kpss-acc-v2"
"renesas,apmu"
"rockchip,rk3036-smp"
"rockchip,rk3066-smp"
"ste,dbx500-smp"

14
Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt Normal file
View file

@ -0,0 +1,14 @@
* Hisilicon Hi3519 System Controller Block
This bindings use the following binding:
Documentation/devicetree/bindings/mfd/syscon.txt
Required properties:
- compatible: "hisilicon,hi3519-sysctrl".
- reg: the register region of this block
Examples:
sysctrl: system-controller@12010000 {
compatible = "hisilicon,hi3519-sysctrl", "syscon";
reg = <0x12010000 0x1000>;
};

4
Documentation/devicetree/bindings/arm/l2c2x0.txt
View file

@ -86,10 +86,10 @@ Optional properties:
firmware)
- arm,dynamic-clock-gating : L2 dynamic clock gating. Value: <0> (forcibly
disable), <1> (forcibly enable), property absent (OS specific behavior,
preferrably retain firmware settings)
preferably retain firmware settings)
- arm,standby-mode: L2 standby mode enable. Value <0> (forcibly disable),
<1> (forcibly enable), property absent (OS specific behavior,
preferrably retain firmware settings)
preferably retain firmware settings)
Example:

4
Documentation/devicetree/bindings/arm/mediatek.txt
View file

@ -10,6 +10,7 @@ compatible: Must contain one of
"mediatek,mt6580"
"mediatek,mt6589"
"mediatek,mt6592"
"mediatek,mt6755"
"mediatek,mt6795"
"mediatek,mt7623"
"mediatek,mt8127"
@ -31,6 +32,9 @@ Supported boards:
- Evaluation board for MT6592:
Required root node properties:
- compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
- Evaluation phone for MT6755(Helio P10):
Required root node properties:
- compatible = "mediatek,mt6755-evb", "mediatek,mt6755";
- Evaluation board for MT6795(Helio X10):
Required root node properties:
- compatible = "mediatek,mt6795-evb", "mediatek,mt6795";

8
Documentation/devicetree/bindings/arm/olimex.txt
View file

@ -1,5 +1,9 @@
Olimex i.MX Platforms Device Tree Bindings
------------------------------------------
Olimex Device Tree Bindings
---------------------------
SAM9-L9260 Board
Required root node properties:
- compatible = "olimex,sam9-l9260", "atmel,at91sam9260";
i.MX23 Olinuxino Low Cost Board
Required root node properties:

3
Documentation/devicetree/bindings/arm/rockchip.txt
View file

@ -107,6 +107,9 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
- Rockchip RK3229 Evaluation board:
- compatible = "rockchip,rk3229-evb", "rockchip,rk3229";
- Rockchip RK3399 evb:
Required root node properties:
- compatible = "rockchip,rk3399-evb", "rockchip,rk3399";

1
Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
View file

@ -47,6 +47,7 @@ Required root node properties:
- "hardkernel,odroid-u3" - for Exynos4412-based Hardkernel Odroid U3.
- "hardkernel,odroid-x" - for Exynos4412-based Hardkernel Odroid X.
- "hardkernel,odroid-x2" - for Exynos4412-based Hardkernel Odroid X2.
- "hardkernel,odroid-xu" - for Exynos5410-based Hardkernel Odroid XU.
- "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3.
- "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel
Odroid XU3 Lite board.

6
Documentation/devicetree/bindings/arm/shmobile.txt
View file

@ -29,6 +29,8 @@ SoCs:
compatible = "renesas,r8a7794"
- R-Car H3 (R8A77950)
compatible = "renesas,r8a7795"
- R-Car M3-W (R8A77960)
compatible = "renesas,r8a7796"
Boards:
@ -39,6 +41,8 @@ Boards:
compatible = "renesas,ape6evm", "renesas,r8a73a4"
- Atmark Techno Armadillo-800 EVA
compatible = "renesas,armadillo800eva"
- Blanche (RTP0RC7792SEB00010S)
compatible = "renesas,blanche", "renesas,r8a7792"
- BOCK-W
compatible = "renesas,bockw", "renesas,r8a7778"
- Genmai (RTK772100BC00000BR)
@ -61,5 +65,7 @@ Boards:
compatible = "renesas,porter", "renesas,r8a7791"
- Salvator-X (RTP0RC7795SIPB0010S)
compatible = "renesas,salvator-x", "renesas,r8a7795";
- Salvator-X
compatible = "renesas,salvator-x", "renesas,r8a7796";
- SILK (RTP0RC7794LCB00011S)
compatible = "renesas,silk", "renesas,r8a7794"

4
Documentation/devicetree/bindings/arm/tegra.txt
View file

@ -32,7 +32,11 @@ board-specific compatible values:
nvidia,whistler
toradex,apalis_t30
toradex,apalis_t30-eval
toradex,apalis-tk1
toradex,apalis-tk1-eval
toradex,colibri_t20-512
toradex,colibri_t30
toradex,colibri_t30-eval-v3
toradex,iris
Trusted Foundations

1
Documentation/devicetree/bindings/ata/ahci-platform.txt
View file

@ -10,6 +10,7 @@ PHYs.
Required properties:
- compatible : compatible string, one of:
- "allwinner,sun4i-a10-ahci"
- "brcm,iproc-ahci"
- "hisilicon,hisi-ahci"
- "cavium,octeon-7130-ahci"
- "ibm,476gtr-ahci"

45
Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.txt Normal file
View file

@ -0,0 +1,45 @@
NVIDIA Tegra ACONNECT Bus
The Tegra ACONNECT bus is an AXI switch which is used to connnect various
components inside the Audio Processing Engine (APE). All CPU accesses to
the APE subsystem go through the ACONNECT via an APB to AXI wrapper.
Required properties:
- compatible: Must be "nvidia,tegra210-aconnect".
- clocks: Must contain the entries for the APE clock (TEGRA210_CLK_APE),
and APE interface clock (TEGRA210_CLK_APB2APE).
- clock-names: Must contain the names "ape" and "apb2ape" for the corresponding
'clocks' entries.
- power-domains: Must contain a phandle that points to the audio powergate
(namely 'aud') for Tegra210.
- #address-cells: The number of cells used to represent physical base addresses
in the aconnect address space. Should be 1.
- #size-cells: The number of cells used to represent the size of an address
range in the aconnect address space. Should be 1.
- ranges: Mapping of the aconnect address space to the CPU address space.
All devices accessed via the ACONNNECT are described by child-nodes.
Example:
aconnect@702c0000 {
compatible = "nvidia,tegra210-aconnect";
clocks = <&tegra_car TEGRA210_CLK_APE>,
<&tegra_car TEGRA210_CLK_APB2APE>;
clock-names = "ape", "apb2ape";
power-domains = <&pd_audio>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x702c0000 0x0 0x702c0000 0x00040000>;
status = "disabled";
child1 {
...
};
child2 {
...
};
};

36
Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt Normal file
View file

@ -0,0 +1,36 @@
* Amlogic GXBB Clock and Reset Unit
The Amlogic GXBB clock controller generates and supplies clock to various
controllers within the SoC.
Required Properties:
- compatible: should be "amlogic,gxbb-clkc"
- reg: physical base address of the clock controller and length of memory
mapped region.
- #clock-cells: should be 1.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/gxbb-clkc.h header and can be
used in device tree sources.
Example: Clock controller node:
clkc: clock-controller@c883c000 {
#clock-cells = <1>;
compatible = "amlogic,gxbb-clkc";
reg = <0x0 0xc883c000 0x0 0x3db>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart_AO: serial@c81004c0 {
compatible = "amlogic,meson-uart";
reg = <0xc81004c0 0x14>;
interrupts = <0 90 1>;
clocks = <&clkc CLKID_CLK81>;
status = "disabled";
};

4
Documentation/devicetree/bindings/clock/clps711x-clock.txt
View file

@ -1,7 +1,7 @@
* Clock bindings for the Cirrus Logic CLPS711X CPUs
Required properties:
- compatible : Shall contain "cirrus,clps711x-clk".
- compatible : Shall contain "cirrus,ep7209-clk".
- reg : Address of the internal register set.
- startup-frequency: Factory set CPU startup frequency in HZ.
- #clock-cells : Should be <1>.
@ -13,7 +13,7 @@ for the full list of CLPS711X clock IDs.
Example:
clks: clks@80000000 {
#clock-cells = <1>;
compatible = "cirrus,ep7312-clk", "cirrus,clps711x-clk";
compatible = "cirrus,ep7312-clk", "cirrus,ep7209-clk";
reg = <0x80000000 0xc000>;
startup-frequency = <73728000>;
};

4
Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
View file

@ -14,6 +14,10 @@ Required properties:
Optional properties:
- clock-output-names : From common clock binding.
Some clocks that require special treatments are also handled by that
driver, with the compatibles:
- allwinner,sun4i-a10-pll3-2x-clk
Example:
clock {
compatible = "fixed-factor-clock";

7
Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
View file

@ -13,7 +13,8 @@ They provide the following functionalities:
Required Properties:
- compatible: Must be one of:
- "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC
- "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3)
- "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W)
- reg: Base address and length of the memory resource used by the CPG/MSSR
block
@ -21,8 +22,8 @@ Required Properties:
- clocks: References to external parent clocks, one entry for each entry in
clock-names
- clock-names: List of external parent clock names. Valid names are:
- "extal" (r8a7795)
- "extalr" (r8a7795)
- "extal" (r8a7795, r8a7796)
- "extalr" (r8a7795, r8a7796)
- #clock-cells: Must be 2
- For CPG core clocks, the two clock specifier cells must be "CPG_CORE"

1
Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
View file

@ -17,6 +17,7 @@ Required Properties:
- "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) MSTP gate clocks
- "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks
- "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2-W) MSTP gate clocks
- "renesas,r8a7792-mstp-clocks" for R8A7792 (R-Car V2H) MSTP gate clocks
- "renesas,r8a7793-mstp-clocks" for R8A7793 (R-Car M2-N) MSTP gate clocks
- "renesas,r8a7794-mstp-clocks" for R8A7794 (R-Car E2) MSTP gate clocks
- "renesas,sh73a0-mstp-clocks" for SH73A0 (SH-MobileAG5) MSTP gate clocks

1
Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
View file

@ -10,6 +10,7 @@ Required Properties:
- compatible: Must be one of
- "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
- "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG
- "renesas,r8a7792-cpg-clocks" for the r8a7792 CPG
- "renesas,r8a7793-cpg-clocks" for the r8a7793 CPG
- "renesas,r8a7794-cpg-clocks" for the r8a7794 CPG
and "renesas,rcar-gen2-cpg-clocks" as a fallback.

24
Documentation/devicetree/bindings/clock/sunxi-ccu.txt Normal file
View file

@ -0,0 +1,24 @@
Allwinner Clock Control Unit Binding
------------------------------------
Required properties :
- compatible: must contain one of the following compatible:
- "allwinner,sun8i-h3-ccu"
- reg: Must contain the registers base address and length
- clocks: phandle to the oscillators feeding the CCU. Two are needed:
- "hosc": the high frequency oscillator (usually at 24MHz)
- "losc": the low frequency oscillator (usually at 32kHz)
- clock-names: Must contain the clock names described just above
- #clock-cells : must contain 1
- #reset-cells : must contain 1
Example:
ccu: clock@01c20000 {
compatible = "allwinner,sun8i-h3-ccu";
reg = <0x01c20000 0x400>;
clocks = <&osc24M>, <&osc32k>;
clock-names = "hosc", "losc";
#clock-cells = <1>;
#reset-cells = <1>;
};

65
Documentation/devicetree/bindings/display/arm,malidp.txt Normal file
View file

@ -0,0 +1,65 @@
ARM Mali-DP
The following bindings apply to a family of Display Processors sold as
licensable IP by ARM Ltd. The bindings describe the Mali DP500, DP550 and
DP650 processors that offer multiple composition layers, support for
rotation and scaling output.
Required properties:
- compatible: should be one of
"arm,mali-dp500"
"arm,mali-dp550"
"arm,mali-dp650"
depending on the particular implementation present in the hardware
- reg: Physical base address and size of the block of registers used by
the processor.
- interrupts: Interrupt list, as defined in ../interrupt-controller/interrupts.txt,
interrupt client nodes.
- interrupt-names: name of the engine inside the processor that will
use the corresponding interrupt. Should be one of "DE" or "SE".
- clocks: A list of phandle + clock-specifier pairs, one for each entry
in 'clock-names'
- clock-names: A list of clock names. It should contain:
- "pclk": for the APB interface clock
- "aclk": for the AXI interface clock
- "mclk": for the main processor clock
- "pxlclk": for the pixel clock feeding the output PLL of the processor.
- arm,malidp-output-port-lines: Array of u8 values describing the number
of output lines per channel (R, G and B).
Required sub-nodes:
- port: The Mali DP connection to an encoder input port. The connection
is modelled using the OF graph bindings specified in
Documentation/devicetree/bindings/graph.txt
Optional properties:
- memory-region: phandle to a node describing memory (see
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
to be used for the framebuffer; if not present, the framebuffer may
be located anywhere in memory.
Example:
/ {
...
dp0: malidp@6f200000 {
compatible = "arm,mali-dp650";
reg = <0 0x6f200000 0 0x20000>;
memory-region = <&display_reserved>;
interrupts = <0 168 IRQ_TYPE_LEVEL_HIGH>,
<0 168 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "DE", "SE";
clocks = <&oscclk2>, <&fpgaosc0>, <&fpgaosc1>, <&fpgaosc1>;
clock-names = "pxlclk", "mclk", "aclk", "pclk";
arm,malidp-output-port-lines = /bits/ 8 <8 8 8>;
port {
dp0_output: endpoint {
remote-endpoint = <&tda998x_2_input>;
};
};
};
...
};

26
Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
View file

@ -1,13 +1,19 @@
Analog Device ADV7511(W)/13 HDMI Encoders
Analog Device ADV7511(W)/13/33 HDMI Encoders
-----------------------------------------
The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters
The ADV7511, ADV7511W, ADV7513 and ADV7533 are HDMI audio and video transmitters
compatible with HDMI 1.4 and DVI 1.0. They support color space conversion,
S/PDIF, CEC and HDCP.
S/PDIF, CEC and HDCP. ADV7533 supports the DSI interface for input pixels, while
the others support RGB interface.
Required properties:
- compatible: Should be one of "adi,adv7511", "adi,adv7511w" or "adi,adv7513"
- compatible: Should be one of:
"adi,adv7511"
"adi,adv7511w"
"adi,adv7513"
"adi,adv7533"
- reg: I2C slave address
The ADV7511 supports a large number of input data formats that differ by their
@ -32,6 +38,11 @@ The following input format properties are required except in "rgb 1x" and
- adi,input-justification: The input bit justification ("left", "evenly",
"right").
The following properties are required for ADV7533:
- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
be one of 1, 2, 3 or 4.
Optional properties:
- interrupts: Specifier for the ADV7511 interrupt
@ -42,13 +53,18 @@ Optional properties:
- adi,embedded-sync: The input uses synchronization signals embedded in the
data stream (similar to BT.656). Defaults to separate H/V synchronization
signals.
- adi,disable-timing-generator: Only for ADV7533. Disables the internal timing
generator. The chip will rely on the sync signals in the DSI data lanes,
rather than generate its own timings for HDMI output.
Required nodes:
The ADV7511 has two video ports. Their connections are modelled using the OF
graph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 for the RGB or YUV input
- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533, the
remote endpoint phandle should be a reference to a valid mipi_dsi_host device
node.
- Video port 1 for the HDMI output

1
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
View file

@ -5,6 +5,7 @@ Required properties for dp-controller:
platform specific such as:
* "samsung,exynos5-dp"
* "rockchip,rk3288-dp"
* "rockchip,rk3399-edp"
-reg:
physical base address of the controller and length
of memory mapped region.

35
Documentation/devicetree/bindings/display/bridge/sii902x.txt Normal file
View file

@ -0,0 +1,35 @@
sii902x HDMI bridge bindings
Required properties:
- compatible: "sil,sii9022"
- reg: i2c address of the bridge
Optional properties:
- interrupts-extended or interrupt-parent + interrupts: describe
the interrupt line used to inform the host about hotplug events.
- reset-gpios: OF device-tree gpio specification for RST_N pin.
Optional subnodes:
- video input: this subnode can contain a video input port node
to connect the bridge to a display controller output (See this
documentation [1]).
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
hdmi-bridge@39 {
compatible = "sil,sii9022";
reg = <0x39>;
reset-gpios = <&pioA 1 0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
bridge_in: endpoint {
remote-endpoint = <&dc_out>;
};
};
};
};

53
Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt Normal file
View file

@ -0,0 +1,53 @@
Toshiba TC358767 eDP bridge bindings
Required properties:
- compatible: "toshiba,tc358767"
- reg: i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins
- clock-names: should be "ref"
- clocks: OF device-tree clock specification for refclk input. The reference
clock rate must be 13 MHz, 19.2 MHz, 26 MHz, or 38.4 MHz.
Optional properties:
- shutdown-gpios: OF device-tree gpio specification for SD pin
(active high shutdown input)
- reset-gpios: OF device-tree gpio specification for RSTX pin
(active low system reset)
- ports: the ports node can contain video interface port nodes to connect
to a DPI/DSI source and to an eDP/DP sink according to [1][2]:
- port@0: DSI input port
- port@1: DPI input port
- port@2: eDP/DP output port
[1]: Documentation/devicetree/bindings/graph.txt
[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
edp-bridge@68 {
compatible = "toshiba,tc358767";
reg = <0x68>;
shutdown-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>;
clock-names = "ref";
clocks = <&edp_refclk>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@1 {
reg = <1>;
bridge_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
port@2 {
reg = <2>;
bridge_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};
};

4
Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt
View file

@ -1,7 +1,7 @@
* Currus Logic CLPS711X Framebuffer
Required properties:
- compatible: Shall contain "cirrus,clps711x-fb".
- compatible: Shall contain "cirrus,ep7209-fb".
- reg : Physical base address and length of the controller's registers +
location and size of the framebuffer memory.
- clocks : phandle + clock specifier pair of the FB reference clock.
@ -18,7 +18,7 @@ Optional properties:
Example:
fb: fb@800002c0 {
compatible = "cirrus,ep7312-fb", "cirrus,clps711x-fb";
compatible = "cirrus,ep7312-fb", "cirrus,ep7209-fb";
reg = <0x800002c0 0xd44>, <0x60000000 0xc000>;
clocks = <&clks 2>;
lcd-supply = <&reg5v0>;

1
Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
View file

@ -8,6 +8,7 @@ Required properties:
Optional properties:
- label: a symbolic name for the connector
- hpd-gpios: HPD GPIO number
- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing
Required nodes:
- Video port for HDMI input

9
Documentation/devicetree/bindings/display/fsl,dcu.txt
View file

@ -12,7 +12,7 @@ Required properties:
- clock-names: Should be "dcu" and "pix"
See ../clocks/clock-bindings.txt for details.
- big-endian Boolean property, LS1021A DCU registers are big-endian.
- fsl,panel: The phandle to panel node.
- port Video port for the panel output
Optional properties:
- fsl,tcon: The phandle to the timing controller node.
@ -24,6 +24,11 @@ dcu: dcu@2ce0000 {
clocks = <&platform_clk 0>, <&platform_clk 0>;
clock-names = "dcu", "pix";
big-endian;
fsl,panel = <&panel>;
fsl,tcon = <&tcon>;
port {
dcu_out: endpoint {
remote-endpoint = <&panel_out>;
};
};
};

148
Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt Normal file
View file

@ -0,0 +1,148 @@
Mediatek HDMI Encoder
=====================
The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
its parallel input.
Required properties:
- compatible: Should be "mediatek,<chip>-hdmi".
- reg: Physical base address and length of the controller's registers
- interrupts: The interrupt signal from the function block.
- clocks: device clocks
See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
- clock-names: must contain "pixel", "pll", "bclk", and "spdif".
- phys: phandle link to the HDMI PHY node.
See Documentation/devicetree/bindings/phy/phy-bindings.txt for details.
- phy-names: must contain "hdmi"
- mediatek,syscon-hdmi: phandle link and register offset to the system
configuration registers. For mt8173 this must be offset 0x900 into the
MMSYS_CONFIG region: <&mmsys 0x900>.
- ports: A node containing input and output port nodes with endpoint
definitions as documented in Documentation/devicetree/bindings/graph.txt.
- port@0: The input port in the ports node should be connected to a DPI output
port.
- port@1: The output port in the ports node should be connected to the input
port of a connector node that contains a ddc-i2c-bus property, or to the
input port of an attached bridge chip, such as a SlimPort transmitter.
HDMI CEC
========
The HDMI CEC controller handles hotplug detection and CEC communication.
Required properties:
- compatible: Should be "mediatek,<chip>-cec"
- reg: Physical base address and length of the controller's registers
- interrupts: The interrupt signal from the function block.
- clocks: device clock
HDMI DDC
========
The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
The Mediatek's I2C controller is used to interface with I2C devices.
Required properties:
- compatible: Should be "mediatek,<chip>-hdmi-ddc"
- reg: Physical base address and length of the controller's registers
- clocks: device clock
- clock-names: Should be "ddc-i2c".
HDMI PHY
========
The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
output and drives the HDMI pads.
Required properties:
- compatible: "mediatek,<chip>-hdmi-phy"
- reg: Physical base address and length of the module's registers
- clocks: PLL reference clock
- clock-names: must contain "pll_ref"
- clock-output-names: must be "hdmitx_dig_cts" on mt8173
- #phy-cells: must be <0>
- #clock-cells: must be <0>
Optional properties:
- mediatek,ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
- mediatek,ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
Example:
cec: cec@10013000 {
compatible = "mediatek,mt8173-cec";
reg = <0 0x10013000 0 0xbc>;
interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>;
clocks = <&infracfg CLK_INFRA_CEC>;
};
hdmi_phy: hdmi-phy@10209100 {
compatible = "mediatek,mt8173-hdmi-phy";
reg = <0 0x10209100 0 0x24>;
clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
clock-names = "pll_ref";
clock-output-names = "hdmitx_dig_cts";
mediatek,ibias = <0xa>;
mediatek,ibias_up = <0x1c>;
#clock-cells = <0>;
#phy-cells = <0>;
};
hdmi_ddc0: i2c@11012000 {
compatible = "mediatek,mt8173-hdmi-ddc";
reg = <0 0x11012000 0 0x1c>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>;
clocks = <&pericfg CLK_PERI_I2C5>;
clock-names = "ddc-i2c";
};
hdmi0: hdmi@14025000 {
compatible = "mediatek,mt8173-hdmi";
reg = <0 0x14025000 0 0x400>;
interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_LOW>;
clocks = <&mmsys CLK_MM_HDMI_PIXEL>,
<&mmsys CLK_MM_HDMI_PLLCK>,
<&mmsys CLK_MM_HDMI_AUDIO>,
<&mmsys CLK_MM_HDMI_SPDIF>;
clock-names = "pixel", "pll", "bclk", "spdif";
pinctrl-names = "default";
pinctrl-0 = <&hdmi_pin>;
phys = <&hdmi_phy>;
phy-names = "hdmi";
mediatek,syscon-hdmi = <&mmsys 0x900>;
assigned-clocks = <&topckgen CLK_TOP_HDMI_SEL>;
assigned-clock-parents = <&hdmi_phy>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
hdmi0_in: endpoint {
remote-endpoint = <&dpi0_out>;
};
};
port@1 {
reg = <1>;
hdmi0_out: endpoint {
remote-endpoint = <&hdmi_con_in>;
};
};
};
};
connector {
compatible = "hdmi-connector";
type = "a";
ddc-i2c-bus = <&hdmiddc0>;
port {
hdmi_con_in: endpoint {
remote-endpoint = <&hdmi0_out>;
};
};
};

117
Documentation/devicetree/bindings/display/msm/dsi.txt
View file

@ -11,8 +11,7 @@ Required properties:
be 0 or 1, since we have 2 DSI controllers at most for now.
- interrupts: The interrupt signal from the DSI block.
- power-domains: Should be <&mmcc MDSS_GDSC>.
- clocks: device clocks
See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
- clocks: Phandles to device clocks.
- clock-names: the following clocks are required:
* "mdp_core_clk"
* "iface_clk"
@ -23,16 +22,21 @@ Required properties:
* "core_clk"
For DSIv2, we need an additional clock:
* "src_clk"
- assigned-clocks: Parents of "byte_clk" and "pixel_clk" for the given platform.
- assigned-clock-parents: The Byte clock and Pixel clock PLL outputs provided
by a DSI PHY block. See [1] for details on clock bindings.
- vdd-supply: phandle to vdd regulator device node
- vddio-supply: phandle to vdd-io regulator device node
- vdda-supply: phandle to vdda regulator device node
- qcom,dsi-phy: phandle to DSI PHY device node
- phys: phandle to DSI PHY device node
- phy-names: the name of the corresponding PHY device
- syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2)
- ports: Contains 2 DSI controller ports as child nodes. Each port contains
an endpoint subnode as defined in [2] and [3].
Optional properties:
- panel@0: Node of panel connected to this DSI controller.
See files in Documentation/devicetree/bindings/display/panel/ for each supported
panel.
See files in [4] for each supported panel.
- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
driving a panel which needs 2 DSI links.
- qcom,master-dsi: Boolean value indicating if the DSI controller is driving
@ -44,34 +48,38 @@ Optional properties:
- pinctrl-names: the pin control state names; should contain "default"
- pinctrl-0: the default pinctrl state (active)
- pinctrl-n: the "sleep" pinctrl state
- port: DSI controller output port, containing one endpoint subnode.
- ports: contains DSI controller input and output ports as children, each
containing one endpoint subnode.
DSI Endpoint properties:
- remote-endpoint: set to phandle of the connected panel's endpoint.
See Documentation/devicetree/bindings/graph.txt for device graph info.
- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
to the physical lanes on the given platform. The value contained in
index n describes what logical data lane is mapped to the physical data
lane n (DATAn, where n lies between 0 and 3).
- remote-endpoint: For port@0, set to phandle of the connected panel/bridge's
input endpoint. For port@1, set to the MDP interface output. See [2] for
device graph info.
- data-lanes: this describes how the physical DSI data lanes are mapped
to the logical lanes on the given platform. The value contained in
index n describes what physical lane is mapped to the logical lane n
(DATAn, where n lies between 0 and 3). The clock lane position is fixed
and can't be changed. Hence, they aren't a part of the DT bindings. See
[3] for more info on the data-lanes property.
For example:
qcom,data-lane-map = <3 0 1 2>;
data-lanes = <3 0 1 2>;
The above mapping describes that the logical data lane DATA3 is mapped to
the physical data lane DATA0, logical DATA0 to physical DATA1, logic DATA1
to phys DATA2 and logic DATA2 to phys DATA3.
The above mapping describes that the logical data lane DATA0 is mapped to
the physical data lane DATA3, logical DATA1 to physical DATA0, logic DATA2
to phys DATA1 and logic DATA3 to phys DATA2.
There are only a limited number of physical to logical mappings possible:
"0123": Logic 0->Phys 0; Logic 1->Phys 1; Logic 2->Phys 2; Logic 3->Phys 3;
"3012": Logic 3->Phys 0; Logic 0->Phys 1; Logic 1->Phys 2; Logic 2->Phys 3;
"2301": Logic 2->Phys 0; Logic 3->Phys 1; Logic 0->Phys 2; Logic 1->Phys 3;
"1230": Logic 1->Phys 0; Logic 2->Phys 1; Logic 3->Phys 2; Logic 0->Phys 3;
"0321": Logic 0->Phys 0; Logic 3->Phys 1; Logic 2->Phys 2; Logic 1->Phys 3;
"1032": Logic 1->Phys 0; Logic 0->Phys 1; Logic 3->Phys 2; Logic 2->Phys 3;
"2103": Logic 2->Phys 0; Logic 1->Phys 1; Logic 0->Phys 2; Logic 3->Phys 3;
"3210": Logic 3->Phys 0; Logic 2->Phys 1; Logic 1->Phys 2; Logic 0->Phys 3;
<0 1 2 3>
<1 2 3 0>
<2 3 0 1>
<3 0 1 2>
<0 3 2 1>
<1 0 3 2>
<2 1 0 3>
<3 2 1 0>
DSI PHY:
Required properties:
@ -86,11 +94,12 @@ Required properties:
* "dsi_pll"
* "dsi_phy"
* "dsi_phy_regulator"
- clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating
2 clocks: A byte clock (index 0), and a pixel clock (index 1).
- qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should
be 0 or 1, since we have 2 DSI PHYs at most for now.
- power-domains: Should be <&mmcc MDSS_GDSC>.
- clocks: device clocks
See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
- clocks: Phandles to device clocks. See [1] for details on clock bindings.
- clock-names: the following clocks are required:
* "iface_clk"
- vddio-supply: phandle to vdd-io regulator device node
@ -99,11 +108,16 @@ Optional properties:
- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
regulator is wanted.
[1] Documentation/devicetree/bindings/clocks/clock-bindings.txt
[2] Documentation/devicetree/bindings/graph.txt
[3] Documentation/devicetree/bindings/media/video-interfaces.txt
[4] Documentation/devicetree/bindings/display/panel/
Example:
mdss_dsi0: qcom,mdss_dsi@fd922800 {
dsi0: dsi@fd922800 {
compatible = "qcom,mdss-dsi-ctrl";
qcom,dsi-host-index = <0>;
interrupt-parent = <&mdss_mdp>;
interrupt-parent = <&mdp>;
interrupts = <4 0>;
reg-names = "dsi_ctrl";
reg = <0xfd922800 0x200>;
@ -124,19 +138,48 @@ Example:
<&mmcc MDSS_AHB_CLK>,
<&mmcc MDSS_MDP_CLK>,
<&mmcc MDSS_PCLK0_CLK>;
assigned-clocks =
<&mmcc BYTE0_CLK_SRC>,
<&mmcc PCLK0_CLK_SRC>;
assigned-clock-parents =
<&dsi_phy0 0>,
<&dsi_phy0 1>;
vdda-supply = <&pma8084_l2>;
vdd-supply = <&pma8084_l22>;
vddio-supply = <&pma8084_l12>;
qcom,dsi-phy = <&mdss_dsi_phy0>;
phys = <&dsi_phy0>;
phy-names ="dsi-phy";
qcom,dual-dsi-mode;
qcom,master-dsi;
qcom,sync-dual-dsi;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&mdss_dsi_active>;
pinctrl-1 = <&mdss_dsi_suspend>;
pinctrl-0 = <&dsi_active>;
pinctrl-1 = <&dsi_suspend>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dsi0_in: endpoint {
remote-endpoint = <&mdp_intf1_out>;
};
};
port@1 {
reg = <1>;
dsi0_out: endpoint {
remote-endpoint = <&panel_in>;
data-lanes = <0 1 2 3>;
};
};
};
panel: panel@0 {
compatible = "sharp,lq101r1sx01";
@ -152,16 +195,9 @@ Example:
};
};
};
port {
dsi0_out: endpoint {
remote-endpoint = <&panel_in>;
lanes = <0 1 2 3>;
};
};
};
mdss_dsi_phy0: qcom,mdss_dsi_phy@fd922a00 {
dsi_phy0: dsi-phy@fd922a00 {
compatible = "qcom,dsi-phy-28nm-hpm";
qcom,dsi-phy-index = <0>;
reg-names =
@ -173,6 +209,7 @@ Example:
<0xfd922d80 0x7b>;
clock-names = "iface_clk";
clocks = <&mmcc MDSS_AHB_CLK>;
#clock-cells = <1>;
vddio-supply = <&pma8084_l12>;
qcom,dsi-phy-regulator-ldo-mode;

59
Documentation/devicetree/bindings/display/msm/mdp.txt
View file

@ -1,59 +0,0 @@
Qualcomm adreno/snapdragon display controller
Required properties:
- compatible:
* "qcom,mdp4" - mdp4
* "qcom,mdp5" - mdp5
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt signal from the display controller.
- connectors: array of phandles for output device(s)
- clocks: device clocks
See ../clocks/clock-bindings.txt for details.
- clock-names: the following clocks are required.
For MDP4:
* "core_clk"
* "iface_clk"
* "lut_clk"
* "src_clk"
* "hdmi_clk"
* "mdp_clk"
For MDP5:
* "bus_clk"
* "iface_clk"
* "core_clk_src"
* "core_clk"
* "lut_clk" (some MDP5 versions may not need this)
* "vsync_clk"
Optional properties:
- gpus: phandle for gpu device
- clock-names: the following clocks are optional:
* "lut_clk"
Example:
/ {
...
mdp: qcom,mdp@5100000 {
compatible = "qcom,mdp4";
reg = <0x05100000 0xf0000>;
interrupts = <GIC_SPI 75 0>;
connectors = <&hdmi>;
gpus = <&gpu>;
clock-names =
"core_clk",
"iface_clk",
"lut_clk",
"src_clk",
"hdmi_clk",
"mdp_clk";
clocks =
<&mmcc MDP_SRC>,
<&mmcc MDP_AHB_CLK>,
<&mmcc MDP_LUT_CLK>,
<&mmcc TV_SRC>,
<&mmcc HDMI_TV_CLK>,
<&mmcc MDP_TV_CLK>;
};
};

112
Documentation/devicetree/bindings/display/msm/mdp4.txt Normal file
View file

@ -0,0 +1,112 @@
Qualcomm adreno/snapdragon MDP4 display controller
Description:
This is the bindings documentation for the MDP4 display controller found in
SoCs like MSM8960, APQ8064 and MSM8660.
Required properties:
- compatible:
* "qcom,mdp4" - mdp4
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt signal from the display controller.
- clocks: device clocks
See ../clocks/clock-bindings.txt for details.
- clock-names: the following clocks are required.
* "core_clk"
* "iface_clk"
* "bus_clk"
* "lut_clk"
* "hdmi_clk"
* "tv_clk"
- ports: contains the list of output ports from MDP. These connect to interfaces
that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a
special case since it is a part of the MDP block itself).
Each output port contains an endpoint that describes how it is connected to an
external interface. These are described by the standard properties documented
here:
Documentation/devicetree/bindings/graph.txt
Documentation/devicetree/bindings/media/video-interfaces.txt
The output port mappings are:
Port 0 -> LCDC/LVDS
Port 1 -> DSI1 Cmd/Video
Port 2 -> DSI2 Cmd/Video
Port 3 -> DTV
Optional properties:
- clock-names: the following clocks are optional:
* "lut_clk"
Example:
/ {
...
hdmi: hdmi@4a00000 {
...
ports {
...
port@0 {
reg = <0>;
hdmi_in: endpoint {
remote-endpoint = <&mdp_dtv_out>;
};
};
...
};
...
};
...
mdp: mdp@5100000 {
compatible = "qcom,mdp4";
reg = <0x05100000 0xf0000>;
interrupts = <GIC_SPI 75 0>;
clock-names =
"core_clk",
"iface_clk",
"lut_clk",
"hdmi_clk",
"tv_clk";
clocks =
<&mmcc MDP_CLK>,
<&mmcc MDP_AHB_CLK>,
<&mmcc MDP_AXI_CLK>,
<&mmcc MDP_LUT_CLK>,
<&mmcc HDMI_TV_CLK>,
<&mmcc MDP_TV_CLK>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
mdp_lvds_out: endpoint {
};
};
port@1 {
reg = <1>;
mdp_dsi1_out: endpoint {
};
};
port@2 {
reg = <2>;
mdp_dsi2_out: endpoint {
};
};
port@3 {
reg = <3>;
mdp_dtv_out: endpoint {
remote-endpoint = <&hdmi_in>;
};
};
};
};
};

160
Documentation/devicetree/bindings/display/msm/mdp5.txt Normal file
View file

@ -0,0 +1,160 @@
Qualcomm adreno/snapdragon MDP5 display controller
Description:
This is the bindings documentation for the Mobile Display Subsytem(MDSS) that
encapsulates sub-blocks like MDP5, DSI, HDMI, eDP etc, and the MDP5 display
controller found in SoCs like MSM8974, APQ8084, MSM8916, MSM8994 and MSM8996.
MDSS:
Required properties:
- compatible:
* "qcom,mdss" - MDSS
- reg: Physical base address and length of the controller's registers.
- reg-names: The names of register regions. The following regions are required:
* "mdss_phys"
* "vbif_phys"
- interrupts: The interrupt signal from MDSS.
- interrupt-controller: identifies the node as an interrupt controller.
- #interrupt-cells: specifies the number of cells needed to encode an interrupt
source, should be 1.
- power-domains: a power domain consumer specifier according to
Documentation/devicetree/bindings/power/power_domain.txt
- clocks: device clocks. See ../clocks/clock-bindings.txt for details.
- clock-names: the following clocks are required.
* "iface_clk"
* "bus_clk"
* "vsync_clk"
- #address-cells: number of address cells for the MDSS children. Should be 1.
- #size-cells: Should be 1.
- ranges: parent bus address space is the same as the child bus address space.
Optional properties:
- clock-names: the following clocks are optional:
* "lut_clk"
MDP5:
Required properties:
- compatible:
* "qcom,mdp5" - MDP5
- reg: Physical base address and length of the controller's registers.
- reg-names: The names of register regions. The following regions are required:
* "mdp_phys"
- interrupts: Interrupt line from MDP5 to MDSS interrupt controller.
- interrupt-parent: phandle to the MDSS block
through MDP block
- clocks: device clocks. See ../clocks/clock-bindings.txt for details.
- clock-names: the following clocks are required.
- * "bus_clk"
- * "iface_clk"
- * "core_clk"
- * "vsync_clk"
- ports: contains the list of output ports from MDP. These connect to interfaces
that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a
special case since it is a part of the MDP block itself).
Each output port contains an endpoint that describes how it is connected to an
external interface. These are described by the standard properties documented
here:
Documentation/devicetree/bindings/graph.txt
Documentation/devicetree/bindings/media/video-interfaces.txt
The availability of output ports can vary across SoC revisions:
For MSM8974 and APQ8084:
Port 0 -> MDP_INTF0 (eDP)
Port 1 -> MDP_INTF1 (DSI1)
Port 2 -> MDP_INTF2 (DSI2)
Port 3 -> MDP_INTF3 (HDMI)
For MSM8916:
Port 0 -> MDP_INTF1 (DSI1)
For MSM8994 and MSM8996:
Port 0 -> MDP_INTF1 (DSI1)
Port 1 -> MDP_INTF2 (DSI2)
Port 2 -> MDP_INTF3 (HDMI)
Optional properties:
- clock-names: the following clocks are optional:
* "lut_clk"
Example:
/ {
...
mdss: mdss@1a00000 {
compatible = "qcom,mdss";
reg = <0x1a00000 0x1000>,
<0x1ac8000 0x3000>;
reg-names = "mdss_phys", "vbif_phys";
power-domains = <&gcc MDSS_GDSC>;
clocks = <&gcc GCC_MDSS_AHB_CLK>,
<&gcc GCC_MDSS_AXI_CLK>,
<&gcc GCC_MDSS_VSYNC_CLK>;
clock-names = "iface_clk",
"bus_clk",
"vsync_clk"
interrupts = <0 72 0>;
interrupt-controller;
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
mdp: mdp@1a01000 {
compatible = "qcom,mdp5";
reg = <0x1a01000 0x90000>;
reg-names = "mdp_phys";
interrupt-parent = <&mdss>;
interrupts = <0 0>;
clocks = <&gcc GCC_MDSS_AHB_CLK>,
<&gcc GCC_MDSS_AXI_CLK>,
<&gcc GCC_MDSS_MDP_CLK>,
<&gcc GCC_MDSS_VSYNC_CLK>;
clock-names = "iface_clk",
"bus_clk",
"core_clk",
"vsync_clk";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
mdp5_intf1_out: endpoint {
remote-endpoint = <&dsi0_in>;
};
};
};
};
dsi0: dsi@1a98000 {
...
ports {
...
port@0 {
reg = <0>;
dsi0_in: endpoint {
remote-endpoint = <&mdp5_intf1_out>;
};
};
...
};
...
};
dsi_phy0: dsi-phy@1a98300 {
...
};
};
};

7
Documentation/devicetree/bindings/display/panel/lg,lp079qx1-sp0v.txt Normal file
View file

@ -0,0 +1,7 @@
LG LP079QX1-SP0V 7.9" (1536x2048 pixels) TFT LCD panel
Required properties:
- compatible: should be "lg,lp079qx1-sp0v"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
Documentation/devicetree/bindings/display/panel/lg,lp097qx1-spa1.txt Normal file
View file

@ -0,0 +1,7 @@
LG 9.7" (2048x1536 pixels) TFT LCD panel
Required properties:
- compatible: should be "lg,lp097qx1-spa1"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

2
Documentation/devicetree/bindings/display/panel/panel-dpi.txt
View file

@ -7,6 +7,8 @@ Required properties:
Optional properties:
- label: a symbolic name for the panel
- enable-gpios: panel enable gpio
- reset-gpios: GPIO to control the RESET pin
- vcc-supply: phandle of regulator that will be used to enable power to the display
Required nodes:
- "panel-timing" containing video timings

7
Documentation/devicetree/bindings/display/panel/samsung,lsn122dl01-c01.txt Normal file
View file

@ -0,0 +1,7 @@
Samsung 12.2" (2560x1600 pixels) TFT LCD panel
Required properties:
- compatible: should be "samsung,lsn122dl01-c01"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
Documentation/devicetree/bindings/display/panel/sharp,lq101k1ly04.txt Normal file
View file

@ -0,0 +1,7 @@
Sharp Display Corp. LQ101K1LY04 10.07" WXGA TFT LCD panel
Required properties:
- compatible: should be "sharp,lq101k1ly04"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
Documentation/devicetree/bindings/display/panel/sharp,lq123p1jx31.txt Normal file
View file

@ -0,0 +1,7 @@
Sharp 12.3" (2400x1600 pixels) TFT LCD panel
Required properties:
- compatible: should be "sharp,lq123p1jx31"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
Documentation/devicetree/bindings/display/panel/starry,kr122ea0sra.txt Normal file
View file

@ -0,0 +1,7 @@
Starry 12.2" (1920x1200 pixels) TFT LCD panel
Required properties:
- compatible: should be "starry,kr122ea0sra"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

9
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
View file

@ -2,7 +2,8 @@ Rockchip RK3288 specific extensions to the Analogix Display Port
================================
Required properties:
- compatible: "rockchip,rk3288-edp";
- compatible: "rockchip,rk3288-dp",
"rockchip,rk3399-edp";
- reg: physical base address of the controller and length
@ -27,6 +28,12 @@ Required properties:
Port 0: contained 2 endpoints, connecting to the output of vop.
Port 1: contained 1 endpoint, connecting to the input of panel.
Optional property for different chips:
- clocks: from common clock binding: handle to grf_vio clock.
- clock-names: from common clock binding:
Required elements: "grf"
For the below properties, please refer to Analogix DP binding document:
* Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
- phys (required)

13
Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
View file

@ -208,6 +208,7 @@ of the following host1x client modules:
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- sor: clock input for the SOR hardware
- source: source clock for the SOR clock
- parent: input for the pixel clock
- dp: reference clock for the SOR clock
- safe: safe reference for the SOR clock during power up
@ -226,9 +227,9 @@ of the following host1x client modules:
- nvidia,dpaux: phandle to a DispayPort AUX interface
- dpaux: DisplayPort AUX interface
- compatible: For Tegra124, must contain "nvidia,tegra124-dpaux". Otherwise,
must contain '"nvidia,<chip>-dpaux", "nvidia,tegra124-dpaux"', where
<chip> is tegra132.
- compatible : Should contain one of the following:
- "nvidia,tegra124-dpaux": for Tegra124 and Tegra132
- "nvidia,tegra210-dpaux": for Tegra210
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain an entry for each entry in clock-names.
@ -241,6 +242,12 @@ of the following host1x client modules:
- reset-names: Must include the following entries:
- dpaux
- vdd-supply: phandle of a supply that powers the DisplayPort link
- i2c-bus: Subnode where I2C slave devices are listed. This subnode
must be always present. If there are no I2C slave devices, an empty
node should be added. See ../../i2c/i2c.txt for more information.
See ../pinctrl/nvidia,tegra124-dpaux-padctl.txt for information
regarding the DPAUX pad controller bindings.
Example:

24
Documentation/devicetree/bindings/dma/mv-xor-v2.txt Normal file
View file

@ -0,0 +1,24 @@
* Marvell XOR v2 engines
Required properties:
- compatible: one of the following values:
"marvell,armada-7k-xor"
"marvell,xor-v2"
- reg: Should contain registers location and length (two sets)
the first set is the DMA registers
the second set is the global registers
- msi-parent: Phandle to the MSI-capable interrupt controller used for
interrupts.
Optional properties:
- clocks: Optional reference to the clock used by the XOR engine.
Example:
xor0@400000 {
compatible = "marvell,xor-v2";
reg = <0x400000 0x1000>,
<0x410000 0x1000>;
msi-parent = <&gic_v2m0>;
dma-coherent;
};

4
Documentation/devicetree/bindings/dma/ti-edma.txt
View file

@ -15,7 +15,7 @@ Required properties:
- reg: Memory map of eDMA CC
- reg-names: "edma3_cc"
- interrupts: Interrupt lines for CCINT, MPERR and CCERRINT.
- interrupt-names: "edma3_ccint", "emda3_mperr" and "edma3_ccerrint"
- interrupt-names: "edma3_ccint", "edma3_mperr" and "edma3_ccerrint"
- ti,tptcs: List of TPTCs associated with the eDMA in the following form:
<&tptc_phandle TC_priority_number>. The highest priority is 0.
@ -48,7 +48,7 @@ edma: edma@49000000 {
reg = <0x49000000 0x10000>;
reg-names = "edma3_cc";
interrupts = <12 13 14>;
interrupt-names = "edma3_ccint", "emda3_mperr", "edma3_ccerrint";
interrupt-names = "edma3_ccint", "edma3_mperr", "edma3_ccerrint";
dma-requests = <64>;
#dma-cells = <2>;

94
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
View file

@ -1,46 +1,96 @@
Xilinx AXI VDMA engine, it does transfers between memory and video devices.
It can be configured to have one channel or two channels. If configured
as two channels, one is to transmit to the video device and another is
to receive from the video device.
Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
target devices. It can be configured to have one channel or two channels.
If configured as two channels, one is to transmit to the device and another
is to receive from the device.
Xilinx AXI CDMA engine, it does transfers between memory-mapped source
address and a memory-mapped destination address.
Required properties:
- compatible: Should be "xlnx,axi-dma-1.00.a"
- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a" or
"xlnx,axi-cdma-1.00.a""
- #dma-cells: Should be <1>, see "dmas" property below
- reg: Should contain DMA registers location and length.
- reg: Should contain VDMA registers location and length.
- xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits).
- dma-ranges: Should be as the following <dma_addr cpu_addr max_len>.
- dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
- clocks: Input clock specifier. Refer to common clock bindings.
- clock-names: List of input clocks
For VDMA:
Required elements: "s_axi_lite_aclk"
Optional elements: "m_axi_mm2s_aclk" "m_axi_s2mm_aclk",
"m_axis_mm2s_aclk", "s_axis_s2mm_aclk"
For CDMA:
Required elements: "s_axi_lite_aclk", "m_axi_aclk"
FOR AXIDMA:
Required elements: "s_axi_lite_aclk"
Optional elements: "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
"m_axi_sg_aclk"
Required properties for VDMA:
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
Optional properties:
- xlnx,include-sg: Tells whether configured for Scatter-mode in
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
Optional properties for AXI DMA:
- xlnx,mcdma: Tells whether configured for multi-channel mode in the hardware.
Optional properties for VDMA:
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:
{1}, flush both channels
{2}, flush mm2s channel
{3}, flush s2mm channel
Required child node properties:
- compatible: It should be either "xlnx,axi-dma-mm2s-channel" or
- compatible:
For VDMA: It should be either "xlnx,axi-vdma-mm2s-channel" or
"xlnx,axi-vdma-s2mm-channel".
For CDMA: It should be "xlnx,axi-cdma-channel".
For AXIDMA: It should be either "xlnx,axi-dma-mm2s-channel" or
"xlnx,axi-dma-s2mm-channel".
- interrupts: Should contain per channel DMA interrupts.
- interrupts: Should contain per channel VDMA interrupts.
- xlnx,datawidth: Should contain the stream data width, take values
{32,64...1024}.
Option child node properties:
- xlnx,include-dre: Tells whether hardware is configured for Data
Optional child node properties:
- xlnx,include-dre: Tells hardware is configured for Data
Realignment Engine.
Optional child node properties for VDMA:
- xlnx,genlock-mode: Tells Genlock synchronization is
enabled/disabled in hardware.
Optional child node properties for AXI DMA:
-dma-channels: Number of dma channels in child node.
Example:
++++++++
axi_dma_0: axidma@40400000 {
compatible = "xlnx,axi-dma-1.00.a";
axi_vdma_0: axivdma@40030000 {
compatible = "xlnx,axi-vdma-1.00.a";
#dma_cells = <1>;
reg = < 0x40400000 0x10000 >;
dma-channel@40400000 {
compatible = "xlnx,axi-dma-mm2s-channel";
interrupts = < 0 59 4 >;
reg = < 0x40030000 0x10000 >;
dma-ranges = <0x00000000 0x00000000 0x40000000>;
xlnx,num-fstores = <0x8>;
xlnx,flush-fsync = <0x1>;
xlnx,addrwidth = <0x20>;
clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>, <&clk 4>;
clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
"m_axis_mm2s_aclk", "s_axis_s2mm_aclk";
dma-channel@40030000 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;
xlnx,datawidth = <0x40>;
} ;
dma-channel@40400030 {
compatible = "xlnx,axi-dma-s2mm-channel";
interrupts = < 0 58 4 >;
dma-channel@40030030 {
compatible = "xlnx,axi-vdma-s2mm-channel";
interrupts = < 0 53 4 >;
xlnx,datawidth = <0x40>;
} ;
} ;
@ -49,7 +99,7 @@ axi_dma_0: axidma@40400000 {
* DMA client
Required properties:
- dmas: a list of <[DMA device phandle] [Channel ID]> pairs,
- dmas: a list of <[Video DMA device phandle] [Channel ID]> pairs,
where Channel ID is '0' for write/tx and '1' for read/rx
channel.
- dma-names: a list of DMA channel names, one per "dmas" entry
@ -57,9 +107,9 @@ Required properties:
Example:
++++++++
dmatest_0: dmatest@0 {
compatible ="xlnx,axi-dma-test-1.00.a";
dmas = <&axi_dma_0 0
&axi_dma_0 1>;
dma-names = "dma0", "dma1";
vdmatest_0: vdmatest@0 {
compatible ="xlnx,axi-vdma-test-1.00.a";
dmas = <&axi_vdma_0 0
&axi_vdma_0 1>;
dma-names = "vdma0", "vdma1";
} ;

107
Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
View file

@ -1,107 +0,0 @@
Xilinx AXI VDMA engine, it does transfers between memory and video devices.
It can be configured to have one channel or two channels. If configured
as two channels, one is to transmit to the video device and another is
to receive from the video device.
Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
target devices. It can be configured to have one channel or two channels.
If configured as two channels, one is to transmit to the device and another
is to receive from the device.
Xilinx AXI CDMA engine, it does transfers between memory-mapped source
address and a memory-mapped destination address.
Required properties:
- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a" or
"xlnx,axi-cdma-1.00.a""
- #dma-cells: Should be <1>, see "dmas" property below
- reg: Should contain VDMA registers location and length.
- xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits).
- dma-ranges: Should be as the following <dma_addr cpu_addr max_len>.
- dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
- clocks: Input clock specifier. Refer to common clock bindings.
- clock-names: List of input clocks
For VDMA:
Required elements: "s_axi_lite_aclk"
Optional elements: "m_axi_mm2s_aclk" "m_axi_s2mm_aclk",
"m_axis_mm2s_aclk", "s_axis_s2mm_aclk"
For CDMA:
Required elements: "s_axi_lite_aclk", "m_axi_aclk"
FOR AXIDMA:
Required elements: "s_axi_lite_aclk"
Optional elements: "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
"m_axi_sg_aclk"
Required properties for VDMA:
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
Optional properties:
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
Optional properties for VDMA:
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:
{1}, flush both channels
{2}, flush mm2s channel
{3}, flush s2mm channel
Required child node properties:
- compatible: It should be either "xlnx,axi-vdma-mm2s-channel" or
"xlnx,axi-vdma-s2mm-channel".
- interrupts: Should contain per channel VDMA interrupts.
- xlnx,datawidth: Should contain the stream data width, take values
{32,64...1024}.
Optional child node properties:
- xlnx,include-dre: Tells hardware is configured for Data
Realignment Engine.
Optional child node properties for VDMA:
- xlnx,genlock-mode: Tells Genlock synchronization is
enabled/disabled in hardware.
Example:
++++++++
axi_vdma_0: axivdma@40030000 {
compatible = "xlnx,axi-vdma-1.00.a";
#dma_cells = <1>;
reg = < 0x40030000 0x10000 >;
dma-ranges = <0x00000000 0x00000000 0x40000000>;
xlnx,num-fstores = <0x8>;
xlnx,flush-fsync = <0x1>;
xlnx,addrwidth = <0x20>;
clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>, <&clk 4>;
clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
"m_axis_mm2s_aclk", "s_axis_s2mm_aclk";
dma-channel@40030000 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;
xlnx,datawidth = <0x40>;
} ;
dma-channel@40030030 {
compatible = "xlnx,axi-vdma-s2mm-channel";
interrupts = < 0 53 4 >;
xlnx,datawidth = <0x40>;
} ;
} ;
* DMA client
Required properties:
- dmas: a list of <[Video DMA device phandle] [Channel ID]> pairs,
where Channel ID is '0' for write/tx and '1' for read/rx
channel.
- dma-names: a list of DMA channel names, one per "dmas" entry
Example:
++++++++
vdmatest_0: vdmatest@0 {
compatible ="xlnx,axi-vdma-test-1.00.a";
dmas = <&axi_vdma_0 0
&axi_vdma_0 1>;
dma-names = "vdma0", "vdma1";
} ;

27
Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt Normal file
View file

@ -0,0 +1,27 @@
Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
memory to device and device to memory transfers. It also has flow
control and rate control support for slave/peripheral dma access.
Required properties:
- compatible : Should be "xlnx,zynqmp-dma-1.0"
- reg : Memory map for gdma/adma module access.
- interrupt-parent : Interrupt controller the interrupt is routed through
- interrupts : Should contain DMA channel interrupt.
- xlnx,bus-width : Axi buswidth in bits. Should contain 128 or 64
- clock-names : List of input clocks "clk_main", "clk_apb"
(see clock bindings for details)
Optional properties:
- dma-coherent : Present if dma operations are coherent.
Example:
++++++++
fpd_dma_chan1: dma@fd500000 {
compatible = "xlnx,zynqmp-dma-1.0";
reg = <0x0 0xFD500000 0x1000>;
interrupt-parent = <&gic>;
interrupts = <0 117 4>;
clock-names = "clk_main", "clk_apb";
xlnx,bus-width = <128>;
dma-coherent;
};

28
Documentation/devicetree/bindings/firmware/qcom,scm.txt Normal file
View file

@ -0,0 +1,28 @@
QCOM Secure Channel Manager (SCM)
Qualcomm processors include an interface to communicate to the secure firmware.
This interface allows for clients to request different types of actions. These
can include CPU power up/down, HDCP requests, loading of firmware, and other
assorted actions.
Required properties:
- compatible: must contain one of the following:
* "qcom,scm-apq8064" for APQ8064 platforms
* "qcom,scm-msm8660" for MSM8660 platforms
* "qcom,scm-msm8690" for MSM8690 platforms
* "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
- clocks: One to three clocks may be required based on compatible.
* Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960"
* Core, iface, and bus clocks required for "qcom,scm"
- clock-names: Must contain "core" for the core clock, "iface" for the interface
clock and "bus" for the bus clock per the requirements of the compatible.
Example for MSM8916:
firmware {
scm {
compatible = "qcom,scm";
clocks = <&gcc GCC_CRYPTO_CLK> , <&gcc GCC_CRYPTO_AXI_CLK>, <&gcc GCC_CRYPTO_AHB_CLK>;
clock-names = "core", "bus", "iface";
};
};

47
Documentation/devicetree/bindings/gpio/gpio_oxnas.txt Normal file
View file

@ -0,0 +1,47 @@
* Oxford Semiconductor OXNAS SoC GPIO Controller
Please refer to gpio.txt for generic information regarding GPIO bindings.
Required properties:
- compatible: "oxsemi,ox810se-gpio"
- reg: Base address and length for the device.
- interrupts: The port interrupt shared by all pins.
- gpio-controller: Marks the port as GPIO controller.
- #gpio-cells: Two. The first cell is the pin number and
the second cell is used to specify the gpio polarity as defined in
defined in <dt-bindings/gpio/gpio.h>:
0 = GPIO_ACTIVE_HIGH
1 = GPIO_ACTIVE_LOW
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells: Two. The first cell is the GPIO number and second cell
is used to specify the trigger type as defined in
<dt-bindings/interrupt-controller/irq.h>:
IRQ_TYPE_EDGE_RISING
IRQ_TYPE_EDGE_FALLING
IRQ_TYPE_EDGE_BOTH
- gpio-ranges: Interaction with the PINCTRL subsystem, it also specifies the
gpio base and count, should be in the format of numeric-gpio-range as
specified in the gpio.txt file.
Example:
gpio0: gpio@0 {
compatible = "oxsemi,ox810se-gpio";
reg = <0x000000 0x100000>;
interrupts = <21>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
#interrupt-cells = <2>;
gpio-ranges = <&pinctrl 0 0 32>;
};
keys {
...
button-esc {
label = "ESC";
linux,code = <1>;
gpios = <&gpio0 12 0>;
};
};

9
Documentation/devicetree/bindings/i2c/trivial-devices.txt
View file

@ -126,6 +126,7 @@ national,lm80 Serial Interface ACPI-Compatible Microprocessor System Hardware M
national,lm85 Temperature sensor with integrated fan control
national,lm92 ±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator with Two-Wire Interface
nuvoton,npct501 i2c trusted platform module (TPM)
nuvoton,npct601 i2c trusted platform module (TPM2)
nxp,pca9556 Octal SMBus and I2C registered interface
nxp,pca9557 8-bit I2C-bus and SMBus I/O port with reset
nxp,pcf8563 Real-time clock/calendar
@ -145,10 +146,10 @@ samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
sgx,vz89x SGX Sensortech VZ89X Sensors
sii,s35390a 2-wire CMOS real-time clock
skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply
st-micro,24c256 i2c serial eeprom (24cxx)
stm,m41t00 Serial Access TIMEKEEPER
stm,m41t62 Serial real-time clock (RTC) with alarm
stm,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS
st,24c256 i2c serial eeprom (24cxx)
st,m41t00 Serial real-time clock (RTC)
st,m41t62 Serial real-time clock (RTC) with alarm
st,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS
taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface
ti,ads7828 8-Channels, 12-bit ADC
ti,ads7830 8-Channels, 8-bit ADC

12
Documentation/devicetree/bindings/iio/adc/at91_adc.txt
View file

@ -59,28 +59,24 @@ adc0: adc@fffb0000 {
atmel,adc-res-names = "lowres", "highres";
atmel,adc-use-res = "lowres";
trigger@0 {
reg = <0>;
trigger0 {
trigger-name = "external-rising";
trigger-value = <0x1>;
trigger-external;
};
trigger@1 {
reg = <1>;
trigger1 {
trigger-name = "external-falling";
trigger-value = <0x2>;
trigger-external;
};
trigger@2 {
reg = <2>;
trigger2 {
trigger-name = "external-any";
trigger-value = <0x3>;
trigger-external;
};
trigger@3 {
reg = <3>;
trigger3 {
trigger-name = "continuous";
trigger-value = <0x6>;
};

4
Documentation/devicetree/bindings/input/clps711x-keypad.txt
View file

@ -1,7 +1,7 @@
* Cirrus Logic CLPS711X matrix keypad device tree bindings
Required Properties:
- compatible: Shall contain "cirrus,clps711x-keypad".
- compatible: Shall contain "cirrus,ep7209-keypad".
- row-gpios: List of GPIOs used as row lines.
- poll-interval: Poll interval time in milliseconds.
- linux,keymap: The definition can be found at
@ -12,7 +12,7 @@ Optional Properties:
Example:
keypad {
compatible = "cirrus,ep7312-keypad", "cirrus,clps711x-keypad";
compatible = "cirrus,ep7312-keypad", "cirrus,ep7209-keypad";
autorepeat;
poll-interval = <120>;
row-gpios = <&porta 0 0>,

4
Documentation/devicetree/bindings/input/rotary-encoder.txt
View file

@ -20,6 +20,8 @@ Optional properties:
2: Half-period mode
4: Quarter-period mode
- wakeup-source: Boolean, rotary encoder can wake up the system.
- rotary-encoder,encoding: String, the method used to encode steps.
Supported are "gray" (the default and more common) and "binary".
Deprecated properties:
- rotary-encoder,half-period: Makes the driver work on half-period mode.
@ -34,6 +36,7 @@ Example:
compatible = "rotary-encoder";
gpios = <&gpio 19 1>, <&gpio 20 0>; /* GPIO19 is inverted */
linux,axis = <0>; /* REL_X */
rotary-encoder,encoding = "gray";
rotary-encoder,relative-axis;
};
@ -42,5 +45,6 @@ Example:
gpios = <&gpio 21 0>, <&gpio 22 0>;
linux,axis = <1>; /* ABS_Y */
rotary-encoder,steps = <24>;
rotary-encoder,encoding = "binary";
rotary-encoder,rollover;
};

36
Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt Normal file
View file

@ -0,0 +1,36 @@
* GSL 1680 touchscreen controller
Required properties:
- compatible : "silead,gsl1680"
- reg : I2C slave address of the chip (0x40)
- interrupt-parent : a phandle pointing to the interrupt controller
serving the interrupt for this chip
- interrupts : interrupt specification for the gsl1680 interrupt
- power-gpios : Specification for the pin connected to the gsl1680's
shutdown input. This needs to be driven high to take the
gsl1680 out of its low power state
- touchscreen-size-x : See touchscreen.txt
- touchscreen-size-y : See touchscreen.txt
Optional properties:
- touchscreen-inverted-x : See touchscreen.txt
- touchscreen-inverted-y : See touchscreen.txt
- touchscreen-swapped-x-y : See touchscreen.txt
- silead,max-fingers : maximum number of fingers the touchscreen can detect
Example:
i2c@00000000 {
gsl1680: touchscreen@40 {
compatible = "silead,gsl1680";
reg = <0x40>;
interrupt-parent = <&pio>;
interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>;
power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>;
touchscreen-size-x = <480>;
touchscreen-size-y = <800>;
touchscreen-inverted-x;
touchscreen-swapped-x-y;
silead,max-fingers = <5>;
};
};

33
Documentation/devicetree/bindings/input/touchscreen/sis_i2c.txt Normal file
View file

@ -0,0 +1,33 @@
* SiS I2C Multiple Touch Controller
Required properties:
- compatible: must be "sis,9200-ts"
- reg: i2c slave address
- interrupt-parent: the phandle for the interrupt controller
(see interrupt binding [0])
- interrupts: touch controller interrupt (see interrupt
binding [0])
Optional properties:
- pinctrl-names: should be "default" (see pinctrl binding [1]).
- pinctrl-0: a phandle pointing to the pin settings for the
device (see pinctrl binding [1]).
- attn-gpios: the gpio pin used as attention line
- reset-gpios: the gpio pin used to reset the controller
- wakeup-source: touchscreen can be used as a wakeup source
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
Example:
sis9255@5c {
compatible = "sis,9200-ts";
reg = <0x5c>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sis>;
interrupt-parent = <&gpio3>;
interrupts = <19 IRQ_TYPE_EDGE_FALLING>;
irq-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>;
};

4
Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
View file

@ -2,7 +2,7 @@ Cirrus Logic CLPS711X Interrupt Controller
Required properties:
- compatible: Should be "cirrus,clps711x-intc".
- compatible: Should be "cirrus,ep7209-intc".
- reg: Specifies base physical address of the registers set.
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: Specifies the number of cells needed to encode an
@ -34,7 +34,7 @@ ID Name Description
Example:
intc: interrupt-controller {
compatible = "cirrus,clps711x-intc";
compatible = "cirrus,ep7312-intc", "cirrus,ep7209-intc";
reg = <0x80000000 0x4000>;
interrupt-controller;
#interrupt-cells = <1>;

1
Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt
View file

@ -9,6 +9,7 @@ Required properties:
"mediatek,mt8135-sysirq"
"mediatek,mt8127-sysirq"
"mediatek,mt6795-sysirq"
"mediatek,mt6755-sysirq"
"mediatek,mt6592-sysirq"
"mediatek,mt6589-sysirq"
"mediatek,mt6582-sysirq"

2
Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt
View file

@ -1,6 +1,6 @@
* ARM SMMUv3 Architecture Implementation
The SMMUv3 architecture is a significant deparature from previous
The SMMUv3 architecture is a significant departure from previous
revisions, replacing the MMIO register interface with in-memory command
and event queues and adding support for the ATS and PRI components of
the PCIe specification.

13
Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
View file

@ -1,7 +1,9 @@
* Mediatek IOMMU Architecture Implementation
Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U) which
uses the ARM Short-Descriptor translation table format for address translation.
Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U), and
this M4U have two generations of HW architecture. Generation one uses flat
pagetable, and only supports 4K size page mapping. Generation two uses the
ARM Short-Descriptor translation table format for address translation.
About the M4U Hardware Block Diagram, please check below:
@ -36,7 +38,9 @@ in each larb. Take a example, There are many ports like MC, PP, VLD in the
video decode local arbiter, all these ports are according to the video HW.
Required properties:
- compatible : must be "mediatek,mt8173-m4u".
- compatible : must be one of the following string:
"mediatek,mt2701-m4u" for mt2701 which uses generation one m4u HW.
"mediatek,mt8173-m4u" for mt8173 which uses generation two m4u HW.
- reg : m4u register base and size.
- interrupts : the interrupt of m4u.
- clocks : must contain one entry for each clock-names.
@ -46,7 +50,8 @@ Required properties:
according to the local arbiter index, like larb0, larb1, larb2...
- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
Specifies the mtk_m4u_id as defined in
dt-binding/memory/mt8173-larb-port.h.
dt-binding/memory/mt2701-larb-port.h for mt2701 and
dt-binding/memory/mt8173-larb-port.h for mt8173
Example:
iommu: iommu@10205000 {

64
Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt Normal file
View file

@ -0,0 +1,64 @@
* QCOM IOMMU
The MSM IOMMU is an implementation compatible with the ARM VMSA short
descriptor page tables. It provides address translation for bus masters outside
of the CPU, each connected to the IOMMU through a port called micro-TLB.
Required Properties:
- compatible: Must contain "qcom,apq8064-iommu".
- reg: Base address and size of the IOMMU registers.
- interrupts: Specifiers for the MMU fault interrupts. For instances that
support secure mode two interrupts must be specified, for non-secure and
secure mode, in that order. For instances that don't support secure mode a
single interrupt must be specified.
- #iommu-cells: The number of cells needed to specify the stream id. This
is always 1.
- qcom,ncb: The total number of context banks in the IOMMU.
- clocks : List of clocks to be used during SMMU register access. See
Documentation/devicetree/bindings/clock/clock-bindings.txt
for information about the format. For each clock specified
here, there must be a corresponding entry in clock-names
(see below).
- clock-names : List of clock names corresponding to the clocks specified in
the "clocks" property (above).
Should be "smmu_pclk" for specifying the interface clock
required for iommu's register accesses.
Should be "smmu_clk" for specifying the functional clock
required by iommu for bus accesses.
Each bus master connected to an IOMMU must reference the IOMMU in its device
node with the following property:
- iommus: A reference to the IOMMU in multiple cells. The first cell is a
phandle to the IOMMU and the second cell is the stream id.
A single master device can be connected to more than one iommu
and multiple contexts in each of the iommu. So multiple entries
are required to list all the iommus and the stream ids that the
master is connected to.
Example: mdp iommu and its bus master
mdp_port0: iommu@7500000 {
compatible = "qcom,apq8064-iommu";
#iommu-cells = <1>;
clock-names =
"smmu_pclk",
"smmu_clk";
clocks =
<&mmcc SMMU_AHB_CLK>,
<&mmcc MDP_AXI_CLK>;
reg = <0x07500000 0x100000>;
interrupts =
<GIC_SPI 63 0>,
<GIC_SPI 64 0>;
qcom,ncb = <2>;
};
mdp: qcom,mdp@5100000 {
compatible = "qcom,mdp";
...
iommus = <&mdp_port0 0
&mdp_port0 2>;
};

2
Documentation/devicetree/bindings/leds/backlight/lp855x.txt
View file

@ -13,6 +13,7 @@ Optional properties:
- rom-addr: Register address of ROM area to be updated (u8)
- rom-val: Register value to be updated (u8)
- power-supply: Regulator which controls the 3V rail
- enable-supply: Regulator which controls the EN/VDDIO input
Example:
@ -57,6 +58,7 @@ Example:
backlight@2c {
compatible = "ti,lp8557";
reg = <0x2c>;
enable-supply = <&backlight_vddio>;
power-supply = <&backlight_vdd>;
dev-ctrl = /bits/ 8 <0x41>;

23
Documentation/devicetree/bindings/mailbox/brcm,iproc-pdc-mbox.txt Normal file
View file

@ -0,0 +1,23 @@
The PDC driver manages data transfer to and from various offload engines
on some Broadcom SoCs. An SoC may have multiple PDC hardware blocks. There is
one device tree entry per block.
Required properties:
- compatible : Should be "brcm,iproc-pdc-mbox".
- reg: Should contain PDC registers location and length.
- interrupts: Should contain the IRQ line for the PDC.
- #mbox-cells: 1
- brcm,rx-status-len: Length of metadata preceding received frames, in bytes.
Optional properties:
- brcm,use-bcm-hdr: present if a BCM header precedes each frame.
Example:
pdc0: iproc-pdc0@0x612c0000 {
compatible = "brcm,iproc-pdc-mbox";
reg = <0 0x612c0000 0 0x445>; /* PDC FS0 regs */
interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
#mbox-cells = <1>; /* one cell per mailbox channel */
brcm,rx-status-len = <32>;
brcm,use-bcm-hdr;
};

20
Documentation/devicetree/bindings/media/nokia,n900-ir Normal file
View file

@ -0,0 +1,20 @@
Device-Tree bindings for LIRC TX driver for Nokia N900(RX51)
Required properties:
- compatible: should be "nokia,n900-ir".
- pwms: specifies PWM used for IR signal transmission.
Example node:
pwm9: dmtimer-pwm@9 {
compatible = "ti,omap-dmtimer-pwm";
ti,timers = <&timer9>;
ti,clock-source = <0x00>; /* timer_sys_ck */
#pwm-cells = <3>;
};
ir: n900-ir {
compatible = "nokia,n900-ir";
pwms = <&pwm9 0 26316 0>; /* 38000 Hz */
};

136
Documentation/devicetree/bindings/memory-controllers/atmel,ebi.txt Normal file
View file

@ -0,0 +1,136 @@
* Device tree bindings for Atmel EBI
The External Bus Interface (EBI) controller is a bus where you can connect
asynchronous (NAND, NOR, SRAM, ....) and synchronous memories (SDR/DDR SDRAMs).
The EBI provides a glue-less interface to asynchronous memories through the SMC
(Static Memory Controller).
Required properties:
- compatible: "atmel,at91sam9260-ebi"
"atmel,at91sam9261-ebi"
"atmel,at91sam9263-ebi0"
"atmel,at91sam9263-ebi1"
"atmel,at91sam9rl-ebi"
"atmel,at91sam9g45-ebi"
"atmel,at91sam9x5-ebi"
"atmel,sama5d3-ebi"
- reg: Contains offset/length value for EBI memory mapping.
This property might contain several entries if the EBI
memory range is not contiguous
- #address-cells: Must be 2.
The first cell encodes the CS.
The second cell encode the offset into the CS memory
range.
- #size-cells: Must be set to 1.
- ranges: Encodes CS to memory region association.
- clocks: Clock feeding the EBI controller.
See clock-bindings.txt
Children device nodes are representing device connected to the EBI bus.
Required device node properties:
- reg: Contains the chip-select id, the offset and the length
of the memory region requested by the device.
EBI bus configuration will be defined directly in the device subnode.
Optional EBI/SMC properties:
- atmel,smc-bus-width: width of the asynchronous device's data bus
8, 16 or 32.
Default to 8 when undefined.
- atmel,smc-byte-access-type "write" or "select" (see Atmel datasheet).
Default to "select" when undefined.
- atmel,smc-read-mode "nrd" or "ncs".
Default to "ncs" when undefined.
- atmel,smc-write-mode "nwe" or "ncs".
Default to "ncs" when undefined.
- atmel,smc-exnw-mode "disabled", "frozen" or "ready".
Default to "disabled" when undefined.
- atmel,smc-page-mode enable page mode if present. The provided value
defines the page size (supported values: 4, 8,
16 and 32).
- atmel,smc-tdf-mode: "normal" or "optimized". When set to
"optimized" the data float time is optimized
depending on the next device being accessed
(next device setup time is subtracted to the
current device data float time).
Default to "normal" when undefined.
If at least one atmel,smc- property is defined the following SMC timing
properties become mandatory. In the other hand, if none of the atmel,smc-
properties are specified, we assume that the EBI bus configuration will be
handled by the sub-device driver, and none of those properties should be
defined.
All the timings are expressed in nanoseconds (see Atmel datasheet for a full
description).
- atmel,smc-ncs-rd-setup-ns
- atmel,smc-nrd-setup-ns
- atmel,smc-ncs-wr-setup-ns
- atmel,smc-nwe-setup-ns
- atmel,smc-ncs-rd-pulse-ns
- atmel,smc-nrd-pulse-ns
- atmel,smc-ncs-wr-pulse-ns
- atmel,smc-nwe-pulse-ns
- atmel,smc-nwe-cycle-ns
- atmel,smc-nrd-cycle-ns
- atmel,smc-tdf-ns
Example:
ebi: ebi@10000000 {
compatible = "atmel,sama5d3-ebi";
#address-cells = <2>;
#size-cells = <1>;
atmel,smc = <&hsmc>;
atmel,matrix = <&matrix>;
reg = <0x10000000 0x10000000
0x40000000 0x30000000>;
ranges = <0x0 0x0 0x10000000 0x10000000
0x1 0x0 0x40000000 0x10000000
0x2 0x0 0x50000000 0x10000000
0x3 0x0 0x60000000 0x10000000>;
clocks = <&mck>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ebi_addr>;
nor: flash@0,0 {
compatible = "cfi-flash";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x0 0x0 0x1000000>;
bank-width = <2>;
atmel,smc-read-mode = "nrd";
atmel,smc-write-mode = "nwe";
atmel,smc-bus-width = <16>;
atmel,smc-ncs-rd-setup-ns = <0>;
atmel,smc-ncs-wr-setup-ns = <0>;
atmel,smc-nwe-setup-ns = <8>;
atmel,smc-nrd-setup-ns = <16>;
atmel,smc-ncs-rd-pulse-ns = <84>;
atmel,smc-ncs-wr-pulse-ns = <84>;
atmel,smc-nrd-pulse-ns = <76>;
atmel,smc-nwe-pulse-ns = <76>;
atmel,smc-nrd-cycle-ns = <107>;
atmel,smc-nwe-cycle-ns = <84>;
atmel,smc-tdf-ns = <16>;
};
};

21
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt
View file

@ -2,16 +2,31 @@ SMI (Smart Multimedia Interface) Common
The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
Mediatek SMI have two generations of HW architecture, mt8173 uses the second
generation of SMI HW while mt2701 uses the first generation HW of SMI.
There's slight differences between the two SMI, for generation 2, the
register which control the iommu port is at each larb's register base. But
for generation 1, the register is at smi ao base(smi always on register
base). Besides that, the smi async clock should be prepared and enabled for
SMI generation 1 to transform the smi clock into emi clock domain, but that is
not needed for SMI generation 2.
Required properties:
- compatible : must be "mediatek,mt8173-smi-common"
- compatible : must be one of :
"mediatek,mt2701-smi-common"
"mediatek,mt8173-smi-common"
- reg : the register and size of the SMI block.
- power-domains : a phandle to the power domain of this local arbiter.
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : must contain 2 entries, as follows:
- clock-names : must contain 3 entries for generation 1 smi HW and 2 entries
for generation 2 smi HW as follows:
- "apb" : Advanced Peripheral Bus clock, It's the clock for setting
the register.
- "smi" : It's the clock for transfer data and command.
They may be the same if both source clocks are the same.
They may be the same if both source clocks are the same.
- "async" : asynchronous clock, it help transform the smi clock into the emi
clock domain, this clock is only needed by generation 1 smi HW.
Example:
smi_common: smi@14022000 {

4
Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
View file

@ -3,7 +3,9 @@ SMI (Smart Multimedia Interface) Local Arbiter
The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
Required properties:
- compatible : must be "mediatek,mt8173-smi-larb"
- compatible : must be one of :
"mediatek,mt8173-smi-larb"
"mediatek,mt2701-smi-larb"
- reg : the register and size of this local arbiter.
- mediatek,smi : a phandle to the smi_common node.
- power-domains : a phandle to the power domain of this local arbiter.

7
Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
View file

@ -46,6 +46,10 @@ Required properties:
0 maps to GPMC_WAIT0 pin.
- gpio-cells: Must be set to 2
Required properties when using NAND prefetch dma:
- dmas GPMC NAND prefetch dma channel
- dma-names Must be set to "rxtx"
Timing properties for child nodes. All are optional and default to 0.
- gpmc,sync-clk-ps: Minimum clock period for synchronous mode, in picoseconds
@ -137,7 +141,8 @@ Example for an AM33xx board:
ti,hwmods = "gpmc";
reg = <0x50000000 0x2000>;
interrupts = <100>;
dmas = <&edma 52 0>;
dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;

28
Documentation/devicetree/bindings/mfd/da9052-i2c.txt
View file

@ -8,10 +8,13 @@ Sub-nodes:
- regulators : Contain the regulator nodes. The DA9052/53 regulators are
bound using their names as listed below:
buck0 : regulator BUCK0
buck1 : regulator BUCK1
buck2 : regulator BUCK2
buck3 : regulator BUCK3
buck1 : regulator BUCK CORE
buck2 : regulator BUCK PRO
buck3 : regulator BUCK MEM
buck4 : regulator BUCK PERI
ldo1 : regulator LDO1
ldo2 : regulator LDO2
ldo3 : regulator LDO3
ldo4 : regulator LDO4
ldo5 : regulator LDO5
ldo6 : regulator LDO6
@ -19,9 +22,6 @@ Sub-nodes:
ldo8 : regulator LDO8
ldo9 : regulator LDO9
ldo10 : regulator LDO10
ldo11 : regulator LDO11
ldo12 : regulator LDO12
ldo13 : regulator LDO13
The bindings details of individual regulator device can be found in:
Documentation/devicetree/bindings/regulator/regulator.txt
@ -36,25 +36,25 @@ i2c@63fc8000 { /* I2C1 */
reg = <0x48>;
regulators {
buck0 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <2075000>;
};
buck1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <2075000>;
};
buck2 {
regulator-min-microvolt = <925000>;
regulator-max-microvolt = <2500000>;
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <2075000>;
};
buck3 {
regulator-min-microvolt = <925000>;
regulator-max-microvolt = <2500000>;
};
buck4 {
regulator-min-microvolt = <925000>;
regulator-max-microvolt = <2500000>;
};
};
};
};

4
Documentation/devicetree/bindings/mfd/twl6040.txt
View file

@ -19,8 +19,8 @@ Required properties:
Optional properties, nodes:
- enable-active-high: To power on the twl6040 during boot.
- clocks: phandle to the clk32k clock provider
- clock-names: Must be "clk32k"
- clocks: phandle to the clk32k and/or to mclk clock provider
- clock-names: Must be "clk32k" for the 32K clock and "mclk" for the MCLK.
Vibra functionality
Required properties:

35
Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
View file

@ -9,8 +9,12 @@ Device Tree Bindings for the Arasan SDHCI Controller
[4] Documentation/devicetree/bindings/phy/phy-bindings.txt
Required Properties:
- compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or
'arasan,sdhci-4.9a' or 'arasan,sdhci-5.1'
- compatible: Compatibility string. One of:
- "arasan,sdhci-8.9a": generic Arasan SDHCI 8.9a PHY
- "arasan,sdhci-4.9a": generic Arasan SDHCI 4.9a PHY
- "arasan,sdhci-5.1": generic Arasan SDHCI 5.1 PHY
- "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1": rk3399 eMMC PHY
For this device it is strongly suggested to include arasan,soc-ctl-syscon.
- reg: From mmc bindings: Register location and length.
- clocks: From clock bindings: Handles to clock inputs.
- clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb"
@ -22,6 +26,17 @@ Required Properties for "arasan,sdhci-5.1":
- phys: From PHY bindings: Phandle for the Generic PHY for arasan.
- phy-names: MUST be "phy_arasan".
Optional Properties:
- arasan,soc-ctl-syscon: A phandle to a syscon device (see ../mfd/syscon.txt)
used to access core corecfg registers. Offsets of registers in this
syscon are determined based on the main compatible string for the device.
- clock-output-names: If specified, this will be the name of the card clock
which will be exposed by this device. Required if #clock-cells is
specified.
- #clock-cells: If specified this should be the value <0>. With this property
in place we will export a clock representing the Card Clock. This clock
is expected to be consumed by our PHY. You must also specify
Example:
sdhci@e0100000 {
compatible = "arasan,sdhci-8.9a";
@ -42,3 +57,19 @@ Example:
phys = <&emmc_phy>;
phy-names = "phy_arasan";
} ;
sdhci: sdhci@fe330000 {
compatible = "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1";
reg = <0x0 0xfe330000 0x0 0x10000>;
interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru SCLK_EMMC>, <&cru ACLK_EMMC>;
clock-names = "clk_xin", "clk_ahb";
arasan,soc-ctl-syscon = <&grf>;
assigned-clocks = <&cru SCLK_EMMC>;
assigned-clock-rates = <200000000>;
clock-output-names = "emmc_cardclock";
phys = <&emmc_phy>;
phy-names = "phy_arasan";
#clock-cells = <0>;
status = "disabled";
};

18
Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt
View file

@ -1,18 +0,0 @@
Broadcom BCM2835 SDHCI controller
This file documents differences between the core properties described
by mmc.txt and the properties that represent the BCM2835 controller.
Required properties:
- compatible : Should be "brcm,bcm2835-sdhci".
- clocks : The clock feeding the SDHCI controller.
Example:
sdhci: sdhci {
compatible = "brcm,bcm2835-sdhci";
reg = <0x7e300000 0x100>;
interrupts = <2 30>;
clocks = <&clk_mmc>;
bus-width = <4>;
};

36
Documentation/devicetree/bindings/mmc/brcm,bcm7425-sdhci.txt Normal file
View file

@ -0,0 +1,36 @@
* BROADCOM BRCMSTB/BMIPS SDHCI Controller
This file documents differences between the core properties in mmc.txt
and the properties used by the sdhci-brcmstb driver.
NOTE: The driver disables all UHS speed modes by default and depends
on Device Tree properties to enable them for SoC/Board combinations
that support them.
Required properties:
- compatible: "brcm,bcm7425-sdhci"
Refer to clocks/clock-bindings.txt for generic clock consumer properties.
Example:
sdhci@f03e0100 {
compatible = "brcm,bcm7425-sdhci";
reg = <0xf03e0000 0x100>;
interrupts = <0x0 0x26 0x0>;
sdhci,auto-cmd12;
clocks = <&sw_sdio>;
sd-uhs-sdr50;
sd-uhs-ddr50;
};
sdhci@f03e0300 {
non-removable;
bus-width = <0x8>;
compatible = "brcm,bcm7425-sdhci";
reg = <0xf03e0200 0x100>;
interrupts = <0x0 0x27 0x0>;
sdhci,auto-cmd12;
clocks = <sw_sdio>;
mmc-hs200-1_8v;
};

2
Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
View file

@ -28,6 +28,8 @@ Optional properties:
transparent level shifters on the outputs of the controller. Two cells are
required, first cell specifies minimum slot voltage (mV), second cell
specifies maximum slot voltage (mV). Several ranges could be specified.
- fsl,tuning-start-tap: Specify the start dealy cell point when send first CMD19
in tuning procedure.
- fsl,tuning-step: Specify the increasing delay cell steps in tuning procedure.
The uSDHC use one delay cell as default increasing step to do tuning process.
This property allows user to change the tuning step to more than one delay

4
Documentation/devicetree/bindings/mmc/mmc.txt
View file

@ -46,8 +46,12 @@ Optional properties:
- mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
- mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
- mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
- mmc-hs400-enhanced-strobe: eMMC HS400 enhanced strobe mode is supported
- dsr: Value the card's (optional) Driver Stage Register (DSR) should be
programmed with. Valid range: [0 .. 0xffff].
- no-sdio: controller is limited to send sdio cmd during initialization
- no-sd: controller is limited to send sd cmd during initialization
- no-mmc: controller is limited to send mmc cmd during initialization
*NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
polarity properties, we have to fix the meaning of the "normal" and "inverted"

32
Documentation/devicetree/bindings/mtd/atmel-quadspi.txt Normal file
View file

@ -0,0 +1,32 @@
* Atmel Quad Serial Peripheral Interface (QSPI)
Required properties:
- compatible: Should be "atmel,sama5d2-qspi".
- reg: Should contain the locations and lengths of the base registers
and the mapped memory.
- reg-names: Should contain the resource reg names:
- qspi_base: configuration register address space
- qspi_mmap: memory mapped address space
- interrupts: Should contain the interrupt for the device.
- clocks: The phandle of the clock needed by the QSPI controller.
- #address-cells: Should be <1>.
- #size-cells: Should be <0>.
Example:
spi@f0020000 {
compatible = "atmel,sama5d2-qspi";
reg = <0xf0020000 0x100>, <0xd0000000 0x8000000>;
reg-names = "qspi_base", "qspi_mmap";
interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>;
clocks = <&spi0_clk>;
#address-cells = <1>;
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_spi0_default>;
status = "okay";
m25p80@0 {
...
};
};

1
Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
View file

@ -27,6 +27,7 @@ Required properties:
brcm,brcmnand-v6.2
brcm,brcmnand-v7.0
brcm,brcmnand-v7.1
brcm,brcmnand-v7.2
brcm,brcmnand
- reg : the register start and length for NAND register region.
(optional) Flash DMA register range (if present)

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