mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-29 03:01:39 -04:00
Linux 3.17
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJUMZqoAAoJEHm+PkMAQRiGFC4H/i0b9vxCwe6VCXonpaDW03fI JKE7v/zwDfhDngKSYfBWRSf3jXwfSHLvAvCgIvqTw5qBW3XSWF8xB7kJpWptQxIi M6ePfaETt2mPYhEWWWxJK8boykiOXObDrFJVhfjHGsjbvmKiLPMaGYwXTSwZJ32V fQDaA9Piugjc9wEY0d+6cjqUUEwlb4+GFz4Wv2oJgbpzxwgJS/XjQYk+3PrcdAXz lmwPXQ+6ntJaducVu3JM2YYvaJLzTw+T+MPsWiTvaE4ILmuiw492VNY5XdyQQtb2 DSActOKCF2hIwnG+DMg63XV5FH81HqczwORDygBuxko0cURxupxMnaLPkVRpksk= =+PRQ -----END PGP SIGNATURE----- Merge tag 'v3.17' into next Synchronize with mainline to bring in changes to Synaptics and i8042 drivers.
This commit is contained in:
Dmitry Torokhov
commit
9d93551188
925 changed files with 9658 additions and 5139 deletions
|
|
@ -2545,6 +2545,30 @@ fields changed from _s32 to _u32.
|
|||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.16</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Added event V4L2_EVENT_SOURCE_CHANGE.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>V4L2 in Linux 3.17</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>Extended &v4l2-pix-format;. Added format flags.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Added compound control types and &VIDIOC-QUERY-EXT-CTRL;.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section id="other">
|
||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||
|
||||
|
|
|
|||
|
|
@ -29,9 +29,12 @@ can suspend execution until the driver has captured data or is ready
|
|||
to accept data for output.</para>
|
||||
|
||||
<para>When streaming I/O has been negotiated this function waits
|
||||
until a buffer has been filled or displayed and can be dequeued with
|
||||
the &VIDIOC-DQBUF; ioctl. When buffers are already in the outgoing
|
||||
queue of the driver the function returns immediately.</para>
|
||||
until a buffer has been filled by the capture device and can be dequeued
|
||||
with the &VIDIOC-DQBUF; ioctl. For output devices this function waits
|
||||
until the device is ready to accept a new buffer to be queued up with
|
||||
the &VIDIOC-QBUF; ioctl for display. When buffers are already in the outgoing
|
||||
queue of the driver (capture) or the incoming queue isn't full (display)
|
||||
the function returns immediately.</para>
|
||||
|
||||
<para>On success <function>poll()</function> returns the number of
|
||||
file descriptors that have been selected (that is, file descriptors
|
||||
|
|
@ -44,10 +47,22 @@ Capture devices set the <constant>POLLIN</constant> and
|
|||
flags. When the function timed out it returns a value of zero, on
|
||||
failure it returns <returnvalue>-1</returnvalue> and the
|
||||
<varname>errno</varname> variable is set appropriately. When the
|
||||
application did not call &VIDIOC-QBUF; or &VIDIOC-STREAMON; yet the
|
||||
application did not call &VIDIOC-STREAMON; the
|
||||
<function>poll()</function> function succeeds, but sets the
|
||||
<constant>POLLERR</constant> flag in the
|
||||
<structfield>revents</structfield> field.</para>
|
||||
<structfield>revents</structfield> field. When the
|
||||
application has called &VIDIOC-STREAMON; for a capture device but hasn't
|
||||
yet called &VIDIOC-QBUF;, the <function>poll()</function> function
|
||||
succeeds and sets the <constant>POLLERR</constant> flag in the
|
||||
<structfield>revents</structfield> field. For output devices this
|
||||
same situation will cause <function>poll()</function> to succeed
|
||||
as well, but it sets the <constant>POLLOUT</constant> and
|
||||
<constant>POLLWRNORM</constant> flags in the <structfield>revents</structfield>
|
||||
field.</para>
|
||||
|
||||
<para>If an event occurred (see &VIDIOC-DQEVENT;) then
|
||||
<constant>POLLPRI</constant> will be set in the <structfield>revents</structfield>
|
||||
field and <function>poll()</function> will return.</para>
|
||||
|
||||
<para>When use of the <function>read()</function> function has
|
||||
been negotiated and the driver does not capture yet, the
|
||||
|
|
@ -58,10 +73,18 @@ continuously (as opposed to, for example, still images) the function
|
|||
may return immediately.</para>
|
||||
|
||||
<para>When use of the <function>write()</function> function has
|
||||
been negotiated the <function>poll</function> function just waits
|
||||
been negotiated and the driver does not stream yet, the
|
||||
<function>poll</function> function starts streaming. When that fails
|
||||
it returns a <constant>POLLERR</constant> as above. Otherwise it waits
|
||||
until the driver is ready for a non-blocking
|
||||
<function>write()</function> call.</para>
|
||||
|
||||
<para>If the caller is only interested in events (just
|
||||
<constant>POLLPRI</constant> is set in the <structfield>events</structfield>
|
||||
field), then <function>poll()</function> will <emphasis>not</emphasis>
|
||||
start streaming if the driver does not stream yet. This makes it
|
||||
possible to just poll for events and not for buffers.</para>
|
||||
|
||||
<para>All drivers implementing the <function>read()</function> or
|
||||
<function>write()</function> function or streaming I/O must also
|
||||
support the <function>poll()</function> function.</para>
|
||||
|
|
|
|||
|
|
@ -152,10 +152,11 @@ structs, ioctls) must be noted in more detail in the history chapter
|
|||
applications. -->
|
||||
|
||||
<revision>
|
||||
<revnumber>3.16</revnumber>
|
||||
<date>2014-05-27</date>
|
||||
<authorinitials>lp</authorinitials>
|
||||
<revremark>Extended &v4l2-pix-format;. Added format flags.
|
||||
<revnumber>3.17</revnumber>
|
||||
<date>2014-08-04</date>
|
||||
<authorinitials>lp, hv</authorinitials>
|
||||
<revremark>Extended &v4l2-pix-format;. Added format flags. Added compound control types
|
||||
and VIDIOC_QUERY_EXT_CTRL.
|
||||
</revremark>
|
||||
</revision>
|
||||
|
||||
|
|
@ -538,7 +539,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 3.14</subtitle>
|
||||
<subtitle>Revision 3.17</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@
|
|||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-rect;</entry>
|
||||
<entry><structfield>rect</structfield></entry>
|
||||
<entry><structfield>r</structfield></entry>
|
||||
<entry>Selection rectangle, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
|
|
|||
|
|
@ -794,6 +794,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
|
|||
<http://www.kroah.com/log/linux/maintainer-03.html>
|
||||
<http://www.kroah.com/log/linux/maintainer-04.html>
|
||||
<http://www.kroah.com/log/linux/maintainer-05.html>
|
||||
<http://www.kroah.com/log/linux/maintainer-06.html>
|
||||
|
||||
NO!!!! No more huge patch bombs to [email protected] people!
|
||||
<https://lkml.org/lkml/2005/7/11/336>
|
||||
|
|
|
|||
|
|
@ -345,14 +345,14 @@ the named feature on.
|
|||
The implementation is simple.
|
||||
|
||||
Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag
|
||||
PF_SPREAD_PAGE for each task that is in that cpuset or subsequently
|
||||
PFA_SPREAD_PAGE for each task that is in that cpuset or subsequently
|
||||
joins that cpuset. The page allocation calls for the page cache
|
||||
is modified to perform an inline check for this PF_SPREAD_PAGE task
|
||||
is modified to perform an inline check for this PFA_SPREAD_PAGE task
|
||||
flag, and if set, a call to a new routine cpuset_mem_spread_node()
|
||||
returns the node to prefer for the allocation.
|
||||
|
||||
Similarly, setting 'cpuset.memory_spread_slab' turns on the flag
|
||||
PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
|
||||
PFA_SPREAD_SLAB, and appropriately marked slab caches will allocate
|
||||
pages from the node returned by cpuset_mem_spread_node().
|
||||
|
||||
The cpuset_mem_spread_node() routine is also simple. It uses the
|
||||
|
|
|
|||
|
|
@ -16,9 +16,9 @@ Example:
|
|||
* DMA client
|
||||
|
||||
Required properties:
|
||||
- dmas: a list of <[DMA multiplexer phandle] [SRS/DRS value]> pairs,
|
||||
where SRS/DRS values are fixed handles, specified in the SoC
|
||||
manual as the value that would be written into the PDMACHCR.
|
||||
- dmas: a list of <[DMA multiplexer phandle] [SRS << 8 | DRS]> pairs.
|
||||
where SRS/DRS are specified in the SoC manual.
|
||||
It will be written into PDMACHCR as high 16-bit parts.
|
||||
- dma-names: a list of DMA channel names, one per "dmas" entry
|
||||
|
||||
Example:
|
||||
|
|
|
|||
|
|
@ -11,10 +11,17 @@ Required properties:
|
|||
|
||||
Optional properties for main touchpad device:
|
||||
|
||||
- linux,gpio-keymap: An array of up to 4 entries indicating the Linux
|
||||
keycode generated by each GPIO. Linux keycodes are defined in
|
||||
- linux,gpio-keymap: When enabled, the SPT_GPIOPWN_T19 object sends messages
|
||||
on GPIO bit changes. An array of up to 8 entries can be provided
|
||||
indicating the Linux keycode mapped to each bit of the status byte,
|
||||
starting at the LSB. Linux keycodes are defined in
|
||||
<dt-bindings/input/input.h>.
|
||||
|
||||
Note: the numbering of the GPIOs and the bit they start at varies between
|
||||
maXTouch devices. You must either refer to the documentation, or
|
||||
experiment to determine which bit corresponds to which input. Use
|
||||
KEY_RESERVED for unused padding values.
|
||||
|
||||
Example:
|
||||
|
||||
touch@4b {
|
||||
|
|
|
|||
|
|
@ -39,6 +39,10 @@ Optional properties:
|
|||
further clocks may be specified in derived bindings.
|
||||
- clock-names: One name for each entry in the clocks property, the
|
||||
first one should be "stmmaceth".
|
||||
- clk_ptp_ref: this is the PTP reference clock; in case of the PTP is
|
||||
available this clock is used for programming the Timestamp Addend Register.
|
||||
If not passed then the system clock will be used and this is fine on some
|
||||
platforms.
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
|
|||
|
|
@ -45,8 +45,8 @@ Example:
|
|||
infet5-supply = <&some_reg>;
|
||||
infet6-supply = <&some_reg>;
|
||||
infet7-supply = <&some_reg>;
|
||||
vsys_l1-supply = <&some_reg>;
|
||||
vsys_l2-supply = <&some_reg>;
|
||||
vsys-l1-supply = <&some_reg>;
|
||||
vsys-l2-supply = <&some_reg>;
|
||||
|
||||
regulators {
|
||||
dcdc1 {
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
ADI AXI-SPDIF controller
|
||||
|
||||
Required properties:
|
||||
- compatible : Must be "adi,axi-spdif-1.00.a"
|
||||
- compatible : Must be "adi,axi-spdif-tx-1.00.a"
|
||||
- reg : Must contain SPDIF core's registers location and length
|
||||
- clocks : Pairs of phandle and specifier referencing the controller's clocks.
|
||||
The controller expects two clocks, the clock used for the AXI interface and
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ i2s@ff890000 {
|
|||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
dmas = <&pdma1 0>, <&pdma1 1>;
|
||||
dma-names = "rx", "tx";
|
||||
dma-names = "tx", "rx";
|
||||
clock-names = "i2s_hclk", "i2s_clk";
|
||||
clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -16,11 +16,15 @@ Required Properties:
|
|||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
- clock-names: Shall be "spiclk" for the transfer-clock, and "apb_pclk" for
|
||||
the peripheral clock.
|
||||
- #address-cells: should be 1.
|
||||
- #size-cells: should be 0.
|
||||
|
||||
Optional Properties:
|
||||
|
||||
- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
|
||||
Documentation/devicetree/bindings/dma/dma.txt
|
||||
- dma-names: DMA request names should include "tx" and "rx" if present.
|
||||
- #address-cells: should be 1.
|
||||
- #size-cells: should be 0.
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -56,6 +56,9 @@ Required properties:
|
|||
- fsl,data-width : should be <18> or <24>
|
||||
- port: A port node with endpoint definitions as defined in
|
||||
Documentation/devicetree/bindings/media/video-interfaces.txt.
|
||||
On i.MX5, the internal two-input-multiplexer is used.
|
||||
Due to hardware limitations, only one port (port@[0,1])
|
||||
can be used for each channel (lvds-channel@[0,1], respectively)
|
||||
On i.MX6, there should be four ports (port@[0-3]) that correspond
|
||||
to the four LVDS multiplexer inputs.
|
||||
|
||||
|
|
@ -78,6 +81,8 @@ ldb: ldb@53fa8008 {
|
|||
"di0", "di1";
|
||||
|
||||
lvds-channel@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0>;
|
||||
fsl,data-mapping = "spwg";
|
||||
fsl,data-width = <24>;
|
||||
|
|
@ -86,7 +91,9 @@ ldb: ldb@53fa8008 {
|
|||
/* ... */
|
||||
};
|
||||
|
||||
port {
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
lvds0_in: endpoint {
|
||||
remote-endpoint = <&ipu_di0_lvds0>;
|
||||
};
|
||||
|
|
@ -94,6 +101,8 @@ ldb: ldb@53fa8008 {
|
|||
};
|
||||
|
||||
lvds-channel@1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <1>;
|
||||
fsl,data-mapping = "spwg";
|
||||
fsl,data-width = <24>;
|
||||
|
|
@ -102,7 +111,9 @@ ldb: ldb@53fa8008 {
|
|||
/* ... */
|
||||
};
|
||||
|
||||
port {
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
|
||||
lvds1_in: endpoint {
|
||||
remote-endpoint = <&ipu_di1_lvds1>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ Required properties:
|
|||
* "fsl,imx23-usbphy" for imx23 and imx28
|
||||
* "fsl,imx6q-usbphy" for imx6dq and imx6dl
|
||||
* "fsl,imx6sl-usbphy" for imx6sl
|
||||
* "fsl,imx6sx-usbphy" for imx6sx
|
||||
"fsl,imx23-usbphy" is still a fallback for other strings
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain phy interrupt
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Analog TV Connector
|
|||
===================
|
||||
|
||||
Required properties:
|
||||
- compatible: "composite-connector" or "svideo-connector"
|
||||
- compatible: "composite-video-connector" or "svideo-connector"
|
||||
|
||||
Optional properties:
|
||||
- label: a symbolic name for the connector
|
||||
|
|
@ -14,7 +14,7 @@ Example
|
|||
-------
|
||||
|
||||
tv: connector {
|
||||
compatible = "composite-connector";
|
||||
compatible = "composite-video-connector";
|
||||
label = "tv";
|
||||
|
||||
port {
|
||||
|
|
|
|||
211
Documentation/devicetree/of_selftest.txt
Normal file
211
Documentation/devicetree/of_selftest.txt
Normal file
|
|
@ -0,0 +1,211 @@
|
|||
Open Firmware Device Tree Selftest
|
||||
----------------------------------
|
||||
|
||||
Author: Gaurav Minocha <[email protected]>
|
||||
|
||||
1. Introduction
|
||||
|
||||
This document explains how the test data required for executing OF selftest
|
||||
is attached to the live tree dynamically, independent of the machine's
|
||||
architecture.
|
||||
|
||||
It is recommended to read the following documents before moving ahead.
|
||||
|
||||
[1] Documentation/devicetree/usage-model.txt
|
||||
[2] http://www.devicetree.org/Device_Tree_Usage
|
||||
|
||||
OF Selftest has been designed to test the interface (include/linux/of.h)
|
||||
provided to device driver developers to fetch the device information..etc.
|
||||
from the unflattened device tree data structure. This interface is used by
|
||||
most of the device drivers in various use cases.
|
||||
|
||||
|
||||
2. Test-data
|
||||
|
||||
The Device Tree Source file (drivers/of/testcase-data/testcases.dts) contains
|
||||
the test data required for executing the unit tests automated in
|
||||
drivers/of/selftests.c. Currently, following Device Tree Source Include files
|
||||
(.dtsi) are included in testcase.dts:
|
||||
|
||||
drivers/of/testcase-data/tests-interrupts.dtsi
|
||||
drivers/of/testcase-data/tests-platform.dtsi
|
||||
drivers/of/testcase-data/tests-phandle.dtsi
|
||||
drivers/of/testcase-data/tests-match.dtsi
|
||||
|
||||
When the kernel is build with OF_SELFTEST enabled, then the following make rule
|
||||
|
||||
$(obj)/%.dtb: $(src)/%.dts FORCE
|
||||
$(call if_changed_dep, dtc)
|
||||
|
||||
is used to compile the DT source file (testcase.dts) into a binary blob
|
||||
(testcase.dtb), also referred as flattened DT.
|
||||
|
||||
After that, using the following rule the binary blob above is wrapped as an
|
||||
assembly file (testcase.dtb.S).
|
||||
|
||||
$(obj)/%.dtb.S: $(obj)/%.dtb
|
||||
$(call cmd, dt_S_dtb)
|
||||
|
||||
The assembly file is compiled into an object file (testcase.dtb.o), and is
|
||||
linked into the kernel image.
|
||||
|
||||
|
||||
2.1. Adding the test data
|
||||
|
||||
Un-flattened device tree structure:
|
||||
|
||||
Un-flattened device tree consists of connected device_node(s) in form of a tree
|
||||
structure described below.
|
||||
|
||||
// following struct members are used to construct the tree
|
||||
struct device_node {
|
||||
...
|
||||
struct device_node *parent;
|
||||
struct device_node *child;
|
||||
struct device_node *sibling;
|
||||
struct device_node *allnext; /* next in list of all nodes */
|
||||
...
|
||||
};
|
||||
|
||||
Figure 1, describes a generic structure of machine’s un-flattened device tree
|
||||
considering only child and sibling pointers. There exists another pointer,
|
||||
*parent, that is used to traverse the tree in the reverse direction. So, at
|
||||
a particular level the child node and all the sibling nodes will have a parent
|
||||
pointer pointing to a common node (e.g. child1, sibling2, sibling3, sibling4’s
|
||||
parent points to root node)
|
||||
|
||||
root (‘/’)
|
||||
|
|
||||
child1 -> sibling2 -> sibling3 -> sibling4 -> null
|
||||
| | | |
|
||||
| | | null
|
||||
| | |
|
||||
| | child31 -> sibling32 -> null
|
||||
| | | |
|
||||
| | null null
|
||||
| |
|
||||
| child21 -> sibling22 -> sibling23 -> null
|
||||
| | | |
|
||||
| null null null
|
||||
|
|
||||
child11 -> sibling12 -> sibling13 -> sibling14 -> null
|
||||
| | | |
|
||||
| | | null
|
||||
| | |
|
||||
null null child131 -> null
|
||||
|
|
||||
null
|
||||
|
||||
Figure 1: Generic structure of un-flattened device tree
|
||||
|
||||
|
||||
*allnext: it is used to link all the nodes of DT into a list. So, for the
|
||||
above tree the list would be as follows:
|
||||
|
||||
root->child1->child11->sibling12->sibling13->child131->sibling14->sibling2->
|
||||
child21->sibling22->sibling23->sibling3->child31->sibling32->sibling4->null
|
||||
|
||||
Before executing OF selftest, it is required to attach the test data to
|
||||
machine's device tree (if present). So, when selftest_data_add() is called,
|
||||
at first it reads the flattened device tree data linked into the kernel image
|
||||
via the following kernel symbols:
|
||||
|
||||
__dtb_testcases_begin - address marking the start of test data blob
|
||||
__dtb_testcases_end - address marking the end of test data blob
|
||||
|
||||
Secondly, it calls of_fdt_unflatten_device_tree() to unflatten the flattened
|
||||
blob. And finally, if the machine’s device tree (i.e live tree) is present,
|
||||
then it attaches the unflattened test data tree to the live tree, else it
|
||||
attaches itself as a live device tree.
|
||||
|
||||
attach_node_and_children() uses of_attach_node() to attach the nodes into the
|
||||
live tree as explained below. To explain the same, the test data tree described
|
||||
in Figure 2 is attached to the live tree described in Figure 1.
|
||||
|
||||
root (‘/’)
|
||||
|
|
||||
testcase-data
|
||||
|
|
||||
test-child0 -> test-sibling1 -> test-sibling2 -> test-sibling3 -> null
|
||||
| | | |
|
||||
test-child01 null null null
|
||||
|
||||
|
||||
allnext list:
|
||||
|
||||
root->testcase-data->test-child0->test-child01->test-sibling1->test-sibling2
|
||||
->test-sibling3->null
|
||||
|
||||
Figure 2: Example test data tree to be attached to live tree.
|
||||
|
||||
According to the scenario above, the live tree is already present so it isn’t
|
||||
required to attach the root(‘/’) node. All other nodes are attached by calling
|
||||
of_attach_node() on each node.
|
||||
|
||||
In the function of_attach_node(), the new node is attached as the child of the
|
||||
given parent in live tree. But, if parent already has a child then the new node
|
||||
replaces the current child and turns it into its sibling. So, when the testcase
|
||||
data node is attached to the live tree above (Figure 1), the final structure is
|
||||
as shown in Figure 3.
|
||||
|
||||
root (‘/’)
|
||||
|
|
||||
testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null
|
||||
| | | | |
|
||||
(...) | | | null
|
||||
| | child31 -> sibling32 -> null
|
||||
| | | |
|
||||
| | null null
|
||||
| |
|
||||
| child21 -> sibling22 -> sibling23 -> null
|
||||
| | | |
|
||||
| null null null
|
||||
|
|
||||
child11 -> sibling12 -> sibling13 -> sibling14 -> null
|
||||
| | | |
|
||||
null null | null
|
||||
|
|
||||
child131 -> null
|
||||
|
|
||||
null
|
||||
-----------------------------------------------------------------------
|
||||
|
||||
root (‘/’)
|
||||
|
|
||||
testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null
|
||||
| | | | |
|
||||
| (...) (...) (...) null
|
||||
|
|
||||
test-sibling3 -> test-sibling2 -> test-sibling1 -> test-child0 -> null
|
||||
| | | |
|
||||
null null null test-child01
|
||||
|
||||
|
||||
Figure 3: Live device tree structure after attaching the testcase-data.
|
||||
|
||||
|
||||
Astute readers would have noticed that test-child0 node becomes the last
|
||||
sibling compared to the earlier structure (Figure 2). After attaching first
|
||||
test-child0 the test-sibling1 is attached that pushes the child node
|
||||
(i.e. test-child0) to become a sibling and makes itself a child node,
|
||||
as mentioned above.
|
||||
|
||||
If a duplicate node is found (i.e. if a node with same full_name property is
|
||||
already present in the live tree), then the node isn’t attached rather its
|
||||
properties are updated to the live tree’s node by calling the function
|
||||
update_node_properties().
|
||||
|
||||
|
||||
2.2. Removing the test data
|
||||
|
||||
Once the test case execution is complete, selftest_data_remove is called in
|
||||
order to remove the device nodes attached initially (first the leaf nodes are
|
||||
detached and then moving up the parent nodes are removed, and eventually the
|
||||
whole tree). selftest_data_remove() calls detach_node_and_children() that uses
|
||||
of_detach_node() to detach the nodes from the live device tree.
|
||||
|
||||
To detach a node, of_detach_node() first updates all_next linked list, by
|
||||
attaching the previous node’s allnext to current node’s allnext pointer. And
|
||||
then, it either updates the child pointer of given node’s parent to its
|
||||
sibling or attaches the previous sibling to the given node’s sibling, as
|
||||
appropriate. That is it :)
|
||||
|
|
@ -138,9 +138,9 @@ Installation
|
|||
- Build, install, reboot
|
||||
|
||||
The NFS/RDMA code will be enabled automatically if NFS and RDMA
|
||||
are turned on. The NFS/RDMA client and server are configured via the hidden
|
||||
SUNRPC_XPRT_RDMA config option that depends on SUNRPC and INFINIBAND. The
|
||||
value of SUNRPC_XPRT_RDMA will be:
|
||||
are turned on. The NFS/RDMA client and server are configured via the
|
||||
SUNRPC_XPRT_RDMA_CLIENT and SUNRPC_XPRT_RDMA_SERVER config options that both
|
||||
depend on SUNRPC and INFINIBAND. The default value of both options will be:
|
||||
|
||||
- N if either SUNRPC or INFINIBAND are N, in this case the NFS/RDMA client
|
||||
and server will not be built
|
||||
|
|
@ -235,8 +235,9 @@ NFS/RDMA Setup
|
|||
|
||||
- Start the NFS server
|
||||
|
||||
If the NFS/RDMA server was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in
|
||||
kernel config), load the RDMA transport module:
|
||||
If the NFS/RDMA server was built as a module
|
||||
(CONFIG_SUNRPC_XPRT_RDMA_SERVER=m in kernel config), load the RDMA
|
||||
transport module:
|
||||
|
||||
$ modprobe svcrdma
|
||||
|
||||
|
|
@ -255,8 +256,9 @@ NFS/RDMA Setup
|
|||
|
||||
- On the client system
|
||||
|
||||
If the NFS/RDMA client was built as a module (CONFIG_SUNRPC_XPRT_RDMA=m in
|
||||
kernel config), load the RDMA client module:
|
||||
If the NFS/RDMA client was built as a module
|
||||
(CONFIG_SUNRPC_XPRT_RDMA_CLIENT=m in kernel config), load the RDMA client
|
||||
module:
|
||||
|
||||
$ modprobe xprtrdma.ko
|
||||
|
||||
|
|
|
|||
|
|
@ -235,6 +235,39 @@ be used for more than one file, you can store an arbitrary pointer in the
|
|||
private field of the seq_file structure; that value can then be retrieved
|
||||
by the iterator functions.
|
||||
|
||||
There is also a wrapper function to seq_open() called seq_open_private(). It
|
||||
kmallocs a zero filled block of memory and stores a pointer to it in the
|
||||
private field of the seq_file structure, returning 0 on success. The
|
||||
block size is specified in a third parameter to the function, e.g.:
|
||||
|
||||
static int ct_open(struct inode *inode, struct file *file)
|
||||
{
|
||||
return seq_open_private(file, &ct_seq_ops,
|
||||
sizeof(struct mystruct));
|
||||
}
|
||||
|
||||
There is also a variant function, __seq_open_private(), which is functionally
|
||||
identical except that, if successful, it returns the pointer to the allocated
|
||||
memory block, allowing further initialisation e.g.:
|
||||
|
||||
static int ct_open(struct inode *inode, struct file *file)
|
||||
{
|
||||
struct mystruct *p =
|
||||
__seq_open_private(file, &ct_seq_ops, sizeof(*p));
|
||||
|
||||
if (!p)
|
||||
return -ENOMEM;
|
||||
|
||||
p->foo = bar; /* initialize my stuff */
|
||||
...
|
||||
p->baz = true;
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
A corresponding close function, seq_release_private() is available which
|
||||
frees the memory allocated in the corresponding open.
|
||||
|
||||
The other operations of interest - read(), llseek(), and release() - are
|
||||
all implemented by the seq_file code itself. So a virtual file's
|
||||
file_operations structure will look like:
|
||||
|
|
|
|||
|
|
@ -53,7 +53,20 @@ with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned
|
|||
if and only if no GPIO has been assigned to the device/function/index triplet,
|
||||
other error codes are used for cases where a GPIO has been assigned but an error
|
||||
occurred while trying to acquire it. This is useful to discriminate between mere
|
||||
errors and an absence of GPIO for optional GPIO parameters.
|
||||
errors and an absence of GPIO for optional GPIO parameters. For the common
|
||||
pattern where a GPIO is optional, the gpiod_get_optional() and
|
||||
gpiod_get_index_optional() functions can be used. These functions return NULL
|
||||
instead of -ENOENT if no GPIO has been assigned to the requested function:
|
||||
|
||||
|
||||
struct gpio_desc *gpiod_get_optional(struct device *dev,
|
||||
const char *con_id,
|
||||
enum gpiod_flags flags)
|
||||
|
||||
struct gpio_desc *gpiod_get_index_optional(struct device *dev,
|
||||
const char *con_id,
|
||||
unsigned int index,
|
||||
enum gpiod_flags flags)
|
||||
|
||||
Device-managed variants of these functions are also defined:
|
||||
|
||||
|
|
@ -65,6 +78,15 @@ Device-managed variants of these functions are also defined:
|
|||
unsigned int idx,
|
||||
enum gpiod_flags flags)
|
||||
|
||||
struct gpio_desc *devm_gpiod_get_optional(struct device *dev,
|
||||
const char *con_id,
|
||||
enum gpiod_flags flags)
|
||||
|
||||
struct gpio_desc * devm_gpiod_get_index_optional(struct device *dev,
|
||||
const char *con_id,
|
||||
unsigned int index,
|
||||
enum gpiod_flags flags)
|
||||
|
||||
A GPIO descriptor can be disposed of using the gpiod_put() function:
|
||||
|
||||
void gpiod_put(struct gpio_desc *desc)
|
||||
|
|
|
|||
|
|
@ -57,12 +57,12 @@ Well, you are all set up now. You can now use SMBus commands or plain
|
|||
I2C to communicate with your device. SMBus commands are preferred if
|
||||
the device supports them. Both are illustrated below.
|
||||
|
||||
__u8 register = 0x10; /* Device register to access */
|
||||
__u8 reg = 0x10; /* Device register to access */
|
||||
__s32 res;
|
||||
char buf[10];
|
||||
|
||||
/* Using SMBus commands */
|
||||
res = i2c_smbus_read_word_data(file, register);
|
||||
res = i2c_smbus_read_word_data(file, reg);
|
||||
if (res < 0) {
|
||||
/* ERROR HANDLING: i2c transaction failed */
|
||||
} else {
|
||||
|
|
@ -70,11 +70,11 @@ the device supports them. Both are illustrated below.
|
|||
}
|
||||
|
||||
/* Using I2C Write, equivalent of
|
||||
i2c_smbus_write_word_data(file, register, 0x6543) */
|
||||
buf[0] = register;
|
||||
i2c_smbus_write_word_data(file, reg, 0x6543) */
|
||||
buf[0] = reg;
|
||||
buf[1] = 0x43;
|
||||
buf[2] = 0x65;
|
||||
if (write(file, buf, 3) ! =3) {
|
||||
if (write(file, buf, 3) != 3) {
|
||||
/* ERROR HANDLING: i2c transaction failed */
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -3541,6 +3541,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
|||
bogus residue values);
|
||||
s = SINGLE_LUN (the device has only one
|
||||
Logical Unit);
|
||||
u = IGNORE_UAS (don't bind to the uas driver);
|
||||
w = NO_WP_DETECT (don't test whether the
|
||||
medium is write-protected).
|
||||
Example: quirks=0419:aaf5:rl,0421:0433:rc
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ acts similar to /dev/rtc and reacts on free-fall interrupts received
|
|||
from the device. It supports blocking operations, poll/select and
|
||||
fasync operation modes. You must read 1 bytes from the device. The
|
||||
result is number of free-fall interrupts since the last successful
|
||||
read (or 255 if number of interrupts would not fit). See the hpfall.c
|
||||
read (or 255 if number of interrupts would not fit). See the freefall.c
|
||||
file for an example on using the device.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -462,9 +462,9 @@ JIT compiler
|
|||
------------
|
||||
|
||||
The Linux kernel has a built-in BPF JIT compiler for x86_64, SPARC, PowerPC,
|
||||
ARM and s390 and can be enabled through CONFIG_BPF_JIT. The JIT compiler is
|
||||
transparently invoked for each attached filter from user space or for internal
|
||||
kernel users if it has been previously enabled by root:
|
||||
ARM, MIPS and s390 and can be enabled through CONFIG_BPF_JIT. The JIT compiler
|
||||
is transparently invoked for each attached filter from user space or for
|
||||
internal kernel users if it has been previously enabled by root:
|
||||
|
||||
echo 1 > /proc/sys/net/core/bpf_jit_enable
|
||||
|
||||
|
|
|
|||
|
|
@ -143,8 +143,9 @@ This will cause the core to recalculate the total load on the regulator (based
|
|||
on all its consumers) and change operating mode (if necessary and permitted)
|
||||
to best match the current operating load.
|
||||
|
||||
The load_uA value can be determined from the consumers datasheet. e.g.most
|
||||
datasheets have tables showing the max current consumed in certain situations.
|
||||
The load_uA value can be determined from the consumer's datasheet. e.g. most
|
||||
datasheets have tables showing the maximum current consumed in certain
|
||||
situations.
|
||||
|
||||
Most consumers will use indirect operating mode control since they have no
|
||||
knowledge of the regulator or whether the regulator is shared with other
|
||||
|
|
@ -173,7 +174,7 @@ Consumers can register interest in regulator events by calling :-
|
|||
int regulator_register_notifier(struct regulator *regulator,
|
||||
struct notifier_block *nb);
|
||||
|
||||
Consumers can uregister interest by calling :-
|
||||
Consumers can unregister interest by calling :-
|
||||
|
||||
int regulator_unregister_notifier(struct regulator *regulator,
|
||||
struct notifier_block *nb);
|
||||
|
|
|
|||
|
|
@ -9,14 +9,14 @@ Safety
|
|||
|
||||
- Errors in regulator configuration can have very serious consequences
|
||||
for the system, potentially including lasting hardware damage.
|
||||
- It is not possible to automatically determine the power confugration
|
||||
- It is not possible to automatically determine the power configuration
|
||||
of the system - software-equivalent variants of the same chip may
|
||||
have different power requirments, and not all components with power
|
||||
have different power requirements, and not all components with power
|
||||
requirements are visible to software.
|
||||
|
||||
=> The API should make no changes to the hardware state unless it has
|
||||
specific knowledge that these changes are safe to do perform on
|
||||
this particular system.
|
||||
specific knowledge that these changes are safe to perform on this
|
||||
particular system.
|
||||
|
||||
Consumer use cases
|
||||
------------------
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Consider the following machine :-
|
|||
+-> [Consumer B @ 3.3V]
|
||||
|
||||
The drivers for consumers A & B must be mapped to the correct regulator in
|
||||
order to control their power supply. This mapping can be achieved in machine
|
||||
order to control their power supplies. This mapping can be achieved in machine
|
||||
initialisation code by creating a struct regulator_consumer_supply for
|
||||
each regulator.
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ to the 'Vcc' supply for Consumer A.
|
|||
|
||||
Constraints can now be registered by defining a struct regulator_init_data
|
||||
for each regulator power domain. This structure also maps the consumers
|
||||
to their supply regulator :-
|
||||
to their supply regulators :-
|
||||
|
||||
static struct regulator_init_data regulator1_data = {
|
||||
.constraints = {
|
||||
|
|
|
|||
|
|
@ -36,11 +36,11 @@ Some terms used in this document:-
|
|||
Consumers can be classified into two types:-
|
||||
|
||||
Static: consumer does not change its supply voltage or
|
||||
current limit. It only needs to enable or disable it's
|
||||
current limit. It only needs to enable or disable its
|
||||
power supply. Its supply voltage is set by the hardware,
|
||||
bootloader, firmware or kernel board initialisation code.
|
||||
|
||||
Dynamic: consumer needs to change it's supply voltage or
|
||||
Dynamic: consumer needs to change its supply voltage or
|
||||
current limit to meet operation demands.
|
||||
|
||||
|
||||
|
|
@ -156,7 +156,7 @@ relevant to non SoC devices and is split into the following four interfaces:-
|
|||
This interface is for machine specific code and allows the creation of
|
||||
voltage/current domains (with constraints) for each regulator. It can
|
||||
provide regulator constraints that will prevent device damage through
|
||||
overvoltage or over current caused by buggy client drivers. It also
|
||||
overvoltage or overcurrent caused by buggy client drivers. It also
|
||||
allows the creation of a regulator tree whereby some regulators are
|
||||
supplied by others (similar to a clock tree).
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Drivers can register a regulator by calling :-
|
|||
struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
|
||||
const struct regulator_config *config);
|
||||
|
||||
This will register the regulators capabilities and operations to the regulator
|
||||
This will register the regulator's capabilities and operations to the regulator
|
||||
core.
|
||||
|
||||
Regulators can be unregistered by calling :-
|
||||
|
|
@ -23,8 +23,8 @@ void regulator_unregister(struct regulator_dev *rdev);
|
|||
|
||||
Regulator Events
|
||||
================
|
||||
Regulators can send events (e.g. over temp, under voltage, etc) to consumer
|
||||
drivers by calling :-
|
||||
Regulators can send events (e.g. overtemperature, undervoltage, etc) to
|
||||
consumer drivers by calling :-
|
||||
|
||||
int regulator_notifier_call_chain(struct regulator_dev *rdev,
|
||||
unsigned long event, void *data);
|
||||
|
|
|
|||
Loading…
Reference in a new issue