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

Linux 3.15-rc1 

-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJTSv89AAoJEHm+PkMAQRiGd7AIAKL45dFRhX96W53uzGlpXtv7
 Ecs9CMY5mtsB/rqtV/NSQaUELlNb4Ilb4lITh7NaLWAZxDJ12GwVsIbFoaBj7Ypx
 tfBNNxffGGnTTn2C1PpPQmLytLBvqXIVHMaPpDvnHYJl6g9BihshLzyMrsrizqnA
 DPJ0xMdgGp6BLC4qm0ZH1mS2q+TyXLN2ZCjJ1lp6NNYwBnwOe/ABjnUa0Ztu7aii
 837N8h6nEuKHTr6DgrYHEgYVc3DPHPHaly/UJ8v4U30myzRv83YkD5DsBSUjSLj8
 CzxJEnECa1XljLJK7SjRHy5pSP9tcUlmjx3Fk7IpQixmT+A15cov6fQ967jNlDw=
 =Hxnc
 -----END PGP SIGNATURE-----

Merge tag 'v3.15-rc1' into for-3.16/core

We don't like this, but things have diverged with the blk-mq fixes
in 3.15-rc1. So merge it in.
wifi-calibration
Jens Axboe 2014-04-15 14:02:24 -06:00
parent 21f9fcd815 c9eaa447e7
commit f89e0dd9d1
2159 changed files with 167482 additions and 35174 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
Documentation/ABI/testing/sysfs-block-zram
View File

@ -43,6 +43,36 @@ Description:
The invalid_io file is read-only and specifies the number of
non-page-size-aligned I/O requests issued to this device.
What: /sys/block/zram<id>/failed_reads
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The failed_reads file is read-only and specifies the number of
failed reads happened on this device.
What: /sys/block/zram<id>/failed_writes
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The failed_writes file is read-only and specifies the number of
failed writes happened on this device.
What: /sys/block/zram<id>/max_comp_streams
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The max_comp_streams file is read-write and specifies the
number of backend's zcomp_strm compression streams (number of
concurrent compress operations).
What: /sys/block/zram<id>/comp_algorithm
Date: February 2014
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The comp_algorithm file is read-write and lets to show
available and selected compression algorithms, change
compression algorithm selection.
What: /sys/block/zram<id>/notify_free
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
@ -53,15 +83,6 @@ Description:
is freed. This statistic is applicable only when this disk is
being used as a swap disk.
What: /sys/block/zram<id>/discard
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The discard file is read-only and specifies the number of
discard requests received by this device. These requests
provide information to block device regarding blocks which are
no longer used by filesystem.
What: /sys/block/zram<id>/zero_pages
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>

46
Documentation/ABI/testing/sysfs-devices-power
View File

@ -83,8 +83,10 @@ Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_count attribute contains the number
of signaled wakeup events associated with the device. This
attribute is read-only. If the device is not enabled to wake up
attribute is read-only. If the device is not capable to wake up
the system from sleep states, this attribute is not present.
If the device is not enabled to wake up the system from sleep
states, this attribute is empty.
What: /sys/devices/.../power/wakeup_active_count
Date: September 2010
@ -93,8 +95,10 @@ Description:
The /sys/devices/.../wakeup_active_count attribute contains the
number of times the processing of wakeup events associated with
the device was completed (at the kernel level). This attribute
is read-only. If the device is not enabled to wake up the
system from sleep states, this attribute is not present.
is read-only. If the device is not capable to wake up the
system from sleep states, this attribute is not present. If
the device is not enabled to wake up the system from sleep
states, this attribute is empty.
What: /sys/devices/.../power/wakeup_abort_count
Date: February 2012
@ -104,8 +108,9 @@ Description:
number of times the processing of a wakeup event associated with
the device might have aborted system transition into a sleep
state in progress. This attribute is read-only. If the device
is not enabled to wake up the system from sleep states, this
attribute is not present.
is not capable to wake up the system from sleep states, this
attribute is not present. If the device is not enabled to wake
up the system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_expire_count
Date: February 2012
@ -114,8 +119,10 @@ Description:
The /sys/devices/.../wakeup_expire_count attribute contains the
number of times a wakeup event associated with the device has
been reported with a timeout that expired. This attribute is
read-only. If the device is not enabled to wake up the system
from sleep states, this attribute is not present.
read-only. If the device is not capable to wake up the system
from sleep states, this attribute is not present. If the
device is not enabled to wake up the system from sleep states,
this attribute is empty.
What: /sys/devices/.../power/wakeup_active
Date: September 2010
@ -124,8 +131,10 @@ Description:
The /sys/devices/.../wakeup_active attribute contains either 1,
or 0, depending on whether or not a wakeup event associated with
the device is being processed (1). This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is not present.
If the device is not capable to wake up the system from sleep
states, this attribute is not present. If the device is not
enabled to wake up the system from sleep states, this attribute
is empty.
What: /sys/devices/.../power/wakeup_total_time_ms
Date: September 2010
@ -134,8 +143,9 @@ Description:
The /sys/devices/.../wakeup_total_time_ms attribute contains
the total time of processing wakeup events associated with the
device, in milliseconds. This attribute is read-only. If the
device is not enabled to wake up the system from sleep states,
this attribute is not present.
device is not capable to wake up the system from sleep states,
this attribute is not present. If the device is not enabled to
wake up the system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_max_time_ms
Date: September 2010
@ -144,8 +154,10 @@ Description:
The /sys/devices/.../wakeup_max_time_ms attribute contains
the maximum time of processing a single wakeup event associated
with the device, in milliseconds. This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is not present.
If the device is not capable to wake up the system from sleep
states, this attribute is not present. If the device is not
enabled to wake up the system from sleep states, this attribute
is empty.
What: /sys/devices/.../power/wakeup_last_time_ms
Date: September 2010
@ -156,7 +168,8 @@ Description:
signaling the last wakeup event associated with the device, in
milliseconds. This attribute is read-only. If the device is
not enabled to wake up the system from sleep states, this
attribute is not present.
attribute is not present. If the device is not enabled to wake
up the system from sleep states, this attribute is empty.
What: /sys/devices/.../power/wakeup_prevent_sleep_time_ms
Date: February 2012
@ -165,9 +178,10 @@ Description:
The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
contains the total time the device has been preventing
opportunistic transitions to sleep states from occurring.
This attribute is read-only. If the device is not enabled to
This attribute is read-only. If the device is not capable to
wake up the system from sleep states, this attribute is not
present.
present. If the device is not enabled to wake up the system
from sleep states, this attribute is empty.
What: /sys/devices/.../power/autosuspend_delay_ms
Date: September 2010

12
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@ -55,3 +55,15 @@ Date: January 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the number of trials to find a victim segment.
What: /sys/fs/f2fs/<disk>/dir_level
Date: March 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the directory level for large directory.
What: /sys/fs/f2fs/<disk>/ram_thresh
Date: March 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
Description:
Controls the memory footprint used by f2fs.

1
Documentation/ABI/testing/sysfs-module
View File

@ -49,3 +49,4 @@ Description: Module taint flags:
O - out-of-tree module
F - force-loaded module
C - staging driver module
E - unsigned module

25
Documentation/DocBook/Makefile
View File

