diff options
Diffstat (limited to 'Documentation')
162 files changed, 4295 insertions, 1030 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd index 501adc2a9ec7..2ddd680929d8 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 000000000000..e4fae6026e79 --- /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 1399bb2da3eb..76ee192f80a0 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 000000000000..6a733bfa37e6 --- /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 000000000000..69f5af632657 --- /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 7fc781048b79..c4f0fed64a6e 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 000000000000..304ba84a973a --- /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 000000000000..ea0cc8c42093 --- /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 7df3134ebc0e..bacefc5b222e 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -315,7 +315,7 @@ char *date;</synopsis> <function>drm_dev_unregister()</function> followed by a call to <function>drm_dev_unref()</function>. </para> -!Edrivers/gpu/drm/drm_stub.c +!Edrivers/gpu/drm/drm_drv.c </sect2> <sect2> <title>Driver Load</title> @@ -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/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt index 10a93696e55a..0d920d54536d 100644 --- a/Documentation/PCI/MSI-HOWTO.txt +++ b/Documentation/PCI/MSI-HOWTO.txt @@ -576,7 +576,7 @@ Some devices are known to have faulty MSI implementations. Usually this is handled in the individual device driver, but occasionally it's necessary to handle this with a quirk. Some drivers have an option to disable use of MSI. While this is a convenient workaround for the driver author, -it is not good practise, and should not be emulated. +it is not good practice, and should not be emulated. 5.4. Finding why MSIs are disabled on a device diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 49b8551a3b68..e48c57f1943b 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -818,7 +818,7 @@ RCU pointer/list update: list_add_tail_rcu list_del_rcu list_replace_rcu - hlist_add_after_rcu + hlist_add_behind_rcu hlist_add_before_rcu hlist_add_head_rcu hlist_del_rcu diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers index 36d16bbf72c6..31d372609ac0 100644 --- a/Documentation/SubmittingDrivers +++ b/Documentation/SubmittingDrivers @@ -146,10 +146,6 @@ LWN.net: Porting drivers from prior kernels to 2.6: http://lwn.net/Articles/driver-porting/ -KernelTrap: - Occasional Linux kernel articles and developer interviews - http://kerneltrap.org/ - KernelNewbies: Documentation and assistance for new kernel programmers http://kernelnewbies.org/ diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 7e9abb8a276b..0a523c9a5ff4 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 @@ -396,13 +420,13 @@ you are responsible for last-minute changes. Example : [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org> -This practise is particularly helpful if you maintain a stable branch and +This practice is particularly helpful if you maintain a stable branch and want at the same time to credit the author, track changes, merge the fix, and protect the submitter from complaints. Note that under no circumstances can you change the author's identity (the From header), as it is the one which appears in the changelog. -Special note to back-porters: It seems to be a common and useful practise +Special note to back-porters: It seems to be a common and useful practice to insert an indication of the origin of a patch at the top of the commit message (just after the subject line) to facilitate tracking. For instance, here's what we see in 2.6-stable : diff --git a/Documentation/arm/CCN.txt b/Documentation/arm/CCN.txt new file mode 100644 index 000000000000..0632b3aad83e --- /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 2cce5401e323..4dc66c173e10 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 658abb258cef..8f7309bad460 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 0c50220851fb..d9174fabe37e 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 85af34d55cee..f3c05b5f9f08 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 80ac454704b8..8870b0212150 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/device-mapper/switch.txt b/Documentation/device-mapper/switch.txt index 2fa749387be8..8897d0494838 100644 --- a/Documentation/device-mapper/switch.txt +++ b/Documentation/device-mapper/switch.txt @@ -106,6 +106,11 @@ which paths. The path number in the range 0 ... (<num_paths> - 1). Expressed in hexadecimal (WITHOUT any prefix like 0x). +R<n>,<m> + This parameter allows repetitive patterns to be loaded quickly. <n> and <m> + are hexadecimal numbers. The last <n> mappings are repeated in the next <m> + slots. + Status ====== @@ -124,3 +129,10 @@ Create a switch device with 64kB region size: Set mappings for the first 7 entries to point to devices switch0, switch1, switch2, switch0, switch1, switch2, switch1: dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1 + +Set repetitive mapping. This command: + dmsetup message switch 0 set_region_mappings 1000:1 :2 R2,10 +is equivalent to: + dmsetup message switch 0 set_region_mappings 1000:1 :2 :1 :2 :1 :2 :1 :2 \ + :1 :2 :1 :2 :1 :2 :1 :2 :1 :2 + diff --git a/Documentation/devicetree/bindings/arm/adapteva.txt b/Documentation/devicetree/bindings/arm/adapteva.txt new file mode 100644 index 000000000000..1d8af9e36065 --- /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 3509707f9320..c554ed3d44fb 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 000000000000..8781073029e9 --- /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 389bed5056e8..795cc78543fe 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 000000000000..8240c023e202 --- /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 000000000000..3c436cc4f35d --- /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 000000000000..b100d3847d88 --- /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 000000000000..cd236b727e2a --- /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 1fe72a0778cd..298e2f6b33c6 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 000000000000..33cd05e6c125 --- /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 5573c08d3180..c7d2fa156678 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 df0a452b8526..934f00025cc4 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 94013a9a8769..904de5781f44 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 000000000000..d6ac71f37314 --- /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 d22b216f5d23..0edc90305dfe 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 000000000000..79074dac684a --- /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 f9865e77e0b0..1e1979b229ff 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 000000000000..cf649827ffcd --- /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 558ed4b4ef39..73278c6d2dc3 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 6f1ed830b4f7..1f7995357888 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 652914b17b95..ecc69520bcea 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 000000000000..4fc869b69d4a --- /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 000000000000..b7adf4e3ea98 --- /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 000000000000..c3b0db437c48 --- /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 6bc9fd2c6631..cc05de9ec393 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 90ec91fe5ce0..9252912a5b0e 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 feb830130714..99c214660bdc 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 000000000000..effd9401c133 --- /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 e577196a12c0..4659fd952301 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 000000000000..a6511df165c5 --- /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 000000000000..d5e2522b9ec1 --- /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 000000000000..9f1d750d76de --- /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 000000000000..df0f48bcf75a --- /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 1f5729f10621..95800ab37bb0 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 000000000000..3e145c1675b1 --- /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 000000000000..46525ea3e646 --- /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 d7df01c5bb3a..e9e4bce40760 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 000000000000..67d0a58dbb77 --- /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 000000000000..aca917fe2ba7 --- /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 000000000000..1a0598e5279d --- /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 000000000000..d8c98c7614d0 --- /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 000000000000..986371a4be2c --- /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 000000000000..23bfe8e1f7cc --- /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 000000000000..2d150c311a05 --- /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 fc15ac519437..50b25c3da186 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 37803eb5521e..6af570ec53b4 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 000000000000..baef432e8369 --- /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 000000000000..4b463904cba0 --- /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 000000000000..6e551090f465 --- /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 2faf1f1fa39e..80c37df940a7 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/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt index 1486497a24c1..ce6a1a072028 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt @@ -4,11 +4,13 @@ Specifying interrupt information for devices 1) Interrupt client nodes ------------------------- -Nodes that describe devices which generate interrupts must contain an either an -"interrupts" property or an "interrupts-extended" property. These properties -contain a list of interrupt specifiers, one per output interrupt. The format of -the interrupt specifier is determined by the interrupt controller to which the -interrupts are routed; see section 2 below for details. +Nodes that describe devices which generate interrupts must contain an +"interrupts" property, an "interrupts-extended" property, or both. If both are +present, the latter should take precedence; the former may be provided simply +for compatibility with software that does not recognize the latter. These +properties contain a list of interrupt specifiers, one per output interrupt. The +format of the interrupt specifier is determined by the interrupt controller to +which the interrupts are routed; see section 2 below for details. Example: interrupt-parent = <&intc1>; diff --git a/Documentation/devicetree/bindings/leds/pca963x.txt b/Documentation/devicetree/bindings/leds/pca963x.txt index aece3eac1b63..dafbe9931c2b 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 d7221b84987c..bad9102796f3 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 36a0c3d8c726..5c7e7230984a 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 8edcb9bd873b..4f64b2a73169 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 d81ba30c0d8b..ba2d7f0f9c5f 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 1f5a31fef907..03c5a551da55 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 000000000000..b97b8bef1fe5 --- /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/mmc/exynos-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt index 532b1d440abc..6cd3525d0e09 100644 --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt @@ -46,13 +46,14 @@ Required Properties: - if CIU clock divider value is 0 (that is divide by 1), both tx and rx phase shift clocks should be 0. -Required properties for a slot: +Required properties for a slot (Deprecated - Recommend to use one slot per host): * gpios: specifies a list of gpios used for command, clock and data bus. The first gpio is the command line and the second gpio is the clock line. The rest of the gpios (depending on the bus-width property) are the data lines in no particular order. The format of the gpio specifier depends on the gpio controller. +(Deprecated - Refer to Documentation/devicetree/binding/pinctrl/samsung-pinctrl.txt) Example: @@ -69,21 +70,13 @@ Example: dwmmc0@12200000 { num-slots = <1>; - supports-highspeed; + cap-mmc-highspeed; + cap-sd-highspeed; broken-cd; fifo-depth = <0x80>; card-detect-delay = <200>; samsung,dw-mshc-ciu-div = <3>; samsung,dw-mshc-sdr-timing = <2 3>; samsung,dw-mshc-ddr-timing = <1 2>; - - slot@0 { - reg = <0>; - bus-width = <8>; - gpios = <&gpc0 0 2 0 3>, <&gpc0 1 2 0 3>, - <&gpc1 0 2 3 3>, <&gpc1 1 2 3 3>, - <&gpc1 2 2 3 3>, <&gpc1 3 2 3 3>, - <&gpc0 3 2 3 3>, <&gpc0 4 2 3 3>, - <&gpc0 5 2 3 3>, <&gpc0 6 2 3 3>; - }; + bus-width = <8>; }; diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt index e5bc49f764d1..3b3544931437 100644 --- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt @@ -34,13 +34,11 @@ Example: num-slots = <1>; vmmc-supply = <&ldo12>; fifo-depth = <0x100>; - supports-highspeed; pinctrl-names = "default"; pinctrl-0 = <&sd_pmx_pins &sd_cfg_func1 &sd_cfg_func2>; - slot@0 { - reg = <0>; - bus-width = <4>; - disable-wp; - cd-gpios = <&gpio10 3 0>; - }; + bus-width = <4>; + disable-wp; + cd-gpios = <&gpio10 3 0>; + cap-mmc-highspeed; + cap-sd-highspeed; }; diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 3c18001dfd5d..431716e37a39 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -34,8 +34,8 @@ Optional properties: - cap-power-off-card: powering off the card is safe - cap-sdio-irq: enable SDIO IRQ signalling on this interface - full-pwr-cycle: full power cycle of the card is supported -- mmc-highspeed-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported -- mmc-highspeed-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported +- mmc-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported +- mmc-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported - mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported - mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt new file mode 100644 index 000000000000..299081f94abd --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt @@ -0,0 +1,32 @@ +* Renesas Multi Media Card Interface (MMCIF) Controller + +This file documents differences between the core properties in mmc.txt +and the properties used by the MMCIF device. + + +Required properties: + +- compatible: must contain one of the following + - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs + - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs + - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs + - "renesas,sh-mmcif" for the generic MMCIF + +- clocks: reference to the functional clock + +- dmas: reference to the DMA channels, one per channel name listed in the + dma-names property. +- dma-names: must contain "tx" for the transmit DMA channel and "rx" for the + receive DMA channel. + + +Example: R8A7790 (R-Car H2) MMCIF0 + + mmcif0: mmc@ee200000 { + compatible = "renesas,mmcif-r8a7790", "renesas,sh-mmcif"; + reg = <0 0xee200000 0 0x80>; + interrupts = <0 169 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp3_clks R8A7790_CLK_MMCIF0>; + dmas = <&dmac0 0xd1>, <&dmac0 0xd2>; + dma-names = "tx", "rx"; + }; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index 81b33b5b20fc..485483a63d8c 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -27,8 +27,8 @@ Example: bus-width = <8>; non-removable; - vmmc = <&pm8941_l20>; - vqmmc = <&pm8941_s3>; + vmmc-supply = <&pm8941_l20>; + vqmmc-supply = <&pm8941_s3>; pinctrl-names = "default"; pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data>; @@ -44,8 +44,8 @@ Example: bus-width = <4>; cd-gpios = <&msmgpio 62 0x1>; - vmmc = <&pm8941_l21>; - vqmmc = <&pm8941_l13>; + vmmc-supply = <&pm8941_l21>; + vqmmc-supply = <&pm8941_l13>; pinctrl-names = "default"; pinctrl-0 = <&sdc2_clk &sdc2_cmd &sdc2_data>; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt b/Documentation/devicetree/bindings/mmc/sdhci-st.txt new file mode 100644 index 000000000000..7527db447a35 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/sdhci-st.txt @@ -0,0 +1,33 @@ +* STMicroelectronics sdhci-st MMC/SD controller + +This file documents the differences between the core properties in +Documentation/devicetree/bindings/mmc/mmc.txt and the properties +used by the sdhci-st driver. + +Required properties: +- compatible : Must be "st,sdhci" +- clock-names : Should be "mmc" + See: Documentation/devicetree/bindings/resource-names.txt +- clocks : Phandle of the clock used by the sdhci controler + See: Documentation/devicetree/bindings/clock/clock-bindings.txt + +Optional properties: +- non-removable: non-removable slot + See: Documentation/devicetree/bindings/mmc/mmc.txt +- bus-width: Number of data lines + See: Documentation/devicetree/bindings/mmc/mmc.txt + +Example: + +mmc0: sdhci@fe81e000 { + compatible = "st,sdhci"; + status = "disabled"; + reg = <0xfe81e000 0x1000>; + interrupts = <GIC_SPI 127 IRQ_TYPE_NONE>; + interrupt-names = "mmcirq"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_mmc0>; + clock-names = "mmc"; + clocks = <&clk_s_a1_ls 1>; + bus-width = <8> +}; diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt index 2d4a7258a10d..346c6095a615 100644 --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt @@ -67,7 +67,8 @@ Optional properties: * card-detect-delay: Delay in milli-seconds before detecting card after card insert event. The default value is 0. -* supports-highspeed: Enables support for high speed cards (up to 50MHz) +* supports-highspeed (DEPRECATED): Enables support for high speed cards (up to 50MHz) + (use "cap-mmc-highspeed" or "cap-sd-highspeed" instead) * broken-cd: as documented in mmc core bindings. @@ -98,14 +99,11 @@ board specific portions as listed below. clock-frequency = <400000000>; clock-freq-min-max = <400000 200000000>; num-slots = <1>; - supports-highspeed; broken-cd; fifo-depth = <0x80>; card-detect-delay = <200>; vmmc-supply = <&buck8>; - - slot@0 { - reg = <0>; - bus-width = <8>; - }; + bus-width = <8>; + cap-mmc-highspeed; + cap-sd-highspeed; }; diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index ce8056116fb0..76bf087bc889 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -12,6 +12,7 @@ Required properties: Should be "ti,omap3-hsmmc", for OMAP3 controllers Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0 Should be "ti,omap4-hsmmc", for OMAP4 controllers + Should be "ti,am33xx-hsmmc", for AM335x controllers - ti,hwmods: Must be "mmc<n>", n is controller instance starting 1 Optional properties: @@ -56,3 +57,56 @@ Examples: &edma 25>; dma-names = "tx", "rx"; }; + +[workaround for missing swakeup on am33xx] + +This SOC is missing the swakeup line, it will not detect SDIO irq +while in suspend. + + ------ + | PRCM | + ------ + ^ | + swakeup | | fclk + | v + ------ ------- ----- + | card | -- CIRQ --> | hsmmc | -- IRQ --> | CPU | + ------ ------- ----- + +In suspend the fclk is off and the module is disfunctional. Even register reads +will fail. A small logic in the host will request fclk restore, when an +external event is detected. Once the clock is restored, the host detects the +event normally. Since am33xx doesn't have this line it never wakes from +suspend. + +The workaround is to reconfigure the dat1 line as a GPIO upon suspend. To make +this work, we need to set the named pinctrl states "default" and "idle". +Prepare idle to remux dat1 as a gpio, and default to remux it back as sdio +dat1. The MMC driver will then toggle between idle and default state during +runtime. + +In summary: +1. select matching 'compatible' section, see example below. +2. specify pinctrl states "default" and "idle", "sleep" is optional. +3. specify the gpio irq used for detecting sdio irq in suspend + +If configuration is incomplete, a warning message is emitted "falling back to +polling". Also check the "sdio irq mode" in /sys/kernel/debug/mmc0/regs. Mind +not every application needs SDIO irq, e.g. MMC cards. + + mmc1: mmc@48060100 { + compatible = "ti,am33xx-hsmmc"; + ... + pinctrl-names = "default", "idle", "sleep" + pinctrl-0 = <&mmc1_pins>; + pinctrl-1 = <&mmc1_idle>; + pinctrl-2 = <&mmc1_sleep>; + ... + interrupts-extended = <&intc 64 &gpio2 28 0>; + }; + + mmc1_idle : pinmux_cirq_pin { + pinctrl-single,pins = < + 0x0f8 0x3f /* GPIO2_28 */ + >; + }; diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt index 6a2a1160a70d..fa0f327cde01 100644 --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt @@ -18,6 +18,7 @@ Required properties: "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC + "renesas,sdhi-r8a7791" - SDHI IP on R8A7791 SoC Optional properties: - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt index 458d59634688..a011fdf61dbf 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/net/apm-xgene-enet.txt b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt new file mode 100644 index 000000000000..ebcad25efd0a --- /dev/null +++ b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt @@ -0,0 +1,66 @@ +APM X-Gene SoC Ethernet nodes + +Ethernet nodes are defined to describe on-chip ethernet interfaces in +APM X-Gene SoC. + +Required properties: +- compatible: Should be "apm,xgene-enet" +- reg: Address and length of the register set for the device. It contains the + information of registers in the same order as described by reg-names +- reg-names: Should contain the register set names + - "enet_csr": Ethernet control and status register address space + - "ring_csr": Descriptor ring control and status register address space + - "ring_cmd": Descriptor ring command register address space +- interrupts: Ethernet main interrupt +- clocks: Reference to the clock entry. +- local-mac-address: MAC address assigned to this device +- phy-connection-type: Interface type between ethernet device and PHY device +- phy-handle: Reference to a PHY node connected to this device + +- mdio: Device tree subnode with the following required properties: + - compatible: Must be "apm,xgene-mdio". + - #address-cells: Must be <1>. + - #size-cells: Must be <0>. + + For the phy on the mdio bus, there must be a node with the following fields: + - compatible: PHY identifier. Please refer ./phy.txt for the format. + - reg: The ID number for the phy. + +Optional properties: +- status: Should be "ok" or "disabled" for enabled/disabled. Default is "ok". + +Example: + menetclk: menetclk { + compatible = "apm,xgene-device-clock"; + clock-output-names = "menetclk"; + status = "ok"; + }; + + menet: ethernet@17020000 { + compatible = "apm,xgene-enet"; + status = "disabled"; + reg = <0x0 0x17020000 0x0 0xd100>, + <0x0 0X17030000 0x0 0X400>, + <0x0 0X10000000 0x0 0X200>; + reg-names = "enet_csr", "ring_csr", "ring_cmd"; + interrupts = <0x0 0x3c 0x4>; + clocks = <&menetclk 0>; + local-mac-address = [00 01 73 00 00 01]; + phy-connection-type = "rgmii"; + phy-handle = <&menetphy>; + mdio { + compatible = "apm,xgene-mdio"; + #address-cells = <1>; + #size-cells = <0>; + menetphy: menetphy@3 { + compatible = "ethernet-phy-id001c.c915"; + reg = <0x3>; + }; + + }; + }; + +/* Board-specific peripheral configurations */ +&menet { + status = "ok"; +}; diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt index 6bc84adb10c0..8a2c7b55ec16 100644 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt @@ -12,7 +12,14 @@ Optional properties: only if property "phy-reset-gpios" is available. Missing the property will have the duration be 1 millisecond. Numbers greater than 1000 are invalid and 1 millisecond will be used instead. -- phy-supply: regulator that powers the Ethernet PHY. +- phy-supply : regulator that powers the Ethernet PHY. +- phy-handle : phandle to the PHY device connected to this device. +- fixed-link : Assume a fixed link. See fixed-link.txt in the same directory. + Use instead of phy-handle. + +Optional subnodes: +- mdio : specifies the mdio bus in the FEC, used as a container for phy nodes + according to phy.txt in the same directory Example: @@ -25,3 +32,23 @@ ethernet@83fec000 { local-mac-address = [00 04 9F 01 1B B9]; phy-supply = <®_fec_supply>; }; + +Example with phy specified: + +ethernet@83fec000 { + compatible = "fsl,imx51-fec", "fsl,imx27-fec"; + reg = <0x83fec000 0x4000>; + interrupts = <87>; + phy-mode = "mii"; + phy-reset-gpios = <&gpio2 14 0>; /* GPIO2_14 */ + local-mac-address = [00 04 9F 01 1B B9]; + phy-supply = <®_fec_supply>; + phy-handle = <ðphy>; + mdio { + ethphy: ethernet-phy@6 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <6>; + max-speed = <100>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/panel/auo,b133htn01.txt b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt new file mode 100644 index 000000000000..302226b5bb55 --- /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 000000000000..b47f9d87bc19 --- /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 000000000000..081bb939ed31 --- /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 000000000000..7825844aafdf --- /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/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index d0d15ee42834..ed0d9b9fff2b 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -2,6 +2,10 @@ Required properties: - compatible: should contain "snps,dw-pcie" to identify the core. +- reg: Should contain the configuration address space. +- reg-names: Must be "config" for the PCIe configuration space. + (The old way of getting the configuration address space from "ranges" + is deprecated and should be avoided.) - #address-cells: set to <3> - #size-cells: set to <2> - device_type: set to "pci" diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt index c300391e8d3e..0823362548dc 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 000000000000..49ea76da7718 --- /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/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt new file mode 100644 index 000000000000..3d217911b313 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt @@ -0,0 +1,59 @@ +TI PCI Controllers + +PCIe Designware Controller + - compatible: Should be "ti,dra7-pcie"" + - reg : Two register ranges as listed in the reg-names property + - reg-names : The first entry must be "ti-conf" for the TI specific registers + The second entry must be "rc-dbics" for the designware pcie + registers + The third entry must be "config" for the PCIe configuration space + - phys : list of PHY specifiers (used by generic PHY framework) + - phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the + number of PHYs as specified in *phys* property. + - ti,hwmods : Name of the hwmod associated to the pcie, "pcie<X>", + where <X> is the instance number of the pcie from the HW spec. + - interrupts : Two interrupt entries must be specified. The first one is for + main interrupt line and the second for MSI interrupt line. + - #address-cells, + #size-cells, + #interrupt-cells, + device_type, + ranges, + num-lanes, + interrupt-map-mask, + interrupt-map : as specified in ../designware-pcie.txt + +Example: +axi { + compatible = "simple-bus"; + #size-cells = <1>; + #address-cells = <1>; + ranges = <0x51000000 0x51000000 0x3000 + 0x0 0x20000000 0x10000000>; + pcie@51000000 { + compatible = "ti,dra7-pcie"; + reg = <0x51000000 0x2000>, <0x51002000 0x14c>, <0x1000 0x2000>; + reg-names = "rc_dbics", "ti_conf", "config"; + interrupts = <0 232 0x4>, <0 233 0x4>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x81000000 0 0 0x03000 0 0x00010000 + 0x82000000 0 0x20013000 0x13000 0 0xffed000>; + #interrupt-cells = <1>; + num-lanes = <1>; + ti,hwmods = "pcie1"; + phys = <&pcie1_phy>; + phy-names = "pcie-phy0"; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_intc 1>, + <0 0 0 2 &pcie_intc 2>, + <0 0 0 3 &pcie_intc 3>, + <0 0 0 4 &pcie_intc 4>; + pcie_intc: interrupt-controller { + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 6099a5c94283..7a6feea2a48b 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 000000000000..2a6bfdcc09b3 --- /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 d8d065608ec0..93ce12eb422a 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 000000000000..2f9c0bd66457 --- /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 7181f925acaa..0211c6d8a522 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 e0d35a40981b..e33e4dcdce79 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 000000000000..93b7de91b9f6 --- /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 73262b575dfc..d2ea80dc43eb 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 35d2e1f186f0..daef6fad6a5f 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 cefef741a40b..4658b69d4f4d 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 2b32783ba821..e82aaf492517 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 700dec4774fa..cff38bdbc0e4 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 000000000000..d47d15a6a298 --- /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 000000000000..84d2fb807d3c --- /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 d290988ed975..20191315e444 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 000000000000..a3eb154c32ca --- /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 792efbaedc54..1e8a8578148f 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 c94909215c07..ae738f562acc 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 28ef498a66e5..0ef00be44b01 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 000000000000..3b9251b4a145 --- /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 d415b38ec8ca..ac7269f90764 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 000000000000..3e3039a8a253 --- /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 1ec175eddca8..b75af94a5e52 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 000000000000..6fc3c6adeefa --- /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 33b5730d07ba..31036c667d54 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 7bfde9c9d658..08b394b1edbf 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 2dad41b689af..ecc899b9817b 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/devicetree/changesets.txt b/Documentation/devicetree/changesets.txt new file mode 100644 index 000000000000..935ba5acc34e --- /dev/null +++ b/Documentation/devicetree/changesets.txt @@ -0,0 +1,40 @@ +A DT changeset is a method which allows one to apply changes +in the live tree in such a way that either the full set of changes +will be applied, or none of them will be. If an error occurs partway +through applying the changeset, then the tree will be rolled back to the +previous state. A changeset can also be removed after it has been +applied. + +When a changeset is applied, all of the changes get applied to the tree +at once before emitting OF_RECONFIG notifiers. This is so that the +receiver sees a complete and consistent state of the tree when it +receives the notifier. + +The sequence of a changeset is as follows. + +1. of_changeset_init() - initializes a changeset + +2. A number of DT tree change calls, of_changeset_attach_node(), +of_changeset_detach_node(), of_changeset_add_property(), +of_changeset_remove_property, of_changeset_update_property() to prepare +a set of changes. No changes to the active tree are made at this point. +All the change operations are recorded in the of_changeset 'entries' +list. + +3. mutex_lock(of_mutex) - starts a changeset; The global of_mutex +ensures there can only be one editor at a time. + +4. of_changeset_apply() - Apply the changes to the tree. Either the +entire changeset will get applied, or if there is an error the tree will +be restored to the previous state + +5. mutex_unlock(of_mutex) - All operations complete, release the mutex + +If a successfully applied changeset needs to be removed, it can be done +with the following sequence. + +1. mutex_lock(of_mutex) + +2. of_changeset_revert() + +3. mutex_unlock(of_mutex) diff --git a/Documentation/devicetree/todo.txt b/Documentation/devicetree/todo.txt new file mode 100644 index 000000000000..c3cf0659bd19 --- /dev/null +++ b/Documentation/devicetree/todo.txt @@ -0,0 +1,11 @@ +Todo list for devicetree: + +=== General structure === +- Switch from custom lists to (h)list_head for nodes and properties structure +- Remove of_allnodes list and iterate using list of child nodes alone + +=== CONFIG_OF_DYNAMIC === +- Switch to RCU for tree updates and get rid of global spinlock +- Document node lifecycle for CONFIG_OF_DYNAMIC +- Always set ->full_name at of_attach_node() time +- pseries: Get rid of open-coded tree modification from arch/powerpc/platforms/pseries/dlpar.c diff --git a/Documentation/dmaengine.txt b/Documentation/dmaengine.txt index 879b6e31e2da..573e28ce9751 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/Locking b/Documentation/filesystems/Locking index b18dd1779029..f1997e9da61f 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -349,7 +349,11 @@ prototypes: locking rules: inode->i_lock may block fl_copy_lock: yes no -fl_release_private: maybe no +fl_release_private: maybe maybe[1] + +[1]: ->fl_release_private for flock or POSIX locks is currently allowed +to block. Leases however can still be freed while the i_lock is held and +so fl_release_private called on a lease should not block. ----------------------- lock_manager_operations --------------------------- prototypes: diff --git a/Documentation/filesystems/cifs/AUTHORS b/Documentation/filesystems/cifs/AUTHORS index ca4a67a0bb1e..c98800df677f 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 355abcdcda98..066ffddc3964 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 e543b1a619cc..c8f036a9b13f 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 a1d0d7a30165..61d65cc65c54 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 ba169faad5c6..4452786225b8 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 d8abfc31abbe..76546324e968 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 fa9a0a8b3734..18790c237977 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/hid/uhid.txt b/Documentation/hid/uhid.txt index 54c8f9706a95..c8656dd029a9 100644 --- a/Documentation/hid/uhid.txt +++ b/Documentation/hid/uhid.txt @@ -1,28 +1,13 @@ UHID - User-space I/O driver support for HID subsystem ======================================================== -The HID subsystem needs two kinds of drivers. In this document we call them: +UHID allows user-space to implement HID transport drivers. Please see +hid-transport.txt for an introduction into HID transport drivers. This document +relies heavily on the definitions declared there. - 1. The "HID I/O Driver" is the driver that performs raw data I/O to the - low-level device. Internally, they register an hid_ll_driver structure with - the HID core. They perform device setup, read raw data from the device and - push it into the HID subsystem and they provide a callback so the HID - subsystem can send data to the device. - - 2. The "HID Device Driver" is the driver that parses HID reports and reacts on - them. There are generic drivers like "generic-usb" and "generic-bluetooth" - which adhere to the HID specification and provide the standardizes features. - But there may be special drivers and quirks for each non-standard device out - there. Internally, they use the hid_driver structure. - -Historically, the USB stack was the first subsystem to provide an HID I/O -Driver. However, other standards like Bluetooth have adopted the HID specs and -may provide HID I/O Drivers, too. The UHID driver allows to implement HID I/O -Drivers in user-space and feed the data into the kernel HID-subsystem. - -This allows user-space to operate on the same level as USB-HID, Bluetooth-HID -and similar. It does not provide a way to write HID Device Drivers, though. Use -hidraw for this purpose. +With UHID, a user-space transport driver can create kernel hid-devices for each +device connected to the user-space controlled bus. The UHID API defines the I/O +events provided from the kernel to user-space and vice versa. There is an example user-space application in ./samples/uhid/uhid-example.c @@ -42,8 +27,9 @@ by setting O_NONBLOCK. struct uhid_event { __u32 type; union { - struct uhid_create_req create; - struct uhid_data_req data; + struct uhid_create2_req create2; + struct uhid_output_req output; + struct uhid_input2_req input2; ... } u; }; @@ -54,8 +40,11 @@ multiple write()'s. A single event must always be sent as a whole. Furthermore, only a single event can be sent per read() or write(). Pending data is ignored. If you want to handle multiple events in a single syscall, then use vectored I/O with readv()/writev(). +The "type" field defines the payload. For each type, there is a +payload-structure available in the union "u" (except for empty payloads). This +payload contains management and/or device data. -The first thing you should do is sending an UHID_CREATE event. This will +The first thing you should do is sending an UHID_CREATE2 event. This will register the device. UHID will respond with an UHID_START event. You can now start sending data to and reading data from UHID. However, unless UHID sends the UHID_OPEN event, the internally attached HID Device Driver has no user attached. @@ -69,12 +58,20 @@ ref-counting for you. You may decide to ignore UHID_OPEN/UHID_CLOSE, though. I/O is allowed even though the device may have no users. -If you want to send data to the HID subsystem, you send an HID_INPUT event with -your raw data payload. If the kernel wants to send data to the device, you will -read an UHID_OUTPUT or UHID_OUTPUT_EV event. +If you want to send data on the interrupt channel to the HID subsystem, you send +an HID_INPUT2 event with your raw data payload. If the kernel wants to send data +on the interrupt channel to the device, you will read an UHID_OUTPUT event. +Data requests on the control channel are currently limited to GET_REPORT and +SET_REPORT (no other data reports on the control channel are defined so far). +Those requests are always synchronous. That means, the kernel sends +UHID_GET_REPORT and UHID_SET_REPORT events and requires you to forward them to +the device on the control channel. Once the device responds, you must forward +the response via UHID_GET_REPORT_REPLY and UHID_SET_REPORT_REPLY to the kernel. +The kernel blocks internal driver-execution during such round-trips (times out +after a hard-coded period). If your device disconnects, you should send an UHID_DESTROY event. This will -unregister the device. You can now send UHID_CREATE again to register a new +unregister the device. You can now send UHID_CREATE2 again to register a new device. If you close() the fd, the device is automatically unregistered and destroyed internally. @@ -82,73 +79,79 @@ internally. write() ------- write() allows you to modify the state of the device and feed input data into -the kernel. The following types are supported: UHID_CREATE, UHID_DESTROY and -UHID_INPUT. The kernel will parse the event immediately and if the event ID is +the kernel. The kernel will parse the event immediately and if the event ID is not supported, it will return -EOPNOTSUPP. If the payload is invalid, then -EINVAL is returned, otherwise, the amount of data that was read is returned and -the request was handled successfully. +the request was handled successfully. O_NONBLOCK does not affect write() as +writes are always handled immediately in a non-blocking fashion. Future requests +might make use of O_NONBLOCK, though. - UHID_CREATE: + UHID_CREATE2: This creates the internal HID device. No I/O is possible until you send this - event to the kernel. The payload is of type struct uhid_create_req and + event to the kernel. The payload is of type struct uhid_create2_req and contains information about your device. You can start I/O now. - UHID_CREATE2: - Same as UHID_CREATE, but the HID report descriptor data (rd_data) is an array - inside struct uhid_create2_req, instead of a pointer to a separate array. - Enables use from languages that don't support pointers, e.g. Python. - UHID_DESTROY: This destroys the internal HID device. No further I/O will be accepted. There may still be pending messages that you can receive with read() but no further UHID_INPUT events can be sent to the kernel. - You can create a new device by sending UHID_CREATE again. There is no need to + You can create a new device by sending UHID_CREATE2 again. There is no need to reopen the character device. - UHID_INPUT: - You must send UHID_CREATE before sending input to the kernel! This event - contains a data-payload. This is the raw data that you read from your device. - The kernel will parse the HID reports and react on it. - UHID_INPUT2: - Same as UHID_INPUT, but the data array is the last field of uhid_input2_req. - Enables userspace to write only the required bytes to kernel (ev.type + - ev.u.input2.size + the part of the data array that matters), instead of - the entire struct uhid_input2_req. - - UHID_FEATURE_ANSWER: - If you receive a UHID_FEATURE request you must answer with this request. You - must copy the "id" field from the request into the answer. Set the "err" field - to 0 if no error occurred or to EIO if an I/O error occurred. + You must send UHID_CREATE2 before sending input to the kernel! This event + contains a data-payload. This is the raw data that you read from your device + on the interrupt channel. The kernel will parse the HID reports. + + UHID_GET_REPORT_REPLY: + If you receive a UHID_GET_REPORT request you must answer with this request. + You must copy the "id" field from the request into the answer. Set the "err" + field to 0 if no error occurred or to EIO if an I/O error occurred. If "err" is 0 then you should fill the buffer of the answer with the results - of the feature request and set "size" correspondingly. + of the GET_REPORT request and set "size" correspondingly. + + UHID_SET_REPORT_REPLY: + This is the SET_REPORT equivalent of UHID_GET_REPORT_REPLY. Unlike GET_REPORT, + SET_REPORT never returns a data buffer, therefore, it's sufficient to set the + "id" and "err" fields correctly. read() ------ -read() will return a queued output report. These output reports can be of type -UHID_START, UHID_STOP, UHID_OPEN, UHID_CLOSE, UHID_OUTPUT or UHID_OUTPUT_EV. No -reaction is required to any of them but you should handle them according to your -needs. Only UHID_OUTPUT and UHID_OUTPUT_EV have payloads. +read() will return a queued output report. No reaction is required to any of +them but you should handle them according to your needs. UHID_START: This is sent when the HID device is started. Consider this as an answer to - UHID_CREATE. This is always the first event that is sent. + UHID_CREATE2. This is always the first event that is sent. Note that this + event might not be available immediately after write(UHID_CREATE2) returns. + Device drivers might required delayed setups. + This event contains a payload of type uhid_start_req. The "dev_flags" field + describes special behaviors of a device. The following flags are defined: + UHID_DEV_NUMBERED_FEATURE_REPORTS: + UHID_DEV_NUMBERED_OUTPUT_REPORTS: + UHID_DEV_NUMBERED_INPUT_REPORTS: + Each of these flags defines whether a given report-type uses numbered + reports. If numbered reports are used for a type, all messages from + the kernel already have the report-number as prefix. Otherwise, no + prefix is added by the kernel. + For messages sent by user-space to the kernel, you must adjust the + prefixes according to these flags. UHID_STOP: This is sent when the HID device is stopped. Consider this as an answer to UHID_DESTROY. - If the kernel HID device driver closes the device manually (that is, you - didn't send UHID_DESTROY) then you should consider this device closed and send - an UHID_DESTROY event. You may want to reregister your device, though. This is - always the last message that is sent to you unless you reopen the device with - UHID_CREATE. + If you didn't destroy your device via UHID_DESTROY, but the kernel sends an + UHID_STOP event, this should usually be ignored. It means that the kernel + reloaded/changed the device driver loaded on your HID device (or some other + maintenance actions happened). + You can usually ignored any UHID_STOP events safely. UHID_OPEN: This is sent when the HID device is opened. That is, the data that the HID device provides is read by some other process. You may ignore this event but it is useful for power-management. As long as you haven't received this event there is actually no other process that reads your data so there is no need to - send UHID_INPUT events to the kernel. + send UHID_INPUT2 events to the kernel. UHID_CLOSE: This is sent when there are no more processes which read the HID data. It is @@ -156,27 +159,29 @@ needs. Only UHID_OUTPUT and UHID_OUTPUT_EV have payloads. UHID_OUTPUT: This is sent if the HID device driver wants to send raw data to the I/O - device. You should read the payload and forward it to the device. The payload - is of type "struct uhid_data_req". + device on the interrupt channel. You should read the payload and forward it to + the device. The payload is of type "struct uhid_data_req". This may be received even though you haven't received UHID_OPEN, yet. - UHID_OUTPUT_EV (obsolete): - Same as UHID_OUTPUT but this contains a "struct input_event" as payload. This - is called for force-feedback, LED or similar events which are received through - an input device by the HID subsystem. You should convert this into raw reports - and send them to your device similar to events of type UHID_OUTPUT. - This is no longer sent by newer kernels. Instead, HID core converts it into a - raw output report and sends it via UHID_OUTPUT. - - UHID_FEATURE: - This event is sent if the kernel driver wants to perform a feature request as - described in the HID specs. The report-type and report-number are available in - the payload. - The kernel serializes feature requests so there will never be two in parallel. - However, if you fail to respond with a UHID_FEATURE_ANSWER in a time-span of 5 - seconds, then the requests will be dropped and a new one might be sent. - Therefore, the payload also contains an "id" field that identifies every - request. - -Document by: - David Herrmann <dh.herrmann@googlemail.com> + UHID_GET_REPORT: + This event is sent if the kernel driver wants to perform a GET_REPORT request + on the control channeld as described in the HID specs. The report-type and + report-number are available in the payload. + The kernel serializes GET_REPORT requests so there will never be two in + parallel. However, if you fail to respond with a UHID_GET_REPORT_REPLY, the + request might silently time out. + Once you read a GET_REPORT request, you shall forward it to the hid device and + remember the "id" field in the payload. Once your hid device responds to the + GET_REPORT (or if it fails), you must send a UHID_GET_REPORT_REPLY to the + kernel with the exact same "id" as in the request. If the request already + timed out, the kernel will ignore the response silently. The "id" field is + never re-used, so conflicts cannot happen. + + UHID_SET_REPORT: + This is the SET_REPORT equivalent of UHID_GET_REPORT. On receipt, you shall + send a SET_REPORT request to your hid device. Once it replies, you must tell + the kernel about it via UHID_SET_REPORT_REPLY. + The same restrictions as for UHID_GET_REPORT apply. + +---------------------------------------------------- +Written 2012, David Herrmann <dh.herrmann@gmail.com> diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index adf5e33e8312..e9c803ea306d 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 fa4b669c166b..a16924fbd289 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/infiniband/user_mad.txt b/Documentation/infiniband/user_mad.txt index 8a366959f5cc..7aca13a54a3a 100644 --- a/Documentation/infiniband/user_mad.txt +++ b/Documentation/infiniband/user_mad.txt @@ -26,6 +26,11 @@ Creating MAD agents ioctl. Also, all agents registered through a file descriptor will be unregistered when the descriptor is closed. + 2014 -- a new registration ioctl is now provided which allows additional + fields to be provided during registration. + Users of this registration call are implicitly setting the use of + pkey_index (see below). + Receiving MADs MADs are received using read(). The receive side now supports @@ -104,10 +109,10 @@ P_Key Index Handling The old ib_umad interface did not allow setting the P_Key index for MADs that are sent and did not provide a way for obtaining the P_Key index of received MADs. A new layout for struct ib_user_mad_hdr - with a pkey_index member has been defined; however, to preserve - binary compatibility with older applications, this new layout will - not be used unless the IB_USER_MAD_ENABLE_PKEY ioctl is called - before a file descriptor is used for anything else. + with a pkey_index member has been defined; however, to preserve binary + compatibility with older applications, this new layout will not be used + unless one of IB_USER_MAD_ENABLE_PKEY or IB_USER_MAD_REGISTER_AGENT2 ioctl's + are called before a file descriptor is used for anything else. In September 2008, the IB_USER_MAD_ABI_VERSION will be incremented to 6, the new layout of struct ib_user_mad_hdr will be used by diff --git a/Documentation/ioctl/00-INDEX b/Documentation/ioctl/00-INDEX index d2fe4d4729ef..c1a925787950 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 000000000000..45fe78c58019 --- /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/kbuild/00-INDEX b/Documentation/kbuild/00-INDEX index e8d2b6d83a3d..8c5e6aa78004 100644 --- a/Documentation/kbuild/00-INDEX +++ b/Documentation/kbuild/00-INDEX @@ -1,5 +1,7 @@ 00-INDEX - this file: info on the kernel build process +headers_install.txt + - how to export Linux headers for use by userspace kbuild.txt - developer information on kbuild kconfig.txt diff --git a/Documentation/make/headers_install.txt b/Documentation/kbuild/headers_install.txt index 951eb9f1e040..951eb9f1e040 100644 --- a/Documentation/make/headers_install.txt +++ b/Documentation/kbuild/headers_install.txt diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index c600e2f44a62..764f5991a3fc 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -23,11 +23,10 @@ This document describes the Linux kernel Makefiles. === 4 Host Program support --- 4.1 Simple Host Program --- 4.2 Composite Host Programs - --- 4.3 Defining shared libraries - --- 4.4 Using C++ for host programs - --- 4.5 Controlling compiler options for host programs - --- 4.6 When host programs are actually built - --- 4.7 Using hostprogs-$(CONFIG_FOO) + --- 4.3 Using C++ for host programs + --- 4.4 Controlling compiler options for host programs + --- 4.5 When host programs are actually built + --- 4.6 Using hostprogs-$(CONFIG_FOO) === 5 Kbuild clean infrastructure @@ -643,29 +642,7 @@ Both possibilities are described in the following. Finally, the two .o files are linked to the executable, lxdialog. Note: The syntax <executable>-y is not permitted for host-programs. ---- 4.3 Defining shared libraries - - Objects with extension .so are considered shared libraries, and - will be compiled as position independent objects. - Kbuild provides support for shared libraries, but the usage - shall be restricted. - In the following example the libkconfig.so shared library is used - to link the executable conf. - - Example: - #scripts/kconfig/Makefile - hostprogs-y := conf - conf-objs := conf.o libkconfig.so - libkconfig-objs := expr.o type.o - - Shared libraries always require a corresponding -objs line, and - in the example above the shared library libkconfig is composed by - the two objects expr.o and type.o. - expr.o and type.o will be built as position independent code and - linked as a shared library libkconfig.so. C++ is not supported for - shared libraries. - ---- 4.4 Using C++ for host programs +--- 4.3 Using C++ for host programs kbuild offers support for host programs written in C++. This was introduced solely to support kconfig, and is not recommended @@ -688,7 +665,7 @@ Both possibilities are described in the following. qconf-cxxobjs := qconf.o qconf-objs := check.o ---- 4.5 Controlling compiler options for host programs +--- 4.4 Controlling compiler options for host programs When compiling host programs, it is possible to set specific flags. The programs will always be compiled utilising $(HOSTCC) passed @@ -716,7 +693,7 @@ Both possibilities are described in the following. When linking qconf, it will be passed the extra option "-L$(QTDIR)/lib". ---- 4.6 When host programs are actually built +--- 4.5 When host programs are actually built Kbuild will only build host-programs when they are referenced as a prerequisite. @@ -747,7 +724,7 @@ Both possibilities are described in the following. This will tell kbuild to build lxdialog even if not referenced in any rule. ---- 4.7 Using hostprogs-$(CONFIG_FOO) +--- 4.6 Using hostprogs-$(CONFIG_FOO) A typical pattern in a Kbuild file looks like this: diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 883901b9ac4f..5ae8608ca9f5 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. @@ -1716,8 +1722,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 7 (KERN_DEBUG) debug-level messages log_buf_len=n[KMG] Sets the size of the printk ring buffer, - in bytes. n must be a power of two. The default - size is set in the kernel config file. + in bytes. n must be a power of two and greater + than the minimal size. The minimal size is defined + by LOG_BUF_SHIFT kernel config parameter. There is + also CONFIG_LOG_CPU_MAX_BUF_SHIFT config parameter + that allows to increase the default size depending on + the number of CPUs. See init/Kconfig for more details. logo.nologo [FB] Disables display of the built-in Linux logo. This may be used to provide more screen space for @@ -2190,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 @@ -3054,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. @@ -3728,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/00-INDEX b/Documentation/laptops/00-INDEX index d399ae1fc724..a3b4f209e562 100644 --- a/Documentation/laptops/00-INDEX +++ b/Documentation/laptops/00-INDEX @@ -18,3 +18,5 @@ sonypi.txt - info on Linux Sony Programmable I/O Device support. thinkpad-acpi.txt - information on the (IBM and Lenovo) ThinkPad ACPI Extras driver. +toshiba_haps.txt + - information on the Toshiba HDD Active Protection Sensor driver. diff --git a/Documentation/laptops/freefall.c b/Documentation/laptops/freefall.c index aab2ff09e868..5e44b20b1848 100644 --- a/Documentation/laptops/freefall.c +++ b/Documentation/laptops/freefall.c @@ -29,15 +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); 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/laptops/toshiba_haps.txt b/Documentation/laptops/toshiba_haps.txt new file mode 100644 index 000000000000..11dbcfdc9e7a --- /dev/null +++ b/Documentation/laptops/toshiba_haps.txt @@ -0,0 +1,76 @@ +Kernel driver toshiba_haps +Toshiba HDD Active Protection Sensor +==================================== + +Author: Azael Avalos <coproscefalo@gmail.com> + + +0. Contents +----------- + +1. Description +2. Interface +3. Accelerometer axes +4. Supported devices +5. Usage + + +1. Description +-------------- + +This driver provides support for the accelerometer found in various Toshiba +laptops, being called "Toshiba HDD Protection - Shock Sensor" officialy, +and detects laptops automatically with this device. +On Windows, Toshiba provided software monitors this device and provides +automatic HDD protection (head unload) on sudden moves or harsh vibrations, +however, this driver only provides a notification via a sysfs file to let +userspace tools or daemons act accordingly, as well as providing a sysfs +file to set the desired protection level or sensor sensibility. + + +2. Interface +------------ + +This device comes with 3 methods: +_STA - Checks existence of the device, returning Zero if the device does not + exists or is not supported. +PTLV - Sets the desired protection level. +RSSS - Shuts down the HDD protection interface for a few seconds, + then restores normal operation. + +Note: +The presence of Solid State Drives (SSD) can make this driver to fail loading, +given the fact that such drives have no movable parts, and thus, not requiring +any "protection" as well as failing during the evaluation of the _STA method +found under this device. + + +3. Accelerometer axes +--------------------- + +This device does not report any axes, however, to query the sensor position +a couple HCI (Hardware Configuration Interface) calls (0x6D and 0xA6) are +provided to query such information, handled by the kernel module toshiba_acpi +since kernel version 3.15. + + +4. Supported devices +-------------------- + +This driver binds itself to the ACPI device TOS620A, and any Toshiba laptop +with this device is supported, given the fact that they have the presence of +conventional HDD and not only SSD, or a combination of both HDD and SSD. + + +5. Usage +-------- + +The sysfs files under /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/ are: +protection_level - The protection_level is readable and writeable, and + provides a way to let userspace query the current protection + level, as well as set the desired protection level, the + available protection levels are: + 0 - Disabled | 1 - Low | 2 - Medium | 3 - High +reset_protection - The reset_protection entry is writeable only, being "1" + the only parameter it accepts, it is used to trigger + a reset of the protection interface. diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt index e3155995ddd8..beefb9f82902 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 6db73df04278..a68784d0a1ee 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 c02a003fa03a..000000000000 --- 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 335f3c6087dc..626052f403bb 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/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt index cda5f8fa2c66..1d508dcbf859 100644 --- a/Documentation/scsi/ncr53c8xx.txt +++ b/Documentation/scsi/ncr53c8xx.txt @@ -1095,7 +1095,7 @@ SCSI_NCR_SETUP_FORCE_SYNC_NEGO (default: not defined) SCSI_NCR_SETUP_MASTER_PARITY (default: defined) If defined, master parity checking is enabled. -SCSI_NCR_SETUP_MASTER_PARITY (default: defined) +SCSI_NCR_SETUP_SCSI_PARITY (default: defined) If defined, SCSI parity checking is enabled. SCSI_NCR_PROFILE_SUPPORT (default: not defined) diff --git a/Documentation/security/LSM.txt b/Documentation/security/LSM.txt index c335a763a2ed..3db7e671c440 100644 --- a/Documentation/security/LSM.txt +++ b/Documentation/security/LSM.txt @@ -22,7 +22,7 @@ system, building their checks on top of the defined capability hooks. For more details on capabilities, see capabilities(7) in the Linux man-pages project. -Based on http://kerneltrap.org/Linux/Documenting_Security_Module_Intent, +Based on https://lkml.org/lkml/2007/10/26/215, a new LSM is accepted into the kernel when its intent (a description of what it tries to protect against and in what cases one would expect to use it) has been appropriately documented in Documentation/security/. diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index c14374e71775..f79eb9666379 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/this_cpu_ops.txt b/Documentation/this_cpu_ops.txt index 1a4ce7e3e05f..0ec995712176 100644 --- a/Documentation/this_cpu_ops.txt +++ b/Documentation/this_cpu_ops.txt @@ -2,26 +2,26 @@ this_cpu operations ------------------- this_cpu operations are a way of optimizing access to per cpu -variables associated with the *currently* executing processor through -the use of segment registers (or a dedicated register where the cpu -permanently stored the beginning of the per cpu area for a specific -processor). +variables associated with the *currently* executing processor. This is +done through the use of segment registers (or a dedicated register where +the cpu permanently stored the beginning of the per cpu area for a +specific processor). -The this_cpu operations add a per cpu variable offset to the processor -specific percpu base and encode that operation in the instruction +this_cpu operations add a per cpu variable offset to the processor +specific per cpu base and encode that operation in the instruction operating on the per cpu variable. -This means there are no atomicity issues between the calculation of +This means that there are no atomicity issues between the calculation of the offset and the operation on the data. Therefore it is not -necessary to disable preempt or interrupts to ensure that the +necessary to disable preemption or interrupts to ensure that the processor is not changed between the calculation of the address and the operation on the data. Read-modify-write operations are of particular interest. Frequently processors have special lower latency instructions that can operate -without the typical synchronization overhead but still provide some -sort of relaxed atomicity guarantee. The x86 for example can execute -RMV (Read Modify Write) instructions like inc/dec/cmpxchg without the +without the typical synchronization overhead, but still provide some +sort of relaxed atomicity guarantees. The x86, for example, can execute +RMW (Read Modify Write) instructions like inc/dec/cmpxchg without the lock prefix and the associated latency penalty. Access to the variable without the lock prefix is not synchronized but @@ -30,6 +30,38 @@ data specific to the currently executing processor. Only the current processor should be accessing that variable and therefore there are no concurrency issues with other processors in the system. +Please note that accesses by remote processors to a per cpu area are +exceptional situations and may impact performance and/or correctness +(remote write operations) of local RMW operations via this_cpu_*. + +The main use of the this_cpu operations has been to optimize counter +operations. + +The following this_cpu() operations with implied preemption protection +are defined. These operations can be used without worrying about +preemption and interrupts. + + this_cpu_add() + this_cpu_read(pcp) + this_cpu_write(pcp, val) + this_cpu_add(pcp, val) + this_cpu_and(pcp, val) + this_cpu_or(pcp, val) + this_cpu_add_return(pcp, val) + this_cpu_xchg(pcp, nval) + this_cpu_cmpxchg(pcp, oval, nval) + this_cpu_cmpxchg_double(pcp1, pcp2, oval1, oval2, nval1, nval2) + this_cpu_sub(pcp, val) + this_cpu_inc(pcp) + this_cpu_dec(pcp) + this_cpu_sub_return(pcp, val) + this_cpu_inc_return(pcp) + this_cpu_dec_return(pcp) + + +Inner working of this_cpu operations +------------------------------------ + On x86 the fs: or the gs: segment registers contain the base of the per cpu area. It is then possible to simply use the segment override to relocate a per cpu relative address to the proper per cpu area for @@ -48,22 +80,21 @@ results in a single instruction mov ax, gs:[x] instead of a sequence of calculation of the address and then a fetch -from that address which occurs with the percpu operations. Before +from that address which occurs with the per cpu operations. Before this_cpu_ops such sequence also required preempt disable/enable to prevent the kernel from moving the thread to a different processor while the calculation is performed. -The main use of the this_cpu operations has been to optimize counter -operations. +Consider the following this_cpu operation: this_cpu_inc(x) -results in the following single instruction (no lock prefix!) +The above results in the following single instruction (no lock prefix!) inc gs:[x] instead of the following operations required if there is no segment -register. +register: int *y; int cpu; @@ -73,10 +104,10 @@ register. (*y)++; put_cpu(); -Note that these operations can only be used on percpu data that is +Note that these operations can only be used on per cpu data that is reserved for a specific processor. Without disabling preemption in the surrounding code this_cpu_inc() will only guarantee that one of the -percpu counters is correctly incremented. However, there is no +per cpu counters is correctly incremented. However, there is no guarantee that the OS will not move the process directly before or after the this_cpu instruction is executed. In general this means that the value of the individual counters for each processor are @@ -86,9 +117,9 @@ that is of interest. Per cpu variables are used for performance reasons. Bouncing cache lines can be avoided if multiple processors concurrently go through the same code paths. Since each processor has its own per cpu -variables no concurrent cacheline updates take place. The price that +variables no concurrent cache line updates take place. The price that has to be paid for this optimization is the need to add up the per cpu -counters when the value of the counter is needed. +counters when the value of a counter is needed. Special operations: @@ -100,33 +131,39 @@ Takes the offset of a per cpu variable (&x !) and returns the address of the per cpu variable that belongs to the currently executing processor. this_cpu_ptr avoids multiple steps that the common get_cpu/put_cpu sequence requires. No processor number is -available. Instead the offset of the local per cpu area is simply -added to the percpu offset. +available. Instead, the offset of the local per cpu area is simply +added to the per cpu offset. +Note that this operation is usually used in a code segment when +preemption has been disabled. The pointer is then used to +access local per cpu data in a critical section. When preemption +is re-enabled this pointer is usually no longer useful since it may +no longer point to per cpu data of the current processor. Per cpu variables and offsets ----------------------------- -Per cpu variables have *offsets* to the beginning of the percpu +Per cpu variables have *offsets* to the beginning of the per cpu area. They do not have addresses although they look like that in the code. Offsets cannot be directly dereferenced. The offset must be -added to a base pointer of a percpu area of a processor in order to +added to a base pointer of a per cpu area of a processor in order to form a valid address. Therefore the use of x or &x outside of the context of per cpu operations is invalid and will generally be treated like a NULL pointer dereference. -In the context of per cpu operations + DEFINE_PER_CPU(int, x); - x is a per cpu variable. Most this_cpu operations take a cpu - variable. +In the context of per cpu operations the above implies that x is a per +cpu variable. Most this_cpu operations take a cpu variable. - &x is the *offset* a per cpu variable. this_cpu_ptr() takes - the offset of a per cpu variable which makes this look a bit - strange. + int __percpu *p = &x; +&x and hence p is the *offset* of a per cpu variable. this_cpu_ptr() +takes the offset of a per cpu variable which makes this look a bit +strange. Operations on a field of a per cpu structure @@ -152,7 +189,7 @@ If we have an offset to struct s: struct s __percpu *ps = &p; - z = this_cpu_dec(ps->m); + this_cpu_dec(ps->m); z = this_cpu_inc_return(ps->n); @@ -172,29 +209,52 @@ if we do not make use of this_cpu ops later to manipulate fields: Variants of this_cpu ops ------------------------- -this_cpu ops are interrupt safe. Some architecture do not support +this_cpu ops are interrupt safe. Some architectures do not support these per cpu local operations. In that case the operation must be replaced by code that disables interrupts, then does the operations -that are guaranteed to be atomic and then reenable interrupts. Doing +that are guaranteed to be atomic and then re-enable interrupts. Doing so is expensive. If there are other reasons why the scheduler cannot change the processor we are executing on then there is no reason to -disable interrupts. For that purpose the __this_cpu operations are -provided. For example. - - __this_cpu_inc(x); - -Will increment x and will not fallback to code that disables +disable interrupts. For that purpose the following __this_cpu operations +are provided. + +These operations have no guarantee against concurrent interrupts or +preemption. If a per cpu variable is not used in an interrupt context +and the scheduler cannot preempt, then they are safe. If any interrupts +still occur while an operation is in progress and if the interrupt too +modifies the variable, then RMW actions can not be guaranteed to be +safe. + + __this_cpu_add() + __this_cpu_read(pcp) + __this_cpu_write(pcp, val) + __this_cpu_add(pcp, val) + __this_cpu_and(pcp, val) + __this_cpu_or(pcp, val) + __this_cpu_add_return(pcp, val) + __this_cpu_xchg(pcp, nval) + __this_cpu_cmpxchg(pcp, oval, nval) + __this_cpu_cmpxchg_double(pcp1, pcp2, oval1, oval2, nval1, nval2) + __this_cpu_sub(pcp, val) + __this_cpu_inc(pcp) + __this_cpu_dec(pcp) + __this_cpu_sub_return(pcp, val) + __this_cpu_inc_return(pcp) + __this_cpu_dec_return(pcp) + + +Will increment x and will not fall-back to code that disables interrupts on platforms that cannot accomplish atomicity through address relocation and a Read-Modify-Write operation in the same instruction. - &this_cpu_ptr(pp)->n vs this_cpu_ptr(&pp->n) -------------------------------------------- The first operation takes the offset and forms an address and then -adds the offset of the n field. +adds the offset of the n field. This may result in two add +instructions emitted by the compiler. The second one first adds the two offsets and then does the relocation. IMHO the second form looks cleaner and has an easier time @@ -202,4 +262,73 @@ with (). The second form also is consistent with the way this_cpu_read() and friends are used. -Christoph Lameter, April 3rd, 2013 +Remote access to per cpu data +------------------------------ + +Per cpu data structures are designed to be used by one cpu exclusively. +If you use the variables as intended, this_cpu_ops() are guaranteed to +be "atomic" as no other CPU has access to these data structures. + +There are special cases where you might need to access per cpu data +structures remotely. It is usually safe to do a remote read access +and that is frequently done to summarize counters. Remote write access +something which could be problematic because this_cpu ops do not +have lock semantics. A remote write may interfere with a this_cpu +RMW operation. + +Remote write accesses to percpu data structures are highly discouraged +unless absolutely necessary. Please consider using an IPI to wake up +the remote CPU and perform the update to its per cpu area. + +To access per-cpu data structure remotely, typically the per_cpu_ptr() +function is used: + + + DEFINE_PER_CPU(struct data, datap); + + struct data *p = per_cpu_ptr(&datap, cpu); + +This makes it explicit that we are getting ready to access a percpu +area remotely. + +You can also do the following to convert the datap offset to an address + + struct data *p = this_cpu_ptr(&datap); + +but, passing of pointers calculated via this_cpu_ptr to other cpus is +unusual and should be avoided. + +Remote access are typically only for reading the status of another cpus +per cpu data. Write accesses can cause unique problems due to the +relaxed synchronization requirements for this_cpu operations. + +One example that illustrates some concerns with write operations is +the following scenario that occurs because two per cpu variables +share a cache-line but the relaxed synchronization is applied to +only one process updating the cache-line. + +Consider the following example + + + struct test { + atomic_t a; + int b; + }; + + DEFINE_PER_CPU(struct test, onecacheline); + +There is some concern about what would happen if the field 'a' is updated +remotely from one processor and the local processor would use this_cpu ops +to update field b. Care should be taken that such simultaneous accesses to +data within the same cache line are avoided. Also costly synchronization +may be necessary. IPIs are generally recommended in such scenarios instead +of a remote write to the per cpu area of another processor. + +Even in cases where the remote writes are rare, please bear in +mind that a remote write will evict the cache line from the processor +that most likely will access it. If the processor wakes up and finds a +missing local cache line of a per cpu area, its performance and hence +the wake up times will be affected. + +Christoph Lameter, August 4th, 2014 +Pranith Kumar, Aug 2nd, 2014 diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl index 78c9a7b2b58f..8f961ef2b457 100644 --- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl +++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl @@ -47,6 +47,10 @@ use constant HIGH_KSWAPD_REWAKEUP => 21; use constant HIGH_NR_SCANNED => 22; use constant HIGH_NR_TAKEN => 23; use constant HIGH_NR_RECLAIMED => 24; +use constant HIGH_NR_FILE_SCANNED => 25; +use constant HIGH_NR_ANON_SCANNED => 26; +use constant HIGH_NR_FILE_RECLAIMED => 27; +use constant HIGH_NR_ANON_RECLAIMED => 28; my %perprocesspid; my %perprocess; @@ -56,14 +60,18 @@ my $opt_read_procstat; my $total_wakeup_kswapd; my ($total_direct_reclaim, $total_direct_nr_scanned); +my ($total_direct_nr_file_scanned, $total_direct_nr_anon_scanned); my ($total_direct_latency, $total_kswapd_latency); my ($total_direct_nr_reclaimed); +my ($total_direct_nr_file_reclaimed, $total_direct_nr_anon_reclaimed); my ($total_direct_writepage_file_sync, $total_direct_writepage_file_async); my ($total_direct_writepage_anon_sync, $total_direct_writepage_anon_async); my ($total_kswapd_nr_scanned, $total_kswapd_wake); +my ($total_kswapd_nr_file_scanned, $total_kswapd_nr_anon_scanned); my ($total_kswapd_writepage_file_sync, $total_kswapd_writepage_file_async); my ($total_kswapd_writepage_anon_sync, $total_kswapd_writepage_anon_async); my ($total_kswapd_nr_reclaimed); +my ($total_kswapd_nr_file_reclaimed, $total_kswapd_nr_anon_reclaimed); # Catch sigint and exit on request my $sigint_report = 0; @@ -374,6 +382,7 @@ EVENT_PROCESS: } my $isolate_mode = $1; my $nr_scanned = $4; + my $file = $6; # To closer match vmstat scanning statistics, only count isolate_both # and isolate_inactive as scanning. isolate_active is rotation @@ -382,6 +391,11 @@ EVENT_PROCESS: # isolate_both == 3 if ($isolate_mode != 2) { $perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned; + if ($file == 1) { + $perprocesspid{$process_pid}->{HIGH_NR_FILE_SCANNED} += $nr_scanned; + } else { + $perprocesspid{$process_pid}->{HIGH_NR_ANON_SCANNED} += $nr_scanned; + } } } elsif ($tracepoint eq "mm_vmscan_lru_shrink_inactive") { $details = $6; @@ -391,8 +405,19 @@ EVENT_PROCESS: print " $regex_lru_shrink_inactive/o\n"; next; } + my $nr_reclaimed = $4; + my $flags = $6; + my $file = 0; + if ($flags =~ /RECLAIM_WB_FILE/) { + $file = 1; + } $perprocesspid{$process_pid}->{HIGH_NR_RECLAIMED} += $nr_reclaimed; + if ($file) { + $perprocesspid{$process_pid}->{HIGH_NR_FILE_RECLAIMED} += $nr_reclaimed; + } else { + $perprocesspid{$process_pid}->{HIGH_NR_ANON_RECLAIMED} += $nr_reclaimed; + } } elsif ($tracepoint eq "mm_vmscan_writepage") { $details = $6; if ($details !~ /$regex_writepage/o) { @@ -493,7 +518,11 @@ sub dump_stats { $total_direct_reclaim += $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}; $total_wakeup_kswapd += $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}; $total_direct_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED}; + $total_direct_nr_file_scanned += $stats{$process_pid}->{HIGH_NR_FILE_SCANNED}; + $total_direct_nr_anon_scanned += $stats{$process_pid}->{HIGH_NR_ANON_SCANNED}; $total_direct_nr_reclaimed += $stats{$process_pid}->{HIGH_NR_RECLAIMED}; + $total_direct_nr_file_reclaimed += $stats{$process_pid}->{HIGH_NR_FILE_RECLAIMED}; + $total_direct_nr_anon_reclaimed += $stats{$process_pid}->{HIGH_NR_ANON_RECLAIMED}; $total_direct_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; $total_direct_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; $total_direct_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; @@ -513,7 +542,11 @@ sub dump_stats { $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}, $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}, $stats{$process_pid}->{HIGH_NR_SCANNED}, + $stats{$process_pid}->{HIGH_NR_FILE_SCANNED}, + $stats{$process_pid}->{HIGH_NR_ANON_SCANNED}, $stats{$process_pid}->{HIGH_NR_RECLAIMED}, + $stats{$process_pid}->{HIGH_NR_FILE_RECLAIMED}, + $stats{$process_pid}->{HIGH_NR_ANON_RECLAIMED}, $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}, $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}, $this_reclaim_delay / 1000); @@ -552,7 +585,11 @@ sub dump_stats { $total_kswapd_wake += $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}; $total_kswapd_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED}; + $total_kswapd_nr_file_scanned += $stats{$process_pid}->{HIGH_NR_FILE_SCANNED}; + $total_kswapd_nr_anon_scanned += $stats{$process_pid}->{HIGH_NR_ANON_SCANNED}; $total_kswapd_nr_reclaimed += $stats{$process_pid}->{HIGH_NR_RECLAIMED}; + $total_kswapd_nr_file_reclaimed += $stats{$process_pid}->{HIGH_NR_FILE_RECLAIMED}; + $total_kswapd_nr_anon_reclaimed += $stats{$process_pid}->{HIGH_NR_ANON_RECLAIMED}; $total_kswapd_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; $total_kswapd_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; $total_kswapd_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; @@ -563,7 +600,11 @@ sub dump_stats { $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}, $stats{$process_pid}->{HIGH_KSWAPD_REWAKEUP}, $stats{$process_pid}->{HIGH_NR_SCANNED}, + $stats{$process_pid}->{HIGH_NR_FILE_SCANNED}, + $stats{$process_pid}->{HIGH_NR_ANON_SCANNED}, $stats{$process_pid}->{HIGH_NR_RECLAIMED}, + $stats{$process_pid}->{HIGH_NR_FILE_RECLAIMED}, + $stats{$process_pid}->{HIGH_NR_ANON_RECLAIMED}, $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}, $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}); @@ -594,7 +635,11 @@ sub dump_stats { print "\nSummary\n"; print "Direct reclaims: $total_direct_reclaim\n"; print "Direct reclaim pages scanned: $total_direct_nr_scanned\n"; + print "Direct reclaim file pages scanned: $total_direct_nr_file_scanned\n"; + print "Direct reclaim anon pages scanned: $total_direct_nr_anon_scanned\n"; print "Direct reclaim pages reclaimed: $total_direct_nr_reclaimed\n"; + print "Direct reclaim file pages reclaimed: $total_direct_nr_file_reclaimed\n"; + print "Direct reclaim anon pages reclaimed: $total_direct_nr_anon_reclaimed\n"; print "Direct reclaim write file sync I/O: $total_direct_writepage_file_sync\n"; print "Direct reclaim write anon sync I/O: $total_direct_writepage_anon_sync\n"; print "Direct reclaim write file async I/O: $total_direct_writepage_file_async\n"; @@ -604,7 +649,11 @@ sub dump_stats { print "\n"; print "Kswapd wakeups: $total_kswapd_wake\n"; print "Kswapd pages scanned: $total_kswapd_nr_scanned\n"; + print "Kswapd file pages scanned: $total_kswapd_nr_file_scanned\n"; + print "Kswapd anon pages scanned: $total_kswapd_nr_anon_scanned\n"; print "Kswapd pages reclaimed: $total_kswapd_nr_reclaimed\n"; + print "Kswapd file pages reclaimed: $total_kswapd_nr_file_reclaimed\n"; + print "Kswapd anon pages reclaimed: $total_kswapd_nr_anon_reclaimed\n"; print "Kswapd reclaim write file sync I/O: $total_kswapd_writepage_file_sync\n"; print "Kswapd reclaim write anon sync I/O: $total_kswapd_writepage_anon_sync\n"; print "Kswapd reclaim write file async I/O: $total_kswapd_writepage_file_async\n"; @@ -629,7 +678,11 @@ sub aggregate_perprocesspid() { $perprocess{$process}->{MM_VMSCAN_WAKEUP_KSWAPD} += $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}; $perprocess{$process}->{HIGH_KSWAPD_REWAKEUP} += $perprocesspid{$process_pid}->{HIGH_KSWAPD_REWAKEUP}; $perprocess{$process}->{HIGH_NR_SCANNED} += $perprocesspid{$process_pid}->{HIGH_NR_SCANNED}; + $perprocess{$process}->{HIGH_NR_FILE_SCANNED} += $perprocesspid{$process_pid}->{HIGH_NR_FILE_SCANNED}; + $perprocess{$process}->{HIGH_NR_ANON_SCANNED} += $perprocesspid{$process_pid}->{HIGH_NR_ANON_SCANNED}; $perprocess{$process}->{HIGH_NR_RECLAIMED} += $perprocesspid{$process_pid}->{HIGH_NR_RECLAIMED}; + $perprocess{$process}->{HIGH_NR_FILE_RECLAIMED} += $perprocesspid{$process_pid}->{HIGH_NR_FILE_RECLAIMED}; + $perprocess{$process}->{HIGH_NR_ANON_RECLAIMED} += $perprocesspid{$process_pid}->{HIGH_NR_ANON_RECLAIMED}; $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt index b9ca02370d46..96978eced341 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 68cda1fc3d52..beae3fde075e 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. diff --git a/Documentation/x86/tlb.txt b/Documentation/x86/tlb.txt index 2b3a82e69151..39d172326703 100644 --- a/Documentation/x86/tlb.txt +++ b/Documentation/x86/tlb.txt @@ -35,7 +35,7 @@ invlpg instruction (or instructions _near_ it) show up high in profiles. If you believe that individual invalidations being called too often, you can lower the tunable: - /sys/debug/kernel/x86/tlb_single_page_flush_ceiling + /sys/kernel/debug/x86/tlb_single_page_flush_ceiling This will cause us to do the global flush for more cases. Lowering it to 0 will disable the use of the individual flushes. diff --git a/Documentation/zh_CN/SubmittingDrivers b/Documentation/zh_CN/SubmittingDrivers index 5889f8df6312..d313f5d8448d 100644 --- a/Documentation/zh_CN/SubmittingDrivers +++ b/Documentation/zh_CN/SubmittingDrivers @@ -150,10 +150,6 @@ LWN.net: 将旧版内核的驱动程序移植到 2.6 版： http://lwn.net/Articles/driver-porting/ -KernelTrap： - Linux 内核的最新动态以及开发者访谈 - http://kerneltrap.org/ - 内核新手(KernelNewbies): 为新的内核开发者提供文档和帮助 http://kernelnewbies.org/ |