DP83867 works on BBAI TIDL.

.gitignore

@@ -124,3 +124,7 @@ all.config
 
 # Kdevelop4
 *.kdev4
+
+# dtb objects
+*.dtb
+*.dtbo

Documentation/ABI/testing/debugfs-aufs

@@ -0,0 +1,55 @@
+What: /debug/aufs/si_<id>/
+Date: March 2009
+Contact: J. R. Okajima <[email protected]>
+Description:
+ Under /debug/aufs, a directory named si_<id> is created
+ per aufs mount, where <id> is a unique id generated
+ internally.
+
+What: /debug/aufs/si_<id>/plink
+Date: Apr 2013
+Contact: J. R. Okajima <[email protected]>
+Description:
+ It has three lines and shows the information about the
+ pseudo-link. The first line is a single number
+ representing a number of buckets. The second line is a
+ number of pseudo-links per buckets (separated by a
+ blank). The last line is a single number representing a
+ total number of psedo-links.
+ When the aufs mount option 'noplink' is specified, it
+ will show "1\n0\n0\n".
+
+What: /debug/aufs/si_<id>/xib
+Date: March 2009
+Contact: J. R. Okajima <[email protected]>
+Description:
+ It shows the consumed blocks by xib (External Inode Number
+ Bitmap), its block size and file size.
+ When the aufs mount option 'noxino' is specified, it
+ will be empty. About XINO files, see the aufs manual.
+
+What: /debug/aufs/si_<id>/xi0, xi1 ... xiN and xiN-N
+Date: March 2009
+Contact: J. R. Okajima <[email protected]>
+Description:
+ It shows the consumed blocks by xino (External Inode Number
+ Translation Table), its link count, block size and file
+ size.
+ Due to the file size limit, there may exist multiple
+ xino files per branch. In this case, "-N" is added to
+ the filename and it corresponds to the index of the
+ internal xino array. "-0" is omitted.
+ When the aufs mount option 'noxino' is specified, Those
+ entries won't exist. About XINO files, see the aufs
+ manual.
+
+What: /debug/aufs/si_<id>/xigen
+Date: March 2009
+Contact: J. R. Okajima <[email protected]>
+Description:
+ It shows the consumed blocks by xigen (External Inode
+ Generation Table), its block size and file size.
+ If CONFIG_AUFS_EXPORT is disabled, this entry will not
+ be created.
+ When the aufs mount option 'noxino' is specified, it
+ will be empty. About XINO files, see the aufs manual.

Documentation/ABI/testing/sysfs-aufs

@@ -0,0 +1,31 @@
+What: /sys/fs/aufs/si_<id>/
+Date: March 2009
+Contact: J. R. Okajima <[email protected]>
+Description:
+ Under /sys/fs/aufs, a directory named si_<id> is created
+ per aufs mount, where <id> is a unique id generated
+ internally.
+
+What: /sys/fs/aufs/si_<id>/br0, br1 ... brN
+Date: March 2009
+Contact: J. R. Okajima <[email protected]>
+Description:
+ It shows the abolute path of a member directory (which
+ is called branch) in aufs, and its permission.
+
+What: /sys/fs/aufs/si_<id>/brid0, brid1 ... bridN
+Date: July 2013
+Contact: J. R. Okajima <[email protected]>
+Description:
+ It shows the id of a member directory (which is called
+ branch) in aufs.
+
+What: /sys/fs/aufs/si_<id>/xi_path
+Date: March 2009
+Contact: J. R. Okajima <[email protected]>
+Description:
+ It shows the abolute path of XINO (External Inode Number
+ Bitmap, Translation Table and Generation Table) file
+ even if it is the default path.
+ When the aufs mount option 'noxino' is specified, it
+ will be empty. About XINO files, see the aufs manual.

Documentation/ABI/testing/sysfs-devices-platform-bone_capemgr

@@ -0,0 +1,63 @@
+What: /sys/devices/platform/bone_capemgr/slots
+Date: May 2015
+KernelVersion: 4.0
+Contact: Pantelis Antoniou <[email protected]>
+Description:
+ READ:
+ Describe the state of all the slots of the beaglebone capemgr.
+ Each line of the output describes a slot:
+ The slot format is as following:
+ <slot-id>: [P-][F-][O-][l-][L-][D-] \
+ <overlay-id> <board-name>,<version>,
+ <manufacturer>,<part-number>
+
+ Where the flags are:
+ P: Slot has been probed
+ F: Slot has failed probing (i.e. no EEPROM detected)
+ O: Slot has been overridden by the user
+ l: Slot is current loading
+ L: Slot has completed loading and is ready
+ D: Slot has been disabled
+
+ Example:
+ 0: P---L- -1 BeagleBone RS232 CAPE,00A1,Beagleboardtoys,BB-BONE-SERL-03
+ 1: PF---- -1
+ 2: PF---- -1
+ 3: PF---- -1
+
+ WRITE:
+ Writing a string of the form <part-number>[:version] issues a request to
+ load a firmware blob containing an overlay. The name of the firmware blob
+ is <part-number>-[version|00A0].dtbo. This act is defined as a slot override.
+
+ Writing a negative slot id removes the slot if it was an overridden one, or
+ unloads a slot that was probed.
+
+What: /sys/devices/platform/bone_capemgr/baseboard/<eeprom-field>
+Date: May 2015
+KernelVersion: 4.0
+Contact: Pantelis Antoniou <[email protected]>
+Description: Contains the probed base board EEPROM field; one of:
+ board-name - board-name as stored in cape EEPROM
+ dc-supplied - whether the cape draws or supplies DC
+ eeprom-format-revision - EEPROM format rev, only 00A0 supported
+ header - header; should be 'aa 55 33 ee'
+ manufacturer - manufacturer string
+ part-number - part-number of the cape
+ serial-number - serial number of the cape
+ version - version of the cape, i.e. 00A0
+ number-of-pins - displayed but ignored
+ pin-usage - displayed but ignored
+ sys-5v - displayed but ignored
+ vdd-3v3exp - displayed but ignored
+ vdd-5v - displayed but ignored
+What: /sys/devices/platform/bone_capemgr/slot-<n>/<eeprom-field>
+Date: May 2015
+KernelVersion: 4.0
+Contact: Pantelis Antoniou <[email protected]>
+Description: Contains the probed cape's EEPROM field; the field is one of:
+ board-name - baseboard name i.e. A335BNLT
+ header - header; should be 'aa 55 33 ee'
+ revision - baseboard revision
+ serial-number - baseboard serial number
+ config-option - displayed but ignored

Documentation/ABI/testing/sysfs-firmware-devicetree-overlays

@@ -0,0 +1,52 @@
+What: /sys/firmware/devicetree/overlays/
+Date: October 2015
+Contact: Pantelis Antoniou <[email protected]>
+Description:
+ This directory contains the applied device tree overlays of
+ the running system, as directories of the overlay id.
+
+What: /sys/firmware/devicetree/overlays/enable
+Date: October 2015
+Contact: Pantelis Antoniou <[email protected]>
+Description:
+ The master enable switch, by default is 1, and when
+ set to 0 it cannot be re-enabled for security reasons.
+
+ The discussion about this switch takes place in:
+ http://comments.gmane.org/gmane.linux.drivers.devicetree/101871
+
+ Kees Cook:
+ "Coming from the perspective of drawing a bright line between
+ kernel and the root user (which tends to start with disabling
+ kernel module loading), I would say that there at least needs
+ to be a high-level one-way "off" switch for the interface so
+ that systems that have this interface can choose to turn it off
+ during initial boot, etc."
+
+What: /sys/firmware/devicetree/overlays/<id>
+Date: October 2015
+Contact: Pantelis Antoniou <[email protected]>
+Description:
+ Each directory represents an applied overlay, containing
+ the following attribute files.
+
+What: /sys/firmware/devicetree/overlays/<id>/can_remove
+Date: October 2015
+Contact: Pantelis Antoniou <[email protected]>
+Description:
+ The attribute set to 1 means that the overlay can be removed,
+ while 0 means that the overlay is being overlapped therefore
+ removal is prohibited.
+
+What: /sys/firmware/devicetree/overlays/<id>/<fragment-name>/
+Date: October 2015
+Contact: Pantelis Antoniou <[email protected]>
+Description:
+ Each of these directories contain information about of the
+ particular overlay fragment.
+
+What: /sys/firmware/devicetree/overlays/<id>/<fragment-name>/target
+Date: October 2015
+Contact: Pantelis Antoniou <[email protected]>
+Description:
+ The full-path of the target of the fragment

Documentation/admin-guide/kernel-parameters.txt

@@ -2883,6 +2883,8 @@
  This can be set from sysctl after boot.
  See Documentation/sysctl/vm.txt for details.
 
+ of_overlay_disable [OF] Disable device tree overlays at boot time.
+
  ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
  See Documentation/debugging-via-ohci1394.txt for more
  info.

Documentation/devicetree/bindings/arm/omap/omap.txt

@@ -24,6 +24,8 @@ Optional properties:
 - ti,no-reset-on-init: When present, the module should not be reset at init
 - ti,no-idle-on-init: When present, the module should not be idled at init
 - ti,no-idle: When present, the module is never allowed to idle.
+- ti,deassert-hard-reset: list of hwmod and hardware reset line name pairs
+ (ascii strings) to be deasserted upon device instantiation.
 
 Example:
 

Documentation/devicetree/bindings/misc/bone_capemgr.txt