@ -16,7 +16,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml drm.xml media_api.xml w1.xml
include $(srctree)/Documentation/DocBook/media/Makefile
include Documentation/DocBook/media/Makefile
###
# The build process is as follows (targets):
@ -36,6 +36,7 @@ PS_METHOD = $(prefer-db2x)
# The targets that may be used.
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
targets += $(DOCBOOKS)
BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
xmldocs: $(BOOKS)
sgmldocs: xmldocs
@ -58,14 +59,14 @@ mandocs: $(MAN)
installmandocs: mandocs
mkdir -p /usr/local/man/man9/
install Documentation/DocBook/man/*.9.gz /usr/local/man/man9/
install $(obj)/man/*.9.gz /usr/local/man/man9/
###
#External programs used
KERNELDOC = $(srctree)/scripts/kernel-doc
DOCPROC = $(objtree)/scripts/docproc
XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl
XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
XMLTOFLAGS += --skip-validation
###
@ -87,21 +88,9 @@ define rule_docproc
) > $(dir $@).$(notdir $@).cmd
endef
%.xml: %.tmpl FORCE
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE
$(call if_changed_rule,docproc)
###
#Read in all saved dependency files
cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd))
ifneq ($(cmd_files),)
include $(cmd_files)
endif
###
# Changes in kernel-doc force a rebuild of all documentation
$(BOOKS): $(KERNELDOC)
# Tell kbuild to always build the programs
always := $(hostprogs-y)
@ -139,7 +128,7 @@ quiet_cmd_db2pdf = PDF $@
index = index.html
main_idx = Documentation/DocBook/$(index)
main_idx = $(obj)/$(index)
build_main_index = rm -rf $(main_idx); \
echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \
echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
@ -148,7 +137,7 @@ build_main_index = rm -rf $(main_idx); \
quiet_cmd_db2html = HTML $@
cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
%.html: %.xml
@(which xmlto > /dev/null 2>&1) || \

552
Documentation/DocBook/drm.tmpl
View File

@ -29,12 +29,26 @@
</address>
</affiliation>
</author>
<author>
<firstname>Daniel</firstname>
<surname>Vetter</surname>
<contrib>Contributions all over the place</contrib>
<affiliation>
<orgname>Intel Corporation</orgname>
<address>
<email>daniel.vetter@ffwll.ch</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
<year>2008-2009</year>
<year>2012</year>
<year>2013-2014</year>
<holder>Intel Corporation</holder>
</copyright>
<copyright>
<year>2012</year>
<holder>Laurent Pinchart</holder>
</copyright>
@ -60,7 +74,15 @@
<toc></toc>
<!-- Introduction -->
<part id="drmCore">
<title>DRM Core</title>
<partintro>
<para>
This first part of the DRM Developer's Guide documents core DRM code,
helper libraries for writting drivers and generic userspace interfaces
exposed by DRM drivers.
</para>
</partintro>
<chapter id="drmIntroduction">
<title>Introduction</title>
@ -264,8 +286,8 @@ char *date;</synopsis>
<para>
The <methodname>load</methodname> method is the driver and device
initialization entry point. The method is responsible for allocating and
initializing driver private data, specifying supported performance
counters, performing resource allocation and mapping (e.g. acquiring
initializing driver private data, performing resource allocation and
mapping (e.g. acquiring
clocks, mapping registers or allocating command buffers), initializing
the memory manager (<xref linkend="drm-memory-management"/>), installing
the IRQ handler (<xref linkend="drm-irq-registration"/>), setting up
@ -295,7 +317,7 @@ char *date;</synopsis>
their <methodname>load</methodname> method called with flags to 0.
</para>
<sect3>
<title>Driver Private &amp; Performance Counters</title>
<title>Driver Private Data</title>
<para>
The driver private hangs off the main
<structname>drm_device</structname> structure and can be used for
@ -307,14 +329,6 @@ char *date;</synopsis>
<structname>drm_device</structname>.<structfield>dev_priv</structfield>
set to NULL when the driver is unloaded.
</para>
<para>
DRM supports several counters which were used for rough performance
characterization. This stat counter system is deprecated and should not
be used. If performance monitoring is desired, the developer should
investigate and potentially enhance the kernel perf and tracing
infrastructure to export GPU related performance information for
consumption by performance monitoring tools and applications.
</para>
</sect3>
<sect3 id="drm-irq-registration">
<title>IRQ Registration</title>
@ -697,55 +711,16 @@ char *date;</synopsis>
respectively. The conversion is handled by the DRM core without any
driver-specific support.
</para>
<para>
Similar to global names, GEM file descriptors are also used to share GEM
objects across processes. They offer additional security: as file
descriptors must be explicitly sent over UNIX domain sockets to be shared
between applications, they can't be guessed like the globally unique GEM
names.
</para>
<para>
Drivers that support GEM file descriptors, also known as the DRM PRIME
API, must set the DRIVER_PRIME bit in the struct
<structname>drm_driver</structname>
<structfield>driver_features</structfield> field, and implement the
<methodname>prime_handle_to_fd</methodname> and
<methodname>prime_fd_to_handle</methodname> operations.
</para>
<para>
<synopsis>int (*prime_handle_to_fd)(struct drm_device *dev,
struct drm_file *file_priv, uint32_t handle,
uint32_t flags, int *prime_fd);
int (*prime_fd_to_handle)(struct drm_device *dev,
struct drm_file *file_priv, int prime_fd,
uint32_t *handle);</synopsis>
Those two operations convert a handle to a PRIME file descriptor and
vice versa. Drivers must use the kernel dma-buf buffer sharing framework
to manage the PRIME file descriptors.
</para>
<para>
While non-GEM drivers must implement the operations themselves, GEM
drivers must use the <function>drm_gem_prime_handle_to_fd</function>
and <function>drm_gem_prime_fd_to_handle</function> helper functions.
Those helpers rely on the driver
<methodname>gem_prime_export</methodname> and
<methodname>gem_prime_import</methodname> operations to create a dma-buf
instance from a GEM object (dma-buf exporter role) and to create a GEM
object from a dma-buf instance (dma-buf importer role).
</para>
<para>
<synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev,
struct drm_gem_object *obj,
int flags);
struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev,
struct dma_buf *dma_buf);</synopsis>
These two operations are mandatory for GEM drivers that support DRM
PRIME.
</para>
<sect4>
<title>DRM PRIME Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
</sect4>
<para>
GEM also supports buffer sharing with dma-buf file descriptors through
PRIME. GEM-based drivers must use the provided helpers functions to
implement the exporting and importing correctly. See <xref linkend="drm-prime-support" />.
Since sharing file descriptors is inherently more secure than the
easily guessable and global GEM names it is the preferred buffer
sharing mechanism. Sharing buffers through GEM names is only supported
for legacy userspace. Furthermore PRIME also allows cross-device
buffer sharing since it is based on dma-bufs.
</para>
</sect3>
<sect3 id="drm-gem-objects-mapping">
<title>GEM Objects Mapping</title>
@ -829,62 +804,6 @@ char *date;</synopsis>
faults can implement their own mmap file operation handler.
</para>
</sect3>
<sect3>
<title>Dumb GEM Objects</title>
<para>
The GEM API doesn't standardize GEM objects creation and leaves it to
driver-specific ioctls. While not an issue for full-fledged graphics
stacks that include device-specific userspace components (in libdrm for
instance), this limit makes DRM-based early boot graphics unnecessarily
complex.
</para>
<para>
Dumb GEM objects partly alleviate the problem by providing a standard
API to create dumb buffers suitable for scanout, which can then be used
to create KMS frame buffers.
</para>
<para>
To support dumb GEM objects drivers must implement the
<methodname>dumb_create</methodname>,
<methodname>dumb_destroy</methodname> and
<methodname>dumb_map_offset</methodname> operations.
</para>
<itemizedlist>
<listitem>
<synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev,
struct drm_mode_create_dumb *args);</synopsis>
<para>
The <methodname>dumb_create</methodname> operation creates a GEM
object suitable for scanout based on the width, height and depth
from the struct <structname>drm_mode_create_dumb</structname>
argument. It fills the argument's <structfield>handle</structfield>,
<structfield>pitch</structfield> and <structfield>size</structfield>
fields with a handle for the newly created GEM object and its line
pitch and size in bytes.
</para>
</listitem>
<listitem>
<synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev,
uint32_t handle);</synopsis>
<para>
The <methodname>dumb_destroy</methodname> operation destroys a dumb
GEM object created by <methodname>dumb_create</methodname>.
</para>
</listitem>
<listitem>
<synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev,
uint32_t handle, uint64_t *offset);</synopsis>
<para>
The <methodname>dumb_map_offset</methodname> operation associates an
mmap fake offset with the GEM object given by the handle and returns
it. Drivers must use the
<function>drm_gem_create_mmap_offset</function> function to
associate the fake offset as described in
<xref linkend="drm-gem-objects-mapping"/>.
</para>
</listitem>
</itemizedlist>
</sect3>
<sect3>
<title>Memory Coherency</title>
<para>
@ -924,7 +843,99 @@ char *date;</synopsis>
abstracted from the client in libdrm.
</para>
</sect3>
</sect2>
<sect3>
<title>GEM Function Reference</title>
!Edrivers/gpu/drm/drm_gem.c
</sect3>
</sect2>
<sect2>
<title>VMA Offset Manager</title>
!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager
!Edrivers/gpu/drm/drm_vma_manager.c
!Iinclude/drm/drm_vma_manager.h
</sect2>
<sect2 id="drm-prime-support">
<title>PRIME Buffer Sharing</title>
<para>
PRIME is the cross device buffer sharing framework in drm, originally
created for the OPTIMUS range of multi-gpu platforms. To userspace
PRIME buffers are dma-buf based file descriptors.
</para>
<sect3>
<title>Overview and Driver Interface</title>
<para>
Similar to GEM global names, PRIME file descriptors are
also used to share buffer objects across processes. They offer
additional security: as file descriptors must be explicitly sent over
UNIX domain sockets to be shared between applications, they can't be
guessed like the globally unique GEM names.
</para>
<para>
Drivers that support the PRIME
API must set the DRIVER_PRIME bit in the struct
<structname>drm_driver</structname>
<structfield>driver_features</structfield> field, and implement the
<methodname>prime_handle_to_fd</methodname> and
<methodname>prime_fd_to_handle</methodname> operations.
</para>
<para>
<synopsis>int (*prime_handle_to_fd)(struct drm_device *dev,
struct drm_file *file_priv, uint32_t handle,
uint32_t flags, int *prime_fd);
int (*prime_fd_to_handle)(struct drm_device *dev,
struct drm_file *file_priv, int prime_fd,
uint32_t *handle);</synopsis>
Those two operations convert a handle to a PRIME file descriptor and
vice versa. Drivers must use the kernel dma-buf buffer sharing framework
to manage the PRIME file descriptors. Similar to the mode setting
API PRIME is agnostic to the underlying buffer object manager, as
long as handles are 32bit unsinged integers.
</para>
<para>
While non-GEM drivers must implement the operations themselves, GEM
drivers must use the <function>drm_gem_prime_handle_to_fd</function>
and <function>drm_gem_prime_fd_to_handle</function> helper functions.
Those helpers rely on the driver
<methodname>gem_prime_export</methodname> and
<methodname>gem_prime_import</methodname> operations to create a dma-buf
instance from a GEM object (dma-buf exporter role) and to create a GEM
object from a dma-buf instance (dma-buf importer role).
</para>
<para>
<synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev,
struct drm_gem_object *obj,
int flags);
struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev,
struct dma_buf *dma_buf);</synopsis>
These two operations are mandatory for GEM drivers that support
PRIME.
</para>
</sect3>
<sect3>
<title>PRIME Helper Functions</title>
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
</sect3>
</sect2>
<sect2>
<title>PRIME Function References</title>
!Edrivers/gpu/drm/drm_prime.c
</sect2>
<sect2>
<title>DRM MM Range Allocator</title>
<sect3>
<title>Overview</title>
!Pdrivers/gpu/drm/drm_mm.c Overview
</sect3>
<sect3>
<title>LRU Scan/Eviction Support</title>
!Pdrivers/gpu/drm/drm_mm.c lru scan roaster
</sect3>
</sect2>
<sect2>
<title>DRM MM Range Allocator Function References</title>
!Edrivers/gpu/drm/drm_mm.c
!Iinclude/drm/drm_mm.h
</sect2>
</sect1>
<!-- Internals: mode setting -->
@ -952,6 +963,11 @@ int max_width, max_height;</synopsis>
<para>Mode setting functions.</para>
</listitem>
</itemizedlist>
<sect2>
<title>Display Modes Function Reference</title>
!Iinclude/drm/drm_modes.h
!Edrivers/gpu/drm/drm_modes.c
</sect2>
<sect2>
<title>Frame Buffer Creation</title>
<synopsis>struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
@ -968,9 +984,11 @@ int max_width, max_height;</synopsis>
Frame buffers rely on the underneath memory manager for low-level memory
operations. When creating a frame buffer applications pass a memory
handle (or a list of memory handles for multi-planar formats) through
the <parameter>drm_mode_fb_cmd2</parameter> argument. This document
assumes that the driver uses GEM, those handles thus reference GEM
objects.
the <parameter>drm_mode_fb_cmd2</parameter> argument. For drivers using
GEM as their userspace buffer management interface this would be a GEM
handle. Drivers are however free to use their own backing storage object
handles, e.g. vmwgfx directly exposes special TTM handles to userspace
and so expects TTM handles in the create ioctl and not GEM handles.
</para>
<para>
Drivers must first validate the requested frame buffer parameters passed
@ -992,7 +1010,7 @@ int max_width, max_height;</synopsis>
</para>
<para>
The initailization of the new framebuffer instance is finalized with a
The initialization of the new framebuffer instance is finalized with a
call to <function>drm_framebuffer_init</function> which takes a pointer
to DRM frame buffer operations (struct
<structname>drm_framebuffer_funcs</structname>). Note that this function
@ -1042,7 +1060,7 @@ int max_width, max_height;</synopsis>
<para>
The lifetime of a drm framebuffer is controlled with a reference count,
drivers can grab additional references with
<function>drm_framebuffer_reference</function> </para> and drop them
<function>drm_framebuffer_reference</function>and drop them
again with <function>drm_framebuffer_unreference</function>. For
driver-private framebuffers for which the last reference is never
dropped (e.g. for the fbdev framebuffer when the struct
@ -1050,6 +1068,72 @@ int max_width, max_height;</synopsis>
helper struct) drivers can manually clean up a framebuffer at module
unload time with
<function>drm_framebuffer_unregister_private</function>.
</para>
</sect2>
<sect2>
<title>Dumb Buffer Objects</title>
<para>
The KMS API doesn't standardize backing storage object creation and
leaves it to driver-specific ioctls. Furthermore actually creating a
buffer object even for GEM-based drivers is done through a
driver-specific ioctl - GEM only has a common userspace interface for
sharing and destroying objects. While not an issue for full-fledged
graphics stacks that include device-specific userspace components (in
libdrm for instance), this limit makes DRM-based early boot graphics
unnecessarily complex.
</para>
<para>
Dumb objects partly alleviate the problem by providing a standard
API to create dumb buffers suitable for scanout, which can then be used
to create KMS frame buffers.
</para>
<para>
To support dumb objects drivers must implement the
<methodname>dumb_create</methodname>,
<methodname>dumb_destroy</methodname> and
<methodname>dumb_map_offset</methodname> operations.
</para>
<itemizedlist>
<listitem>
<synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev,
struct drm_mode_create_dumb *args);</synopsis>
<para>
The <methodname>dumb_create</methodname> operation creates a driver
object (GEM or TTM handle) suitable for scanout based on the
width, height and depth from the struct
<structname>drm_mode_create_dumb</structname> argument. It fills the
argument's <structfield>handle</structfield>,
<structfield>pitch</structfield> and <structfield>size</structfield>
fields with a handle for the newly created object and its line
pitch and size in bytes.
</para>
</listitem>
<listitem>
<synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev,
uint32_t handle);</synopsis>
<para>
The <methodname>dumb_destroy</methodname> operation destroys a dumb
object created by <methodname>dumb_create</methodname>.
</para>
</listitem>
<listitem>
<synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev,
uint32_t handle, uint64_t *offset);</synopsis>
<para>
The <methodname>dumb_map_offset</methodname> operation associates an
mmap fake offset with the object given by the handle and returns
it. Drivers must use the
<function>drm_gem_create_mmap_offset</function> function to
associate the fake offset as described in
<xref linkend="drm-gem-objects-mapping"/>.
</para>
</listitem>
</itemizedlist>
<para>
Note that dumb objects may not be used for gpu acceleration, as has been
attempted on some ARM embedded platforms. Such drivers really must have
a hardware-specific ioctl to allocate suitable buffer objects.
</para>
</sect2>
<sect2>
<title>Output Polling</title>
@ -1110,7 +1194,7 @@ int max_width, max_height;</synopsis>
pointer to CRTC functions.
</para>
</sect3>
<sect3>
<sect3 id="drm-kms-crtcops">
<title>CRTC Operations</title>
<sect4>
<title>Set Configuration</title>
@ -1130,8 +1214,11 @@ int max_width, max_height;</synopsis>
This operation is called with the mode config lock held.
</para>
<note><para>
FIXME: How should set_config interact with DPMS? If the CRTC is
suspended, should it be resumed?
Note that the drm core has no notion of restoring the mode setting
state after resume, since all resume handling is in the full
responsibility of the driver. The common mode setting helper library
though provides a helper which can be used for this:
<function>drm_helper_resume_force_mode</function>.
</para></note>
</sect4>
<sect4>
@ -1248,15 +1335,47 @@ int max_width, max_height;</synopsis>
optionally scale it to a destination size. The result is then blended
with or overlayed on top of a CRTC.
</para>
<para>
The DRM core recognizes three types of planes:
<itemizedlist>
<listitem>
DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC. Primary
planes are the planes operated upon by by CRTC modesetting and flipping
operations described in <xref linkend="drm-kms-crtcops"/>.
</listitem>
<listitem>
DRM_PLANE_TYPE_CURSOR represents a "cursor" plane for a CRTC. Cursor
planes are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and
DRM_IOCTL_MODE_CURSOR2 ioctls.
</listitem>
<listitem>
DRM_PLANE_TYPE_OVERLAY represents all non-primary, non-cursor planes.
Some drivers refer to these types of planes as "sprites" internally.
</listitem>
</itemizedlist>
For compatibility with legacy userspace, only overlay planes are made
available to userspace by default. Userspace clients may set the
DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that
they wish to receive a universal plane list containing all plane types.
</para>
<sect3>
<title>Plane Initialization</title>
<para>
Planes are optional. To create a plane, a KMS drivers allocates and
To create a plane, a KMS drivers allocates and
zeroes an instances of struct <structname>drm_plane</structname>
(possibly as part of a larger structure) and registers it with a call
to <function>drm_plane_init</function>. The function takes a bitmask
to <function>drm_universal_plane_init</function>. The function takes a bitmask
of the CRTCs that can be associated with the plane, a pointer to the
plane functions and a list of format supported formats.
plane functions, a list of format supported formats, and the type of
plane (primary, cursor, or overlay) being initialized.
</para>
<para>
Cursor and overlay planes are optional. All drivers should provide
one primary plane per CRTC (although this requirement may change in
the future); drivers that do not wish to provide special handling for
primary planes may make use of the helper functions described in
<xref linkend="drm-kms-planehelpers"/> to create and register a
primary plane with standard capabilities.
</para>
</sect3>
<sect3>
@ -1687,7 +1806,7 @@ void intel_crt_init(struct drm_device *dev)
<sect1>
<title>Mode Setting Helper Functions</title>
<para>
The CRTC, encoder and connector functions provided by the drivers
The plane, CRTC, encoder and connector functions provided by the drivers
implement the DRM API. They're called by the DRM core and ioctl handlers
to handle device state changes and configuration request. As implementing
those functions often requires logic not specific to drivers, mid-layer
@ -1695,8 +1814,8 @@ void intel_crt_init(struct drm_device *dev)
</para>
<para>
The DRM core contains one mid-layer implementation. The mid-layer provides
implementations of several CRTC, encoder and connector functions (called
from the top of the mid-layer) that pre-process requests and call
implementations of several plane, CRTC, encoder and connector functions
(called from the top of the mid-layer) that pre-process requests and call
lower-level functions provided by the driver (at the bottom of the
mid-layer). For instance, the
<function>drm_crtc_helper_set_config</function> function can be used to
@ -2134,7 +2253,7 @@ void intel_crt_init(struct drm_device *dev)
set the <structfield>display_info</structfield>
<structfield>width_mm</structfield> and
<structfield>height_mm</structfield> fields if they haven't been set
already (for instance at initilization time when a fixed-size panel is
already (for instance at initialization time when a fixed-size panel is
attached to the connector). The mode <structfield>width_mm</structfield>
and <structfield>height_mm</structfield> fields are only used internally
during EDID parsing and should not be set when creating modes manually.
@ -2196,10 +2315,19 @@ void intel_crt_init(struct drm_device *dev)
!Edrivers/gpu/drm/drm_flip_work.c
</sect2>
<sect2>
<title>VMA Offset Manager</title>
!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager
!Edrivers/gpu/drm/drm_vma_manager.c
!Iinclude/drm/drm_vma_manager.h
<title>HDMI Infoframes Helper Reference</title>
<para>
Strictly speaking this is not a DRM helper library but generally useable
by any driver interfacing with HDMI outputs like v4l or alsa drivers.
But it nicely fits into the overall topic of mode setting helper
libraries and hence is also included here.
</para>
!Iinclude/linux/hdmi.h
!Edrivers/video/hdmi.c
</sect2>
<sect2>
<title id="drm-kms-planehelpers">Plane Helper Reference</title>
!Edrivers/gpu/drm/drm_plane_helper.c Plane Helpers
</sect2>
</sect1>
@ -2561,42 +2689,44 @@ int num_ioctls;</synopsis>
</para>
</sect2>
</sect1>
<sect1>
<title>Command submission &amp; fencing</title>
<title>Legacy Support Code</title>
<para>
This should cover a few device-specific command submission
implementations.
The section very brievely covers some of the old legacy support code which
is only used by old DRM drivers which have done a so-called shadow-attach
to the underlying device instead of registering as a real driver. This
also includes some of the old generic buffer mangement and command
submission code. Do not use any of this in new and modern drivers.
</para>
</sect1>
<!-- Internals: suspend/resume -->
<sect2>
<title>Legacy Suspend/Resume</title>
<para>
The DRM core provides some suspend/resume code, but drivers wanting full
suspend/resume support should provide save() and restore() functions.
These are called at suspend, hibernate, or resume time, and should perform
any state save or restore required by your device across suspend or
hibernate states.
</para>
<synopsis>int (*suspend) (struct drm_device *, pm_message_t state);
int (*resume) (struct drm_device *);</synopsis>
<para>
Those are legacy suspend and resume methods which
<emphasis>only</emphasis> work with the legacy shadow-attach driver
registration functions. New driver should use the power management
interface provided by their bus type (usually through
the struct <structname>device_driver</structname> dev_pm_ops) and set
these methods to NULL.
</para>
</sect2>
<sect1>
<title>Suspend/Resume</title>
<para>
The DRM core provides some suspend/resume code, but drivers wanting full
suspend/resume support should provide save() and restore() functions.
These are called at suspend, hibernate, or resume time, and should perform
any state save or restore required by your device across suspend or
hibernate states.
</para>
<synopsis>int (*suspend) (struct drm_device *, pm_message_t state);
int (*resume) (struct drm_device *);</synopsis>
<para>
Those are legacy suspend and resume methods. New driver should use the
power management interface provided by their bus type (usually through
the struct <structname>device_driver</structname> dev_pm_ops) and set
these methods to NULL.
</para>
</sect1>
<sect1>
<title>DMA services</title>
<para>
This should cover how DMA mapping etc. is supported by the core.
These functions are deprecated and should not be used.
</para>
<sect2>
<title>Legacy DMA Services</title>
<para>
This should cover how DMA mapping etc. is supported by the core.
These functions are deprecated and should not be used.
</para>
</sect2>
</sect1>
</chapter>
@ -2658,8 +2788,8 @@ int (*resume) (struct drm_device *);</synopsis>
DRM core provides multiple character-devices for user-space to use.
Depending on which device is opened, user-space can perform a different
set of operations (mainly ioctls). The primary node is always created
and called <term>card&lt;num&gt;</term>. Additionally, a currently
unused control node, called <term>controlD&lt;num&gt;</term> is also
and called card&lt;num&gt;. Additionally, a currently
unused control node, called controlD&lt;num&gt; is also
created. The primary node provides all legacy operations and
historically was the only interface used by userspace. With KMS, the
control node was introduced. However, the planned KMS control interface
@ -2674,21 +2804,21 @@ int (*resume) (struct drm_device *);</synopsis>
nodes were introduced. Render nodes solely serve render clients, that
is, no modesetting or privileged ioctls can be issued on render nodes.
Only non-global rendering commands are allowed. If a driver supports
render nodes, it must advertise it via the <term>DRIVER_RENDER</term>
render nodes, it must advertise it via the DRIVER_RENDER
DRM driver capability. If not supported, the primary node must be used
for render clients together with the legacy drmAuth authentication
procedure.
</para>
<para>
If a driver advertises render node support, DRM core will create a
separate render node called <term>renderD&lt;num&gt;</term>. There will
separate render node called renderD&lt;num&gt;. There will
be one render node per device. No ioctls except PRIME-related ioctls
will be allowed on this node. Especially <term>GEM_OPEN</term> will be
will be allowed on this node. Especially GEM_OPEN will be
explicitly prohibited. Render nodes are designed to avoid the
buffer-leaks, which occur if clients guess the flink names or mmap
offsets on the legacy interface. Additionally to this basic interface,
drivers must mark their driver-dependent render-only ioctls as
<term>DRM_RENDER_ALLOW</term> so render clients can use them. Driver
DRM_RENDER_ALLOW so render clients can use them. Driver
authors must be careful not to allow any privileged ioctls on render
nodes.
</para>
@ -2749,15 +2879,73 @@ int (*resume) (struct drm_device *);</synopsis>
</sect1>
</chapter>
</part>
<part id="drmDrivers">
<title>DRM Drivers</title>
<!-- API reference -->
<appendix id="drmDriverApi">
<title>DRM Driver API</title>
<partintro>
<para>
Include auto-generated API reference here (need to reference it
from paragraphs above too).
This second part of the DRM Developer's Guide documents driver code,
implementation details and also all the driver-specific userspace
interfaces. Especially since all hardware-acceleration interfaces to
userspace are driver specific for efficiency and other reasons these
interfaces can be rather substantial. Hence every driver has its own
chapter.
</para>
</appendix>
</partintro>
<chapter id="drmI915">
<title>drm/i915 Intel GFX Driver</title>
<para>
The drm/i915 driver supports all (with the exception of some very early
models) integrated GFX chipsets with both Intel display and rendering
blocks. This excludes a set of SoC platforms with an SGX rendering unit,
those have basic support through the gma500 drm driver.
</para>
<sect1>
<title>Display Hardware Handling</title>
<para>
This section covers everything related to the display hardware including
the mode setting infrastructure, plane, sprite and cursor handling and
display, output probing and related topics.
</para>
<sect2>
<title>Mode Setting Infrastructure</title>
<para>
The i915 driver is thus far the only DRM driver which doesn't use the
common DRM helper code to implement mode setting sequences. Thus it
has its own tailor-made infrastructure for executing a display
configuration change.
</para>
</sect2>
<sect2>
<title>Plane Configuration</title>
<para>
This section covers plane configuration and composition with the
primary plane, sprites, cursors and overlays. This includes the
infrastructure to do atomic vsync'ed updates of all this state and
also tightly coupled topics like watermark setup and computation,
framebuffer compression and panel self refresh.
</para>
</sect2>
<sect2>
<title>Output Probing</title>
<para>
This section covers output probing and related infrastructure like the
hotplug interrupt storm detection and mitigation code. Note that the
i915 driver still uses most of the common DRM helper code for output
probing, so those sections fully apply.
</para>
</sect2>
</sect1>
<sect1>
<title>Memory Management and Command Submission</title>
<para>
This sections covers all things related to the GEM implementation in the
i915 driver.
</para>
</sect1>
</chapter>
</part>
</book>

12
Documentation/DocBook/kernel-hacking.tmpl
View File

@ -671,7 +671,7 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<sect1 id="routines-local-irqs">
<title><function>local_irq_save()</function>/<function>local_irq_restore()</function>
<filename class="headerfile">include/asm/system.h</filename>
<filename class="headerfile">include/linux/irqflags.h</filename>
</title>
<para>
@ -850,16 +850,6 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<returnvalue>-ERESTARTSYS</returnvalue> if a signal is received.
The <function>wait_event()</function> version ignores signals.
</para>
<para>
Do not use the <function>sleep_on()</function> function family -
it is very easy to accidentally introduce races; almost certainly
one of the <function>wait_event()</function> family will do, or a
loop around <function>schedule_timeout()</function>. If you choose
to loop around <function>schedule_timeout()</function> remember
you must set the task state (with
<function>set_current_state()</function>) on each iteration to avoid
busy-looping.
</para>
</sect1>

10
Documentation/arm64/booting.txt
View File

@ -111,8 +111,14 @@ Before jumping into the kernel, the following conditions must be met:
- Caches, MMUs
The MMU must be off.
Instruction cache may be on or off.
Data cache must be off and invalidated.
External caches (if present) must be configured and disabled.
The address range corresponding to the loaded kernel image must be
cleaned to the PoC. In the presence of a system cache or other
coherent masters with caches enabled, this will typically require
cache maintenance by VA rather than set/way operations.
System caches which respect the architected cache maintenance by VA
operations must be configured and may be enabled.
System caches which do not respect architected cache maintenance by VA
operations (not recommended) must be configured and disabled.
- Architected timers
CNTFRQ must be programmed with the timer frequency and CNTVOFF must

4
Documentation/arm64/memory.txt
View File

@ -39,7 +39,7 @@ ffffffbffa000000 ffffffbffaffffff 16MB PCI I/O space
ffffffbffb000000 ffffffbffbbfffff 12MB [guard]
ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device
ffffffbffbc00000 ffffffbffbdfffff 2MB fixed mappings
ffffffbffbe00000 ffffffbffbffffff 2MB [guard]
@ -66,7 +66,7 @@ fffffdfffa000000 fffffdfffaffffff 16MB PCI I/O space
fffffdfffb000000 fffffdfffbbfffff 12MB [guard]
fffffdfffbc00000 fffffdfffbdfffff 2MB earlyprintk device
fffffdfffbc00000 fffffdfffbdfffff 2MB fixed mappings
fffffdfffbe00000 fffffdfffbffffff 2MB [guard]

54
Documentation/blockdev/zram.txt
View File

@ -21,7 +21,43 @@ Following shows a typical sequence of steps for using zram.
This creates 4 devices: /dev/zram{0,1,2,3}
(num_devices parameter is optional. Default: 1)
2) Set Disksize
2) Set max number of compression streams
Compression backend may use up to max_comp_streams compression streams,
thus allowing up to max_comp_streams concurrent compression operations.
By default, compression backend uses single compression stream.
Examples:
#show max compression streams number
cat /sys/block/zram0/max_comp_streams
#set max compression streams number to 3
echo 3 > /sys/block/zram0/max_comp_streams
Note:
In order to enable compression backend's multi stream support max_comp_streams
must be initially set to desired concurrency level before ZRAM device
initialisation. Once the device initialised as a single stream compression
backend (max_comp_streams equals to 1), you will see error if you try to change
the value of max_comp_streams because single stream compression backend
implemented as a special case by lock overhead issue and does not support
dynamic max_comp_streams. Only multi stream backend supports dynamic
max_comp_streams adjustment.
3) Select compression algorithm
Using comp_algorithm device attribute one can see available and
currently selected (shown in square brackets) compression algortithms,
change selected compression algorithm (once the device is initialised
there is no way to change compression algorithm).
Examples:
#show supported compression algorithms
cat /sys/block/zram0/comp_algorithm
lzo [lz4]
#select lzo compression algorithm
echo lzo > /sys/block/zram0/comp_algorithm
4) Set Disksize
Set disk size by writing the value to sysfs node 'disksize'.
The value can be either in bytes or you can use mem suffixes.
Examples:
@ -33,32 +69,38 @@ Following shows a typical sequence of steps for using zram.
echo 512M > /sys/block/zram0/disksize
echo 1G > /sys/block/zram0/disksize
3) Activate:
Note:
There is little point creating a zram of greater than twice the size of memory
since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the
size of the disk when not in use so a huge zram is wasteful.
5) Activate:
mkswap /dev/zram0
swapon /dev/zram0
mkfs.ext4 /dev/zram1
mount /dev/zram1 /tmp
4) Stats:
6) Stats:
Per-device statistics are exported as various nodes under
/sys/block/zram<id>/
disksize
num_reads
num_writes
failed_reads
failed_writes
invalid_io
notify_free
discard
zero_pages
orig_data_size
compr_data_size
mem_used_total
5) Deactivate:
7) Deactivate:
swapoff /dev/zram0
umount /dev/zram1
6) Reset:
8) Reset:
Write any positive value to 'reset' sysfs node
echo 1 > /sys/block/zram0/reset
echo 1 > /sys/block/zram1/reset

4
Documentation/cgroups/memcg_test.txt
View File

@ -24,7 +24,7 @@ Please note that implementation details can be changed.
a page/swp_entry may be charged (usage += PAGE_SIZE) at
mem_cgroup_newpage_charge()
mem_cgroup_charge_anon()
Called at new page fault and Copy-On-Write.
mem_cgroup_try_charge_swapin()
@ -32,7 +32,7 @@ Please note that implementation details can be changed.
Followed by charge-commit-cancel protocol. (With swap accounting)
At commit, a charge recorded in swap_cgroup is removed.
mem_cgroup_cache_charge()
mem_cgroup_charge_file()
Called at add_to_page_cache()
mem_cgroup_cache_charge_swapin()

12
Documentation/cgroups/resource_counter.txt
View File

@ -76,15 +76,7 @@ to work with it.
limit_fail_at parameter is set to the particular res_counter element
where the charging failed.
d. int res_counter_charge_locked
(struct res_counter *rc, unsigned long val, bool force)
The same as res_counter_charge(), but it must not acquire/release the
res_counter->lock internally (it must be called with res_counter->lock
held). The force parameter indicates whether we can bypass the limit.
e. u64 res_counter_uncharge[_locked]
(struct res_counter *rc, unsigned long val)
d. u64 res_counter_uncharge(struct res_counter *rc, unsigned long val)
When a resource is released (freed) it should be de-accounted
from the resource counter it was accounted to. This is called
@ -93,7 +85,7 @@ to work with it.
The _locked routines imply that the res_counter->lock is taken.
f. u64 res_counter_uncharge_until
e. u64 res_counter_uncharge_until
(struct res_counter *rc, struct res_counter *top,
unsigned long val)

45
Documentation/cpu-hotplug.txt
View File

@ -312,12 +312,57 @@ things will happen if a notifier in path sent a BAD notify code.
Q: I don't see my action being called for all CPUs already up and running?
A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined.
If you need to perform some action for each cpu already in the system, then
do this:
for_each_online_cpu(i) {
foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i);
foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i);
}
However, if you want to register a hotplug callback, as well as perform
some initialization for CPUs that are already online, then do this:
Version 1: (Correct)
---------
cpu_notifier_register_begin();
for_each_online_cpu(i) {
foobar_cpu_callback(&foobar_cpu_notifier,
CPU_UP_PREPARE, i);
foobar_cpu_callback(&foobar_cpu_notifier,
CPU_ONLINE, i);
}
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(&foobar_cpu_notifier);
cpu_notifier_register_done();
Note that the following code is *NOT* the right way to achieve this,
because it is prone to an ABBA deadlock between the cpu_add_remove_lock
and the cpu_hotplug.lock.
Version 2: (Wrong!)
---------
get_online_cpus();
for_each_online_cpu(i) {
foobar_cpu_callback(&foobar_cpu_notifier,
CPU_UP_PREPARE, i);
foobar_cpu_callback(&foobar_cpu_notifier,
CPU_ONLINE, i);
}
register_cpu_notifier(&foobar_cpu_notifier);
put_online_cpus();
So always use the first version shown above when you want to register
callbacks as well as initialize the already online CPUs.
Q: If i would like to develop cpu hotplug support for a new architecture,
what do i need at a minimum?
A: The following are what is required for CPU hotplug infrastructure to work

7
Documentation/devicetree/bindings/arm/topology.txt
View File

@ -75,9 +75,10 @@ The cpu-map node can only contain three types of child nodes:
whose bindings are described in paragraph 3.
The nodes describing the CPU topology (cluster/core/thread) can only be
defined within the cpu-map node.
Any other configuration is consider invalid and therefore must be ignored.
The nodes describing the CPU topology (cluster/core/thread) can only
be defined within the cpu-map node and every core/thread in the system
must be defined within the topology. Any other configuration is
invalid and therefore must be ignored.
===========================================
2.1 - cpu-map child nodes naming convention

76
Documentation/devicetree/bindings/dma/fsl-edma.txt 100644
View File

@ -0,0 +1,76 @@
* Freescale enhanced Direct Memory Access(eDMA) Controller
The eDMA channels have multiplex capability by programmble memory-mapped
registers. channels are split into two groups, called DMAMUX0 and DMAMUX1,
specific DMA request source can only be multiplexed by any channel of certain
group, DMAMUX0 or DMAMUX1, but not both.
* eDMA Controller
Required properties:
- compatible :
- "fsl,vf610-edma" for eDMA used similar to that on Vybrid vf610 SoC
- reg : Specifies base physical address(s) and size of the eDMA registers.
The 1st region is eDMA control register's address and size.
The 2nd and the 3rd regions are programmable channel multiplexing
control register's address and size.
- interrupts : A list of interrupt-specifiers, one for each entry in
interrupt-names.
- interrupt-names : Should contain:
"edma-tx" - the transmission interrupt
"edma-err" - the error interrupt
- #dma-cells : Must be <2>.
The 1st cell specifies the DMAMUX(0 for DMAMUX0 and 1 for DMAMUX1).
Specific request source can only be multiplexed by specific channels
group called DMAMUX.
The 2nd cell specifies the request source(slot) ID.
See the SoC's reference manual for all the supported request sources.
- dma-channels : Number of channels supported by the controller
- clock-names : A list of channel group clock names. Should contain:
"dmamux0" - clock name of mux0 group
"dmamux1" - clock name of mux1 group
- clocks : A list of phandle and clock-specifier pairs, one for each entry in
clock-names.
Optional properties:
- big-endian: If present registers and hardware scatter/gather descriptors
of the eDMA are implemented in big endian mode, otherwise in little
mode.
Examples:
edma0: dma-controller@40018000 {
#dma-cells = <2>;
compatible = "fsl,vf610-edma";
reg = <0x40018000 0x2000>,
<0x40024000 0x1000>,
<0x40025000 0x1000>;
interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>,
<0 9 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "edma-tx", "edma-err";
dma-channels = <32>;
clock-names = "dmamux0", "dmamux1";
clocks = <&clks VF610_CLK_DMAMUX0>,
<&clks VF610_CLK_DMAMUX1>;
};
* DMA clients
DMA client drivers that uses the DMA function must use the format described
in the dma.txt file, using a two-cell specifier for each channel: the 1st
specifies the channel group(DMAMUX) in which this request can be multiplexed,
and the 2nd specifies the request source.
Examples:
sai2: sai@40031000 {
compatible = "fsl,vf610-sai";
reg = <0x40031000 0x1000>;
interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "sai";
clocks = <&clks VF610_CLK_SAI2>;
dma-names = "tx", "rx";
dmas = <&edma0 0 21>,
<&edma0 0 20>;
status = "disabled";
};

41
Documentation/devicetree/bindings/dma/qcom_bam_dma.txt 100644
View File

@ -0,0 +1,41 @@
QCOM BAM DMA controller
Required properties:
- compatible: must contain "qcom,bam-v1.4.0" for MSM8974
- reg: Address range for DMA registers
- interrupts: Should contain the one interrupt shared by all channels
- #dma-cells: must be <1>, the cell in the dmas property of the client device
represents the channel number
- clocks: required clock
- clock-names: must contain "bam_clk" entry
- qcom,ee : indicates the active Execution Environment identifier (0-7) used in
the secure world.
Example:
uart-bam: dma@f9984000 = {
compatible = "qcom,bam-v1.4.0";
reg = <0xf9984000 0x15000>;
interrupts = <0 94 0>;
clocks = <&gcc GCC_BAM_DMA_AHB_CLK>;
clock-names = "bam_clk";
#dma-cells = <1>;
qcom,ee = <0>;
};
DMA clients must use the format described in the dma.txt file, using a two cell
specifier for each channel.
Example:
serial@f991e000 {
compatible = "qcom,msm-uart";
reg = <0xf991e000 0x1000>
<0xf9944000 0x19000>;
interrupts = <0 108 0>;
clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>,
<&gcc GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
dmas = <&uart-bam 0>, <&uart-bam 1>;
dma-names = "rx", "tx";
};

43
Documentation/devicetree/bindings/dma/sirfsoc-dma.txt 100644
View File

@ -0,0 +1,43 @@
* CSR SiRFSoC DMA controller
See dma.txt first
Required properties:
- compatible: Should be "sirf,prima2-dmac" or "sirf,marco-dmac"
- reg: Should contain DMA registers location and length.
- interrupts: Should contain one interrupt shared by all channel
- #dma-cells: must be <1>. used to represent the number of integer
cells in the dmas property of client device.
- clocks: clock required
Example:
Controller:
dmac0: dma-controller@b00b0000 {
compatible = "sirf,prima2-dmac";
reg = <0xb00b0000 0x10000>;
interrupts = <12>;
clocks = <&clks 24>;
#dma-cells = <1>;
};
Client:
Fill the specific dma request line in dmas. In the below example, spi0 read
channel request line is 9 of the 2nd dma controller, while write channel uses
4 of the 2nd dma controller; spi1 read channel request line is 12 of the 1st
dma controller, while write channel uses 13 of the 1st dma controller:
spi0: spi@b00d0000 {
compatible = "sirf,prima2-spi";
dmas = <&dmac1 9>,
<&dmac1 4>;
dma-names = "rx", "tx";
};
spi1: spi@b0170000 {
compatible = "sirf,prima2-spi";
dmas = <&dmac0 12>,
<&dmac0 13>;
dma-names = "rx", "tx";
};

27
Documentation/devicetree/bindings/drm/bridge/ptn3460.txt 100644
View File

@ -0,0 +1,27 @@
ptn3460 bridge bindings
Required properties:
- compatible: "nxp,ptn3460"
- reg: i2c address of the bridge
- powerdown-gpio: OF device-tree gpio specification
- reset-gpio: OF device-tree gpio specification
- edid-emulation: The EDID emulation entry to use
+-------+------------+------------------+
| Value | Resolution | Description |
| 0 | 1024x768 | NXP Generic |
| 1 | 1920x1080 | NXP Generic |
| 2 | 1920x1080 | NXP Generic |
| 3 | 1600x900 | Samsung LTM200KT |
| 4 | 1920x1080 | Samsung LTM230HT |
| 5 | 1366x768 | NXP Generic |
| 6 | 1600x900 | ChiMei M215HGE |
+-------+------------+------------------+
Example:
lvds-bridge@20 {
compatible = "nxp,ptn3460";
reg = <0x20>;
powerdown-gpio = <&gpy2 5 1 0 0>;
reset-gpio = <&gpx1 5 1 0 0>;
edid-emulation = <5>;
};

27
Documentation/devicetree/bindings/drm/i2c/tda998x.txt 100644
View File

@ -0,0 +1,27 @@
Device-Tree bindings for the NXP TDA998x HDMI transmitter
Required properties;
- compatible: must be "nxp,tda998x"
Optional properties:
- interrupts: interrupt number and trigger type
default: polling
- pinctrl-0: pin control group to be used for
screen plug/unplug interrupt.
- pinctrl-names: must contain a "default" entry.
- video-ports: 24 bits value which defines how the video controller
output is wired to the TDA998x input - default: <0x230145>
Example:
tda998x: hdmi-encoder {
compatible = "nxp,tda998x";
reg = <0x70>;
interrupt-parent = <&gpio0>;
interrupts = <27 2>; /* falling edge */
pinctrl-0 = <&pmx_camera>;
pinctrl-names = "default";
};

