Linux 3.11-rc2
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAABAgAGBQJR7DEPAAoJEHm+PkMAQRiGYTsH+QEBZLTcCNzMEgFNjzBhB2w3 XYfWkHH8kOXEnE5Hxg2Y4cc4yOGOevO6yItUGMf/WTdFUT5C3AFtqh34QcbymQK6 ovT7o/gH6L2lne1wit/Wgddagkt1NqIsEVum5dUFXhkfoEpDrn9raQ4zF/BmJ/MB 7ZMdY7AjnsZbdYUpOgM7oh6oK8KHw7Z+ujUXKsDjzcXTsQg+9kK4Qj/bvmhrQEr4 acoLAk0VOojZk++BNhjsP/OMgtIbh6Y2JoZ6G7Uxc/pGXTMHAxQoK/8akO6XLuJ2 vWEq1N3zCNtVjv7rYJqOhlkwgYV5YXAE2dTt/6sWxoEDN8ezdRI1r6FLu5DgiUg= =TA+I -----END PGP SIGNATURE----- Merge tag 'v3.11-rc2' into core/locking Merge in Linux 3.11-rc2 before moving on with new work. Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar
Коммит
b59f2b4d30
|
|
@ -54,6 +54,13 @@ Description: Interface for making ib_srp connect to a new target.
|
|||
ib_srp. Specifying a value that exceeds cmd_sg_entries is
|
||||
only safe with partial memory descriptor list support enabled
|
||||
(allow_ext_sg=1).
|
||||
* comp_vector, a number in the range 0..n-1 specifying the
|
||||
MSI-X completion vector. Some HCA's allocate multiple (n)
|
||||
MSI-X vectors per HCA port. If the IRQ affinity masks of
|
||||
these interrupts have been configured such that each MSI-X
|
||||
interrupt is handled by a different CPU then the comp_vector
|
||||
parameter can be used to spread the SRP completion workload
|
||||
over multiple CPU's.
|
||||
|
||||
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
|
||||
Date: January 2, 2006
|
||||
|
|
|
|||
|
|
@ -4,9 +4,13 @@ Description:
|
|||
|
||||
/sys/module/MODULENAME
|
||||
The name of the module that is in the kernel. This
|
||||
module name will show up either if the module is built
|
||||
directly into the kernel, or if it is loaded as a
|
||||
dynamic module.
|
||||
module name will always show up if the module is loaded as a
|
||||
dynamic module. If it is built directly into the kernel, it
|
||||
will only show up if it has a version or at least one
|
||||
parameter.
|
||||
|
||||
Note: The conditions of creation in the built-in case are not
|
||||
by design and may be removed in the future.
|
||||
|
||||
/sys/module/MODULENAME/parameters
|
||||
This directory contains individual files that are each
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Description: Generic performance monitoring events
|
|||
|
||||
What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
|
||||
/sys/devices/cpu/events/PM_BRU_FIN
|
||||
/sys/devices/cpu/events/PM_BRU_MPRED
|
||||
/sys/devices/cpu/events/PM_BR_MPRED
|
||||
/sys/devices/cpu/events/PM_CMPLU_STALL
|
||||
/sys/devices/cpu/events/PM_CMPLU_STALL_BRU
|
||||
/sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS
|
||||
|
|
|
|||
|
|
@ -0,0 +1,79 @@
|
|||
What: /sys/class/pwm/
|
||||
Date: May 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
Description:
|
||||
The pwm/ class sub-directory belongs to the Generic PWM
|
||||
Framework and provides a sysfs interface for using PWM
|
||||
channels.
|
||||
|
||||
What: /sys/class/pwm/pwmchipN/
|
||||
Date: May 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
Description:
|
||||
A /sys/class/pwm/pwmchipN directory is created for each
|
||||
probed PWM controller/chip where N is the base of the
|
||||
PWM chip.
|
||||
|
||||
What: /sys/class/pwm/pwmchipN/npwm
|
||||
Date: May 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
Description:
|
||||
The number of PWM channels supported by the PWM chip.
|
||||
|
||||
What: /sys/class/pwm/pwmchipN/export
|
||||
Date: May 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
Description:
|
||||
Exports a PWM channel from the PWM chip for sysfs control.
|
||||
Value is between 0 and /sys/class/pwm/pwmchipN/npwm - 1.
|
||||
|
||||
What: /sys/class/pwm/pwmchipN/unexport
|
||||
Date: May 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
Description:
|
||||
Unexports a PWM channel.
|
||||
|
||||
What: /sys/class/pwm/pwmchipN/pwmX
|
||||
Date: May 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
Description:
|
||||
A /sys/class/pwm/pwmchipN/pwmX directory is created for
|
||||
each exported PWM channel where X is the exported PWM
|
||||
channel number.
|
||||
|
||||
What: /sys/class/pwm/pwmchipN/pwmX/period
|
||||
Date: May 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
Description:
|
||||
Sets the PWM signal period in nanoseconds.
|
||||
|
||||
What: /sys/class/pwm/pwmchipN/pwmX/duty_cycle
|
||||
Date: May 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
Description:
|
||||
Sets the PWM signal duty cycle in nanoseconds.
|
||||
|
||||
What: /sys/class/pwm/pwmchipN/pwmX/polarity
|
||||
Date: May 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
Description:
|
||||
Sets the output polarity of the PWM signal to "normal" or
|
||||
"inversed".
|
||||
|
||||
What: /sys/class/pwm/pwmchipN/pwmX/enable
|
||||
Date: May 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
|
||||
Description:
|
||||
Enable/disable the PWM signal.
|
||||
0 is disabled
|
||||
1 is enabled
|
||||
|
|
@ -77,7 +77,7 @@ Description: Read/Write attribute file that controls memory scrubbing.
|
|||
|
||||
What: /sys/devices/system/edac/mc/mc*/max_location
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
linux-edac@vger.kernel.org
|
||||
Description: This attribute file displays the information about the last
|
||||
available memory slot in this memory controller. It is used by
|
||||
|
|
@ -85,7 +85,7 @@ Description: This attribute file displays the information about the last
|
|||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/size
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
linux-edac@vger.kernel.org
|
||||
Description: This attribute file will display the size of dimm or rank.
|
||||
For dimm*/size, this is the size, in MB of the DIMM memory
|
||||
|
|
@ -96,14 +96,14 @@ Description: This attribute file will display the size of dimm or rank.
|
|||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_dev_type
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
linux-edac@vger.kernel.org
|
||||
Description: This attribute file will display what type of DRAM device is
|
||||
being utilized on this DIMM (x1, x2, x4, x8, ...).
|
||||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_edac_mode
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
linux-edac@vger.kernel.org
|
||||
Description: This attribute file will display what type of Error detection
|
||||
and correction is being utilized. For example: S4ECD4ED would
|
||||
|
|
@ -111,7 +111,7 @@ Description: This attribute file will display what type of Error detection
|
|||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_label
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
linux-edac@vger.kernel.org
|
||||
Description: This control file allows this DIMM to have a label assigned
|
||||
to it. With this label in the module, when errors occur
|
||||
|
|
@ -126,14 +126,14 @@ Description: This control file allows this DIMM to have a label assigned
|
|||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_location
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
linux-edac@vger.kernel.org
|
||||
Description: This attribute file will display the location (csrow/channel,
|
||||
branch/channel/slot or channel/slot) of the dimm or rank.
|
||||
|
||||
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_mem_type
|
||||
Date: April 2012
|
||||
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
linux-edac@vger.kernel.org
|
||||
Description: This attribute file will display what type of memory is
|
||||
currently on this csrow. Normally, either buffered or
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
What: /sys/bus/acpi/intel-rapid-start/wakeup_events
|
||||
Date: July 2, 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: Matthew Garrett <mjg59@srcf.ucam.org>
|
||||
Description: An integer representing a set of wakeup events as follows:
|
||||
1: Wake to enter hibernation when the wakeup timer expires
|
||||
2: Wake to enter hibernation when the battery reaches a
|
||||
critical level
|
||||
|
||||
These values are ORed together. For example, a value of 3
|
||||
indicates that the system will wake to enter hibernation when
|
||||
either the wakeup timer expires or the battery reaches a
|
||||
critical level.
|
||||
|
||||
What: /sys/bus/acpi/intel-rapid-start/wakeup_time
|
||||
Date: July 2, 2013
|
||||
KernelVersion: 3.11
|
||||
Contact: Matthew Garrett <mjg59@srcf.ucam.org>
|
||||
Description: An integer representing the length of time the system will
|
||||
remain asleep before waking up to enter hibernation.
|
||||
This value is in minutes.
|
||||
|
|
@ -127,14 +127,11 @@
|
|||
!Finclude/net/cfg80211.h cfg80211_ibss_params
|
||||
!Finclude/net/cfg80211.h cfg80211_connect_params
|
||||
!Finclude/net/cfg80211.h cfg80211_pmksa
|
||||
!Finclude/net/cfg80211.h cfg80211_send_rx_auth
|
||||
!Finclude/net/cfg80211.h cfg80211_send_auth_timeout
|
||||
!Finclude/net/cfg80211.h cfg80211_send_rx_assoc
|
||||
!Finclude/net/cfg80211.h cfg80211_send_assoc_timeout
|
||||
!Finclude/net/cfg80211.h cfg80211_send_deauth
|
||||
!Finclude/net/cfg80211.h __cfg80211_send_deauth
|
||||
!Finclude/net/cfg80211.h cfg80211_send_disassoc
|
||||
!Finclude/net/cfg80211.h __cfg80211_send_disassoc
|
||||
!Finclude/net/cfg80211.h cfg80211_rx_mlme_mgmt
|
||||
!Finclude/net/cfg80211.h cfg80211_auth_timeout
|
||||
!Finclude/net/cfg80211.h cfg80211_rx_assoc_resp
|
||||
!Finclude/net/cfg80211.h cfg80211_assoc_timeout
|
||||
!Finclude/net/cfg80211.h cfg80211_tx_mlme_mgmt
|
||||
!Finclude/net/cfg80211.h cfg80211_ibss_joined
|
||||
!Finclude/net/cfg80211.h cfg80211_connect_result
|
||||
!Finclude/net/cfg80211.h cfg80211_roamed
|
||||
|
|
|
|||
|
|
@ -2254,7 +2254,7 @@ video encoding.</para>
|
|||
<orderedlist>
|
||||
<listitem>
|
||||
<para>The <constant>VIDIOC_G_CHIP_IDENT</constant> ioctl was renamed
|
||||
to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and &VIDIOC-DBG-G-CHIP-IDENT;
|
||||
to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and <constant>VIDIOC_DBG_G_CHIP_IDENT</constant>
|
||||
was introduced in its place. The old struct <structname>v4l2_chip_ident</structname>
|
||||
was renamed to <structname id="v4l2-chip-ident-old">v4l2_chip_ident_old</structname>.</para>
|
||||
</listitem>
|
||||
|
|
@ -2513,6 +2513,16 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
|||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.11</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Remove obsolete <constant>VIDIOC_DBG_G_CHIP_IDENT</constant> ioctl.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section id="other">
|
||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||
|
||||
|
|
@ -2596,7 +2606,7 @@ and may change in the future.</para>
|
|||
ioctls.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-DBG-G-CHIP-IDENT; ioctl.</para>
|
||||
<para>&VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and
|
||||
|
|
|
|||
|
|
@ -140,6 +140,14 @@ structs, ioctls) must be noted in more detail in the history chapter
|
|||
(compat.xml), along with the possible impact on existing drivers and
|
||||
applications. -->
|
||||
|
||||
<revision>
|
||||
<revnumber>3.11</revnumber>
|
||||
<date>2013-05-26</date>
|
||||
<authorinitials>hv</authorinitials>
|
||||
<revremark>Remove obsolete VIDIOC_DBG_G_CHIP_IDENT ioctl.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>3.10</revnumber>
|
||||
<date>2013-03-25</date>
|
||||
|
|
@ -493,7 +501,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 3.10</subtitle>
|
||||
<subtitle>Revision 3.11</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
|
|
@ -547,7 +555,6 @@ and discussions on the V4L mailing list.</revremark>
|
|||
<!-- All ioctls go here. -->
|
||||
&sub-create-bufs;
|
||||
&sub-cropcap;
|
||||
&sub-dbg-g-chip-ident;
|
||||
&sub-dbg-g-chip-info;
|
||||
&sub-dbg-g-register;
|
||||
&sub-decoder-cmd;
|
||||
|
|
|
|||
|
|
@ -1,271 +0,0 @@
|
|||
<refentry id="vidioc-dbg-g-chip-ident">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_DBG_G_CHIP_IDENT</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_DBG_G_CHIP_IDENT</refname>
|
||||
<refpurpose>Identify the chips on a TV card</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_dbg_chip_ident
|
||||
*<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_DBG_G_CHIP_IDENT</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
|
||||
<para>This is an <link
|
||||
linkend="experimental">experimental</link> interface and may change in
|
||||
the future.</para>
|
||||
</note>
|
||||
|
||||
<para>For driver debugging purposes this ioctl allows test
|
||||
applications to query the driver about the chips present on the TV
|
||||
card. Regular applications must not use it. When you found a chip
|
||||
specific bug, please contact the linux-media mailing list (&v4l-ml;)
|
||||
so it can be fixed.</para>
|
||||
|
||||
<para>To query the driver applications must initialize the
|
||||
<structfield>match.type</structfield> and
|
||||
<structfield>match.addr</structfield> or <structfield>match.name</structfield>
|
||||
fields of a &v4l2-dbg-chip-ident;
|
||||
and call <constant>VIDIOC_DBG_G_CHIP_IDENT</constant> with a pointer to
|
||||
this structure. On success the driver stores information about the
|
||||
selected chip in the <structfield>ident</structfield> and
|
||||
<structfield>revision</structfield> fields. On failure the structure
|
||||
remains unchanged.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_HOST</constant>,
|
||||
<structfield>match.addr</structfield> selects the nth non-&i2c; chip
|
||||
on the TV card. You can enumerate all chips by starting at zero and
|
||||
incrementing <structfield>match.addr</structfield> by one until
|
||||
<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;.
|
||||
The number zero always selects the host chip, ⪚ the chip connected
|
||||
to the PCI or USB bus.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
|
||||
<structfield>match.name</structfield> contains the I2C driver name.
|
||||
For instance
|
||||
<constant>"saa7127"</constant> will match any chip
|
||||
supported by the saa7127 driver, regardless of its &i2c; bus address.
|
||||
When multiple chips supported by the same driver are present, the
|
||||
ioctl will return <constant>V4L2_IDENT_AMBIGUOUS</constant> in the
|
||||
<structfield>ident</structfield> field.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>,
|
||||
<structfield>match.addr</structfield> selects a chip by its 7 bit
|
||||
&i2c; bus address.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_AC97</constant>,
|
||||
<structfield>match.addr</structfield> selects the nth AC97 chip
|
||||
on the TV card. You can enumerate all chips by starting at zero and
|
||||
incrementing <structfield>match.addr</structfield> by one until
|
||||
<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;.</para>
|
||||
|
||||
<para>On success, the <structfield>ident</structfield> field will
|
||||
contain a chip ID from the Linux
|
||||
<filename>media/v4l2-chip-ident.h</filename> header file, and the
|
||||
<structfield>revision</structfield> field will contain a driver
|
||||
specific value, or zero if no particular revision is associated with
|
||||
this chip.</para>
|
||||
|
||||
<para>When the driver could not identify the selected chip,
|
||||
<structfield>ident</structfield> will contain
|
||||
<constant>V4L2_IDENT_UNKNOWN</constant>. When no chip matched
|
||||
the ioctl will succeed but the
|
||||
<structfield>ident</structfield> field will contain
|
||||
<constant>V4L2_IDENT_NONE</constant>. If multiple chips matched,
|
||||
<structfield>ident</structfield> will contain
|
||||
<constant>V4L2_IDENT_AMBIGUOUS</constant>. In all these cases the
|
||||
<structfield>revision</structfield> field remains unchanged.</para>
|
||||
|
||||
<para>This ioctl is optional, not all drivers may support it. It
|
||||
was introduced in Linux 2.6.21, but the API was changed to the
|
||||
one described here in 2.6.29.</para>
|
||||
|
||||
<para>We recommended the <application>v4l2-dbg</application>
|
||||
utility over calling this ioctl directly. It is available from the
|
||||
LinuxTV v4l-dvb repository; see <ulink
|
||||
url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
|
||||
access instructions.</para>
|
||||
|
||||
<!-- Note for convenience vidioc-dbg-g-register.sgml
|
||||
contains a duplicate of this table. -->
|
||||
<table pgwide="1" frame="none" id="ident-v4l2-dbg-match">
|
||||
<title>struct <structname>v4l2_dbg_match</structname></title>
|
||||
<tgroup cols="4">
|
||||
&cs-ustr;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>See <xref linkend="ident-chip-match-types" /> for a list of
|
||||
possible types.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>union</entry>
|
||||
<entry>(anonymous)</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>addr</structfield></entry>
|
||||
<entry>Match a chip by this number, interpreted according
|
||||
to the <structfield>type</structfield> field.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>char</entry>
|
||||
<entry><structfield>name[32]</structfield></entry>
|
||||
<entry>Match a chip by this name, interpreted according
|
||||
to the <structfield>type</structfield> field.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-dbg-chip-ident">
|
||||
<title>struct <structname>v4l2_dbg_chip_ident</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>struct v4l2_dbg_match</entry>
|
||||
<entry><structfield>match</structfield></entry>
|
||||
<entry>How to match the chip, see <xref linkend="ident-v4l2-dbg-match" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>ident</structfield></entry>
|
||||
<entry>A chip identifier as defined in the Linux
|
||||
<filename>media/v4l2-chip-ident.h</filename> header file, or one of
|
||||
the values from <xref linkend="chip-ids" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>revision</structfield></entry>
|
||||
<entry>A chip revision, chip and driver specific.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<!-- Note for convenience vidioc-dbg-g-register.sgml
|
||||
contains a duplicate of this table. -->
|
||||
<table pgwide="1" frame="none" id="ident-chip-match-types">
|
||||
<title>Chip Match Types</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_BRIDGE</constant></entry>
|
||||
<entry>0</entry>
|
||||
<entry>Match the nth chip on the card, zero for the
|
||||
bridge chip. Does not match sub-devices.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>Match an &i2c; chip by its driver name.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>Match a chip by its 7 bit &i2c; bus address.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
|
||||
<entry>3</entry>
|
||||
<entry>Match the nth anciliary AC97 chip.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
|
||||
<entry>4</entry>
|
||||
<entry>Match the nth sub-device. Can't be used with this ioctl.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<!-- This is an anonymous enum in media/v4l2-chip-ident.h. -->
|
||||
<table pgwide="1" frame="none" id="chip-ids">
|
||||
<title>Chip Identifiers</title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>V4L2_IDENT_NONE</constant></entry>
|
||||
<entry>0</entry>
|
||||
<entry>No chip matched.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_IDENT_AMBIGUOUS</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>Multiple chips matched.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_IDENT_UNKNOWN</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>A chip is present at this address, but the driver
|
||||
could not identify it.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The <structfield>match_type</structfield> is invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -73,8 +73,7 @@ fields of a &v4l2-dbg-chip-info;
|
|||
and call <constant>VIDIOC_DBG_G_CHIP_INFO</constant> with a pointer to
|
||||
this structure. On success the driver stores information about the
|
||||
selected chip in the <structfield>name</structfield> and
|
||||
<structfield>flags</structfield> fields. On failure the structure
|
||||
remains unchanged.</para>
|
||||
<structfield>flags</structfield> fields.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
|
||||
|
|
@ -132,7 +131,7 @@ to the <structfield>type</structfield> field.</entry>
|
|||
<entry>char</entry>
|
||||
<entry><structfield>name[32]</structfield></entry>
|
||||
<entry>Match a chip by this name, interpreted according
|
||||
to the <structfield>type</structfield> field.</entry>
|
||||
to the <structfield>type</structfield> field. Currently unused.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
@ -182,21 +181,6 @@ is set, then the driver supports reading registers from the device. If
|
|||
<entry>Match the nth chip on the card, zero for the
|
||||
bridge chip. Does not match sub-devices.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>Match an &i2c; chip by its driver name. Can't be used with this ioctl.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>Match a chip by its 7 bit &i2c; bus address. Can't be used with this ioctl.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
|
||||
<entry>3</entry>
|
||||
<entry>Match the nth anciliary AC97 chip. Can't be used with this ioctl.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
|
||||
<entry>4</entry>
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ compiled with the <constant>CONFIG_VIDEO_ADV_DEBUG</constant> option
|
|||
to enable these ioctls.</para>
|
||||
|
||||
<para>To write a register applications must initialize all fields
|
||||
of a &v4l2-dbg-register; and call
|
||||
of a &v4l2-dbg-register; except for <structfield>size</structfield> and call
|
||||
<constant>VIDIOC_DBG_S_REGISTER</constant> with a pointer to this
|
||||
structure. The <structfield>match.type</structfield> and
|
||||
<structfield>match.addr</structfield> or <structfield>match.name</structfield>
|
||||
|
|
@ -91,8 +91,8 @@ written into the register.</para>
|
|||
<structfield>reg</structfield> fields, and call
|
||||
<constant>VIDIOC_DBG_G_REGISTER</constant> with a pointer to this
|
||||
structure. On success the driver stores the register value in the
|
||||
<structfield>val</structfield> field. On failure the structure remains
|
||||
unchanged.</para>
|
||||
<structfield>val</structfield> field and the size (in bytes) of the
|
||||
value in <structfield>size</structfield>.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
|
||||
|
|
@ -101,40 +101,10 @@ on the TV card. The number zero always selects the host chip, ⪚ the
|
|||
chip connected to the PCI or USB bus. You can find out which chips are
|
||||
present with the &VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
|
||||
<structfield>match.name</structfield> contains the I2C driver name.
|
||||
For instance
|
||||
<constant>"saa7127"</constant> will match any chip
|
||||
supported by the saa7127 driver, regardless of its &i2c; bus address.
|
||||
When multiple chips supported by the same driver are present, the
|
||||
effect of these ioctls is undefined. Again with the
|
||||
&VIDIOC-DBG-G-CHIP-INFO; ioctl you can find out which &i2c; chips are
|
||||
present.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>,
|
||||
<structfield>match.addr</structfield> selects a chip by its 7 bit &i2c;
|
||||
bus address.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_AC97</constant>,
|
||||
<structfield>match.addr</structfield> selects the nth AC97 chip
|
||||
on the TV card.</para>
|
||||
|
||||
<para>When <structfield>match.type</structfield> is
|
||||
<constant>V4L2_CHIP_MATCH_SUBDEV</constant>,
|
||||
<structfield>match.addr</structfield> selects the nth sub-device.</para>
|
||||
|
||||
<note>
|
||||
<title>Success not guaranteed</title>
|
||||
|
||||
<para>Due to a flaw in the Linux &i2c; bus driver these ioctls may
|
||||
return successfully without actually reading or writing a register. To
|
||||
catch the most likely failure we recommend a &VIDIOC-DBG-G-CHIP-INFO;
|
||||
call confirming the presence of the selected &i2c; chip.</para>
|
||||
</note>
|
||||
|
||||
<para>These ioctls are optional, not all drivers may support them.
|
||||
However when a driver supports these ioctls it must also support
|
||||
&VIDIOC-DBG-G-CHIP-INFO;. Conversely it may support
|
||||
|
|
@ -150,7 +120,7 @@ LinuxTV v4l-dvb repository; see <ulink
|
|||
url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
|
||||
access instructions.</para>
|
||||
|
||||
<!-- Note for convenience vidioc-dbg-g-chip-ident.sgml
|
||||
<!-- Note for convenience vidioc-dbg-g-chip-info.sgml
|
||||
contains a duplicate of this table. -->
|
||||
<table pgwide="1" frame="none" id="v4l2-dbg-match">
|
||||
<title>struct <structname>v4l2_dbg_match</structname></title>
|
||||
|
|
@ -160,7 +130,7 @@ access instructions.</para>
|
|||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>See <xref linkend="ident-chip-match-types" /> for a list of
|
||||
<entry>See <xref linkend="chip-match-types" /> for a list of
|
||||
possible types.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
|
@ -179,7 +149,7 @@ to the <structfield>type</structfield> field.</entry>
|
|||
<entry>char</entry>
|
||||
<entry><structfield>name[32]</structfield></entry>
|
||||
<entry>Match a chip by this name, interpreted according
|
||||
to the <structfield>type</structfield> field.</entry>
|
||||
to the <structfield>type</structfield> field. Currently unused.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
|
|
@ -198,6 +168,11 @@ to the <structfield>type</structfield> field.</entry>
|
|||
<entry><structfield>match</structfield></entry>
|
||||
<entry>How to match the chip, see <xref linkend="v4l2-dbg-match" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>size</structfield></entry>
|
||||
<entry>The register size in bytes.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u64</entry>
|
||||
<entry><structfield>reg</structfield></entry>
|
||||
|
|
@ -213,7 +188,7 @@ register.</entry>
|
|||
</tgroup>
|
||||
</table>
|
||||
|
||||
<!-- Note for convenience vidioc-dbg-g-chip-ident.sgml
|
||||
<!-- Note for convenience vidioc-dbg-g-chip-info.sgml
|
||||
contains a duplicate of this table. -->
|
||||
<table pgwide="1" frame="none" id="chip-match-types">
|
||||
<title>Chip Match Types</title>
|
||||
|
|
@ -226,21 +201,6 @@ register.</entry>
|
|||
<entry>Match the nth chip on the card, zero for the
|
||||
bridge chip. Does not match sub-devices.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>Match an &i2c; chip by its driver name.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>Match a chip by its 7 bit &i2c; bus address.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
|
||||
<entry>3</entry>
|
||||
<entry>Match the nth anciliary AC97 chip.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
|
||||
<entry>4</entry>
|
||||
|
|
|
|||
|
|
@ -54,7 +54,8 @@ standard automatically. To do so, applications call <constant>
|
|||
VIDIOC_QUERYSTD</constant> with a pointer to a &v4l2-std-id; type. The
|
||||
driver stores here a set of candidates, this can be a single flag or a
|
||||
set of supported standards if for example the hardware can only
|
||||
distinguish between 50 and 60 Hz systems. When detection is not
|
||||
distinguish between 50 and 60 Hz systems. If no signal was detected,
|
||||
then the driver will return V4L2_STD_UNKNOWN. When detection is not
|
||||
possible or fails, the set must contain all standards supported by the
|
||||
current video input or output.</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -94,9 +94,11 @@ Throttling/Upper Limit policy
|
|||
|
||||
Hierarchical Cgroups
|
||||
====================
|
||||
- Currently only CFQ supports hierarchical groups. For throttling,
|
||||
cgroup interface does allow creation of hierarchical cgroups and
|
||||
internally it treats them as flat hierarchy.
|
||||
|
||||
Both CFQ and throttling implement hierarchy support; however,
|
||||
throttling's hierarchy support is enabled iff "sane_behavior" is
|
||||
enabled from cgroup side, which currently is a development option and
|
||||
not publicly available.
|
||||
|
||||
If somebody created a hierarchy like as follows.
|
||||
|
||||
|
|
@ -106,21 +108,20 @@ Hierarchical Cgroups
|
|||
|
|
||||
test3
|
||||
|
||||
CFQ will handle the hierarchy correctly but and throttling will
|
||||
practically treat all groups at same level. For details on CFQ
|
||||
hierarchy support, refer to Documentation/block/cfq-iosched.txt.
|
||||
Throttling will treat the hierarchy as if it looks like the
|
||||
CFQ by default and throttling with "sane_behavior" will handle the
|
||||
hierarchy correctly. For details on CFQ hierarchy support, refer to
|
||||
Documentation/block/cfq-iosched.txt. For throttling, all limits apply
|
||||
to the whole subtree while all statistics are local to the IOs
|
||||
directly generated by tasks in that cgroup.
|
||||
|
||||
Throttling without "sane_behavior" enabled from cgroup side will
|
||||
practically treat all groups at same level as if it looks like the
|
||||
following.
|
||||
|
||||
pivot
|
||||
/ / \ \
|
||||
root test1 test2 test3
|
||||
|
||||
Nesting cgroups, while allowed, isn't officially supported and blkio
|
||||
genereates warning when cgroups nest. Once throttling implements
|
||||
hierarchy support, hierarchy will be supported and the warning will
|
||||
be removed.
|
||||
|
||||
Various user visible config options
|
||||
===================================
|
||||
CONFIG_BLK_CGROUP
|
||||
|
|
|
|||
|
|
@ -6,15 +6,17 @@ Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr>
|
|||
Getting Coccinelle
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The semantic patches included in the kernel use the 'virtual rule'
|
||||
feature which was introduced in Coccinelle version 0.1.11.
|
||||
The semantic patches included in the kernel use features and options
|
||||
which are provided by Coccinelle version 1.0.0-rc11 and above.
|
||||
Using earlier versions will fail as the option names used by
|
||||
the Coccinelle files and coccicheck have been updated.
|
||||
|
||||
Coccinelle (>=0.2.0) is available through the package manager
|
||||
Coccinelle is available through the package manager
|
||||
of many distributions, e.g. :
|
||||
|
||||
- Debian (>=squeeze)
|
||||
- Fedora (>=13)
|
||||
- Ubuntu (>=10.04 Lucid Lynx)
|
||||
- Debian
|
||||
- Fedora
|
||||
- Ubuntu
|
||||
- OpenSUSE
|
||||
- Arch Linux
|
||||
- NetBSD
|
||||
|
|
@ -36,11 +38,6 @@ as a regular user, and install it with
|
|||
|
||||
sudo make install
|
||||
|
||||
The semantic patches in the kernel will work best with Coccinelle version
|
||||
0.2.4 or later. Using earlier versions may incur some parse errors in the
|
||||
semantic patch code, but any results that are obtained should still be
|
||||
correct.
|
||||
|
||||
Using Coccinelle on the Linux kernel
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
@ -48,7 +45,7 @@ A Coccinelle-specific target is defined in the top level
|
|||
Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
|
||||
front-end in the 'scripts' directory.
|
||||
|
||||
Four modes are defined: patch, report, context, and org. The mode to
|
||||
Four basic modes are defined: patch, report, context, and org. The mode to
|
||||
use is specified by setting the MODE variable with 'MODE=<mode>'.
|
||||
|
||||
'patch' proposes a fix, when possible.
|
||||
|
|
@ -62,15 +59,21 @@ diff-like style.Lines of interest are indicated with '-'.
|
|||
'org' generates a report in the Org mode format of Emacs.
|
||||
|
||||
Note that not all semantic patches implement all modes. For easy use
|
||||
of Coccinelle, the default mode is "chain" which tries the previous
|
||||
modes in the order above until one succeeds.
|
||||
of Coccinelle, the default mode is "report".
|
||||
|
||||
Two other modes provide some common combinations of these modes.
|
||||
|
||||
'chain' tries the previous modes in the order above until one succeeds.
|
||||
|
||||
'rep+ctxt' runs successively the report mode and the context mode.
|
||||
It should be used with the C option (described later)
|
||||
which checks the code on a file basis.
|
||||
|
||||
Examples:
|
||||
To make a report for every semantic patch, run the following command:
|
||||
|
||||
make coccicheck MODE=report
|
||||
|
||||
NB: The 'report' mode is the default one.
|
||||
|
||||
To produce patches, run:
|
||||
|
||||
make coccicheck MODE=patch
|
||||
|
|
@ -91,6 +94,11 @@ To enable verbose messages set the V= variable, for example:
|
|||
|
||||
make coccicheck MODE=report V=1
|
||||
|
||||
By default, coccicheck tries to run as parallel as possible. To change
|
||||
the parallelism, set the J= variable. For example, to run across 4 CPUs:
|
||||
|
||||
make coccicheck MODE=report J=4
|
||||
|
||||
|
||||
Using Coccinelle with a single semantic patch
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -124,26 +132,33 @@ To check only newly edited code, use the value 2 for the C flag, i.e.
|
|||
|
||||
make C=2 CHECK="scripts/coccicheck"
|
||||
|
||||
In these modes, which works on a file basis, there is no information
|
||||
about semantic patches displayed, and no commit message proposed.
|
||||
|
||||
This runs every semantic patch in scripts/coccinelle by default. The
|
||||
COCCI variable may additionally be used to only apply a single
|
||||
semantic patch as shown in the previous section.
|
||||
|
||||
The "chain" mode is the default. You can select another one with the
|
||||
The "report" mode is the default. You can select another one with the
|
||||
MODE variable explained above.
|
||||
|
||||
In this mode, there is no information about semantic patches
|
||||
displayed, and no commit message proposed.
|
||||
|
||||
Additional flags
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Additional flags can be passed to spatch through the SPFLAGS
|
||||
variable.
|
||||
|
||||
make SPFLAGS=--use_glimpse coccicheck
|
||||
make SPFLAGS=--use-glimpse coccicheck
|
||||
make SPFLAGS=--use-idutils coccicheck
|
||||
|
||||
See spatch --help to learn more about spatch options.
|
||||
|
||||
Note that the '--use-glimpse' and '--use-idutils' options
|
||||
require external tools for indexing the code. None of them is
|
||||
thus active by default. However, by indexing the code with
|
||||
one of these tools, and according to the cocci file used,
|
||||
spatch could proceed the entire code base more quickly.
|
||||
|
||||
Proposing new semantic patches
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
|
|||
|
|
@ -267,7 +267,7 @@ Q: If i have some kernel code that needs to be aware of CPU arrival and
|
|||
A: This is what you would need in your kernel code to receive notifications.
|
||||
|
||||
#include <linux/cpu.h>
|
||||
static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb,
|
||||
static int foobar_cpu_callback(struct notifier_block *nfb,
|
||||
unsigned long action, void *hcpu)
|
||||
{
|
||||
unsigned int cpu = (unsigned long)hcpu;
|
||||
|
|
@ -285,7 +285,7 @@ A: This is what you would need in your kernel code to receive notifications.
|
|||
return NOTIFY_OK;
|
||||
}
|
||||
|
||||
static struct notifier_block __cpuinitdata foobar_cpu_notifer =
|
||||
static struct notifier_block foobar_cpu_notifer =
|
||||
{
|
||||
.notifier_call = foobar_cpu_callback,
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,126 @@
|
|||
dm-switch
|
||||
=========
|
||||
|
||||
The device-mapper switch target creates a device that supports an
|
||||
arbitrary mapping of fixed-size regions of I/O across a fixed set of
|
||||
paths. The path used for any specific region can be switched
|
||||
dynamically by sending the target a message.
|
||||
|
||||
It maps I/O to underlying block devices efficiently when there is a large
|
||||
number of fixed-sized address regions but there is no simple pattern
|
||||
that would allow for a compact representation of the mapping such as
|
||||
dm-stripe.
|
||||
|
||||
Background
|
||||
----------
|
||||
|
||||
Dell EqualLogic and some other iSCSI storage arrays use a distributed
|
||||
frameless architecture. In this architecture, the storage group
|
||||
consists of a number of distinct storage arrays ("members") each having
|
||||
independent controllers, disk storage and network adapters. When a LUN
|
||||
is created it is spread across multiple members. The details of the
|
||||
spreading are hidden from initiators connected to this storage system.
|
||||
The storage group exposes a single target discovery portal, no matter
|
||||
how many members are being used. When iSCSI sessions are created, each
|
||||
session is connected to an eth port on a single member. Data to a LUN
|
||||
can be sent on any iSCSI session, and if the blocks being accessed are
|
||||
stored on another member the I/O will be forwarded as required. This
|
||||
forwarding is invisible to the initiator. The storage layout is also
|
||||
dynamic, and the blocks stored on disk may be moved from member to
|
||||
member as needed to balance the load.
|
||||
|
||||
This architecture simplifies the management and configuration of both
|
||||
the storage group and initiators. In a multipathing configuration, it
|
||||
is possible to set up multiple iSCSI sessions to use multiple network
|
||||
interfaces on both the host and target to take advantage of the
|
||||
increased network bandwidth. An initiator could use a simple round
|
||||
robin algorithm to send I/O across all paths and let the storage array
|
||||
members forward it as necessary, but there is a performance advantage to
|
||||
sending data directly to the correct member.
|
||||
|
||||
A device-mapper table already lets you map different regions of a
|
||||
device onto different targets. However in this architecture the LUN is
|
||||
spread with an address region size on the order of 10s of MBs, which
|
||||
means the resulting table could have more than a million entries and
|
||||
consume far too much memory.
|
||||
|
||||
Using this device-mapper switch target we can now build a two-layer
|
||||
device hierarchy:
|
||||
|
||||
Upper Tier – Determine which array member the I/O should be sent to.
|
||||
Lower Tier – Load balance amongst paths to a particular member.
|
||||
|
||||
The lower tier consists of a single dm multipath device for each member.
|
||||
Each of these multipath devices contains the set of paths directly to
|
||||
the array member in one priority group, and leverages existing path
|
||||
selectors to load balance amongst these paths. We also build a
|
||||
non-preferred priority group containing paths to other array members for
|
||||
failover reasons.
|
||||
|
||||
The upper tier consists of a single dm-switch device. This device uses
|
||||
a bitmap to look up the location of the I/O and choose the appropriate
|
||||
lower tier device to route the I/O. By using a bitmap we are able to
|
||||
use 4 bits for each address range in a 16 member group (which is very
|
||||
large for us). This is a much denser representation than the dm table
|
||||
b-tree can achieve.
|
||||
|
||||
Construction Parameters
|
||||
=======================
|
||||
|
||||
<num_paths> <region_size> <num_optional_args> [<optional_args>...]
|
||||
[<dev_path> <offset>]+
|
||||
|
||||
<num_paths>
|
||||
The number of paths across which to distribute the I/O.
|
||||
|
||||
<region_size>
|
||||
The number of 512-byte sectors in a region. Each region can be redirected
|
||||
to any of the available paths.
|
||||
|
||||
<num_optional_args>
|
||||
The number of optional arguments. Currently, no optional arguments
|
||||
are supported and so this must be zero.
|
||||
|
||||
<dev_path>
|
||||
The block device that represents a specific path to the device.
|
||||
|
||||
<offset>
|
||||
The offset of the start of data on the specific <dev_path> (in units
|
||||
of 512-byte sectors). This number is added to the sector number when
|
||||
forwarding the request to the specific path. Typically it is zero.
|
||||
|
||||
Messages
|
||||
========
|
||||
|
||||
set_region_mappings <index>:<path_nr> [<index>]:<path_nr> [<index>]:<path_nr>...
|
||||
|
||||
Modify the region table by specifying which regions are redirected to
|
||||
which paths.
|
||||
|
||||
<index>
|
||||
The region number (region size was specified in constructor parameters).
|
||||
If index is omitted, the next region (previous index + 1) is used.
|
||||
Expressed in hexadecimal (WITHOUT any prefix like 0x).
|
||||
|
||||
<path_nr>
|
||||
The path number in the range 0 ... (<num_paths> - 1).
|
||||
Expressed in hexadecimal (WITHOUT any prefix like 0x).
|
||||
|
||||
Status
|
||||
======
|
||||
|
||||
No status line is reported.
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
Assume that you have volumes vg1/switch0 vg1/switch1 vg1/switch2 with
|
||||
the same size.
|
||||
|
||||
Create a switch device with 64kB region size:
|
||||
dmsetup create switch --table "0 `blockdev --getsize /dev/vg1/switch0`
|
||||
switch 3 128 0 /dev/vg1/switch0 0 /dev/vg1/switch1 0 /dev/vg1/switch2 0"
|
||||
|
||||
Set mappings for the first 7 entries to point to devices switch0, switch1,
|
||||
switch2, switch0, switch1, switch2, switch1:
|
||||
dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
|
||||
* ARM Global Timer
|
||||
Cortex-A9 are often associated with a per-core Global timer.
|
||||
|
||||
** Timer node required properties:
|
||||
|
||||
- compatible : Should be "arm,cortex-a9-global-timer"
|
||||
Driver supports versions r2p0 and above.
|
||||
|
||||
- interrupts : One interrupt to each core
|
||||
|
||||
- reg : Specify the base address and the size of the GT timer
|
||||
register window.
|
||||
|
||||
- clocks : Should be phandle to a clock.
|
||||
|
||||
Example:
|
||||
|
||||
timer@2c000600 {
|
||||
compatible = "arm,cortex-a9-global-timer";
|
||||
reg = <0x2c000600 0x20>;
|
||||
interrupts = <1 13 0xf01>;
|
||||
clocks = <&arm_periph_clk>;
|
||||
};
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
Bindings for MEN A21 Watchdog device connected to GPIO lines
|
||||
|
||||
Required properties:
|
||||
- compatible: "men,a021-wdt"
|
||||
- gpios: Specifies the pins that control the Watchdog, order:
|
||||
1: Watchdog enable
|
||||
2: Watchdog fast-mode
|
||||
3: Watchdog trigger
|
||||
4: Watchdog reset cause bit 0
|
||||
5: Watchdog reset cause bit 1
|
||||
6: Watchdog reset cause bit 2
|
||||
|
||||
Optional properties:
|
||||
- None
|
||||
|
||||
Example:
|
||||
watchdog {
|
||||
compatible ="men,a021-wdt";
|
||||
gpios = <&gpio3 9 1 /* WD_EN */
|
||||
&gpio3 10 1 /* WD_FAST */
|
||||
&gpio3 11 1 /* WD_TRIG */
|
||||
&gpio3 6 1 /* RST_CAUSE[0] */
|
||||
&gpio3 7 1 /* RST_CAUSE[1] */
|
||||
&gpio3 8 1>; /* RST_CAUSE[2] */
|
||||
};
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
Device tree bindings for TI's ADS7843, ADS7845, ADS7846, ADS7873, TSC2046
|
||||
SPI driven touch screen controllers.
|
||||
|
||||
The node for this driver must be a child node of a SPI controller, hence
|
||||
all mandatory properties described in
|
||||
|
||||
Documentation/devicetree/bindings/spi/spi-bus.txt
|
||||
|
||||
must be specified.
|
||||
|
||||
Additional required properties:
|
||||
|
||||
compatible Must be one of the following, depending on the
|
||||
model:
|
||||
"ti,tsc2046"
|
||||
"ti,ads7843"
|
||||
"ti,ads7845"
|
||||
"ti,ads7846"
|
||||
"ti,ads7873"
|
||||
|
||||
interrupt-parent
|
||||
interrupts An interrupt node describing the IRQ line the chip's
|
||||
!PENIRQ pin is connected to.
|
||||
vcc-supply A regulator node for the supply voltage.
|
||||
|
||||
|
||||
Optional properties:
|
||||
|
||||
ti,vref-delay-usecs vref supply delay in usecs, 0 for
|
||||
external vref (u16).
|
||||
ti,vref-mv The VREF voltage, in millivolts (u16).
|
||||
ti,keep-vref-on set to keep vref on for differential
|
||||
measurements as well
|
||||
ti,swap-xy swap x and y axis
|
||||
ti,settle-delay-usec Settling time of the analog signals;
|
||||
a function of Vcc and the capacitance
|
||||
on the X/Y drivers. If set to non-zero,
|
||||
two samples are taken with settle_delay
|
||||
us apart, and the second one is used.
|
||||
~150 uSec with 0.01uF caps (u16).
|
||||
ti,penirq-recheck-delay-usecs If set to non-zero, after samples are
|
||||
taken this delay is applied and penirq
|
||||
is rechecked, to help avoid false
|
||||
events. This value is affected by the
|
||||
material used to build the touch layer
|
||||
(u16).
|
||||
ti,x-plate-ohms Resistance of the X-plate,
|
||||
in Ohms (u16).
|
||||
ti,y-plate-ohms Resistance of the Y-plate,
|
||||
in Ohms (u16).
|
||||
ti,x-min Minimum value on the X axis (u16).
|
||||
ti,y-min Minimum value on the Y axis (u16).
|
||||
ti,x-max Maximum value on the X axis (u16).
|
||||
ti,y-max Minimum value on the Y axis (u16).
|
||||
ti,pressure-min Minimum reported pressure value
|
||||
(threshold) - u16.
|
||||
ti,pressure-max Maximum reported pressure value (u16).
|
||||
ti,debounce-max Max number of additional readings per
|
||||
sample (u16).
|
||||
ti,debounce-tol Tolerance used for filtering (u16).
|
||||
ti,debounce-rep Additional consecutive good readings
|
||||
required after the first two (u16).
|
||||
ti,pendown-gpio-debounce Platform specific debounce time for the
|
||||
pendown-gpio (u32).
|
||||
pendown-gpio GPIO handle describing the pin the !PENIRQ
|
||||
line is connected to.
|
||||
linux,wakeup use any event on touchscreen as wakeup event.
|
||||
|
||||
|
||||
Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC::
|
||||
|
||||
spi_controller {
|
||||
tsc2046@0 {
|
||||
reg = <0>; /* CS0 */
|
||||
compatible = "ti,tsc2046";
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <8 0>; /* BOOT6 / GPIO 8 */
|
||||
spi-max-frequency = <1000000>;
|
||||
pendown-gpio = <&gpio1 8 0>;
|
||||
vcc-supply = <®_vcc3>;
|
||||
|
||||
ti,x-min = /bits/ 16 <0>;
|
||||
ti,x-max = /bits/ 16 <8000>;
|
||||
ti,y-min = /bits/ 16 <0>;
|
||||
ti,y-max = /bits/ 16 <4800>;
|
||||
ti,x-plate-ohms = /bits/ 16 <40>;
|
||||
ti,pressure-max = /bits/ 16 <255>;
|
||||
|
||||
linux,wakeup;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
* TI - TSC ADC (Touschscreen and analog digital converter)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Required properties:
|
||||
- child "tsc"
|
||||
ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen
|
||||
support on the platform.
|
||||
ti,x-plate-resistance: X plate resistance
|
||||
ti,coordiante-readouts: The sequencer supports a total of 16
|
||||
programmable steps each step is used to
|
||||
read a single coordinate. A single
|
||||
readout is enough but multiple reads can
|
||||
increase the quality.
|
||||
A value of 5 means, 5 reads for X, 5 for
|
||||
Y and 2 for Z (always). This utilises 12
|
||||
of the 16 software steps available. The
|
||||
remaining 4 can be used by the ADC.
|
||||
ti,wire-config: Different boards could have a different order for
|
||||
connecting wires on touchscreen. We need to provide an
|
||||
8 bit number where in the 1st four bits represent the
|
||||
analog lines and the next 4 bits represent positive/
|
||||
negative terminal on that input line. Notations to
|
||||
represent the input lines and terminals resoectively
|
||||
is as follows:
|
||||
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
|
||||
XP = 0, XN = 1, YP = 2, YN = 3.
|
||||
- child "adc"
|
||||
ti,adc-channels: List of analog inputs available for ADC.
|
||||
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
|
||||
|
||||
Example:
|
||||
tscadc: tscadc@44e0d000 {
|
||||
compatible = "ti,am3359-tscadc";
|
||||
tsc {
|
||||
ti,wires = <4>;
|
||||
ti,x-plate-resistance = <200>;
|
||||
ti,coordiante-readouts = <5>;
|
||||
ti,wire-config = <0x00 0x11 0x22 0x33>;
|
||||
};
|
||||
|
||||
adc {
|
||||
ti,adc-channels = <4 5 6 7>;
|
||||
};
|
||||
}
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
* ARM System MMU Architecture Implementation
|
||||
|
||||
ARM SoCs may contain an implementation of the ARM System Memory
|
||||
Management Unit Architecture, which can be used to provide 1 or 2 stages
|
||||
of address translation to bus masters external to the CPU.
|
||||
|
||||
The SMMU may also raise interrupts in response to various fault
|
||||
conditions.
|
||||
|
||||
** System MMU required properties:
|
||||
|
||||
- compatible : Should be one of:
|
||||
|
||||
"arm,smmu-v1"
|
||||
"arm,smmu-v2"
|
||||
"arm,mmu-400"
|
||||
"arm,mmu-500"
|
||||
|
||||
depending on the particular implementation and/or the
|
||||
version of the architecture implemented.
|
||||
|
||||
- reg : Base address and size of the SMMU.
|
||||
|
||||
- #global-interrupts : The number of global interrupts exposed by the
|
||||
device.
|
||||
|
||||
- interrupts : Interrupt list, with the first #global-irqs entries
|
||||
corresponding to the global interrupts and any
|
||||
following entries corresponding to context interrupts,
|
||||
specified in order of their indexing by the SMMU.
|
||||
|
||||
For SMMUv2 implementations, there must be exactly one
|
||||
interrupt per context bank. In the case of a single,
|
||||
combined interrupt, it must be listed multiple times.
|
||||
|
||||
- mmu-masters : A list of phandles to device nodes representing bus
|
||||
masters for which the SMMU can provide a translation
|
||||
and their corresponding StreamIDs (see example below).
|
||||
Each device node linked from this list must have a
|
||||
"#stream-id-cells" property, indicating the number of
|
||||
StreamIDs associated with it.
|
||||
|
||||
** System MMU optional properties:
|
||||
|
||||
- smmu-parent : When multiple SMMUs are chained together, this
|
||||
property can be used to provide a phandle to the
|
||||
parent SMMU (that is the next SMMU on the path going
|
||||
from the mmu-masters towards memory) node for this
|
||||
SMMU.
|
||||
|
||||
Example:
|
||||
|
||||
smmu {
|
||||
compatible = "arm,smmu-v1";
|
||||
reg = <0xba5e0000 0x10000>;
|
||||
#global-interrupts = <2>;
|
||||
interrupts = <0 32 4>,
|
||||
<0 33 4>,
|
||||
<0 34 4>, /* This is the first context interrupt */
|
||||
<0 35 4>,
|
||||
<0 36 4>,
|
||||
<0 37 4>;
|
||||
|
||||
/*
|
||||
* Two DMA controllers, the first with two StreamIDs (0xd01d
|
||||
* and 0xd01e) and the second with only one (0xd11c).
|
||||
*/
|
||||
mmu-masters = <&dma0 0xd01d 0xd01e>,
|
||||
<&dma1 0xd11c>;
|
||||
};
|
||||
|
|
@ -2,8 +2,10 @@ Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE)
|
|||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "samsung,exynos4212-fimc-lite" for Exynos4212 and
|
||||
Exynos4412 SoCs;
|
||||
- compatible : should be one of:
|
||||
"samsung,exynos4212-fimc-lite" for Exynos4212/4412 SoCs,
|
||||
"samsung,exynos5250-fimc-lite" for Exynos5250 compatible
|
||||
devices;
|
||||
- reg : physical base address and size of the device memory mapped
|
||||
registers;
|
||||
- interrupts : should contain FIMC-LITE interrupt;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,40 @@
|
|||
* Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor
|
||||
|
||||
The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor with
|
||||
an active array size of 2592H x 1944V. It is programmable through a simple
|
||||
two-wire serial interface.
|
||||
|
||||
Required Properties:
|
||||
- compatible: value should be either one among the following
|
||||
(a) "aptina,mt9p031" for mt9p031 sensor
|
||||
(b) "aptina,mt9p031m" for mt9p031m sensor
|
||||
|
||||
- input-clock-frequency: Input clock frequency.
|
||||
|
||||
- pixel-clock-frequency: Pixel clock frequency.
|
||||
|
||||
Optional Properties:
|
||||
- reset-gpios: Chip reset GPIO
|
||||
|
||||
For further reading on port node refer to
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
|
||||
Example:
|
||||
|
||||
i2c0@1c22000 {
|
||||
...
|
||||
...
|
||||
mt9p031@5d {
|
||||
compatible = "aptina,mt9p031";
|
||||
reg = <0x5d>;
|
||||
reset-gpios = <&gpio3 30 0>;
|
||||
|
||||
port {
|
||||
mt9p031_1: endpoint {
|
||||
input-clock-frequency = <6000000>;
|
||||
pixel-clock-frequency = <96000000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
};
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
* Texas Instruments TVP514x video decoder
|
||||
|
||||
The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip
|
||||
digital video decoder that digitizes and decodes all popular baseband analog
|
||||
video formats into digital video component. The tvp514x decoder supports analog-
|
||||
to-digital (A/D) conversion of component RGB and YPbPr signals as well as A/D
|
||||
conversion and decoding of NTSC, PAL and SECAM composite and S-video into
|
||||
component YCbCr.
|
||||
|
||||
Required Properties :
|
||||
- compatible : value should be either one among the following
|
||||
(a) "ti,tvp5146" for tvp5146 decoder.
|
||||
(b) "ti,tvp5146m2" for tvp5146m2 decoder.
|
||||
(c) "ti,tvp5147" for tvp5147 decoder.
|
||||
(d) "ti,tvp5147m1" for tvp5147m1 decoder.
|
||||
|
||||
- hsync-active: HSYNC Polarity configuration for endpoint.
|
||||
|
||||
- vsync-active: VSYNC Polarity configuration for endpoint.
|
||||
|
||||
- pclk-sample: Clock polarity of the endpoint.
|
||||
|
||||
For further reading on port node refer to Documentation/devicetree/bindings/
|
||||
media/video-interfaces.txt.
|
||||
|
||||
Example:
|
||||
|
||||
i2c0@1c22000 {
|
||||
...
|
||||
...
|
||||
tvp514x@5c {
|
||||
compatible = "ti,tvp5146";
|
||||
reg = <0x5c>;
|
||||
|
||||
port {
|
||||
tvp514x_1: endpoint {
|
||||
hsync-active = <1>;
|
||||
vsync-active = <1>;
|
||||
pclk-sample = <0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
};
|
||||
|
|
@ -127,7 +127,6 @@ Example:
|
|||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
/* MIPI CSI-2 bus IF sensor */
|
||||
s5c73m3: sensor@0x1a {
|
||||
|
|
@ -146,6 +145,7 @@ Example:
|
|||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
camera {
|
||||
compatible = "samsung,fimc", "simple-bus";
|
||||
|
|
|
|||
|
|
@ -5,8 +5,8 @@ Required properties:
|
|||
|
||||
- compatible : "samsung,s5pv210-csis" for S5PV210 (S5PC110),
|
||||
"samsung,exynos4210-csis" for Exynos4210 (S5PC210),
|
||||
"samsung,exynos4212-csis" for Exynos4212/Exynos4412
|
||||
SoC series;
|
||||
"samsung,exynos4212-csis" for Exynos4212/Exynos4412,
|
||||
"samsung,exynos5250-csis" for Exynos5250;
|
||||
- reg : offset and length of the register set for the device;
|
||||
- interrupts : should contain MIPI CSIS interrupt; the format of the
|
||||
interrupt specifier depends on the interrupt controller;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
Bindings, specific for the sh_mobile_ceu_camera.c driver:
|
||||
- compatible: Should be "renesas,sh-mobile-ceu"
|
||||
- reg: register base and size
|
||||
- interrupts: the interrupt number
|
||||
- interrupt-parent: the interrupt controller
|
||||
- renesas,max-width: maximum image width, supported on this SoC
|
||||
- renesas,max-height: maximum image height, supported on this SoC
|
||||
|
||||
Example:
|
||||
|
||||
ceu0: ceu@0xfe910000 {
|
||||
compatible = "renesas,sh-mobile-ceu";
|
||||
reg = <0xfe910000 0xa0>;
|
||||
interrupt-parent = <&intcs>;
|
||||
interrupts = <0x880>;
|
||||
renesas,max-width = <8188>;
|
||||
renesas,max-height = <8188>;
|
||||
};
|
||||
|
|
@ -0,0 +1,119 @@
|
|||
* Maxim MAX8998, National/TI LP3974 multi-function device
|
||||
|
||||
The Maxim MAX8998 is a multi-function device which includes voltage/current
|
||||
regulators, real time clock, battery charging controller and several
|
||||
other sub-blocks. It is interfaced using an I2C interface. Each sub-block
|
||||
is addressed by the host system using different i2c slave address.
|
||||
|
||||
PMIC sub-block
|
||||
--------------
|
||||
|
||||
The PMIC sub-block contains a number of voltage and current regulators,
|
||||
with controllable parameters and dynamic voltage scaling capability.
|
||||
In addition, it includes a real time clock and battery charging controller
|
||||
as well. It is accessible at I2C address 0x66.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be one of the following:
|
||||
- "maxim,max8998" for Maxim MAX8998
|
||||
- "national,lp3974" or "ti,lp3974" for National/TI LP3974.
|
||||
- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
|
||||
|
||||
Optional properties:
|
||||
- interrupt-parent: Specifies the phandle of the interrupt controller to which
|
||||
the interrupts from MAX8998 are routed to.
|
||||
- interrupts: Interrupt specifiers for two interrupt sources.
|
||||
- First interrupt specifier is for main interrupt.
|
||||
- Second interrupt specifier is for power-on/-off interrupt.
|
||||
- max8998,pmic-buck1-dvs-gpios: GPIO specifiers for two host gpios used
|
||||
for buck 1 dvs. The format of the gpio specifier depends on the gpio
|
||||
controller.
|
||||
- max8998,pmic-buck2-dvs-gpio: GPIO specifier for host gpio used
|
||||
for buck 2 dvs. The format of the gpio specifier depends on the gpio
|
||||
controller.
|
||||
- max8998,pmic-buck1-default-dvs-idx: Default voltage setting selected from
|
||||
the possible 4 options selectable by the dvs gpios. The value of this
|
||||
property should be 0, 1, 2 or 3. If not specified or out of range,
|
||||
a default value of 0 is taken.
|
||||
- max8998,pmic-buck2-default-dvs-idx: Default voltage setting selected from
|
||||
the possible 2 options selectable by the dvs gpios. The value of this
|
||||
property should be 0 or 1. If not specified or out of range, a default
|
||||
value of 0 is taken.
|
||||
- max8998,pmic-buck-voltage-lock: If present, disallows changing of
|
||||
preprogrammed buck dvfs voltages.
|
||||
|
||||
Additional properties required if max8998,pmic-buck1-dvs-gpios is defined:
|
||||
- max8998,pmic-buck1-dvs-voltage: An array of 4 voltage values in microvolts
|
||||
for buck1 regulator that can be selected using dvs gpio.
|
||||
|
||||
Additional properties required if max8998,pmic-buck2-dvs-gpio is defined:
|
||||
- max8998,pmic-buck2-dvs-voltage: An array of 2 voltage values in microvolts
|
||||
for buck2 regulator that can be selected using dvs gpio.
|
||||
|
||||
Regulators: All the regulators of MAX8998 to be instantiated shall be
|
||||
listed in a child node named 'regulators'. Each regulator is represented
|
||||
by a child node of the 'regulators' node.
|
||||
|
||||
regulator-name {
|
||||
/* standard regulator bindings here */
|
||||
};
|
||||
|
||||
Following regulators of the MAX8998 PMIC block are supported. Note that
|
||||
the 'n' in regulator name, as in LDOn or BUCKn, represents the LDO or BUCK
|
||||
number as described in MAX8998 datasheet.
|
||||
|
||||
- LDOn
|
||||
- valid values for n are 2 to 17
|
||||
- Example: LDO2, LDO10, LDO17
|
||||
- BUCKn
|
||||
- valid values for n are 1 to 4.
|
||||
- Example: BUCK1, BUCK2, BUCK3, BUCK4
|
||||
|
||||
- ENVICHG: Battery Charging Current Monitor Output. This is a fixed
|
||||
voltage type regulator
|
||||
|
||||
- ESAFEOUT1: (ldo19)
|
||||
- ESAFEOUT2: (ld020)
|
||||
|
||||
Standard regulator bindings are used inside regulator subnodes. Check
|
||||
Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
for more details.
|
||||
|
||||
Example:
|
||||
|
||||
pmic@66 {
|
||||
compatible = "maxim,max8998-pmic";
|
||||
reg = <0x66>;
|
||||
interrupt-parent = <&wakeup_eint>;
|
||||
interrupts = <4 0>, <3 0>;
|
||||
|
||||
/* Buck 1 DVS settings */
|
||||
max8998,pmic-buck1-default-dvs-idx = <0>;
|
||||
max8998,pmic-buck1-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */
|
||||
<&gpx0 1 1 0 0>; /* SET2 */
|
||||
max8998,pmic-buck1-dvs-voltage = <1350000>, <1300000>,
|
||||
<1000000>, <950000>;
|
||||
|
||||
/* Buck 2 DVS settings */
|
||||
max8998,pmic-buck2-default-dvs-idx = <0>;
|
||||
max8998,pmic-buck2-dvs-gpio = <&gpx0 0 3 0 0>; /* SET3 */
|
||||
max8998,pmic-buck2-dvs-voltage = <1350000>, <1300000>;
|
||||
|
||||
/* Regulators to instantiate */
|
||||
regulators {
|
||||
ldo2_reg: LDO2 {
|
||||
regulator-name = "VDD_ALIVE_1.1V";
|
||||
regulator-min-microvolt = <1100000>;
|
||||
regulator-max-microvolt = <1100000>;
|
||||
regulator-always-on;
|
||||
};
|
||||
|
||||
buck1_reg: BUCK1 {
|
||||
regulator-name = "VDD_ARM_1.2V";
|
||||
regulator-min-microvolt = <950000>;
|
||||
regulator-max-microvolt = <1350000>;
|
||||
regulator-always-on;
|
||||
regulator-boot-on;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
Texas Instruments TWL family (twl4030) reset and power management module
|
||||
|
||||
The power management module inside the TWL family provides several facilities
|
||||
to control the power resources, including power scripts. For now, the
|
||||
binding only supports the complete shutdown of the system after poweroff.
|
||||
|
||||
Required properties:
|
||||
- compatible : must be "ti,twl4030-power"
|
||||
|
||||
Optional properties:
|
||||
- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
|
||||
SLEEP-to-OFF transition when the system poweroffs.
|
||||
|
||||
Example:
|
||||
&i2c1 {
|
||||
clock-frequency = <2600000>;
|
||||
|
||||
twl: twl@48 {
|
||||
reg = <0x48>;
|
||||
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
|
||||
interrupt-parent = <&intc>;
|
||||
|
||||
twl_power: power {
|
||||
compatible = "ti,twl4030-power";
|
||||
ti,use_poweroff;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -28,6 +28,7 @@ Optional properties:
|
|||
- cap-mmc-highspeed: MMC high-speed timing 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
|
||||
|
||||
*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"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
* Rockchip specific extensions to the Synopsis Designware Mobile
|
||||
Storage Host Controller
|
||||
|
||||
The Synopsis designware mobile storage host controller is used to interface
|
||||
a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
|
||||
differences between the core Synopsis dw mshc controller properties described
|
||||
by synopsis-dw-mshc.txt and the properties used by the Rockchip specific
|
||||
extensions to the Synopsis Designware Mobile Storage Host Controller.
|
||||
|
||||
Required Properties:
|
||||
|
||||
* compatible: should be
|
||||
- "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following
|
||||
|
||||
Example:
|
||||
|
||||
rkdwmmc0@12200000 {
|
||||
compatible = "rockchip,rk2928-dw-mshc";
|
||||
reg = <0x12200000 0x1000>;
|
||||
interrupts = <0 75 0>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
|
|
@ -39,6 +39,19 @@ Required Properties:
|
|||
|
||||
Optional properties:
|
||||
|
||||
* clocks: from common clock binding: handle to biu and ciu clocks for the
|
||||
bus interface unit clock and the card interface unit clock.
|
||||
|
||||
* clock-names: from common clock binding: Shall be "biu" and "ciu".
|
||||
If the biu clock is missing we'll simply skip enabling it. If the
|
||||
ciu clock is missing we'll just assume that the clock is running at
|
||||
clock-frequency. It is an error to omit both the ciu clock and the
|
||||
clock-frequency.
|
||||
|
||||
* clock-frequency: should be the frequency (in Hz) of the ciu clock. If this
|
||||
is specified and the ciu clock is specified then we'll try to set the ciu
|
||||
clock to this at probe time.
|
||||
|
||||
* num-slots: specifies the number of slots supported by the controller.
|
||||
The number of physical slots actually used could be equal or less than the
|
||||
value specified by num-slots. If this property is not specified, the value
|
||||
|
|
@ -55,6 +68,9 @@ Optional properties:
|
|||
|
||||
* broken-cd: as documented in mmc core bindings.
|
||||
|
||||
* vmmc-supply: The phandle to the regulator to use for vmmc. If this is
|
||||
specified we'll defer probe until we can find this regulator.
|
||||
|
||||
Aliases:
|
||||
|
||||
- All the MSHC controller nodes should be represented in the aliases node using
|
||||
|
|
@ -67,6 +83,8 @@ board specific portions as listed below.
|
|||
|
||||
dwmmc0@12200000 {
|
||||
compatible = "snps,dw-mshc";
|
||||
clocks = <&clock 351>, <&clock 132>;
|
||||
clock-names = "biu", "ciu";
|
||||
reg = <0x12200000 0x1000>;
|
||||
interrupts = <0 75 0>;
|
||||
#address-cells = <1>;
|
||||
|
|
@ -74,11 +92,13 @@ board specific portions as listed below.
|
|||
};
|
||||
|
||||
dwmmc0@12200000 {
|
||||
clock-frequency = <400000000>;
|
||||
num-slots = <1>;
|
||||
supports-highspeed;
|
||||
broken-cd;
|
||||
fifo-depth = <0x80>;
|
||||
card-detect-delay = <200>;
|
||||
vmmc-supply = <&buck8>;
|
||||
|
||||
slot@0 {
|
||||
reg = <0>;
|
||||
|
|
|
|||
|
|
@ -0,0 +1,22 @@
|
|||
* Allwinner EMAC ethernet controller
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "allwinner,sun4i-emac".
|
||||
- reg: address and length of the register set for the device.
|
||||
- interrupts: interrupt for the device
|
||||
- phy: A phandle to a phy node defining the PHY address (as the reg
|
||||
property, a single integer).
|
||||
- clocks: A phandle to the reference clock for this device
|
||||
|
||||
Optional properties:
|
||||
- (local-)mac-address: mac address to be used by this driver
|
||||
|
||||
Example:
|
||||
|
||||
emac: ethernet@01c0b000 {
|
||||
compatible = "allwinner,sun4i-emac";
|
||||
reg = <0x01c0b000 0x1000>;
|
||||
interrupts = <55>;
|
||||
clocks = <&ahb_gates 17>;
|
||||
phy = <&phy0>;
|
||||
};
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
* Allwinner A10 MDIO Ethernet Controller interface
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "allwinner,sun4i-mdio".
|
||||
- reg: address and length of the register set for the device.
|
||||
|
||||
Optional properties:
|
||||
- phy-supply: phandle to a regulator if the PHY needs one
|
||||
|
||||
Example at the SoC level:
|
||||
mdio@01c0b080 {
|
||||
compatible = "allwinner,sun4i-mdio";
|
||||
reg = <0x01c0b080 0x14>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
|
||||
And at the board level:
|
||||
|
||||
mdio@01c0b080 {
|
||||
phy-supply = <®_emac_3v3>;
|
||||
|
||||
phy0: ethernet-phy@0 {
|
||||
reg = <0>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
* Synopsys ARC EMAC 10/100 Ethernet driver (EMAC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "snps,arc-emac"
|
||||
- reg: Address and length of the register set for the device
|
||||
- interrupts: Should contain the EMAC interrupts
|
||||
- clock-frequency: CPU frequency. It is needed to calculate and set polling
|
||||
period of EMAC.
|
||||
- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations
|
||||
bandwidth of external memory controller might be a limiting factor. That's why
|
||||
it's required to specify which data-rate is supported on current SoC or FPGA.
|
||||
For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s is
|
||||
supported (100BASE-TX) set "100".
|
||||
- phy: PHY device attached to the EMAC via MDIO bus
|
||||
|
||||
Child nodes of the driver are the individual PHY devices connected to the
|
||||
MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus.
|
||||
|
||||
Optional properties:
|
||||
- mac-address: 6 bytes, mac address
|
||||
|
||||
Examples:
|
||||
|
||||
ethernet@c0fc2000 {
|
||||
compatible = "snps,arc-emac";
|
||||
reg = <0xc0fc2000 0x3c>;
|
||||
interrupts = <6>;
|
||||
mac-address = [ 00 11 22 33 44 55 ];
|
||||
clock-frequency = <80000000>;
|
||||
max-speed = <100>;
|
||||
phy = <&phy0>;
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
phy0: ethernet-phy@0 {
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -16,6 +16,8 @@ Optional properties:
|
|||
|
||||
- clock-frequency : The oscillator frequency driving the flexcan device
|
||||
|
||||
- xceiver-supply: Regulator that powers the CAN transceiver
|
||||
|
||||
Example:
|
||||
|
||||
can@1c000 {
|
||||
|
|
|
|||
|
|
@ -28,6 +28,8 @@ Optional properties:
|
|||
Slave Properties:
|
||||
Required properties:
|
||||
- phy_id : Specifies slave phy id
|
||||
- phy-mode : The interface between the SoC and the PHY (a string
|
||||
that of_get_phy_mode() can understand)
|
||||
- mac-address : Specifies slave MAC address
|
||||
|
||||
Optional properties:
|
||||
|
|
@ -58,11 +60,13 @@ Examples:
|
|||
cpts_clock_shift = <29>;
|
||||
cpsw_emac0: slave@0 {
|
||||
phy_id = <&davinci_mdio>, <0>;
|
||||
phy-mode = "rgmii-txid";
|
||||
/* Filled in by U-Boot */
|
||||
mac-address = [ 00 00 00 00 00 00 ];
|
||||
};
|
||||
cpsw_emac1: slave@1 {
|
||||
phy_id = <&davinci_mdio>, <1>;
|
||||
phy-mode = "rgmii-txid";
|
||||
/* Filled in by U-Boot */
|
||||
mac-address = [ 00 00 00 00 00 00 ];
|
||||
};
|
||||
|
|
@ -84,11 +88,13 @@ Examples:
|
|||
cpts_clock_shift = <29>;
|
||||
cpsw_emac0: slave@0 {
|
||||
phy_id = <&davinci_mdio>, <0>;
|
||||
phy-mode = "rgmii-txid";
|
||||
/* Filled in by U-Boot */
|
||||
mac-address = [ 00 00 00 00 00 00 ];
|
||||
};
|
||||
cpsw_emac1: slave@1 {
|
||||
phy_id = <&davinci_mdio>, <1>;
|
||||
phy-mode = "rgmii-txid";
|
||||
/* Filled in by U-Boot */
|
||||
mac-address = [ 00 00 00 00 00 00 ];
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
Davicom DM9000 Fast Ethernet controller
|
||||
|
||||
Required properties:
|
||||
- compatible = "davicom,dm9000";
|
||||
- reg : physical addresses and sizes of registers, must contain 2 entries:
|
||||
first entry : address register,
|
||||
second entry : data register.
|
||||
- interrupt-parent : interrupt controller to which the device is connected
|
||||
- interrupts : interrupt specifier specific to interrupt controller
|
||||
|
||||
Optional properties:
|
||||
- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address
|
||||
to use (from firmware or bootloader)
|
||||
- davicom,no-eeprom : Configuration EEPROM is not available
|
||||
- davicom,ext-phy : Use external PHY
|
||||
|
||||
Example:
|
||||
|
||||
ethernet@18000000 {
|
||||
compatible = "davicom,dm9000";
|
||||
reg = <0x18000000 0x2 0x18000004 0x2>;
|
||||
interrupt-parent = <&gpn>;
|
||||
interrupts = <7 4>;
|
||||
local-mac-address = [00 00 de ad be ef];
|
||||
davicom,no-eeprom;
|
||||
};
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
Marvell Orion/Discovery ethernet controller
|
||||
=============================================
|
||||
|
||||
The Marvell Discovery ethernet controller can be found on Marvell Orion SoCs
|
||||
(Kirkwood, Dove, Orion5x, and Discovery Innovation) and as part of Marvell
|
||||
Discovery system controller chips (mv64[345]60).
|
||||
|
||||
The Discovery ethernet controller is described with two levels of nodes. The
|
||||
first level describes the ethernet controller itself and the second level
|
||||
describes up to 3 ethernet port nodes within that controller. The reason for
|
||||
the multiple levels is that the port registers are interleaved within a single
|
||||
set of controller registers. Each port node describes port-specific properties.
|
||||
|
||||
Note: The above separation is only true for Discovery system controllers.
|
||||
For Orion SoCs we stick to the separation, although there each controller has
|
||||
only one port associated. Multiple ports are implemented as multiple single-port
|
||||
controllers. As Kirkwood has some issues with proper initialization after reset,
|
||||
an extra compatible string is added for it.
|
||||
|
||||
* Ethernet controller node
|
||||
|
||||
Required controller properties:
|
||||
- #address-cells: shall be 1.
|
||||
- #size-cells: shall be 0.
|
||||
- compatible: shall be one of "marvell,orion-eth", "marvell,kirkwood-eth".
|
||||
- reg: address and length of the controller registers.
|
||||
|
||||
Optional controller properties:
|
||||
- clocks: phandle reference to the controller clock.
|
||||
- marvell,tx-checksum-limit: max tx packet size for hardware checksum.
|
||||
|
||||
* Ethernet port node
|
||||
|
||||
Required port properties:
|
||||
- device_type: shall be "network".
|
||||
- compatible: shall be one of "marvell,orion-eth-port",
|
||||
"marvell,kirkwood-eth-port".
|
||||
- reg: port number relative to ethernet controller, shall be 0, 1, or 2.
|
||||
- interrupts: port interrupt.
|
||||
- local-mac-address: 6 bytes MAC address.
|
||||
|
||||
Optional port properties:
|
||||
- marvell,tx-queue-size: size of the transmit ring buffer.
|
||||
- marvell,tx-sram-addr: address of transmit descriptor buffer located in SRAM.
|
||||
- marvell,tx-sram-size: size of transmit descriptor buffer located in SRAM.
|
||||
- marvell,rx-queue-size: size of the receive ring buffer.
|
||||
- marvell,rx-sram-addr: address of receive descriptor buffer located in SRAM.
|
||||
- marvell,rx-sram-size: size of receive descriptor buffer located in SRAM.
|
||||
|
||||
and
|
||||
|
||||
- phy-handle: phandle reference to ethernet PHY.
|
||||
|
||||
or
|
||||
|
||||
- speed: port speed if no PHY connected.
|
||||
- duplex: port mode if no PHY connected.
|
||||
|
||||
* Node example:
|
||||
|
||||
mdio-bus {
|
||||
...
|
||||
ethphy: ethernet-phy@8 {
|
||||
device_type = "ethernet-phy";
|
||||
...
|
||||
};
|
||||
};
|
||||
|
||||
eth: ethernet-controller@72000 {
|
||||
compatible = "marvell,orion-eth";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0x72000 0x2000>;
|
||||
clocks = <&gate_clk 2>;
|
||||
marvell,tx-checksum-limit = <1600>;
|
||||
|
||||
ethernet@0 {
|
||||
device_type = "network";
|
||||
compatible = "marvell,orion-eth-port";
|
||||
reg = <0>;
|
||||
interrupts = <29>;
|
||||
phy-handle = <ðphy>;
|
||||
local-mac-address = [00 00 00 00 00 00];
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
Micrel KS8851 Ethernet mac
|
||||
|
||||
Required properties:
|
||||
- compatible = "micrel,ks8851-ml" of parallel interface
|
||||
- reg : 2 physical address and size of registers for data and command
|
||||
- interrupts : interrupt connection
|
||||
|
||||
Optional properties:
|
||||
- local-mac-address : Ethernet mac address to use
|
||||
|
|
@ -12,6 +12,16 @@ Required properties:
|
|||
property
|
||||
- phy-mode: String, operation mode of the PHY interface.
|
||||
Supported values are: "mii", "rmii", "gmii", "rgmii".
|
||||
- snps,phy-addr phy address to connect to.
|
||||
- snps,reset-gpio gpio number for phy reset.
|
||||
- snps,reset-active-low boolean flag to indicate if phy reset is active low.
|
||||
- snps,reset-delays-us is triplet of delays
|
||||
The 1st cell is reset pre-delay in micro seconds.
|
||||
The 2nd cell is reset pulse in micro seconds.
|
||||
The 3rd cell is reset post-delay in micro seconds.
|
||||
- snps,pbl Programmable Burst Length
|
||||
- snps,fixed-burst Program the DMA to use the fixed burst mode
|
||||
- snps,mixed-burst Program the DMA to use the mixed burst mode
|
||||
|
||||
Optional properties:
|
||||
- mac-address: 6 bytes, mac address
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
* VIA Velocity 10/100/1000 Network Controller
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "via,velocity-vt6110"
|
||||
- reg : Address and length of the io space
|
||||
- interrupts : Should contain the controller interrupt line
|
||||
|
||||
Optional properties:
|
||||
- no-eeprom : PCI network cards use an external EEPROM to store data. Embedded
|
||||
devices quite often set this data in uboot and do not provide an eeprom.
|
||||
Specify this option if you have no external eeprom.
|
||||
|
||||
Examples:
|
||||
|
||||
eth0@d8004000 {
|
||||
compatible = "via,velocity-vt6110";
|
||||
reg = <0xd8004000 0x400>;
|
||||
interrupts = <10>;
|
||||
no-eeprom;
|
||||
};
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
Binding for TI/National Semiconductor LP8727 Charger
|
||||
|
||||
Required properties:
|
||||
- compatible: "ti,lp8727"
|
||||
- reg: I2C slave address 27h
|
||||
|
||||
Optional properties:
|
||||
- interrupt-parent: interrupt controller node (see interrupt binding[0])
|
||||
- interrupts: interrupt specifier (see interrupt binding[0])
|
||||
- debounce-ms: interrupt debounce time. (u32)
|
||||
|
||||
AC and USB charging parameters
|
||||
- charger-type: "ac" or "usb" (string)
|
||||
- eoc-level: value of 'enum lp8727_eoc_level' (u8)
|
||||
- charging-current: value of 'enum lp8727_ichg' (u8)
|
||||
|
||||
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
|
||||
|
||||
Example)
|
||||
|
||||
lp8727@27 {
|
||||
compatible = "ti,lp8727";
|
||||
reg = <0x27>;
|
||||
|
||||
/* GPIO 134 is used for LP8728 interrupt pin */
|
||||
interrupt-parent = <&gpio5>; /* base = 128 */
|
||||
interrupts = <6 0x2>; /* offset = 6, falling edge type */
|
||||
|
||||
debounce-ms = <300>;
|
||||
|
||||
/* AC charger: 5% EOC and 500mA charging current */
|
||||
ac {
|
||||
charger-type = "ac";
|
||||
eoc-level = /bits/ 8 <0>;
|
||||
charging-current = /bits/ 8 <4>;
|
||||
};
|
||||
|
||||
/* USB charger: 10% EOC and 400mA charging current */
|
||||
usb {
|
||||
charger-type = "usb";
|
||||
eoc-level = /bits/ 8 <1>;
|
||||
charging-current = /bits/ 8 <2>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
NXP PCA9685 16-channel 12-bit PWM LED controller
|
||||
================================================
|
||||
|
||||
Required properties:
|
||||
- compatible: "nxp,pca9685-pwm"
|
||||
- #pwm-cells: should be 2. The first cell specifies the per-chip index
|
||||
of the PWM to use and the second cell is the period in nanoseconds.
|
||||
The index 16 is the ALLCALL channel, that sets all PWM channels at the same
|
||||
time.
|
||||
|
||||
Optional properties:
|
||||
- invert (bool): boolean to enable inverted logic
|
||||
- open-drain (bool): boolean to configure outputs with open-drain structure;
|
||||
if omitted use totem-pole structure
|
||||
|
||||
Example:
|
||||
|
||||
For LEDs that are directly connected to the PCA, the following setting is
|
||||
applicable:
|
||||
|
||||
pca: pca@41 {
|
||||
compatible = "nxp,pca9685-pwm";
|
||||
#pwm-cells = <2>;
|
||||
reg = <0x41>;
|
||||
invert;
|
||||
open-drain;
|
||||
};
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
* Maxim MAX8997 Voltage and Current Regulator
|
||||
|
||||
The Maxim MAX8997 is a multi-function device which includes volatage and
|
||||
The Maxim MAX8997 is a multi-function device which includes voltage and
|
||||
current regulators, rtc, charger controller and other sub-blocks. It is
|
||||
interfaced to the host controller using a i2c interface. Each sub-block is
|
||||
addressed by the host system using different i2c slave address. This document
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
* Samsung S5M8767 Voltage and Current Regulator
|
||||
|
||||
The Samsung S5M8767 is a multi-function device which includes volatage and
|
||||
The Samsung S5M8767 is a multi-function device which includes voltage and
|
||||
current regulators, rtc, charger controller and other sub-blocks. It is
|
||||
interfaced to the host controller using a i2c interface. Each sub-block is
|
||||
addressed by the host system using different i2c slave address. This document
|
||||
|
|
@ -103,13 +103,13 @@ Example:
|
|||
|
||||
s5m8767,pmic-buck-default-dvs-idx = <0>;
|
||||
|
||||
s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 1 0 0>, /* DVS1 */
|
||||
<&gpx0 1 1 0 0>, /* DVS2 */
|
||||
<&gpx0 2 1 0 0>; /* DVS3 */
|
||||
s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 0>, /* DVS1 */
|
||||
<&gpx0 1 0>, /* DVS2 */
|
||||
<&gpx0 2 0>; /* DVS3 */
|
||||
|
||||
s5m8767,pmic-buck-ds-gpios = <&gpx2 3 1 0 0>, /* SET1 */
|
||||
<&gpx2 4 1 0 0>, /* SET2 */
|
||||
<&gpx2 5 1 0 0>; /* SET3 */
|
||||
s5m8767,pmic-buck-ds-gpios = <&gpx2 3 0>, /* SET1 */
|
||||
<&gpx2 4 0>, /* SET2 */
|
||||
<&gpx2 5 0>; /* SET3 */
|
||||
|
||||
s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>,
|
||||
<1250000>, <1200000>,
|
||||
|
|
|
|||
|
|
@ -18,20 +18,20 @@ For twl6030 regulators/LDOs
|
|||
- "ti,twl6030-vdd1" for VDD1 SMPS
|
||||
- "ti,twl6030-vdd2" for VDD2 SMPS
|
||||
- "ti,twl6030-vdd3" for VDD3 SMPS
|
||||
For twl6025 regulators/LDOs
|
||||
For twl6032 regulators/LDOs
|
||||
- compatible:
|
||||
- "ti,twl6025-ldo1" for LDO1 LDO
|
||||
- "ti,twl6025-ldo2" for LDO2 LDO
|
||||
- "ti,twl6025-ldo3" for LDO3 LDO
|
||||
- "ti,twl6025-ldo4" for LDO4 LDO
|
||||
- "ti,twl6025-ldo5" for LDO5 LDO
|
||||
- "ti,twl6025-ldo6" for LDO6 LDO
|
||||
- "ti,twl6025-ldo7" for LDO7 LDO
|
||||
- "ti,twl6025-ldoln" for LDOLN LDO
|
||||
- "ti,twl6025-ldousb" for LDOUSB LDO
|
||||
- "ti,twl6025-smps3" for SMPS3 SMPS
|
||||
- "ti,twl6025-smps4" for SMPS4 SMPS
|
||||
- "ti,twl6025-vio" for VIO SMPS
|
||||
- "ti,twl6032-ldo1" for LDO1 LDO
|
||||
- "ti,twl6032-ldo2" for LDO2 LDO
|
||||
- "ti,twl6032-ldo3" for LDO3 LDO
|
||||
- "ti,twl6032-ldo4" for LDO4 LDO
|
||||
- "ti,twl6032-ldo5" for LDO5 LDO
|
||||
- "ti,twl6032-ldo6" for LDO6 LDO
|
||||
- "ti,twl6032-ldo7" for LDO7 LDO
|
||||
- "ti,twl6032-ldoln" for LDOLN LDO
|
||||
- "ti,twl6032-ldousb" for LDOUSB LDO
|
||||
- "ti,twl6032-smps3" for SMPS3 SMPS
|
||||
- "ti,twl6032-smps4" for SMPS4 SMPS
|
||||
- "ti,twl6032-vio" for VIO SMPS
|
||||
For twl4030 regulators/LDOs
|
||||
- compatible:
|
||||
- "ti,twl4030-vaux1" for VAUX1 LDO
|
||||
|
|
|
|||
|
|
@ -17,8 +17,9 @@ Required properties:
|
|||
- interrupts : this entry should indicate which interrupt line
|
||||
the talert signal is routed to;
|
||||
Specific:
|
||||
- ti,tshut-gpio : this entry should be used to inform which GPIO
|
||||
line the tshut signal is routed to;
|
||||
- gpios : this entry should be used to inform which GPIO
|
||||
line the tshut signal is routed to. The informed GPIO will
|
||||
be treated as an IRQ;
|
||||
- regs : this entry must also be specified and it is specific
|
||||
to each bandgap version, because the mapping may change from
|
||||
soc to soc, apart of depending on available features.
|
||||
|
|
@ -37,7 +38,7 @@ bandgap {
|
|||
0x4a002378 0x18>;
|
||||
compatible = "ti,omap4460-bandgap";
|
||||
interrupts = <0 126 4>; /* talert */
|
||||
ti,tshut-gpio = <86>;
|
||||
gpios = <&gpio3 22 0>; /* tshut */
|
||||
};
|
||||
|
||||
OMAP4470:
|
||||
|
|
@ -47,7 +48,7 @@ bandgap {
|
|||
0x4a002378 0x18>;
|
||||
compatible = "ti,omap4470-bandgap";
|
||||
interrupts = <0 126 4>; /* talert */
|
||||
ti,tshut-gpio = <86>;
|
||||
gpios = <&gpio3 22 0>; /* tshut */
|
||||
};
|
||||
|
||||
OMAP5430:
|
||||
|
|
@ -59,3 +60,15 @@ bandgap {
|
|||
compatible = "ti,omap5430-bandgap";
|
||||
interrupts = <0 126 4>; /* talert */
|
||||
};
|
||||
|
||||
DRA752:
|
||||
bandgap {
|
||||
reg = <0x4a0021e0 0xc
|
||||
0x4a00232c 0xc
|
||||
0x4a002380 0x2c
|
||||
0x4a0023C0 0x3c
|
||||
0x4a002564 0x8
|
||||
0x4a002574 0x50>;
|
||||
compatible = "ti,dra752-bandgap";
|
||||
interrupts = <0 126 4>; /* talert */
|
||||
};
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
Marvell Orion SoC timer
|
||||
|
||||
Required properties:
|
||||
- compatible: shall be "marvell,orion-timer"
|
||||
- reg: base address of the timer register starting with TIMERS CONTROL register
|
||||
- interrupt-parent: phandle of the bridge interrupt controller
|
||||
- interrupts: should contain the interrupts for Timer0 and Timer1
|
||||
- clocks: phandle of timer reference clock (tclk)
|
||||
|
||||
Example:
|
||||
timer: timer {
|
||||
compatible = "marvell,orion-timer";
|
||||
reg = <0x20300 0x20>;
|
||||
interrupt-parent = <&bridge_intc>;
|
||||
interrupts = <1>, <2>;
|
||||
clocks = <&core_clk 0>;
|
||||
};
|
||||
|
|
@ -8,7 +8,7 @@ TWL6030 USB COMPARATOR
|
|||
usb interrupt number that raises VBUS interrupts when the controller has to
|
||||
act as device
|
||||
- usb-supply : phandle to the regulator device tree node. It should be vusb
|
||||
if it is twl6030 or ldousb if it is twl6025 subclass.
|
||||
if it is twl6030 or ldousb if it is twl6032 subclass.
|
||||
|
||||
twl6030-usb {
|
||||
compatible = "ti,twl6030-usb";
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ chrp Common Hardware Reference Platform
|
|||
cirrus Cirrus Logic, Inc.
|
||||
cortina Cortina Systems, Inc.
|
||||
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
|
||||
davicom DAVICOM Semiconductor, Inc.
|
||||
denx Denx Software Engineering
|
||||
emmicro EM Microelectronic
|
||||
epson Seiko Epson Corp.
|
||||
|
|
|
|||
|
|
@ -5,9 +5,14 @@ Required properties:
|
|||
- compatible : should be "brcm,bcm2835-pm-wdt"
|
||||
- reg : Specifies base physical address and size of the registers.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- timeout-sec : Contains the watchdog timeout in seconds
|
||||
|
||||
Example:
|
||||
|
||||
watchdog {
|
||||
compatible = "brcm,bcm2835-pm-wdt";
|
||||
reg = <0x7e100000 0x28>;
|
||||
timeout-sec = <10>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -18,6 +18,8 @@ Mount Options
|
|||
=============
|
||||
|
||||
When mounting an XFS filesystem, the following options are accepted.
|
||||
For boolean mount options, the names with the (*) suffix is the
|
||||
default behaviour.
|
||||
|
||||
allocsize=size
|
||||
Sets the buffered I/O end-of-file preallocation size when
|
||||
|
|
@ -25,97 +27,128 @@ When mounting an XFS filesystem, the following options are accepted.
|
|||
Valid values for this option are page size (typically 4KiB)
|
||||
through to 1GiB, inclusive, in power-of-2 increments.
|
||||
|
||||
attr2/noattr2
|
||||
The options enable/disable (default is disabled for backward
|
||||
compatibility on-disk) an "opportunistic" improvement to be
|
||||
made in the way inline extended attributes are stored on-disk.
|
||||
When the new form is used for the first time (by setting or
|
||||
removing extended attributes) the on-disk superblock feature
|
||||
bit field will be updated to reflect this format being in use.
|
||||
The default behaviour is for dynamic end-of-file
|
||||
preallocation size, which uses a set of heuristics to
|
||||
optimise the preallocation size based on the current
|
||||
allocation patterns within the file and the access patterns
|
||||
to the file. Specifying a fixed allocsize value turns off
|
||||
the dynamic behaviour.
|
||||
|
||||
attr2
|
||||
noattr2
|
||||
The options enable/disable an "opportunistic" improvement to
|
||||
be made in the way inline extended attributes are stored
|
||||
on-disk. When the new form is used for the first time when
|
||||
attr2 is selected (either when setting or removing extended
|
||||
attributes) the on-disk superblock feature bit field will be
|
||||
updated to reflect this format being in use.
|
||||
|
||||
The default behaviour is determined by the on-disk feature
|
||||
bit indicating that attr2 behaviour is active. If either
|
||||
mount option it set, then that becomes the new default used
|
||||
by the filesystem.
|
||||
|
||||
CRC enabled filesystems always use the attr2 format, and so
|
||||
will reject the noattr2 mount option if it is set.
|
||||
|
||||
barrier
|
||||
Enables the use of block layer write barriers for writes into
|
||||
the journal and unwritten extent conversion. This allows for
|
||||
drive level write caching to be enabled, for devices that
|
||||
support write barriers.
|
||||
barrier (*)
|
||||
nobarrier
|
||||
Enables/disables the use of block layer write barriers for
|
||||
writes into the journal and for data integrity operations.
|
||||
This allows for drive level write caching to be enabled, for
|
||||
devices that support write barriers.
|
||||
|
||||
discard
|
||||
Issue command to let the block device reclaim space freed by the
|
||||
filesystem. This is useful for SSD devices, thinly provisioned
|
||||
LUNs and virtual machine images, but may have a performance
|
||||
impact.
|
||||
nodiscard (*)
|
||||
Enable/disable the issuing of commands to let the block
|
||||
device reclaim space freed by the filesystem. This is
|
||||
useful for SSD devices, thinly provisioned LUNs and virtual
|
||||
machine images, but may have a performance impact.
|
||||
|
||||
dmapi
|
||||
Enable the DMAPI (Data Management API) event callouts.
|
||||
Use with the "mtpt" option.
|
||||
Note: It is currently recommended that you use the fstrim
|
||||
application to discard unused blocks rather than the discard
|
||||
mount option because the performance impact of this option
|
||||
is quite severe.
|
||||
|
||||
grpid/bsdgroups and nogrpid/sysvgroups
|
||||
These options define what group ID a newly created file gets.
|
||||
When grpid is set, it takes the group ID of the directory in
|
||||
which it is created; otherwise (the default) it takes the fsgid
|
||||
of the current process, unless the directory has the setgid bit
|
||||
set, in which case it takes the gid from the parent directory,
|
||||
and also gets the setgid bit set if it is a directory itself.
|
||||
grpid/bsdgroups
|
||||
nogrpid/sysvgroups (*)
|
||||
These options define what group ID a newly created file
|
||||
gets. When grpid is set, it takes the group ID of the
|
||||
directory in which it is created; otherwise it takes the
|
||||
fsgid of the current process, unless the directory has the
|
||||
setgid bit set, in which case it takes the gid from the
|
||||
parent directory, and also gets the setgid bit set if it is
|
||||
a directory itself.
|
||||
|
||||
ihashsize=value
|
||||
In memory inode hashes have been removed, so this option has
|
||||
no function as of August 2007. Option is deprecated.
|
||||
filestreams
|
||||
Make the data allocator use the filestreams allocation mode
|
||||
across the entire filesystem rather than just on directories
|
||||
configured to use it.
|
||||
|
||||
ikeep/noikeep
|
||||
When ikeep is specified, XFS does not delete empty inode clusters
|
||||
and keeps them around on disk. ikeep is the traditional XFS
|
||||
behaviour. When noikeep is specified, empty inode clusters
|
||||
are returned to the free space pool. The default is noikeep for
|
||||
non-DMAPI mounts, while ikeep is the default when DMAPI is in use.
|
||||
|
||||
inode64
|
||||
Indicates that XFS is allowed to create inodes at any location
|
||||
in the filesystem, including those which will result in inode
|
||||
numbers occupying more than 32 bits of significance. This is
|
||||
the default allocation option. Applications which do not handle
|
||||
inode numbers bigger than 32 bits, should use inode32 option.
|
||||
ikeep
|
||||
noikeep (*)
|
||||
When ikeep is specified, XFS does not delete empty inode
|
||||
clusters and keeps them around on disk. When noikeep is
|
||||
specified, empty inode clusters are returned to the free
|
||||
space pool.
|
||||
|
||||
inode32
|
||||
Indicates that XFS is limited to create inodes at locations which
|
||||
will not result in inode numbers with more than 32 bits of
|
||||
significance. This is provided for backwards compatibility, since
|
||||
64 bits inode numbers might cause problems for some applications
|
||||
that cannot handle large inode numbers.
|
||||
inode64 (*)
|
||||
When inode32 is specified, it indicates that XFS limits
|
||||
inode creation to locations which will not result in inode
|
||||
numbers with more than 32 bits of significance.
|
||||
|
||||
largeio/nolargeio
|
||||
When inode64 is specified, it indicates that XFS is allowed
|
||||
to create inodes at any location in the filesystem,
|
||||
including those which will result in inode numbers occupying
|
||||
more than 32 bits of significance.
|
||||
|
||||
inode32 is provided for backwards compatibility with older
|
||||
systems and applications, since 64 bits inode numbers might
|
||||
cause problems for some applications that cannot handle
|
||||
large inode numbers. If applications are in use which do
|
||||
not handle inode numbers bigger than 32 bits, the inode32
|
||||
option should be specified.
|
||||
|
||||
|
||||
largeio
|
||||
nolargeio (*)
|
||||
If "nolargeio" is specified, the optimal I/O reported in
|
||||
st_blksize by stat(2) will be as small as possible to allow user
|
||||
applications to avoid inefficient read/modify/write I/O.
|
||||
If "largeio" specified, a filesystem that has a "swidth" specified
|
||||
will return the "swidth" value (in bytes) in st_blksize. If the
|
||||
filesystem does not have a "swidth" specified but does specify
|
||||
an "allocsize" then "allocsize" (in bytes) will be returned
|
||||
instead.
|
||||
If neither of these two options are specified, then filesystem
|
||||
will behave as if "nolargeio" was specified.
|
||||
st_blksize by stat(2) will be as small as possible to allow
|
||||
user applications to avoid inefficient read/modify/write
|
||||
I/O. This is typically the page size of the machine, as
|
||||
this is the granularity of the page cache.
|
||||
|
||||
If "largeio" specified, a filesystem that was created with a
|
||||
"swidth" specified will return the "swidth" value (in bytes)
|
||||
in st_blksize. If the filesystem does not have a "swidth"
|
||||
specified but does specify an "allocsize" then "allocsize"
|
||||
(in bytes) will be returned instead. Otherwise the behaviour
|
||||
is the same as if "nolargeio" was specified.
|
||||
|
||||
logbufs=value
|
||||
Set the number of in-memory log buffers. Valid numbers range
|
||||
from 2-8 inclusive.
|
||||
The default value is 8 buffers for filesystems with a
|
||||
blocksize of 64KiB, 4 buffers for filesystems with a blocksize
|
||||
of 32KiB, 3 buffers for filesystems with a blocksize of 16KiB
|
||||
and 2 buffers for all other configurations. Increasing the
|
||||
number of buffers may increase performance on some workloads
|
||||
at the cost of the memory used for the additional log buffers
|
||||
and their associated control structures.
|
||||
Set the number of in-memory log buffers. Valid numbers
|
||||
range from 2-8 inclusive.
|
||||
|
||||
The default value is 8 buffers.
|
||||
|
||||
If the memory cost of 8 log buffers is too high on small
|
||||
systems, then it may be reduced at some cost to performance
|
||||
on metadata intensive workloads. The logbsize option below
|
||||
controls the size of each buffer and so is also relevent to
|
||||
this case.
|
||||
|
||||
logbsize=value
|
||||
Set the size of each in-memory log buffer.
|
||||
Size may be specified in bytes, or in kilobytes with a "k" suffix.
|
||||
Valid sizes for version 1 and version 2 logs are 16384 (16k) and
|
||||
32768 (32k). Valid sizes for version 2 logs also include
|
||||
65536 (64k), 131072 (128k) and 262144 (256k).
|
||||
The default value for machines with more than 32MiB of memory
|
||||
is 32768, machines with less memory use 16384 by default.
|
||||
Set the size of each in-memory log buffer. The size may be
|
||||
specified in bytes, or in kilobytes with a "k" suffix.
|
||||
Valid sizes for version 1 and version 2 logs are 16384 (16k)
|
||||
and 32768 (32k). Valid sizes for version 2 logs also
|
||||
include 65536 (64k), 131072 (128k) and 262144 (256k). The
|
||||
logbsize must be an integer multiple of the log
|
||||
stripe unit configured at mkfs time.
|
||||
|
||||
The default value for for version 1 logs is 32768, while the
|
||||
default value for version 2 logs is MAX(32768, log_sunit).
|
||||
|
||||
logdev=device and rtdev=device
|
||||
Use an external log (metadata journal) and/or real-time device.
|
||||
|
|
@ -124,16 +157,11 @@ When mounting an XFS filesystem, the following options are accepted.
|
|||
optional, and the log section can be separate from the data
|
||||
section or contained within it.
|
||||
|
||||
mtpt=mountpoint
|
||||
Use with the "dmapi" option. The value specified here will be
|
||||
included in the DMAPI mount event, and should be the path of
|
||||
the actual mountpoint that is used.
|
||||
|
||||
noalign
|
||||
Data allocations will not be aligned at stripe unit boundaries.
|
||||
|
||||
noatime
|
||||
Access timestamps are not updated when a file is read.
|
||||
Data allocations will not be aligned at stripe unit
|
||||
boundaries. This is only relevant to filesystems created
|
||||
with non-zero data alignment parameters (sunit, swidth) by
|
||||
mkfs.
|
||||
|
||||
norecovery
|
||||
The filesystem will be mounted without running log recovery.
|
||||
|
|
@ -144,8 +172,14 @@ When mounting an XFS filesystem, the following options are accepted.
|
|||
the mount will fail.
|
||||
|
||||
nouuid
|
||||
Don't check for double mounted file systems using the file system uuid.
|
||||
This is useful to mount LVM snapshot volumes.
|
||||
Don't check for double mounted file systems using the file
|
||||
system uuid. This is useful to mount LVM snapshot volumes,
|
||||
and often used in combination with "norecovery" for mounting
|
||||
read-only snapshots.
|
||||
|
||||
noquota
|
||||
Forcibly turns off all quota accounting and enforcement
|
||||
within the filesystem.
|
||||
|
||||
uquota/usrquota/uqnoenforce/quota
|
||||
User disk quota accounting enabled, and limits (optionally)
|
||||
|
|
@ -160,24 +194,64 @@ When mounting an XFS filesystem, the following options are accepted.
|
|||
enforced. Refer to xfs_quota(8) for further details.
|
||||
|
||||
sunit=value and swidth=value
|
||||
Used to specify the stripe unit and width for a RAID device or
|
||||
a stripe volume. "value" must be specified in 512-byte block
|
||||
units.
|
||||
If this option is not specified and the filesystem was made on
|
||||
a stripe volume or the stripe width or unit were specified for
|
||||
the RAID device at mkfs time, then the mount system call will
|
||||
restore the value from the superblock. For filesystems that
|
||||
are made directly on RAID devices, these options can be used
|
||||
to override the information in the superblock if the underlying
|
||||
disk layout changes after the filesystem has been created.
|
||||
The "swidth" option is required if the "sunit" option has been
|
||||
specified, and must be a multiple of the "sunit" value.
|
||||
Used to specify the stripe unit and width for a RAID device
|
||||
or a stripe volume. "value" must be specified in 512-byte
|
||||
block units. These options are only relevant to filesystems
|
||||
that were created with non-zero data alignment parameters.
|
||||
|
||||
The sunit and swidth parameters specified must be compatible
|
||||
with the existing filesystem alignment characteristics. In
|
||||
general, that means the only valid changes to sunit are
|
||||
increasing it by a power-of-2 multiple. Valid swidth values
|
||||
are any integer multiple of a valid sunit value.
|
||||
|
||||
Typically the only time these mount options are necessary if
|
||||
after an underlying RAID device has had it's geometry
|
||||
modified, such as adding a new disk to a RAID5 lun and
|
||||
reshaping it.
|
||||
|
||||
swalloc
|
||||
Data allocations will be rounded up to stripe width boundaries
|
||||
when the current end of file is being extended and the file
|
||||
size is larger than the stripe width size.
|
||||
|
||||
wsync
|
||||
When specified, all filesystem namespace operations are
|
||||
executed synchronously. This ensures that when the namespace
|
||||
operation (create, unlink, etc) completes, the change to the
|
||||
namespace is on stable storage. This is useful in HA setups
|
||||
where failover must not result in clients seeing
|
||||
inconsistent namespace presentation during or after a
|
||||
failover event.
|
||||
|
||||
|
||||
Deprecated Mount Options
|
||||
========================
|
||||
|
||||
delaylog/nodelaylog
|
||||
Delayed logging is the only logging method that XFS supports
|
||||
now, so these mount options are now ignored.
|
||||
|
||||
Due for removal in 3.12.
|
||||
|
||||
ihashsize=value
|
||||
In memory inode hashes have been removed, so this option has
|
||||
no function as of August 2007. Option is deprecated.
|
||||
|
||||
Due for removal in 3.12.
|
||||
|
||||
irixsgid
|
||||
This behaviour is now controlled by a sysctl, so the mount
|
||||
option is ignored.
|
||||
|
||||
Due for removal in 3.12.
|
||||
|
||||
osyncisdsync
|
||||
osyncisosync
|
||||
O_SYNC and O_DSYNC are fully supported, so there is no need
|
||||
for these options any more.
|
||||
|
||||
Due for removal in 3.12.
|
||||
|
||||
sysctls
|
||||
=======
|
||||
|
|
@ -189,15 +263,20 @@ The following sysctls are available for the XFS filesystem:
|
|||
in /proc/fs/xfs/stat. It then immediately resets to "0".
|
||||
|
||||
fs.xfs.xfssyncd_centisecs (Min: 100 Default: 3000 Max: 720000)
|
||||
The interval at which the xfssyncd thread flushes metadata
|
||||
out to disk. This thread will flush log activity out, and
|
||||
do some processing on unlinked inodes.
|
||||
The interval at which the filesystem flushes metadata
|
||||
out to disk and runs internal cache cleanup routines.
|
||||
|
||||
fs.xfs.xfsbufd_centisecs (Min: 50 Default: 100 Max: 3000)
|
||||
The interval at which xfsbufd scans the dirty metadata buffers list.
|
||||
fs.xfs.filestream_centisecs (Min: 1 Default: 3000 Max: 360000)
|
||||
The interval at which the filesystem ages filestreams cache
|
||||
references and returns timed-out AGs back to the free stream
|
||||
pool.
|
||||
|
||||
fs.xfs.age_buffer_centisecs (Min: 100 Default: 1500 Max: 720000)
|
||||
The age at which xfsbufd flushes dirty metadata buffers to disk.
|
||||
fs.xfs.speculative_prealloc_lifetime
|
||||
(Units: seconds Min: 1 Default: 300 Max: 86400)
|
||||
The interval at which the background scanning for inodes
|
||||
with unused speculative preallocation runs. The scan
|
||||
removes unused preallocation from clean inodes and releases
|
||||
the unused space back to the free pool.
|
||||
|
||||
fs.xfs.error_level (Min: 0 Default: 3 Max: 11)
|
||||
A volume knob for error reporting when internal errors occur.
|
||||
|
|
@ -254,9 +333,31 @@ The following sysctls are available for the XFS filesystem:
|
|||
by the xfs_io(8) chattr command on a directory to be
|
||||
inherited by files in that directory.
|
||||
|
||||
fs.xfs.inherit_nodefrag (Min: 0 Default: 1 Max: 1)
|
||||
Setting this to "1" will cause the "nodefrag" flag set
|
||||
by the xfs_io(8) chattr command on a directory to be
|
||||
inherited by files in that directory.
|
||||
|
||||
fs.xfs.rotorstep (Min: 1 Default: 1 Max: 256)
|
||||
In "inode32" allocation mode, this option determines how many
|
||||
files the allocator attempts to allocate in the same allocation
|
||||
group before moving to the next allocation group. The intent
|
||||
is to control the rate at which the allocator moves between
|
||||
allocation groups when allocating extents for new files.
|
||||
|
||||
Deprecated Sysctls
|
||||
==================
|
||||
|
||||
fs.xfs.xfsbufd_centisecs (Min: 50 Default: 100 Max: 3000)
|
||||
Dirty metadata is now tracked by the log subsystem and
|
||||
flushing is driven by log space and idling demands. The
|
||||
xfsbufd no longer exists, so this syctl does nothing.
|
||||
|
||||
Due for removal in 3.14.
|
||||
|
||||
fs.xfs.age_buffer_centisecs (Min: 100 Default: 1500 Max: 720000)
|
||||
Dirty metadata is now tracked by the log subsystem and
|
||||
flushing is driven by log space and idling demands. The
|
||||
xfsbufd no longer exists, so this syctl does nothing.
|
||||
|
||||
Due for removal in 3.14.
|
||||
|
|
|
|||
|
|
@ -174,6 +174,19 @@ Searching in menuconfig:
|
|||
|
||||
/^hotplug
|
||||
|
||||
When searching, symbols are sorted thus:
|
||||
- exact match first: an exact match is when the search matches
|
||||
the complete symbol name;
|
||||
- alphabetical order: when two symbols do not match exactly,
|
||||
they are sorted in alphabetical order (in the user's current
|
||||
locale).
|
||||
For example: ^ATH.K matches:
|
||||
ATH5K ATH9K ATH5K_AHB ATH5K_DEBUG [...] ATH6KL ATH6KL_DEBUG
|
||||
[...] ATH9K_AHB ATH9K_BTCOEX_SUPPORT ATH9K_COMMON [...]
|
||||
of which only ATH5K and ATH9K match exactly and so are sorted
|
||||
first (and in alphabetical order), then come all other symbols,
|
||||
sorted in alphabetical order.
|
||||
|
||||
______________________________________________________________________
|
||||
User interface options for 'menuconfig'
|
||||
|
||||
|
|
|
|||
|
|
@ -3081,6 +3081,19 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
See also Documentation/trace/ftrace.txt "trace options"
|
||||
section.
|
||||
|
||||
traceoff_on_warning
|
||||
[FTRACE] enable this option to disable tracing when a
|
||||
warning is hit. This turns off "tracing_on". Tracing can
|
||||
be enabled again by echoing '1' into the "tracing_on"
|
||||
file located in /sys/kernel/debug/tracing/
|
||||
|
||||
This option is useful, as it disables the trace before
|
||||
the WARNING dump is called, which prevents the trace to
|
||||
be filled with content caused by the warning output.
|
||||
|
||||
This option can also be set at run time via the sysctl
|
||||
option: kernel/traceoff_on_warning
|
||||
|
||||
transparent_hugepage=
|
||||
[KNL]
|
||||
Format: [always|madvise|never]
|
||||
|
|
|
|||
|
|
@ -265,7 +265,7 @@ connected to another pad through an enabled link
|
|||
media_entity_find_link(struct media_pad *source,
|
||||
struct media_pad *sink);
|
||||
|
||||
media_entity_remote_source(struct media_pad *pad);
|
||||
media_entity_remote_pad(struct media_pad *pad);
|
||||
|
||||
Refer to the kerneldoc documentation for more information.
|
||||
|
||||
|
|
|
|||
|
|
@ -1 +0,0 @@
|
|||
ifenslave
|
||||
|
|
@ -88,8 +88,6 @@ gianfar.txt
|
|||
- Gianfar Ethernet Driver.
|
||||
ieee802154.txt
|
||||
- Linux IEEE 802.15.4 implementation, API and drivers
|
||||
ifenslave.c
|
||||
- Configure network interfaces for parallel routing (bonding).
|
||||
igb.txt
|
||||
- README for the Intel Gigabit Ethernet Driver (igb).
|
||||
igbvf.txt
|
||||
|
|
|
|||
|
|
@ -1,11 +1,6 @@
|
|||
# kbuild trick to avoid linker error. Can be omitted if a module is built.
|
||||
obj- := dummy.o
|
||||
|
||||
# List of programs to build
|
||||
hostprogs-y := ifenslave
|
||||
|
||||
HOSTCFLAGS_ifenslave.o += -I$(objtree)/usr/include
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
always := $(hostprogs-y)
|
||||
|
||||
|
|
|
|||
|
|
@ -70,9 +70,10 @@ list, mail to linux-arcnet@tichy.ch.uj.edu.pl.
|
|||
There are archives of the mailing list at:
|
||||
http://epistolary.org/mailman/listinfo.cgi/arcnet
|
||||
|
||||
The people on linux-net@vger.kernel.org have also been known to be very
|
||||
helpful, especially when we're talking about ALPHA Linux kernels that may or
|
||||
may not work right in the first place.
|
||||
The people on linux-net@vger.kernel.org (now defunct, replaced by
|
||||
netdev@vger.kernel.org) have also been known to be very helpful, especially
|
||||
when we're talking about ALPHA Linux kernels that may or may not work right
|
||||
in the first place.
|
||||
|
||||
|
||||
Other Drivers and Info
|
||||
|
|
|
|||
|
|
@ -104,8 +104,7 @@ Table of Contents
|
|||
==============================
|
||||
|
||||
Most popular distro kernels ship with the bonding driver
|
||||
already available as a module and the ifenslave user level control
|
||||
program installed and ready for use. If your distro does not, or you
|
||||
already available as a module. If your distro does not, or you
|
||||
have need to compile bonding from source (e.g., configuring and
|
||||
installing a mainline kernel from kernel.org), you'll need to perform
|
||||
the following steps:
|
||||
|
|
@ -124,46 +123,13 @@ device support" section. It is recommended that you configure the
|
|||
driver as module since it is currently the only way to pass parameters
|
||||
to the driver or configure more than one bonding device.
|
||||
|
||||
Build and install the new kernel and modules, then continue
|
||||
below to install ifenslave.
|
||||
Build and install the new kernel and modules.
|
||||
|
||||
1.2 Install ifenslave Control Utility
|
||||
1.2 Bonding Control Utility
|
||||
-------------------------------------
|
||||
|
||||
The ifenslave user level control program is included in the
|
||||
kernel source tree, in the file Documentation/networking/ifenslave.c.
|
||||
It is generally recommended that you use the ifenslave that
|
||||
corresponds to the kernel that you are using (either from the same
|
||||
source tree or supplied with the distro), however, ifenslave
|
||||
executables from older kernels should function (but features newer
|
||||
than the ifenslave release are not supported). Running an ifenslave
|
||||
that is newer than the kernel is not supported, and may or may not
|
||||
work.
|
||||
|
||||
To install ifenslave, do the following:
|
||||
|
||||
# gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave
|
||||
# cp ifenslave /sbin/ifenslave
|
||||
|
||||
If your kernel source is not in "/usr/src/linux," then replace
|
||||
"/usr/src/linux/include" in the above with the location of your kernel
|
||||
source include directory.
|
||||
|
||||
You may wish to back up any existing /sbin/ifenslave, or, for
|
||||
testing or informal use, tag the ifenslave to the kernel version
|
||||
(e.g., name the ifenslave executable /sbin/ifenslave-2.6.10).
|
||||
|
||||
IMPORTANT NOTE:
|
||||
|
||||
If you omit the "-I" or specify an incorrect directory, you
|
||||
may end up with an ifenslave that is incompatible with the kernel
|
||||
you're trying to build it for. Some distros (e.g., Red Hat from 7.1
|
||||
onwards) do not have /usr/include/linux symbolically linked to the
|
||||
default kernel source include directory.
|
||||
|
||||
SECOND IMPORTANT NOTE:
|
||||
If you plan to configure bonding using sysfs or using the
|
||||
/etc/network/interfaces file, you do not need to use ifenslave.
|
||||
It is recommended to configure bonding via iproute2 (netlink)
|
||||
or sysfs, the old ifenslave control utility is obsolete.
|
||||
|
||||
2. Bonding Driver Options
|
||||
=========================
|
||||
|
|
@ -337,6 +303,12 @@ arp_validate
|
|||
such a situation, validation of backup slaves must be
|
||||
disabled.
|
||||
|
||||
The validation of ARP requests on backup slaves is mainly
|
||||
helping bonding to decide which slaves are more likely to
|
||||
work in case of the active slave failure, it doesn't really
|
||||
guarantee that the backup slave will work if it's selected
|
||||
as the next active slave.
|
||||
|
||||
This option is useful in network configurations in which
|
||||
multiple bonding hosts are concurrently issuing ARPs to one or
|
||||
more targets beyond a common switch. Should the link between
|
||||
|
|
@ -349,6 +321,25 @@ arp_validate
|
|||
|
||||
This option was added in bonding version 3.1.0.
|
||||
|
||||
arp_all_targets
|
||||
|
||||
Specifies the quantity of arp_ip_targets that must be reachable
|
||||
in order for the ARP monitor to consider a slave as being up.
|
||||
This option affects only active-backup mode for slaves with
|
||||
arp_validation enabled.
|
||||
|
||||
Possible values are:
|
||||
|
||||
any or 0
|
||||
|
||||
consider the slave up only when any of the arp_ip_targets
|
||||
is reachable
|
||||
|
||||
all or 1
|
||||
|
||||
consider the slave up only when all of the arp_ip_targets
|
||||
are reachable
|
||||
|
||||
downdelay
|
||||
|
||||
Specifies the time, in milliseconds, to wait before disabling
|
||||
|
|
@ -851,7 +842,7 @@ resend_igmp
|
|||
==============================
|
||||
|
||||
You can configure bonding using either your distro's network
|
||||
initialization scripts, or manually using either ifenslave or the
|
||||
initialization scripts, or manually using either iproute2 or the
|
||||
sysfs interface. Distros generally use one of three packages for the
|
||||
network initialization scripts: initscripts, sysconfig or interfaces.
|
||||
Recent versions of these packages have support for bonding, while older
|
||||
|
|
@ -1160,7 +1151,7 @@ not support this method for specifying multiple bonding interfaces; for
|
|||
those instances, see the "Configuring Multiple Bonds Manually" section,
|
||||
below.
|
||||
|
||||
3.3 Configuring Bonding Manually with Ifenslave
|
||||
3.3 Configuring Bonding Manually with iproute2
|
||||
-----------------------------------------------
|
||||
|
||||
This section applies to distros whose network initialization
|
||||
|
|
@ -1171,7 +1162,7 @@ version 8.
|
|||
The general method for these systems is to place the bonding
|
||||
module parameters into a config file in /etc/modprobe.d/ (as
|
||||
appropriate for the installed distro), then add modprobe and/or
|
||||
ifenslave commands to the system's global init script. The name of
|
||||
`ip link` commands to the system's global init script. The name of
|
||||
the global init script differs; for sysconfig, it is
|
||||
/etc/init.d/boot.local and for initscripts it is /etc/rc.d/rc.local.
|
||||
|
||||
|
|
@ -1183,8 +1174,8 @@ reboots, edit the appropriate file (/etc/init.d/boot.local or
|
|||
modprobe bonding mode=balance-alb miimon=100
|
||||
modprobe e100
|
||||
ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
|
||||
ifenslave bond0 eth0
|
||||
ifenslave bond0 eth1
|
||||
ip link set eth0 master bond0
|
||||
ip link set eth1 master bond0
|
||||
|
||||
Replace the example bonding module parameters and bond0
|
||||
network configuration (IP address, netmask, etc) with the appropriate
|
||||
|
|
|
|||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
|
|
@ -685,6 +685,15 @@ ip_dynaddr - BOOLEAN
|
|||
occurs.
|
||||
Default: 0
|
||||
|
||||
ip_early_demux - BOOLEAN
|
||||
Optimize input packet processing down to one demux for
|
||||
certain kinds of local sockets. Currently we only do this
|
||||
for established TCP sockets.
|
||||
|
||||
It may add an additional cost for pure routing workloads that
|
||||
reduces overall throughput, in such case you should disable it.
|
||||
Default: 1
|
||||
|
||||
icmp_echo_ignore_all - BOOLEAN
|
||||
If set non-zero, then the kernel will ignore all ICMP ECHO
|
||||
requests sent to it.
|
||||
|
|
@ -729,7 +738,7 @@ icmp_ignore_bogus_error_responses - BOOLEAN
|
|||
frames. Such violations are normally logged via a kernel warning.
|
||||
If this is set to TRUE, the kernel will not give such warnings, which
|
||||
will avoid log file clutter.
|
||||
Default: FALSE
|
||||
Default: 1
|
||||
|
||||
icmp_errors_use_inbound_ifaddr - BOOLEAN
|
||||
|
||||
|
|
|
|||
|
|
@ -181,6 +181,19 @@ snat_reroute - BOOLEAN
|
|||
always be the same as the original route so it is an optimisation
|
||||
to disable snat_reroute and avoid the recalculation.
|
||||
|
||||
sync_persist_mode - INTEGER
|
||||
default 0
|
||||
|
||||
Controls the synchronisation of connections when using persistence
|
||||
|
||||
0: All types of connections are synchronised
|
||||
1: Attempt to reduce the synchronisation traffic depending on
|
||||
the connection type. For persistent services avoid synchronisation
|
||||
for normal connections, do it only for persistence templates.
|
||||
In such case, for TCP and SCTP it may need enabling sloppy_tcp and
|
||||
sloppy_sctp flags on backup servers. For non-persistent services
|
||||
such optimization is not applied, mode 0 is assumed.
|
||||
|
||||
sync_version - INTEGER
|
||||
default 1
|
||||
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ Some parameters are constrained, specifically:
|
|||
- nm_frame_nr must equal the actual number of frames as specified above.
|
||||
|
||||
When the kernel can't allocate physically continuous memory for a ring block,
|
||||
it will fall back to use physically discontinous memory. This might affect
|
||||
it will fall back to use physically discontinuous memory. This might affect
|
||||
performance negatively, in order to avoid this the nm_frame_size parameter
|
||||
should be chosen to be as small as possible for the required frame size and
|
||||
the number of blocks should be increased instead.
|
||||
|
|
@ -274,9 +274,9 @@ This example assumes some ring parameters of the ring setup are available.
|
|||
/* Get next frame header */
|
||||
hdr = rx_ring + frame_offset;
|
||||
|
||||
if (hdr->nm_status == NL_MMAP_STATUS_VALID)
|
||||
if (hdr->nm_status == NL_MMAP_STATUS_VALID) {
|
||||
/* Regular memory mapped frame */
|
||||
nlh = (void *hdr) + NL_MMAP_HDRLEN;
|
||||
nlh = (void *)hdr + NL_MMAP_HDRLEN;
|
||||
len = hdr->nm_len;
|
||||
|
||||
/* Release empty message immediately. May happen
|
||||
|
|
|
|||
|
|
@ -704,6 +704,12 @@ So it seems to be a good candidate to be used with packet fanout.
|
|||
Minimal example code by Daniel Borkmann based on Chetan Loke's lolpcap (compile
|
||||
it with gcc -Wall -O2 blob.c, and try things like "./a.out eth0", etc.):
|
||||
|
||||
/* Written from scratch, but kernel-to-user space API usage
|
||||
* dissected from lolpcap:
|
||||
* Copyright 2011, Chetan Loke <loke.chetan@gmail.com>
|
||||
* License: GPL, version 2.0
|
||||
*/
|
||||
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <stdint.h>
|
||||
|
|
@ -722,27 +728,6 @@ it with gcc -Wall -O2 blob.c, and try things like "./a.out eth0", etc.):
|
|||
#include <linux/if_ether.h>
|
||||
#include <linux/ip.h>
|
||||
|
||||
#define BLOCK_SIZE (1 << 22)
|
||||
#define FRAME_SIZE 2048
|
||||
|
||||
#define NUM_BLOCKS 64
|
||||
#define NUM_FRAMES ((BLOCK_SIZE * NUM_BLOCKS) / FRAME_SIZE)
|
||||
|
||||
#define BLOCK_RETIRE_TOV_IN_MS 64
|
||||
#define BLOCK_PRIV_AREA_SZ 13
|
||||
|
||||
#define ALIGN_8(x) (((x) + 8 - 1) & ~(8 - 1))
|
||||
|
||||
#define BLOCK_STATUS(x) ((x)->h1.block_status)
|
||||
#define BLOCK_NUM_PKTS(x) ((x)->h1.num_pkts)
|
||||
#define BLOCK_O2FP(x) ((x)->h1.offset_to_first_pkt)
|
||||
#define BLOCK_LEN(x) ((x)->h1.blk_len)
|
||||
#define BLOCK_SNUM(x) ((x)->h1.seq_num)
|
||||
#define BLOCK_O2PRIV(x) ((x)->offset_to_priv)
|
||||
#define BLOCK_PRIV(x) ((void *) ((uint8_t *) (x) + BLOCK_O2PRIV(x)))
|
||||
#define BLOCK_HDR_LEN (ALIGN_8(sizeof(struct block_desc)))
|
||||
#define BLOCK_PLUS_PRIV(sz_pri) (BLOCK_HDR_LEN + ALIGN_8((sz_pri)))
|
||||
|
||||
#ifndef likely
|
||||
# define likely(x) __builtin_expect(!!(x), 1)
|
||||
#endif
|
||||
|
|
@ -765,7 +750,7 @@ struct ring {
|
|||
static unsigned long packets_total = 0, bytes_total = 0;
|
||||
static sig_atomic_t sigint = 0;
|
||||
|
||||
void sighandler(int num)
|
||||
static void sighandler(int num)
|
||||
{
|
||||
sigint = 1;
|
||||
}
|
||||
|
|
@ -774,6 +759,8 @@ static int setup_socket(struct ring *ring, char *netdev)
|
|||
{
|
||||
int err, i, fd, v = TPACKET_V3;
|
||||
struct sockaddr_ll ll;
|
||||
unsigned int blocksiz = 1 << 22, framesiz = 1 << 11;
|
||||
unsigned int blocknum = 64;
|
||||
|
||||
fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
|
||||
if (fd < 0) {
|
||||
|
|
@ -788,13 +775,12 @@ static int setup_socket(struct ring *ring, char *netdev)
|
|||
}
|
||||
|
||||
memset(&ring->req, 0, sizeof(ring->req));
|
||||
ring->req.tp_block_size = BLOCK_SIZE;
|
||||
ring->req.tp_frame_size = FRAME_SIZE;
|
||||
ring->req.tp_block_nr = NUM_BLOCKS;
|
||||
ring->req.tp_frame_nr = NUM_FRAMES;
|
||||
ring->req.tp_retire_blk_tov = BLOCK_RETIRE_TOV_IN_MS;
|
||||
ring->req.tp_sizeof_priv = BLOCK_PRIV_AREA_SZ;
|
||||
ring->req.tp_feature_req_word |= TP_FT_REQ_FILL_RXHASH;
|
||||
ring->req.tp_block_size = blocksiz;
|
||||
ring->req.tp_frame_size = framesiz;
|
||||
ring->req.tp_block_nr = blocknum;
|
||||
ring->req.tp_frame_nr = (blocksiz * blocknum) / framesiz;
|
||||
ring->req.tp_retire_blk_tov = 60;
|
||||
ring->req.tp_feature_req_word = TP_FT_REQ_FILL_RXHASH;
|
||||
|
||||
err = setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &ring->req,
|
||||
sizeof(ring->req));
|
||||
|
|
@ -804,8 +790,7 @@ static int setup_socket(struct ring *ring, char *netdev)
|
|||
}
|
||||
|
||||
ring->map = mmap(NULL, ring->req.tp_block_size * ring->req.tp_block_nr,
|
||||
PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED,
|
||||
fd, 0);
|
||||
PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED, fd, 0);
|
||||
if (ring->map == MAP_FAILED) {
|
||||
perror("mmap");
|
||||
exit(1);
|
||||
|
|
@ -835,58 +820,6 @@ static int setup_socket(struct ring *ring, char *netdev)
|
|||
return fd;
|
||||
}
|
||||
|
||||
#ifdef __checked
|
||||
static uint64_t prev_block_seq_num = 0;
|
||||
|
||||
void assert_block_seq_num(struct block_desc *pbd)
|
||||
{
|
||||
if (unlikely(prev_block_seq_num + 1 != BLOCK_SNUM(pbd))) {
|
||||
printf("prev_block_seq_num:%"PRIu64", expected seq:%"PRIu64" != "
|
||||
"actual seq:%"PRIu64"\n", prev_block_seq_num,
|
||||
prev_block_seq_num + 1, (uint64_t) BLOCK_SNUM(pbd));
|
||||
exit(1);
|
||||
}
|
||||
|
||||
prev_block_seq_num = BLOCK_SNUM(pbd);
|
||||
}
|
||||
|
||||
static void assert_block_len(struct block_desc *pbd, uint32_t bytes, int block_num)
|
||||
{
|
||||
if (BLOCK_NUM_PKTS(pbd)) {
|
||||
if (unlikely(bytes != BLOCK_LEN(pbd))) {
|
||||
printf("block:%u with %upackets, expected len:%u != actual len:%u\n",
|
||||
block_num, BLOCK_NUM_PKTS(pbd), bytes, BLOCK_LEN(pbd));
|
||||
exit(1);
|
||||
}
|
||||
} else {
|
||||
if (unlikely(BLOCK_LEN(pbd) != BLOCK_PLUS_PRIV(BLOCK_PRIV_AREA_SZ))) {
|
||||
printf("block:%u, expected len:%lu != actual len:%u\n",
|
||||
block_num, BLOCK_HDR_LEN, BLOCK_LEN(pbd));
|
||||
exit(1);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
static void assert_block_header(struct block_desc *pbd, const int block_num)
|
||||
{
|
||||
uint32_t block_status = BLOCK_STATUS(pbd);
|
||||
|
||||
if (unlikely((block_status & TP_STATUS_USER) == 0)) {
|
||||
printf("block:%u, not in TP_STATUS_USER\n", block_num);
|
||||
exit(1);
|
||||
}
|
||||
|
||||
assert_block_seq_num(pbd);
|
||||
}
|
||||
#else
|
||||
static inline void assert_block_header(struct block_desc *pbd, const int block_num)
|
||||
{
|
||||
}
|
||||
static void assert_block_len(struct block_desc *pbd, uint32_t bytes, int block_num)
|
||||
{
|
||||
}
|
||||
#endif
|
||||
|
||||
static void display(struct tpacket3_hdr *ppd)
|
||||
{
|
||||
struct ethhdr *eth = (struct ethhdr *) ((uint8_t *) ppd + ppd->tp_mac);
|
||||
|
|
@ -916,37 +849,27 @@ static void display(struct tpacket3_hdr *ppd)
|
|||
|
||||
static void walk_block(struct block_desc *pbd, const int block_num)
|
||||
{
|
||||
int num_pkts = BLOCK_NUM_PKTS(pbd), i;
|
||||
int num_pkts = pbd->h1.num_pkts, i;
|
||||
unsigned long bytes = 0;
|
||||
unsigned long bytes_with_padding = BLOCK_PLUS_PRIV(BLOCK_PRIV_AREA_SZ);
|
||||
struct tpacket3_hdr *ppd;
|
||||
|
||||
assert_block_header(pbd, block_num);
|
||||
|
||||
ppd = (struct tpacket3_hdr *) ((uint8_t *) pbd + BLOCK_O2FP(pbd));
|
||||
ppd = (struct tpacket3_hdr *) ((uint8_t *) pbd +
|
||||
pbd->h1.offset_to_first_pkt);
|
||||
for (i = 0; i < num_pkts; ++i) {
|
||||
bytes += ppd->tp_snaplen;
|
||||
if (ppd->tp_next_offset)
|
||||
bytes_with_padding += ppd->tp_next_offset;
|
||||
else
|
||||
bytes_with_padding += ALIGN_8(ppd->tp_snaplen + ppd->tp_mac);
|
||||
|
||||
display(ppd);
|
||||
|
||||
ppd = (struct tpacket3_hdr *) ((uint8_t *) ppd + ppd->tp_next_offset);
|
||||
__sync_synchronize();
|
||||
ppd = (struct tpacket3_hdr *) ((uint8_t *) ppd +
|
||||
ppd->tp_next_offset);
|
||||
}
|
||||
|
||||
assert_block_len(pbd, bytes_with_padding, block_num);
|
||||
|
||||
packets_total += num_pkts;
|
||||
bytes_total += bytes;
|
||||
}
|
||||
|
||||
void flush_block(struct block_desc *pbd)
|
||||
static void flush_block(struct block_desc *pbd)
|
||||
{
|
||||
BLOCK_STATUS(pbd) = TP_STATUS_KERNEL;
|
||||
__sync_synchronize();
|
||||
pbd->h1.block_status = TP_STATUS_KERNEL;
|
||||
}
|
||||
|
||||
static void teardown_socket(struct ring *ring, int fd)
|
||||
|
|
@ -962,7 +885,7 @@ int main(int argc, char **argp)
|
|||
socklen_t len;
|
||||
struct ring ring;
|
||||
struct pollfd pfd;
|
||||
unsigned int block_num = 0;
|
||||
unsigned int block_num = 0, blocks = 64;
|
||||
struct block_desc *pbd;
|
||||
struct tpacket_stats_v3 stats;
|
||||
|
||||
|
|
@ -984,15 +907,15 @@ int main(int argc, char **argp)
|
|||
|
||||
while (likely(!sigint)) {
|
||||
pbd = (struct block_desc *) ring.rd[block_num].iov_base;
|
||||
retry_block:
|
||||
if ((BLOCK_STATUS(pbd) & TP_STATUS_USER) == 0) {
|
||||
|
||||
if ((pbd->h1.block_status & TP_STATUS_USER) == 0) {
|
||||
poll(&pfd, 1, -1);
|
||||
goto retry_block;
|
||||
continue;
|
||||
}
|
||||
|
||||
walk_block(pbd, block_num);
|
||||
flush_block(pbd);
|
||||
block_num = (block_num + 1) % NUM_BLOCKS;
|
||||
block_num = (block_num + 1) % blocks;
|
||||
}
|
||||
|
||||
len = sizeof(stats);
|
||||
|
|
|
|||
|
|
@ -163,6 +163,64 @@ and unnecessary. If there are fewer hardware queues than CPUs, then
|
|||
RPS might be beneficial if the rps_cpus for each queue are the ones that
|
||||
share the same memory domain as the interrupting CPU for that queue.
|
||||
|
||||
==== RPS Flow Limit
|
||||
|
||||
RPS scales kernel receive processing across CPUs without introducing
|
||||
reordering. The trade-off to sending all packets from the same flow
|
||||
to the same CPU is CPU load imbalance if flows vary in packet rate.
|
||||
In the extreme case a single flow dominates traffic. Especially on
|
||||
common server workloads with many concurrent connections, such
|
||||
behavior indicates a problem such as a misconfiguration or spoofed
|
||||
source Denial of Service attack.
|
||||
|
||||
Flow Limit is an optional RPS feature that prioritizes small flows
|
||||
during CPU contention by dropping packets from large flows slightly
|
||||
ahead of those from small flows. It is active only when an RPS or RFS
|
||||
destination CPU approaches saturation. Once a CPU's input packet
|
||||
queue exceeds half the maximum queue length (as set by sysctl
|
||||
net.core.netdev_max_backlog), the kernel starts a per-flow packet
|
||||
count over the last 256 packets. If a flow exceeds a set ratio (by
|
||||
default, half) of these packets when a new packet arrives, then the
|
||||
new packet is dropped. Packets from other flows are still only
|
||||
dropped once the input packet queue reaches netdev_max_backlog.
|
||||
No packets are dropped when the input packet queue length is below
|
||||
the threshold, so flow limit does not sever connections outright:
|
||||
even large flows maintain connectivity.
|
||||
|
||||
== Interface
|
||||
|
||||
Flow limit is compiled in by default (CONFIG_NET_FLOW_LIMIT), but not
|
||||
turned on. It is implemented for each CPU independently (to avoid lock
|
||||
and cache contention) and toggled per CPU by setting the relevant bit
|
||||
in sysctl net.core.flow_limit_cpu_bitmap. It exposes the same CPU
|
||||
bitmap interface as rps_cpus (see above) when called from procfs:
|
||||
|
||||
/proc/sys/net/core/flow_limit_cpu_bitmap
|
||||
|
||||
Per-flow rate is calculated by hashing each packet into a hashtable
|
||||
bucket and incrementing a per-bucket counter. The hash function is
|
||||
the same that selects a CPU in RPS, but as the number of buckets can
|
||||
be much larger than the number of CPUs, flow limit has finer-grained
|
||||
identification of large flows and fewer false positives. The default
|
||||
table has 4096 buckets. This value can be modified through sysctl
|
||||
|
||||
net.core.flow_limit_table_len
|
||||
|
||||
The value is only consulted when a new table is allocated. Modifying
|
||||
it does not update active tables.
|
||||
|
||||
== Suggested Configuration
|
||||
|
||||
Flow limit is useful on systems with many concurrent connections,
|
||||
where a single connection taking up 50% of a CPU indicates a problem.
|
||||
In such environments, enable the feature on all CPUs that handle
|
||||
network rx interrupts (as set in /proc/irq/N/smp_affinity).
|
||||
|
||||
The feature depends on the input packet queue length to exceed
|
||||
the flow limit threshold (50%) + the flow history length (256).
|
||||
Setting net.core.netdev_max_backlog to either 1000 or 10000
|
||||
performed well in experiments.
|
||||
|
||||
|
||||
RFS: Receive Flow Steering
|
||||
==========================
|
||||
|
|
|
|||
|
|
@ -359,7 +359,7 @@ steps you should take:
|
|||
- OK, it's a driver problem.
|
||||
|
||||
You need to generate a report. Typically this is an email to the
|
||||
maintainer and/or linux-net@vger.kernel.org. The maintainer's
|
||||
maintainer and/or netdev@vger.kernel.org. The maintainer's
|
||||
email address will be in the driver source or in the MAINTAINERS file.
|
||||
|
||||
- The contents of your report will vary a lot depending upon the
|
||||
|
|
|
|||
|
|
@ -77,6 +77,14 @@ PSW default E value 0
|
|||
Shadow Registers used by interruption handler code
|
||||
TOC enable bit 1
|
||||
|
||||
=========================================================================
|
||||
|
||||
The PA-RISC architecture defines 7 registers as "shadow registers".
|
||||
Those are used in RETURN FROM INTERRUPTION AND RESTORE instruction to reduce
|
||||
the state save and restore time by eliminating the need for general register
|
||||
(GR) saves and restores in interruption handlers.
|
||||
Shadow registers are the GRs 1, 8, 9, 16, 17, 24, and 25.
|
||||
|
||||
=========================================================================
|
||||
Register usage notes, originally from John Marvin, with some additional
|
||||
notes from Randolph Chung.
|
||||
|
|
|
|||
|
|
@ -121,6 +121,38 @@ IPv6 addresses:
|
|||
print a compressed IPv6 address as described by
|
||||
http://tools.ietf.org/html/rfc5952
|
||||
|
||||
IPv4/IPv6 addresses (generic, with port, flowinfo, scope):
|
||||
|
||||
%pIS 1.2.3.4 or 0001:0002:0003:0004:0005:0006:0007:0008
|
||||
%piS 001.002.003.004 or 00010002000300040005000600070008
|
||||
%pISc 1.2.3.4 or 1:2:3:4:5:6:7:8
|
||||
%pISpc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345
|
||||
%p[Ii]S[pfschnbl]
|
||||
|
||||
For printing an IP address without the need to distinguish whether it's
|
||||
of type AF_INET or AF_INET6, a pointer to a valid 'struct sockaddr',
|
||||
specified through 'IS' or 'iS', can be passed to this format specifier.
|
||||
|
||||
The additional 'p', 'f', and 's' specifiers are used to specify port
|
||||
(IPv4, IPv6), flowinfo (IPv6) and scope (IPv6). Ports have a ':' prefix,
|
||||
flowinfo a '/' and scope a '%', each followed by the actual value.
|
||||
|
||||
In case of an IPv6 address the compressed IPv6 address as described by
|
||||
http://tools.ietf.org/html/rfc5952 is being used if the additional
|
||||
specifier 'c' is given. The IPv6 address is surrounded by '[', ']' in
|
||||
case of additional specifiers 'p', 'f' or 's' as suggested by
|
||||
https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07
|
||||
|
||||
In case of IPv4 addresses, the additional 'h', 'n', 'b', and 'l'
|
||||
specifiers can be used as well and are ignored in case of an IPv6
|
||||
address.
|
||||
|
||||
Further examples:
|
||||
|
||||
%pISfc 1.2.3.4 or [1:2:3:4:5:6:7:8]/123456789
|
||||
%pISsc 1.2.3.4 or [1:2:3:4:5:6:7:8]%1234567890
|
||||
%pISpfc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345/123456789
|
||||
|
||||
UUID/GUID addresses:
|
||||
|
||||
%pUb 00010203-0405-0607-0809-0a0b0c0d0e0f
|
||||
|
|
|
|||
|
|
@ -45,6 +45,43 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
|
|||
|
||||
To start/stop toggling the PWM output use pwm_enable()/pwm_disable().
|
||||
|
||||
Using PWMs with the sysfs interface
|
||||
-----------------------------------
|
||||
|
||||
If CONFIG_SYSFS is enabled in your kernel configuration a simple sysfs
|
||||
interface is provided to use the PWMs from userspace. It is exposed at
|
||||
/sys/class/pwm/. Each probed PWM controller/chip will be exported as
|
||||
pwmchipN, where N is the base of the PWM chip. Inside the directory you
|
||||
will find:
|
||||
|
||||
npwm - The number of PWM channels this chip supports (read-only).
|
||||
|
||||
export - Exports a PWM channel for use with sysfs (write-only).
|
||||
|
||||
unexport - Unexports a PWM channel from sysfs (write-only).
|
||||
|
||||
The PWM channels are numbered using a per-chip index from 0 to npwm-1.
|
||||
|
||||
When a PWM channel is exported a pwmX directory will be created in the
|
||||
pwmchipN directory it is associated with, where X is the number of the
|
||||
channel that was exported. The following properties will then be available:
|
||||
|
||||
period - The total period of the PWM signal (read/write).
|
||||
Value is in nanoseconds and is the sum of the active and inactive
|
||||
time of the PWM.
|
||||
|
||||
duty_cycle - The active time of the PWM signal (read/write).
|
||||
Value is in nanoseconds and must be less than the period.
|
||||
|
||||
polarity - Changes the polarity of the PWM signal (read/write).
|
||||
Writes to this property only work if the PWM chip supports changing
|
||||
the polarity. The polarity can only be changed if the PWM is not
|
||||
enabled. Value is the string "normal" or "inversed".
|
||||
|
||||
enable - Enable/disable the PWM signal (read/write).
|
||||
0 - disabled
|
||||
1 - enabled
|
||||
|
||||
Implementing a PWM driver
|
||||
-------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Table : Subdirectories in /proc/sys/net
|
|||
ipv4 IP version 4 x25 X.25 protocol
|
||||
ipx IPX token-ring IBM token ring
|
||||
bridge Bridging decnet DEC net
|
||||
ipv6 IP version 6
|
||||
ipv6 IP version 6 tipc TIPC
|
||||
..............................................................................
|
||||
|
||||
1. /proc/sys/net/core - Network core options
|
||||
|
|
@ -50,6 +50,30 @@ The maximum number of packets that kernel can handle on a NAPI interrupt,
|
|||
it's a Per-CPU variable.
|
||||
Default: 64
|
||||
|
||||
busy_read
|
||||
----------------
|
||||
Low latency busy poll timeout for socket reads. (needs CONFIG_NET_LL_RX_POLL)
|
||||
Approximate time in us to busy loop waiting for packets on the device queue.
|
||||
This sets the default value of the SO_BUSY_POLL socket option.
|
||||
Can be set or overridden per socket by setting socket option SO_BUSY_POLL,
|
||||
which is the preferred method of enabling. If you need to enable the feature
|
||||
globally via sysctl, a value of 50 is recommended.
|
||||
Will increase power usage.
|
||||
Default: 0 (off)
|
||||
|
||||
busy_poll
|
||||
----------------
|
||||
Low latency busy poll timeout for poll and select. (needs CONFIG_NET_LL_RX_POLL)
|
||||
Approximate time in us to busy loop waiting for events.
|
||||
Recommended value depends on the number of sockets you poll on.
|
||||
For several sockets 50, for several hundreds 100.
|
||||
For more than that you probably want to use epoll.
|
||||
Note that only sockets with SO_BUSY_POLL set will be busy polled,
|
||||
so you want to either selectively set SO_BUSY_POLL on those sockets or set
|
||||
sysctl.net.busy_read globally.
|
||||
Will increase power usage.
|
||||
Default: 0 (off)
|
||||
|
||||
rmem_default
|
||||
------------
|
||||
|
||||
|
|
@ -93,8 +117,7 @@ netdev_budget
|
|||
|
||||
Maximum number of packets taken from all interfaces in one polling cycle (NAPI
|
||||
poll). In one polling cycle interfaces which are registered to polling are
|
||||
probed in a round-robin manner. The limit of packets in one such probe can be
|
||||
set per-device via sysfs class/net/<device>/weight .
|
||||
probed in a round-robin manner.
|
||||
|
||||
netdev_max_backlog
|
||||
------------------
|
||||
|
|
@ -201,3 +224,18 @@ IPX.
|
|||
The /proc/net/ipx_route table holds a list of IPX routes. For each route it
|
||||
gives the destination network, the router node (or Directly) and the network
|
||||
address of the router (or Connected) for internal networks.
|
||||
|
||||
6. TIPC
|
||||
-------------------------------------------------------
|
||||
|
||||
The TIPC protocol now has a tunable for the receive memory, similar to the
|
||||
tcp_rmem - i.e. a vector of 3 INTEGERs: (min, default, max)
|
||||
|
||||
# cat /proc/sys/net/tipc/tipc_rmem
|
||||
4252725 34021800 68043600
|
||||
#
|
||||
|
||||
The max value is set to CONN_OVERLOAD_LIMIT, and the default and min values
|
||||
are scaled (shifted) versions of that same value. Note that the min value
|
||||
is not at this point in time used in any meaningful way, but the triplet is
|
||||
preserved in order to be consistent with things like tcp_rmem.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,47 @@
|
|||
Kernel driver: x86_pkg_temp_thermal
|
||||
===================
|
||||
|
||||
Supported chips:
|
||||
* x86: with package level thermal management
|
||||
(Verify using: CPUID.06H:EAX[bit 6] =1)
|
||||
|
||||
Authors: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
|
||||
|
||||
Reference
|
||||
---
|
||||
Intel® 64 and IA-32 Architectures Software Developer’s Manual (Jan, 2013):
|
||||
Chapter 14.6: PACKAGE LEVEL THERMAL MANAGEMENT
|
||||
|
||||
Description
|
||||
---------
|
||||
|
||||
This driver register CPU digital temperature package level sensor as a thermal
|
||||
zone with maximum two user mode configurable trip points. Number of trip points
|
||||
depends on the capability of the package. Once the trip point is violated,
|
||||
user mode can receive notification via thermal notification mechanism and can
|
||||
take any action to control temperature.
|
||||
|
||||
|
||||
Threshold management
|
||||
--------------------
|
||||
Each package will register as a thermal zone under /sys/class/thermal.
|
||||
Example:
|
||||
/sys/class/thermal/thermal_zone1
|
||||
|
||||
This contains two trip points:
|
||||
- trip_point_0_temp
|
||||
- trip_point_1_temp
|
||||
|
||||
User can set any temperature between 0 to TJ-Max temperature. Temperature units
|
||||
are in milli-degree Celsius. Refer to "Documentation/thermal/sysfs-api.txt" for
|
||||
thermal sys-fs details.
|
||||
|
||||
Any value other than 0 in these trip points, can trigger thermal notifications.
|
||||
Setting 0, stops sending thermal notifications.
|
||||
|
||||
Thermal notifications: To get kobject-uevent notifications, set the thermal zone
|
||||
policy to "user_space". For example: echo -n "user_space" > policy
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -183,13 +183,22 @@ The relational-operators depend on the type of the field being tested:
|
|||
|
||||
The operators available for numeric fields are:
|
||||
|
||||
==, !=, <, <=, >, >=
|
||||
==, !=, <, <=, >, >=, &
|
||||
|
||||
And for string fields they are:
|
||||
|
||||
==, !=
|
||||
==, !=, ~
|
||||
|
||||
Currently, only exact string matches are supported.
|
||||
The glob (~) only accepts a wild card character (*) at the start and or
|
||||
end of the string. For example:
|
||||
|
||||
prev_comm ~ "*sh"
|
||||
prev_comm ~ "sh*"
|
||||
prev_comm ~ "*sh*"
|
||||
|
||||
But does not allow for it to be within the string:
|
||||
|
||||
prev_comm ~ "ba*sh" <-- is invalid
|
||||
|
||||
5.2 Setting filters
|
||||
-------------------
|
||||
|
|
|
|||
|
|
@ -2430,6 +2430,19 @@ The following commands are supported:
|
|||
echo '!schedule:disable_event:sched:sched_switch' > \
|
||||
set_ftrace_filter
|
||||
|
||||
- dump
|
||||
When the function is hit, it will dump the contents of the ftrace
|
||||
ring buffer to the console. This is useful if you need to debug
|
||||
something, and want to dump the trace when a certain function
|
||||
is hit. Perhaps its a function that is called before a tripple
|
||||
fault happens and does not allow you to get a regular dump.
|
||||
|
||||
- cpudump
|
||||
When the function is hit, it will dump the contents of the ftrace
|
||||
ring buffer for the current CPU to the console. Unlike the "dump"
|
||||
command, it only prints out the contents of the ring buffer for the
|
||||
CPU that executed the function that triggered the dump.
|
||||
|
||||
trace_pipe
|
||||
----------
|
||||
|
||||
|
|
|
|||
|
|
@ -172,12 +172,12 @@ group and can access them as follows:
|
|||
struct vfio_device_info device_info = { .argsz = sizeof(device_info) };
|
||||
|
||||
/* Create a new container */
|
||||
container = open("/dev/vfio/vfio, O_RDWR);
|
||||
container = open("/dev/vfio/vfio", O_RDWR);
|
||||
|
||||
if (ioctl(container, VFIO_GET_API_VERSION) != VFIO_API_VERSION)
|
||||
/* Unknown API version */
|
||||
|
||||
if (!ioctl(container, VFIO_CHECK_EXTENSION, VFIO_X86_IOMMU))
|
||||
if (!ioctl(container, VFIO_CHECK_EXTENSION, VFIO_TYPE1_IOMMU))
|
||||
/* Doesn't support the IOMMU driver we want. */
|
||||
|
||||
/* Open the group */
|
||||
|
|
@ -193,7 +193,7 @@ group and can access them as follows:
|
|||
ioctl(group, VFIO_GROUP_SET_CONTAINER, &container);
|
||||
|
||||
/* Enable the IOMMU model we want */
|
||||
ioctl(container, VFIO_SET_IOMMU, VFIO_X86_IOMMU)
|
||||
ioctl(container, VFIO_SET_IOMMU, VFIO_TYPE1_IOMMU)
|
||||
|
||||
/* Get addition IOMMU info */
|
||||
ioctl(container, VFIO_IOMMU_GET_INFO, &iommu_info);
|
||||
|
|
|
|||
|
|
@ -160,3 +160,6 @@
|
|||
159 -> ProVideo PV183 [1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540]
|
||||
160 -> Tongwei Video Technology TD-3116 [f200:3116]
|
||||
161 -> Aposonic W-DVR [0279:0228]
|
||||
162 -> Adlink MPG24
|
||||
163 -> Bt848 Capture 14MHz
|
||||
164 -> CyberVision CV06 (SV)
|
||||
|
|
|
|||
|
|
@ -190,3 +190,4 @@
|
|||
189 -> Kworld PC150-U [17de:a134]
|
||||
190 -> Asus My Cinema PS3-100 [1043:48cd]
|
||||
191 -> Hawell HW-9004V1
|
||||
192 -> AverMedia AverTV Satellite Hybrid+FM A706 [1461:2055]
|
||||
|
|
|
|||
|
|
@ -86,6 +86,6 @@ tuner=85 - Philips FQ1236 MK5
|
|||
tuner=86 - Tena TNF5337 MFD
|
||||
tuner=87 - Xceive 4000 tuner
|
||||
tuner=88 - Xceive 5000C tuner
|
||||
tuner=89 - Sony PAL+SECAM (BTF-PG472Z)
|
||||
tuner=90 - Sony NTSC-M-JP (BTF-PK467Z)
|
||||
tuner=91 - Sony NTSC-M (BTF-PB463Z)
|
||||
tuner=89 - Sony BTF-PG472Z PAL/SECAM
|
||||
tuner=90 - Sony BTF-PK467Z NTSC-M-JP
|
||||
tuner=91 - Sony BTF-PB463Z NTSC-M
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
Samsung S5P/EXYNOS4 FIMC driver
|
||||
|
||||
Copyright (C) 2012 Samsung Electronics Co., Ltd.
|
||||
Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd.
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
The FIMC (Fully Interactive Mobile Camera) device available in Samsung
|
||||
|
|
@ -10,7 +10,7 @@ data from LCD controller (FIMD) through the SoC internal writeback data
|
|||
path. There are multiple FIMC instances in the SoCs (up to 4), having
|
||||
slightly different capabilities, like pixel alignment constraints, rotator
|
||||
availability, LCD writeback support, etc. The driver is located at
|
||||
drivers/media/platform/s5p-fimc directory.
|
||||
drivers/media/platform/exynos4-is directory.
|
||||
|
||||
1. Supported SoCs
|
||||
=================
|
||||
|
|
@ -36,21 +36,21 @@ Not currently supported:
|
|||
=====================
|
||||
|
||||
- media device driver
|
||||
drivers/media/platform/s5p-fimc/fimc-mdevice.[ch]
|
||||
drivers/media/platform/exynos4-is/media-dev.[ch]
|
||||
|
||||
- camera capture video device driver
|
||||
drivers/media/platform/s5p-fimc/fimc-capture.c
|
||||
drivers/media/platform/exynos4-is/fimc-capture.c
|
||||
|
||||
- MIPI-CSI2 receiver subdev
|
||||
drivers/media/platform/s5p-fimc/mipi-csis.[ch]
|
||||
drivers/media/platform/exynos4-is/mipi-csis.[ch]
|
||||
|
||||
- video post-processor (mem-to-mem)
|
||||
drivers/media/platform/s5p-fimc/fimc-core.c
|
||||
drivers/media/platform/exynos4-is/fimc-core.c
|
||||
|
||||
- common files
|
||||
drivers/media/platform/s5p-fimc/fimc-core.h
|
||||
drivers/media/platform/s5p-fimc/fimc-reg.h
|
||||
drivers/media/platform/s5p-fimc/regs-fimc.h
|
||||
drivers/media/platform/exynos4-is/fimc-core.h
|
||||
drivers/media/platform/exynos4-is/fimc-reg.h
|
||||
drivers/media/platform/exynos4-is/regs-fimc.h
|
||||
|
||||
4. User space interfaces
|
||||
========================
|
||||
|
|
@ -143,7 +143,8 @@ or retrieve the information from /dev/media? with help of the media-ctl tool:
|
|||
6. Platform support
|
||||
===================
|
||||
|
||||
The machine code (plat-s5p and arch/arm/mach-*) must select following options
|
||||
The machine code (arch/arm/plat-samsung and arch/arm/mach-*) must select
|
||||
following options:
|
||||
|
||||
CONFIG_S5P_DEV_FIMC0 mandatory
|
||||
CONFIG_S5P_DEV_FIMC1 \
|
||||
|
|
|
|||
|
|
@ -246,7 +246,6 @@ may be NULL if the subdev driver does not support anything from that category.
|
|||
It looks like this:
|
||||
|
||||
struct v4l2_subdev_core_ops {
|
||||
int (*g_chip_ident)(struct v4l2_subdev *sd, struct v4l2_dbg_chip_ident *chip);
|
||||
int (*log_status)(struct v4l2_subdev *sd);
|
||||
int (*init)(struct v4l2_subdev *sd, u32 val);
|
||||
...
|
||||
|
|
@ -326,8 +325,27 @@ that width, height and the media bus pixel code are equal on both source and
|
|||
sink of the link. Subdev drivers are also free to use this function to
|
||||
perform the checks mentioned above in addition to their own checks.
|
||||
|
||||
A device (bridge) driver needs to register the v4l2_subdev with the
|
||||
v4l2_device:
|
||||
There are currently two ways to register subdevices with the V4L2 core. The
|
||||
first (traditional) possibility is to have subdevices registered by bridge
|
||||
drivers. This can be done when the bridge driver has the complete information
|
||||
about subdevices connected to it and knows exactly when to register them. This
|
||||
is typically the case for internal subdevices, like video data processing units
|
||||
within SoCs or complex PCI(e) boards, camera sensors in USB cameras or connected
|
||||
to SoCs, which pass information about them to bridge drivers, usually in their
|
||||
platform data.
|
||||
|
||||
There are however also situations where subdevices have to be registered
|
||||
asynchronously to bridge devices. An example of such a configuration is a Device
|
||||
Tree based system where information about subdevices is made available to the
|
||||
system independently from the bridge devices, e.g. when subdevices are defined
|
||||
in DT as I2C device nodes. The API used in this second case is described further
|
||||
below.
|
||||
|
||||
Using one or the other registration method only affects the probing process, the
|
||||
run-time bridge-subdevice interaction is in both cases the same.
|
||||
|
||||
In the synchronous case a device (bridge) driver needs to register the
|
||||
v4l2_subdev with the v4l2_device:
|
||||
|
||||
int err = v4l2_device_register_subdev(v4l2_dev, sd);
|
||||
|
||||
|
|
@ -346,24 +364,24 @@ Afterwards the subdev module can be unloaded and sd->dev == NULL.
|
|||
|
||||
You can call an ops function either directly:
|
||||
|
||||
err = sd->ops->core->g_chip_ident(sd, &chip);
|
||||
err = sd->ops->core->g_std(sd, &norm);
|
||||
|
||||
but it is better and easier to use this macro:
|
||||
|
||||
err = v4l2_subdev_call(sd, core, g_chip_ident, &chip);
|
||||
err = v4l2_subdev_call(sd, core, g_std, &norm);
|
||||
|
||||
The macro will to the right NULL pointer checks and returns -ENODEV if subdev
|
||||
is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_chip_ident is
|
||||
NULL, or the actual result of the subdev->ops->core->g_chip_ident ops.
|
||||
is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_std is
|
||||
NULL, or the actual result of the subdev->ops->core->g_std ops.
|
||||
|
||||
It is also possible to call all or a subset of the sub-devices:
|
||||
|
||||
v4l2_device_call_all(v4l2_dev, 0, core, g_chip_ident, &chip);
|
||||
v4l2_device_call_all(v4l2_dev, 0, core, g_std, &norm);
|
||||
|
||||
Any subdev that does not support this ops is skipped and error results are
|
||||
ignored. If you want to check for errors use this:
|
||||
|
||||
err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip);
|
||||
err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_std, &norm);
|
||||
|
||||
Any error except -ENOIOCTLCMD will exit the loop with that error. If no
|
||||
errors (except -ENOIOCTLCMD) occurred, then 0 is returned.
|
||||
|
|
@ -394,6 +412,30 @@ controlled through GPIO pins. This distinction is only relevant when setting
|
|||
up the device, but once the subdev is registered it is completely transparent.
|
||||
|
||||
|
||||
In the asynchronous case subdevice probing can be invoked independently of the
|
||||
bridge driver availability. The subdevice driver then has to verify whether all
|
||||
the requirements for a successful probing are satisfied. This can include a
|
||||
check for a master clock availability. If any of the conditions aren't satisfied
|
||||
the driver might decide to return -EPROBE_DEFER to request further reprobing
|
||||
attempts. Once all conditions are met the subdevice shall be registered using
|
||||
the v4l2_async_register_subdev() function. Unregistration is performed using
|
||||
the v4l2_async_unregister_subdev() call. Subdevices registered this way are
|
||||
stored in a global list of subdevices, ready to be picked up by bridge drivers.
|
||||
|
||||
Bridge drivers in turn have to register a notifier object with an array of
|
||||
subdevice descriptors that the bridge device needs for its operation. This is
|
||||
performed using the v4l2_async_notifier_register() call. To unregister the
|
||||
notifier the driver has to call v4l2_async_notifier_unregister(). The former of
|
||||
the two functions takes two arguments: a pointer to struct v4l2_device and a
|
||||
pointer to struct v4l2_async_notifier. The latter contains a pointer to an array
|
||||
of pointers to subdevice descriptors of type struct v4l2_async_subdev type. The
|
||||
V4L2 core will then use these descriptors to match asynchronously registered
|
||||
subdevices to them. If a match is detected the .bound() notifier callback is
|
||||
called. After all subdevices have been located the .complete() callback is
|
||||
called. When a subdevice is removed from the system the .unbind() method is
|
||||
called. All three callbacks are optional.
|
||||
|
||||
|
||||
V4L2 sub-device userspace API
|
||||
-----------------------------
|
||||
|
||||
|
|
@ -575,9 +617,13 @@ of the video device exits.
|
|||
The default video_device_release() callback just calls kfree to free the
|
||||
allocated memory.
|
||||
|
||||
There is also a video_device_release_empty() function that does nothing
|
||||
(is empty) and can be used if the struct is embedded and there is nothing
|
||||
to do when it is released.
|
||||
|
||||
You should also set these fields:
|
||||
|
||||
- v4l2_dev: set to the v4l2_device parent device.
|
||||
- v4l2_dev: must be set to the v4l2_device parent device.
|
||||
|
||||
- name: set to something descriptive and unique.
|
||||
|
||||
|
|
@ -614,15 +660,16 @@ You should also set these fields:
|
|||
If you want to have a separate priority state per (group of) device node(s),
|
||||
then you can point it to your own struct v4l2_prio_state.
|
||||
|
||||
- parent: you only set this if v4l2_device was registered with NULL as
|
||||
- dev_parent: you only set this if v4l2_device was registered with NULL as
|
||||
the parent device struct. This only happens in cases where one hardware
|
||||
device has multiple PCI devices that all share the same v4l2_device core.
|
||||
|
||||
The cx88 driver is an example of this: one core v4l2_device struct, but
|
||||
it is used by both an raw video PCI device (cx8800) and a MPEG PCI device
|
||||
(cx8802). Since the v4l2_device cannot be associated with a particular
|
||||
PCI device it is setup without a parent device. But when the struct
|
||||
video_device is setup you do know which parent PCI device to use.
|
||||
it is used by both a raw video PCI device (cx8800) and a MPEG PCI device
|
||||
(cx8802). Since the v4l2_device cannot be associated with two PCI devices
|
||||
at the same time it is setup without a parent device. But when the struct
|
||||
video_device is initialized you *do* know which parent PCI device to use and
|
||||
so you set dev_device to the correct PCI device.
|
||||
|
||||
- flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework
|
||||
handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct
|
||||
|
|
@ -1061,3 +1108,29 @@ available event type is 'class base + 1'.
|
|||
|
||||
An example on how the V4L2 events may be used can be found in the OMAP
|
||||
3 ISP driver (drivers/media/platform/omap3isp).
|
||||
|
||||
|
||||
V4L2 clocks
|
||||
-----------
|
||||
|
||||
Many subdevices, like camera sensors, TV decoders and encoders, need a clock
|
||||
signal to be supplied by the system. Often this clock is supplied by the
|
||||
respective bridge device. The Linux kernel provides a Common Clock Framework for
|
||||
this purpose. However, it is not (yet) available on all architectures. Besides,
|
||||
the nature of the multi-functional (clock, data + synchronisation, I2C control)
|
||||
connection of subdevices to the system might impose special requirements on the
|
||||
clock API usage. E.g. V4L2 has to support clock provider driver unregistration
|
||||
while a subdevice driver is holding a reference to the clock. For these reasons
|
||||
a V4L2 clock helper API has been developed and is provided to bridge and
|
||||
subdevice drivers.
|
||||
|
||||
The API consists of two parts: two functions to register and unregister a V4L2
|
||||
clock source: v4l2_clk_register() and v4l2_clk_unregister() and calls to control
|
||||
a clock object, similar to the respective generic clock API calls:
|
||||
v4l2_clk_get(), v4l2_clk_put(), v4l2_clk_enable(), v4l2_clk_disable(),
|
||||
v4l2_clk_get_rate(), and v4l2_clk_set_rate(). Clock suppliers have to provide
|
||||
clock operations that will be called when clock users invoke respective API
|
||||
methods.
|
||||
|
||||
It is expected that once the CCF becomes available on all relevant
|
||||
architectures this API will be removed.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,68 @@
|
|||
Overview:
|
||||
|
||||
Zswap is a lightweight compressed cache for swap pages. It takes pages that are
|
||||
in the process of being swapped out and attempts to compress them into a
|
||||
dynamically allocated RAM-based memory pool. zswap basically trades CPU cycles
|
||||
for potentially reduced swap I/O. This trade-off can also result in a
|
||||
significant performance improvement if reads from the compressed cache are
|
||||
faster than reads from a swap device.
|
||||
|
||||
NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memory
|
||||
reclaim. This interaction has not be fully explored on the large set of
|
||||
potential configurations and workloads that exist. For this reason, zswap
|
||||
is a work in progress and should be considered experimental.
|
||||
|
||||
Some potential benefits:
|
||||
* Desktop/laptop users with limited RAM capacities can mitigate the
|
||||
performance impact of swapping.
|
||||
* Overcommitted guests that share a common I/O resource can
|
||||
dramatically reduce their swap I/O pressure, avoiding heavy handed I/O
|
||||
throttling by the hypervisor. This allows more work to get done with less
|
||||
impact to the guest workload and guests sharing the I/O subsystem
|
||||
* Users with SSDs as swap devices can extend the life of the device by
|
||||
drastically reducing life-shortening writes.
|
||||
|
||||
Zswap evicts pages from compressed cache on an LRU basis to the backing swap
|
||||
device when the compressed pool reaches it size limit. This requirement had
|
||||
been identified in prior community discussions.
|
||||
|
||||
To enabled zswap, the "enabled" attribute must be set to 1 at boot time. e.g.
|
||||
zswap.enabled=1
|
||||
|
||||
Design:
|
||||
|
||||
Zswap receives pages for compression through the Frontswap API and is able to
|
||||
evict pages from its own compressed pool on an LRU basis and write them back to
|
||||
the backing swap device in the case that the compressed pool is full.
|
||||
|
||||
Zswap makes use of zbud for the managing the compressed memory pool. Each
|
||||
allocation in zbud is not directly accessible by address. Rather, a handle is
|
||||
return by the allocation routine and that handle must be mapped before being
|
||||
accessed. The compressed memory pool grows on demand and shrinks as compressed
|
||||
pages are freed. The pool is not preallocated.
|
||||
|
||||
When a swap page is passed from frontswap to zswap, zswap maintains a mapping
|
||||
of the swap entry, a combination of the swap type and swap offset, to the zbud
|
||||
handle that references that compressed swap page. This mapping is achieved
|
||||
with a red-black tree per swap type. The swap offset is the search key for the
|
||||
tree nodes.
|
||||
|
||||
During a page fault on a PTE that is a swap entry, frontswap calls the zswap
|
||||
load function to decompress the page into the page allocated by the page fault
|
||||
handler.
|
||||
|
||||
Once there are no PTEs referencing a swap page stored in zswap (i.e. the count
|
||||
in the swap_map goes to 0) the swap code calls the zswap invalidate function,
|
||||
via frontswap, to free the compressed entry.
|
||||
|
||||
Zswap seeks to be simple in its policies. Sysfs attributes allow for one user
|
||||
controlled policies:
|
||||
* max_pool_percent - The maximum percentage of memory that the compressed
|
||||
pool can occupy.
|
||||
|
||||
Zswap allows the compressor to be selected at kernel boot time by setting the
|
||||
“compressor” attribute. The default compressor is lzo. e.g.
|
||||
zswap.compressor=deflate
|
||||
|
||||
A debugfs interface is provided for various statistic about pool size, number
|
||||
of pages stored, and various counters for the reasons pages are rejected.
|
||||
|
|
@ -194,14 +194,6 @@ reset: Watchdog Interrupt/Reset Mode. 0 = interrupt, 1 = reset
|
|||
nowayout: Watchdog cannot be stopped once started
|
||||
(default=kernel config parameter)
|
||||
-------------------------------------------------
|
||||
mpcore_wdt:
|
||||
mpcore_margin: MPcore timer margin in seconds.
|
||||
(0 < mpcore_margin < 65536, default=60)
|
||||
nowayout: Watchdog cannot be stopped once started
|
||||
(default=kernel config parameter)
|
||||
mpcore_noboot: MPcore watchdog action, set to 1 to ignore reboots,
|
||||
0 to reboot (default=0
|
||||
-------------------------------------------------
|
||||
mv64x60_wdt:
|
||||
nowayout: Watchdog cannot be stopped once started
|
||||
(default=kernel config parameter)
|
||||
|
|
|
|||
|
|
@ -247,7 +247,6 @@ i2c_client 结构体，i2c_set_clientdata() 函数可用于保存一个 v4l2_sub
|
|||
这些结构体定义如下：
|
||||
|
||||
struct v4l2_subdev_core_ops {
|
||||
int (*g_chip_ident)(struct v4l2_subdev *sd, struct v4l2_dbg_chip_ident *chip);
|
||||
int (*log_status)(struct v4l2_subdev *sd);
|
||||
int (*init)(struct v4l2_subdev *sd, u32 val);
|
||||
...
|
||||
|
|
@ -337,24 +336,24 @@ subdev->dev 域就指向了 v4l2_device。
|
|||
|
||||
注册之设备后，可通过以下方式直接调用其操作函数：
|
||||
|
||||
err = sd->ops->core->g_chip_ident(sd, &chip);
|
||||
err = sd->ops->core->g_std(sd, &norm);
|
||||
|
||||
但使用如下宏会比较容易且合适：
|
||||
|
||||
err = v4l2_subdev_call(sd, core, g_chip_ident, &chip);
|
||||
err = v4l2_subdev_call(sd, core, g_std, &norm);
|
||||
|
||||
这个宏将会做 NULL 指针检查，如果 subdev 为 NULL，则返回-ENODEV；如果
|
||||
subdev->core 或 subdev->core->g_chip_ident 为 NULL，则返回 -ENOIOCTLCMD；
|
||||
否则将返回 subdev->ops->core->g_chip_ident ops 调用的实际结果。
|
||||
subdev->core 或 subdev->core->g_std 为 NULL，则返回 -ENOIOCTLCMD；
|
||||
否则将返回 subdev->ops->core->g_std ops 调用的实际结果。
|
||||
|
||||
有时也可能同时调用所有或一系列子设备的某个操作函数：
|
||||
|
||||
v4l2_device_call_all(v4l2_dev, 0, core, g_chip_ident, &chip);
|
||||
v4l2_device_call_all(v4l2_dev, 0, core, g_std, &norm);
|
||||
|
||||
任何不支持此操作的子设备都会被跳过，并忽略错误返回值。但如果你需要
|
||||
检查出错码，则可使用如下函数：
|
||||
|
||||
err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip);
|
||||
err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_std, &norm);
|
||||
|
||||
除 -ENOIOCTLCMD 外的任何错误都会跳出循环并返回错误值。如果（除 -ENOIOCTLCMD
|
||||
外）没有错误发生，则返回 0。
|
||||
|
|
|
|||
121
MAINTAINERS
121
MAINTAINERS
|
|
@ -752,7 +752,7 @@ S: Maintained
|
|||
F: arch/arm/mach-highbank/
|
||||
|
||||
ARM/CAVIUM NETWORKS CNS3XXX MACHINE SUPPORT
|
||||
M: Anton Vorontsov <avorontsov@mvista.com>
|
||||
M: Anton Vorontsov <anton@enomsg.org>
|
||||
S: Maintained
|
||||
F: arch/arm/mach-cns3xxx/
|
||||
T: git git://git.infradead.org/users/cbou/linux-cns3xxx.git
|
||||
|
|
@ -1165,15 +1165,6 @@ L: linux-media@vger.kernel.org
|
|||
S: Maintained
|
||||
F: drivers/media/platform/s5p-g2d/
|
||||
|
||||
ARM/SAMSUNG S5P SERIES FIMC SUPPORT
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
L: linux-arm-kernel@lists.infradead.org
|
||||
L: linux-media@vger.kernel.org
|
||||
S: Maintained
|
||||
F: arch/arm/plat-samsung/include/plat/*fimc*
|
||||
F: drivers/media/platform/s5p-fimc/
|
||||
|
||||
ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
M: Kamil Debski <k.debski@samsung.com>
|
||||
|
|
@ -1333,6 +1324,12 @@ S: Supported
|
|||
F: arch/arm/mach-zynq/
|
||||
F: drivers/cpuidle/cpuidle-zynq.c
|
||||
|
||||
ARM SMMU DRIVER
|
||||
M: Will Deacon <will.deacon@arm.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: drivers/iommu/arm-smmu.c
|
||||
|
||||
ARM64 PORT (AARCH64 ARCHITECTURE)
|
||||
M: Catalin Marinas <catalin.marinas@arm.com>
|
||||
M: Will Deacon <will.deacon@arm.com>
|
||||
|
|
@ -1589,7 +1586,7 @@ F: include/net/ax25.h
|
|||
F: net/ax25/
|
||||
|
||||
AZ6007 DVB DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -1874,7 +1871,7 @@ F: Documentation/filesystems/btrfs.txt
|
|||
F: fs/btrfs/
|
||||
|
||||
BTTV VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -2129,9 +2126,12 @@ COCCINELLE/Semantic Patches (SmPL)
|
|||
M: Julia Lawall <Julia.Lawall@lip6.fr>
|
||||
M: Gilles Muller <Gilles.Muller@lip6.fr>
|
||||
M: Nicolas Palix <nicolas.palix@imag.fr>
|
||||
M: Michal Marek <mmarek@suse.cz>
|
||||
L: cocci@systeme.lip6.fr (moderated for non-subscribers)
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git misc
|
||||
W: http://coccinelle.lip6.fr/
|
||||
S: Supported
|
||||
F: Documentation/coccinelle.txt
|
||||
F: scripts/coccinelle/
|
||||
F: scripts/coccicheck
|
||||
|
||||
|
|
@ -2332,6 +2332,11 @@ M: Jaya Kumar <jayakumar.alsa@gmail.com>
|
|||
S: Maintained
|
||||
F: sound/pci/cs5535audio/
|
||||
|
||||
CW1200 WLAN driver
|
||||
M: Solomon Peachy <pizza@shaftnet.org>
|
||||
S: Maintained
|
||||
F: drivers/net/wireless/cw1200/
|
||||
|
||||
CX18 VIDEO4LINUX DRIVER
|
||||
M: Andy Walls <awalls@md.metrocast.net>
|
||||
L: ivtv-devel@ivtvdriver.org (moderated for non-subscribers)
|
||||
|
|
@ -2354,7 +2359,7 @@ F: drivers/media/common/cx2341x*
|
|||
F: include/media/cx2341x*
|
||||
|
||||
CX88 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -2560,6 +2565,7 @@ S: Maintained
|
|||
|
||||
DEVICE-MAPPER (LVM)
|
||||
M: Alasdair Kergon <agk@redhat.com>
|
||||
M: Mike Snitzer <snitzer@redhat.com>
|
||||
M: dm-devel@redhat.com
|
||||
L: dm-devel@redhat.com
|
||||
W: http://sources.redhat.com/dm
|
||||
|
|
@ -2571,6 +2577,7 @@ F: drivers/md/dm*
|
|||
F: drivers/md/persistent-data/
|
||||
F: include/linux/device-mapper.h
|
||||
F: include/linux/dm-*.h
|
||||
F: include/uapi/linux/dm-*.h
|
||||
|
||||
DIOLAN U2C-12 I2C DRIVER
|
||||
M: Guenter Roeck <linux@roeck-us.net>
|
||||
|
|
@ -2974,7 +2981,7 @@ S: Maintained
|
|||
F: drivers/edac/e7xxx_edac.c
|
||||
|
||||
EDAC-GHES
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
|
|
@ -3002,21 +3009,21 @@ S: Maintained
|
|||
F: drivers/edac/i5000_edac.c
|
||||
|
||||
EDAC-I5400
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
F: drivers/edac/i5400_edac.c
|
||||
|
||||
EDAC-I7300
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
F: drivers/edac/i7300_edac.c
|
||||
|
||||
EDAC-I7CORE
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
|
|
@ -3045,7 +3052,7 @@ S: Maintained
|
|||
F: drivers/edac/r82600_edac.c
|
||||
|
||||
EDAC-SBRIDGE
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-edac@vger.kernel.org
|
||||
W: bluesmoke.sourceforge.net
|
||||
S: Maintained
|
||||
|
|
@ -3105,7 +3112,7 @@ S: Maintained
|
|||
F: drivers/net/ethernet/ibm/ehea/
|
||||
|
||||
EM28XX VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -5301,7 +5308,7 @@ S: Maintained
|
|||
F: drivers/media/radio/radio-maxiradio*
|
||||
|
||||
MEDIA INPUT INFRASTRUCTURE (V4L/DVB)
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
P: LinuxTV.org Project
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
|
|
@ -5380,6 +5387,12 @@ F: drivers/mtd/
|
|||
F: include/linux/mtd/
|
||||
F: include/uapi/mtd/
|
||||
|
||||
MEN A21 WATCHDOG DRIVER
|
||||
M: Johannes Thumshirn <johannes.thumshirn@men.de>
|
||||
L: linux-watchdog@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/watchdog/mena21_wdt.c
|
||||
|
||||
METAG ARCHITECTURE
|
||||
M: James Hogan <james.hogan@imgtec.com>
|
||||
S: Supported
|
||||
|
|
@ -5423,6 +5436,28 @@ W: http://linuxtv.org
|
|||
S: Odd Fixes
|
||||
F: drivers/media/radio/radio-miropcm20*
|
||||
|
||||
Mellanox MLX5 core VPI driver
|
||||
M: Eli Cohen <eli@mellanox.com>
|
||||
L: netdev@vger.kernel.org
|
||||
L: linux-rdma@vger.kernel.org
|
||||
W: http://www.mellanox.com
|
||||
Q: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
Q: http://patchwork.kernel.org/project/linux-rdma/list/
|
||||
T: git://openfabrics.org/~eli/connect-ib.git
|
||||
S: Supported
|
||||
F: drivers/net/ethernet/mellanox/mlx5/core/
|
||||
F: include/linux/mlx5/
|
||||
|
||||
Mellanox MLX5 IB driver
|
||||
M: Eli Cohen <eli@mellanox.com>
|
||||
L: linux-rdma@vger.kernel.org
|
||||
W: http://www.mellanox.com
|
||||
Q: http://patchwork.kernel.org/project/linux-rdma/list/
|
||||
T: git://openfabrics.org/~eli/connect-ib.git
|
||||
S: Supported
|
||||
F: include/linux/mlx5/
|
||||
F: drivers/infiniband/hw/mlx5/
|
||||
|
||||
MODULE SUPPORT
|
||||
M: Rusty Russell <rusty@rustcorp.com.au>
|
||||
S: Maintained
|
||||
|
|
@ -5495,9 +5530,12 @@ F: include/media/mt9v032.h
|
|||
|
||||
MULTIFUNCTION DEVICES (MFD)
|
||||
M: Samuel Ortiz <sameo@linux.intel.com>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git
|
||||
M: Lee Jones <lee.jones@linaro.org>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-fixes.git
|
||||
S: Supported
|
||||
F: drivers/mfd/
|
||||
F: include/linux/mfd/
|
||||
|
||||
MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
|
||||
M: Chris Ball <cjb@laptop.org>
|
||||
|
|
@ -6398,7 +6436,7 @@ F: include/linux/timer*
|
|||
F: kernel/*timer*
|
||||
|
||||
POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
|
||||
M: Anton Vorontsov <cbou@mail.ru>
|
||||
M: Anton Vorontsov <anton@enomsg.org>
|
||||
M: David Woodhouse <dwmw2@infradead.org>
|
||||
T: git git://git.infradead.org/battery-2.6.git
|
||||
S: Maintained
|
||||
|
|
@ -6508,7 +6546,7 @@ S: Maintained
|
|||
F: drivers/block/ps3vram.c
|
||||
|
||||
PSTORE FILESYSTEM
|
||||
M: Anton Vorontsov <cbouatmailru@gmail.com>
|
||||
M: Anton Vorontsov <anton@enomsg.org>
|
||||
M: Colin Cross <ccross@android.com>
|
||||
M: Kees Cook <keescook@chromium.org>
|
||||
M: Tony Luck <tony.luck@intel.com>
|
||||
|
|
@ -6560,8 +6598,8 @@ S: Maintained
|
|||
F: drivers/media/usb/pwc/*
|
||||
|
||||
PWM SUBSYSTEM
|
||||
M: Thierry Reding <thierry.reding@avionic-design.de>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
M: Thierry Reding <thierry.reding@gmail.com>
|
||||
L: linux-pwm@vger.kernel.org
|
||||
S: Maintained
|
||||
W: http://gitorious.org/linux-pwm
|
||||
T: git git://gitorious.org/linux-pwm/linux-pwm.git
|
||||
|
|
@ -6643,10 +6681,12 @@ F: Documentation/networking/LICENSE.qla3xxx
|
|||
F: drivers/net/ethernet/qlogic/qla3xxx.*
|
||||
|
||||
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
|
||||
M: Himanshu Madhani <himanshu.madhani@qlogic.com>
|
||||
M: Rajesh Borundia <rajesh.borundia@qlogic.com>
|
||||
M: Shahed Shaikh <shahed.shaikh@qlogic.com>
|
||||
M: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
|
||||
M: Sony Chacko <sony.chacko@qlogic.com>
|
||||
M: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
|
||||
M: linux-driver@qlogic.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
|
|
@ -6994,7 +7034,7 @@ S: Odd Fixes
|
|||
F: drivers/media/i2c/saa6588*
|
||||
|
||||
SAA7134 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -7039,6 +7079,15 @@ F: drivers/regulator/s5m*.c
|
|||
F: drivers/rtc/rtc-sec.c
|
||||
F: include/linux/mfd/samsung/
|
||||
|
||||
SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS
|
||||
M: Kyungmin Park <kyungmin.park@samsung.com>
|
||||
M: Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
Q: https://patchwork.linuxtv.org/project/linux-media/list/
|
||||
S: Supported
|
||||
F: drivers/media/platform/exynos4-is/
|
||||
F: include/media/s5p_fimc.h
|
||||
|
||||
SAMSUNG S3C24XX/S3C64XX SOC SERIES CAMIF DRIVER
|
||||
M: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
|
|
@ -7206,7 +7255,7 @@ F: drivers/mmc/host/sdhci.*
|
|||
F: drivers/mmc/host/sdhci-pltfm.[ch]
|
||||
|
||||
SECURE DIGITAL HOST CONTROLLER INTERFACE, OPEN FIRMWARE BINDINGS (SDHCI-OF)
|
||||
M: Anton Vorontsov <avorontsov@ru.mvista.com>
|
||||
M: Anton Vorontsov <anton@enomsg.org>
|
||||
L: linuxppc-dev@lists.ozlabs.org
|
||||
L: linux-mmc@vger.kernel.org
|
||||
S: Maintained
|
||||
|
|
@ -7356,7 +7405,7 @@ S: Odd Fixes
|
|||
F: drivers/media/radio/radio-si4713.h
|
||||
|
||||
SIANO DVB DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -8061,7 +8110,7 @@ S: Maintained
|
|||
F: drivers/media/i2c/tda9840*
|
||||
|
||||
TEA5761 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -8069,7 +8118,7 @@ S: Odd fixes
|
|||
F: drivers/media/tuners/tea5761.*
|
||||
|
||||
TEA5767 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -8142,6 +8191,7 @@ M: Zhang Rui <rui.zhang@intel.com>
|
|||
M: Eduardo Valentin <eduardo.valentin@ti.com>
|
||||
L: linux-pm@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git
|
||||
Q: https://patchwork.kernel.org/project/linux-pm/list/
|
||||
S: Supported
|
||||
F: drivers/thermal/
|
||||
|
|
@ -8166,8 +8216,8 @@ F: drivers/platform/x86/thinkpad_acpi.c
|
|||
TI BANDGAP AND THERMAL DRIVER
|
||||
M: Eduardo Valentin <eduardo.valentin@ti.com>
|
||||
L: linux-pm@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/staging/omap-thermal/
|
||||
S: Supported
|
||||
F: drivers/thermal/ti-soc-thermal/
|
||||
|
||||
TI FLASH MEDIA INTERFACE DRIVER
|
||||
M: Alex Dubov <oakad@yahoo.com>
|
||||
|
|
@ -8307,7 +8357,7 @@ F: include/linux/shmem_fs.h
|
|||
F: mm/shmem.c
|
||||
|
||||
TM6000 VIDEO4LINUX DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
@ -8876,6 +8926,7 @@ M: "Michael S. Tsirkin" <mst@redhat.com>
|
|||
L: virtualization@lists.linux-foundation.org
|
||||
S: Maintained
|
||||
F: drivers/virtio/
|
||||
F: tools/virtio/
|
||||
F: drivers/net/virtio_net.c
|
||||
F: drivers/block/virtio_blk.c
|
||||
F: include/linux/virtio_*.h
|
||||
|
|
@ -8971,7 +9022,7 @@ M: Liam Girdwood <lgirdwood@gmail.com>
|
|||
M: Mark Brown <broonie@kernel.org>
|
||||
W: http://opensource.wolfsonmicro.com/node/15
|
||||
W: http://www.slimlogic.co.uk/?p=48
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lrg/regulator.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
|
||||
S: Supported
|
||||
F: drivers/regulator/
|
||||
F: include/linux/regulator/
|
||||
|
|
@ -9163,7 +9214,7 @@ S: Maintained
|
|||
F: arch/x86/kernel/cpu/mcheck/*
|
||||
|
||||
XC2028/3028 TUNER DRIVER
|
||||
M: Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
M: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://linuxtv.org
|
||||
T: git git://linuxtv.org/media_tree.git
|
||||
|
|
|
|||
12
Makefile
12
Makefile
|
|
@ -1,8 +1,8 @@
|
|||
VERSION = 3
|
||||
PATCHLEVEL = 10
|
||||
PATCHLEVEL = 11
|
||||
SUBLEVEL = 0
|
||||
EXTRAVERSION =
|
||||
NAME = Unicycling Gorilla
|
||||
EXTRAVERSION = -rc2
|
||||
NAME = Linux for Workgroups
|
||||
|
||||
# *DOCUMENTATION*
|
||||
# To see a list of typical targets execute "make help"
|
||||
|
|
@ -1116,6 +1116,7 @@ help:
|
|||
@echo ' gtags - Generate GNU GLOBAL index'
|
||||
@echo ' kernelrelease - Output the release version string'
|
||||
@echo ' kernelversion - Output the version stored in Makefile'
|
||||
@echo ' image_name - Output the image name'
|
||||
@echo ' headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH'; \
|
||||
echo ' (default: $(INSTALL_HDR_PATH))'; \
|
||||
echo ''
|
||||
|
|
@ -1310,7 +1311,7 @@ export_report:
|
|||
endif #ifeq ($(config-targets),1)
|
||||
endif #ifeq ($(mixed-targets),1)
|
||||
|
||||
PHONY += checkstack kernelrelease kernelversion
|
||||
PHONY += checkstack kernelrelease kernelversion image_name
|
||||
|
||||
# UML needs a little special treatment here. It wants to use the host
|
||||
# toolchain, so needs $(SUBARCH) passed to checkstack.pl. Everyone
|
||||
|
|
@ -1331,6 +1332,9 @@ kernelrelease:
|
|||
kernelversion:
|
||||
@echo $(KERNELVERSION)
|
||||
|
||||
image_name:
|
||||
@echo $(KBUILD_IMAGE)
|
||||
|
||||
# Clear a bunch of variables before executing the submake
|
||||
tools/: FORCE
|
||||
$(Q)mkdir -p $(objtree)/tools
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@
|
|||
#define O_SYNC (__O_SYNC|O_DSYNC)
|
||||
|
||||
#define O_PATH 040000000
|
||||
#define O_TMPFILE 0100000000
|
||||
#define __O_TMPFILE 0100000000
|
||||
|
||||
#define F_GETLK 7
|
||||
#define F_SETLK 8
|
||||
|
|
|
|||
|
|
@ -81,4 +81,6 @@
|
|||
|
||||
#define SO_SELECT_ERR_QUEUE 45
|
||||
|
||||
#define SO_BUSY_POLL 46
|
||||
|
||||
#endif /* _UAPI_ASM_SOCKET_H */
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ wait_boot_cpu_to_stop(int cpuid)
|
|||
/*
|
||||
* Where secondaries begin a life of C.
|
||||
*/
|
||||
void __cpuinit
|
||||
void
|
||||
smp_callin(void)
|
||||
{
|
||||
int cpuid = hard_smp_processor_id();
|
||||
|
|
@ -194,7 +194,7 @@ wait_for_txrdy (unsigned long cpumask)
|
|||
* Send a message to a secondary's console. "START" is one such
|
||||
* interesting message. ;-)
|
||||
*/
|
||||
static void __cpuinit
|
||||
static void
|
||||
send_secondary_console_msg(char *str, int cpuid)
|
||||
{
|
||||
struct percpu_struct *cpu;
|
||||
|
|
@ -285,7 +285,7 @@ recv_secondary_console_msg(void)
|
|||
/*
|
||||
* Convince the console to have a secondary cpu begin execution.
|
||||
*/
|
||||
static int __cpuinit
|
||||
static int
|
||||
secondary_cpu_start(int cpuid, struct task_struct *idle)
|
||||
{
|
||||
struct percpu_struct *cpu;
|
||||
|
|
@ -356,7 +356,7 @@ secondary_cpu_start(int cpuid, struct task_struct *idle)
|
|||
/*
|
||||
* Bring one cpu online.
|
||||
*/
|
||||
static int __cpuinit
|
||||
static int
|
||||
smp_boot_one_cpu(int cpuid, struct task_struct *idle)
|
||||
{
|
||||
unsigned long timeout;
|
||||
|
|
@ -472,7 +472,7 @@ smp_prepare_boot_cpu(void)
|
|||
{
|
||||
}
|
||||
|
||||
int __cpuinit
|
||||
int
|
||||
__cpu_up(unsigned int cpu, struct task_struct *tidle)
|
||||
{
|
||||
smp_boot_one_cpu(cpu, tidle);
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@
|
|||
|
||||
static int opDEC_fix;
|
||||
|
||||
static void __cpuinit
|
||||
static void
|
||||
opDEC_check(void)
|
||||
{
|
||||
__asm__ __volatile__ (
|
||||
|
|
@ -1059,7 +1059,7 @@ give_sigbus:
|
|||
return;
|
||||
}
|
||||
|
||||
void __cpuinit
|
||||
void
|
||||
trap_init(void)
|
||||
{
|
||||
/* Tell PAL-code what global pointer we want in the kernel. */
|
||||
|
|
|
|||
|
|
@ -21,10 +21,6 @@
|
|||
|
||||
/include/ "abilis_tb10x.dtsi"
|
||||
|
||||
/* interrupt specifiers
|
||||
* --------------------
|
||||
* 0: rising, 1: low, 2: high, 3: falling,
|
||||
*/
|
||||
|
||||
/ {
|
||||
clock-frequency = <500000000>; /* 500 MHZ */
|
||||
|
|
@ -173,7 +169,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF140000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -185,7 +181,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF141000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -197,7 +193,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF142000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -209,7 +205,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF143000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -221,7 +217,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF144000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -233,7 +229,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF145000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -245,7 +241,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF146000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -257,7 +253,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF147000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -269,7 +265,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF148000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -281,7 +277,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF149000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -293,7 +289,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF14A000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -305,7 +301,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF14B000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -317,7 +313,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF14C000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -329,7 +325,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF14D000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -21,10 +21,6 @@
|
|||
|
||||
/include/ "abilis_tb10x.dtsi"
|
||||
|
||||
/* interrupt specifiers
|
||||
* --------------------
|
||||
* 0: rising, 1: low, 2: high, 3: falling,
|
||||
*/
|
||||
|
||||
/ {
|
||||
clock-frequency = <500000000>; /* 500 MHZ */
|
||||
|
|
@ -182,7 +178,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF140000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -194,7 +190,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF141000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -206,7 +202,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF142000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -218,7 +214,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF143000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -230,7 +226,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF144000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -242,7 +238,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF145000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -254,7 +250,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF146000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -266,7 +262,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF147000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -278,7 +274,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF148000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -290,7 +286,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF149000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -302,7 +298,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF14A000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -314,7 +310,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF14B000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -326,7 +322,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF14C000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
@ -338,7 +334,7 @@
|
|||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <27 1>;
|
||||
interrupts = <27 2>;
|
||||
reg = <0xFF14D000 0x1000>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <1>;
|
||||
|
|
|
|||
|
|
@ -19,10 +19,6 @@
|
|||
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
||||
*/
|
||||
|
||||
/* interrupt specifiers
|
||||
* --------------------
|
||||
* 0: rising, 1: low, 2: high, 3: falling,
|
||||
*/
|
||||
|
||||
/ {
|
||||
compatible = "abilis,arc-tb10x";
|
||||
|
|
@ -78,7 +74,7 @@
|
|||
#interrupt-cells = <1>;
|
||||
};
|
||||
tb10x_ictl: pic@fe002000 {
|
||||
compatible = "abilis,tb10x_ictl";
|
||||
compatible = "abilis,tb10x-ictl";
|
||||
reg = <0xFE002000 0x20>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
|
@ -91,7 +87,7 @@
|
|||
compatible = "snps,dw-apb-uart";
|
||||
reg = <0xFF100000 0x100>;
|
||||
clock-frequency = <166666666>;
|
||||
interrupts = <25 1>;
|
||||
interrupts = <25 8>;
|
||||
reg-shift = <2>;
|
||||
reg-io-width = <4>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
|
|
@ -100,7 +96,7 @@
|
|||
compatible = "snps,dwmac-3.70a","snps,dwmac";
|
||||
reg = <0xFE100000 0x1058>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <6 1>;
|
||||
interrupts = <6 8>;
|
||||
interrupt-names = "macirq";
|
||||
clocks = <&ahb_clk>;
|
||||
clock-names = "stmmaceth";
|
||||
|
|
@ -109,7 +105,7 @@
|
|||
compatible = "snps,dma-spear1340";
|
||||
reg = <0xFE000000 0x400>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <14 1>;
|
||||
interrupts = <14 8>;
|
||||
dma-channels = <6>;
|
||||
dma-requests = <0>;
|
||||
dma-masters = <1>;
|
||||
|
|
@ -128,7 +124,7 @@
|
|||
compatible = "snps,designware-i2c";
|
||||
reg = <0xFF120000 0x1000>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <12 1>;
|
||||
interrupts = <12 8>;
|
||||
clocks = <&ahb_clk>;
|
||||
};
|
||||
i2c1: i2c@FF121000 {
|
||||
|
|
@ -137,7 +133,7 @@
|
|||
compatible = "snps,designware-i2c";
|
||||
reg = <0xFF121000 0x1000>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <12 1>;
|
||||
interrupts = <12 8>;
|
||||
clocks = <&ahb_clk>;
|
||||
};
|
||||
i2c2: i2c@FF122000 {
|
||||
|
|
@ -146,7 +142,7 @@
|
|||
compatible = "snps,designware-i2c";
|
||||
reg = <0xFF122000 0x1000>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <12 1>;
|
||||
interrupts = <12 8>;
|
||||
clocks = <&ahb_clk>;
|
||||
};
|
||||
i2c3: i2c@FF123000 {
|
||||
|
|
@ -155,7 +151,7 @@
|
|||
compatible = "snps,designware-i2c";
|
||||
reg = <0xFF123000 0x1000>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <12 1>;
|
||||
interrupts = <12 8>;
|
||||
clocks = <&ahb_clk>;
|
||||
};
|
||||
i2c4: i2c@FF124000 {
|
||||
|
|
@ -164,7 +160,7 @@
|
|||
compatible = "snps,designware-i2c";
|
||||
reg = <0xFF124000 0x1000>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <12 1>;
|
||||
interrupts = <12 8>;
|
||||
clocks = <&ahb_clk>;
|
||||
};
|
||||
|
||||
|
|
@ -176,7 +172,7 @@
|
|||
num-cs = <1>;
|
||||
reg = <0xFE010000 0x20>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <26 1>;
|
||||
interrupts = <26 8>;
|
||||
clocks = <&ahb_clk>;
|
||||
};
|
||||
spi1: spi@0xFE011000 {
|
||||
|
|
@ -187,7 +183,7 @@
|
|||
num-cs = <2>;
|
||||
reg = <0xFE011000 0x20>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <10 1>;
|
||||
interrupts = <10 8>;
|
||||
clocks = <&ahb_clk>;
|
||||
};
|
||||
|
||||
|
|
@ -195,7 +191,7 @@
|
|||
compatible = "abilis,tb100-tsm";
|
||||
reg = <0xff316000 0x400>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <17 1>;
|
||||
interrupts = <17 8>;
|
||||
output-clkdiv = <4>;
|
||||
global-packet-delay = <0x21>;
|
||||
port-packet-delay = <0>;
|
||||
|
|
@ -213,7 +209,7 @@
|
|||
"cpuctrl",
|
||||
"a6it_int_force";
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <20 1>, <19 1>;
|
||||
interrupts = <20 2>, <19 2>;
|
||||
interrupt-names = "cmd_irq", "event_irq";
|
||||
};
|
||||
tb10x_mdsc0: tb10x-mdscr@FF300000 {
|
||||
|
|
@ -239,7 +235,7 @@
|
|||
compatible = "abilis,tb100-wfb";
|
||||
reg = <0xff319000 0x1000>;
|
||||
interrupt-parent = <&tb10x_ictl>;
|
||||
interrupts = <16 1>;
|
||||
interrupts = <16 8>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -51,5 +51,21 @@
|
|||
current-speed = <115200>;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
ethernet@c0fc2000 {
|
||||
compatible = "snps,arc-emac";
|
||||
reg = <0xc0fc2000 0x3c>;
|
||||
interrupts = <6>;
|
||||
mac-address = [ 00 11 22 33 44 55 ];
|
||||
clock-frequency = <80000000>;
|
||||
max-speed = <100>;
|
||||
phy = <&phy0>;
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
phy0: ethernet-phy@0 {
|
||||
reg = <1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -38,6 +38,9 @@ CONFIG_INET=y
|
|||
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
|
||||
# CONFIG_FIRMWARE_IN_KERNEL is not set
|
||||
# CONFIG_BLK_DEV is not set
|
||||
CONFIG_NETDEVICES=y
|
||||
CONFIG_ARC_EMAC=y
|
||||
CONFIG_LXT_PHY=y
|
||||
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
|
||||
# CONFIG_INPUT_KEYBOARD is not set
|
||||
# CONFIG_INPUT_MOUSE is not set
|
||||
|
|
|
|||
|
|
@ -16,8 +16,6 @@
|
|||
#define UART1_IRQ 10
|
||||
#define UART2_IRQ 11
|
||||
|
||||
#define VMAC_IRQ 6
|
||||
|
||||
#define IDE_IRQ 13
|
||||
#define PCI_IRQ 14
|
||||
#define PS2_IRQ 15
|
||||
|
|
|
|||
|
|
@ -15,8 +15,6 @@
|
|||
#define UART0_BASE 0xC0FC1000
|
||||
#define UART1_BASE 0xC0FC1100
|
||||
|
||||
#define VMAC_REG_BASEADDR 0xC0FC2000
|
||||
|
||||
#define IDE_CONTROLLER_BASE 0xC0FC9000
|
||||
|
||||
#define AHB_PCI_HOST_BRG_BASE 0xC0FD0000
|
||||
|
|
|
|||
|
|
@ -22,6 +22,7 @@ menuconfig ARC_PLAT_TB10X
|
|||
select PINCTRL
|
||||
select PINMUX
|
||||
select ARCH_REQUIRE_GPIOLIB
|
||||
select TB10X_IRQC
|
||||
help
|
||||
Support for platforms based on the TB10x home media gateway SOC by
|
||||
Abilis Systems. TB10x is based on the ARC700 CPU architecture.
|
||||
|
|
|
|||
|
|
@ -1316,7 +1316,7 @@ config ARM_ERRATA_754327
|
|||
|
||||
config ARM_ERRATA_364296
|
||||
bool "ARM errata: Possible cache data corruption with hit-under-miss enabled"
|
||||
depends on CPU_V6 && !SMP
|
||||
depends on CPU_V6
|
||||
help
|
||||
This options enables the workaround for the 364296 ARM1136
|
||||
r0p2 erratum (possible cache data corruption with
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче