diff options
Diffstat (limited to 'Documentation')
128 files changed, 3495 insertions, 810 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd index 501adc2a9ec..2ddd680929d 100644 --- a/Documentation/ABI/testing/sysfs-bus-rbd +++ b/Documentation/ABI/testing/sysfs-bus-rbd @@ -94,5 +94,5 @@ current_snap parent - Information identifying the pool, image, and snapshot id for - the parent image in a layered rbd image (format 2 only). + Information identifying the chain of parent images in a layered rbd + image. Entries are separated by empty lines. diff --git a/Documentation/ABI/testing/sysfs-class-leds-gt683r b/Documentation/ABI/testing/sysfs-class-leds-gt683r new file mode 100644 index 00000000000..e4fae6026e7 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-leds-gt683r @@ -0,0 +1,16 @@ +What: /sys/class/leds/<led>/gt683r/mode +Date: Jun 2014 +KernelVersion: 3.17 +Contact: Janne Kanniainen <janne.kanniainen@gmail.com> +Description: + Set the mode of LEDs. You should notice that changing the mode + of one LED will update the mode of its two sibling devices as + well. + + 0 - normal + 1 - audio + 2 - breathing + + Normal: LEDs are fully on when enabled + Audio: LEDs brightness depends on sound level + Breathing: LEDs brightness varies at human breathing rate
\ No newline at end of file diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd index 1399bb2da3e..76ee192f80a 100644 --- a/Documentation/ABI/testing/sysfs-class-mtd +++ b/Documentation/ABI/testing/sysfs-class-mtd @@ -184,3 +184,41 @@ Description: It will always be a non-negative integer. In the case of devices lacking any ECC capability, it is 0. + +What: /sys/class/mtd/mtdX/ecc_failures +Date: June 2014 +KernelVersion: 3.17 +Contact: linux-mtd@lists.infradead.org +Description: + The number of failures reported by this device's ECC. Typically, + these failures are associated with failed read operations. + + It will always be a non-negative integer. In the case of + devices lacking any ECC capability, it is 0. + +What: /sys/class/mtd/mtdX/corrected_bits +Date: June 2014 +KernelVersion: 3.17 +Contact: linux-mtd@lists.infradead.org +Description: + The number of bits that have been corrected by means of the + device's ECC. + + It will always be a non-negative integer. In the case of + devices lacking any ECC capability, it is 0. + +What: /sys/class/mtd/mtdX/bad_blocks +Date: June 2014 +KernelVersion: 3.17 +Contact: linux-mtd@lists.infradead.org +Description: + The number of blocks marked as bad, if any, in this partition. + +What: /sys/class/mtd/mtdX/bbt_blocks +Date: June 2014 +KernelVersion: 3.17 +Contact: linux-mtd@lists.infradead.org +Description: + The number of blocks that are marked as reserved, if any, in + this partition. These are typically used to store the in-flash + bad block table (BBT). diff --git a/Documentation/ABI/testing/sysfs-driver-pciback b/Documentation/ABI/testing/sysfs-driver-pciback new file mode 100644 index 00000000000..6a733bfa37e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-pciback @@ -0,0 +1,13 @@ +What: /sys/bus/pci/drivers/pciback/quirks +Date: Oct 2011 +KernelVersion: 3.1 +Contact: xen-devel@lists.xenproject.org +Description: + If the permissive attribute is set, then writing a string in + the format of DDDD:BB:DD.F-REG:SIZE:MASK will allow the guest + to write and read from the PCI device. That is Domain:Bus: + Device.Function-Register:Size:Mask (Domain is optional). + For example: + #echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks + will allow the guest to read and write to the configuration + register 0x0E. diff --git a/Documentation/ABI/testing/sysfs-driver-tegra-fuse b/Documentation/ABI/testing/sysfs-driver-tegra-fuse new file mode 100644 index 00000000000..69f5af63265 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-tegra-fuse @@ -0,0 +1,11 @@ +What: /sys/devices/*/<our-device>/fuse +Date: February 2014 +Contact: Peter De Schrijver <pdeschrijver@nvidia.com> +Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114 + and Tegra124 SoC's from NVIDIA. The efuses contain write once + data programmed at the factory. The data is layed out in 32bit + words in LSB first format. Each bit represents a single value + as decoded from the fuse registers. Bits order/assignment + exactly matches the HW registers, including any unused bits. +Users: any user space application which wants to read the efuses on + Tegra SoC's diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom index 7fc781048b7..c4f0fed64a6 100644 --- a/Documentation/ABI/testing/sysfs-driver-wacom +++ b/Documentation/ABI/testing/sysfs-driver-wacom @@ -1,48 +1,27 @@ -WWhat: /sys/class/hidraw/hidraw*/device/oled*_img -Date: June 2012 -Contact: linux-bluetooth@vger.kernel.org -Description: - The /sys/class/hidraw/hidraw*/device/oled*_img files control - OLED mocro displays on Intuos4 Wireless tablet. Accepted image - has to contain 256 bytes (64x32 px 1 bit colour). The format - is the same as PBM image 62x32px without header (64 bits per - horizontal line, 32 lines). An example of setting OLED No. 0: - dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img - The attribute is read only and no local copy of the image is - stored. - -What: /sys/class/hidraw/hidraw*/device/speed +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed Date: April 2010 Kernel Version: 2.6.35 Contact: linux-bluetooth@vger.kernel.org Description: - The /sys/class/hidraw/hidraw*/device/speed file controls - reporting speed of Wacom bluetooth tablet. Reading from - this file returns 1 if tablet reports in high speed mode + The /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed file + controls reporting speed of Wacom bluetooth tablet. Reading + from this file returns 1 if tablet reports in high speed mode or 0 otherwise. Writing to this file one of these values switches reporting speed. -What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/ -Date: May 2012 -Kernel Version: 3.5 -Contact: linux-bluetooth@vger.kernel.org -Description: - LED selector for Intuos4 WL. There are 4 leds, but only one LED - can be lit at a time. Max brightness is 127. - -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led -Date: August 2011 +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/led +Date: August 2014 Contact: linux-input@vger.kernel.org Description: Attribute group for control of the status LEDs and the OLEDs. This attribute group is only available for Intuos 4 M, L, - and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq - 21UX2 and Cintiq 24HD (LEDs only). Therefore its presence - implicitly signifies the presence of said LEDs and OLEDs on the - tablet device. + and XL (with LEDs and OLEDs), Intuos 4 WL, Intuos 5 (LEDs only), + Intuos Pro (LEDs only) and Cintiq 21UX2 and Cintiq 24HD + (LEDs only). Therefore its presence implicitly signifies the + presence of said LEDs and OLEDs on the tablet device. -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance -Date: August 2011 +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance +Date: August 2014 Contact: linux-input@vger.kernel.org Description: Writing to this file sets the status LED luminance (1..127) @@ -50,16 +29,16 @@ Description: button is pressed on the stylus. This luminance level is normally lower than the level when a button is pressed. -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance -Date: August 2011 +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance +Date: August 2014 Contact: linux-input@vger.kernel.org Description: Writing to this file sets the status LED luminance (1..127) when the stylus touches the tablet surface, or any button is pressed on the stylus. -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select -Date: August 2011 +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select +Date: August 2014 Contact: linux-input@vger.kernel.org Description: Writing to this file sets which one of the four (for Intuos 4 @@ -67,23 +46,23 @@ Description: 24HD) status LEDs is active (0..3). The other three LEDs on the same side are always inactive. -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select -Date: September 2011 +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select +Date: August 2014 Contact: linux-input@vger.kernel.org Description: Writing to this file sets which one of the left four (for Cintiq 21UX2 and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on the left are always inactive. -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance -Date: August 2011 +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/buttons_luminance +Date: August 2014 Contact: linux-input@vger.kernel.org Description: Writing to this file sets the overall luminance level (0..15) of all eight button OLED displays. -What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg -Date: August 2011 +What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/button<n>_rawimg +Date: August 2014 Contact: linux-input@vger.kernel.org Description: When writing a 1024 byte raw image in Wacom Intuos 4 @@ -93,3 +72,8 @@ Description: byte chunk encodes the image data for two consecutive lines on the display. The low nibble of each byte contains the first line, and the high nibble contains the second line. + When the Wacom Intuos 4 is connected over Bluetooth, the + image has to contain 256 bytes (64x32 px 1 bit colour). + The format is also scrambled, like in the USB mode, and it can + be summarized by converting 76543210 into GECA6420. + HGFEDCBA HFDB7531 diff --git a/Documentation/ABI/testing/sysfs-fs-nilfs2 b/Documentation/ABI/testing/sysfs-fs-nilfs2 new file mode 100644 index 00000000000..304ba84a973 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-fs-nilfs2 @@ -0,0 +1,269 @@ + +What: /sys/fs/nilfs2/features/revision +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show current revision of NILFS file system driver. + This value informs about file system revision that + driver is ready to support. + +What: /sys/fs/nilfs2/features/README +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Describe attributes of /sys/fs/nilfs2/features group. + +What: /sys/fs/nilfs2/<device>/revision +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show NILFS file system revision on volume. + This value informs about metadata structures' + revision on mounted volume. + +What: /sys/fs/nilfs2/<device>/blocksize +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show volume's block size in bytes. + +What: /sys/fs/nilfs2/<device>/device_size +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show volume size in bytes. + +What: /sys/fs/nilfs2/<device>/free_blocks +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show count of free blocks on volume. + +What: /sys/fs/nilfs2/<device>/uuid +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show volume's UUID (Universally Unique Identifier). + +What: /sys/fs/nilfs2/<device>/volume_name +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show volume's label. + +What: /sys/fs/nilfs2/<device>/README +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Describe attributes of /sys/fs/nilfs2/<device> group. + +What: /sys/fs/nilfs2/<device>/superblock/sb_write_time +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show last write time of super block in human-readable + format. + +What: /sys/fs/nilfs2/<device>/superblock/sb_write_time_secs +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show last write time of super block in seconds. + +What: /sys/fs/nilfs2/<device>/superblock/sb_write_count +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show current write count of super block. + +What: /sys/fs/nilfs2/<device>/superblock/sb_update_frequency +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show/Set interval of periodical update of superblock + (in seconds). + +What: /sys/fs/nilfs2/<device>/superblock/README +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Describe attributes of /sys/fs/nilfs2/<device>/superblock + group. + +What: /sys/fs/nilfs2/<device>/segctor/last_pseg_block +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show start block number of the latest segment. + +What: /sys/fs/nilfs2/<device>/segctor/last_seg_sequence +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show sequence value of the latest segment. + +What: /sys/fs/nilfs2/<device>/segctor/last_seg_checkpoint +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show checkpoint number of the latest segment. + +What: /sys/fs/nilfs2/<device>/segctor/current_seg_sequence +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show segment sequence counter. + +What: /sys/fs/nilfs2/<device>/segctor/current_last_full_seg +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show index number of the latest full segment. + +What: /sys/fs/nilfs2/<device>/segctor/next_full_seg +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show index number of the full segment index + to be used next. + +What: /sys/fs/nilfs2/<device>/segctor/next_pseg_offset +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show offset of next partial segment in the current + full segment. + +What: /sys/fs/nilfs2/<device>/segctor/next_checkpoint +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show next checkpoint number. + +What: /sys/fs/nilfs2/<device>/segctor/last_seg_write_time +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show write time of the last segment in + human-readable format. + +What: /sys/fs/nilfs2/<device>/segctor/last_seg_write_time_secs +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show write time of the last segment in seconds. + +What: /sys/fs/nilfs2/<device>/segctor/last_nongc_write_time +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show write time of the last segment not for cleaner + operation in human-readable format. + +What: /sys/fs/nilfs2/<device>/segctor/last_nongc_write_time_secs +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show write time of the last segment not for cleaner + operation in seconds. + +What: /sys/fs/nilfs2/<device>/segctor/dirty_data_blocks_count +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show number of dirty data blocks. + +What: /sys/fs/nilfs2/<device>/segctor/README +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Describe attributes of /sys/fs/nilfs2/<device>/segctor + group. + +What: /sys/fs/nilfs2/<device>/segments/segments_number +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show number of segments on a volume. + +What: /sys/fs/nilfs2/<device>/segments/blocks_per_segment +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show number of blocks in segment. + +What: /sys/fs/nilfs2/<device>/segments/clean_segments +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show count of clean segments. + +What: /sys/fs/nilfs2/<device>/segments/dirty_segments +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show count of dirty segments. + +What: /sys/fs/nilfs2/<device>/segments/README +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Describe attributes of /sys/fs/nilfs2/<device>/segments + group. + +What: /sys/fs/nilfs2/<device>/checkpoints/checkpoints_number +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show number of checkpoints on volume. + +What: /sys/fs/nilfs2/<device>/checkpoints/snapshots_number +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show number of snapshots on volume. + +What: /sys/fs/nilfs2/<device>/checkpoints/last_seg_checkpoint +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show checkpoint number of the latest segment. + +What: /sys/fs/nilfs2/<device>/checkpoints/next_checkpoint +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show next checkpoint number. + +What: /sys/fs/nilfs2/<device>/checkpoints/README +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Describe attributes of /sys/fs/nilfs2/<device>/checkpoints + group. + +What: /sys/fs/nilfs2/<device>/mounted_snapshots/README +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Describe content of /sys/fs/nilfs2/<device>/mounted_snapshots + group. + +What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/inodes_count +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show number of inodes for snapshot. + +What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/blocks_count +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Show number of blocks for snapshot. + +What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/README +Date: April 2014 +Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com> +Description: + Describe attributes of /sys/fs/nilfs2/<device>/mounted_snapshots/<id> + group. diff --git a/Documentation/ABI/testing/sysfs-fs-xfs b/Documentation/ABI/testing/sysfs-fs-xfs new file mode 100644 index 00000000000..ea0cc8c4209 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-fs-xfs @@ -0,0 +1,39 @@ +What: /sys/fs/xfs/<disk>/log/log_head_lsn +Date: July 2014 +KernelVersion: 3.17 +Contact: xfs@oss.sgi.com +Description: + The log sequence number (LSN) of the current head of the + log. The LSN is exported in "cycle:basic block" format. +Users: xfstests + +What: /sys/fs/xfs/<disk>/log/log_tail_lsn +Date: July 2014 +KernelVersion: 3.17 +Contact: xfs@oss.sgi.com +Description: + The log sequence number (LSN) of the current tail of the + log. The LSN is exported in "cycle:basic block" format. + +What: /sys/fs/xfs/<disk>/log/reserve_grant_head +Date: July 2014 +KernelVersion: 3.17 +Contact: xfs@oss.sgi.com +Description: + The current state of the log reserve grant head. It + represents the total log reservation of all currently + outstanding transactions. The grant head is exported in + "cycle:bytes" format. +Users: xfstests + +What: /sys/fs/xfs/<disk>/log/write_grant_head +Date: July 2014 +KernelVersion: 3.17 +Contact: xfs@oss.sgi.com +Description: + The current state of the log write grant head. It + represents the total log reservation of all currently + oustanding transactions, including regrants due to + rolling transactions. The grant head is exported in + "cycle:bytes" format. +Users: xfstests diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 7df3134ebc0..1d3756d3176 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -1610,7 +1610,7 @@ int max_width, max_height;</synopsis> The connector is then registered with a call to <function>drm_connector_init</function> with a pointer to the connector functions and a connector type, and exposed through sysfs with a call to - <function>drm_sysfs_connector_add</function>. + <function>drm_connector_register</function>. </para> <para> Supported connector types are @@ -1768,7 +1768,7 @@ int max_width, max_height;</synopsis> (<function>drm_encoder_cleanup</function>) and connectors (<function>drm_connector_cleanup</function>). Furthermore, connectors that have been added to sysfs must be removed by a call to - <function>drm_sysfs_connector_remove</function> before calling + <function>drm_connector_unregister</function> before calling <function>drm_connector_cleanup</function>. </para> <para> @@ -1813,7 +1813,7 @@ void intel_crt_init(struct drm_device *dev) drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs); drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs); - drm_sysfs_connector_add(connector); + drm_connector_register(connector); }]]></programlisting> <para> In the example above (taken from the i915 driver), a CRTC, connector and @@ -2338,6 +2338,12 @@ void intel_crt_init(struct drm_device *dev) !Edrivers/gpu/drm/drm_dp_helper.c </sect2> <sect2> + <title>Display Port MST Helper Functions Reference</title> +!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper +!Iinclude/drm/drm_dp_mst_helper.h +!Edrivers/gpu/drm/drm_dp_mst_topology.c + </sect2> + <sect2> <title>EDID Helper Functions Reference</title> !Edrivers/gpu/drm/drm_edid.c </sect2> @@ -2502,7 +2508,7 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >Description/Restrictions</td> </tr> <tr> - <td rowspan="20" valign="top" >DRM</td> + <td rowspan="21" valign="top" >DRM</td> <td rowspan="2" valign="top" >Generic</td> <td valign="top" >“EDID”</td> <td valign="top" >BLOB | IMMUTABLE</td> @@ -2633,7 +2639,7 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> - <td rowspan="2" valign="top" >Optional</td> + <td rowspan="3" valign="top" >Optional</td> <td valign="top" >“scaling mode”</td> <td valign="top" >ENUM</td> <td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td> @@ -2641,6 +2647,15 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> + <td valign="top" >"aspect ratio"</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "None", "4:3", "16:9" }</td> + <td valign="top" >Connector</td> + <td valign="top" >DRM property to set aspect ratio from user space app. + This enum is made generic to allow addition of custom aspect + ratios.</td> + </tr> + <tr> <td valign="top" >“dirty”</td> <td valign="top" >ENUM | IMMUTABLE</td> <td valign="top" >{ "Off", "On", "Annotate" }</td> @@ -2649,7 +2664,7 @@ void intel_crt_init(struct drm_device *dev) </tr> <tr> <td rowspan="21" valign="top" >i915</td> - <td rowspan="3" valign="top" >Generic</td> + <td rowspan="2" valign="top" >Generic</td> <td valign="top" >"Broadcast RGB"</td> <td valign="top" >ENUM</td> <td valign="top" >{ "Automatic", "Full", "Limited 16:235" }</td> @@ -2664,10 +2679,11 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> - <td valign="top" >Standard name as in DRM</td> - <td valign="top" >Standard type as in DRM</td> - <td valign="top" >Standard value as in DRM</td> - <td valign="top" >Standard Object as in DRM</td> + <td rowspan="1" valign="top" >Plane</td> + <td valign="top" >“rotation”</td> + <td valign="top" >BITMASK</td> + <td valign="top" >{ 0, "rotate-0" }, { 2, "rotate-180" }</td> + <td valign="top" >Plane</td> <td valign="top" >TBD</td> </tr> <tr> @@ -2799,8 +2815,8 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> - <td rowspan="3" valign="top" >CDV gma-500</td> - <td rowspan="3" valign="top" >Generic</td> + <td rowspan="2" valign="top" >CDV gma-500</td> + <td rowspan="2" valign="top" >Generic</td> <td valign="top" >"Broadcast RGB"</td> <td valign="top" >ENUM</td> <td valign="top" >{ “Full”, “Limited 16:235” }</td> @@ -2815,15 +2831,8 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> - <td valign="top" >Standard name as in DRM</td> - <td valign="top" >Standard type as in DRM</td> - <td valign="top" >Standard value as in DRM</td> - <td valign="top" >Standard Object as in DRM</td> - <td valign="top" >TBD</td> - </tr> - <tr> - <td rowspan="20" valign="top" >Poulsbo</td> - <td rowspan="2" valign="top" >Generic</td> + <td rowspan="19" valign="top" >Poulsbo</td> + <td rowspan="1" valign="top" >Generic</td> <td valign="top" >“backlight”</td> <td valign="top" >RANGE</td> <td valign="top" >Min=0, Max=100</td> @@ -2831,13 +2840,6 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> - <td valign="top" >Standard name as in DRM</td> - <td valign="top" >Standard type as in DRM</td> - <td valign="top" >Standard value as in DRM</td> - <td valign="top" >Standard Object as in DRM</td> - <td valign="top" >TBD</td> - </tr> - <tr> <td rowspan="17" valign="top" >SDVO-TV</td> <td valign="top" >“mode”</td> <td valign="top" >ENUM</td> @@ -3064,7 +3066,7 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> - <td rowspan="3" valign="top" >i2c/ch7006_drv</td> + <td rowspan="2" valign="top" >i2c/ch7006_drv</td> <td valign="top" >Generic</td> <td valign="top" >“scale”</td> <td valign="top" >RANGE</td> @@ -3073,14 +3075,7 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> - <td rowspan="2" valign="top" >TV</td> - <td valign="top" >Standard names as in DRM</td> - <td valign="top" >Standard types as in DRM</td> - <td valign="top" >Standard Values as in DRM</td> - <td valign="top" >Standard object as in DRM</td> - <td valign="top" >TBD</td> - </tr> - <tr> + <td rowspan="1" valign="top" >TV</td> <td valign="top" >“mode”</td> <td valign="top" >ENUM</td> <td valign="top" >{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc" @@ -3089,7 +3084,7 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> - <td rowspan="16" valign="top" >nouveau</td> + <td rowspan="15" valign="top" >nouveau</td> <td rowspan="6" valign="top" >NV10 Overlay</td> <td valign="top" >"colorkey"</td> <td valign="top" >RANGE</td> @@ -3198,14 +3193,6 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> - <td valign="top" >Generic</td> - <td valign="top" >Standard name as in DRM</td> - <td valign="top" >Standard type as in DRM</td> - <td valign="top" >Standard value as in DRM</td> - <td valign="top" >Standard Object as in DRM</td> - <td valign="top" >TBD</td> - </tr> - <tr> <td rowspan="2" valign="top" >omap</td> <td rowspan="2" valign="top" >Generic</td> <td valign="top" >“rotation”</td> @@ -3236,7 +3223,7 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> - <td rowspan="10" valign="top" >radeon</td> + <td rowspan="9" valign="top" >radeon</td> <td valign="top" >DVI-I</td> <td valign="top" >“coherent”</td> <td valign="top" >RANGE</td> @@ -3308,14 +3295,6 @@ void intel_crt_init(struct drm_device *dev) <td valign="top" >TBD</td> </tr> <tr> - <td valign="top" >Generic</td> - <td valign="top" >Standard name as in DRM</td> - <td valign="top" >Standard type as in DRM</td> - <td valign="top" >Standard value as in DRM</td> - <td valign="top" >Standard Object as in DRM</td> - <td valign="top" >TBD</td> - </tr> - <tr> <td rowspan="3" valign="top" >rcar-du</td> <td rowspan="3" valign="top" >Generic</td> <td valign="top" >"alpha"</td> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index dcadffcab2d..0a523c9a5ff 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -84,18 +84,42 @@ is another popular alternative. 2) Describe your changes. -Describe the technical detail of the change(s) your patch includes. - -Be as specific as possible. The WORST descriptions possible include -things like "update driver X", "bug fix for driver X", or "this patch -includes updates for subsystem X. Please apply." +Describe your problem. Whether your patch is a one-line bug fix or +5000 lines of a new feature, there must be an underlying problem that +motivated you to do this work. Convince the reviewer that there is a +problem worth fixing and that it makes sense for them to read past the +first paragraph. + +Describe user-visible impact. Straight up crashes and lockups are +pretty convincing, but not all bugs are that blatant. Even if the +problem was spotted during code review, describe the impact you think +it can have on users. Keep in mind that the majority of Linux +installations run kernels from secondary stable trees or +vendor/product-specific trees that cherry-pick only specific patches +from upstream, so include anything that could help route your change +downstream: provoking circumstances, excerpts from dmesg, crash +descriptions, performance regressions, latency spikes, lockups, etc. + +Quantify optimizations and trade-offs. If you claim improvements in +performance, memory consumption, stack footprint, or binary size, +include numbers that back them up. But also describe non-obvious +costs. Optimizations usually aren't free but trade-offs between CPU, +memory, and readability; or, when it comes to heuristics, between +different workloads. Describe the expected downsides of your +optimization so that the reviewer can weigh costs against benefits. + +Once the problem is established, describe what you are actually doing +about it in technical detail. It's important to describe the change +in plain English for the reviewer to verify that the code is behaving +as you intend it to. The maintainer will thank you if you write your patch description in a form which can be easily pulled into Linux's source code management system, git, as a "commit log". See #15, below. -If your description starts to get long, that's a sign that you probably -need to split up your patch. See #3, next. +Solve only one problem per patch. If your description starts to get +long, that's a sign that you probably need to split up your patch. +See #3, next. When you submit or resubmit a patch or patch series, include the complete patch description and justification for it. Don't just diff --git a/Documentation/arm/CCN.txt b/Documentation/arm/CCN.txt new file mode 100644 index 00000000000..0632b3aad83 --- /dev/null +++ b/Documentation/arm/CCN.txt @@ -0,0 +1,52 @@ +ARM Cache Coherent Network +========================== + +CCN-504 is a ring-bus interconnect consisting of 11 crosspoints +(XPs), with each crosspoint supporting up to two device ports, +so nodes (devices) 0 and 1 are connected to crosspoint 0, +nodes 2 and 3 to crosspoint 1 etc. + +PMU (perf) driver +----------------- + +The CCN driver registers a perf PMU driver, which provides +description of available events and configuration options +in sysfs, see /sys/bus/event_source/devices/ccn*. + +The "format" directory describes format of the config, config1 +and config2 fields of the perf_event_attr structure. The "events" +directory provides configuration templates for all documented +events, that can be used with perf tool. For example "xp_valid_flit" +is an equivalent of "type=0x8,event=0x4". Other parameters must be +explicitly specified. For events originating from device, "node" +defines its index. All crosspoint events require "xp" (index), +"port" (device port number) and "vc" (virtual channel ID) and +"dir" (direction). Watchpoints (special "event" value 0xfe) also +require comparator values ("cmp_l" and "cmp_h") and "mask", being +index of the comparator mask. + +Masks are defined separately from the event description +(due to limited number of the config values) in the "cmp_mask" +directory, with first 8 configurable by user and additional +4 hardcoded for the most frequent use cases. + +Cycle counter is described by a "type" value 0xff and does +not require any other settings. + +Example of perf tool use: + +/ # perf list | grep ccn + ccn/cycles/ [Kernel PMU event] +<...> + ccn/xp_valid_flit/ [Kernel PMU event] +<...> + +/ # perf stat -C 0 -e ccn/cycles/,ccn/xp_valid_flit,xp=1,port=0,vc=1,dir=1/ \ + sleep 1 + +The driver does not support sampling, therefore "perf record" will +not work. Also notice that only single cpu is being selected +("-C 0") - this is because perf framework does not support +"non-CPU related" counters (yet?) so system-wide session ("-a") +would try (and in most cases fail) to set up the same event +per each CPU. diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README index 2cce5401e32..4dc66c173e1 100644 --- a/Documentation/arm/Marvell/README +++ b/Documentation/arm/Marvell/README @@ -53,8 +53,8 @@ Kirkwood family Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf Homepage: http://www.marvell.com/embedded-processors/kirkwood/ Core: Feroceon ARMv5 compatible - Linux kernel mach directory: arch/arm/mach-kirkwood - Linux kernel plat directory: arch/arm/plat-orion + Linux kernel mach directory: arch/arm/mach-mvebu + Linux kernel plat directory: none Discovery family ---------------- @@ -83,7 +83,9 @@ EBU Armada family 88F6710 88F6707 88F6W11 - Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf + Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf + Hardware Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf + Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf Armada 375 Flavors: 88F6720 @@ -100,8 +102,7 @@ EBU Armada family MV78460 NOTE: not to be confused with the non-SMP 78xx0 SoCs Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf - - No public datasheet available. + Functional Spec: http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf Core: Sheeva ARMv7 compatible @@ -135,7 +136,9 @@ Dove family (application processor) Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf Homepage: http://www.marvell.com/application-processors/armada-500/ Core: ARMv7 compatible - Directory: arch/arm/mach-dove + + Directory: arch/arm/mach-mvebu (DT enabled platforms) + arch/arm/mach-dove (non-DT enabled platforms) PXA 2xx/3xx/93x/95x family -------------------------- @@ -253,10 +256,10 @@ Berlin family (Digital Entertainment) Long-term plans --------------- - * Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ and - mach-kirkwood/ into the mach-mvebu/ to support all SoCs from the - Marvell EBU (Engineering Business Unit) in a single mach-<foo> - directory. The plat-orion/ would therefore disappear. + * Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ into the + mach-mvebu/ to support all SoCs from the Marvell EBU (Engineering + Business Unit) in a single mach-<foo> directory. The plat-orion/ + would therefore disappear. * Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa directory. The plat-pxa/ would therefore disappear. diff --git a/Documentation/arm/Samsung/Overview.txt b/Documentation/arm/Samsung/Overview.txt index 658abb258ce..8f7309bad46 100644 --- a/Documentation/arm/Samsung/Overview.txt +++ b/Documentation/arm/Samsung/Overview.txt @@ -13,8 +13,6 @@ Introduction - S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list - S3C64XX: S3C6400 and S3C6410 - - S5P6440 - - S5PC100 - S5PC110 / S5PV210 @@ -34,8 +32,6 @@ Configuration A number of configurations are supplied, as there is no current way of unifying all the SoCs into one kernel. - s5p6440_defconfig - S5P6440 specific default configuration - s5pc100_defconfig - S5PC100 specific default configuration s5pc110_defconfig - S5PC110 specific default configuration s5pv210_defconfig - S5PV210 specific default configuration @@ -67,13 +63,6 @@ Layout changes where to simplify the include and dependency issues involved with having so many different platform directories. - It was decided to remove plat-s5pc1xx as some of the support was already - in plat-s5p or plat-samsung, with the S5PC110 support added with S5PV210 - the only user was the S5PC100. The S5PC100 specific items where moved to - arch/arm/mach-s5pc100. - - - Port Contributors ----------------- diff --git a/Documentation/arm/Samsung/clksrc-change-registers.awk b/Documentation/arm/Samsung/clksrc-change-registers.awk index 0c50220851f..d9174fabe37 100755 --- a/Documentation/arm/Samsung/clksrc-change-registers.awk +++ b/Documentation/arm/Samsung/clksrc-change-registers.awk @@ -68,7 +68,6 @@ BEGIN { while (getline line < ARGV[1] > 0) { if (line ~ /\#define.*_MASK/ && - !(line ~ /S5PC100_EPLL_MASK/) && !(line ~ /USB_SIG_MASK/)) { splitdefine(line, fields) name = fields[0] diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index 85af34d55ce..f3c05b5f9f0 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -168,6 +168,14 @@ Before jumping into the kernel, the following conditions must be met: the kernel image will be entered must be initialised by software at a higher exception level to prevent execution in an UNKNOWN state. + For systems with a GICv3 interrupt controller: + - If EL3 is present: + ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1. + ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1. + - If the kernel is entered at EL1: + ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1 + ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1. + The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must enter the kernel in the same exception level. diff --git a/Documentation/cgroups/memcg_test.txt b/Documentation/cgroups/memcg_test.txt index 80ac454704b..8870b021215 100644 --- a/Documentation/cgroups/memcg_test.txt +++ b/Documentation/cgroups/memcg_test.txt @@ -24,64 +24,27 @@ Please note that implementation details can be changed. a page/swp_entry may be charged (usage += PAGE_SIZE) at - mem_cgroup_charge_anon() - Called at new page fault and Copy-On-Write. - - mem_cgroup_try_charge_swapin() - Called at do_swap_page() (page fault on swap entry) and swapoff. - Followed by charge-commit-cancel protocol. (With swap accounting) - At commit, a charge recorded in swap_cgroup is removed. - - mem_cgroup_charge_file() - Called at add_to_page_cache() - - mem_cgroup_cache_charge_swapin() - Called at shmem's swapin. - - mem_cgroup_prepare_migration() - Called before migration. "extra" charge is done and followed by - charge-commit-cancel protocol. - At commit, charge against oldpage or newpage will be committed. + mem_cgroup_try_charge() 2. Uncharge a page/swp_entry may be uncharged (usage -= PAGE_SIZE) by - mem_cgroup_uncharge_page() - Called when an anonymous page is fully unmapped. I.e., mapcount goes - to 0. If the page is SwapCache, uncharge is delayed until - mem_cgroup_uncharge_swapcache(). - - mem_cgroup_uncharge_cache_page() - Called when a page-cache is deleted from radix-tree. If the page is - SwapCache, uncharge is delayed until mem_cgroup_uncharge_swapcache(). - - mem_cgroup_uncharge_swapcache() - Called when SwapCache is removed from radix-tree. The charge itself - is moved to swap_cgroup. (If mem+swap controller is disabled, no - charge to swap occurs.) + mem_cgroup_uncharge() + Called when a page's refcount goes down to 0. mem_cgroup_uncharge_swap() Called when swp_entry's refcnt goes down to 0. A charge against swap disappears. - mem_cgroup_end_migration(old, new) - At success of migration old is uncharged (if necessary), a charge - to new page is committed. At failure, charge to old page is committed. - 3. charge-commit-cancel - In some case, we can't know this "charge" is valid or not at charging - (because of races). - To handle such case, there are charge-commit-cancel functions. - mem_cgroup_try_charge_XXX - mem_cgroup_commit_charge_XXX - mem_cgroup_cancel_charge_XXX - these are used in swap-in and migration. + Memcg pages are charged in two steps: + mem_cgroup_try_charge() + mem_cgroup_commit_charge() or mem_cgroup_cancel_charge() At try_charge(), there are no flags to say "this page is charged". at this point, usage += PAGE_SIZE. - At commit(), the function checks the page should be charged or not - and set flags or avoid charging.(usage -= PAGE_SIZE) + At commit(), the page is associated with the memcg. At cancel(), simply usage -= PAGE_SIZE. @@ -91,18 +54,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. Anonymous page is newly allocated at - page fault into MAP_ANONYMOUS mapping. - Copy-On-Write. - It is charged right after it's allocated before doing any page table - related operations. Of course, it's uncharged when another page is used - for the fault address. - - At freeing anonymous page (by exit() or munmap()), zap_pte() is called - and pages for ptes are freed one by one.(see mm/memory.c). Uncharges - are done at page_remove_rmap() when page_mapcount() goes down to 0. - - Another page freeing is by page-reclaim (vmscan.c) and anonymous - pages are swapped out. In this case, the page is marked as - PageSwapCache(). uncharge() routine doesn't uncharge the page marked - as SwapCache(). It's delayed until __delete_from_swap_cache(). 4.1 Swap-in. At swap-in, the page is taken from swap-cache. There are 2 cases. @@ -111,41 +62,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. (b) If the SwapCache has been mapped by processes, it has been charged already. - This swap-in is one of the most complicated work. In do_swap_page(), - following events occur when pte is unchanged. - - (1) the page (SwapCache) is looked up. - (2) lock_page() - (3) try_charge_swapin() - (4) reuse_swap_page() (may call delete_swap_cache()) - (5) commit_charge_swapin() - (6) swap_free(). - - Considering following situation for example. - - (A) The page has not been charged before (2) and reuse_swap_page() - doesn't call delete_from_swap_cache(). - (B) The page has not been charged before (2) and reuse_swap_page() - calls delete_from_swap_cache(). - (C) The page has been charged before (2) and reuse_swap_page() doesn't - call delete_from_swap_cache(). - (D) The page has been charged before (2) and reuse_swap_page() calls - delete_from_swap_cache(). - - memory.usage/memsw.usage changes to this page/swp_entry will be - Case (A) (B) (C) (D) - Event - Before (2) 0/ 1 0/ 1 1/ 1 1/ 1 - =========================================== - (3) +1/+1 +1/+1 +1/+1 +1/+1 - (4) - 0/ 0 - -1/ 0 - (5) 0/-1 0/ 0 -1/-1 0/ 0 - (6) - 0/-1 - 0/-1 - =========================================== - Result 1/ 1 1/ 1 1/ 1 1/ 1 - - In any cases, charges to this page should be 1/ 1. - 4.2 Swap-out. At swap-out, typical state transition is below. @@ -158,28 +74,20 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. swp_entry's refcnt -= 1. - At (b), the page is marked as SwapCache and not uncharged. - At (d), the page is removed from SwapCache and a charge in page_cgroup - is moved to swap_cgroup. - Finally, at task exit, (e) zap_pte() is called and swp_entry's refcnt -=1 -> 0. - Here, a charge in swap_cgroup disappears. 5. Page Cache Page Cache is charged at - add_to_page_cache_locked(). - uncharged at - - __remove_from_page_cache(). - The logic is very clear. (About migration, see below) Note: __remove_from_page_cache() is called by remove_from_page_cache() and __remove_mapping(). 6. Shmem(tmpfs) Page Cache - Memcg's charge/uncharge have special handlers of shmem. The best way - to understand shmem's page state transition is to read mm/shmem.c. + The best way to understand shmem's page state transition is to read + mm/shmem.c. But brief explanation of the behavior of memcg around shmem will be helpful to understand the logic. @@ -192,56 +100,10 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. It's charged when... - A new page is added to shmem's radix-tree. - A swp page is read. (move a charge from swap_cgroup to page_cgroup) - It's uncharged when - - A page is removed from radix-tree and not SwapCache. - - When SwapCache is removed, a charge is moved to swap_cgroup. - - When swp_entry's refcnt goes down to 0, a charge in swap_cgroup - disappears. 7. Page Migration - One of the most complicated functions is page-migration-handler. - Memcg has 2 routines. Assume that we are migrating a page's contents - from OLDPAGE to NEWPAGE. - - Usual migration logic is.. - (a) remove the page from LRU. - (b) allocate NEWPAGE (migration target) - (c) lock by lock_page(). - (d) unmap all mappings. - (e-1) If necessary, replace entry in radix-tree. - (e-2) move contents of a page. - (f) map all mappings again. - (g) pushback the page to LRU. - (-) OLDPAGE will be freed. - - Before (g), memcg should complete all necessary charge/uncharge to - NEWPAGE/OLDPAGE. - - The point is.... - - If OLDPAGE is anonymous, all charges will be dropped at (d) because - try_to_unmap() drops all mapcount and the page will not be - SwapCache. - - - If OLDPAGE is SwapCache, charges will be kept at (g) because - __delete_from_swap_cache() isn't called at (e-1) - - - If OLDPAGE is page-cache, charges will be kept at (g) because - remove_from_swap_cache() isn't called at (e-1) - - memcg provides following hooks. - - - mem_cgroup_prepare_migration(OLDPAGE) - Called after (b) to account a charge (usage += PAGE_SIZE) against - memcg which OLDPAGE belongs to. - - - mem_cgroup_end_migration(OLDPAGE, NEWPAGE) - Called after (f) before (g). - If OLDPAGE is used, commit OLDPAGE again. If OLDPAGE is already - charged, a charge by prepare_migration() is automatically canceled. - If NEWPAGE is used, commit NEWPAGE and uncharge OLDPAGE. - - But zap_pte() (by exit or munmap) can be called while migration, - we have to check if OLDPAGE/NEWPAGE is a valid page after commit(). + + mem_cgroup_migrate() 8. LRU Each memcg has its own private LRU. Now, its handling is under global diff --git a/Documentation/devicetree/bindings/arm/adapteva.txt b/Documentation/devicetree/bindings/arm/adapteva.txt new file mode 100644 index 00000000000..1d8af9e3606 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/adapteva.txt @@ -0,0 +1,7 @@ +Adapteva Platforms Device Tree Bindings +--------------------------------------- + +Parallella board + +Required root node properties: + - compatible = "adapteva,parallella"; diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards index 3509707f932..c554ed3d44f 100644 --- a/Documentation/devicetree/bindings/arm/arm-boards +++ b/Documentation/devicetree/bindings/arm/arm-boards @@ -86,3 +86,9 @@ Interrupt controllers: compatible = "arm,versatile-sic"; interrupt-controller; #interrupt-cells = <1>; + +Required nodes: + +- core-module: the root node to the Versatile platforms must have + a core-module with regs and the compatible strings + "arm,core-module-versatile", "syscon" diff --git a/Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt b/Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt new file mode 100644 index 00000000000..8781073029e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt @@ -0,0 +1,14 @@ +Marvell Armada 38x CA9 MPcore SoC Controller +============================================ + +Required properties: + +- compatible: Should be "marvell,armada-380-mpcore-soc-ctrl". + +- reg: should be the register base and length as documented in the + datasheet for the CA9 MPcore SoC Control registers + +mpcore-soc-ctrl@20d20 { + compatible = "marvell,armada-380-mpcore-soc-ctrl"; + reg = <0x20d20 0x6c>; +}; diff --git a/Documentation/devicetree/bindings/arm/atmel-pmc.txt b/Documentation/devicetree/bindings/arm/atmel-pmc.txt index 389bed5056e..795cc78543f 100644 --- a/Documentation/devicetree/bindings/arm/atmel-pmc.txt +++ b/Documentation/devicetree/bindings/arm/atmel-pmc.txt @@ -1,7 +1,10 @@ * Power Management Controller (PMC) Required properties: -- compatible: Should be "atmel,at91rm9200-pmc" +- compatible: Should be "atmel,<chip>-pmc". + <chip> can be: at91rm9200, at91sam9260, at91sam9g45, at91sam9n12, + at91sam9x5, sama5d3 + - reg: Should contain PMC registers location and length Examples: diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method new file mode 100644 index 00000000000..8240c023e20 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method @@ -0,0 +1,36 @@ +Broadcom Kona Family CPU Enable Method +-------------------------------------- +This binding defines the enable method used for starting secondary +CPUs in the following Broadcom SoCs: + BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664 + +The enable method is specified by defining the following required +properties in the "cpus" device tree node: + - enable-method = "brcm,bcm11351-cpu-method"; + - secondary-boot-reg = <...>; + +The secondary-boot-reg property is a u32 value that specifies the +physical address of the register used to request the ROM holding pen +code release a secondary CPU. The value written to the register is +formed by encoding the target CPU id into the low bits of the +physical start address it should jump to. + +Example: + cpus { + #address-cells = <1>; + #size-cells = <0>; + enable-method = "brcm,bcm11351-cpu-method"; + secondary-boot-reg = <0x3500417c>; + + cpu0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a9"; + reg = <0>; + }; + + cpu1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a9"; + reg = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt new file mode 100644 index 00000000000..3c436cc4f35 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt @@ -0,0 +1,95 @@ +ARM Broadcom STB platforms Device Tree Bindings +----------------------------------------------- +Boards with Broadcom Brahma15 ARM-based BCMxxxx (generally BCM7xxx variants) +SoC shall have the following DT organization: + +Required root node properties: + - compatible: "brcm,bcm<chip_id>", "brcm,brcmstb" + +example: +/ { + #address-cells = <2>; + #size-cells = <2>; + model = "Broadcom STB (bcm7445)"; + compatible = "brcm,bcm7445", "brcm,brcmstb"; + +Further, syscon nodes that map platform-specific registers used for general +system control is required: + + - compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon" + - compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon" + - compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon" + +example: + rdb { + #address-cells = <1>; + #size-cells = <1>; + compatible = "simple-bus"; + ranges = <0 0x00 0xf0000000 0x1000000>; + + sun_top_ctrl: syscon@404000 { + compatible = "brcm,bcm7445-sun-top-ctrl", "syscon"; + reg = <0x404000 0x51c>; + }; + + hif_cpubiuctrl: syscon@3e2400 { + compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon"; + reg = <0x3e2400 0x5b4>; + }; + + hif_continuation: syscon@452000 { + compatible = "brcm,bcm7445-hif-continuation", "syscon"; + reg = <0x452000 0x100>; + }; + }; + +Lastly, nodes that allow for support of SMP initialization and reboot are +required: + +smpboot +------- +Required properties: + + - compatible + The string "brcm,brcmstb-smpboot". + + - syscon-cpu + A phandle / integer array property which lets the BSP know the location + of certain CPU power-on registers. + + The layout of the property is as follows: + o a phandle to the "hif_cpubiuctrl" syscon node + o offset to the base CPU power zone register + o offset to the base CPU reset register + + - syscon-cont + A phandle pointing to the syscon node which describes the CPU boot + continuation registers. + o a phandle to the "hif_continuation" syscon node + +example: + smpboot { + compatible = "brcm,brcmstb-smpboot"; + syscon-cpu = <&hif_cpubiuctrl 0x88 0x178>; + syscon-cont = <&hif_continuation>; + }; + +reboot +------- +Required properties + + - compatible + The string property "brcm,brcmstb-reboot". + + - syscon + A phandle / integer array that points to the syscon node which describes + the general system reset registers. + o a phandle to "sun_top_ctrl" + o offset to the "reset source enable" register + o offset to the "software master reset" register + +example: + reboot { + compatible = "brcm,brcmstb-reboot"; + syscon = <&sun_top_ctrl 0x304 0x308>; + }; diff --git a/Documentation/devicetree/bindings/arm/ccn.txt b/Documentation/devicetree/bindings/arm/ccn.txt new file mode 100644 index 00000000000..b100d3847d8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/ccn.txt @@ -0,0 +1,21 @@ +* ARM CCN (Cache Coherent Network) + +Required properties: + +- compatible: (standard compatible string) should be one of: + "arm,ccn-504" + "arm,ccn-508" + +- reg: (standard registers property) physical address and size + (16MB) of the configuration registers block + +- interrupts: (standard interrupt property) single interrupt + generated by the control block + +Example: + + ccn@0x2000000000 { + compatible = "arm,ccn-504"; + reg = <0x20 0x00000000 0 0x1000000>; + interrupts = <0 181 4>; + }; diff --git a/Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,berlin-smp b/Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,berlin-smp new file mode 100644 index 00000000000..cd236b727e2 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,berlin-smp @@ -0,0 +1,41 @@ +======================================================== +Secondary CPU enable-method "marvell,berlin-smp" binding +======================================================== + +This document describes the "marvell,berlin-smp" method for enabling secondary +CPUs. To apply to all CPUs, a single "marvell,berlin-smp" enable method should +be defined in the "cpus" node. + +Enable method name: "marvell,berlin-smp" +Compatible machines: "marvell,berlin2" and "marvell,berlin2q" +Compatible CPUs: "marvell,pj4b" and "arm,cortex-a9" +Related properties: (none) + +Note: +This enable method needs valid nodes compatible with "arm,cortex-a9-scu" and +"marvell,berlin-cpu-ctrl"[1]. + +Example: + + cpus { + #address-cells = <1>; + #size-cells = <0>; + enable-method = "marvell,berlin-smp"; + + cpu@0 { + compatible = "marvell,pj4b"; + device_type = "cpu"; + next-level-cache = <&l2>; + reg = <0>; + }; + + cpu@1 { + compatible = "marvell,pj4b"; + device_type = "cpu"; + next-level-cache = <&l2>; + reg = <1>; + }; + }; + +-- +[1] arm/marvell,berlin.txt diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 1fe72a0778c..298e2f6b33c 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -152,7 +152,9 @@ nodes to be present and contain the properties described below. "arm,cortex-a7" "arm,cortex-a8" "arm,cortex-a9" + "arm,cortex-a12" "arm,cortex-a15" + "arm,cortex-a17" "arm,cortex-a53" "arm,cortex-a57" "arm,cortex-m0" @@ -163,6 +165,7 @@ nodes to be present and contain the properties described below. "arm,cortex-r4" "arm,cortex-r5" "arm,cortex-r7" + "brcm,brahma-b15" "faraday,fa526" "intel,sa110" "intel,sa1100" @@ -184,6 +187,7 @@ nodes to be present and contain the properties described below. can be one of: "allwinner,sun6i-a31" "arm,psci" + "brcm,brahma-b15" "marvell,armada-375-smp" "marvell,armada-380-smp" "marvell,armada-xp-smp" diff --git a/Documentation/devicetree/bindings/arm/gic-v3.txt b/Documentation/devicetree/bindings/arm/gic-v3.txt new file mode 100644 index 00000000000..33cd05e6c12 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/gic-v3.txt @@ -0,0 +1,79 @@ +* ARM Generic Interrupt Controller, version 3 + +AArch64 SMP cores are often associated with a GICv3, providing Private +Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI), +Software Generated Interrupts (SGI), and Locality-specific Peripheral +Interrupts (LPI). + +Main node required properties: + +- compatible : should at least contain "arm,gic-v3". +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. Must be a single cell with a value of at least 3. + + The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI + interrupts. Other values are reserved for future use. + + The 2nd cell contains the interrupt number for the interrupt type. + SPI interrupts are in the range [0-987]. PPI interrupts are in the + range [0-15]. + + The 3rd cell is the flags, encoded as follows: + bits[3:0] trigger type and level flags. + 1 = edge triggered + 4 = level triggered + + Cells 4 and beyond are reserved for future use. When the 1st cell + has a value of 0 or 1, cells 4 and beyond act as padding, and may be + ignored. It is recommended that padding cells have a value of 0. + +- reg : Specifies base physical address(s) and size of the GIC + registers, in the following order: + - GIC Distributor interface (GICD) + - GIC Redistributors (GICR), one range per redistributor region + - GIC CPU interface (GICC) + - GIC Hypervisor interface (GICH) + - GIC Virtual CPU interface (GICV) + + GICC, GICH and GICV are optional. + +- interrupts : Interrupt source of the VGIC maintenance interrupt. + +Optional + +- redistributor-stride : If using padding pages, specifies the stride + of consecutive redistributors. Must be a multiple of 64kB. + +- #redistributor-regions: The number of independent contiguous regions + occupied by the redistributors. Required if more than one such + region is present. + +Examples: + + gic: interrupt-controller@2cf00000 { + compatible = "arm,gic-v3"; + #interrupt-cells = <3>; + interrupt-controller; + reg = <0x0 0x2f000000 0 0x10000>, // GICD + <0x0 0x2f100000 0 0x200000>, // GICR + <0x0 0x2c000000 0 0x2000>, // GICC + <0x0 0x2c010000 0 0x2000>, // GICH + <0x0 0x2c020000 0 0x2000>; // GICV + interrupts = <1 9 4>; + }; + + gic: interrupt-controller@2c010000 { + compatible = "arm,gic-v3"; + #interrupt-cells = <3>; + interrupt-controller; + redistributor-stride = <0x0 0x40000>; // 256kB stride + #redistributor-regions = <2>; + reg = <0x0 0x2c010000 0 0x10000>, // GICD + <0x0 0x2d000000 0 0x800000>, // GICR 1: CPUs 0-31 + <0x0 0x2e000000 0 0x800000>; // GICR 2: CPUs 32-63 + <0x0 0x2c040000 0 0x2000>, // GICC + <0x0 0x2c060000 0 0x2000>, // GICH + <0x0 0x2c080000 0 0x2000>; // GICV + interrupts = <1 9 4>; + }; diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 5573c08d318..c7d2fa15667 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -16,6 +16,7 @@ Main node required properties: "arm,cortex-a9-gic" "arm,cortex-a7-gic" "arm,arm11mp-gic" + "brcm,brahma-b15-gic" - interrupt-controller : Identifies the node as an interrupt controller - #interrupt-cells : Specifies the number of cells needed to encode an interrupt source. The type shall be a <u32> and the value shall be 3. diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt index df0a452b852..934f00025cc 100644 --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt @@ -31,6 +31,17 @@ Example: reboot-offset = <0x4>; }; +----------------------------------------------------------------------- +Hisilicon CPU controller + +Required properties: +- compatible : "hisilicon,cpuctrl" +- reg : Register address and size + +The clock registers and power registers of secondary cores are defined +in CPU controller, especially in HIX5HD2 SoC. + +----------------------------------------------------------------------- PCTRL: Peripheral misc control register Required Properties: diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell,berlin.txt index 94013a9a876..904de5781f4 100644 --- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt +++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt @@ -24,6 +24,22 @@ SoC and board used. Currently known SoC compatibles are: ... } +* Marvell Berlin CPU control bindings + +CPU control register allows various operations on CPUs, like resetting them +independently. + +Required properties: +- compatible: should be "marvell,berlin-cpu-ctrl" +- reg: address and length of the register set + +Example: + +cpu-ctrl@f7dd0000 { + compatible = "marvell,berlin-cpu-ctrl"; + reg = <0xf7dd0000 0x10000>; +}; + * Marvell Berlin2 chip control binding Marvell Berlin SoCs have a chip control register set providing several diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt new file mode 100644 index 00000000000..d6ac71f3731 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek.txt @@ -0,0 +1,8 @@ +Mediatek MT6589 Platforms Device Tree Bindings + +Boards with a SoC of the Mediatek MT6589 shall have the following property: + +Required root node property: + +compatible: must contain "mediatek,mt6589" + diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index d22b216f5d2..0edc90305df 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -129,6 +129,9 @@ Boards: - AM437x GP EVM compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43" +- AM437x SK EVM: AM437x StarterKit Evaluation Module + compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43" + - DRA742 EVM: Software Development Board for DRA742 compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7" diff --git a/Documentation/devicetree/bindings/arm/omap/prcm.txt b/Documentation/devicetree/bindings/arm/omap/prcm.txt new file mode 100644 index 00000000000..79074dac684 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/prcm.txt @@ -0,0 +1,65 @@ +OMAP PRCM bindings + +Power Reset and Clock Manager lists the device clocks and clockdomains under +a DT hierarchy. Each TI SoC can have multiple PRCM entities listed for it, +each describing one module and the clock hierarchy under it. see [1] for +documentation about the individual clock/clockdomain nodes. + +[1] Documentation/devicetree/bindings/clock/ti/* + +Required properties: +- compatible: Must be one of: + "ti,am3-prcm" + "ti,am3-scrm" + "ti,am4-prcm" + "ti,am4-scrm" + "ti,omap2-prcm" + "ti,omap2-scrm" + "ti,omap3-prm" + "ti,omap3-cm" + "ti,omap3-scrm" + "ti,omap4-cm1" + "ti,omap4-prm" + "ti,omap4-cm2" + "ti,omap4-scrm" + "ti,omap5-prm" + "ti,omap5-cm-core-aon" + "ti,omap5-scrm" + "ti,omap5-cm-core" + "ti,dra7-prm" + "ti,dra7-cm-core-aon" + "ti,dra7-cm-core" +- reg: Contains PRCM module register address range + (base address and length) +- clocks: clocks for this module +- clockdomains: clockdomains for this module + +Example: + +cm: cm@48004000 { + compatible = "ti,omap3-cm"; + reg = <0x48004000 0x4000>; + + cm_clocks: clocks { + #address-cells = <1>; + #size-cells = <0>; + }; + + cm_clockdomains: clockdomains { + }; +} + +&cm_clocks { + omap2_32k_fck: omap_32k_fck { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <32768>; + }; +}; + +&cm_clockdomains { + core_l3_clkdm: core_l3_clkdm { + compatible = "ti,clockdomain"; + clocks = <&sdrc_ick>; + }; +}; diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt index f9865e77e0b..1e1979b229f 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt @@ -7,6 +7,8 @@ Properties: - "samsung,exynos4212-pmu" - for Exynos4212 SoC, - "samsung,exynos4412-pmu" - for Exynos4412 SoC, - "samsung,exynos5250-pmu" - for Exynos5250 SoC, + - "samsung,exynos5260-pmu" - for Exynos5260 SoC. + - "samsung,exynos5410-pmu" - for Exynos5410 SoC, - "samsung,exynos5420-pmu" - for Exynos5420 SoC. second value must be always "syscon". diff --git a/Documentation/devicetree/bindings/arm/spear-misc.txt b/Documentation/devicetree/bindings/arm/spear-misc.txt new file mode 100644 index 00000000000..cf649827ffc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/spear-misc.txt @@ -0,0 +1,9 @@ +SPEAr Misc configuration +=========================== +SPEAr SOCs have some miscellaneous registers which are used to configure +few properties of different peripheral controllers. + +misc node required properties: + +- compatible Should be "st,spear1340-misc", "syscon". +- reg: Address range of misc space upto 8K diff --git a/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt index 558ed4b4ef3..73278c6d2dc 100644 --- a/Documentation/devicetree/bindings/arm/tegra.txt +++ b/Documentation/devicetree/bindings/arm/tegra.txt @@ -30,6 +30,8 @@ board-specific compatible values: nvidia,seaboard nvidia,ventana nvidia,whistler + toradex,apalis_t30 + toradex,apalis_t30-eval toradex,colibri_t20-512 toradex,iris diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt index 6f1ed830b4f..1f799535788 100644 --- a/Documentation/devicetree/bindings/arm/xilinx.txt +++ b/Documentation/devicetree/bindings/arm/xilinx.txt @@ -1,7 +1,7 @@ -Xilinx Zynq EP107 Emulation Platform board +Xilinx Zynq Platforms Device Tree Bindings -This board is an emulation platform for the Zynq product which is -based on an ARM Cortex A9 processor. +Boards with Zynq-7000 SOC based on an ARM Cortex A9 processor +shall have the following properties. Required root node properties: - - compatible = "xlnx,zynq-ep107"; + - compatible = "xlnx,zynq-7000"; diff --git a/Documentation/devicetree/bindings/clock/arm-integrator.txt b/Documentation/devicetree/bindings/clock/arm-integrator.txt index 652914b17b9..ecc69520bce 100644 --- a/Documentation/devicetree/bindings/clock/arm-integrator.txt +++ b/Documentation/devicetree/bindings/clock/arm-integrator.txt @@ -1,4 +1,4 @@ -Clock bindings for ARM Integrator Core Module clocks +Clock bindings for ARM Integrator and Versatile Core Module clocks Auxilary Oscillator Clock @@ -12,7 +12,7 @@ parent node. Required properties: -- compatible: must be "arm,integrator-cm-auxosc" +- compatible: must be "arm,integrator-cm-auxosc" or "arm,versatile-cm-auxosc" - #clock-cells: must be <0> Optional properties: diff --git a/Documentation/devicetree/bindings/clock/clk-s5pv210-audss.txt b/Documentation/devicetree/bindings/clock/clk-s5pv210-audss.txt new file mode 100644 index 00000000000..4fc869b69d4 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/clk-s5pv210-audss.txt @@ -0,0 +1,53 @@ +* Samsung Audio Subsystem Clock Controller + +The Samsung Audio Subsystem clock controller generates and supplies clocks +to Audio Subsystem block available in the S5PV210 and compatible SoCs. + +Required Properties: + +- compatible: should be "samsung,s5pv210-audss-clock". +- reg: physical base address and length of the controller's register set. + +- #clock-cells: should be 1. + +- clocks: + - hclk: AHB bus clock of the Audio Subsystem. + - xxti: Optional fixed rate PLL reference clock, parent of mout_audss. If + not specified (i.e. xusbxti is used for PLL reference), it is fixed to + a clock named "xxti". + - fout_epll: Input PLL to the AudioSS block, parent of mout_audss. + - iiscdclk0: Optional external i2s clock, parent of mout_i2s. If not + specified, it is fixed to a clock named "iiscdclk0". + - sclk_audio0: Audio bus clock, parent of mout_i2s. + +- clock-names: Aliases for the above clocks. They should be "hclk", + "xxti", "fout_epll", "iiscdclk0", and "sclk_audio0" respectively. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/s5pv210-audss-clk.h header and can be used in device +tree sources. + +Example: Clock controller node. + + clk_audss: clock-controller@c0900000 { + compatible = "samsung,s5pv210-audss-clock"; + reg = <0xc0900000 0x1000>; + #clock-cells = <1>; + clock-names = "hclk", "xxti", + "fout_epll", "sclk_audio0"; + clocks = <&clocks DOUT_HCLKP>, <&xxti>, + <&clocks FOUT_EPLL>, <&clocks SCLK_AUDIO0>; + }; + +Example: I2S controller node that consumes the clock generated by the clock + controller. Refer to the standard clock bindings for information + about 'clocks' and 'clock-names' property. + + i2s0: i2s@03830000 { + /* ... */ + clock-names = "iis", "i2s_opclk0", + "i2s_opclk1"; + clocks = <&clk_audss CLK_I2S>, <&clk_audss CLK_I2S>, + <&clk_audss CLK_DOUT_AUD_BUS>; + /* ... */ + }; diff --git a/Documentation/devicetree/bindings/clock/imx1-clock.txt b/Documentation/devicetree/bindings/clock/imx1-clock.txt new file mode 100644 index 00000000000..b7adf4e3ea9 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx1-clock.txt @@ -0,0 +1,26 @@ +* Clock bindings for Freescale i.MX1 CPUs + +Required properties: +- compatible: Should be "fsl,imx1-ccm". +- reg: Address and length of the register set. +- #clock-cells: Should be <1>. + +The clock consumer should specify the desired clock by having the clock +ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx1-clock.h +for the full list of i.MX1 clock IDs. + +Examples: + clks: ccm@0021b000 { + #clock-cells = <1>; + compatible = "fsl,imx1-ccm"; + reg = <0x0021b000 0x1000>; + }; + + pwm: pwm@00208000 { + #pwm-cells = <2>; + compatible = "fsl,imx1-pwm"; + reg = <0x00208000 0x1000>; + interrupts = <34>; + clocks = <&clks IMX1_CLK_DUMMY>, <&clks IMX1_CLK_PER1>; + clock-names = "ipg", "per"; + }; diff --git a/Documentation/devicetree/bindings/clock/imx21-clock.txt b/Documentation/devicetree/bindings/clock/imx21-clock.txt new file mode 100644 index 00000000000..c3b0db437c4 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx21-clock.txt @@ -0,0 +1,28 @@ +* Clock bindings for Freescale i.MX21 + +Required properties: +- compatible : Should be "fsl,imx21-ccm". +- reg : Address and length of the register set. +- interrupts : Should contain CCM interrupt. +- #clock-cells: Should be <1>. + +The clock consumer should specify the desired clock by having the clock +ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx21-clock.h +for the full list of i.MX21 clock IDs. + +Examples: + clks: ccm@10027000{ + compatible = "fsl,imx21-ccm"; + reg = <0x10027000 0x800>; + #clock-cells = <1>; + }; + + uart1: serial@1000a000 { + compatible = "fsl,imx21-uart"; + reg = <0x1000a000 0x1000>; + interrupts = <20>; + clocks = <&clks IMX21_CLK_UART1_IPG_GATE>, + <&clks IMX21_CLK_PER1>; + clock-names = "ipg", "per"; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.txt b/Documentation/devicetree/bindings/clock/imx27-clock.txt index 6bc9fd2c663..cc05de9ec39 100644 --- a/Documentation/devicetree/bindings/clock/imx27-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx27-clock.txt @@ -7,117 +7,22 @@ Required properties: - #clock-cells: Should be <1> The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. The following is a full list of i.MX27 -clocks and IDs. - - Clock ID - ----------------------- - dummy 0 - ckih 1 - ckil 2 - mpll 3 - spll 4 - mpll_main2 5 - ahb 6 - ipg 7 - nfc_div 8 - per1_div 9 - per2_div 10 - per3_div 11 - per4_div 12 - vpu_sel 13 - vpu_div 14 - usb_div 15 - cpu_sel 16 - clko_sel 17 - cpu_div 18 - clko_div 19 - ssi1_sel 20 - ssi2_sel 21 - ssi1_div 22 - ssi2_div 23 - clko_en 24 - ssi2_ipg_gate 25 - ssi1_ipg_gate 26 - slcdc_ipg_gate 27 - sdhc3_ipg_gate 28 - sdhc2_ipg_gate 29 - sdhc1_ipg_gate 30 - scc_ipg_gate 31 - sahara_ipg_gate 32 - rtc_ipg_gate 33 - pwm_ipg_gate 34 - owire_ipg_gate 35 - lcdc_ipg_gate 36 - kpp_ipg_gate 37 - iim_ipg_gate 38 - i2c2_ipg_gate 39 - i2c1_ipg_gate 40 - gpt6_ipg_gate 41 - gpt5_ipg_gate 42 - gpt4_ipg_gate 43 - gpt3_ipg_gate 44 - gpt2_ipg_gate 45 - gpt1_ipg_gate 46 - gpio_ipg_gate 47 - fec_ipg_gate 48 - emma_ipg_gate 49 - dma_ipg_gate 50 - cspi3_ipg_gate 51 - cspi2_ipg_gate 52 - cspi1_ipg_gate 53 - nfc_baud_gate 54 - ssi2_baud_gate 55 - ssi1_baud_gate 56 - vpu_baud_gate 57 - per4_gate 58 - per3_gate 59 - per2_gate 60 - per1_gate 61 - usb_ahb_gate 62 - slcdc_ahb_gate 63 - sahara_ahb_gate 64 - lcdc_ahb_gate 65 - vpu_ahb_gate 66 - fec_ahb_gate 67 - emma_ahb_gate 68 - emi_ahb_gate 69 - dma_ahb_gate 70 - csi_ahb_gate 71 - brom_ahb_gate 72 - ata_ahb_gate 73 - wdog_ipg_gate 74 - usb_ipg_gate 75 - uart6_ipg_gate 76 - uart5_ipg_gate 77 - uart4_ipg_gate 78 - uart3_ipg_gate 79 - uart2_ipg_gate 80 - uart1_ipg_gate 81 - ckih_div1p5 82 - fpm 83 - mpll_osc_sel 84 - mpll_sel 85 - spll_gate 86 - mshc_div 87 - rtic_ipg_gate 88 - mshc_ipg_gate 89 - rtic_ahb_gate 90 - mshc_baud_gate 91 +ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx27-clock.h +for the full list of i.MX27 clock IDs. Examples: + clks: ccm@10027000{ + compatible = "fsl,imx27-ccm"; + reg = <0x10027000 0x1000>; + #clock-cells = <1>; + }; -clks: ccm@10027000{ - compatible = "fsl,imx27-ccm"; - reg = <0x10027000 0x1000>; - #clock-cells = <1>; -}; - -uart1: serial@1000a000 { - compatible = "fsl,imx27-uart", "fsl,imx21-uart"; - reg = <0x1000a000 0x1000>; - interrupts = <20>; - clocks = <&clks 81>, <&clks 61>; - clock-names = "ipg", "per"; - status = "disabled"; -}; + uart1: serial@1000a000 { + compatible = "fsl,imx27-uart", "fsl,imx21-uart"; + reg = <0x1000a000 0x1000>; + interrupts = <20>; + clocks = <&clks IMX27_CLK_UART1_IPG_GATE>, + <&clks IMX27_CLK_PER1_GATE>; + clock-names = "ipg", "per"; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index 90ec91fe5ce..9252912a5b0 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt @@ -7,223 +7,13 @@ Required properties: - #clock-cells: Should be <1> The clock consumer should specify the desired clock by having the clock -ID in its "clocks" phandle cell. The following is a full list of i.MX6Q -clocks and IDs. - - Clock ID - --------------------------- - dummy 0 - ckil 1 - ckih 2 - osc 3 - pll2_pfd0_352m 4 - pll2_pfd1_594m 5 - pll2_pfd2_396m 6 - pll3_pfd0_720m 7 - pll3_pfd1_540m 8 - pll3_pfd2_508m 9 - pll3_pfd3_454m 10 - pll2_198m 11 - pll3_120m 12 - pll3_80m 13 - pll3_60m 14 - twd 15 - step 16 - pll1_sw 17 - periph_pre 18 - periph2_pre 19 - periph_clk2_sel 20 - periph2_clk2_sel 21 - axi_sel 22 - esai_sel 23 - asrc_sel 24 - spdif_sel 25 - gpu2d_axi 26 - gpu3d_axi 27 - gpu2d_core_sel 28 - gpu3d_core_sel 29 - gpu3d_shader_sel 30 - ipu1_sel 31 - ipu2_sel 32 - ldb_di0_sel 33 - ldb_di1_sel 34 - ipu1_di0_pre_sel 35 - ipu1_di1_pre_sel 36 - ipu2_di0_pre_sel 37 - ipu2_di1_pre_sel 38 - ipu1_di0_sel 39 - ipu1_di1_sel 40 - ipu2_di0_sel 41 - ipu2_di1_sel 42 - hsi_tx_sel 43 - pcie_axi_sel 44 - ssi1_sel 45 - ssi2_sel 46 - ssi3_sel 47 - usdhc1_sel 48 - usdhc2_sel 49 - usdhc3_sel 50 - usdhc4_sel 51 - enfc_sel 52 - emi_sel 53 - emi_slow_sel 54 - vdo_axi_sel 55 - vpu_axi_sel 56 - cko1_sel 57 - periph 58 - periph2 59 - periph_clk2 60 - periph2_clk2 61 - ipg 62 - ipg_per 63 - esai_pred 64 - esai_podf 65 - asrc_pred 66 - asrc_podf 67 - spdif_pred 68 - spdif_podf 69 - can_root 70 - ecspi_root 71 - gpu2d_core_podf 72 - gpu3d_core_podf 73 - gpu3d_shader 74 - ipu1_podf 75 - ipu2_podf 76 - ldb_di0_podf 77 - ldb_di1_podf 78 - ipu1_di0_pre 79 - ipu1_di1_pre 80 - ipu2_di0_pre 81 - ipu2_di1_pre 82 - hsi_tx_podf 83 - ssi1_pred 84 - ssi1_podf 85 - ssi2_pred 86 - ssi2_podf 87 - ssi3_pred 88 - ssi3_podf 89 - uart_serial_podf 90 - usdhc1_podf 91 - usdhc2_podf 92 - usdhc3_podf 93 - usdhc4_podf 94 - enfc_pred 95 - enfc_podf 96 - emi_podf 97 - emi_slow_podf 98 - vpu_axi_podf 99 - cko1_podf 100 - axi 101 - mmdc_ch0_axi_podf 102 - mmdc_ch1_axi_podf 103 - arm 104 - ahb 105 - apbh_dma 106 - asrc 107 - can1_ipg 108 - can1_serial 109 - can2_ipg 110 - can2_serial 111 - ecspi1 112 - ecspi2 113 - ecspi3 114 - ecspi4 115 - ecspi5 116 - enet 117 - esai 118 - gpt_ipg 119 - gpt_ipg_per 120 - gpu2d_core 121 - gpu3d_core 122 - hdmi_iahb 123 - hdmi_isfr 124 - i2c1 125 - i2c2 126 - i2c3 127 - iim 128 - enfc 129 - ipu1 130 - ipu1_di0 131 - ipu1_di1 132 - ipu2 133 - ipu2_di0 134 - ldb_di0 135 - ldb_di1 136 - ipu2_di1 137 - hsi_tx 138 - mlb 139 - mmdc_ch0_axi 140 - mmdc_ch1_axi 141 - ocram 142 - openvg_axi 143 - pcie_axi 144 - pwm1 145 - pwm2 146 - pwm3 147 - pwm4 148 - per1_bch 149 - gpmi_bch_apb 150 - gpmi_bch 151 - gpmi_io 152 - gpmi_apb 153 - sata 154 - sdma 155 - spba 156 - ssi1 157 - ssi2 158 - ssi3 159 - uart_ipg 160 - uart_serial 161 - usboh3 162 - usdhc1 163 - usdhc2 164 - usdhc3 165 - usdhc4 166 - vdo_axi 167 - vpu_axi 168 - cko1 169 - pll1_sys 170 - pll2_bus 171 - pll3_usb_otg 172 - pll4_audio 173 - pll5_video 174 - pll8_mlb 175 - pll7_usb_host 176 - pll6_enet 177 - ssi1_ipg 178 - ssi2_ipg 179 - ssi3_ipg 180 - rom 181 - usbphy1 182 - usbphy2 183 - ldb_di0_div_3_5 184 - ldb_di1_div_3_5 185 - sata_ref 186 - sata_ref_100m 187 - pcie_ref 188 - pcie_ref_125m 189 - enet_ref 190 - usbphy1_gate 191 - usbphy2_gate 192 - pll4_post_div 193 - pll5_post_div 194 - pll5_video_div 195 - eim_slow 196 - spdif 197 - cko2_sel 198 - cko2_podf 199 - cko2 200 - cko 201 - vdoa 202 - pll4_audio_div 203 - lvds1_sel 204 - lvds2_sel 205 - lvds1_gate 206 - lvds2_gate 207 - esai_ahb 208 +ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6qdl-clock.h +for the full list of i.MX6 Quad and DualLite clock IDs. Examples: +#include <dt-bindings/clock/imx6qdl-clock.h> + clks: ccm@020c4000 { compatible = "fsl,imx6q-ccm"; reg = <0x020c4000 0x4000>; @@ -235,7 +25,7 @@ uart1: serial@02020000 { compatible = "fsl,imx6q-uart", "fsl,imx21-uart"; reg = <0x02020000 0x4000>; interrupts = <0 26 0x04>; - clocks = <&clks 160>, <&clks 161>; + clocks = <&clks IMX6QDL_CLK_UART_IPG>, <&clks IMX6QDL_CLK_UART_SERIAL>; clock-names = "ipg", "per"; status = "disabled"; }; diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt index feb83013071..99c214660bd 100644 --- a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt +++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt @@ -3,14 +3,15 @@ Device Tree Clock bindings for cpu clock of Marvell EBU platforms Required properties: - compatible : shall be one of the following: "marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP -- reg : Address and length of the clock complex register set +- reg : Address and length of the clock complex register set, followed + by address and length of the PMU DFS registers - #clock-cells : should be set to 1. - clocks : shall be the input parent clock phandle for the clock. cpuclk: clock-complex@d0018700 { #clock-cells = <1>; compatible = "marvell,armada-xp-cpu-clock"; - reg = <0xd0018700 0xA0>; + reg = <0xd0018700 0xA0>, <0x1c054 0x10>; clocks = <&coreclk 1>; } diff --git a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt new file mode 100644 index 00000000000..effd9401c13 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt @@ -0,0 +1,78 @@ +* Samsung S5P6442/S5PC110/S5PV210 Clock Controller + +Samsung S5P6442, S5PC110 and S5PV210 SoCs contain integrated clock +controller, which generates and supplies clock to various controllers +within the SoC. + +Required Properties: + +- compatible: should be one of following: + - "samsung,s5pv210-clock" : for clock controller of Samsung + S5PC110/S5PV210 SoCs, + - "samsung,s5p6442-clock" : for clock controller of Samsung + S5P6442 SoC. + +- reg: physical base address of the controller and length of memory mapped + region. + +- #clock-cells: should be 1. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/s5pv210.h header and can be used in device tree sources. + +External clocks: + +There are several clocks that are generated outside the SoC. It is expected +that they are defined using standard clock bindings with following +clock-output-names: + - "xxti": external crystal oscillator connected to XXTI and XXTO pins of +the SoC, + - "xusbxti": external crystal oscillator connected to XUSBXTI and XUSBXTO +pins of the SoC, + +A subset of above clocks available on given board shall be specified in +board device tree, including the system base clock, as selected by XOM[0] +pin of the SoC. Refer to generic fixed rate clock bindings +documentation[1] for more information how to specify these clocks. + +[1] Documentation/devicetree/bindings/clock/fixed-clock.txt + +Example: Clock controller node: + + clock: clock-controller@7e00f000 { + compatible = "samsung,s5pv210-clock"; + reg = <0x7e00f000 0x1000>; + #clock-cells = <1>; + }; + +Example: Required external clocks: + + xxti: clock-xxti { + compatible = "fixed-clock"; + clock-output-names = "xxti"; + clock-frequency = <24000000>; + #clock-cells = <0>; + }; + + xusbxti: clock-xusbxti { + compatible = "fixed-clock"; + clock-output-names = "xusbxti"; + clock-frequency = <24000000>; + #clock-cells = <0>; + }; + +Example: UART controller node that consumes the clock generated by the clock + controller (refer to the standard clock bindings for information about + "clocks" and "clock-names" properties): + + uart0: serial@e2900000 { + compatible = "samsung,s5pv210-uart"; + reg = <0xe2900000 0x400>; + interrupt-parent = <&vic1>; + interrupts = <10>; + clock-names = "uart", "clk_uart_baud0", + "clk_uart_baud1"; + clocks = <&clocks UART0>, <&clocks UART0>, + <&clocks SCLK_UART0>; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt index e577196a12c..4659fd95230 100644 --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt @@ -47,6 +47,7 @@ The full ID of peripheral types can be found below. 20 ASRC 21 ESAI 22 SSI Dual FIFO (needs firmware ver >= 2) + 23 Shared ASRC The third cell specifies the transfer priority as below. diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt new file mode 100644 index 00000000000..a6511df165c --- /dev/null +++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt @@ -0,0 +1,29 @@ +* Freescale MPC512x and MPC8308 DMA Controller + +The DMA controller in Freescale MPC512x and MPC8308 SoCs can move +blocks of memory contents between memory and peripherals or +from memory to memory. + +Refer to "Generic DMA Controller and DMA request bindings" in +the dma/dma.txt file for a more detailed description of binding. + +Required properties: +- compatible: should be "fsl,mpc5121-dma" or "fsl,mpc8308-dma"; +- reg: should contain the DMA controller registers location and length; +- interrupt for the DMA controller: syntax of interrupt client node + is described in interrupt-controller/interrupts.txt file. +- #dma-cells: the length of the DMA specifier, must be <1>. + Each channel of this DMA controller has a peripheral request line, + the assignment is fixed in hardware. This one cell + in dmas property of a client device represents the channel number. + +Example: + + dma0: dma@14000 { + compatible = "fsl,mpc5121-dma"; + reg = <0x14000 0x1800>; + interrupts = <65 0x8>; + #dma-cells = <1>; + }; + +DMA clients must use the format described in dma/dma.txt file. diff --git a/Documentation/devicetree/bindings/dma/nbpfaxi.txt b/Documentation/devicetree/bindings/dma/nbpfaxi.txt new file mode 100644 index 00000000000..d5e2522b9ec --- /dev/null +++ b/Documentation/devicetree/bindings/dma/nbpfaxi.txt @@ -0,0 +1,61 @@ +* Renesas "Type-AXI" NBPFAXI* DMA controllers + +* DMA controller + +Required properties + +- compatible: must be one of + "renesas,nbpfaxi64dmac1b4" + "renesas,nbpfaxi64dmac1b8" + "renesas,nbpfaxi64dmac1b16" + "renesas,nbpfaxi64dmac4b4" + "renesas,nbpfaxi64dmac4b8" + "renesas,nbpfaxi64dmac4b16" + "renesas,nbpfaxi64dmac8b4" + "renesas,nbpfaxi64dmac8b8" + "renesas,nbpfaxi64dmac8b16" +- #dma-cells: must be 2: the first integer is a terminal number, to which this + slave is connected, the second one is flags. Flags is a bitmask + with the following bits defined: + +#define NBPF_SLAVE_RQ_HIGH 1 +#define NBPF_SLAVE_RQ_LOW 2 +#define NBPF_SLAVE_RQ_LEVEL 4 + +Optional properties: + +You can use dma-channels and dma-requests as described in dma.txt, although they +won't be used, this information is derived from the compatibility string. + +Example: + + dma: dma-controller@48000000 { + compatible = "renesas,nbpfaxi64dmac8b4"; + reg = <0x48000000 0x400>; + interrupts = <0 12 0x4 + 0 13 0x4 + 0 14 0x4 + 0 15 0x4 + 0 16 0x4 + 0 17 0x4 + 0 18 0x4 + 0 19 0x4>; + #dma-cells = <2>; + dma-channels = <8>; + dma-requests = <8>; + }; + +* DMA client + +Required properties: + +dmas and dma-names are required, as described in dma.txt. + +Example: + +#include <dt-bindings/dma/nbpfaxi.h> + +... + dmas = <&dma 0 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL) + &dma 1 (NBPF_SLAVE_RQ_HIGH | NBPF_SLAVE_RQ_LEVEL)>; + dma-names = "rx", "tx"; diff --git a/Documentation/devicetree/bindings/dma/rcar-audmapp.txt b/Documentation/devicetree/bindings/dma/rcar-audmapp.txt new file mode 100644 index 00000000000..9f1d750d76d --- /dev/null +++ b/Documentation/devicetree/bindings/dma/rcar-audmapp.txt @@ -0,0 +1,29 @@ +* R-Car Audio DMAC peri peri Device Tree bindings + +Required properties: +- compatible: should be "renesas,rcar-audmapp" +- #dma-cells: should be <1>, see "dmas" property below + +Example: + audmapp: audio-dma-pp@0xec740000 { + compatible = "renesas,rcar-audmapp"; + #dma-cells = <1>; + + reg = <0 0xec740000 0 0x200>; + }; + + +* 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. +- dma-names: a list of DMA channel names, one per "dmas" entry + +Example: + + dmas = <&audmapp 0x2d00 + &audmapp 0x3700>; + dma-names = "src0_ssiu0", + "dvc0_ssiu0"; diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt new file mode 100644 index 00000000000..df0f48bcf75 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.txt @@ -0,0 +1,98 @@ +* Renesas R-Car DMA Controller Device Tree bindings + +Renesas R-Car Generation 2 SoCs have have multiple multi-channel DMA +controller instances named DMAC capable of serving multiple clients. Channels +can be dedicated to specific clients or shared between a large number of +clients. + +DMA clients are connected to the DMAC ports referenced by an 8-bit identifier +called MID/RID. + +Each DMA client is connected to one dedicated port of the DMAC, identified by +an 8-bit port number called the MID/RID. A DMA controller can thus serve up to +256 clients in total. When the number of hardware channels is lower than the +number of clients to be served, channels must be shared between multiple DMA +clients. The association of DMA clients to DMAC channels is fully dynamic and +not described in these device tree bindings. + +Required Properties: + +- compatible: must contain "renesas,rcar-dmac" + +- reg: base address and length of the registers block for the DMAC + +- interrupts: interrupt specifiers for the DMAC, one for each entry in + interrupt-names. +- interrupt-names: one entry per channel, named "ch%u", where %u is the + channel number ranging from zero to the number of channels minus one. + +- clock-names: "fck" for the functional clock +- clocks: a list of phandle + clock-specifier pairs, one for each entry + in clock-names. +- clock-names: must contain "fck" for the functional clock. + +- #dma-cells: must be <1>, the cell specifies the MID/RID of the DMAC port + connected to the DMA client +- dma-channels: number of DMA channels + +Example: R8A7790 (R-Car H2) SYS-DMACs + + dmac0: dma-controller@e6700000 { + compatible = "renesas,rcar-dmac"; + reg = <0 0xe6700000 0 0x20000>; + interrupts = <0 197 IRQ_TYPE_LEVEL_HIGH + 0 200 IRQ_TYPE_LEVEL_HIGH + 0 201 IRQ_TYPE_LEVEL_HIGH + 0 202 IRQ_TYPE_LEVEL_HIGH + 0 203 IRQ_TYPE_LEVEL_HIGH + 0 204 IRQ_TYPE_LEVEL_HIGH + 0 205 IRQ_TYPE_LEVEL_HIGH + 0 206 IRQ_TYPE_LEVEL_HIGH + 0 207 IRQ_TYPE_LEVEL_HIGH + 0 208 IRQ_TYPE_LEVEL_HIGH + 0 209 IRQ_TYPE_LEVEL_HIGH + 0 210 IRQ_TYPE_LEVEL_HIGH + 0 211 IRQ_TYPE_LEVEL_HIGH + 0 212 IRQ_TYPE_LEVEL_HIGH + 0 213 IRQ_TYPE_LEVEL_HIGH + 0 214 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "error", + "ch0", "ch1", "ch2", "ch3", + "ch4", "ch5", "ch6", "ch7", + "ch8", "ch9", "ch10", "ch11", + "ch12", "ch13", "ch14"; + clocks = <&mstp2_clks R8A7790_CLK_SYS_DMAC0>; + clock-names = "fck"; + #dma-cells = <1>; + dma-channels = <15>; + }; + + dmac1: dma-controller@e6720000 { + compatible = "renesas,rcar-dmac"; + reg = <0 0xe6720000 0 0x20000>; + interrupts = <0 220 IRQ_TYPE_LEVEL_HIGH + 0 216 IRQ_TYPE_LEVEL_HIGH + 0 217 IRQ_TYPE_LEVEL_HIGH + 0 218 IRQ_TYPE_LEVEL_HIGH + 0 219 IRQ_TYPE_LEVEL_HIGH + 0 308 IRQ_TYPE_LEVEL_HIGH + 0 309 IRQ_TYPE_LEVEL_HIGH + 0 310 IRQ_TYPE_LEVEL_HIGH + 0 311 IRQ_TYPE_LEVEL_HIGH + 0 312 IRQ_TYPE_LEVEL_HIGH + 0 313 IRQ_TYPE_LEVEL_HIGH + 0 314 IRQ_TYPE_LEVEL_HIGH + 0 315 IRQ_TYPE_LEVEL_HIGH + 0 316 IRQ_TYPE_LEVEL_HIGH + 0 317 IRQ_TYPE_LEVEL_HIGH + 0 318 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "error", + "ch0", "ch1", "ch2", "ch3", + "ch4", "ch5", "ch6", "ch7", + "ch8", "ch9", "ch10", "ch11", + "ch12", "ch13", "ch14"; + clocks = <&mstp2_clks R8A7790_CLK_SYS_DMAC1>; + clock-names = "fck"; + #dma-cells = <1>; + dma-channels = <15>; + }; diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt index 1f5729f1062..95800ab37bb 100644 --- a/Documentation/devicetree/bindings/dma/ste-dma40.txt +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt @@ -35,9 +35,11 @@ Required properties: Each dmas request consists of 4 cells: 1. A phandle pointing to the DMA controller - 2. Device Type + 2. Device signal number, the signal line for single and burst requests + connected from the device to the DMA40 engine 3. The DMA request line number (only when 'use fixed channel' is set) - 4. A 32bit mask specifying; mode, direction and endianness [NB: This list will grow] + 4. A 32bit mask specifying; mode, direction and endianness + [NB: This list will grow] 0x00000001: Mode: Logical channel when unset Physical channel when set @@ -54,6 +56,74 @@ Each dmas request consists of 4 cells: Normal priority when unset High priority when set +Existing signal numbers for the DB8500 ASIC. Unless specified, the signals are +bidirectional, i.e. the same for RX and TX operations: + +0: SPI controller 0 +1: SD/MMC controller 0 (unused) +2: SD/MMC controller 1 (unused) +3: SD/MMC controller 2 (unused) +4: I2C port 1 +5: I2C port 3 +6: I2C port 2 +7: I2C port 4 +8: Synchronous Serial Port SSP0 +9: Synchronous Serial Port SSP1 +10: Multi-Channel Display Engine MCDE RX +11: UART port 2 +12: UART port 1 +13: UART port 0 +14: Multirate Serial Port MSP2 +15: I2C port 0 +16: USB OTG in/out endpoints 7 & 15 +17: USB OTG in/out endpoints 6 & 14 +18: USB OTG in/out endpoints 5 & 13 +19: USB OTG in/out endpoints 4 & 12 +20: SLIMbus or HSI channel 0 +21: SLIMbus or HSI channel 1 +22: SLIMbus or HSI channel 2 +23: SLIMbus or HSI channel 3 +24: Multimedia DSP SXA0 +25: Multimedia DSP SXA1 +26: Multimedia DSP SXA2 +27: Multimedia DSP SXA3 +28: SD/MM controller 2 +29: SD/MM controller 0 +30: MSP port 1 on DB8500 v1, MSP port 3 on DB8500 v2 +31: MSP port 0 or SLIMbus channel 0 +32: SD/MM controller 1 +33: SPI controller 2 +34: i2c3 RX2 TX2 +35: SPI controller 1 +36: USB OTG in/out endpoints 3 & 11 +37: USB OTG in/out endpoints 2 & 10 +38: USB OTG in/out endpoints 1 & 9 +39: USB OTG in/out endpoints 8 +40: SPI controller 3 +41: SD/MM controller 3 +42: SD/MM controller 4 +43: SD/MM controller 5 +44: Multimedia DSP SXA4 +45: Multimedia DSP SXA5 +46: SLIMbus channel 8 or Multimedia DSP SXA6 +47: SLIMbus channel 9 or Multimedia DSP SXA7 +48: Crypto Accelerator 1 +49: Crypto Accelerator 1 TX or Hash Accelerator 1 TX +50: Hash Accelerator 1 TX +51: memcpy TX (to be used by the DMA driver for memcpy operations) +52: SLIMbus or HSI channel 4 +53: SLIMbus or HSI channel 5 +54: SLIMbus or HSI channel 6 +55: SLIMbus or HSI channel 7 +56: memcpy (to be used by the DMA driver for memcpy operations) +57: memcpy (to be used by the DMA driver for memcpy operations) +58: memcpy (to be used by the DMA driver for memcpy operations) +59: memcpy (to be used by the DMA driver for memcpy operations) +60: memcpy (to be used by the DMA driver for memcpy operations) +61: Crypto Accelerator 0 +62: Crypto Accelerator 0 TX or Hash Accelerator 0 TX +63: Hash Accelerator 0 TX + Example: uart@80120000 { diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt b/Documentation/devicetree/bindings/dma/sun6i-dma.txt new file mode 100644 index 00000000000..3e145c1675b --- /dev/null +++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt @@ -0,0 +1,45 @@ +Allwinner A31 DMA Controller + +This driver follows the generic DMA bindings defined in dma.txt. + +Required properties: + +- compatible: Must be "allwinner,sun6i-a31-dma" +- reg: Should contain the registers base address and length +- interrupts: Should contain a reference to the interrupt used by this device +- clocks: Should contain a reference to the parent AHB clock +- resets: Should contain a reference to the reset controller asserting + this device in reset +- #dma-cells : Should be 1, a single cell holding a line request number + +Example: + dma: dma-controller@01c02000 { + compatible = "allwinner,sun6i-a31-dma"; + reg = <0x01c02000 0x1000>; + interrupts = <0 50 4>; + clocks = <&ahb1_gates 6>; + resets = <&ahb1_rst 6>; + #dma-cells = <1>; + }; + +Clients: + +DMA clients connected to the A31 DMA controller must use the format +described in the dma.txt file, using a two-cell specifier for each +channel: a phandle plus one integer cells. +The two cells in order are: + +1. A phandle pointing to the DMA controller. +2. The port ID as specified in the datasheet + +Example: +spi2: spi@01c6a000 { + compatible = "allwinner,sun6i-a31-spi"; + reg = <0x01c6a000 0x1000>; + interrupts = <0 67 4>; + clocks = <&ahb1_gates 22>, <&spi2_clk>; + clock-names = "ahb", "mod"; + dmas = <&dma 25>, <&dma 25>; + dma-names = "rx", "tx"; + resets = <&ahb1_rst 22>; +}; diff --git a/Documentation/devicetree/bindings/drm/armada/marvell,dove-lcd.txt b/Documentation/devicetree/bindings/drm/armada/marvell,dove-lcd.txt new file mode 100644 index 00000000000..46525ea3e64 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/armada/marvell,dove-lcd.txt @@ -0,0 +1,30 @@ +Device Tree bindings for Armada DRM CRTC driver + +Required properties: + - compatible: value should be "marvell,dove-lcd". + - reg: base address and size of the LCD controller + - interrupts: single interrupt number for the LCD controller + - port: video output port with endpoints, as described by graph.txt + +Optional properties: + + - clocks: as described by clock-bindings.txt + - clock-names: as described by clock-bindings.txt + "axiclk" - axi bus clock for pixel clock + "plldivider" - pll divider clock for pixel clock + "ext_ref_clk0" - external clock 0 for pixel clock + "ext_ref_clk1" - external clock 1 for pixel clock + +Note: all clocks are optional but at least one must be specified. +Further clocks may be added in the future according to requirements of +different SoCs. + +Example: + + lcd0: lcd-controller@820000 { + compatible = "marvell,dove-lcd"; + reg = <0x820000 0x1000>; + interrupts = <47>; + clocks = <&si5351 0>; + clock-names = "ext_ref_clk_1"; + }; diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt index d7df01c5bb3..e9e4bce4076 100644 --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt @@ -3,6 +3,8 @@ Device-Tree bindings for the NXP TDA998x HDMI transmitter Required properties; - compatible: must be "nxp,tda998x" + - reg: I2C address + Optional properties: - interrupts: interrupt number and trigger type default: polling diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt b/Documentation/devicetree/bindings/drm/msm/gpu.txt new file mode 100644 index 00000000000..67d0a58dbb7 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/msm/gpu.txt @@ -0,0 +1,52 @@ +Qualcomm adreno/snapdragon GPU + +Required properties: +- compatible: "qcom,adreno-3xx" +- reg: Physical base address and length of the controller's registers. +- interrupts: The interrupt signal from the gpu. +- clocks: device clocks + See ../clocks/clock-bindings.txt for details. +- clock-names: the following clocks are required: + * "core_clk" + * "iface_clk" + * "mem_iface_clk" +- qcom,chipid: gpu chip-id. Note this may become optional for future + devices if we can reliably read the chipid from hw +- qcom,gpu-pwrlevels: list of operating points + - compatible: "qcom,gpu-pwrlevels" + - for each qcom,gpu-pwrlevel: + - qcom,gpu-freq: requested gpu clock speed + - NOTE: downstream android driver defines additional parameters to + configure memory bandwidth scaling per OPP. + +Example: + +/ { + ... + + gpu: qcom,kgsl-3d0@4300000 { + compatible = "qcom,adreno-3xx"; + reg = <0x04300000 0x20000>; + reg-names = "kgsl_3d0_reg_memory"; + interrupts = <GIC_SPI 80 0>; + interrupt-names = "kgsl_3d0_irq"; + clock-names = + "core_clk", + "iface_clk", + "mem_iface_clk"; + clocks = + <&mmcc GFX3D_CLK>, + <&mmcc GFX3D_AHB_CLK>, + <&mmcc MMSS_IMEM_AHB_CLK>; + qcom,chipid = <0x03020100>; + qcom,gpu-pwrlevels { + compatible = "qcom,gpu-pwrlevels"; + qcom,gpu-pwrlevel@0 { + qcom,gpu-freq = <450000000>; + }; + qcom,gpu-pwrlevel@1 { + qcom,gpu-freq = <27000000>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/drm/msm/hdmi.txt b/Documentation/devicetree/bindings/drm/msm/hdmi.txt new file mode 100644 index 00000000000..aca917fe2ba --- /dev/null +++ b/Documentation/devicetree/bindings/drm/msm/hdmi.txt @@ -0,0 +1,46 @@ +Qualcomm adreno/snapdragon hdmi output + +Required properties: +- compatible: one of the following + * "qcom,hdmi-tx-8660" + * "qcom,hdmi-tx-8960" +- reg: Physical base address and length of the controller's registers +- reg-names: "core_physical" +- interrupts: The interrupt signal from the hdmi block. +- clocks: device clocks + See ../clocks/clock-bindings.txt for details. +- qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin +- qcom,hdmi-tx-ddc-data-gpio: ddc data pin +- qcom,hdmi-tx-hpd-gpio: hpd pin +- core-vdda-supply: phandle to supply regulator +- hdmi-mux-supply: phandle to mux regulator + +Optional properties: +- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin +- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin + +Example: + +/ { + ... + + hdmi: qcom,hdmi-tx-8960@4a00000 { + compatible = "qcom,hdmi-tx-8960"; + reg-names = "core_physical"; + reg = <0x04a00000 0x1000>; + interrupts = <GIC_SPI 79 0>; + clock-names = + "core_clk", + "master_iface_clk", + "slave_iface_clk"; + clocks = + <&mmcc HDMI_APP_CLK>, + <&mmcc HDMI_M_AHB_CLK>, + <&mmcc HDMI_S_AHB_CLK>; + qcom,hdmi-tx-ddc-clk = <&msmgpio 70 GPIO_ACTIVE_HIGH>; + qcom,hdmi-tx-ddc-data = <&msmgpio 71 GPIO_ACTIVE_HIGH>; + qcom,hdmi-tx-hpd = <&msmgpio 72 GPIO_ACTIVE_HIGH>; + core-vdda-supply = <&pm8921_hdmi_mvs>; + hdmi-mux-supply = <&ext_3p3v>; + }; +}; diff --git a/Documentation/devicetree/bindings/drm/msm/mdp.txt b/Documentation/devicetree/bindings/drm/msm/mdp.txt new file mode 100644 index 00000000000..1a0598e5279 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/msm/mdp.txt @@ -0,0 +1,48 @@ +Qualcomm adreno/snapdragon display controller + +Required properties: +- compatible: + * "qcom,mdp" - mdp4 +- reg: Physical base address and length of the controller's registers. +- interrupts: The interrupt signal from the display controller. +- connectors: array of phandles for output device(s) +- clocks: device clocks + See ../clocks/clock-bindings.txt for details. +- clock-names: the following clocks are required: + * "core_clk" + * "iface_clk" + * "lut_clk" + * "src_clk" + * "hdmi_clk" + * "mpd_clk" + +Optional properties: +- gpus: phandle for gpu device + +Example: + +/ { + ... + + mdp: qcom,mdp@5100000 { + compatible = "qcom,mdp"; + reg = <0x05100000 0xf0000>; + interrupts = <GIC_SPI 75 0>; + connectors = <&hdmi>; + gpus = <&gpu>; + clock-names = + "core_clk", + "iface_clk", + "lut_clk", + "src_clk", + "hdmi_clk", + "mdp_clk"; + clocks = + <&mmcc MDP_SRC>, + <&mmcc MDP_AHB_CLK>, + <&mmcc MDP_LUT_CLK>, + <&mmcc TV_SRC>, + <&mmcc HDMI_TV_CLK>, + <&mmcc MDP_TV_CLK>; + }; +}; diff --git a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt new file mode 100644 index 00000000000..d8c98c7614d --- /dev/null +++ b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt @@ -0,0 +1,40 @@ +NVIDIA Tegra20/Tegra30/Tegr114/Tegra124 fuse block. + +Required properties: +- compatible : should be: + "nvidia,tegra20-efuse" + "nvidia,tegra30-efuse" + "nvidia,tegra114-efuse" + "nvidia,tegra124-efuse" + Details: + nvidia,tegra20-efuse: Tegra20 requires using APB DMA to read the fuse data + due to a hardware bug. Tegra20 also lacks certain information which is + available in later generations such as fab code, lot code, wafer id,.. + nvidia,tegra30-efuse, nvidia,tegra114-efuse and nvidia,tegra124-efuse: + The differences between these SoCs are the size of the efuse array, + the location of the spare (OEM programmable) bits and the location of + the speedo data. +- reg: Should contain 1 entry: the entry gives the physical address and length + of the fuse registers. +- clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names: Must include the following entries: + - fuse +- resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names: Must include the following entries: + - fuse + +Example: + + fuse@7000f800 { + compatible = "nvidia,tegra20-efuse"; + reg = <0x7000F800 0x400>, + <0x70000000 0x400>; + clocks = <&tegra_car TEGRA20_CLK_FUSE>; + clock-names = "fuse"; + resets = <&tegra_car 39>; + reset-names = "fuse"; + }; + + diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt new file mode 100644 index 00000000000..986371a4be2 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt @@ -0,0 +1,26 @@ +Xilinx Zynq GPIO controller Device Tree Bindings +------------------------------------------- + +Required properties: +- #gpio-cells : Should be two + - First cell is the GPIO line number + - Second cell is used to specify optional + parameters (unused) +- compatible : Should be "xlnx,zynq-gpio-1.0" +- clocks : Clock specifier (see clock bindings for details) +- gpio-controller : Marks the device node as a GPIO controller. +- interrupts : Interrupt specifier (see interrupt bindings for + details) +- interrupt-parent : Must be core interrupt controller +- reg : Address and length of the register set for the device + +Example: + gpio@e000a000 { + #gpio-cells = <2>; + compatible = "xlnx,zynq-gpio-1.0"; + clocks = <&clkc 42>; + gpio-controller; + interrupt-parent = <&intc>; + interrupts = <0 20 4>; + reg = <0xe000a000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt new file mode 100644 index 00000000000..23bfe8e1f7c --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt @@ -0,0 +1,43 @@ +NVIDIA GK20A Graphics Processing Unit + +Required properties: +- compatible: "nvidia,<chip>-<gpu>" + Currently recognized values: + - nvidia,tegra124-gk20a +- reg: Physical base address and length of the controller's registers. + Must contain two entries: + - first entry for bar0 + - second entry for bar1 +- interrupts: Must contain an entry for each entry in interrupt-names. + See ../interrupt-controller/interrupts.txt for details. +- interrupt-names: Must include the following entries: + - stall + - nonstall +- vdd-supply: regulator for supply voltage. +- clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names: Must include the following entries: + - gpu + - pwr +- resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names: Must include the following entries: + - gpu + +Example: + + gpu@0,57000000 { + compatible = "nvidia,gk20a"; + reg = <0x0 0x57000000 0x0 0x01000000>, + <0x0 0x58000000 0x0 0x01000000>; + interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "stall", "nonstall"; + vdd-supply = <&vdd_gpu>; + clocks = <&tegra_car TEGRA124_CLK_GPU>, + <&tegra_car TEGRA124_CLK_PLL_P_OUT5>; + clock-names = "gpu", "pwr"; + resets = <&tegra_car 184>; + reset-names = "gpu"; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt new file mode 100644 index 00000000000..2d150c311a0 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt @@ -0,0 +1,189 @@ +STMicroelectronics stih4xx platforms + +- sti-vtg: video timing generator + Required properties: + - compatible: "st,vtg" + - reg: Physical base address of the IP registers and length of memory mapped region. + Optional properties: + - interrupts : VTG interrupt number to the CPU. + - st,slave: phandle on a slave vtg + +- sti-vtac: video timing advanced inter dye communication Rx and TX + Required properties: + - compatible: "st,vtac-main" or "st,vtac-aux" + - reg: Physical base address of the IP registers and length of memory mapped region. + - clocks: from common clock binding: handle hardware IP needed clocks, the + number of clocks may depend of the SoC type. + See ../clocks/clock-bindings.txt for details. + - clock-names: names of the clocks listed in clocks property in the same + order. + +- sti-display-subsystem: Master device for DRM sub-components + This device must be the parent of all the sub-components and is responsible + of bind them. + Required properties: + - compatible: "st,sti-display-subsystem" + - ranges: to allow probing of subdevices + +- sti-compositor: frame compositor engine + must be a child of sti-display-subsystem + Required properties: + - compatible: "st,stih<chip>-compositor" + - reg: Physical base address of the IP registers and length of memory mapped region. + - clocks: from common clock binding: handle hardware IP needed clocks, the + number of clocks may depend of the SoC type. + See ../clocks/clock-bindings.txt for details. + - clock-names: names of the clocks listed in clocks property in the same + order. + - resets: resets to be used by the device + See ../reset/reset.txt for details. + - reset-names: names of the resets listed in resets property in the same + order. + - st,vtg: phandle(s) on vtg device (main and aux) nodes. + +- sti-tvout: video out hardware block + must be a child of sti-display-subsystem + Required properties: + - compatible: "st,stih<chip>-tvout" + - reg: Physical base address of the IP registers and length of memory mapped region. + - reg-names: names of the mapped memory regions listed in regs property in + the same order. + - resets: resets to be used by the device + See ../reset/reset.txt for details. + - reset-names: names of the resets listed in resets property in the same + order. + - ranges: to allow probing of subdevices + +- sti-hdmi: hdmi output block + must be a child of sti-tvout + Required properties: + - compatible: "st,stih<chip>-hdmi"; + - reg: Physical base address of the IP registers and length of memory mapped region. + - reg-names: names of the mapped memory regions listed in regs property in + the same order. + - interrupts : HDMI interrupt number to the CPU. + - interrupt-names: name of the interrupts listed in interrupts property in + the same order + - clocks: from common clock binding: handle hardware IP needed clocks, the + number of clocks may depend of the SoC type. + - clock-names: names of the clocks listed in clocks property in the same + order. + - hdmi,hpd-gpio: gpio id to detect if an hdmi cable is plugged or not. + +sti-hda: + Required properties: + must be a child of sti-tvout + - compatible: "st,stih<chip>-hda" + - reg: Physical base address of the IP registers and length of memory mapped region. + - reg-names: names of the mapped memory regions listed in regs property in + the same order. + - clocks: from common clock binding: handle hardware IP needed clocks, the + number of clocks may depend of the SoC type. + See ../clocks/clock-bindings.txt for details. + - clock-names: names of the clocks listed in clocks property in the same + order. + +Example: + +/ { + ... + + vtg_main_slave: sti-vtg-main-slave@fe85A800 { + compatible = "st,vtg"; + reg = <0xfe85A800 0x300>; + interrupts = <GIC_SPI 175 IRQ_TYPE_NONE>; + }; + + vtg_main: sti-vtg-main-master@fd348000 { + compatible = "st,vtg"; + reg = <0xfd348000 0x400>; + st,slave = <&vtg_main_slave>; + }; + + vtg_aux_slave: sti-vtg-aux-slave@fd348400 { + compatible = "st,vtg"; + reg = <0xfe858200 0x300>; + interrupts = <GIC_SPI 176 IRQ_TYPE_NONE>; + }; + + vtg_aux: sti-vtg-aux-master@fd348400 { + compatible = "st,vtg"; + reg = <0xfd348400 0x400>; + st,slave = <&vtg_aux_slave>; + }; + + + sti-vtac-rx-main@fee82800 { + compatible = "st,vtac-main"; + reg = <0xfee82800 0x200>; + clock-names = "vtac"; + clocks = <&clk_m_a2_div0 CLK_M_VTAC_MAIN_PHY>; + }; + + sti-vtac-rx-aux@fee82a00 { + compatible = "st,vtac-aux"; + reg = <0xfee82a00 0x200>; + clock-names = "vtac"; + clocks = <&clk_m_a2_div0 CLK_M_VTAC_AUX_PHY>; + }; + + sti-vtac-tx-main@fd349000 { + compatible = "st,vtac-main"; + reg = <0xfd349000 0x200>, <0xfd320000 0x10000>; + clock-names = "vtac"; + clocks = <&clk_s_a1_hs CLK_S_VTAC_TX_PHY>; + }; + + sti-vtac-tx-aux@fd349200 { + compatible = "st,vtac-aux"; + reg = <0xfd349200 0x200>, <0xfd320000 0x10000>; + clock-names = "vtac"; + clocks = <&clk_s_a1_hs CLK_S_VTAC_TX_PHY>; + }; + + sti-display-subsystem { + compatible = "st,sti-display-subsystem"; + ranges; + + sti-compositor@fd340000 { + compatible = "st,stih416-compositor"; + reg = <0xfd340000 0x1000>; + clock-names = "compo_main", "compo_aux", + "pix_main", "pix_aux"; + clocks = <&clk_m_a2_div1 CLK_M_COMPO_MAIN>, <&clk_m_a2_div1 CLK_M_COMPO_AUX>, + <&clockgen_c_vcc CLK_S_PIX_MAIN>, <&clockgen_c_vcc CLK_S_PIX_AUX>; + reset-names = "compo-main", "compo-aux"; + resets = <&softreset STIH416_COMPO_M_SOFTRESET>, <&softreset STIH416_COMPO_A_SOFTRESET>; + st,vtg = <&vtg_main>, <&vtg_aux>; + }; + + sti-tvout@fe000000 { + compatible = "st,stih416-tvout"; + reg = <0xfe000000 0x1000>, <0xfe85a000 0x400>, <0xfe830000 0x10000>; + reg-names = "tvout-reg", "hda-reg", "syscfg"; + reset-names = "tvout"; + resets = <&softreset STIH416_HDTVOUT_SOFTRESET>; + ranges; + + sti-hdmi@fe85c000 { + compatible = "st,stih416-hdmi"; + reg = <0xfe85c000 0x1000>, <0xfe830000 0x10000>; + reg-names = "hdmi-reg", "syscfg"; + interrupts = <GIC_SPI 173 IRQ_TYPE_NONE>; + interrupt-names = "irq"; + clock-names = "pix", "tmds", "phy", "audio"; + clocks = <&clockgen_c_vcc CLK_S_PIX_HDMI>, <&clockgen_c_vcc CLK_S_TMDS_HDMI>, <&clockgen_c_vcc CLK_S_HDMI_REJECT_PLL>, <&clockgen_b1 CLK_S_PCM_0>; + hdmi,hpd-gpio = <&PIO2 5>; + }; + + sti-hda@fe85a000 { + compatible = "st,stih416-hda"; + reg = <0xfe85a000 0x400>, <0xfe83085c 0x4>; + reg-names = "hda-reg", "video-dacs-ctrl"; + clock-names = "pix", "hddac"; + clocks = <&clockgen_c_vcc CLK_S_PIX_HD>, <&clockgen_c_vcc CLK_S_HDDAC>; + }; + }; + }; + ... +}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-efm32.txt b/Documentation/devicetree/bindings/i2c/i2c-efm32.txt index fc15ac51943..50b25c3da18 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-efm32.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-efm32.txt @@ -10,7 +10,7 @@ Required properties : Recommended properties : - clock-frequency : maximal I2C bus clock frequency in Hz. - - efm32,location : Decides the location of the USART I/O pins. + - energymicro,location : Decides the location of the USART I/O pins. Allowed range : [0 .. 6] Example: @@ -23,7 +23,7 @@ Example: clocks = <&cmu clk_HFPERCLKI2C0>; clock-frequency = <100000>; status = "ok"; - efm32,location = <3>; + energymicro,location = <3>; eeprom@50 { compatible = "microchip,24c02"; diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index 37803eb5521..6af570ec53b 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -70,6 +70,7 @@ nuvoton,npct501 i2c trusted platform module (TPM) nxp,pca9556 Octal SMBus and I2C registered interface nxp,pca9557 8-bit I2C-bus and SMBus I/O port with reset nxp,pcf8563 Real-time clock/calendar +nxp,pcf85063 Tiny Real-Time Clock ovti,ov5642 OV5642: Color CMOS QSXGA (5-megapixel) Image Sensor with OmniBSI and Embedded TrueFocus pericom,pt7c4338 Real-time Clock Module plx,pex8648 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt new file mode 100644 index 00000000000..baef432e836 --- /dev/null +++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt @@ -0,0 +1,25 @@ +Atmel maXTouch touchscreen/touchpad + +Required properties: +- compatible: + atmel,maxtouch + +- reg: The I2C address of the device + +- interrupts: The sink for the touchpad's IRQ output + See ../interrupt-controller/interrupts.txt + +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 + <dt-bindings/input/input.h>. + +Example: + + touch@4b { + compatible = "atmel,maxtouch"; + reg = <0x4b>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_LOW>; + }; diff --git a/Documentation/devicetree/bindings/input/cap1106.txt b/Documentation/devicetree/bindings/input/cap1106.txt new file mode 100644 index 00000000000..4b463904cba --- /dev/null +++ b/Documentation/devicetree/bindings/input/cap1106.txt @@ -0,0 +1,53 @@ +Device tree bindings for Microchip CAP1106, 6 channel capacitive touch sensor + +The node for this driver must be a child of a I2C controller node, as the +device communication via I2C only. + +Required properties: + + compatible: Must be "microchip,cap1106" + + reg: The I2C slave address of the device. + Only 0x28 is valid. + + interrupts: Property describing the interrupt line the + device's ALERT#/CM_IRQ# pin is connected to. + The device only has one interrupt source. + +Optional properties: + + autorepeat: Enables the Linux input system's autorepeat + feature on the input device. + + microchip,sensor-gain: Defines the gain of the sensor circuitry. This + effectively controls the sensitivity, as a + smaller delta capacitance is required to + generate the same delta count values. + Valid values are 1, 2, 4, and 8. + By default, a gain of 1 is set. + + linux,keycodes: Specifies an array of numeric keycode values to + be used for the channels. If this property is + omitted, KEY_A, KEY_B, etc are used as + defaults. The array must have exactly six + entries. + +Example: + +i2c_controller { + cap1106@28 { + compatible = "microchip,cap1106"; + interrupt-parent = <&gpio1>; + interrupts = <0 0>; + reg = <0x28>; + autorepeat; + microchip,sensor-gain = <2>; + + linux,keycodes = <103 /* KEY_UP */ + 106 /* KEY_RIGHT */ + 108 /* KEY_DOWN */ + 105 /* KEY_LEFT */ + 109 /* KEY_PAGEDOWN */ + 104>; /* KEY_PAGEUP */ + }; +} diff --git a/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt new file mode 100644 index 00000000000..6e551090f46 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt @@ -0,0 +1,26 @@ +* Pixcir I2C touchscreen controllers + +Required properties: +- compatible: must be "pixcir,pixcir_ts" or "pixcir,pixcir_tangoc" +- reg: I2C address of the chip +- interrupts: interrupt to which the chip is connected +- attb-gpio: GPIO connected to the ATTB line of the chip +- touchscreen-size-x: horizontal resolution of touchscreen (in pixels) +- touchscreen-size-y: vertical resolution of touchscreen (in pixels) + +Example: + + i2c@00000000 { + /* ... */ + + pixcir_ts@5c { + compatible = "pixcir,pixcir_ts"; + reg = <0x5c>; + interrupts = <2 0>; + attb-gpio = <&gpf 2 0 2>; + touchscreen-size-x = <800>; + touchscreen-size-y = <600>; + }; + + /* ... */ + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt index 2faf1f1fa39..80c37df940a 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt @@ -9,6 +9,9 @@ Required properties: - x-size: horizontal resolution of touchscreen - y-size: vertical resolution of touchscreen +Optional properties: +- vdd-supply: Regulator controlling the controller supply + Example: i2c@00000000 { @@ -18,6 +21,7 @@ Example: compatible = "neonode,zforce"; reg = <0x50>; interrupts = <2 0>; + vdd-supply = <®_zforce_vdd>; gpios = <&gpio5 6 0>, /* INT */ <&gpio5 9 0>; /* RST */ diff --git a/Documentation/devicetree/bindings/leds/pca963x.txt b/Documentation/devicetree/bindings/leds/pca963x.txt index aece3eac1b6..dafbe9931c2 100644 --- a/Documentation/devicetree/bindings/leds/pca963x.txt +++ b/Documentation/devicetree/bindings/leds/pca963x.txt @@ -1,18 +1,19 @@ LEDs connected to pca9632, pca9633 or pca9634 Required properties: -- compatible : should be : "nxp,pca9632", "nxp,pca9633" or "nxp,pca9634" +- compatible : should be : "nxp,pca9632", "nxp,pca9633", "nxp,pca9634" or "nxp,pca9635" Optional properties: -- nxp,totem-pole : use totem pole (push-pull) instead of default open-drain +- nxp,totem-pole : use totem pole (push-pull) instead of open-drain (pca9632 defaults + to open-drain, newer chips to totem pole) - nxp,hw-blink : use hardware blinking instead of software blinking Each led is represented as a sub-node of the nxp,pca963x device. LED sub-node properties: - label : (optional) see Documentation/devicetree/bindings/leds/common.txt -- reg : number of LED line (could be from 0 to 3 in pca9632 or pca9633 - or 0 to 7 in pca9634) +- reg : number of LED line (could be from 0 to 3 in pca9632 or pca9633, + 0 to 7 in pca9634, or 0 to 15 in pca9635) - linux,default-trigger : (optional) see Documentation/devicetree/bindings/leds/common.txt diff --git a/Documentation/devicetree/bindings/leds/tca6507.txt b/Documentation/devicetree/bindings/leds/tca6507.txt index d7221b84987..bad9102796f 100644 --- a/Documentation/devicetree/bindings/leds/tca6507.txt +++ b/Documentation/devicetree/bindings/leds/tca6507.txt @@ -8,7 +8,7 @@ Required properties: Optional properties: - gpio-controller: allows lines to be used as output-only GPIOs. -- #gpio-cells: if present, must be 0. +- #gpio-cells: if present, must not be 0. Each led is represented as a sub-node of the ti,tca6507 device. diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index 36a0c3d8c72..5c7e7230984 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -42,6 +42,16 @@ Optional properties: the chip default will be used. If present exactly five values must be specified. + - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if + they are being externally supplied. As covered in + Documentation/devicetree/bindings/regulator/regulator.txt + +Optional subnodes: + - ldo1 : Initial data for the LDO1 regulator, as covered in + Documentation/devicetree/bindings/regulator/regulator.txt + - micvdd : Initial data for the MICVDD regulator, as covered in + Documentation/devicetree/bindings/regulator/regulator.txt + Example: codec: wm5102@1a { diff --git a/Documentation/devicetree/bindings/mfd/as3722.txt b/Documentation/devicetree/bindings/mfd/as3722.txt index 8edcb9bd873..4f64b2a7316 100644 --- a/Documentation/devicetree/bindings/mfd/as3722.txt +++ b/Documentation/devicetree/bindings/mfd/as3722.txt @@ -13,6 +13,14 @@ Required properties: The second cell is the flags, encoded as the trigger masks from binding document interrupts.txt, using dt-bindings/irq. +Optional properties: +-------------------- +- ams,enable-internal-int-pullup: Boolean property, to enable internal pullup on + interrupt pin. Missing this will disable internal pullup on INT pin. +- ams,enable-internal-i2c-pullup: Boolean property, to enable internal pullup on + i2c scl/sda pins. Missing this will disable internal pullup on i2c + scl/sda lines. + Optional submodule and their properties: ======================================= diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index d81ba30c0d8..ba2d7f0f9c5 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11 and S2MPS14 Voltage and Current Regulator +* Samsung S2MPS11, S2MPS14 and S2MPU02 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,7 +7,8 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps14-pmic". +- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps14-pmic" + or "samsung,s2mpu02-pmic". - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: @@ -81,11 +82,13 @@ as per the datasheet of s2mps11. - valid values for n are: - S2MPS11: 1 to 38 - S2MPS14: 1 to 25 - - Example: LDO1, LD02, LDO28 + - S2MPU02: 1 to 28 + - Example: LDO1, LDO2, LDO28 - BUCKn - valid values for n are: - S2MPS11: 1 to 10 - S2MPS14: 1 to 5 + - S2MPU02: 1 to 7 - Example: BUCK1, BUCK2, BUCK9 Example: @@ -96,7 +99,7 @@ Example: s2m_osc: clocks { compatible = "samsung,s2mps11-clk"; - #clock-cells = 1; + #clock-cells = <1>; clock-output-names = "xx", "yy", "zz"; }; diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt index 1f5a31fef90..03c5a551da5 100644 --- a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt +++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt @@ -4,7 +4,7 @@ PRCM is an MFD device exposing several Power Management related devices (like clks and reset controllers). Required properties: - - compatible: "allwinner,sun6i-a31-prcm" + - compatible: "allwinner,sun6i-a31-prcm" or "allwinner,sun8i-a23-prcm" - reg: The PRCM registers range The prcm node may contain several subdevices definitions: diff --git a/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt b/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt new file mode 100644 index 00000000000..b97b8bef1fe --- /dev/null +++ b/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt @@ -0,0 +1,13 @@ +NVIDIA Tegra20/Tegra30/Tegr114/Tegra124 apbmisc block + +Required properties: +- compatible : should be: + "nvidia,tegra20-apbmisc" + "nvidia,tegra30-apbmisc" + "nvidia,tegra114-apbmisc" + "nvidia,tegra124-apbmisc" +- reg: Should contain 2 entries: the first entry gives the physical address + and length of the registers which contain revision and debug features. + The second entry gives the physical address and length of the + registers indicating the strapping options. + diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt index 458d5963468..a011fdf61db 100644 --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt @@ -25,6 +25,16 @@ Optional properties: discoverable or this property is not enabled, the software may chooses an implementation-defined ECC scheme. + - fsl,no-blockmark-swap: Don't swap the bad block marker from the OOB + area with the byte in the data area but rely on the + flash based BBT for identifying bad blocks. + NOTE: this is only valid in conjunction with + 'nand-on-flash-bbt'. + WARNING: on i.MX28 blockmark swapping cannot be + disabled for the BootROM in the FCB. Thus, + partitions written from Linux with this feature + turned on may not be accessible by the BootROM + code. The device tree may optionally contain sub-nodes describing partitions of the address space. See partition.txt for more detail. diff --git a/Documentation/devicetree/bindings/panel/auo,b133htn01.txt b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt new file mode 100644 index 00000000000..302226b5bb5 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt @@ -0,0 +1,7 @@ +AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel + +Required properties: +- compatible: should be "auo,b133htn01" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/foxlink,fl500wvr00-a0t.txt b/Documentation/devicetree/bindings/panel/foxlink,fl500wvr00-a0t.txt new file mode 100644 index 00000000000..b47f9d87bc1 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/foxlink,fl500wvr00-a0t.txt @@ -0,0 +1,7 @@ +Foxlink Group 5" WVGA TFT LCD panel + +Required properties: +- compatible: should be "foxlink,fl500wvr00-a0t" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/innolux,n116bge.txt b/Documentation/devicetree/bindings/panel/innolux,n116bge.txt new file mode 100644 index 00000000000..081bb939ed3 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/innolux,n116bge.txt @@ -0,0 +1,7 @@ +Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel + +Required properties: +- compatible: should be "innolux,n116bge" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/innolux,n156bge-l21.txt b/Documentation/devicetree/bindings/panel/innolux,n156bge-l21.txt new file mode 100644 index 00000000000..7825844aafd --- /dev/null +++ b/Documentation/devicetree/bindings/panel/innolux,n156bge-l21.txt @@ -0,0 +1,7 @@ +InnoLux 15.6" WXGA TFT LCD panel + +Required properties: +- compatible: should be "innolux,n156bge-l21" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt index c300391e8d3..0823362548d 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt @@ -14,9 +14,6 @@ Required properties: - interrupt-names: Must include the following entries: "intr": The Tegra interrupt that is asserted for controller interrupts "msi": The Tegra interrupt that is asserted when an MSI is received -- pex-clk-supply: Supply voltage for internal reference clock -- vdd-supply: Power supply for controller (1.05V) -- avdd-supply: Power supply for controller (1.05V) (not required for Tegra20) - bus-range: Range of bus numbers associated with this controller - #address-cells: Address representation for root ports (must be 3) - cell 0 specifies the bus and device numbers of the root port: @@ -60,6 +57,33 @@ Required properties: - afi - pcie_x +Power supplies for Tegra20: +- avdd-pex-supply: Power supply for analog PCIe logic. Must supply 1.05 V. +- vdd-pex-supply: Power supply for digital PCIe I/O. Must supply 1.05 V. +- avdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must + supply 1.05 V. +- avdd-plle-supply: Power supply for PLLE, which is shared with SATA. Must + supply 1.05 V. +- vddio-pex-clk-supply: Power supply for PCIe clock. Must supply 3.3 V. + +Power supplies for Tegra30: +- Required: + - avdd-pex-pll-supply: Power supply for dedicated (internal) PCIe PLL. Must + supply 1.05 V. + - avdd-plle-supply: Power supply for PLLE, which is shared with SATA. Must + supply 1.05 V. + - vddio-pex-ctl-supply: Power supply for PCIe control I/O partition. Must + supply 1.8 V. + - hvdd-pex-supply: High-voltage supply for PCIe I/O and PCIe output clocks. + Must supply 3.3 V. +- Optional: + - If lanes 0 to 3 are used: + - avdd-pexa-supply: Power supply for analog PCIe logic. Must supply 1.05 V. + - vdd-pexa-supply: Power supply for digital PCIe I/O. Must supply 1.05 V. + - If lanes 4 or 5 are used: + - avdd-pexb-supply: Power supply for analog PCIe logic. Must supply 1.05 V. + - vdd-pexb-supply: Power supply for digital PCIe I/O. Must supply 1.05 V. + Root ports are defined as subnodes of the PCIe controller node. Required properties: diff --git a/Documentation/devicetree/bindings/pci/spear13xx-pcie.txt b/Documentation/devicetree/bindings/pci/spear13xx-pcie.txt new file mode 100644 index 00000000000..49ea76da771 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/spear13xx-pcie.txt @@ -0,0 +1,14 @@ +SPEAr13XX PCIe DT detail: +================================ + +SPEAr13XX uses synopsis designware PCIe controller and ST MiPHY as phy +controller. + +Required properties: +- compatible : should be "st,spear1340-pcie", "snps,dw-pcie". +- phys : phandle to phy node associated with pcie controller +- phy-names : must be "pcie-phy" +- All other definitions as per generic PCI bindings + + Optional properties: +- st,pcie-is-gen1 indicates that forced gen1 initialization is needed. diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 6099a5c9428..7a6feea2a48 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -30,6 +30,7 @@ Required properties: - "samsung,exynos4210-usb2-phy" - "samsung,exynos4x12-usb2-phy" - "samsung,exynos5250-usb2-phy" + - "samsung,s5pv210-usb2-phy" - reg : a list of registers used by phy driver - first and obligatory is the location of phy modules registers - samsung,sysreg-phandle - handle to syscon used to control the system registers diff --git a/Documentation/devicetree/bindings/phy/st-spear-miphy.txt b/Documentation/devicetree/bindings/phy/st-spear-miphy.txt new file mode 100644 index 00000000000..2a6bfdcc09b --- /dev/null +++ b/Documentation/devicetree/bindings/phy/st-spear-miphy.txt @@ -0,0 +1,15 @@ +ST SPEAr miphy DT details +========================= + +ST Microelectronics SPEAr miphy is a phy controller supporting PCIe and SATA. + +Required properties: +- compatible : should be "st,spear1310-miphy" or "st,spear1340-miphy" +- reg : offset and length of the PHY register set. +- misc: phandle for the syscon node to access misc registers +- #phy-cells : from the generic PHY bindings, must be 1. + - cell[1]: 0 if phy used for SATA, 1 for PCIe. + +Optional properties: +- phy-id: Instance id of the phy. Only required when there are multiple phys + present on a implementation. diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt index d8d065608ec..93ce12eb422 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt @@ -13,6 +13,8 @@ Required properties: "allwinner,sun6i-a31-pinctrl" "allwinner,sun6i-a31-r-pinctrl" "allwinner,sun7i-a20-pinctrl" + "allwinner,sun8i-a23-pinctrl" + "allwinner,sun8i-a23-r-pinctrl" - reg: Should contain the register physical address and length for the pin controller. diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt new file mode 100644 index 00000000000..2f9c0bd6645 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt @@ -0,0 +1,127 @@ +Device tree binding for NVIDIA Tegra XUSB pad controller +======================================================== + +The Tegra XUSB pad controller manages a set of lanes, each of which can be +assigned to one out of a set of different pads. Some of these pads have an +associated PHY that must be powered up before the pad can be used. + +This document defines the device-specific binding for the XUSB pad controller. + +Refer to pinctrl-bindings.txt in this directory for generic information about +pin controller device tree bindings and ../phy/phy-bindings.txt for details on +how to describe and reference PHYs in device trees. + +Required properties: +-------------------- +- compatible: should be "nvidia,tegra124-xusb-padctl" +- reg: Physical base address and length of the controller's registers. +- resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names: Must include the following entries: + - padctl +- #phy-cells: Should be 1. The specifier is the index of the PHY to reference. + See <dt-bindings/pinctrl/pinctrl-tegra-xusb.h> for the list of valid values. + +Lane muxing: +------------ + +Child nodes contain the pinmux configurations following the conventions from +the pinctrl-bindings.txt document. Typically a single, static configuration is +given and applied at boot time. + +Each subnode describes groups of lanes along with parameters and pads that +they should be assigned to. The name of these subnodes is not important. All +subnodes should be parsed solely based on their content. + +Each subnode only applies the parameters that are explicitly listed. In other +words, if a subnode that lists a function but no pin configuration parameters +implies no information about any pin configuration parameters. Similarly, a +subnode that describes only an IDDQ parameter implies no information about +what function the pins are assigned to. For this reason even seemingly boolean +values are actually tristates in this binding: unspecified, off or on. +Unspecified is represented as an absent property, and off/on are represented +as integer values 0 and 1. + +Required properties: +- nvidia,lanes: An array of strings. Each string is the name of a lane. + +Optional properties: +- nvidia,function: A string that is the name of the function (pad) that the + pin or group should be assigned to. Valid values for function names are + listed below. +- nvidia,iddq: Enables IDDQ mode of the lane. (0: no, 1: yes) + +Note that not all of these properties are valid for all lanes. Lanes can be +divided into three groups: + + - otg-0, otg-1, otg-2: + + Valid functions for this group are: "snps", "xusb", "uart", "rsvd". + + The nvidia,iddq property does not apply to this group. + + - ulpi-0, hsic-0, hsic-1: + + Valid functions for this group are: "snps", "xusb". + + The nvidia,iddq property does not apply to this group. + + - pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, sata-0: + + Valid functions for this group are: "pcie", "usb3", "sata", "rsvd". + + +Example: +======== + +SoC file extract: +----------------- + + padctl@0,7009f000 { + compatible = "nvidia,tegra124-xusb-padctl"; + reg = <0x0 0x7009f000 0x0 0x1000>; + resets = <&tegra_car 142>; + reset-names = "padctl"; + + #phy-cells = <1>; + }; + +Board file extract: +------------------- + + pcie-controller@0,01003000 { + ... + + phys = <&padctl 0>; + phy-names = "pcie"; + + ... + }; + + ... + + padctl: padctl@0,7009f000 { + pinctrl-0 = <&padctl_default>; + pinctrl-names = "default"; + + padctl_default: pinmux { + usb3 { + nvidia,lanes = "pcie-0", "pcie-1"; + nvidia,function = "usb3"; + nvidia,iddq = <0>; + }; + + pcie { + nvidia,lanes = "pcie-2", "pcie-3", + "pcie-4"; + nvidia,function = "pcie"; + nvidia,iddq = <0>; + }; + + sata { + nvidia,lanes = "sata-0"; + nvidia,function = "sata"; + nvidia,iddq = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt index 7181f925aca..0211c6d8a52 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt @@ -46,7 +46,7 @@ Valid values for pins are: gpio0-gpio89 Valid values for function are: - cam_mclk, codec_mic_i2s, codec_spkr_i2s, gsbi1, gsbi2, gsbi3, gsbi4, + cam_mclk, codec_mic_i2s, codec_spkr_i2s, gpio, gsbi1, gsbi2, gsbi3, gsbi4, gsbi4_cam_i2c, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3, gsbi7, gsbi7_spi_cs1, gsbi7_spi_cs2, gsbi7_spi_cs3, gsbi_cam_i2c, hdmi, mi2s, riva_bt, riva_fm, diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt index e0d35a40981..e33e4dcdce7 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt @@ -51,7 +51,7 @@ Valid values for qcom,pins are: Valid values for function are: - mdio, mi2s, pdm, ssbi, spmi, audio_pcm, gsbi1, gsbi2, gsbi4, gsbi5, + mdio, mi2s, pdm, ssbi, spmi, audio_pcm, gpio, gsbi1, gsbi2, gsbi4, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, gsbi7, nss_spi, sdc1, spdif, nand, tsif1, tsif2, usb_fs_n, usb_fs, usb2_hsic, rgmii2, sata, pcie1_rst, pcie1_prsnt, pcie1_pwren_n, pcie1_pwren, pcie1_pwrflt, diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt new file mode 100644 index 00000000000..93b7de91b9f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8960-pinctrl.txt @@ -0,0 +1,181 @@ +Qualcomm MSM8960 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +MSM8960 platform. + +- compatible: + Usage: required + Value type: <string> + Definition: must be "qcom,msm8960-pinctrl" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: <none> + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/interrupt-controller/irq.h> + +- gpio-controller: + Usage: required + Value type: <none> + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: <u32> + Definition: must be 2. Specifying the pin number and flags, as defined + in <dt-bindings/gpio/gpio.h> + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: <string-array> + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio151, + sdc1_clk, + sdc1_cmd, + sdc1_data + sdc3_clk, + sdc3_cmd, + sdc3_data + +- function: + Usage: required + Value type: <string> + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + audio_pcm, bt, cam_mclk0, cam_mclk1, cam_mclk2, + codec_mic_i2s, codec_spkr_i2s, ext_gps, fm, gps_blanking, + gps_pps_in, gps_pps_out, gp_clk_0a, gp_clk_0b, gp_clk_1a, + gp_clk_1b, gp_clk_2a, gp_clk_2b, gp_mn, gp_pdm_0a, + gp_pdm_0b, gp_pdm_1a, gp_pdm_1b, gp_pdm_2a, gp_pdm_2b, gpio, + gsbi1, gsbi1_spi_cs1_n, gsbi1_spi_cs2a_n, gsbi1_spi_cs2b_n, + gsbi1_spi_cs3_n, gsbi2, gsbi2_spi_cs1_n, gsbi2_spi_cs2_n, + gsbi2_spi_cs3_n, gsbi3, gsbi4, gsbi4_3d_cam_i2c_l, + gsbi4_3d_cam_i2c_r, gsbi5, gsbi5_3d_cam_i2c_l, + gsbi5_3d_cam_i2c_r, gsbi6, gsbi7, gsbi8, gsbi9, gsbi10, + gsbi11, gsbi11_spi_cs1a_n, gsbi11_spi_cs1b_n, + gsbi11_spi_cs2a_n, gsbi11_spi_cs2b_n, gsbi11_spi_cs3_n, + gsbi12, hdmi_cec, hdmi_ddc_clock, hdmi_ddc_data, + hdmi_hot_plug_detect, hsic, mdp_vsync, mi2s, mic_i2s, + pmb_clk, pmb_ext_ctrl, ps_hold, rpm_wdog, sdc2, sdc4, sdc5, + slimbus1, slimbus2, spkr_i2s, ssbi1, ssbi2, ssbi_ext_gps, + ssbi_pmic2, ssbi_qpa1, ssbi_ts, tsif1, tsif2, ts_eoc, + usb_fs1, usb_fs1_oe, usb_fs1_oe_n, usb_fs2, usb_fs2_oe, + usb_fs2_oe_n, vfe_camif_timer1_a, vfe_camif_timer1_b, + vfe_camif_timer2, vfe_camif_timer3_a, vfe_camif_timer3_b, + vfe_camif_timer4_a, vfe_camif_timer4_b, vfe_camif_timer4_c, + vfe_camif_timer5_a, vfe_camif_timer5_b, vfe_camif_timer6_a, + vfe_camif_timer6_b, vfe_camif_timer6_c, vfe_camif_timer7_a, + vfe_camif_timer7_b, vfe_camif_timer7_c, wlan + +- bias-disable: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as no pull. + +- bias-pull-down: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull down. + +- bias-pull-up: + Usage: optional + Value type: <none> + Definition: The specified pins should be configued as pull up. + +- output-high: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + high. + Not valid for sdc pins. + +- output-low: + Usage: optional + Value type: <none> + Definition: The specified pins are configured in output mode, driven + low. + Not valid for sdc pins. + +- drive-strength: + Usage: optional + Value type: <u32> + Definition: Selects the drive strength for the specified pins, in mA. + Valid values are: 2, 4, 6, 8, 10, 12, 14 and 16 + +Example: + + msmgpio: pinctrl@800000 { + compatible = "qcom,msm8960-pinctrl"; + reg = <0x800000 0x4000>; + + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <0 16 0x4>; + + gsbi8_uart: gsbi8-uart { + mux { + pins = "gpio34", "gpio35"; + function = "gsbi8"; + }; + + tx { + pins = "gpio34"; + drive-strength = <4>; + bias-disable; + }; + + rx { + pins = "gpio35"; + drive-strength = <2>; + bias-pull-up; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt index 73262b575df..d2ea80dc43e 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt @@ -70,7 +70,7 @@ Valid values for function are: cam_mckl0, cam_mclk1, cam_mclk2, cam_mclk3, mdp_vsync, hdmi_cec, hdmi_ddc, hdmi_hpd, edp_hpd, gp_pdm0, gp_pdm1, gp_pdm2, gp_pdm3, gp0_clk, gp1_clk, gp_mn, tsif1, tsif2, hsic, grfc, audio_ref_clk, qua_mi2s, pri_mi2s, spkr_mi2s, - ter_mi2s, sec_mi2s, bt, fm, wlan, slimbus + ter_mi2s, sec_mi2s, bt, fm, wlan, slimbus, gpio (Note that this is not yet the complete list of functions) diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt index 35d2e1f186f..daef6fad6a5 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt @@ -15,6 +15,7 @@ Required Properties: - "renesas,pfc-r8a7778": for R8A7778 (R-Mobile M1) compatible pin-controller. - "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller. - "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller. + - "renesas,pfc-r8a7791": for R8A7791 (R-Car M2) compatible pin-controller. - "renesas,pfc-sh7372": for SH7372 (SH-Mobile AP4) compatible pin-controller. - "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller. diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index cefef741a40..4658b69d4f4 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt @@ -21,6 +21,7 @@ defined as gpio sub-nodes of the pinmux controller. Required properties for iomux controller: - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl" + "rockchip,rk3288-pinctrl" - rockchip,grf: phandle referencing a syscon providing the "general register files" @@ -36,7 +37,7 @@ Deprecated properties for iomux controller: Use rockchip,grf and rockchip,pmu described above instead. Required properties for gpio sub nodes: - - compatible: "rockchip,gpio-bank", "rockchip,rk3188-gpio-bank0" + - compatible: "rockchip,gpio-bank" - reg: register of the gpio bank (different than the iomux registerset) - interrupts: base interrupt of the gpio bank in the interrupt controller - clocks: clock that drives this bank @@ -50,6 +51,7 @@ Required properties for gpio sub nodes: bindings/interrupt-controller/interrupts.txt Deprecated properties for gpio sub nodes: + - compatible: "rockchip,rk3188-gpio-bank0" - reg: second element: separate pull register for rk3188 bank0, use rockchip,pmu described above instead diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index 2b32783ba82..e82aaf49251 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -44,7 +44,11 @@ Required Properties: - Pin mux/config groups as child nodes: The pin mux (selecting pin function mode) and pin config (pull up/down, driver strength) settings are represented as child nodes of the pin-controller node. There should be atleast one - child node and there is no limit on the count of these child nodes. + child node and there is no limit on the count of these child nodes. It is + also possible for a child node to consist of several further child nodes + to allow grouping multiple pinctrl groups into one. The format of second + level child nodes is exactly the same as for first level ones and is + described below. The child node should contain a list of pin(s) on which a particular pin function selection or pin configuration (or both) have to applied. This @@ -71,6 +75,7 @@ Required Properties: "samsung,pins" property of the child node. The following pin configuration properties are supported. + - samsung,pin-val: Initial value of pin output buffer. - samsung,pin-pud: Pull up/down configuration. - samsung,pin-drv: Drive strength configuration. - samsung,pin-pud-pdn: Pull up/down configuration in power down mode. @@ -249,6 +254,23 @@ Example 1: A pin-controller node with pin groups. samsung,pin-pud = <3>; samsung,pin-drv = <0>; }; + + sd4_bus8: sd4-bus-width8 { + part-1 { + samsung,pins = "gpk0-3", "gpk0-4", + "gpk0-5", "gpk0-6"; + samsung,pin-function = <3>; + samsung,pin-pud = <3>; + samsung,pin-drv = <3>; + }; + part-2 { + samsung,pins = "gpk1-3", "gpk1-4", + "gpk1-5", "gpk1-6"; + samsung,pin-function = <4>; + samsung,pin-pud = <4>; + samsung,pin-drv = <3>; + }; + }; }; Example 2: A pin-controller node with external wakeup interrupt controller node. diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt index 700dec4774f..cff38bdbc0e 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt @@ -84,3 +84,19 @@ Example: compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c"; reg = <0x66>; }; + +* Freescale on-board CPLD + +Some Freescale boards like T1040RDB have an on board CPLD connected. + +Required properties: +- compatible: Should be a board-specific string like "fsl,<board>-cpld" + Example: + "fsl,t1040rdb-cpld", "fsl,t1042rdb-cpld", "fsl,t1042rdb_pi-cpld" +- reg: should describe CPLD registers + +Example: + cpld@3,0 { + compatible = "fsl,t1040rdb-cpld"; + reg = <3 0 0x300>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt new file mode 100644 index 00000000000..d47d15a6a29 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.txt @@ -0,0 +1,20 @@ +Rockchip PWM controller + +Required properties: + - compatible: should be "rockchip,<name>-pwm" + "rockchip,rk2928-pwm": found on RK29XX,RK3066 and RK3188 SoCs + "rockchip,rk3288-pwm": found on RK3288 SoC + "rockchip,vop-pwm": found integrated in VOP on RK3288 SoC + - reg: physical base address and length of the controller's registers + - clocks: phandle and clock specifier of the PWM reference clock + - #pwm-cells: should be 2. See pwm.txt in this directory for a + description of the cell format. + +Example: + + pwm0: pwm@20030000 { + compatible = "rockchip,rk2928-pwm"; + reg = <0x20030000 0x10>; + clocks = <&cru PCLK_PWM01>; + #pwm-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-st.txt b/Documentation/devicetree/bindings/pwm/pwm-st.txt new file mode 100644 index 00000000000..84d2fb807d3 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-st.txt @@ -0,0 +1,41 @@ +STMicroelectronics PWM driver bindings +-------------------------------------- + +Required parameters: +- compatible : "st,pwm" +- #pwm-cells : Number of cells used to specify a PWM. First cell + specifies the per-chip index of the PWM to use and the + second cell is the period in nanoseconds - fixed to 2 + for STiH41x. +- reg : Physical base address and length of the controller's + registers. +- pinctrl-names: Set to "default". +- pinctrl-0: List of phandles pointing to pin configuration nodes + for PWM module. + For Pinctrl properties, please refer to [1]. +- clock-names: Set to "pwm". +- clocks: phandle of the clock used by the PWM module. + For Clk properties, please refer to [2]. + +Optional properties: +- st,pwm-num-chan: Number of available channels. If not passed, the driver + will consider single channel by default. + +[1] Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +[2] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Example: + +pwm1: pwm@fe510000 { + compatible = "st,pwm"; + reg = <0xfe510000 0x68>; + #pwm-cells = <2>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pwm1_chan0_default + &pinctrl_pwm1_chan1_default + &pinctrl_pwm1_chan2_default + &pinctrl_pwm1_chan3_default>; + clocks = <&clk_sysin>; + clock-names = "pwm"; + st,pwm-num-chan = <4>; +}; diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt index d290988ed97..20191315e44 100644 --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt @@ -86,7 +86,7 @@ as per the datasheet of s5m8767. - LDOn - valid values for n are 1 to 28 - - Example: LDO1, LD02, LDO28 + - Example: LDO1, LDO2, LDO28 - BUCKn - valid values for n are 1 to 9. - Example: BUCK1, BUCK2, BUCK9 diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt b/Documentation/devicetree/bindings/serial/cdns,uart.txt new file mode 100644 index 00000000000..a3eb154c32c --- /dev/null +++ b/Documentation/devicetree/bindings/serial/cdns,uart.txt @@ -0,0 +1,20 @@ +Binding for Cadence UART Controller + +Required properties: +- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps" +- reg: Should contain UART controller registers location and length. +- interrupts: Should contain UART controller interrupts. +- clocks: Must contain phandles to the UART clocks + See ../clocks/clock-bindings.txt for details. +- clock-names: Tuple to identify input clocks, must contain "uart_clk" and "pclk" + See ../clocks/clock-bindings.txt for details. + + +Example: + uart@e0000000 { + compatible = "cdns,uart-r1p8"; + clocks = <&clkc 23>, <&clkc 40>; + clock-names = "uart_clk", "pclk"; + reg = <0xE0000000 0x1000>; + interrupts = <0 27 4>; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt b/Documentation/devicetree/bindings/spi/spi-samsung.txt index 792efbaedc5..1e8a8578148 100644 --- a/Documentation/devicetree/bindings/spi/spi-samsung.txt +++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt @@ -8,7 +8,6 @@ Required SoC Specific Properties: - compatible: should be one of the following. - samsung,s3c2443-spi: for s3c2443, s3c2416 and s3c2450 platforms - samsung,s3c6410-spi: for s3c6410 platforms - - samsung,s5p6440-spi: for s5p6440 and s5p6450 platforms - samsung,s5pv210-spi: for s5pv210 and s5pc110 platforms - samsung,exynos4210-spi: for exynos4 and exynos5 platforms diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index c94909215c0..ae738f562ac 100644 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@ -3,6 +3,7 @@ ** Required properties: - compatible : One of the following: + "samsung,exynos3250-tmu" "samsung,exynos4412-tmu" "samsung,exynos4210-tmu" "samsung,exynos5250-tmu" diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt index 28ef498a66e..0ef00be44b0 100644 --- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt @@ -1,7 +1,13 @@ * Renesas R-Car Thermal Required properties: -- compatible : "renesas,rcar-thermal" +- compatible : "renesas,thermal-<soctype>", "renesas,rcar-thermal" + as fallback. + Examples with soctypes are: + - "renesas,thermal-r8a73a4" (R-Mobile AP6) + - "renesas,thermal-r8a7779" (R-Car H1) + - "renesas,thermal-r8a7790" (R-Car H2) + - "renesas,thermal-r8a7791" (R-Car M2) - reg : Address range of the thermal registers. The 1st reg will be recognized as common register if it has "interrupts". @@ -12,18 +18,18 @@ Option properties: Example (non interrupt support): -thermal@e61f0100 { - compatible = "renesas,rcar-thermal"; - reg = <0xe61f0100 0x38>; +thermal@ffc48000 { + compatible = "renesas,thermal-r8a7779", "renesas,rcar-thermal"; + reg = <0xffc48000 0x38>; }; Example (interrupt support): thermal@e61f0000 { - compatible = "renesas,rcar-thermal"; + compatible = "renesas,thermal-r8a73a4", "renesas,rcar-thermal"; reg = <0xe61f0000 0x14 0xe61f0100 0x38 0xe61f0200 0x38 0xe61f0300 0x38>; - interrupts = <0 69 4>; + interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>; }; diff --git a/Documentation/devicetree/bindings/thermal/st-thermal.txt b/Documentation/devicetree/bindings/thermal/st-thermal.txt new file mode 100644 index 00000000000..3b9251b4a14 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/st-thermal.txt @@ -0,0 +1,42 @@ +Binding for Thermal Sensor driver for STMicroelectronics STi series of SoCs. + +Required parameters: +------------------- + +compatible : st,<SoC>-<module>-thermal; should be one of: + "st,stih415-sas-thermal", + "st,stih415-mpe-thermal", + "st,stih416-sas-thermal" + "st,stih416-mpe-thermal" + "st,stid127-thermal" or + "st,stih407-thermal" + according to the SoC type (stih415, stih416, stid127, stih407) + and module type (sas or mpe). On stid127 & stih407 there is only + one die/module, so there is no module type in the compatible + string. +clock-names : Should be "thermal". + See: Documentation/devicetree/bindings/resource-names.txt +clocks : Phandle of the clock used by the thermal sensor. + See: Documentation/devicetree/bindings/clock/clock-bindings.txt + +Optional parameters: +------------------- + +reg : For non-sysconf based sensors, this should be the physical base + address and length of the sensor's registers. +interrupts : Standard way to define interrupt number. + Interrupt is mandatory to be defined when compatible is + "stih416-mpe-thermal". + NB: For thermal sensor's for which no interrupt has been + defined, a polling delay of 1000ms will be used to read the + temperature from device. + +Example: + + temp1@fdfe8000 { + compatible = "st,stih416-mpe-thermal"; + reg = <0xfdfe8000 0x10>; + clock-names = "thermal"; + clocks = <&clk_m_mpethsens>; + interrupts = <GIC_SPI 23 IRQ_TYPE_NONE>; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index d415b38ec8c..ac7269f9076 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -6,6 +6,7 @@ using them to avoid name-space collisions. abilis Abilis Systems active-semi Active-Semi International Inc ad Avionic Design GmbH +adapteva Adapteva, Inc. adi Analog Devices, Inc. aeroflexgaisler Aeroflex Gaisler AB ak Asahi Kasei Corp. @@ -72,6 +73,7 @@ karo Ka-Ro electronics GmbH keymile Keymile GmbH lacie LaCie lantiq Lantiq Semiconductor +lenovo Lenovo Group Ltd. lg LG Corporation linux Linux-specific binding lsi LSI Corp. (LSI Logic) @@ -101,6 +103,7 @@ panasonic Panasonic Corporation phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd plathome Plat'Home Co., Ltd. +pixcir PIXCIR MICROELECTRONICS Co., Ltd powervr PowerVR (deprecated, use img) qca Qualcomm Atheros, Inc. qcom Qualcomm Technologies, Inc @@ -124,6 +127,7 @@ sii Seiko Instruments, Inc. sirf SiRF Technology, Inc. smsc Standard Microsystems Corporation snps Synopsys, Inc. +solidrun SolidRun spansion Spansion Inc. st STMicroelectronics ste ST-Ericsson diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt new file mode 100644 index 00000000000..3e3039a8a25 --- /dev/null +++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt @@ -0,0 +1,109 @@ +* ARM PrimeCell Color LCD Controller PL110/PL111 + +See also Documentation/devicetree/bindings/arm/primecell.txt + +Required properties: + +- compatible: must be one of: + "arm,pl110", "arm,primecell" + "arm,pl111", "arm,primecell" + +- reg: base address and size of the control registers block + +- interrupt-names: either the single entry "combined" representing a + combined interrupt output (CLCDINTR), or the four entries + "mbe", "vcomp", "lnbu", "fuf" representing the individual + CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts + +- interrupts: contains an interrupt specifier for each entry in + interrupt-names + +- clock-names: should contain "clcdclk" and "apb_pclk" + +- clocks: contains phandle and clock specifier pairs for the entries + in the clock-names property. See + Documentation/devicetree/binding/clock/clock-bindings.txt + +Optional properties: + +- memory-region: phandle to a node describing memory (see + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) + to be used for the framebuffer; if not present, the framebuffer + may be located anywhere in the memory + +- max-memory-bandwidth: maximum bandwidth in bytes per second that the + cell's memory interface can handle; if not present, the memory + interface is fast enough to handle all possible video modes + +Required sub-nodes: + +- port: describes LCD panel signals, following the common binding + for video transmitter interfaces; see + Documentation/devicetree/bindings/media/video-interfaces.txt; + when it is a TFT panel, the port's endpoint must define the + following property: + + - arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values, + defining the way CLD pads are wired up; first value + contains index of the "CLD" external pin (pad) used + as R0 (first bit of the red component), second value + index of the pad used as G0, third value index of the + pad used as B0, see also "LCD panel signal multiplexing + details" paragraphs in the PL110/PL111 Technical + Reference Manuals; this implicitly defines available + color modes, for example: + - PL111 TFT 4:4:4 panel: + arm,pl11x,tft-r0g0b0-pads = <4 15 20>; + - PL110 TFT (1:)5:5:5 panel: + arm,pl11x,tft-r0g0b0-pads = <1 7 13>; + - PL111 TFT (1:)5:5:5 panel: + arm,pl11x,tft-r0g0b0-pads = <3 11 19>; + - PL111 TFT 5:6:5 panel: + arm,pl11x,tft-r0g0b0-pads = <3 10 19>; + - PL110 and PL111 TFT 8:8:8 panel: + arm,pl11x,tft-r0g0b0-pads = <0 8 16>; + - PL110 and PL111 TFT 8:8:8 panel, R & B components swapped: + arm,pl11x,tft-r0g0b0-pads = <16 8 0>; + + +Example: + + clcd@10020000 { + compatible = "arm,pl111", "arm,primecell"; + reg = <0x10020000 0x1000>; + interrupt-names = "combined"; + interrupts = <0 44 4>; + clocks = <&oscclk1>, <&oscclk2>; + clock-names = "clcdclk", "apb_pclk"; + max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */ + + port { + clcd_pads: endpoint { + remote-endpoint = <&clcd_panel>; + arm,pl11x,tft-r0g0b0-pads = <0 8 16>; + }; + }; + + }; + + panel { + compatible = "panel-dpi"; + + port { + clcd_panel: endpoint { + remote-endpoint = <&clcd_pads>; + }; + }; + + panel-timing { + clock-frequency = <25175000>; + hactive = <640>; + hback-porch = <40>; + hfront-porch = <24>; + hsync-len = <96>; + vactive = <480>; + vback-porch = <32>; + vfront-porch = <11>; + vsync-len = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt b/Documentation/devicetree/bindings/video/atmel,lcdc.txt index 1ec175eddca..b75af94a5e5 100644 --- a/Documentation/devicetree/bindings/video/atmel,lcdc.txt +++ b/Documentation/devicetree/bindings/video/atmel,lcdc.txt @@ -46,6 +46,7 @@ Required properties (as per of_videomode_helper): Optional properties (as per of_videomode_helper): - atmel,lcdcon-backlight: enable backlight + - atmel,lcdcon-backlight-inverted: invert backlight PWM polarity - atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG" - atmel,power-control-gpio: gpio to power on or off the LCD (as many as needed) diff --git a/Documentation/devicetree/bindings/video/cirrus,clps711x-fb.txt b/Documentation/devicetree/bindings/video/cirrus,clps711x-fb.txt new file mode 100644 index 00000000000..6fc3c6adeef --- /dev/null +++ b/Documentation/devicetree/bindings/video/cirrus,clps711x-fb.txt @@ -0,0 +1,47 @@ +* Currus Logic CLPS711X Framebuffer + +Required properties: +- compatible: Shall contain "cirrus,clps711x-fb". +- reg : Physical base address and length of the controller's registers + + location and size of the framebuffer memory. +- clocks : phandle + clock specifier pair of the FB reference clock. +- display : phandle to a display node as described in + Documentation/devicetree/bindings/video/display-timing.txt. + Additionally, the display node has to define properties: + - bits-per-pixel: Bits per pixel. + - ac-prescale : LCD AC bias frequency. This frequency is the required + AC bias frequency for a given manufacturer's LCD plate. + - cmap-invert : Invert the color levels (Optional). + +Optional properties: +- lcd-supply: Regulator for LCD supply voltage. + +Example: + fb: fb@800002c0 { + compatible = "cirrus,ep7312-fb", "cirrus,clps711x-fb"; + reg = <0x800002c0 0xd44>, <0x60000000 0xc000>; + clocks = <&clks 2>; + lcd-supply = <®5v0>; + display = <&display>; + }; + + display: display { + model = "320x240x4"; + native-mode = <&timing0>; + bits-per-pixel = <4>; + ac-prescale = <17>; + + display-timings { + timing0: 320x240 { + hactive = <320>; + hback-porch = <0>; + hfront-porch = <0>; + hsync-len = <0>; + vactive = <240>; + vback-porch = <0>; + vfront-porch = <0>; + vsync-len = <0>; + clock-frequency = <6500000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt b/Documentation/devicetree/bindings/video/exynos_dsim.txt index 33b5730d07b..31036c667d5 100644 --- a/Documentation/devicetree/bindings/video/exynos_dsim.txt +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt @@ -1,7 +1,9 @@ Exynos MIPI DSI Master Required properties: - - compatible: "samsung,exynos4210-mipi-dsi" + - compatible: value should be one of the following + "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */ + "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */ - reg: physical base address and length of the registers set for the device - interrupts: should contain DSI interrupt - clocks: list of clock specifiers, must contain an entry for each required diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt b/Documentation/devicetree/bindings/video/exynos_mixer.txt index 7bfde9c9d65..08b394b1edb 100644 --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt @@ -4,8 +4,9 @@ Required properties: - compatible: value should be one of the following: 1) "samsung,exynos5-mixer" <DEPRECATED> 2) "samsung,exynos4210-mixer" - 3) "samsung,exynos5250-mixer" - 4) "samsung,exynos5420-mixer" + 3) "samsung,exynos4212-mixer" + 4) "samsung,exynos5250-mixer" + 5) "samsung,exynos5420-mixer" - reg: physical base address of the mixer and length of memory mapped region. diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt index 2dad41b689a..ecc899b9817 100644 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt @@ -8,8 +8,6 @@ Required properties: - compatible: value should be one of the following "samsung,s3c2443-fimd"; /* for S3C24XX SoCs */ "samsung,s3c6400-fimd"; /* for S3C64XX SoCs */ - "samsung,s5p6440-fimd"; /* for S5P64X0 SoCs */ - "samsung,s5pc100-fimd"; /* for S5PC100 SoC */ "samsung,s5pv210-fimd"; /* for S5PV210 SoC */ "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */ "samsung,exynos5250-fimd"; /* for Exynos5 SoCs */ @@ -44,6 +42,34 @@ Optional Properties: - display-timings: timing settings for FIMD, as described in document [1]. Can be used in case timings cannot be provided otherwise or to override timings provided by the panel. +- samsung,sysreg: handle to syscon used to control the system registers +- i80-if-timings: timing configuration for lcd i80 interface support. + - cs-setup: clock cycles for the active period of address signal is enabled + until chip select is enabled. + If not specified, the default value(0) will be used. + - wr-setup: clock cycles for the active period of CS signal is enabled until + write signal is enabled. + If not specified, the default value(0) will be used. + - wr-active: clock cycles for the active period of CS is enabled. + If not specified, the default value(1) will be used. + - wr-hold: clock cycles for the active period of CS is disabled until write + signal is disabled. + If not specified, the default value(0) will be used. + + The parameters are defined as: + + VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|?? + : : : : : + Address Output --:<XXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XX + | cs-setup+1 | : : : + |<---------->| : : : + Chip Select ???????????????|____________:____________:____________|?? + | wr-setup+1 | | wr-hold+1 | + |<---------->| |<---------->| + Write Enable ????????????????????????????|____________|??????????????? + | wr-active+1| + |<---------->| + Video Data ----------------------------<XXXXXXXXXXXXXXXXXXXXXXXXX>-- The device node can contain 'port' child nodes according to the bindings defined in [2]. The following are properties specific to those nodes: diff --git a/Documentation/dmaengine.txt b/Documentation/dmaengine.txt index 879b6e31e2d..573e28ce975 100644 --- a/Documentation/dmaengine.txt +++ b/Documentation/dmaengine.txt @@ -84,31 +84,32 @@ The slave DMA usage consists of following steps: the given transaction. Interface: - struct dma_async_tx_descriptor *(*chan->device->device_prep_slave_sg)( + struct dma_async_tx_descriptor *dmaengine_prep_slave_sg( struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len, enum dma_data_direction direction, unsigned long flags); - struct dma_async_tx_descriptor *(*chan->device->device_prep_dma_cyclic)( + struct dma_async_tx_descriptor *dmaengine_prep_dma_cyclic( struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len, size_t period_len, enum dma_data_direction direction); - struct dma_async_tx_descriptor *(*device_prep_interleaved_dma)( + struct dma_async_tx_descriptor *dmaengine_prep_interleaved_dma( struct dma_chan *chan, struct dma_interleaved_template *xt, unsigned long flags); The peripheral driver is expected to have mapped the scatterlist for the DMA operation prior to calling device_prep_slave_sg, and must keep the scatterlist mapped until the DMA operation has completed. - The scatterlist must be mapped using the DMA struct device. So, - normal setup should look like this: + The scatterlist must be mapped using the DMA struct device. + If a mapping needs to be synchronized later, dma_sync_*_for_*() must be + called using the DMA struct device, too. + So, normal setup should look like this: nr_sg = dma_map_sg(chan->device->dev, sgl, sg_len); if (nr_sg == 0) /* error */ - desc = chan->device->device_prep_slave_sg(chan, sgl, nr_sg, - direction, flags); + desc = dmaengine_prep_slave_sg(chan, sgl, nr_sg, direction, flags); Once a descriptor has been obtained, the callback information can be added and the descriptor must then be submitted. Some DMA engine @@ -188,7 +189,7 @@ Further APIs: description of this API. This can be used in conjunction with dma_async_is_complete() and - the cookie returned from 'descriptor->submit()' to check for + the cookie returned from dmaengine_submit() to check for completion of a specific DMA transaction. Note: diff --git a/Documentation/filesystems/cifs/AUTHORS b/Documentation/filesystems/cifs/AUTHORS index ca4a67a0bb1..c98800df677 100644 --- a/Documentation/filesystems/cifs/AUTHORS +++ b/Documentation/filesystems/cifs/AUTHORS @@ -40,6 +40,7 @@ Gunter Kukkukk (testing and suggestions for support of old servers) Igor Mammedov (DFS support) Jeff Layton (many, many fixes, as well as great work on the cifs Kerberos code) Scott Lovenberg +Pavel Shilovsky (for great work adding SMB2 support, and various SMB3 features) Test case and Bug Report contributors ------------------------------------- diff --git a/Documentation/filesystems/cifs/TODO b/Documentation/filesystems/cifs/TODO index 355abcdcda9..066ffddc396 100644 --- a/Documentation/filesystems/cifs/TODO +++ b/Documentation/filesystems/cifs/TODO @@ -1,4 +1,4 @@ -Version 1.53 May 20, 2008 +Version 2.03 August 1, 2014 A Partial List of Missing Features ================================== @@ -7,63 +7,49 @@ Contributions are welcome. There are plenty of opportunities for visible, important contributions to this module. Here is a partial list of the known problems and missing features: -a) Support for SecurityDescriptors(Windows/CIFS ACLs) for chmod/chgrp/chown -so that these operations can be supported to Windows servers +a) SMB3 (and SMB3.02) missing optional features: + - RDMA + - multichannel (started) + - directory leases (improved metadata caching) + - T10 copy offload (copy chunk is only mechanism supported) + - encrypted shares -b) Mapping POSIX ACLs (and eventually NFSv4 ACLs) to CIFS -SecurityDescriptors +b) improved sparse file support -c) Better pam/winbind integration (e.g. to handle uid mapping -better) - -d) Cleanup now unneeded SessSetup code in -fs/cifs/connect.c and add back in NTLMSSP code if any servers -need it - -e) fix NTLMv2 signing when two mounts with different users to same -server. - -f) Directory entry caching relies on a 1 second timer, rather than +c) Directory entry caching relies on a 1 second timer, rather than using FindNotify or equivalent. - (started) -g) quota support (needs minor kernel change since quota calls +d) quota support (needs minor kernel change since quota calls to make it to network filesystems or deviceless filesystems) -h) investigate sync behavior (including syncpage) and check -for proper behavior of intr/nointr - -i) improve support for very old servers (OS/2 and Win9x for example) +e) improve support for very old servers (OS/2 and Win9x for example) Including support for changing the time remotely (utimes command). -j) hook lower into the sockets api (as NFS/SunRPC does) to avoid the +f) hook lower into the sockets api (as NFS/SunRPC does) to avoid the extra copy in/out of the socket buffers in some cases. -k) Better optimize open (and pathbased setfilesize) to reduce the +g) Better optimize open (and pathbased setfilesize) to reduce the oplock breaks coming from windows srv. Piggyback identical file opens on top of each other by incrementing reference count rather than resending (helps reduce server resource utilization and avoid spurious oplock breaks). -l) Improve performance of readpages by sending more than one read -at a time when 8 pages or more are requested. In conjuntion -add support for async_cifs_readpages. - -m) Add support for storing symlink info to Windows servers +h) Add support for storing symlink info to Windows servers in the Extended Attribute format their SFU clients would recognize. -n) Finish fcntl D_NOTIFY support so kde and gnome file list windows +i) Finish inotify support so kde and gnome file list windows will autorefresh (partially complete by Asser). Needs minor kernel vfs change to support removing D_NOTIFY on a file. -o) Add GUI tool to configure /proc/fs/cifs settings and for display of +j) Add GUI tool to configure /proc/fs/cifs settings and for display of the CIFS statistics (started) -p) implement support for security and trusted categories of xattrs +k) implement support for security and trusted categories of xattrs (requires minor protocol extension) to enable better support for SELINUX -q) Implement O_DIRECT flag on open (already supported on mount) +l) Implement O_DIRECT flag on open (already supported on mount) -r) Create UID mapping facility so server UIDs can be mapped on a per +m) Create UID mapping facility so server UIDs can be mapped on a per mount or a per server basis to client UIDs or nobody if no mapping exists. This is helpful when Unix extensions are negotiated to allow better permission checking when UIDs differ on the server @@ -71,28 +57,29 @@ and client. Add new protocol request to the CIFS protocol standard for asking the server for the corresponding name of a particular uid. -s) Add support for CIFS Unix and also the newer POSIX extensions to the -server side for Samba 4. +n) DOS attrs - returned as pseudo-xattr in Samba format (check VFAT and NTFS for this too) + +o) mount check for unmatched uids -t) In support for OS/2 (LANMAN 1.2 and LANMAN2.1 based SMB servers) -need to add ability to set time to server (utimes command) +p) Add support for new vfs entry point for fallocate -u) DOS attrs - returned as pseudo-xattr in Samba format (check VFAT and NTFS for this too) +q) Add tools to take advantage of cifs/smb3 specific ioctls and features +such as "CopyChunk" (fast server side file copy) -v) mount check for unmatched uids +r) encrypted file support -w) Add support for new vfs entry point for fallocate +s) improved stats gathering, tools (perhaps integration with nfsometer?) -x) Fix Samba 3 server to handle Linux kernel aio so dbench with lots of -processes can proceed better in parallel (on the server) +t) allow setting more NTFS/SMB3 file attributes remotely (currently limited to compressed +file attribute via chflags) -y) Fix Samba 3 to handle reads/writes over 127K (and remove the cifs mount -restriction of wsize max being 127K) +u) mount helper GUI (to simplify the various configuration options on mount) -KNOWN BUGS (updated April 24, 2007) + +KNOWN BUGS ==================================== See http://bugzilla.samba.org - search on product "CifsVFS" for -current bug list. +current bug list. Also check http://bugzilla.kernel.org (Product = File System, Component = CIFS) 1) existing symbolic links (Windows reparse points) are recognized but can not be created remotely. They are implemented for Samba and those that @@ -100,30 +87,18 @@ support the CIFS Unix extensions, although earlier versions of Samba overly restrict the pathnames. 2) follow_link and readdir code does not follow dfs junctions but recognizes them -3) create of new files to FAT partitions on Windows servers can -succeed but still return access denied (appears to be Windows -server not cifs client problem) and has not been reproduced recently. -NTFS partitions do not have this problem. -4) Unix/POSIX capabilities are reset after reconnection, and affect -a few fields in the tree connection but we do do not know which -superblocks to apply these changes to. We should probably walk -the list of superblocks to set these. Also need to check the -flags on the second mount to the same share, and see if we -can do the same trick that NFS does to remount duplicate shares. Misc testing to do ================== 1) check out max path names and max path name components against various server types. Try nested symlinks (8 deep). Return max path name in stat -f information -2) Modify file portion of ltp so it can run against a mounted network -share and run it against cifs vfs in automated fashion. +2) Improve xfstest's cifs enablement and adapt xfstests where needed to test +cifs better 3) Additional performance testing and optimization using iozone and similar - there are some easy changes that can be done to parallelize sequential writes, and when signing is disabled to request larger read sizes (larger than negotiated size) and send larger write sizes to modern servers. -4) More exhaustively test against less common servers. More testing -against Windows 9x, Windows ME servers. - +4) More exhaustively test against less common servers diff --git a/Documentation/filesystems/nfs/Exporting b/Documentation/filesystems/nfs/Exporting index e543b1a619c..c8f036a9b13 100644 --- a/Documentation/filesystems/nfs/Exporting +++ b/Documentation/filesystems/nfs/Exporting @@ -66,23 +66,31 @@ b/ A per-superblock list "s_anon" of dentries which are the roots of c/ Helper routines to allocate anonymous dentries, and to help attach loose directory dentries at lookup time. They are: - d_alloc_anon(inode) will return a dentry for the given inode. + d_obtain_alias(inode) will return a dentry for the given inode. If the inode already has a dentry, one of those is returned. If it doesn't, a new anonymous (IS_ROOT and DCACHE_DISCONNECTED) dentry is allocated and attached. In the case of a directory, care is taken that only one dentry can ever be attached. - d_splice_alias(inode, dentry) will make sure that there is a - dentry with the same name and parent as the given dentry, and - which refers to the given inode. - If the inode is a directory and already has a dentry, then that - dentry is d_moved over the given dentry. - If the passed dentry gets attached, care is taken that this is - mutually exclusive to a d_alloc_anon operation. - If the passed dentry is used, NULL is returned, else the used - dentry is returned. This corresponds to the calling pattern of - ->lookup. - + d_splice_alias(inode, dentry) or d_materialise_unique(dentry, inode) + will introduce a new dentry into the tree; either the passed-in + dentry or a preexisting alias for the given inode (such as an + anonymous one created by d_obtain_alias), if appropriate. The two + functions differ in their handling of directories with preexisting + aliases: + d_splice_alias will use any existing IS_ROOT dentry, but it will + return -EIO rather than try to move a dentry with a different + parent. This is appropriate for local filesystems, which + should never see such an alias unless the filesystem is + corrupted somehow (for example, if two on-disk directory + entries refer to the same directory.) + d_materialise_unique will attempt to move any dentry. This is + appropriate for distributed filesystems, where finding a + directory other than where we last cached it may be a normal + consequence of concurrent operations on other hosts. + Both functions return NULL when the passed-in dentry is used, + following the calling convention of ->lookup. + Filesystem Issues ----------------- @@ -120,12 +128,12 @@ struct which has the following members: fh_to_dentry (mandatory) Given a filehandle fragment, this should find the implied object and - create a dentry for it (possibly with d_alloc_anon). + create a dentry for it (possibly with d_obtain_alias). fh_to_parent (optional but strongly recommended) Given a filehandle fragment, this should find the parent of the - implied object and create a dentry for it (possibly with d_alloc_anon). - May fail if the filehandle fragment is too small. + implied object and create a dentry for it (possibly with + d_obtain_alias). May fail if the filehandle fragment is too small. get_parent (optional but strongly recommended) When given a dentry for a directory, this should return a dentry for diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index a1d0d7a3016..61d65cc65c5 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -1053,7 +1053,8 @@ struct dentry_operations { If the 'rcu_walk' parameter is true, then the caller is doing a pathwalk in RCU-walk mode. Sleeping is not permitted in this mode, and the caller can be asked to leave it and call again by returning - -ECHILD. + -ECHILD. -EISDIR may also be returned to tell pathwalk to + ignore d_automount or any mounts. This function is only used if DCACHE_MANAGE_TRANSIT is set on the dentry being transited from. diff --git a/Documentation/gpio/board.txt b/Documentation/gpio/board.txt index ba169faad5c..4452786225b 100644 --- a/Documentation/gpio/board.txt +++ b/Documentation/gpio/board.txt @@ -60,7 +60,7 @@ Platform Data Finally, GPIOs can be bound to devices and functions using platform data. Board files that desire to do so need to include the following header: - #include <linux/gpio/driver.h> + #include <linux/gpio/machine.h> GPIOs are mapped by the means of tables of lookups, containing instances of the gpiod_lookup structure. Two macros are defined to help declaring such mappings: diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt index d8abfc31abb..76546324e96 100644 --- a/Documentation/gpio/consumer.txt +++ b/Documentation/gpio/consumer.txt @@ -29,13 +29,24 @@ gpiod_get() functions. Like many other kernel subsystems, gpiod_get() takes the device that will use the GPIO and the function the requested GPIO is supposed to fulfill: - struct gpio_desc *gpiod_get(struct device *dev, const char *con_id) + struct gpio_desc *gpiod_get(struct device *dev, const char *con_id, + enum gpiod_flags flags) If a function is implemented by using several GPIOs together (e.g. a simple LED device that displays digits), an additional index argument can be specified: struct gpio_desc *gpiod_get_index(struct device *dev, - const char *con_id, unsigned int idx) + const char *con_id, unsigned int idx, + enum gpiod_flags flags) + +The flags parameter is used to optionally specify a direction and initial value +for the GPIO. Values can be: + +* GPIOD_ASIS or 0 to not initialize the GPIO at all. The direction must be set + later with one of the dedicated functions. +* GPIOD_IN to initialize the GPIO as input. +* GPIOD_OUT_LOW to initialize the GPIO as output with a value of 0. +* GPIOD_OUT_HIGH to initialize the GPIO as output with a value of 1. Both functions return either a valid GPIO descriptor, or an error code checkable with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned @@ -46,11 +57,13 @@ errors and an absence of GPIO for optional GPIO parameters. Device-managed variants of these functions are also defined: - struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id) + struct gpio_desc *devm_gpiod_get(struct device *dev, const char *con_id, + enum gpiod_flags flags) struct gpio_desc *devm_gpiod_get_index(struct device *dev, const char *con_id, - unsigned int idx) + unsigned int idx, + enum gpiod_flags flags) A GPIO descriptor can be disposed of using the gpiod_put() function: @@ -67,8 +80,9 @@ Using GPIOs Setting Direction ----------------- -The first thing a driver must do with a GPIO is setting its direction. This is -done by invoking one of the gpiod_direction_*() functions: +The first thing a driver must do with a GPIO is setting its direction. If no +direction-setting flags have been given to gpiod_get*(), this is done by +invoking one of the gpiod_direction_*() functions: int gpiod_direction_input(struct gpio_desc *desc) int gpiod_direction_output(struct gpio_desc *desc, int value) diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index fa9a0a8b373..18790c23797 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -157,13 +157,34 @@ Locking IRQ usage Input GPIOs can be used as IRQ signals. When this happens, a driver is requested to mark the GPIO as being used as an IRQ: - int gpiod_lock_as_irq(struct gpio_desc *desc) + int gpio_lock_as_irq(struct gpio_chip *chip, unsigned int offset) This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock is released: - void gpiod_unlock_as_irq(struct gpio_desc *desc) + void gpio_unlock_as_irq(struct gpio_chip *chip, unsigned int offset) When implementing an irqchip inside a GPIO driver, these two functions should typically be called in the .startup() and .shutdown() callbacks from the irqchip. + + +Requesting self-owned GPIO pins +------------------------------- + +Sometimes it is useful to allow a GPIO chip driver to request its own GPIO +descriptors through the gpiolib API. Using gpio_request() for this purpose +does not help since it pins the module to the kernel forever (it calls +try_module_get()). A GPIO driver can use the following functions instead +to request and free descriptors without being pinned to the kernel forever. + + int gpiochip_request_own_desc(struct gpio_desc *desc, const char *label) + + void gpiochip_free_own_desc(struct gpio_desc *desc) + +Descriptors requested with gpiochip_request_own_desc() must be released with +gpiochip_free_own_desc(). + +These functions must be used with care since they do not affect module use +count. Do not use the functions to request gpio descriptors not owned by the +calling driver. diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index adf5e33e831..e9c803ea306 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -25,6 +25,7 @@ Supported adapters: * Intel Avoton (SOC) * Intel Wellsburg (PCH) * Intel Coleto Creek (PCH) + * Intel Wildcat Point (PCH) * Intel Wildcat Point-LP (PCH) * Intel BayTrail (SOC) Datasheets: Publicly available at the Intel website diff --git a/Documentation/i2c/i2c-stub b/Documentation/i2c/i2c-stub index fa4b669c166..a16924fbd28 100644 --- a/Documentation/i2c/i2c-stub +++ b/Documentation/i2c/i2c-stub @@ -2,9 +2,9 @@ MODULE: i2c-stub DESCRIPTION: -This module is a very simple fake I2C/SMBus driver. It implements five +This module is a very simple fake I2C/SMBus driver. It implements six types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w) -word data, and (r/w) I2C block data. +word data, (r/w) I2C block data, and (r/w) SMBus block data. You need to provide chip addresses as a module parameter when loading this driver, which will then only react to SMBus commands to these addresses. @@ -19,6 +19,14 @@ A pointer register with auto-increment is implemented for all byte operations. This allows for continuous byte reads like those supported by EEPROMs, among others. +SMBus block command support is disabled by default, and must be enabled +explicitly by setting the respective bits (0x03000000) in the functionality +module parameter. + +SMBus block commands must be written to configure an SMBus command for +SMBus block operations. Writes can be partial. Block read commands always +return the number of bytes selected with the largest write so far. + The typical use-case is like this: 1. load this module 2. use i2cset (from the i2c-tools project) to pre-load some data @@ -39,15 +47,18 @@ unsigned long functionality: value 0x1f0000 would only enable the quick, byte and byte data commands. +u8 bank_reg[10] +u8 bank_mask[10] +u8 bank_start[10] +u8 bank_end[10]: + Optional bank settings. They tell which bits in which register + select the active bank, as well as the range of banked registers. + CAVEATS: If your target driver polls some byte or word waiting for it to change, the stub could lock it up. Use i2cset to unlock it. -If the hardware for your driver has banked registers (e.g. Winbond sensors -chips) this module will not work well - although it could be extended to -support that pretty easily. - If you spam it hard enough, printk can be lossy. This module really wants something like relayfs. diff --git a/Documentation/ioctl/00-INDEX b/Documentation/ioctl/00-INDEX index d2fe4d4729e..c1a92578795 100644 --- a/Documentation/ioctl/00-INDEX +++ b/Documentation/ioctl/00-INDEX @@ -1,5 +1,7 @@ 00-INDEX - this file +botching-up-ioctls.txt + - how to avoid botching up ioctls cdrom.txt - summary of CDROM ioctl calls hdio.txt diff --git a/Documentation/ioctl/botching-up-ioctls.txt b/Documentation/ioctl/botching-up-ioctls.txt new file mode 100644 index 00000000000..45fe78c5801 --- /dev/null +++ b/Documentation/ioctl/botching-up-ioctls.txt @@ -0,0 +1,219 @@ +(How to avoid) Botching up ioctls +================================= + +From: http://blog.ffwll.ch/2013/11/botching-up-ioctls.html + +By: Daniel Vetter, Copyright © 2013 Intel Corporation + +One clear insight kernel graphics hackers gained in the past few years is that +trying to come up with a unified interface to manage the execution units and +memory on completely different GPUs is a futile effort. So nowadays every +driver has its own set of ioctls to allocate memory and submit work to the GPU. +Which is nice, since there's no more insanity in the form of fake-generic, but +actually only used once interfaces. But the clear downside is that there's much +more potential to screw things up. + +To avoid repeating all the same mistakes again I've written up some of the +lessons learned while botching the job for the drm/i915 driver. Most of these +only cover technicalities and not the big-picture issues like what the command +submission ioctl exactly should look like. Learning these lessons is probably +something every GPU driver has to do on its own. + + +Prerequisites +------------- + +First the prerequisites. Without these you have already failed, because you +will need to add a a 32-bit compat layer: + + * Only use fixed sized integers. To avoid conflicts with typedefs in userspace + the kernel has special types like __u32, __s64. Use them. + + * Align everything to the natural size and use explicit padding. 32-bit + platforms don't necessarily align 64-bit values to 64-bit boundaries, but + 64-bit platforms do. So we always need padding to the natural size to get + this right. + + * Pad the entire struct to a multiple of 64-bits - the structure size will + otherwise differ on 32-bit versus 64-bit. Having a different structure size + hurts when passing arrays of structures to the kernel, or if the kernel + checks the structure size, which e.g. the drm core does. + + * Pointers are __u64, cast from/to a uintprt_t on the userspace side and + from/to a void __user * in the kernel. Try really hard not to delay this + conversion or worse, fiddle the raw __u64 through your code since that + diminishes the checking tools like sparse can provide. + + +Basics +------ + +With the joys of writing a compat layer avoided we can take a look at the basic +fumbles. Neglecting these will make backward and forward compatibility a real +pain. And since getting things wrong on the first attempt is guaranteed you +will have a second iteration or at least an extension for any given interface. + + * Have a clear way for userspace to figure out whether your new ioctl or ioctl + extension is supported on a given kernel. If you can't rely on old kernels + rejecting the new flags/modes or ioctls (since doing that was botched in the + past) then you need a driver feature flag or revision number somewhere. + + * Have a plan for extending ioctls with new flags or new fields at the end of + the structure. The drm core checks the passed-in size for each ioctl call + and zero-extends any mismatches between kernel and userspace. That helps, + but isn't a complete solution since newer userspace on older kernels won't + notice that the newly added fields at the end get ignored. So this still + needs a new driver feature flags. + + * Check all unused fields and flags and all the padding for whether it's 0, + and reject the ioctl if that's not the case. Otherwise your nice plan for + future extensions is going right down the gutters since someone will submit + an ioctl struct with random stack garbage in the yet unused parts. Which + then bakes in the ABI that those fields can never be used for anything else + but garbage. + + * Have simple testcases for all of the above. + + +Fun with Error Paths +-------------------- + +Nowadays we don't have any excuse left any more for drm drivers being neat +little root exploits. This means we both need full input validation and solid +error handling paths - GPUs will die eventually in the oddmost corner cases +anyway: + + * The ioctl must check for array overflows. Also it needs to check for + over/underflows and clamping issues of integer values in general. The usual + example is sprite positioning values fed directly into the hardware with the + hardware just having 12 bits or so. Works nicely until some odd display + server doesn't bother with clamping itself and the cursor wraps around the + screen. + + * Have simple testcases for every input validation failure case in your ioctl. + Check that the error code matches your expectations. And finally make sure + that you only test for one single error path in each subtest by submitting + otherwise perfectly valid data. Without this an earlier check might reject + the ioctl already and shadow the codepath you actually want to test, hiding + bugs and regressions. + + * Make all your ioctls restartable. First X really loves signals and second + this will allow you to test 90% of all error handling paths by just + interrupting your main test suite constantly with signals. Thanks to X's + love for signal you'll get an excellent base coverage of all your error + paths pretty much for free for graphics drivers. Also, be consistent with + how you handle ioctl restarting - e.g. drm has a tiny drmIoctl helper in its + userspace library. The i915 driver botched this with the set_tiling ioctl, + now we're stuck forever with some arcane semantics in both the kernel and + userspace. + + * If you can't make a given codepath restartable make a stuck task at least + killable. GPUs just die and your users won't like you more if you hang their + entire box (by means of an unkillable X process). If the state recovery is + still too tricky have a timeout or hangcheck safety net as a last-ditch + effort in case the hardware has gone bananas. + + * Have testcases for the really tricky corner cases in your error recovery code + - it's way too easy to create a deadlock between your hangcheck code and + waiters. + + +Time, Waiting and Missing it +---------------------------- + +GPUs do most everything asynchronously, so we have a need to time operations and +wait for oustanding ones. This is really tricky business; at the moment none of +the ioctls supported by the drm/i915 get this fully right, which means there's +still tons more lessons to learn here. + + * Use CLOCK_MONOTONIC as your reference time, always. It's what alsa, drm and + v4l use by default nowadays. But let userspace know which timestamps are + derived from different clock domains like your main system clock (provided + by the kernel) or some independent hardware counter somewhere else. Clocks + will mismatch if you look close enough, but if performance measuring tools + have this information they can at least compensate. If your userspace can + get at the raw values of some clocks (e.g. through in-command-stream + performance counter sampling instructions) consider exposing those also. + + * Use __s64 seconds plus __u64 nanoseconds to specify time. It's not the most + convenient time specification, but it's mostly the standard. + + * Check that input time values are normalized and reject them if not. Note + that the kernel native struct ktime has a signed integer for both seconds + and nanoseconds, so beware here. + + * For timeouts, use absolute times. If you're a good fellow and made your + ioctl restartable relative timeouts tend to be too coarse and can + indefinitely extend your wait time due to rounding on each restart. + Especially if your reference clock is something really slow like the display + frame counter. With a spec laywer hat on this isn't a bug since timeouts can + always be extended - but users will surely hate you if their neat animations + starts to stutter due to this. + + * Consider ditching any synchronous wait ioctls with timeouts and just deliver + an asynchronous event on a pollable file descriptor. It fits much better + into event driven applications' main loop. + + * Have testcases for corner-cases, especially whether the return values for + already-completed events, successful waits and timed-out waits are all sane + and suiting to your needs. + + +Leaking Resources, Not +---------------------- + +A full-blown drm driver essentially implements a little OS, but specialized to +the given GPU platforms. This means a driver needs to expose tons of handles +for different objects and other resources to userspace. Doing that right +entails its own little set of pitfalls: + + * Always attach the lifetime of your dynamically created resources to the + lifetime of a file descriptor. Consider using a 1:1 mapping if your resource + needs to be shared across processes - fd-passing over unix domain sockets + also simplifies lifetime management for userspace. + + * Always have O_CLOEXEC support. + + * Ensure that you have sufficient insulation between different clients. By + default pick a private per-fd namespace which forces any sharing to be done + explictly. Only go with a more global per-device namespace if the objects + are truly device-unique. One counterexample in the drm modeset interfaces is + that the per-device modeset objects like connectors share a namespace with + framebuffer objects, which mostly are not shared at all. A separate + namespace, private by default, for framebuffers would have been more + suitable. + + * Think about uniqueness requirements for userspace handles. E.g. for most drm + drivers it's a userspace bug to submit the same object twice in the same + command submission ioctl. But then if objects are shareable userspace needs + to know whether it has seen an imported object from a different process + already or not. I haven't tried this myself yet due to lack of a new class + of objects, but consider using inode numbers on your shared file descriptors + as unique identifiers - it's how real files are told apart, too. + Unfortunately this requires a full-blown virtual filesystem in the kernel. + + +Last, but not Least +------------------- + +Not every problem needs a new ioctl: + + * Think hard whether you really want a driver-private interface. Of course + it's much quicker to push a driver-private interface than engaging in + lengthy discussions for a more generic solution. And occasionally doing a + private interface to spearhead a new concept is what's required. But in the + end, once the generic interface comes around you'll end up maintainer two + interfaces. Indefinitely. + + * Consider other interfaces than ioctls. A sysfs attribute is much better for + per-device settings, or for child objects with fairly static lifetimes (like + output connectors in drm with all the detection override attributes). Or + maybe only your testsuite needs this interface, and then debugfs with its + disclaimer of not having a stable ABI would be better. + +Finally, the name of the game is to get it right on the first attempt, since if +your driver proves popular and your hardware platforms long-lived then you'll +be stuck with a given ioctl essentially forever. You can try to deprecate +horrible ioctls on newer iterations of your hardware, but generally it takes +years to accomplish this. And then again years until the last user able to +complain about regressions disappears, too. diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 9344d833b7e..5ae8608ca9f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -571,6 +571,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. trust validation. format: { id:<keyid> | builtin } + cca= [MIPS] Override the kernel pages' cache coherency + algorithm. Accepted values range from 0 to 7 + inclusive. See arch/mips/include/asm/pgtable-bits.h + for platform specific values (SB1, Loongson3 and + others). + ccw_timeout_log [S390] See Documentation/s390/CommonIO for details. @@ -2194,6 +2200,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted. and restore using xsave. The kernel will fallback to enabling legacy floating-point and sse state. + noxsaveopt [X86] Disables xsaveopt used in saving x86 extended + register states. The kernel will fall back to use + xsave to save the states. By using this parameter, + performance of saving the states is degraded because + xsave doesn't support modified optimization while + xsaveopt supports it on xsaveopt enabled systems. + + noxsaves [X86] Disables xsaves and xrstors used in saving and + restoring x86 extended register state in compacted + form of xsave area. The kernel will fall back to use + xsaveopt and xrstor to save and restore the states + in standard form of xsave area. By using this + parameter, xsave area per process might occupy more + memory on xsaves enabled systems. + eagerfpu= [X86] on enable eager fpu restore off disable eager fpu restore @@ -3058,6 +3079,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. S [KNL] Run init in single mode + s390_iommu= [HW,S390] + Set s390 IOTLB flushing mode + strict + With strict flushing every unmap operation will result in + an IOTLB flush. Default is lazy flushing before reuse, + which is faster. + sa1100ir [NET] See drivers/net/irda/sa1100_ir.c. @@ -3732,6 +3760,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Disables the ticketlock slowpath using Xen PV optimizations. + xen_nopv [X86] + Disables the PV optimizations forcing the HVM guest to + run as generic HVM guest with no PV drivers. + xirc2ps_cs= [NET,PCMCIA] Format: <irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]] diff --git a/Documentation/laptops/freefall.c b/Documentation/laptops/freefall.c index d4173186555..5e44b20b184 100644 --- a/Documentation/laptops/freefall.c +++ b/Documentation/laptops/freefall.c @@ -29,16 +29,12 @@ static const char app_name[] = "FREE FALL"; static int set_unload_heads_path(char *device) { - char devname[64]; - if (strlen(device) <= 5 || strncmp(device, "/dev/", 5) != 0) return -EINVAL; - strncpy(devname, device + 5, sizeof(devname) - 1); - devname[sizeof(devname) - 1] = '\0'; strncpy(device_path, device, sizeof(device_path) - 1); snprintf(unload_heads_path, sizeof(unload_heads_path) - 1, - "/sys/block/%s/device/unload_heads", devname); + "/sys/block/%s/device/unload_heads", device+5); return 0; } diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt index e3155995ddd..beefb9f8290 100644 --- a/Documentation/oops-tracing.txt +++ b/Documentation/oops-tracing.txt @@ -268,6 +268,8 @@ characters, each representing a particular tainted value. 14: 'E' if an unsigned module has been loaded in a kernel supporting module signature. + 15: 'L' if a soft lockup has previously occurred on the system. + The primary reason for the 'Tainted: ' string is to tell kernel debuggers if this is a clean kernel or if anything unusual has occurred. Tainting is permanent: even if an offending module is diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index 6db73df0427..a68784d0a1e 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX @@ -17,8 +17,6 @@ firmware-assisted-dump.txt - Documentation on the firmware assisted dump mechanism "fadump". hvcs.txt - IBM "Hypervisor Virtual Console Server" Installation Guide -kvm_440.txt - - Various notes on the implementation of KVM for PowerPC 440. mpc52xx.txt - Linux 2.6.x on MPC52xx family pmu-ebb.txt diff --git a/Documentation/powerpc/kvm_440.txt b/Documentation/powerpc/kvm_440.txt deleted file mode 100644 index c02a003fa03..00000000000 --- a/Documentation/powerpc/kvm_440.txt +++ /dev/null @@ -1,41 +0,0 @@ -Hollis Blanchard <hollisb@us.ibm.com> -15 Apr 2008 - -Various notes on the implementation of KVM for PowerPC 440: - -To enforce isolation, host userspace, guest kernel, and guest userspace all -run at user privilege level. Only the host kernel runs in supervisor mode. -Executing privileged instructions in the guest traps into KVM (in the host -kernel), where we decode and emulate them. Through this technique, unmodified -440 Linux kernels can be run (slowly) as guests. Future performance work will -focus on reducing the overhead and frequency of these traps. - -The usual code flow is started from userspace invoking an "run" ioctl, which -causes KVM to switch into guest context. We use IVPR to hijack the host -interrupt vectors while running the guest, which allows us to direct all -interrupts to kvmppc_handle_interrupt(). At this point, we could either -- handle the interrupt completely (e.g. emulate "mtspr SPRG0"), or -- let the host interrupt handler run (e.g. when the decrementer fires), or -- return to host userspace (e.g. when the guest performs device MMIO) - -Address spaces: We take advantage of the fact that Linux doesn't use the AS=1 -address space (in host or guest), which gives us virtual address space to use -for guest mappings. While the guest is running, the host kernel remains mapped -in AS=0, but the guest can only use AS=1 mappings. - -TLB entries: The TLB entries covering the host linear mapping remain -present while running the guest. This reduces the overhead of lightweight -exits, which are handled by KVM running in the host kernel. We keep three -copies of the TLB: - - guest TLB: contents of the TLB as the guest sees it - - shadow TLB: the TLB that is actually in hardware while guest is running - - host TLB: to restore TLB state when context switching guest -> host -When a TLB miss occurs because a mapping was not present in the shadow TLB, -but was present in the guest TLB, KVM handles the fault without invoking the -guest. Large guest pages are backed by multiple 4KB shadow pages through this -mechanism. - -IO: MMIO and DCR accesses are emulated by userspace. We use virtio for network -and block IO, so those drivers must be enabled in the guest. It's possible -that some qemu device emulation (e.g. e1000 or rtl8139) may also work with -little effort. diff --git a/Documentation/rapidio/tsi721.txt b/Documentation/rapidio/tsi721.txt index 335f3c6087d..626052f403b 100644 --- a/Documentation/rapidio/tsi721.txt +++ b/Documentation/rapidio/tsi721.txt @@ -20,13 +20,26 @@ II. Known problems None. -III. To do +III. DMA Engine Support - Add DMA data transfers (non-messaging). - Add inbound region (SRIO-to-PCIe) mapping. +Tsi721 mport driver supports DMA data transfers between local system memory and +remote RapidIO devices. This functionality is implemented according to SLAVE +mode API defined by common Linux kernel DMA Engine framework. + +Depending on system requirements RapidIO DMA operations can be included/excluded +by setting CONFIG_RAPIDIO_DMA_ENGINE option. Tsi721 miniport driver uses seven +out of eight available BDMA channels to support DMA data transfers. +One BDMA channel is reserved for generation of maintenance read/write requests. + +If Tsi721 mport driver have been built with RAPIDIO_DMA_ENGINE support included, +this driver will accept DMA-specific module parameter: + "dma_desc_per_channel" - defines number of hardware buffer descriptors used by + each BDMA channel of Tsi721 (by default - 128). IV. Version History + 1.1.0 - DMA operations re-worked to support data scatter/gather lists larger + than hardware buffer descriptors ring. 1.0.0 - Initial driver release. V. License diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index c14374e7177..f79eb966637 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -826,6 +826,7 @@ can be ORed together: 4096 - An out-of-tree module has been loaded. 8192 - An unsigned module has been loaded in a kernel supporting module signature. +16384 - A soft lockup has previously occurred on the system. ============================================================== diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt index b9ca02370d4..96978eced34 100644 --- a/Documentation/vfio.txt +++ b/Documentation/vfio.txt @@ -305,7 +305,15 @@ faster, the map/unmap handling has been implemented in real mode which provides an excellent performance which has limitations such as inability to do locked pages accounting in real time. -So 3 additional ioctls have been added: +4) According to sPAPR specification, A Partitionable Endpoint (PE) is an I/O +subtree that can be treated as a unit for the purposes of partitioning and +error recovery. A PE may be a single or multi-function IOA (IO Adapter), a +function of a multi-function IOA, or multiple IOAs (possibly including switch +and bridge structures above the multiple IOAs). PPC64 guests detect PCI errors +and recover from them via EEH RTAS services, which works on the basis of +additional ioctl commands. + +So 4 additional ioctls have been added: VFIO_IOMMU_SPAPR_TCE_GET_INFO - returns the size and the start of the DMA window on the PCI bus. @@ -316,9 +324,12 @@ So 3 additional ioctls have been added: VFIO_IOMMU_DISABLE - disables the container. + VFIO_EEH_PE_OP - provides an API for EEH setup, error detection and recovery. The code flow from the example above should be slightly changed: + struct vfio_eeh_pe_op pe_op = { .argsz = sizeof(pe_op), .flags = 0 }; + ..... /* Add the group to the container */ ioctl(group, VFIO_GROUP_SET_CONTAINER, &container); @@ -342,9 +353,79 @@ The code flow from the example above should be slightly changed: dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE; /* Check here is .iova/.size are within DMA window from spapr_iommu_info */ - ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map); - ..... + + /* Get a file descriptor for the device */ + device = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, "0000:06:0d.0"); + + .... + + /* Gratuitous device reset and go... */ + ioctl(device, VFIO_DEVICE_RESET); + + /* Make sure EEH is supported */ + ioctl(container, VFIO_CHECK_EXTENSION, VFIO_EEH); + + /* Enable the EEH functionality on the device */ + pe_op.op = VFIO_EEH_PE_ENABLE; + ioctl(container, VFIO_EEH_PE_OP, &pe_op); + + /* You're suggested to create additional data struct to represent + * PE, and put child devices belonging to same IOMMU group to the + * PE instance for later reference. + */ + + /* Check the PE's state and make sure it's in functional state */ + pe_op.op = VFIO_EEH_PE_GET_STATE; + ioctl(container, VFIO_EEH_PE_OP, &pe_op); + + /* Save device state using pci_save_state(). + * EEH should be enabled on the specified device. + */ + + .... + + /* When 0xFF's returned from reading PCI config space or IO BARs + * of the PCI device. Check the PE's state to see if that has been + * frozen. + */ + ioctl(container, VFIO_EEH_PE_OP, &pe_op); + + /* Waiting for pending PCI transactions to be completed and don't + * produce any more PCI traffic from/to the affected PE until + * recovery is finished. + */ + + /* Enable IO for the affected PE and collect logs. Usually, the + * standard part of PCI config space, AER registers are dumped + * as logs for further analysis. + */ + pe_op.op = VFIO_EEH_PE_UNFREEZE_IO; + ioctl(container, VFIO_EEH_PE_OP, &pe_op); + + /* + * Issue PE reset: hot or fundamental reset. Usually, hot reset + * is enough. However, the firmware of some PCI adapters would + * require fundamental reset. + */ + pe_op.op = VFIO_EEH_PE_RESET_HOT; + ioctl(container, VFIO_EEH_PE_OP, &pe_op); + pe_op.op = VFIO_EEH_PE_RESET_DEACTIVATE; + ioctl(container, VFIO_EEH_PE_OP, &pe_op); + + /* Configure the PCI bridges for the affected PE */ + pe_op.op = VFIO_EEH_PE_CONFIGURE; + ioctl(container, VFIO_EEH_PE_OP, &pe_op); + + /* Restored state we saved at initialization time. pci_restore_state() + * is good enough as an example. + */ + + /* Hopefully, error is recovered successfully. Now, you can resume to + * start PCI traffic to/from the affected PE. + */ + + .... ------------------------------------------------------------------------------- diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 68cda1fc3d5..beae3fde075 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -148,9 +148,9 @@ of banks, as set via the KVM_X86_SETUP_MCE ioctl. 4.4 KVM_CHECK_EXTENSION -Capability: basic +Capability: basic, KVM_CAP_CHECK_EXTENSION_VM for vm ioctl Architectures: all -Type: system ioctl +Type: system ioctl, vm ioctl Parameters: extension identifier (KVM_CAP_*) Returns: 0 if unsupported; 1 (or some other positive integer) if supported @@ -160,6 +160,9 @@ receives an integer that describes the extension availability. Generally 0 means no and 1 means yes, but some extensions may report additional information in the integer return value. +Based on their initialization different VMs may have different capabilities. +It is thus encouraged to use the vm ioctl to query for capabilities (available +with KVM_CAP_CHECK_EXTENSION_VM on the vm fd) 4.5 KVM_GET_VCPU_MMAP_SIZE @@ -1892,7 +1895,8 @@ registers, find a list below: PPC | KVM_REG_PPC_PID | 64 PPC | KVM_REG_PPC_ACOP | 64 PPC | KVM_REG_PPC_VRSAVE | 32 - PPC | KVM_REG_PPC_LPCR | 64 + PPC | KVM_REG_PPC_LPCR | 32 + PPC | KVM_REG_PPC_LPCR_64 | 64 PPC | KVM_REG_PPC_PPR | 64 PPC | KVM_REG_PPC_ARCH_COMPAT | 32 PPC | KVM_REG_PPC_DABRX | 32 @@ -2677,8 +2681,8 @@ The 'data' member contains, in its first 'len' bytes, the value as it would appear if the VCPU performed a load or store of the appropriate width directly to the byte array. -NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_DCR, - KVM_EXIT_PAPR and KVM_EXIT_EPR the corresponding +NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_PAPR and + KVM_EXIT_EPR the corresponding operations are complete (and guest state is consistent) only after userspace has re-entered the kernel with KVM_RUN. The kernel side will first finish incomplete operations and then check for pending signals. Userspace @@ -2749,7 +2753,7 @@ Principles of Operation Book in the Chapter for Dynamic Address Translation __u8 is_write; } dcr; -powerpc specific. +Deprecated - was used for 440 KVM. /* KVM_EXIT_OSI */ struct { @@ -2931,8 +2935,8 @@ The fields in each entry are defined as follows: this function/index combination -6. Capabilities that can be enabled ------------------------------------ +6. Capabilities that can be enabled on vCPUs +-------------------------------------------- There are certain capabilities that change the behavior of the virtual CPU or the virtual machine when enabled. To enable them, please see section 4.37. @@ -3091,3 +3095,43 @@ Parameters: none This capability enables the in-kernel irqchip for s390. Please refer to "4.24 KVM_CREATE_IRQCHIP" for details. + +7. Capabilities that can be enabled on VMs +------------------------------------------ + +There are certain capabilities that change the behavior of the virtual +machine when enabled. To enable them, please see section 4.37. Below +you can find a list of capabilities and what their effect on the VM +is when enabling them. + +The following information is provided along with the description: + + Architectures: which instruction set architectures provide this ioctl. + x86 includes both i386 and x86_64. + + Parameters: what parameters are accepted by the capability. + + Returns: the return value. General error numbers (EBADF, ENOMEM, EINVAL) + are not detailed, but errors with specific meanings are. + + +7.1 KVM_CAP_PPC_ENABLE_HCALL + +Architectures: ppc +Parameters: args[0] is the sPAPR hcall number + args[1] is 0 to disable, 1 to enable in-kernel handling + +This capability controls whether individual sPAPR hypercalls (hcalls) +get handled by the kernel or not. Enabling or disabling in-kernel +handling of an hcall is effective across the VM. On creation, an +initial set of hcalls are enabled for in-kernel handling, which +consists of those hcalls for which in-kernel handlers were implemented +before this capability was implemented. If disabled, the kernel will +not to attempt to handle the hcall, but will always exit to userspace +to handle it. Note that it may not make sense to enable some and +disable others of a group of related hcalls, but KVM does not prevent +userspace from doing that. + +If the hcall number specified is not one that has an in-kernel +implementation, the KVM_ENABLE_CAP ioctl will fail with an EINVAL +error. |