42
Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
View File

@ -190,6 +190,48 @@ of the following host1x client modules:
- nvidia,edid: supplies a binary EDID blob
- nvidia,panel: phandle of a display panel
- sor: serial output resource
Required properties:
- compatible: "nvidia,tegra124-sor"
- 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.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- sor: clock input for the SOR hardware
- parent: input for the pixel clock
- dp: reference clock for the SOR clock
- safe: safe reference for the SOR clock during power up
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- sor
Optional properties:
- nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
- nvidia,edid: supplies a binary EDID blob
- nvidia,panel: phandle of a display panel
Optional properties when driving an eDP output:
- nvidia,dpaux: phandle to a DispayPort AUX interface
- dpaux: DisplayPort AUX interface
- compatible: "nvidia,tegra124-dpaux"
- 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.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- dpaux: clock input for the DPAUX hardware
- parent: reference clock
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- dpaux
- vdd-supply: phandle of a supply that powers the DisplayPort link
Example:
/ {

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

@ -12,6 +12,7 @@ Required properties :
- clocks: phandles to input clocks.
Optional properties:
- clock-frequency: Desired I2C bus frequency in Hz, otherwise defaults to 100000
- Child nodes conforming to i2c bus binding
Examples :
@ -23,6 +24,7 @@ i2c0: i2c@fff84000 {
#address-cells = <1>;
#size-cells = <0>;
clocks = <&twi0_clk>;
clock-frequency = <400000>;
24c512@50 {
compatible = "24c512";

24
Documentation/devicetree/bindings/i2c/i2c-cadence.txt 100644
View File

@ -0,0 +1,24 @@
Binding for the Cadence I2C controller
Required properties:
- reg: Physical base address and size of the controller's register area.
- compatible: Compatibility string. Must be 'cdns,i2c-r1p10'.
- clocks: Input clock specifier. Refer to common clock bindings.
- interrupts: Interrupt specifier. Refer to interrupt bindings.
- #address-cells: Should be 1.
- #size-cells: Should be 0.
Optional properties:
- clock-frequency: Desired operating frequency, in Hz, of the bus.
- clock-names: Input clock name, should be 'pclk'.
Example:
i2c@e0004000 {
compatible = "cdns,i2c-r1p10";
clocks = <&clkc 38>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
reg = <0xe0004000 0x1000>;
clock-frequency = <400000>;
#address-cells = <1>;
#size-cells = <0>;
};

8
Documentation/devicetree/bindings/i2c/i2c-designware.txt
View File

@ -14,6 +14,12 @@ Optional properties :
- i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds.
This option is only supported in hardware blocks version 1.11a or newer.
- i2c-scl-falling-time : should contain the SCL falling time in nanoseconds.
This value which is by default 300ns is used to compute the tLOW period.
- i2c-sda-falling-time : should contain the SDA falling time in nanoseconds.
This value which is by default 300ns is used to compute the tHIGH period.
Example :
i2c@f0000 {
@ -34,4 +40,6 @@ Example :
interrupts = <12 1>;
clock-frequency = <400000>;
i2c-sda-hold-time-ns = <300>;
i2c-sda-falling-time-ns = <300>;
i2c-scl-falling-time-ns = <300>;
};

34
Documentation/devicetree/bindings/i2c/i2c-efm32.txt 100644
View File

@ -0,0 +1,34 @@
* Energymicro efm32 i2c controller
Required properties :
- reg : Offset and length of the register set for the device
- compatible : should be "energymicro,efm32-i2c"
- interrupts : the interrupt number
- clocks : reference to the module clock
Recommended properties :
- clock-frequency : maximal I2C bus clock frequency in Hz.
- efm32,location : Decides the location of the USART I/O pins.
Allowed range : [0 .. 6]
Example:
i2c0: i2c@4000a000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "energymicro,efm32-i2c";
reg = <0x4000a000 0x400>;
interrupts = <9>;
clocks = <&cmu clk_HFPERCLKI2C0>;
clock-frequency = <100000>;
status = "ok";
efm32,location = <3>;
eeprom@50 {
compatible = "microchip,24c02";
reg = <0x50>;
pagesize = <16>;
};
};

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

@ -4,12 +4,16 @@
Required properties :
- reg : Offset and length of the register set for the device
- compatible : Should be "marvell,mv64xxx-i2c" or "allwinner,sun4i-i2c"
or "marvell,mv78230-i2c" or "marvell,mv78230-a0-i2c"
Note: Only use "marvell,mv78230-a0-i2c" for a very rare,
initial version of the SoC which had broken offload
support. Linux auto-detects this and sets it
appropriately.
- compatible : Should be either:
- "allwinner,sun4i-i2c"
- "allwinner,sun6i-a31-i2c"
- "marvell,mv64xxx-i2c"
- "marvell,mv78230-i2c"
- "marvell,mv78230-a0-i2c"
* Note: Only use "marvell,mv78230-a0-i2c" for a
very rare, initial version of the SoC which
had broken offload support. Linux
auto-detects this and sets it appropriately.
- interrupts : The interrupt number
Optional properties :
@ -17,6 +21,10 @@ Optional properties :
- clock-frequency : Desired I2C bus clock frequency in Hz. If not set the
default frequency is 100kHz
- resets : phandle to the parent reset controller. Mandatory
whenever you're using the "allwinner,sun6i-a31-i2c"
compatible.
Examples:
i2c@11000 {

14
Documentation/devicetree/bindings/i2c/i2c-rcar.txt
View File

@ -6,6 +6,7 @@ Required properties:
"renesas,i2c-r8a7778"
"renesas,i2c-r8a7779"
"renesas,i2c-r8a7790"
"renesas,i2c-r8a7791"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt specifier.
@ -13,11 +14,16 @@ Required properties:
Optional properties:
- clock-frequency: desired I2C bus clock frequency in Hz. The absence of this
propoerty indicates the default frequency 100 kHz.
- clocks: clock specifier.
Examples :
i2c0: i2c@e6500000 {
compatible = "renesas,i2c-rcar-h2";
reg = <0 0xe6500000 0 0x428>;
interrupts = <0 174 0x4>;
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "renesas,i2c-r8a7791";
reg = <0 0xe6508000 0 0x40>;
interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
clock-frequency = <400000>;
};

40
Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt 100644
View File

@ -0,0 +1,40 @@
Qualcomm Universal Peripheral (QUP) I2C controller
Required properties:
- compatible: Should be:
* "qcom,i2c-qup-v1.1.1" for 8660, 8960 and 8064.
* "qcom,i2c-qup-v2.1.1" for 8974 v1.
* "qcom,i2c-qup-v2.2.1" for 8974 v2 and later.
- reg: Should contain QUP register address and length.
- interrupts: Should contain I2C interrupt.
- clocks: A list of phandles + clock-specifiers, one for each entry in
clock-names.
- clock-names: Should contain:
* "core" for the core clock
* "iface" for the AHB clock
- #address-cells: Should be <1> Address cells for i2c device address
- #size-cells: Should be <0> as i2c addresses have no size component
Optional properties:
- clock-frequency: Should specify the desired i2c bus clock frequency in Hz,
defaults to 100kHz if omitted.
Child nodes should conform to i2c bus binding.
Example:
i2c@f9924000 {
compatible = "qcom,i2c-qup-v2.2.1";
reg = <0xf9924000 0x1000>;
interrupts = <0 96 0>;
clocks = <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
clock-frequency = <355000>;
#address-cells = <1>;
#size-cells = <0>;
};

24
Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt 100644
View File

@ -0,0 +1,24 @@
* TWL4030 Monitoring Analog to Digital Converter (MADC)
The MADC subsystem in the TWL4030 consists of a 10-bit ADC
combined with a 16-input analog multiplexer.
Required properties:
- compatible: Should contain "ti,twl4030-madc".
- interrupts: IRQ line for the MADC submodule.
- #io-channel-cells: Should be set to <1>.
Optional properties:
- ti,system-uses-second-madc-irq: boolean, set if the second madc irq register
should be used, which is intended to be used
by Co-Processors (e.g. a modem).
Example:
&twl {
madc {
compatible = "ti,twl4030-madc";
interrupts = <3>;
#io-channel-cells = <1>;
};
};

12
Documentation/devicetree/bindings/leds/leds-gpio.txt
View File

@ -21,6 +21,8 @@ LED sub-node properties:
on). The "keep" setting will keep the LED at whatever its current
state is, without producing a glitch. The default is off if this
property is not present.
- retain-state-suspended: (optional) The suspend state can be retained.Such
as charge-led gpio.
Examples:
@ -50,3 +52,13 @@ run-control {
default-state = "on";
};
};
leds {
compatible = "gpio-leds";
charger-led {
gpios = <&gpio1 2 0>;
linux,default-trigger = "max8903-charger-charging";
retain-state-suspended;
};
};

23
Documentation/devicetree/bindings/mfd/arizona.txt
View File

@ -5,9 +5,10 @@ of analogue I/O.
Required properties:
- compatible : one of the following chip-specific strings:
"wlf,wm5102"
"wlf,wm5110"
- compatible : One of the following chip-specific strings:
"wlf,wm5102"
"wlf,wm5110"
"wlf,wm8997"
- reg : I2C slave address when connected using I2C, chip select number when
using SPI.
@ -25,8 +26,9 @@ Required properties:
- #gpio-cells : Must be 2. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- AVDD1-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply,
SPKVDDL-supply, SPKVDDR-supply : power supplies for the device, as covered
- AVDD-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply (wm5102, wm5110),
CPVDD-supply, SPKVDDL-supply (wm5102, wm5110), SPKVDDR-supply (wm5102,
wm5110), SPKVDD-supply (wm8997) : Power supplies for the device, as covered
in Documentation/devicetree/bindings/regulator/regulator.txt
Optional properties:
@ -46,6 +48,7 @@ codec: wm5102@1a {
compatible = "wlf,wm5102";
reg = <0x1a>;
interrupts = <347>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&gic>;
@ -53,10 +56,10 @@ codec: wm5102@1a {
#gpio-cells = <2>;
wlf,gpio-defaults = <
0x00000000, /* AIF1TXLRCLK */
0xffffffff,
0xffffffff,
0xffffffff,
0xffffffff,
0x00000000 /* AIF1TXLRCLK */
0xffffffff
0xffffffff
0xffffffff
0xffffffff
>;
};

37
Documentation/devicetree/bindings/mfd/bcm590xx.txt 100644
View File

@ -0,0 +1,37 @@
-------------------------------
BCM590xx Power Management Units
-------------------------------
Required properties:
- compatible: "brcm,bcm59056"
- reg: I2C slave address
- interrupts: interrupt for the PMU. Generic interrupt client node bindings
are described in interrupt-controller/interrupts.txt
------------------
Voltage Regulators
------------------
Optional child nodes:
- regulators: container node for regulators following the generic
regulator binding in regulator/regulator.txt
The valid regulator node names for BCM59056 are:
rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo,
mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo,
csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr
Example:
pmu: bcm59056@8 {
compatible = "brcm,bcm59056";
reg = <0x08>;
interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
regulators {
rfldo_reg: rfldo {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
...
};
};

72
Documentation/devicetree/bindings/mfd/da9055.txt 100644
View File

@ -0,0 +1,72 @@
* Dialog DA9055 Power Management Integrated Circuit (PMIC)
DA9055 consists of a large and varied group of sub-devices (I2C Only):
Device Supply Names Description
------ ------------ -----------
da9055-gpio : : GPIOs
da9055-regulator : : Regulators
da9055-onkey : : On key
da9055-rtc : : RTC
da9055-hwmon : : ADC
da9055-watchdog : : Watchdog
The CODEC device in DA9055 has a separate, configurable I2C address and so
is instantiated separately from the PMIC.
For details on accompanying CODEC I2C device, see the following:
Documentation/devicetree/bindings/sound/da9055.txt
======
Required properties:
- compatible : Should be "dlg,da9055-pmic"
- reg: Specifies the I2C slave address (defaults to 0x5a but can be modified)
- interrupt-parent: Specifies the phandle of the interrupt controller to which
the IRQs from da9055 are delivered to.
- interrupts: IRQ line info for da9055 chip.
- interrupt-controller: da9055 has internal IRQs (has own IRQ domain).
- #interrupt-cells: Should be 1, is the local IRQ number for da9055.
Sub-nodes:
- regulators : Contain the regulator nodes. The DA9055 regulators are
bound using their names as listed below:
buck1 : regulator BUCK1
buck2 : regulator BUCK2
ldo1 : regulator LDO1
ldo2 : regulator LDO2
ldo3 : regulator LDO3
ldo4 : regulator LDO4
ldo5 : regulator LDO5
ldo6 : regulator LDO6
The bindings details of individual regulator device can be found in:
Documentation/devicetree/bindings/regulator/regulator.txt
Example:
pmic: da9055-pmic@5a {
compatible = "dlg,da9055-pmic";
reg = <0x5a>;
interrupt-parent = <&intc>;
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <1>;
regulators {
buck1: BUCK1 {
regulator-min-microvolt = <725000>;
regulator-max-microvolt = <2075000>;
};
buck2: BUCK2 {
regulator-min-microvolt = <925000>;
regulator-max-microvolt = <2500000>;
};
ldo1: LDO1 {
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <3300000>;
};
};
};

47
Documentation/devicetree/bindings/mfd/mc13xxx.txt
View File

@ -10,9 +10,44 @@ Optional properties:
- fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
Sub-nodes:
- leds : Contain the led nodes and initial register values in property
"led-control". Number of register depends of used IC, for MC13783 is 6,
for MC13892 is 4, for MC34708 is 1. See datasheet for bits definitions of
these registers.
- #address-cells: Must be 1.
- #size-cells: Must be 0.
Each led node should contain "reg", which used as LED ID (described below).
Optional properties "label" and "linux,default-trigger" is described in
Documentation/devicetree/bindings/leds/common.txt.
- regulators : Contain the regulator nodes. The regulators are bound using
their names as listed below with their registers and bits for enabling.
MC13783 LED IDs:
0 : Main display
1 : AUX display
2 : Keypad
3 : Red 1
4 : Green 1
5 : Blue 1
6 : Red 2
7 : Green 2
8 : Blue 2
9 : Red 3
10 : Green 3
11 : Blue 3
MC13892 LED IDs:
0 : Main display
1 : AUX display
2 : Keypad
3 : Red
4 : Green
5 : Blue
MC34708 LED IDs:
0 : Charger Red
1 : Charger Green
MC13783 regulators:
sw1a : regulator SW1A (register 24, bit 0)
sw1b : regulator SW1B (register 25, bit 0)
@ -89,6 +124,18 @@ ecspi@70010000 { /* ECSPI1 */
interrupt-parent = <&gpio0>;
interrupts = <8>;
leds {
#address-cells = <1>;
#size-cells = <0>;
led-control = <0x000 0x000 0x0e0 0x000>;
sysled {
reg = <3>;
label = "system:red:live";
linux,default-trigger = "heartbeat";
};
};
regulators {
sw1_reg: mc13892__sw1 {
regulator-min-microvolt = <600000>;

23
Documentation/devicetree/bindings/mfd/omap-usb-host.txt
View File

@ -32,6 +32,29 @@ Optional properties:
- single-ulpi-bypass: Must be present if the controller contains a single
ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
- clocks: a list of phandles and clock-specifier pairs, one for each entry in
clock-names.
- clock-names: should include:
For OMAP3
* "usbhost_120m_fck" - 120MHz Functional clock.
For OMAP4+
* "refclk_60m_int" - 60MHz internal reference clock for UTMI clock mux
* "refclk_60m_ext_p1" - 60MHz external ref. clock for Port 1's UTMI clock mux.
* "refclk_60m_ext_p2" - 60MHz external ref. clock for Port 2's UTMI clock mux
* "utmi_p1_gfclk" - Port 1 UTMI clock mux.
* "utmi_p2_gfclk" - Port 2 UTMI clock mux.
* "usb_host_hs_utmi_p1_clk" - Port 1 UTMI clock gate.
* "usb_host_hs_utmi_p2_clk" - Port 2 UTMI clock gate.
* "usb_host_hs_utmi_p3_clk" - Port 3 UTMI clock gate.
* "usb_host_hs_hsic480m_p1_clk" - Port 1 480MHz HSIC clock gate.
* "usb_host_hs_hsic480m_p2_clk" - Port 2 480MHz HSIC clock gate.
* "usb_host_hs_hsic480m_p3_clk" - Port 3 480MHz HSIC clock gate.
* "usb_host_hs_hsic60m_p1_clk" - Port 1 60MHz HSIC clock gate.
* "usb_host_hs_hsic60m_p2_clk" - Port 2 60MHz HSIC clock gate.
* "usb_host_hs_hsic60m_p3_clk" - Port 3 60MHz HSIC clock gate.
Required properties if child node exists:
- #address-cells: Must be 1

10
Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
View File

@ -7,6 +7,16 @@ Required properties:
- interrupts : should contain the TLL module's interrupt
- ti,hwmod : must contain "usb_tll_hs"
Optional properties:
- clocks: a list of phandles and clock-specifier pairs, one for each entry in
clock-names.
- clock-names: should include:
* "usb_tll_hs_usb_ch0_clk" - USB TLL channel 0 clock
* "usb_tll_hs_usb_ch1_clk" - USB TLL channel 1 clock
* "usb_tll_hs_usb_ch2_clk" - USB TLL channel 2 clock
Example:
usbhstll: usbhstll@4a062000 {

96
Documentation/devicetree/bindings/mfd/qcom,pm8xxx.txt 100644
View File

@ -0,0 +1,96 @@
Qualcomm PM8xxx PMIC multi-function devices
The PM8xxx family of Power Management ICs are used to provide regulated
voltages and other various functionality to Qualcomm SoCs.
= PROPERTIES
- compatible:
Usage: required
Value type: <string>
Definition: must be one of:
"qcom,pm8058"
"qcom,pm8921"
- #address-cells:
Usage: required
Value type: <u32>
Definition: must be 1
- #size-cells:
Usage: required
Value type: <u32>
Definition: must be 0
- interrupts:
Usage: required
Value type: <prop-encoded-array>
Definition: specifies the interrupt that indicates a subdevice
has generated an interrupt (summary interrupt). The
format of the specifier is defined by the binding document
describing the node's interrupt parent.
- #interrupt-cells:
Usage: required
Value type : <u32>
Definition: must be 2. Specifies the number of cells needed to encode
an interrupt source. The 1st cell contains the interrupt
number. The 2nd cell is the trigger type and level flags
encoded as follows:
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
- interrupt-controller:
Usage: required
Value type: <empty>
Definition: identifies this node as an interrupt controller
= SUBCOMPONENTS
The PMIC contains multiple independent functions, each described in a subnode.
The below bindings specify the set of valid subnodes.
== Real-Time Clock
- compatible:
Usage: required
Value type: <string>
Definition: must be one of:
"qcom,pm8058-rtc"
"qcom,pm8921-rtc"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: single entry specifying the base address of the RTC registers
- interrupts:
Usage: required
Value type: <prop-encoded-array>
Definition: single entry specifying the RTC's alarm interrupt
- allow-set-time:
Usage: optional
Value type: <empty>
Definition: indicates that the setting of RTC time is allowed by
the host CPU
= EXAMPLE
pmicintc: pmic@0 {
compatible = "qcom,pm8921";
interrupts = <104 8>;
#interrupt-cells = <2>;
interrupt-controller;
#address-cells = <1>;
#size-cells = <0>;
rtc@11d {
compatible = "qcom,pm8921-rtc";
reg = <0x11d>;
interrupts = <0x27 0>;
};
};

24
Documentation/devicetree/bindings/mfd/s2mps11.txt
View File

@ -16,20 +16,25 @@ Optional properties:
- interrupts: Interrupt specifiers for interrupt sources.
Optional nodes:
- clocks: s2mps11 provides three(AP/CP/BT) buffered 32.768 KHz outputs, so to
register these as clocks with common clock framework instantiate a sub-node
named "clocks". It uses the common clock binding documented in :
- clocks: s2mps11 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz
outputs, so to register these as clocks with common clock framework
instantiate a sub-node named "clocks". It uses the common clock binding
documented in :
[Documentation/devicetree/bindings/clock/clock-bindings.txt]
The s2mps14 provides two (AP/BT) buffered 32.768 KHz outputs.
- #clock-cells: should be 1.
- The following is the list of clocks generated by the controller. Each clock
is assigned an identifier and client nodes use this identifier to specify
the clock which they consume.
Clock ID
----------------------
32KhzAP 0
32KhzCP 1
32KhzBT 2
Clock ID Devices
----------------------------------------------------------
32KhzAP 0 S2MPS11, S2MPS14, S5M8767
32KhzCP 1 S2MPS11, S5M8767
32KhzBT 2 S2MPS11, S2MPS14, S5M8767
- compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps14-clk",
"samsung,s5m8767-clk"
- regulators: The regulators of s2mps11 that have to be instantiated should be
included in a sub-node named 'regulators'. Regulator nodes included in this
@ -75,7 +80,8 @@ Example:
compatible = "samsung,s2mps11-pmic";
reg = <0x66>;
s2m_osc: clocks{
s2m_osc: clocks {
compatible = "samsung,s2mps11-clk";
#clock-cells = 1;
clock-output-names = "xx", "yy", "zz";
};

9
Documentation/devicetree/bindings/mmc/mmc.txt
View File

@ -26,9 +26,18 @@ Optional properties:
this system, even if the controller claims it is.
- cap-sd-highspeed: SD high-speed timing is supported
- cap-mmc-highspeed: MMC high-speed timing is supported
- sd-uhs-sdr12: SD UHS SDR12 speed is supported
- sd-uhs-sdr25: SD UHS SDR25 speed is supported
- sd-uhs-sdr50: SD UHS SDR50 speed is supported
- sd-uhs-sdr104: SD UHS SDR104 speed is supported
- sd-uhs-ddr50: SD UHS DDR50 speed is supported
- cap-power-off-card: powering off the card is safe
- cap-sdio-irq: enable SDIO IRQ signalling on this interface
- full-pwr-cycle: full power cycle of the card is supported
- mmc-highspeed-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported
- mmc-highspeed-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported
- mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported
- mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
*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"

55
Documentation/devicetree/bindings/mmc/sdhci-msm.txt 100644
View File

@ -0,0 +1,55 @@
* Qualcomm SDHCI controller (sdhci-msm)
This file documents differences between the core properties in mmc.txt
and the properties used by the sdhci-msm driver.
Required properties:
- compatible: Should contain "qcom,sdhci-msm-v4".
- reg: Base address and length of the register in the following order:
- Host controller register map (required)
- SD Core register map (required)
- interrupts: Should contain an interrupt-specifiers for the interrupts:
- Host controller interrupt (required)
- pinctrl-names: Should contain only one value - "default".
- pinctrl-0: Should specify pin control groups used for this controller.
- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock-names.
- clock-names: Should contain the following:
"iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required)
"core" - SDC MMC clock (MCLK) (required)
"bus" - SDCC bus voter clock (optional)
Example:
sdhc_1: sdhci@f9824900 {
compatible = "qcom,sdhci-msm-v4";
reg = <0xf9824900 0x11c>, <0xf9824000 0x800>;
interrupts = <0 123 0>;
bus-width = <8>;
non-removable;
vmmc = <&pm8941_l20>;
vqmmc = <&pm8941_s3>;
pinctrl-names = "default";
pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data>;
clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
clock-names = "core", "iface";
};
sdhc_2: sdhci@f98a4900 {
compatible = "qcom,sdhci-msm-v4";
reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>;
interrupts = <0 125 0>;
bus-width = <4>;
cd-gpios = <&msmgpio 62 0x1>;
vmmc = <&pm8941_l21>;
vqmmc = <&pm8941_l13>;
pinctrl-names = "default";
pinctrl-0 = <&sdc2_clk &sdc2_cmd &sdc2_data>;
clocks = <&gcc GCC_SDCC2_APPS_CLK>, <&gcc GCC_SDCC2_AHB_CLK>;
clock-names = "core", "iface";
};

17
Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
View File

@ -4,7 +4,14 @@ This file documents differences between the core properties in mmc.txt
and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers.
Required properties:
- compatible: Should be "mrvl,pxav2-mmc" or "mrvl,pxav3-mmc".
- compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or
"marvell,armada-380-sdhci".
- reg:
* for "mrvl,pxav2-mmc" and "mrvl,pxav3-mmc", one register area for
the SDHCI registers.
* for "marvell,armada-380-sdhci", two register areas. The first one
for the SDHCI registers themselves, and the second one for the
AXI/Mbus bridge registers of the SDHCI unit.
Optional properties:
- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning.
@ -19,3 +26,11 @@ sdhci@d4280800 {
non-removable;
mrvl,clk-delay-cycles = <31>;
};
sdhci@d8000 {
compatible = "marvell,armada-380-sdhci";
reg = <0xd8000 0x1000>, <0xdc000 0x100>;
interrupts = <0 25 0x4>;
clocks = <&gateclk 17>;
mrvl,clk-delay-cycles = <0x1F>;
};

1
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
View File

@ -10,6 +10,7 @@ Required properties:
- compatible:
Should be "ti,omap2-hsmmc", for OMAP2 controllers
Should be "ti,omap3-hsmmc", for OMAP3 controllers
Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0
Should be "ti,omap4-hsmmc", for OMAP4 controllers
- ti,hwmods: Must be "mmc<n>", n is controller instance starting 1

14
Documentation/devicetree/bindings/mtd/nand.txt
View File

@ -5,3 +5,17 @@
"soft_bch".
- nand-bus-width : 8 or 16 bus width if not present 8
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
- nand-ecc-strength: integer representing the number of bits to correct
per ECC step.
- nand-ecc-step-size: integer representing the number of data bytes
that are covered by a single ECC step.
The ECC strength and ECC step size properties define the correction capability
of a controller. Together, they say a controller can correct "{strength} bit
errors per {size} bytes".
The interpretation of these parameters is implementation-defined, so not all
implementations must support all possible combinations. However, implementations
are encouraged to further specify the value(s) they support.

26
Documentation/devicetree/bindings/mtd/st-fsm.txt 100644
View File

@ -0,0 +1,26 @@
* ST-Microelectronics SPI FSM Serial (NOR) Flash Controller
Required properties:
- compatible : Should be "st,spi-fsm"
- reg : Contains register's location and length.
- reg-names : Should contain the reg names "spi-fsm"
- interrupts : The interrupt number
- pinctrl-0 : Standard Pinctrl phandle (see: pinctrl/pinctrl-bindings.txt)
Optional properties:
- st,syscfg : Phandle to boot-device system configuration registers
- st,boot-device-reg : Address of the aforementioned boot-device register(s)
- st,boot-device-spi : Expected boot-device value if booted via this device
Example:
spifsm: spifsm@fe902000{
compatible = "st,spi-fsm";
reg = <0xfe902000 0x1000>;
reg-names = "spi-fsm";
pinctrl-0 = <&pinctrl_fsm>;
st,syscfg = <&syscfg_rear>;
st,boot-device-reg = <0x958>;
st,boot-device-spi = <0x1a>;
status = "okay";
};

7
Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt 100644
View File

@ -0,0 +1,7 @@
LG Corporation 7" WXGA TFT LCD panel
Required properties:
- compatible: should be "lg,ld070wx3-sl01"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt 100644
View File

@ -0,0 +1,7 @@
LG Corporation 5" HD TFT LCD panel
Required properties:
- compatible: should be "lg,lh500wx1-sd03"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
Documentation/devicetree/bindings/panel/lg,lp129qe.txt 100644
View File

@ -0,0 +1,7 @@
LG 12.9" (2560x1700 pixels) TFT LCD panel
Required properties:
- compatible: should be "lg,lp129qe"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

66
Documentation/devicetree/bindings/panel/samsung,ld9040.txt 100644
View File

@ -0,0 +1,66 @@
Samsung LD9040 AMOLED LCD parallel RGB panel with SPI control bus
Required properties:
- compatible: "samsung,ld9040"
- reg: address of the panel on SPI bus
- vdd3-supply: core voltage supply
- vci-supply: voltage supply for analog circuits
- reset-gpios: a GPIO spec for the reset pin
- display-timings: timings for the connected panel according to [1]
The panel must obey rules for SPI slave device specified in document [2].
Optional properties:
- power-on-delay: delay after turning regulators on [ms]
- reset-delay: delay after reset sequence [ms]
- panel-width-mm: physical panel width [mm]
- panel-height-mm: physical panel height [mm]
The device node can contain one 'port' child node with one child
'endpoint' node, according to the bindings defined in [3]. This
node should describe panel's video bus.
[1]: Documentation/devicetree/bindings/video/display-timing.txt
[2]: Documentation/devicetree/bindings/spi/spi-bus.txt
[3]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
lcd@0 {
compatible = "samsung,ld9040";
reg = <0>;
vdd3-supply = <&ldo7_reg>;
vci-supply = <&ldo17_reg>;
reset-gpios = <&gpy4 5 0>;
spi-max-frequency = <1200000>;
spi-cpol;
spi-cpha;
power-on-delay = <10>;
reset-delay = <10>;
panel-width-mm = <90>;
panel-height-mm = <154>;
display-timings {
timing {
clock-frequency = <23492370>;
hactive = <480>;
vactive = <800>;
hback-porch = <16>;
hfront-porch = <16>;
vback-porch = <2>;
vfront-porch = <28>;
hsync-len = <2>;
vsync-len = <1>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <0>;
pixelclk-active = <0>;
};
};
port {
lcd_ep: endpoint {
remote-endpoint = <&fimd_dpi_ep>;
};
};
};

56
Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt 100644
View File

@ -0,0 +1,56 @@
Samsung S6E8AA0 AMOLED LCD 5.3 inch panel
Required properties:
- compatible: "samsung,s6e8aa0"
- reg: the virtual channel number of a DSI peripheral
- vdd3-supply: core voltage supply
- vci-supply: voltage supply for analog circuits
- reset-gpios: a GPIO spec for the reset pin
- display-timings: timings for the connected panel as described by [1]
Optional properties:
- power-on-delay: delay after turning regulators on [ms]
- reset-delay: delay after reset sequence [ms]
- init-delay: delay after initialization sequence [ms]
- panel-width-mm: physical panel width [mm]
- panel-height-mm: physical panel height [mm]
- flip-horizontal: boolean to flip image horizontally
- flip-vertical: boolean to flip image vertically
The device node can contain one 'port' child node with one child
'endpoint' node, according to the bindings defined in [2]. This
node should describe panel's video bus.
[1]: Documentation/devicetree/bindings/video/display-timing.txt
[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
panel {
compatible = "samsung,s6e8aa0";
reg = <0>;
vdd3-supply = <&vcclcd_reg>;
vci-supply = <&vlcd_reg>;
reset-gpios = <&gpy4 5 0>;
power-on-delay= <50>;
reset-delay = <100>;
init-delay = <100>;
panel-width-mm = <58>;
panel-height-mm = <103>;
flip-horizontal;
flip-vertical;
display-timings {
timing0: timing-0 {
clock-frequency = <57153600>;
hactive = <720>;
vactive = <1280>;
hfront-porch = <5>;
hback-porch = <5>;
hsync-len = <5>;
vfront-porch = <13>;
vback-porch = <1>;
vsync-len = <2>;
};
};
};

27
Documentation/devicetree/bindings/regulator/pbias-regulator.txt 100644
View File

@ -0,0 +1,27 @@
PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
Required properties:
- compatible:
- "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7.
- reg: pbias register offset from syscon base and size of pbias register.
- syscon : phandle of the system control module
- regulator-name : should be
pbias_mmc_omap2430 for OMAP2430, OMAP3 SoCs
pbias_sim_omap3 for OMAP3 SoCs
pbias_mmc_omap4 for OMAP4 SoCs
pbias_mmc_omap5 for OMAP5 and DRA7 SoC
Optional properties:
- Any optional property defined in bindings/regulator/regulator.txt
Example:
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap";
reg = <0 0x4>;
syscon = <&omap5_padconf_global>;
pbias_mmc_reg: pbias_mmc_omap5 {
regulator-name = "pbias_mmc_omap5";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <3000000>;
};

21
Documentation/devicetree/bindings/sound/fsl,ssi.txt
View File

@ -20,15 +20,6 @@ Required properties:
have.
- interrupt-parent: The phandle for the interrupt controller that
services interrupts for this device.
- fsl,mode: The operating mode for the SSI interface.
"i2s-slave" - I2S mode, SSI is clock slave
"i2s-master" - I2S mode, SSI is clock master
"lj-slave" - left-justified mode, SSI is clock slave
"lj-master" - l.j. mode, SSI is clock master
"rj-slave" - right-justified mode, SSI is clock slave
"rj-master" - r.j., SSI is clock master
"ac97-slave" - AC97 mode, SSI is clock slave
"ac97-master" - AC97 mode, SSI is clock master
- fsl,playback-dma: Phandle to a node for the DMA channel to use for
playback of audio. This is typically dictated by SOC
design. See the notes below.
@ -47,6 +38,9 @@ Required properties:
be connected together, and SRFS and STFS be connected
together. This would still allow different sample sizes,
but not different sample rates.
- clocks: "ipg" - Required clock for the SSI unit
"baud" - Required clock for SSI master mode. Otherwise this
clock is not used
Required are also ac97 link bindings if ac97 is used. See
Documentation/devicetree/bindings/sound/soc-ac97link.txt for the necessary
@ -64,6 +58,15 @@ Optional properties:
Documentation/devicetree/bindings/dma/dma.txt.
- dma-names: Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq
is not defined.
- fsl,mode: The operating mode for the SSI interface.
"i2s-slave" - I2S mode, SSI is clock slave
"i2s-master" - I2S mode, SSI is clock master
"lj-slave" - left-justified mode, SSI is clock slave
"lj-master" - l.j. mode, SSI is clock master
"rj-slave" - right-justified mode, SSI is clock slave
"rj-master" - r.j., SSI is clock master
"ac97-slave" - AC97 mode, SSI is clock slave
"ac97-master" - AC97 mode, SSI is clock master
Child 'codec' node required properties:
- compatible: Compatible list, contains the name of the codec

8
Documentation/devicetree/bindings/spi/efm32-spi.txt
View File

@ -8,7 +8,13 @@ Required properties:
- interrupts: pair specifying rx and tx irq
- clocks: phandle to the spi clock
- cs-gpios: see spi-bus.txt
- efm32,location: Value to write to the ROUTE register's LOCATION bitfield to configure the pinmux for the device, see datasheet for values.
Recommended properties :
- efm32,location: Value to write to the ROUTE register's LOCATION bitfield to
configure the pinmux for the device, see datasheet for values.
If "efm32,location" property is not provided, keeping what is
already configured in the hardware, so its either the reset
default 0 or whatever the bootloader did.
Example:

25
Documentation/devicetree/bindings/video/analog-tv-connector.txt 100644
View File

@ -0,0 +1,25 @@
Analog TV Connector
===================
Required properties:
- compatible: "composite-connector" or "svideo-connector"
Optional properties:
- label: a symbolic name for the connector
Required nodes:
- Video port for TV input
Example
-------
tv: connector {
compatible = "composite-connector";
label = "tv";
port {
tv_connector_in: endpoint {
remote-endpoint = <&venc_out>;
};
};
};

16
Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt 100644
View File

@ -0,0 +1,16 @@
gpio-backlight bindings
Required properties:
- compatible: "gpio-backlight"
- gpios: describes the gpio that is used for enabling/disabling the backlight.
refer to bindings/gpio/gpio.txt for more details.
Optional properties:
- default-on: enable the backlight at boot.
Example:
backlight {
compatible = "gpio-backlight";
gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>;
default-on;
};

35
Documentation/devicetree/bindings/video/dvi-connector.txt 100644
View File

@ -0,0 +1,35 @@
DVI Connector
==============
Required properties:
- compatible: "dvi-connector"
Optional properties:
- label: a symbolic name for the connector
- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
- analog: the connector has DVI analog pins
- digital: the connector has DVI digital pins
- dual-link: the connector has pins for DVI dual-link
Required nodes:
- Video port for DVI input
Note: One (or both) of 'analog' or 'digital' must be set.
Example
-------
dvi0: connector@0 {
compatible = "dvi-connector";
label = "dvi";
digital;
ddc-i2c-bus = <&i2c3>;
port {
dvi_connector_in: endpoint {
remote-endpoint = <&tfp410_out>;
};
};
};

17
Documentation/devicetree/bindings/video/exynos_dp.txt
View File

@ -49,6 +49,8 @@ Required properties for dp-controller:
-samsung,lane-count:
number of lanes supported by the panel.
LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
- display-timings: timings for the connected panel as described by
Documentation/devicetree/bindings/video/display-timing.txt
Optional properties for dp-controller:
-interlaced:
@ -84,4 +86,19 @@ Board Specific portion:
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
display-timings {
native-mode = <&lcd_timing>;
lcd_timing: 1366x768 {
clock-frequency = <70589280>;
hactive = <1366>;
vactive = <768>;
hfront-porch = <40>;
hback-porch = <40>;
hsync-len = <32>;
vback-porch = <10>;
vfront-porch = <12>;
vsync-len = <6>;
};
};
};

80
Documentation/devicetree/bindings/video/exynos_dsim.txt 100644
View File

@ -0,0 +1,80 @@
Exynos MIPI DSI Master
Required properties:
- compatible: "samsung,exynos4210-mipi-dsi"
- reg: physical base address and length of the registers set for the device
- interrupts: should contain DSI interrupt
- clocks: list of clock specifiers, must contain an entry for each required
entry in clock-names
- clock-names: should include "bus_clk"and "pll_clk" entries
- phys: list of phy specifiers, must contain an entry for each required
entry in phy-names
- phy-names: should include "dsim" entry
- vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V)
- vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V)
- samsung,pll-clock-frequency: specifies frequency of the "pll_clk" clock
- #address-cells, #size-cells: should be set respectively to <1> and <0>
according to DSI host bindings (see MIPI DSI bindings [1])
Optional properties:
- samsung,power-domain: a phandle to DSIM power domain node
Child nodes:
Should contain DSI peripheral nodes (see MIPI DSI bindings [1]).
Video interfaces:
Device node can contain video interface port nodes according to [2].
The following are properties specific to those nodes:
port node:
- reg: (required) can be 0 for input RGB/I80 port or 1 for DSI port;
endpoint node of DSI port (reg = 1):
- samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst
mode
- samsung,esc-clock-frequency: specifies DSI frequency in escape mode
[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
dsi@11C80000 {
compatible = "samsung,exynos4210-mipi-dsi";
reg = <0x11C80000 0x10000>;
interrupts = <0 79 0>;
clocks = <&clock 286>, <&clock 143>;
clock-names = "bus_clk", "pll_clk";
phys = <&mipi_phy 1>;
phy-names = "dsim";
vddcore-supply = <&vusb_reg>;
vddio-supply = <&vmipi_reg>;
samsung,power-domain = <&pd_lcd0>;
#address-cells = <1>;
#size-cells = <0>;
samsung,pll-clock-frequency = <24000000>;
panel@1 {
reg = <0>;
...
port {
panel_ep: endpoint {
remote-endpoint = <&dsi_ep>;
};
};
};
ports {
#address-cells = <1>;
#size-cells = <0>;
port@1 {
dsi_ep: endpoint {
reg = <0>;
samsung,burst-clock-frequency = <500000000>;
samsung,esc-clock-frequency = <20000000>;
remote-endpoint = <&panel_ep>;
};
};
};
};

5
Documentation/devicetree/bindings/video/exynos_hdmi.txt
View File

@ -25,6 +25,9 @@ Required properties:
sclk_pixel.
- clock-names: aliases as per driver requirements for above clock IDs:
"hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
Example:
hdmi {
@ -32,4 +35,6 @@ Example:
reg = <0x14530000 0x100000>;
interrupts = <0 95 0>;
hpd-gpio = <&gpx3 7 1>;
ddc = <&hdmi_ddc_node>;
phy = <&hdmi_phy_node>;
};

28
Documentation/devicetree/bindings/video/hdmi-connector.txt 100644
View File

@ -0,0 +1,28 @@
HDMI Connector
==============
Required properties:
- compatible: "hdmi-connector"
- type: the HDMI connector type: "a", "b", "c", "d" or "e"
Optional properties:
- label: a symbolic name for the connector
Required nodes:
- Video port for HDMI input
Example
-------
hdmi0: connector@1 {
compatible = "hdmi-connector";
label = "hdmi";
type = "a";
port {
hdmi_connector_in: endpoint {
remote-endpoint = <&tpd12s015_out>;
};
};
};

29
Documentation/devicetree/bindings/video/panel-dsi-cm.txt 100644
View File

@ -0,0 +1,29 @@
Generic MIPI DSI Command Mode Panel
===================================
Required properties:
- compatible: "panel-dsi-cm"
Optional properties:
- label: a symbolic name for the panel
- reset-gpios: panel reset gpio
- te-gpios: panel TE gpio
Required nodes:
- Video port for DSI input
Example
-------
lcd0: display {
compatible = "tpo,taal", "panel-dsi-cm";
label = "lcd0";
reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;
port {
lcd0_in: endpoint {
remote-endpoint = <&dsi1_out_ep>;
};
};
};

17
Documentation/devicetree/bindings/video/samsung-fimd.txt
View File

@ -39,6 +39,23 @@ Required properties:
Optional Properties:
- samsung,power-domain: a phandle to FIMD power domain node.
- samsung,invert-vden: video enable signal is inverted
- samsung,invert-vclk: video clock signal is inverted
- display-timings: timing settings for FIMD, as described in document [1].
Can be used in case timings cannot be provided otherwise
or to override timings provided by the panel.
The device node can contain 'port' child nodes according to the bindings defined
in [2]. The following are properties specific to those nodes:
- reg: (required) port index, can be:
0 - for CAMIF0 input,
1 - for CAMIF1 input,
2 - for CAMIF2 input,
3 - for parallel output,
4 - for write-back interface
[1]: Documentation/devicetree/bindings/video/display-timing.txt
[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:

30
Documentation/devicetree/bindings/video/sony,acx565akm.txt 100644
View File

@ -0,0 +1,30 @@
Sony ACX565AKM SDI Panel
========================
Required properties:
- compatible: "sony,acx565akm"
Optional properties:
- label: a symbolic name for the panel
- reset-gpios: panel reset gpio
Required nodes:
- Video port for SDI input
Example
-------
acx565akm@2 {
compatible = "sony,acx565akm";
spi-max-frequency = <6000000>;
reg = <2>;
label = "lcd";
reset-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */
port {
lcd_in: endpoint {
remote-endpoint = <&sdi_out>;
};
};
};

211
Documentation/devicetree/bindings/video/ti,omap-dss.txt 100644
View File

@ -0,0 +1,211 @@
Texas Instruments OMAP Display Subsystem
========================================
Generic Description
-------------------
This document is a generic description of the OMAP Display Subsystem bindings.
Binding details for each OMAP SoC version are described in respective binding
documentation.
The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and
a number of encoder modules. All DSS versions contain DSS Core and DISPC, but
the encoder modules vary.
The DSS Core is the parent of the other DSS modules, and manages clock routing,
integration to the SoC, etc.
DISPC is the display controller, which reads pixels from the memory and outputs
a RGB pixel stream to encoders.
The encoder modules encode the received RGB pixel stream to a video output like
HDMI, MIPI DPI, etc.
Video Ports
-----------
The DSS Core and the encoders have video port outputs. The structure of the
video ports is described in Documentation/devicetree/bindings/video/video-
ports.txt, and the properties for the ports and endpoints for each encoder are
described in the SoC's DSS binding documentation.
The video ports are used to describe the connections to external hardware, like
panels or external encoders.
Aliases
-------
The board dts file may define aliases for displays to assign "displayX" style
name for each display. If no aliases are defined, a semi-random number is used
for the display.
Example
-------
A shortened example of the DSS description for OMAP4, with non-relevant parts
removed, defined in omap4.dtsi:
dss: dss@58000000 {
compatible = "ti,omap4-dss";
reg = <0x58000000 0x80>;
status = "disabled";
ti,hwmods = "dss_core";
clocks = <&dss_dss_clk>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges;
dispc@58001000 {
compatible = "ti,omap4-dispc";
reg = <0x58001000 0x1000>;
interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
ti,hwmods = "dss_dispc";
clocks = <&dss_dss_clk>;
clock-names = "fck";
};
hdmi: encoder@58006000 {
compatible = "ti,omap4-hdmi";
reg = <0x58006000 0x200>,
<0x58006200 0x100>,
<0x58006300 0x100>,
<0x58006400 0x1000>;
reg-names = "wp", "pll", "phy", "core";
interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
ti,hwmods = "dss_hdmi";
clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
clock-names = "fck", "sys_clk";
};
};
A shortened example of the board description for OMAP4 Panda board, defined in
omap4-panda.dts.
The Panda board has a DVI and a HDMI connector, and the board contains a TFP410
chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level
shifter). The video pipelines for the connectors are formed as follows:
DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector
OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector
/ {
aliases {
display0 = &dvi0;
display1 = &hdmi0;
};
tfp410: encoder@0 {
compatible = "ti,tfp410";
gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */
pinctrl-names = "default";
pinctrl-0 = <&tfp410_pins>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
tfp410_in: endpoint@0 {
remote-endpoint = <&dpi_out>;
};
};
port@1 {
reg = <1>;
tfp410_out: endpoint@0 {
remote-endpoint = <&dvi_connector_in>;
};
};
};
};
dvi0: connector@0 {
compatible = "dvi-connector";
label = "dvi";
i2c-bus = <&i2c3>;
port {
dvi_connector_in: endpoint {
remote-endpoint = <&tfp410_out>;
};
};
};
tpd12s015: encoder@1 {
compatible = "ti,tpd12s015";
pinctrl-names = "default";
pinctrl-0 = <&tpd12s015_pins>;
gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */
<&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */
<&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
tpd12s015_in: endpoint@0 {
remote-endpoint = <&hdmi_out>;
};
};
port@1 {
reg = <1>;
tpd12s015_out: endpoint@0 {
remote-endpoint = <&hdmi_connector_in>;
};
};
};
};
hdmi0: connector@1 {
compatible = "hdmi-connector";
label = "hdmi";
port {
hdmi_connector_in: endpoint {
remote-endpoint = <&tpd12s015_out>;
};
};
};
};
&dss {
status = "ok";
pinctrl-names = "default";
pinctrl-0 = <&dss_dpi_pins>;
port {
dpi_out: endpoint {
remote-endpoint = <&tfp410_in>;
data-lines = <24>;
};
};
};
&hdmi {
status = "ok";
vdda-supply = <&vdac>;
pinctrl-names = "default";
pinctrl-0 = <&dss_hdmi_pins>;
port {
hdmi_out: endpoint {
remote-endpoint = <&tpd12s015_in>;
};
};
};

54
Documentation/devicetree/bindings/video/ti,omap2-dss.txt 100644
View File

@ -0,0 +1,54 @@
Texas Instruments OMAP2 Display Subsystem
=========================================
See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
description about OMAP Display Subsystem bindings.
DSS Core
--------
Required properties:
- compatible: "ti,omap2-dss"
- reg: address and length of the register space
- ti,hwmods: "dss_core"
Optional nodes:
- Video port for DPI output
DPI Endpoint required properties:
- data-lines: number of lines used
DISPC
-----
Required properties:
- compatible: "ti,omap2-dispc"
- reg: address and length of the register space
- ti,hwmods: "dss_dispc"
- interrupts: the DISPC interrupt
RFBI
----
Required properties:
- compatible: "ti,omap2-rfbi"
- reg: address and length of the register space
- ti,hwmods: "dss_rfbi"
VENC
----
Required properties:
- compatible: "ti,omap2-venc"
- reg: address and length of the register space
- ti,hwmods: "dss_venc"
- vdda-supply: power supply for DAC
VENC Endpoint required properties:
Required properties:
- ti,invert-polarity: invert the polarity of the video signal
- ti,channels: 1 for composite, 2 for s-video

83
Documentation/devicetree/bindings/video/ti,omap3-dss.txt 100644
View File

@ -0,0 +1,83 @@
Texas Instruments OMAP3 Display Subsystem
=========================================
See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
description about OMAP Display Subsystem bindings.
DSS Core
--------
Required properties:
- compatible: "ti,omap3-dss"
- reg: address and length of the register space
- ti,hwmods: "dss_core"
- clocks: handle to fclk
- clock-names: "fck"
Optional nodes:
- Video ports:
- Port 0: DPI output
- Port 1: SDI output
DPI Endpoint required properties:
- data-lines: number of lines used
SDI Endpoint required properties:
- datapairs: number of datapairs used
DISPC
-----
Required properties:
- compatible: "ti,omap3-dispc"
- reg: address and length of the register space
- ti,hwmods: "dss_dispc"
- interrupts: the DISPC interrupt
- clocks: handle to fclk
- clock-names: "fck"
RFBI
----
Required properties:
- compatible: "ti,omap3-rfbi"
- reg: address and length of the register space
- ti,hwmods: "dss_rfbi"
- clocks: handles to fclk and iclk
- clock-names: "fck", "ick"
VENC
----
Required properties:
- compatible: "ti,omap3-venc"
- reg: address and length of the register space
- ti,hwmods: "dss_venc"
- vdda-supply: power supply for DAC
- clocks: handle to fclk
- clock-names: "fck"
VENC Endpoint required properties:
- ti,invert-polarity: invert the polarity of the video signal
- ti,channels: 1 for composite, 2 for s-video
DSI
---
Required properties:
- compatible: "ti,omap3-dsi"
- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
- reg-names: "proto", "phy", "pll"
- interrupts: the DSI interrupt line
- ti,hwmods: "dss_dsi1"
- vdd-supply: power supply for DSI
- clocks: handles to fclk and pll clock
- clock-names: "fck", "sys_clk"
DSI Endpoint required properties:
- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
DATA1+, DATA1-, ...

111
Documentation/devicetree/bindings/video/ti,omap4-dss.txt 100644
View File

@ -0,0 +1,111 @@
Texas Instruments OMAP4 Display Subsystem
=========================================
See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
description about OMAP Display Subsystem bindings.
DSS Core
--------
Required properties:
- compatible: "ti,omap4-dss"
- reg: address and length of the register space
- ti,hwmods: "dss_core"
- clocks: handle to fclk
- clock-names: "fck"
Required nodes:
- DISPC
Optional nodes:
- DSS Submodules: RFBI, VENC, DSI, HDMI
- Video port for DPI output
DPI Endpoint required properties:
- data-lines: number of lines used
DISPC
-----
Required properties:
- compatible: "ti,omap4-dispc"
- reg: address and length of the register space
- ti,hwmods: "dss_dispc"
- interrupts: the DISPC interrupt
- clocks: handle to fclk
- clock-names: "fck"
RFBI
----
Required properties:
- compatible: "ti,omap4-rfbi"
- reg: address and length of the register space
- ti,hwmods: "dss_rfbi"
- clocks: handles to fclk and iclk
- clock-names: "fck", "ick"
Optional nodes:
- Video port for RFBI output
- RFBI controlled peripherals
VENC
----
Required properties:
- compatible: "ti,omap4-venc"
- reg: address and length of the register space
- ti,hwmods: "dss_venc"
- vdda-supply: power supply for DAC
- clocks: handle to fclk
- clock-names: "fck"
Optional nodes:
- Video port for VENC output
VENC Endpoint required properties:
- ti,invert-polarity: invert the polarity of the video signal
- ti,channels: 1 for composite, 2 for s-video
DSI
---
Required properties:
- compatible: "ti,omap4-dsi"
- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
- reg-names: "proto", "phy", "pll"
- interrupts: the DSI interrupt line
- ti,hwmods: "dss_dsi1" or "dss_dsi2"
- vdd-supply: power supply for DSI
- clocks: handles to fclk and pll clock
- clock-names: "fck", "sys_clk"
Optional nodes:
- Video port for DSI output
- DSI controlled peripherals
DSI Endpoint required properties:
- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
DATA1+, DATA1-, ...
HDMI
----
Required properties:
- compatible: "ti,omap4-hdmi"
- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy',
'core'
- reg-names: "wp", "pll", "phy", "core"
- interrupts: the HDMI interrupt line
- ti,hwmods: "dss_hdmi"
- vdda-supply: vdda power supply
- clocks: handles to fclk and pll clock
- clock-names: "fck", "sys_clk"
Optional nodes:
- Video port for HDMI output

41
Documentation/devicetree/bindings/video/ti,tfp410.txt 100644
View File

@ -0,0 +1,41 @@
TFP410 DPI to DVI encoder
=========================
Required properties:
- compatible: "ti,tfp410"
Optional properties:
- powerdown-gpios: power-down gpio
Required nodes:
- Video port 0 for DPI input
- Video port 1 for DVI output
Example
-------
tfp410: encoder@0 {
compatible = "ti,tfp410";
powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
tfp410_in: endpoint@0 {
remote-endpoint = <&dpi_out>;
};
};
port@1 {
reg = <1>;
tfp410_out: endpoint@0 {
remote-endpoint = <&dvi_connector_in>;
};
};
};
};

44
Documentation/devicetree/bindings/video/ti,tpd12s015.txt 100644
View File

@ -0,0 +1,44 @@
TPD12S015 HDMI level shifter and ESD protection chip
====================================================
Required properties:
- compatible: "ti,tpd12s015"
Optional properties:
- gpios: CT CP HPD, LS OE and HPD gpios
Required nodes:
- Video port 0 for HDMI input
- Video port 1 for HDMI output
Example
-------
tpd12s015: encoder@1 {
compatible = "ti,tpd12s015";
gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */
<&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */
<&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
tpd12s015_in: endpoint@0 {
remote-endpoint = <&hdmi_out>;
};
};
port@1 {
reg = <1>;
tpd12s015_out: endpoint@0 {
remote-endpoint = <&hdmi_connector_in>;
};
};
};
};