@@ -0,0 +1,111 @@
+* Beaglebone cape manager driver
+
+Required properties:
+- compatible: "ti,bone-capemgr"
+- eeprom: phandle to the EEPROM baseboard.
+ The EEPROM framework interface is use to obtain the data.
+
+Required children nodes:
+
+- baseboardmaps: Contains nodes, which each of the them defines a mapping from
+ the baseboard EEPROM board-name ID to a DT friendly compatible
+ string.
+
+ - board-name: The baseboard EEPROM board name, i.e. A335BONE for the
+ original beaglebone white.
+ - compatible-name: The DT friendly compatible string to be used for matching
+ compatible capes, i.e. "ti,beaglebone"
+
+
+ - nvmem-cells: Defines the phandles of the nvmem cells of the baseboard and the
+ slots.
+ - nvmem-cells: Defines the names of the nvmem cells. Required to have at
+ least a baseboard cell name.
+
+ - #slots: Defines how many slots are there.
+
+- Example of a beaglebone cape-manager:
+
+bone_capemgr {
+ compatible = "ti,bone-capemgr";
+ status = "okay";
+
+ nvmem-cell = <&baseboard_data
+ &cape0_data &cape1_data &cape2_data &cape3_data>;
+ nvmem-cell-names = "baseboard", "slot0", "slot1", "slot2", "slot3";
+
+ #slots = <4>;
+
+ /* map board revisions to compatible definitions */
+ baseboardmaps {
+ baseboard_beaglebone: board@0 {
+ board-name = "A335BONE";
+ compatible-name = "ti,beaglebone";
+ };
+
+ baseboard_beaglebone_black: board@1 {
+ board-name = "A335BNLT";
+ compatible-name = "ti,beaglebone-black";
+ };
+ };
+};
+
+The format of the cape to be loaded is in a standard overlay format with
+the following root properties that are interpreted by the cape manager:
+
+Required properties:
+ - compatible: Should be compatible to the baseboard according to the
+ baseboard map value, i.e. "ti,beaglebone".
+ - part-numer: Should contain the part-number as stored in the EEPROM.
+ - version: Should contain a list of all the version that are supported
+ by the single cape dtbo, i.e. "00A1".
+
+Optional properties:
+ - exclusive-use: A string list which state the resources this cape requires.
+ No processing or matching to anything regarding the internal
+ kernel state is performed; it's purpose is to guard against
+ conflicts with other capes.
+ - priority: A priority to be assigned when loading a cape. A lower value
+ has higher priority. The purpose of the priority is to control
+ which cape is loaded first in case of a conflict.
+
+- Example of a serial cape:
+
+/dts-v1/;
+/plugin/;
+/ {
+ compatible = "ti,beaglebone", "ti,beaglebone-black";
+
+ /* identification */
+ part-number = "BB-BONE-SERL-03";
+ version = "00A1";
+
+ /* state the resources this cape uses */
+ exclusive-use =
+ /* the pin header uses */
+ "P9.21", /* uart2_txd */
+ "P9.22", /* uart2_rxd */
+ /* the hardware ip uses */
+ "uart2";
+
+ fragment@0 {
+ target = <&am33xx_pinmux>;
+ __overlay__ {
+ bb_uart2_pins: pinmux_bb_uart2_pins {
+ pinctrl-single,pins = <
+ 0x150 0x21 /* spi0_sclk.uart2_rxd | MODE1 */
+ 0x154 0x01 /* spi0_d0.uart2_txd | MODE1 */
+ >;
+ };
+ };
+ };
+
+ fragment@1 {
+ target = <&uart2>;
+ __overlay__ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&bb_uart2_pins>;
+ };
+ };
+};

Documentation/devicetree/configfs-overlays.txt

@@ -0,0 +1,31 @@
+Howto use the configfs overlay interface.
+
+A device-tree configfs entry is created in /config/device-tree/overlays
+and and it is manipulated using standard file system I/O.
+Note that this is a debug level interface, for use by developers and
+not necessarily something accessed by normal users due to the
+security implications of having direct access to the kernel's device tree.
+
+* To create an overlay you mkdir the directory:
+
+ # mkdir /config/device-tree/overlays/foo
+
+* Either you echo the overlay firmware file to the path property file.
+
+ # echo foo.dtbo >/config/device-tree/overlays/foo/path
+
+* Or you cat the contents of the overlay to the dtbo file
+
+ # cat foo.dtbo >/config/device-tree/overlays/foo/dtbo
+
+The overlay file will be applied, and devices will be created/destroyed
+as required.
+
+To remove it simply rmdir the directory.
+
+ # rmdir /config/device-tree/overlays/foo
+
+The rationalle of the dual interface (firmware & direct copy) is that each is
+better suited to different use patterns. The firmware interface is what's
+intended to be used by hardware managers in the kernel, while the copy interface
+make sense for developers (since it avoids problems with namespaces).