3
Documentation/dontdiff
View File

@ -1,5 +1,6 @@
*.a
*.aux
*.bc
*.bin
*.bz2
*.cis
@ -21,6 +22,7 @@
*.i
*.jpeg
*.ko
*.ll
*.log
*.lst
*.lzma
@ -35,6 +37,7 @@
*.out
*.patch
*.pdf
*.plist
*.png
*.pot
*.ps

12
Documentation/filesystems/Locking
View File

@ -202,7 +202,7 @@ prototypes:
unsigned long *);
int (*migratepage)(struct address_space *, struct page *, struct page *);
int (*launder_page)(struct page *);
int (*is_partially_uptodate)(struct page *, read_descriptor_t *, unsigned long);
int (*is_partially_uptodate)(struct page *, unsigned long, unsigned long);
int (*error_remove_page)(struct address_space *, struct page *);
int (*swap_activate)(struct file *);
int (*swap_deactivate)(struct file *);
@ -529,6 +529,7 @@ locking rules:
open: yes
close: yes
fault: yes can return with page locked
map_pages: yes
page_mkwrite: yes can return with page locked
access: yes
@ -540,6 +541,15 @@ the page, then ensure it is not already truncated (the page lock will block
subsequent truncate), and then return with VM_FAULT_LOCKED, and the page
locked. The VM will unlock the page.
->map_pages() is called when VM asks to map easy accessible pages.
Filesystem should find and map pages associated with offsets from "pgoff"
till "max_pgoff". ->map_pages() is called with page table locked and must
not block. If it's not possible to reach a page without blocking,
filesystem should skip it. Filesystem should use do_set_pte() to setup
page table entry. Pointer to entry associated with offset "pgoff" is
passed in "pte" field in vm_fault structure. Pointers to entries for other
offsets should be calculated relative to "pte".
->page_mkwrite() is called when a previously read-only pte is
about to become writeable. The filesystem again must ensure that there are
no truncate/invalidate races, and then return with the page locked. If

9
Documentation/filesystems/affs.txt
View File

@ -49,6 +49,10 @@ mode=mode Sets the mode flags to the given (octal) value, regardless
This is useful since most of the plain AmigaOS files
will map to 600.
nofilenametruncate
The file system will return an error when filename exceeds
standard maximum filename length (30 characters).
reserved=num Sets the number of reserved blocks at the start of the
partition to num. You should never need this option.
Default is 2.
@ -181,9 +185,8 @@ tested, though several hundred MB have been read and written using
this fs. For a most up-to-date list of bugs please consult
fs/affs/Changes.
Filenames are truncated to 30 characters without warning (this
can be changed by setting the compile-time option AFFS_NO_TRUNCATE
in include/linux/amigaffs.h).
By default, filenames are truncated to 30 characters without warning.
'nofilenametruncate' mount option can change that behavior.
Case is ignored by the affs in filename matching, but Linux shells
do care about the case. Example (with /wb being an affs mounted fs):

29
Documentation/filesystems/f2fs.txt
View File

@ -122,6 +122,10 @@ disable_ext_identify Disable the extension list configured by mkfs, so f2fs
inline_xattr Enable the inline xattrs feature.
inline_data Enable the inline data feature: New created small(<~3.4k)
files can be written into inode block.
flush_merge Merge concurrent cache_flush commands as much as possible
to eliminate redundant command issues. If the underlying
device handles the cache_flush command relatively slowly,
recommend to enable this option.
================================================================================
DEBUGFS ENTRIES
@ -169,9 +173,11 @@ Files in /sys/fs/f2fs/<devname>
reclaim_segments This parameter controls the number of prefree
segments to be reclaimed. If the number of prefree
segments is larger than this number, f2fs tries to
conduct checkpoint to reclaim the prefree segments
to free segments. By default, 100 segments, 200MB.
segments is larger than the number of segments
in the proportion to the percentage over total
volume size, f2fs tries to conduct checkpoint to
reclaim the prefree segments to free segments.
By default, 5% over total # of segments.
max_small_discards This parameter controls the number of discard
commands that consist small blocks less than 2MB.
@ -195,6 +201,17 @@ Files in /sys/fs/f2fs/<devname>
cleaning operations. The default value is 4096
which covers 8GB block address range.
dir_level This parameter controls the directory level to
support large directory. If a directory has a
number of files, it can reduce the file lookup
latency by increasing this dir_level value.
Otherwise, it needs to decrease this value to
reduce the space overhead. The default value is 0.
ram_thresh This parameter controls the memory footprint used
by free nids and cached nat entries. By default,
10 is set, which indicates 10 MB / 1 GB RAM.
================================================================================
USAGE
================================================================================
@ -444,9 +461,11 @@ The number of blocks and buckets are determined by,
# of blocks in level #n = |
`- 4, Otherwise
,- 2^n, if n < MAX_DIR_HASH_DEPTH / 2,
,- 2^ (n + dir_level),
| if n < MAX_DIR_HASH_DEPTH / 2,
# of buckets in level #n = |
`- 2^((MAX_DIR_HASH_DEPTH / 2) - 1), Otherwise
`- 2^((MAX_DIR_HASH_DEPTH / 2 + dir_level) - 1),
Otherwise
When F2FS finds a file name in a directory, at first a hash value of the file
name is calculated. Then, F2FS scans the hash table in level #0 to find the

17
Documentation/filesystems/proc.txt
View File

@ -1648,18 +1648,21 @@ pids, so one need to either stop or freeze processes being inspected
if precise results are needed.
3.7 /proc/<pid>/fdinfo/<fd> - Information about opened file
3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file
---------------------------------------------------------------
This file provides information associated with an opened file. The regular
files have at least two fields -- 'pos' and 'flags'. The 'pos' represents
the current offset of the opened file in decimal form [see lseek(2) for
details] and 'flags' denotes the octal O_xxx mask the file has been
created with [see open(2) for details].
files have at least three fields -- 'pos', 'flags' and mnt_id. The 'pos'
represents the current offset of the opened file in decimal form [see lseek(2)
for details], 'flags' denotes the octal O_xxx mask the file has been
created with [see open(2) for details] and 'mnt_id' represents mount ID of
the file system containing the opened file [see 3.5 /proc/<pid>/mountinfo
for details].
A typical output is
pos: 0
flags: 0100002
mnt_id: 19
The files such as eventfd, fsnotify, signalfd, epoll among the regular pos/flags
pair provide additional information particular to the objects they represent.
@ -1668,6 +1671,7 @@ pair provide additional information particular to the objects they represent.
~~~~~~~~~~~~~
pos: 0
flags: 04002
mnt_id: 9
eventfd-count: 5a
where 'eventfd-count' is hex value of a counter.
@ -1676,6 +1680,7 @@ pair provide additional information particular to the objects they represent.
~~~~~~~~~~~~~~
pos: 0
flags: 04002
mnt_id: 9
sigmask: 0000000000000200
where 'sigmask' is hex value of the signal mask associated
@ -1685,6 +1690,7 @@ pair provide additional information particular to the objects they represent.
~~~~~~~~~~~
pos: 0
flags: 02
mnt_id: 9
tfd: 5 events: 1d data: ffffffffffffffff
where 'tfd' is a target file descriptor number in decimal form,
@ -1718,6 +1724,7 @@ pair provide additional information particular to the objects they represent.
pos: 0
flags: 02
mnt_id: 9
fanotify flags:10 event-flags:0
fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003
fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4

2
Documentation/filesystems/vfs.txt
View File

@ -596,7 +596,7 @@ struct address_space_operations {
/* migrate the contents of a page to the specified target */
int (*migratepage) (struct page *, struct page *);
int (*launder_page) (struct page *);
int (*is_partially_uptodate) (struct page *, read_descriptor_t *,
int (*is_partially_uptodate) (struct page *, unsigned long,
unsigned long);
void (*is_dirty_writeback) (struct page *, bool *, bool *);
int (*error_remove_page) (struct mapping *mapping, struct page *page);

1
Documentation/i2c/busses/i2c-i801
View File

@ -26,6 +26,7 @@ Supported adapters:
* Intel Wellsburg (PCH)
* Intel Coleto Creek (PCH)
* Intel Wildcat Point-LP (PCH)
* Intel BayTrail (SOC)
Datasheets: Publicly available at the Intel website
On Intel Patsburg and later chipsets, both the normal host SMBus controller

2
Documentation/i2c/functionality
View File

@ -46,7 +46,7 @@ A few combinations of the above flags are also defined for your convenience:
and write_block_data commands
I2C_FUNC_SMBUS_I2C_BLOCK Handles the SMBus read_i2c_block_data
and write_i2c_block_data commands
I2C_FUNC_SMBUS_EMUL Handles all SMBus commands than can be
I2C_FUNC_SMBUS_EMUL Handles all SMBus commands that can be
emulated by a real I2C adapter (using
the transparent emulation layer)

35
Documentation/i2c/i2c-protocol
View File

@ -6,8 +6,8 @@ Key to symbols
S (1 bit) : Start bit
P (1 bit) : Stop bit
Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0.
A, NA (1 bit) : Accept and reverse accept bit.
Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to
A, NA (1 bit) : Accept and reverse accept bit.
Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to
get a 10 bit I2C address.
Comm (8 bits): Command byte, a data byte which often selects a register on
the device.
@ -49,11 +49,20 @@ a byte read, followed by a byte write:
Modified transactions
=====================
The following modifications to the I2C protocol can also be generated,
with the exception of I2C_M_NOSTART these are usually only needed to
work around device issues:
The following modifications to the I2C protocol can also be generated by
setting these flags for i2c messages. With the exception of I2C_M_NOSTART, they
are usually only needed to work around device issues:
Flag I2C_M_NOSTART:
I2C_M_IGNORE_NAK:
Normally message is interrupted immediately if there is [NA] from the
client. Setting this flag treats any [NA] as [A], and all of
message is sent.
These messages may still fail to SCL lo->hi timeout.
I2C_M_NO_RD_ACK:
In a read message, master A/NA bit is skipped.
I2C_M_NOSTART:
In a combined transaction, no 'S Addr Wr/Rd [A]' is generated at some
point. For example, setting I2C_M_NOSTART on the second partial message
generates something like:
@ -67,17 +76,13 @@ work around device issues:
I2C device but may also be used between direction changes by some
rare devices.
Flags I2C_M_REV_DIR_ADDR
I2C_M_REV_DIR_ADDR:
This toggles the Rd/Wr flag. That is, if you want to do a write, but
need to emit an Rd instead of a Wr, or vice versa, you set this
flag. For example:
S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P
Flags I2C_M_IGNORE_NAK
Normally message is interrupted immediately if there is [NA] from the
client. Setting this flag treats any [NA] as [A], and all of
message is sent.
These messages may still fail to SCL lo->hi timeout.
Flags I2C_M_NO_RD_ACK
In a read message, master A/NA bit is skipped.
I2C_M_STOP:
Force a stop condition (P) after the message. Some I2C related protocols
like SCCB require that. Normally, you really don't want to get interrupted
between the messages of one transfer.

7
Documentation/irqflags-tracing.txt
View File

@ -22,13 +22,6 @@ rather straightforward and risk-free manner.
Architectures that want to support this need to do a couple of
code-organizational changes first:
- move their irq-flags manipulation code from their asm/system.h header
to asm/irqflags.h
- rename local_irq_disable()/etc to raw_local_irq_disable()/etc. so that
the linux/irqflags.h code can inject callbacks and can construct the
real local_irq_disable()/etc APIs.
- add and enable TRACE_IRQFLAGS_SUPPORT in their arch level Kconfig file
and then a couple of functional changes are needed as well to implement

4
Documentation/kbuild/kconfig-language.txt
View File

@ -157,6 +157,10 @@ applicable everywhere (see syntax).
to the build environment (if this is desired, it can be done via
another symbol).
- "allnoconfig_y"
This declares the symbol as one that should have the value y when
using "allnoconfig". Used for symbols that hide other symbols.
Menu dependencies
-----------------

12
Documentation/kernel-parameters.txt
View File

@ -884,6 +884,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
Enable debug messages at boot time. See
Documentation/dynamic-debug-howto.txt for details.
early_ioremap_debug [KNL]
Enable debug messages in early_ioremap support. This
is useful for tracking down temporary early mappings
which are not unmapped.
earlycon= [KNL] Output early console device and options.
uart[8250],io,<addr>[,options]
uart[8250],mmio,<addr>[,options]
@ -2558,6 +2563,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
pcmv= [HW,PCMCIA] BadgePAD 4
pd_ignore_unused
[PM]
Keep all power-domains already enabled by bootloader on,
even if no driver has claimed them. This is useful
for debug and development, but should not be
needed on a platform with proper driver support.
pd. [PARIDE]
See Documentation/blockdev/paride.txt.

3
Documentation/module-signing.txt
View File

@ -53,7 +53,8 @@ This has a number of options available:
If this is off (ie. "permissive"), then modules for which the key is not
available and modules that are unsigned are permitted, but the kernel will
be marked as being tainted.
be marked as being tainted, and the concerned modules will be marked as
tainted, shown with the character 'E'.
If this is on (ie. "restrictive"), only modules that have a valid
signature that can be verified by a public key in the kernel's possession

3
Documentation/oops-tracing.txt
View File

@ -265,6 +265,9 @@ characters, each representing a particular tainted value.
13: 'O' if an externally-built ("out-of-tree") module has been loaded.
14: 'E' if an unsigned module has been loaded in a kernel supporting
module signature.
The primary reason for the 'Tainted: ' string is to tell kernel
debuggers if this is a clean kernel or if anything unusual has
occurred. Tainting is permanent: even if an offending module is

66
Documentation/rapidio/sysfs.txt
View File

@ -2,8 +2,8 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Device Subdirectories
------------------------
1. RapidIO Device Subdirectories
--------------------------------
For each RapidIO device, the RapidIO subsystem creates files in an individual
subdirectory with the following name, /sys/bus/rapidio/devices/<device_name>.
@ -25,8 +25,8 @@ seen by the enumerating host (destID = 1):
NOTE: An enumerating or discovering endpoint does not create a sysfs entry for
itself, this is why an endpoint with destID=1 is not shown in the list.
2. Attributes Common for All Devices
------------------------------------
2. Attributes Common for All RapidIO Devices
--------------------------------------------
Each device subdirectory contains the following informational read-only files:
@ -52,16 +52,16 @@ This attribute is similar in behavior to the "config" attribute of PCI devices
and provides an access to the RapidIO device registers using standard file read
and write operations.
3. Endpoint Device Attributes
-----------------------------
3. RapidIO Endpoint Device Attributes
-------------------------------------
Currently Linux RapidIO subsystem does not create any endpoint specific sysfs
attributes. It is possible that RapidIO master port drivers and endpoint device
drivers will add their device-specific sysfs attributes but such attributes are
outside the scope of this document.
4. Switch Device Attributes
---------------------------
4. RapidIO Switch Device Attributes
-----------------------------------
RapidIO switches have additional attributes in sysfs. RapidIO subsystem supports
common and device-specific sysfs attributes for switches. Because switches are
@ -106,3 +106,53 @@ attribute:
for that controller always will be 0.
To initiate RapidIO enumeration/discovery on all available mports
a user must write '-1' (or RIO_MPORT_ANY) into this attribute file.
6. RapidIO Bus Controllers/Ports
--------------------------------
On-chip RapidIO controllers and PCIe-to-RapidIO bridges (referenced as
"Master Port" or "mport") are presented in sysfs as the special class of
devices: "rapidio_port".
The /sys/class/rapidio_port subdirectory contains individual subdirectories
named as "rapidioN" where N = mport ID registered with RapidIO subsystem.
NOTE: An mport ID is not a RapidIO destination ID assigned to a given local
mport device.
Each mport device subdirectory in addition to standard entries contains the
following device-specific attributes:
port_destid - reports RapidIO destination ID assigned to the given RapidIO
mport device. If value 0xFFFFFFFF is returned this means that
no valid destination ID have been assigned to the mport (yet).
Normally, before enumeration/discovery have been executed only
fabric enumerating mports have a valid destination ID assigned
to them using "hdid=..." rapidio module parameter.
sys_size - reports RapidIO common transport system size:
0 = small (8-bit destination ID, max. 256 devices),
1 = large (16-bit destination ID, max. 65536 devices).
After enumeration or discovery was performed for a given mport device,
the corresponding subdirectory will also contain subdirectories for each
child RapidIO device connected to the mport. Naming conventions for RapidIO
devices are described in Section 1 above.
The example below shows mport device subdirectory with several child RapidIO
devices attached to it.
[rio@rapidio ~]$ ls /sys/class/rapidio_port/rapidio0/ -l
total 0
drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0001
drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0004
drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0007
drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0002
drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0003
drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0005
lrwxrwxrwx 1 root root 0 Feb 11 15:11 device -> ../../../0000:01:00.0
-r--r--r-- 1 root root 4096 Feb 11 15:11 port_destid
drwxr-xr-x 2 root root 0 Feb 11 15:11 power
lrwxrwxrwx 1 root root 0 Feb 11 15:04 subsystem -> ../../../../../../class/rapidio_port
-r--r--r-- 1 root root 4096 Feb 11 15:11 sys_size
-rw-r--r-- 1 root root 4096 Feb 11 15:04 uevent

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

@ -8,7 +8,7 @@ Context switch
By default, the switch_to arch function is called with the runqueue
locked. This is usually not a problem unless switch_to may need to
take the runqueue lock. This is usually due to a wake up operation in
the context switch. See arch/ia64/include/asm/system.h for an example.
the context switch. See arch/ia64/include/asm/switch_to.h for an example.
To request the scheduler call switch_to with the runqueue unlocked,
you must `#define __ARCH_WANT_UNLOCKED_CTXSW` in a header file

3
Documentation/sysctl/kernel.txt
View File

@ -317,6 +317,7 @@ for more than this value report a warning.
This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
0: means infinite timeout - no checking done.
Possible values to set are in range {0..LONG_MAX/HZ}.
==============================================================
@ -785,6 +786,8 @@ can be ORed together:
1024 - A module from drivers/staging was loaded.
2048 - The system is working around a severe firmware bug.
4096 - An out-of-tree module has been loaded.
8192 - An unsigned module has been loaded in a kernel supporting module
signature.
==============================================================

26
MAINTAINERS
View File

@ -1427,6 +1427,7 @@ F: drivers/cpuidle/cpuidle-zynq.c
N: zynq
N: xilinx
F: drivers/clocksource/cadence_ttc_timer.c
F: drivers/i2c/busses/i2c-cadence.c
F: drivers/mmc/host/sdhci-of-arasan.c
ARM SMMU DRIVER
@ -2945,6 +2946,16 @@ F: drivers/gpu/drm/radeon/
F: include/drm/radeon*
F: include/uapi/drm/radeon*
DRM PANEL DRIVERS
M: Thierry Reding <thierry.reding@gmail.com>
L: dri-devel@lists.freedesktop.org
T: git git://anongit.freedesktop.org/tegra/linux.git
S: Maintained
F: drivers/gpu/drm/drm_panel.c
F: drivers/gpu/drm/panel/
F: include/drm/drm_panel.h
F: Documentation/devicetree/bindings/panel/
INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
M: Daniel Vetter <daniel.vetter@ffwll.ch>
M: Jani Nikula <jani.nikula@linux.intel.com>
@ -3474,12 +3485,6 @@ S: Maintained
F: drivers/extcon/
F: Documentation/extcon/
EXYNOS DP DRIVER
M: Jingoo Han <jg1.han@samsung.com>
L: linux-fbdev@vger.kernel.org
S: Maintained
F: drivers/video/exynos/exynos_dp*
EXYNOS MIPI DISPLAY DRIVERS
M: Inki Dae <inki.dae@samsung.com>
M: Donghwa Lee <dh09.lee@samsung.com>
@ -4304,7 +4309,8 @@ F: drivers/i2c/i2c-stub.c
I2C SUBSYSTEM
M: Wolfram Sang <wsa@the-dreams.de>
L: linux-i2c@vger.kernel.org
W: http://i2c.wiki.kernel.org/
W: https://i2c.wiki.kernel.org/
Q: https://patchwork.ozlabs.org/project/linux-i2c/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
S: Maintained
F: Documentation/i2c/
@ -4542,8 +4548,7 @@ K: \b(ABS|SYN)_MT_
INTEL C600 SERIES SAS CONTROLLER DRIVER
M: Intel SCU Linux support <intel-linux-scu@intel.com>
M: Lukasz Dorau <lukasz.dorau@intel.com>
M: Maciej Patelczyk <maciej.patelczyk@intel.com>
M: Artur Paszkiewicz <artur.paszkiewicz@intel.com>
M: Dave Jiang <dave.jiang@intel.com>
L: linux-scsi@vger.kernel.org
T: git git://git.code.sf.net/p/intel-sas/isci
@ -5927,6 +5932,7 @@ F: include/linux/mfd/
MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
M: Chris Ball <chris@printf.net>
M: Ulf Hansson <ulf.hansson@linaro.org>
L: linux-mmc@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
S: Maintained
@ -6537,7 +6543,7 @@ F: drivers/net/wireless/orinoco/
OSD LIBRARY and FILESYSTEM
M: Boaz Harrosh <bharrosh@panasas.com>
M: Benny Halevy <bhalevy@tonian.com>
M: Benny Halevy <bhalevy@primarydata.com>
L: osd-dev@open-osd.org
W: http://open-osd.org
T: git git://git.open-osd.org/open-osd.git

51
Makefile
View File

@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 14
PATCHLEVEL = 15
SUBLEVEL = 0
EXTRAVERSION =
EXTRAVERSION = -rc1
NAME = Shuffling Zombie Juror
# *DOCUMENTATION*
@ -120,9 +120,10 @@ ifneq ($(KBUILD_OUTPUT),)
# Invoke a second make in the output directory, passing relevant variables
# check that the output directory actually exists
saved-output := $(KBUILD_OUTPUT)
KBUILD_OUTPUT := $(shell cd $(KBUILD_OUTPUT) && /bin/pwd)
KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) \
&& /bin/pwd)
$(if $(KBUILD_OUTPUT),, \
$(error output directory "$(saved-output)" does not exist))
$(error failed to create output directory "$(saved-output)"))
PHONY += $(MAKECMDGOALS) sub-make
@ -247,6 +248,11 @@ HOSTCXX = g++
HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
HOSTCXXFLAGS = -O2
ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
HOSTCFLAGS += -Wno-unused-value -Wno-unused-parameter \
-Wno-missing-field-initializers -fno-delete-null-pointer-checks
endif
# Decide whether to build built-in, modular, or both.
# Normally, just do built-in.
@ -323,6 +329,14 @@ endif
export quiet Q KBUILD_VERBOSE
ifneq ($(CC),)
ifeq ($(shell $(CC) -v 2>&1 | grep -c "clang version"), 1)
COMPILER := clang
else
COMPILER := gcc
endif
export COMPILER
endif
# Look for make include files relative to root of kernel src
MAKEFLAGS += --include-dir=$(srctree)
@ -382,7 +396,7 @@ KBUILD_CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
-Werror-implicit-function-declaration \
-Wno-format-security \
-fno-delete-null-pointer-checks
$(call cc-option,-fno-delete-null-pointer-checks,)
KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_KERNEL :=
KBUILD_AFLAGS := -D__ASSEMBLY__
@ -414,8 +428,9 @@ export MODVERDIR := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/).tmp_ve
# Files to ignore in find ... statements
RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS \
-o -name .pc -o -name .hg -o -name .git \) -prune -o
export RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o \
-name CVS -o -name .pc -o -name .hg -o -name .git \) \
-prune -o
export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn \
--exclude CVS --exclude .pc --exclude .hg --exclude .git
@ -622,9 +637,24 @@ endif
endif
KBUILD_CFLAGS += $(stackp-flag)
ifeq ($(COMPILER),clang)
KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,)
KBUILD_CPPFLAGS += $(call cc-option,-Wno-unknown-warning-option,)
KBUILD_CFLAGS += $(call cc-disable-warning, unused-variable)
KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier)
KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
# Quiet clang warning: comparison of unsigned expression < 0 is always false
KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare)
# CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the
# source of a reference will be _MergedGlobals and not on of the whitelisted names.
# See modpost pattern 2
KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)
else
# This warning generated too much noise in a regular build.
# Use make W=1 to enable this warning (see scripts/Makefile.build)
KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable)
endif
ifdef CONFIG_FRAME_POINTER
KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
@ -1074,12 +1104,12 @@ CLEAN_DIRS += $(MODVERDIR)
# Directories & files removed with 'make mrproper'
MRPROPER_DIRS += include/config usr/include include/generated \
arch/*/include/generated
arch/*/include/generated .tmp_objdiff
MRPROPER_FILES += .config .config.old .version .old_version $(version_h) \
Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
signing_key.priv signing_key.x509 x509.genkey \
extra_certificates signing_key.x509.keyid \
signing_key.x509.signer
signing_key.x509.signer include/linux/version.h
# clean - Delete most, but leave enough to build external modules
#
@ -1118,8 +1148,7 @@ distclean: mrproper
@find $(srctree) $(RCS_FIND_IGNORE) \
\( -name '*.orig' -o -name '*.rej' -o -name '*~' \
-o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \
-o -name '.*.rej' \
-o -name '*%' -o -name '.*.cmd' -o -name 'core' \) \
-o -name '.*.rej' -o -name '*%' -o -name 'core' \) \
-type f -print | xargs rm -f

1
arch/alpha/Kconfig
View File

@ -22,6 +22,7 @@ config ALPHA
select GENERIC_SMP_IDLE_THREAD
select GENERIC_STRNCPY_FROM_USER
select GENERIC_STRNLEN_USER
select HAVE_ARCH_AUDITSYSCALL
select HAVE_MOD_ARCH_SPECIFIC
select MODULES_USE_ELF_RELA
select ODD_RT_SIGACTION

2
arch/arc/Kconfig
View File

@ -57,7 +57,7 @@ config ARCH_FLATMEM_ENABLE
config MMU
def_bool y
config NO_IOPORT
config NO_IOPORT_MAP
def_bool y
config GENERIC_CALIBRATE_DELAY

1
arch/arc/boot/.gitignore vendored
View File

@ -1 +1,2 @@
*.dtb*
uImage

12
arch/arc/boot/dts/nsimosci.dts
View File

@ -11,13 +11,16 @@
/ {
compatible = "snps,nsimosci";
clock-frequency = <80000000>; /* 80 MHZ */
clock-frequency = <20000000>; /* 20 MHZ */
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <&intc>;
chosen {
bootargs = "console=tty0 consoleblank=0";
/* this is for console on PGU */
/* bootargs = "console=tty0 consoleblank=0"; */
/* this is for console on serial */
bootargs = "earlycon=uart8250,mmio32,0xc0000000,115200n8 console=ttyS0,115200n8 consoleblank=0 debug";
};
aliases {
@ -44,15 +47,14 @@
};
uart0: serial@c0000000 {
compatible = "snps,dw-apb-uart";
compatible = "ns8250";
reg = <0xc0000000 0x2000>;
interrupts = <11>;
#clock-frequency = <80000000>;
clock-frequency = <3686400>;
baud = <115200>;
reg-shift = <2>;
reg-io-width = <4>;
status = "okay";
no-loopback-test = <1>;
};
pgu0: pgu@c9000000 {

10
arch/arc/boot/dts/skeleton.dts
View File

@ -1,10 +0,0 @@
/*
* Copyright (C) 2012 Synopsys, Inc. (www.synopsys.com)
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
/include/ "skeleton.dtsi"

1
arch/arc/configs/nsimosci_defconfig
View File

@ -54,6 +54,7 @@ CONFIG_SERIO_ARC_PS2=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DW=y
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_SERIAL_ARC=y
CONFIG_SERIAL_ARC_CONSOLE=y
# CONFIG_HW_RANDOM is not set

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

@ -13,20 +13,6 @@
#define ASM_NL ` /* use '`' to mark new line in macro */
/* Can't use the ENTRY macro in linux/linkage.h
* gas considers ';' as comment vs. newline
*/
.macro ARC_ENTRY name
.global \name
.align 4
\name:
.endm
.macro ARC_EXIT name
#define ASM_PREV_SYM_ADDR(name) .-##name
.size \ name, ASM_PREV_SYM_ADDR(\name)
.endm
/* annotation for data we want in DCCM - if enabled in .config */
.macro ARCFP_DATA nm
#ifdef CONFIG_ARC_HAS_DCCM

2
arch/arc/kernel/ctx_sw_asm.S
View File

@ -62,4 +62,4 @@ __switch_to:
ld.ab blink, [sp, 4]
j [blink]
ARC_EXIT __switch_to
END(__switch_to)

52
arch/arc/kernel/entry.S
View File

@ -141,7 +141,7 @@ VECTOR EV_Extension ; 0x130, Extn Intruction Excp (0x26)
VECTOR reserved ; Reserved Exceptions
.endr
#include <linux/linkage.h> /* ARC_{EXTRY,EXIT} */
#include <linux/linkage.h> /* {EXTRY,EXIT} */
#include <asm/entry.h> /* SAVE_ALL_{INT1,INT2,SYS...} */
#include <asm/errno.h>
#include <asm/arcregs.h>
@ -184,7 +184,7 @@ reserved: ; processor restart
; ---------------------------------------------
; Level 2 ISR: Can interrupt a Level 1 ISR
; ---------------------------------------------
ARC_ENTRY handle_interrupt_level2
ENTRY(handle_interrupt_level2)
; TODO-vineetg for SMP this wont work
; free up r9 as scratchpad
@ -225,14 +225,14 @@ ARC_ENTRY handle_interrupt_level2
b ret_from_exception
ARC_EXIT handle_interrupt_level2
END(handle_interrupt_level2)
#endif
; ---------------------------------------------
; Level 1 ISR
; ---------------------------------------------
ARC_ENTRY handle_interrupt_level1
ENTRY(handle_interrupt_level1)
/* free up r9 as scratchpad */
#ifdef CONFIG_SMP
@ -265,7 +265,7 @@ ARC_ENTRY handle_interrupt_level1
sr r8, [AUX_IRQ_LV12] ; clear bit in Sticky Status Reg
b ret_from_exception
ARC_EXIT handle_interrupt_level1
END(handle_interrupt_level1)
;################### Non TLB Exception Handling #############################
@ -273,7 +273,7 @@ ARC_EXIT handle_interrupt_level1
; Instruction Error Exception Handler
; ---------------------------------------------
ARC_ENTRY instr_service
ENTRY(instr_service)
EXCEPTION_PROLOGUE
@ -284,13 +284,13 @@ ARC_ENTRY instr_service
bl do_insterror_or_kprobe
b ret_from_exception
ARC_EXIT instr_service
END(instr_service)
; ---------------------------------------------
; Memory Error Exception Handler
; ---------------------------------------------
ARC_ENTRY mem_service
ENTRY(mem_service)
EXCEPTION_PROLOGUE
@ -301,13 +301,13 @@ ARC_ENTRY mem_service
bl do_memory_error
b ret_from_exception
ARC_EXIT mem_service
END(mem_service)
; ---------------------------------------------
; Machine Check Exception Handler
; ---------------------------------------------
ARC_ENTRY EV_MachineCheck
ENTRY(EV_MachineCheck)
EXCEPTION_PROLOGUE
@ -331,13 +331,13 @@ ARC_ENTRY EV_MachineCheck
j do_machine_check_fault
ARC_EXIT EV_MachineCheck
END(EV_MachineCheck)
; ---------------------------------------------
; Protection Violation Exception Handler
; ---------------------------------------------
ARC_ENTRY EV_TLBProtV
ENTRY(EV_TLBProtV)
EXCEPTION_PROLOGUE
@ -385,12 +385,12 @@ ARC_ENTRY EV_TLBProtV
b ret_from_exception
ARC_EXIT EV_TLBProtV
END(EV_TLBProtV)
; ---------------------------------------------
; Privilege Violation Exception Handler
; ---------------------------------------------
ARC_ENTRY EV_PrivilegeV
ENTRY(EV_PrivilegeV)
EXCEPTION_PROLOGUE
@ -401,12 +401,12 @@ ARC_ENTRY EV_PrivilegeV
bl do_privilege_fault
b ret_from_exception
ARC_EXIT EV_PrivilegeV
END(EV_PrivilegeV)
; ---------------------------------------------
; Extension Instruction Exception Handler
; ---------------------------------------------
ARC_ENTRY EV_Extension
ENTRY(EV_Extension)
EXCEPTION_PROLOGUE
@ -417,7 +417,7 @@ ARC_ENTRY EV_Extension
bl do_extension_fault
b ret_from_exception
ARC_EXIT EV_Extension
END(EV_Extension)
;######################### System Call Tracing #########################
@ -504,7 +504,7 @@ trap_with_param:
; (2) Break Points
;------------------------------------------------------------------
ARC_ENTRY EV_Trap
ENTRY(EV_Trap)
EXCEPTION_PROLOGUE
@ -534,9 +534,9 @@ ARC_ENTRY EV_Trap
jl [r9] ; Entry into Sys Call Handler
; fall through to ret_from_system_call
ARC_EXIT EV_Trap
END(EV_Trap)
ARC_ENTRY ret_from_system_call
ENTRY(ret_from_system_call)
st r0, [sp, PT_r0] ; sys call return value in pt_regs
@ -546,7 +546,7 @@ ARC_ENTRY ret_from_system_call
;
; If ret to user mode do we need to handle signals, schedule() et al.
ARC_ENTRY ret_from_exception
ENTRY(ret_from_exception)
; Pre-{IRQ,Trap,Exception} K/U mode from pt_regs->status32
ld r8, [sp, PT_status32] ; returning to User/Kernel Mode
@ -726,9 +726,9 @@ not_level1_interrupt:
debug_marker_syscall:
rtie
ARC_EXIT ret_from_exception
END(ret_from_exception)
ARC_ENTRY ret_from_fork
ENTRY(ret_from_fork)
; when the forked child comes here from the __switch_to function
; r0 has the last task pointer.
; put last task in scheduler queue
@ -745,11 +745,11 @@ ARC_ENTRY ret_from_fork
; special case of kernel_thread entry point returning back due to
; kernel_execve() - pretend return from syscall to ret to userland
b ret_from_exception
ARC_EXIT ret_from_fork
END(ret_from_fork)
;################### Special Sys Call Wrappers ##########################
ARC_ENTRY sys_clone_wrapper
ENTRY(sys_clone_wrapper)
SAVE_CALLEE_SAVED_USER
bl @sys_clone
DISCARD_CALLEE_SAVED_USER
@ -759,7 +759,7 @@ ARC_ENTRY sys_clone_wrapper
bnz tracesys_exit
b ret_from_system_call
ARC_EXIT sys_clone_wrapper
END(sys_clone_wrapper)
#ifdef CONFIG_ARC_DW2_UNWIND
; Workaround for bug 94179 (STAR ):

7
arch/arc/kernel/head.S
View File

@ -24,13 +24,13 @@
.globl stext
stext:
;-------------------------------------------------------------------
; Don't clobber r0-r4 yet. It might have bootloader provided info
; Don't clobber r0-r2 yet. It might have bootloader provided info
;-------------------------------------------------------------------
sr @_int_vec_base_lds, [AUX_INTR_VEC_BASE]
#ifdef CONFIG_SMP
; Only Boot (Master) proceeds. Others wait in platform dependent way
; Ensure Boot (Master) proceeds. Others wait in platform dependent way
; IDENTITY Reg [ 3 2 1 0 ]
; (cpu-id) ^^^ => Zero for UP ARC700
; => #Core-ID if SMP (Master 0)
@ -39,7 +39,8 @@ stext:
; need to make sure only boot cpu takes this path.
GET_CPU_ID r5
cmp r5, 0
jnz arc_platform_smp_wait_to_boot
mov.ne r0, r5
jne arc_platform_smp_wait_to_boot
#endif
; Clear BSS before updating any globals
; XXX: use ZOL here

37
arch/arc/kernel/time.c
View File

@ -155,22 +155,6 @@ static void arc_timer_event_setup(unsigned int limit)
write_aux_reg(ARC_REG_TIMER0_CTRL, TIMER_CTRL_IE | TIMER_CTRL_NH);
}
/*
* Acknowledge the interrupt (oneshot) and optionally re-arm it (periodic)
* -Any write to CTRL Reg will ack the intr (NH bit: Count when not halted)
* -Rearming is done by setting the IE bit
*
* Small optimisation: Normal code would have been
* if (irq_reenable)
* CTRL_REG = (IE | NH);
* else
* CTRL_REG = NH;
* However since IE is BIT0 we can fold the branch
*/
static void arc_timer_event_ack(unsigned int irq_reenable)
{
write_aux_reg(ARC_REG_TIMER0_CTRL, irq_reenable | TIMER_CTRL_NH);
}
static int arc_clkevent_set_next_event(unsigned long delta,
struct clock_event_device *dev)
@ -207,10 +191,22 @@ static DEFINE_PER_CPU(struct clock_event_device, arc_clockevent_device) = {
static irqreturn_t timer_irq_handler(int irq, void *dev_id)
{
struct clock_event_device *clk = this_cpu_ptr(&arc_clockevent_device);
/*
* Note that generic IRQ core could have passed @evt for @dev_id if
* irq_set_chip_and_handler() asked for handle_percpu_devid_irq()
*/
struct clock_event_device *evt = this_cpu_ptr(&arc_clockevent_device);
int irq_reenable = evt->mode == CLOCK_EVT_MODE_PERIODIC;
/*
* Any write to CTRL reg ACks the interrupt, we rewrite the
* Count when [N]ot [H]alted bit.
* And re-arm it if perioid by [I]nterrupt [E]nable bit
*/
write_aux_reg(ARC_REG_TIMER0_CTRL, irq_reenable | TIMER_CTRL_NH);
evt->event_handler(evt);
arc_timer_event_ack(clk->mode == CLOCK_EVT_MODE_PERIODIC);
clk->event_handler(clk);
return IRQ_HANDLED;
}
@ -222,9 +218,8 @@ static struct irqaction arc_timer_irq = {
/*
* Setup the local event timer for @cpu
* N.B. weak so that some exotic ARC SoCs can completely override it
*/
void __weak arc_local_timer_setup(unsigned int cpu)
void arc_local_timer_setup(unsigned int cpu)
{
struct clock_event_device *clk = &per_cpu(arc_clockevent_device, cpu);

6
arch/arc/lib/memcmp.S
View File

@ -6,7 +6,7 @@
* published by the Free Software Foundation.
*/
#include <asm/linkage.h>
#include <linux/linkage.h>
#ifdef __LITTLE_ENDIAN__
#define WORD2 r2
@ -16,7 +16,7 @@
#define SHIFT r2
#endif
ARC_ENTRY memcmp
ENTRY(memcmp)
or r12,r0,r1
asl_s r12,r12,30
sub r3,r2,1
@ -121,4 +121,4 @@ ARC_ENTRY memcmp
.Lnil:
j_s.d [blink]
mov r0,0
ARC_EXIT memcmp
END(memcmp)

6
arch/arc/lib/memcpy-700.S
View File

@ -6,9 +6,9 @@
* published by the Free Software Foundation.
*/
#include <asm/linkage.h>
#include <linux/linkage.h>
ARC_ENTRY memcpy
ENTRY(memcpy)
or r3,r0,r1
asl_s r3,r3,30
mov_s r5,r0
@ -63,4 +63,4 @@ ARC_ENTRY memcpy
.Lendbloop:
j_s.d [blink]
stb r12,[r5,0]
ARC_EXIT memcpy
END(memcpy)

10
arch/arc/lib/memset.S
View File

@ -6,11 +6,11 @@
* published by the Free Software Foundation.
*/
#include <asm/linkage.h>
#include <linux/linkage.h>
#define SMALL 7 /* Must be at least 6 to deal with alignment/loop issues. */
ARC_ENTRY memset
ENTRY(memset)
mov_s r4,r0
or r12,r0,r2
bmsk.f r12,r12,1
@ -46,14 +46,14 @@ ARC_ENTRY memset
stb.ab r1,[r4,1]
.Ltiny_end:
j_s [blink]
ARC_EXIT memset
END(memset)
; memzero: @r0 = mem, @r1 = size_t
; memset: @r0 = mem, @r1 = char, @r2 = size_t
ARC_ENTRY memzero
ENTRY(memzero)
; adjust bzero args to memset args
mov r2, r1
mov r1, 0
b memset ;tail call so need to tinker with blink
ARC_EXIT memzero
END(memzero)

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