diff options
Diffstat (limited to 'Documentation')
160 files changed, 5015 insertions, 779 deletions
diff --git a/Documentation/ABI/stable/sysfs-bus-usb b/Documentation/ABI/stable/sysfs-bus-usb index a6b685724740..e2bc700a6f9c 100644 --- a/Documentation/ABI/stable/sysfs-bus-usb +++ b/Documentation/ABI/stable/sysfs-bus-usb @@ -3,13 +3,13 @@ Date: May 2007 KernelVersion: 2.6.23 Contact: Alan Stern <stern@rowland.harvard.edu> Description: - If CONFIG_USB_PERSIST is set, then each USB device directory - will contain a file named power/persist. The file holds a - boolean value (0 or 1) indicating whether or not the - "USB-Persist" facility is enabled for the device. Since the - facility is inherently dangerous, it is disabled by default - for all devices except hubs. For more information, see - Documentation/usb/persist.txt. + USB device directories can contain a file named power/persist. + The file holds a boolean value (0 or 1) indicating whether or + not the "USB-Persist" facility is enabled for the device. For + hubs this facility is always enabled and their device + directories will not contain this file. + + For more information, see Documentation/usb/persist.txt. What: /sys/bus/usb/devices/.../power/autosuspend Date: March 2007 diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index 4c3efe434806..d0d0c578324c 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -26,6 +26,7 @@ Description: option: [[appraise_type=]] [permit_directio] base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK] + [FIRMWARE_CHECK] mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC] fsmagic:= hex value fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6) @@ -57,7 +58,8 @@ Description: measure func=BPRM_CHECK measure func=FILE_MMAP mask=MAY_EXEC measure func=FILE_CHECK mask=MAY_READ uid=0 - measure func=MODULE_CHECK uid=0 + measure func=MODULE_CHECK + measure func=FIRMWARE_CHECK appraise fowner=0 The default policy measures all executables in bprm_check, diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index a9757dcf2e81..d760b0224ef7 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -260,6 +260,10 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_scale +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale KernelVersion: 2.6.35 @@ -447,6 +451,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en What: /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en @@ -492,6 +504,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_roc_rising_en What: /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en What: /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_falling_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_rising_en +What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_roc_rising_en @@ -538,6 +558,14 @@ What: /sys/.../events/in_magn_y_raw_thresh_rising_value What: /sys/.../events/in_magn_y_raw_thresh_falling_value What: /sys/.../events/in_magn_z_raw_thresh_rising_value What: /sys/.../events/in_magn_z_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_magnetic_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_magnetic_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_true_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_true_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_falling_value +What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_rising_value +What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_falling_value What: /sys/.../events/in_voltageY_supply_raw_thresh_rising_value What: /sys/.../events/in_voltageY_supply_raw_thresh_falling_value What: /sys/.../events/in_voltageY_raw_thresh_rising_value @@ -588,6 +616,18 @@ What: /sys/.../events/in_magn_y_thresh_either_hysteresis What: /sys/.../events/in_magn_z_thresh_rising_hysteresis What: /sys/.../events/in_magn_z_thresh_falling_hysteresis What: /sys/.../events/in_magn_z_thresh_either_hysteresis +What: /sys/.../events/in_rot_from_north_magnetic_thresh_rising_hysteresis +What: /sys/.../events/in_rot_from_north_magnetic_thresh_falling_hysteresis +What: /sys/.../events/in_rot_from_north_magnetic_thresh_either_hysteresis +What: /sys/.../events/in_rot_from_north_true_thresh_rising_hysteresis +What: /sys/.../events/in_rot_from_north_true_thresh_falling_hysteresis +What: /sys/.../events/in_rot_from_north_true_thresh_either_hysteresis +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_hysteresis +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_hysteresis +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_either_hysteresis +What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_rising_hysteresis +What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_falling_hysteresis +What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_either_hysteresis What: /sys/.../events/in_voltageY_thresh_rising_hysteresis What: /sys/.../events/in_voltageY_thresh_falling_hysteresis What: /sys/.../events/in_voltageY_thresh_either_hysteresis @@ -635,6 +675,14 @@ What: /sys/.../events/in_magn_y_raw_roc_rising_value What: /sys/.../events/in_magn_y_raw_roc_falling_value What: /sys/.../events/in_magn_z_raw_roc_rising_value What: /sys/.../events/in_magn_z_raw_roc_falling_value +What: /sys/.../events/in_rot_from_north_magnetic_raw_roc_rising_value +What: /sys/.../events/in_rot_from_north_magnetic_raw_roc_falling_value +What: /sys/.../events/in_rot_from_north_true_raw_roc_rising_value +What: /sys/.../events/in_rot_from_north_true_raw_roc_falling_value +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_roc_rising_value +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_roc_falling_value +What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_roc_rising_value +What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_roc_falling_value What: /sys/.../events/in_voltageY_supply_raw_roc_rising_value What: /sys/.../events/in_voltageY_supply_raw_roc_falling_value What: /sys/.../events/in_voltageY_raw_roc_rising_value @@ -690,6 +738,22 @@ What: /sys/.../events/in_magn_z_thresh_rising_period What: /sys/.../events/in_magn_z_thresh_falling_period What: /sys/.../events/in_magn_z_roc_rising_period What: /sys/.../events/in_magn_z_roc_falling_period +What: /sys/.../events/in_rot_from_north_magnetic_thresh_rising_period +What: /sys/.../events/in_rot_from_north_magnetic_thresh_falling_period +What: /sys/.../events/in_rot_from_north_magnetic_roc_rising_period +What: /sys/.../events/in_rot_from_north_magnetic_roc_falling_period +What: /sys/.../events/in_rot_from_north_true_thresh_rising_period +What: /sys/.../events/in_rot_from_north_true_thresh_falling_period +What: /sys/.../events/in_rot_from_north_true_roc_rising_period +What: /sys/.../events/in_rot_from_north_true_roc_falling_period +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_period +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_period +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_roc_rising_period +What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_roc_falling_period +What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_rising_period +What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_falling_period +What: /sys/.../events/in_rot_from_north_true_tilt_comp_roc_rising_period +What: /sys/.../events/in_rot_from_north_true_tilt_comp_roc_falling_period What: /sys/.../events/in_voltageY_supply_thresh_rising_period What: /sys/.../events/in_voltageY_supply_thresh_falling_period What: /sys/.../events/in_voltageY_supply_roc_rising_period @@ -787,6 +851,10 @@ What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_en +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_en +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_en +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_en What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en @@ -853,6 +921,10 @@ What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_index +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_index +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_index +What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_index What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index @@ -895,6 +967,19 @@ Description: on-chip EEPROM. After power-up or chip reset the device will automatically load the saved configuration. +What: /sys/.../iio:deviceX/in_proximity_raw +What: /sys/.../iio:deviceX/in_proximity_input +What: /sys/.../iio:deviceX/in_proximityY_raw +KernelVersion: 3.4 +Contact: linux-iio@vger.kernel.org +Description: + Proximity measurement indicating that some + object is near the sensor, usually be observing + reflectivity of infrared or ultrasound emitted. + Often these sensors are unit less and as such conversion + to SI units is not possible. Where it is, the units should + be meters. + What: /sys/.../iio:deviceX/in_illuminanceY_input What: /sys/.../iio:deviceX/in_illuminanceY_raw What: /sys/.../iio:deviceX/in_illuminanceY_mean_raw @@ -933,3 +1018,13 @@ Description: x y z w. Here x, y, and z component represents the axis about which a rotation will occur and w component represents the amount of rotation. + +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_raw +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_raw +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_raw +What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_raw +KernelVersion: 3.15 +Contact: linux-iio@vger.kernel.org +Description: + Raw value of rotation from true/magnetic north measured with + or without compensation from tilt sensors. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs new file mode 100644 index 000000000000..5235e6c749ab --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs @@ -0,0 +1,11 @@ +What: /sys/bus/iio/devices/triggerX/trigger_now +KernelVersion: 2.6.38 +Contact: linux-iio@vger.kernel.org +Description: + This file is provided by the iio-trig-sysfs stand-alone trigger + driver. Writing this file with any value triggers an event + driven driver, associated with this trigger, to capture data + into an in kernel buffer. This approach can be valuable during + automated testing or in situations, where other trigger methods + are not applicable. For example no RTC or spare GPIOs. + X is the IIO index of the trigger. diff --git a/Documentation/ABI/testing/sysfs-bus-platform b/Documentation/ABI/testing/sysfs-bus-platform new file mode 100644 index 000000000000..5172a6124b27 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-platform @@ -0,0 +1,20 @@ +What: /sys/bus/platform/devices/.../driver_override +Date: April 2014 +Contact: Kim Phillips <kim.phillips@freescale.com> +Description: + This file allows the driver for a device to be specified which + will override standard OF, ACPI, ID table, and name matching. + When specified, only a driver with a name matching the value + written to driver_override will have an opportunity to bind + to the device. The override is specified by writing a string + to the driver_override file (echo vfio-platform > \ + driver_override) and may be cleared with an empty string + (echo > driver_override). This returns the device to standard + matching rules binding. Writing to driver_override does not + automatically unbind the device from its current driver or make + any attempt to automatically load the specified driver. If no + driver with a matching name is currently loaded in the kernel, + the device will not bind to any driver. This also allows + devices to opt-out of driver binding using a driver_override + name such as "none". Only a single driver may be specified in + the override, there is no support for parsing delimiters. diff --git a/Documentation/ABI/testing/sysfs-bus-usb-lvstest b/Documentation/ABI/testing/sysfs-bus-usb-lvstest new file mode 100644 index 000000000000..aae68fc2d842 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-usb-lvstest @@ -0,0 +1,47 @@ +Link Layer Validation Device is a standard device for testing of Super +Speed Link Layer tests. These nodes are available in sysfs only when lvs +driver is bound with root hub device. + +What: /sys/bus/usb/devices/.../get_dev_desc +Date: March 2014 +Contact: Pratyush Anand <pratyush.anand@st.com> +Description: + Write to this node to issue "Get Device Descriptor" + for Link Layer Validation device. It is needed for TD.7.06. + +What: /sys/bus/usb/devices/.../u1_timeout +Date: March 2014 +Contact: Pratyush Anand <pratyush.anand@st.com> +Description: + Set "U1 timeout" for the downstream port where Link Layer + Validation device is connected. Timeout value must be between 0 + and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21. + +What: /sys/bus/usb/devices/.../u2_timeout +Date: March 2014 +Contact: Pratyush Anand <pratyush.anand@st.com> +Description: + Set "U2 timeout" for the downstream port where Link Layer + Validation device is connected. Timeout value must be between 0 + and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21. + +What: /sys/bus/usb/devices/.../hot_reset +Date: March 2014 +Contact: Pratyush Anand <pratyush.anand@st.com> +Description: + Write to this node to issue "Reset" for Link Layer Validation + device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35. + +What: /sys/bus/usb/devices/.../u3_entry +Date: March 2014 +Contact: Pratyush Anand <pratyush.anand@st.com> +Description: + Write to this node to issue "U3 entry" for Link Layer + Validation device. It is needed for TD.7.35 and TD.7.36. + +What: /sys/bus/usb/devices/.../u3_exit +Date: March 2014 +Contact: Pratyush Anand <pratyush.anand@st.com> +Description: + Write to this node to issue "U3 exit" for Link Layer + Validation device. It is needed for TD.7.36. diff --git a/Documentation/ABI/testing/sysfs-class-iommu b/Documentation/ABI/testing/sysfs-class-iommu new file mode 100644 index 000000000000..6d0a1b4be82d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-iommu @@ -0,0 +1,17 @@ +What: /sys/class/iommu/<iommu>/devices/ +Date: June 2014 +KernelVersion: 3.17 +Contact: Alex Williamson <alex.williamson@redhat.com> +Description: + IOMMU drivers are able to link devices managed by a + given IOMMU here to allow association of IOMMU to + device. + +What: /sys/devices/.../iommu +Date: June 2014 +KernelVersion: 3.17 +Contact: Alex Williamson <alex.williamson@redhat.com> +Description: + IOMMU drivers are able to link the IOMMU for a + given device here to allow association of device to + IOMMU. diff --git a/Documentation/ABI/testing/sysfs-class-iommu-amd-iommu b/Documentation/ABI/testing/sysfs-class-iommu-amd-iommu new file mode 100644 index 000000000000..d6ba8e8a4a97 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-iommu-amd-iommu @@ -0,0 +1,14 @@ +What: /sys/class/iommu/<iommu>/amd-iommu/cap +Date: June 2014 +KernelVersion: 3.17 +Contact: Alex Williamson <alex.williamson@redhat.com> +Description: + IOMMU capability header as documented in the AMD IOMMU + specification. Format: %x + +What: /sys/class/iommu/<iommu>/amd-iommu/features +Date: June 2014 +KernelVersion: 3.17 +Contact: Alex Williamson <alex.williamson@redhat.com> +Description: + Extended features of the IOMMU. Format: %llx diff --git a/Documentation/ABI/testing/sysfs-class-iommu-intel-iommu b/Documentation/ABI/testing/sysfs-class-iommu-intel-iommu new file mode 100644 index 000000000000..258cc246d98e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-iommu-intel-iommu @@ -0,0 +1,32 @@ +What: /sys/class/iommu/<iommu>/intel-iommu/address +Date: June 2014 +KernelVersion: 3.17 +Contact: Alex Williamson <alex.williamson@redhat.com> +Description: + Physical address of the VT-d DRHD for this IOMMU. + Format: %llx. This allows association of a sysfs + intel-iommu with a DMAR DRHD table entry. + +What: /sys/class/iommu/<iommu>/intel-iommu/cap +Date: June 2014 +KernelVersion: 3.17 +Contact: Alex Williamson <alex.williamson@redhat.com> +Description: + The cached hardware capability register value + of this DRHD unit. Format: %llx. + +What: /sys/class/iommu/<iommu>/intel-iommu/ecap +Date: June 2014 +KernelVersion: 3.17 +Contact: Alex Williamson <alex.williamson@redhat.com> +Description: + The cached hardware extended capability register + value of this DRHD unit. Format: %llx. + +What: /sys/class/iommu/<iommu>/intel-iommu/version +Date: June 2014 +KernelVersion: 3.17 +Contact: Alex Williamson <alex.williamson@redhat.com> +Description: + The architecture version as reported from the + VT-d VER_REG. Format: %d:%d, major:minor diff --git a/Documentation/ABI/testing/sysfs-class-mei b/Documentation/ABI/testing/sysfs-class-mei new file mode 100644 index 000000000000..0ec8b8178c41 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-mei @@ -0,0 +1,16 @@ +What: /sys/class/mei/ +Date: May 2014 +KernelVersion: 3.17 +Contact: Tomas Winkler <tomas.winkler@intel.com> +Description: + The mei/ class sub-directory belongs to mei device class + + +What: /sys/class/mei/meiN/ +Date: May 2014 +KernelVersion: 3.17 +Contact: Tomas Winkler <tomas.winkler@intel.com> +Description: + The /sys/class/mei/meiN directory is created for + each probed mei device + diff --git a/Documentation/ABI/testing/sysfs-driver-genwqe b/Documentation/ABI/testing/sysfs-driver-genwqe index 1870737a1f5e..64ac6d567c4b 100644 --- a/Documentation/ABI/testing/sysfs-driver-genwqe +++ b/Documentation/ABI/testing/sysfs-driver-genwqe @@ -25,6 +25,15 @@ Date: Oct 2013 Contact: haver@linux.vnet.ibm.com Description: Interface to set the next bitstream to be used. +What: /sys/class/genwqe/genwqe<n>_card/reload_bitstream +Date: May 2014 +Contact: klebers@linux.vnet.ibm.com +Description: Interface to trigger a PCIe card reset to reload the bitstream. + sudo sh -c 'echo 1 > \ + /sys/class/genwqe/genwqe0_card/reload_bitstream' + If successfully, the card will come back with the bitstream set + on 'next_bitstream'. + What: /sys/class/genwqe/genwqe<n>_card/tempsens Date: Oct 2013 Contact: haver@linux.vnet.ibm.com diff --git a/Documentation/ABI/testing/sysfs-platform-ts5500 b/Documentation/ABI/testing/sysfs-platform-ts5500 index c88375a537a1..e685957caa12 100644 --- a/Documentation/ABI/testing/sysfs-platform-ts5500 +++ b/Documentation/ABI/testing/sysfs-platform-ts5500 @@ -30,6 +30,13 @@ Description: the corresponding bit is set. For instance, 0x0e means jumpers 2, 3 and 4 are set. +What: /sys/devices/platform/ts5500/name +Date: July 2014 +KernelVersion: 3.16 +Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com> +Description: + Model name of the TS board, e.g. "TS-5500". + What: /sys/devices/platform/ts5500/rs485 Date: January 2013 KernelVersion: 3.7 diff --git a/Documentation/ABI/testing/sysfs-tty b/Documentation/ABI/testing/sysfs-tty index ad22fb0ee765..9eb3c2b6b040 100644 --- a/Documentation/ABI/testing/sysfs-tty +++ b/Documentation/ABI/testing/sysfs-tty @@ -138,3 +138,19 @@ Description: These sysfs values expose the TIOCGSERIAL interface via sysfs rather than via ioctls. + +What: /sys/class/tty/ttyS0/rx_trig_bytes +Date: May 2014 +Contact: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com> +Description: + Shows current RX interrupt trigger bytes or sets the + user specified value to change it for the FIFO buffer. + Users can show or set this value regardless of opening the + serial device file or not. + + The RX trigger can be set one of four kinds of values for UART + serials. When users input a meaning less value to this I/F, + the RX trigger is changed to the nearest lower value for the + device specification. For example, when user sets 7bytes on + 16550A, which has 1/4/8/14 bytes trigger, the RX trigger is + automatically changed to 4 bytes. diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index cc63f30de166..f2130586ef5d 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -54,7 +54,7 @@ !Ikernel/sched/cpupri.c !Ikernel/sched/fair.c !Iinclude/linux/completion.h -!Ekernel/timer.c +!Ekernel/time/timer.c </sect1> <sect1><title>Wait queues and Wake events</title> !Iinclude/linux/wait.h @@ -63,7 +63,7 @@ <sect1><title>High-resolution timers</title> !Iinclude/linux/ktime.h !Iinclude/linux/hrtimer.h -!Ekernel/hrtimer.c +!Ekernel/time/hrtimer.c </sect1> <sect1><title>Workqueues and Kevents</title> !Ekernel/workqueue.c @@ -128,8 +128,12 @@ X!Edrivers/base/interface.c !Edrivers/base/bus.c </sect1> <sect1><title>Device Drivers DMA Management</title> -!Edrivers/base/dma-buf.c -!Edrivers/base/reservation.c +!Edrivers/dma-buf/dma-buf.c +!Edrivers/dma-buf/fence.c +!Edrivers/dma-buf/seqno-fence.c +!Iinclude/linux/fence.h +!Iinclude/linux/seqno-fence.h +!Edrivers/dma-buf/reservation.c !Iinclude/linux/reservation.h !Edrivers/base/dma-coherent.c !Edrivers/base/dma-mapping.c diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl index 2c425d70f7e2..641629221176 100644 --- a/Documentation/DocBook/gadget.tmpl +++ b/Documentation/DocBook/gadget.tmpl @@ -556,11 +556,11 @@ been converted to this framework. Near-term plans include converting all of them, except for "gadgetfs". </para> -!Edrivers/usb/gadget/f_acm.c -!Edrivers/usb/gadget/f_ecm.c -!Edrivers/usb/gadget/f_subset.c -!Edrivers/usb/gadget/f_obex.c -!Edrivers/usb/gadget/f_serial.c +!Edrivers/usb/gadget/function/f_acm.c +!Edrivers/usb/gadget/function/f_ecm.c +!Edrivers/usb/gadget/function/f_subset.c +!Edrivers/usb/gadget/function/f_obex.c +!Edrivers/usb/gadget/function/f_serial.c </sect1> diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 639e74857968..df2962d9e11e 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -174,7 +174,7 @@ FILENAME = \ DOCUMENTED = \ -e "s/\(enum *\)v4l2_mpeg_cx2341x_video_\([a-z]*_spatial_filter_type\)/\1<link linkend=\"\2\">v4l2_mpeg_cx2341x_video_\2<\/link>/g" \ -e "s/\(\(enum\|struct\) *\)\(v4l2_[a-zA-Z0-9_]*\)/\1<link linkend=\"\3\">\3<\/link>/g" \ - -e "s/\(V4L2_PIX_FMT_[A-Z0-9_]\+\) /<link linkend=\"\1\">\1<\/link> /g" \ + -e "s/\(V4L2_PIX_FMT_[A-Z0-9_]\+\)\(\s\+v4l2_fourcc\)/<link linkend=\"\1\">\1<\/link>\2/g" \ -e ":a;s/\(linkend=\".*\)_\(.*\">\)/\1-\2/;ta" \ -e "s/v4l2\-mpeg\-vbi\-ITV0/v4l2-mpeg-vbi-itv0-1/g" diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index 24c22cabc668..948ddaab592e 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml @@ -555,10 +555,46 @@ typedef enum fe_delivery_system { </section> <section id="DTV-ISDBT-LAYER-TIME-INTERLEAVING"> <title><constant>DTV_ISDBT_LAYER*_TIME_INTERLEAVING</constant></title> - <para>Possible values: 0, 1, 2, 3, -1 (AUTO)</para> - <para>Note: The real inter-leaver depth-names depend on the mode (fft-size); the values - here are referring to what can be found in the TMCC-structure - - independent of the mode.</para> + <para>Valid values: 0, 1, 2, 4, -1 (AUTO)</para> + <para>when DTV_ISDBT_SOUND_BROADCASTING is active, value 8 is also valid.</para> + <para>Note: The real time interleaving length depends on the mode (fft-size). The values + here are referring to what can be found in the TMCC-structure, as shown in the table below.</para> + <informaltable id="isdbt-layer-interleaving-table"> + <tgroup cols="4" align="center"> + <tbody> + <row> + <entry>DTV_ISDBT_LAYER*_TIME_INTERLEAVING</entry> + <entry>Mode 1 (2K FFT)</entry> + <entry>Mode 2 (4K FFT)</entry> + <entry>Mode 3 (8K FFT)</entry> + </row> + <row> + <entry>0</entry> + <entry>0</entry> + <entry>0</entry> + <entry>0</entry> + </row> + <row> + <entry>1</entry> + <entry>4</entry> + <entry>2</entry> + <entry>1</entry> + </row> + <row> + <entry>2</entry> + <entry>8</entry> + <entry>4</entry> + <entry>2</entry> + </row> + <row> + <entry>4</entry> + <entry>16</entry> + <entry>8</entry> + <entry>4</entry> + </row> + </tbody> + </tgroup> + </informaltable> </section> <section id="DTV-ATSCMH-FIC-VER"> <title><constant>DTV_ATSCMH_FIC_VER</constant></title> diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 47198eef75a4..9f5ffd85560b 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -13,6 +13,19 @@ correctly with any device.</para> <para>All controls are accessed using an ID value. V4L2 defines several IDs for specific purposes. Drivers can also implement their own custom controls using <constant>V4L2_CID_PRIVATE_BASE</constant> +<footnote><para>The use of <constant>V4L2_CID_PRIVATE_BASE</constant> +is problematic because different drivers may use the same +<constant>V4L2_CID_PRIVATE_BASE</constant> ID for different controls. +This makes it hard to programatically set such controls since the meaning +of the control with that ID is driver dependent. In order to resolve this +drivers use unique IDs and the <constant>V4L2_CID_PRIVATE_BASE</constant> +IDs are mapped to those unique IDs by the kernel. Consider these +<constant>V4L2_CID_PRIVATE_BASE</constant> IDs as aliases to the real +IDs.</para> +<para>Many applications today still use the <constant>V4L2_CID_PRIVATE_BASE</constant> +IDs instead of using &VIDIOC-QUERYCTRL; with the <constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> +flag to enumerate all IDs, so support for <constant>V4L2_CID_PRIVATE_BASE</constant> +is still around.</para></footnote> and higher values. The pre-defined control IDs have the prefix <constant>V4L2_CID_</constant>, and are listed in <xref linkend="control-id" />. The ID is used when querying the attributes of @@ -31,25 +44,22 @@ the current video input or output, tuner or modulator, or audio input or output. Different in the sense of other bounds, another default and current value, step size or other menu items. A control with a certain <emphasis>custom</emphasis> ID can also change name and -type.<footnote> - <para>It will be more convenient for applications if drivers -make use of the <constant>V4L2_CTRL_FLAG_DISABLED</constant> flag, but -that was never required.</para> - </footnote> Control values are stored globally, they do not +type.</para> + + <para>If a control is not applicable to the current configuration +of the device (for example, it doesn't apply to the current video input) +drivers set the <constant>V4L2_CTRL_FLAG_INACTIVE</constant> flag.</para> + + <para>Control values are stored globally, they do not change when switching except to stay within the reported bounds. They also do not change ⪚ when the device is opened or closed, when the tuner radio frequency is changed or generally never without -application request. Since V4L2 specifies no event mechanism, panel -applications intended to cooperate with other panel applications (be -they built into a larger application, as a TV viewer) may need to -regularly poll control values to update their user -interface.<footnote> - <para>Applications could call an ioctl to request events. -After another process called &VIDIOC-S-CTRL; or another ioctl changing -shared properties the &func-select; function would indicate -readability until any ioctl (querying the properties) is -called.</para> - </footnote></para> +application request.</para> + + <para>V4L2 specifies an event mechanism to notify applications +when controls change value (see &VIDIOC-SUBSCRIBE-EVENT;, event +<constant>V4L2_EVENT_CTRL</constant>), panel applications might want to make +use of that in order to always reflect the correct control value.</para> <para> All controls use machine endianness. @@ -398,14 +408,17 @@ to work.</entry> <row id="v4l2-alpha-component"> <entry><constant>V4L2_CID_ALPHA_COMPONENT</constant></entry> <entry>integer</entry> - <entry> Sets the alpha color component on the capture device or on - the capture buffer queue of a mem-to-mem device. When a mem-to-mem - device produces frame format that includes an alpha component + <entry>Sets the alpha color component. When a capture device (or + capture queue of a mem-to-mem device) produces a frame format that + includes an alpha component (e.g. <link linkend="rgb-formats">packed RGB image formats</link>) - and the alpha value is not defined by the mem-to-mem input data - this control lets you select the alpha component value of all - pixels. It is applicable to any pixel format that contains an alpha - component. + and the alpha value is not defined by the device or the mem-to-mem + input data this control lets you select the alpha component value of + all pixels. When an output device (or output queue of a mem-to-mem + device) consumes a frame format that doesn't include an alpha + component and the device supports alpha channel processing this + control lets you set the alpha component value of all pixels for + further processing in the device. </entry> </row> <row> @@ -434,127 +447,152 @@ Drivers must implement <constant>VIDIOC_QUERYCTRL</constant>, controls, <constant>VIDIOC_QUERYMENU</constant> when it has one or more menu type controls.</para> - <example> - <title>Enumerating all controls</title> + <example id="enum_all_controls"> + <title>Enumerating all user controls</title> <programlisting> &v4l2-queryctrl; queryctrl; &v4l2-querymenu; querymenu; -static void -enumerate_menu (void) +static void enumerate_menu(void) { - printf (" Menu items:\n"); + printf(" Menu items:\n"); - memset (&querymenu, 0, sizeof (querymenu)); + memset(&querymenu, 0, sizeof(querymenu)); querymenu.id = queryctrl.id; for (querymenu.index = queryctrl.minimum; querymenu.index <= queryctrl.maximum; - querymenu.index++) { - if (0 == ioctl (fd, &VIDIOC-QUERYMENU;, &querymenu)) { - printf (" %s\n", querymenu.name); + querymenu.index++) { + if (0 == ioctl(fd, &VIDIOC-QUERYMENU;, &querymenu)) { + printf(" %s\n", querymenu.name); } } } -memset (&queryctrl, 0, sizeof (queryctrl)); +memset(&queryctrl, 0, sizeof(queryctrl)); for (queryctrl.id = V4L2_CID_BASE; queryctrl.id < V4L2_CID_LASTP1; queryctrl.id++) { - if (0 == ioctl (fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { + if (0 == ioctl(fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) continue; - printf ("Control %s\n", queryctrl.name); + printf("Control %s\n", queryctrl.name); if (queryctrl.type == V4L2_CTRL_TYPE_MENU) - enumerate_menu (); + enumerate_menu(); } else { if (errno == EINVAL) continue; - perror ("VIDIOC_QUERYCTRL"); - exit (EXIT_FAILURE); + perror("VIDIOC_QUERYCTRL"); + exit(EXIT_FAILURE); } } for (queryctrl.id = V4L2_CID_PRIVATE_BASE;; queryctrl.id++) { - if (0 == ioctl (fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { + if (0 == ioctl(fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) continue; - printf ("Control %s\n", queryctrl.name); + printf("Control %s\n", queryctrl.name); if (queryctrl.type == V4L2_CTRL_TYPE_MENU) - enumerate_menu (); + enumerate_menu(); } else { if (errno == EINVAL) break; - perror ("VIDIOC_QUERYCTRL"); - exit (EXIT_FAILURE); + perror("VIDIOC_QUERYCTRL"); + exit(EXIT_FAILURE); } } </programlisting> </example> <example> + <title>Enumerating all user controls (alternative)</title> + <programlisting> +memset(&queryctrl, 0, sizeof(queryctrl)); + +queryctrl.id = V4L2_CTRL_CLASS_USER | V4L2_CTRL_FLAG_NEXT_CTRL; +while (0 == ioctl(fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { + if (V4L2_CTRL_ID2CLASS(queryctrl.id) != V4L2_CTRL_CLASS_USER) + break; + if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) + continue; + + printf("Control %s\n", queryctrl.name); + + if (queryctrl.type == V4L2_CTRL_TYPE_MENU) + enumerate_menu(); + + queryctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL; +} +if (errno != EINVAL) { + perror("VIDIOC_QUERYCTRL"); + exit(EXIT_FAILURE); +} +</programlisting> + </example> + + <example> <title>Changing controls</title> <programlisting> &v4l2-queryctrl; queryctrl; &v4l2-control; control; -memset (&queryctrl, 0, sizeof (queryctrl)); +memset(&queryctrl, 0, sizeof(queryctrl)); queryctrl.id = V4L2_CID_BRIGHTNESS; -if (-1 == ioctl (fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { +if (-1 == ioctl(fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { if (errno != EINVAL) { - perror ("VIDIOC_QUERYCTRL"); - exit (EXIT_FAILURE); + perror("VIDIOC_QUERYCTRL"); + exit(EXIT_FAILURE); } else { - printf ("V4L2_CID_BRIGHTNESS is not supported\n"); + printf("V4L2_CID_BRIGHTNESS is not supported\n"); } } else if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) { - printf ("V4L2_CID_BRIGHTNESS is not supported\n"); + printf("V4L2_CID_BRIGHTNESS is not supported\n"); } else { - memset (&control, 0, sizeof (control)); + memset(&control, 0, sizeof (control)); control.id = V4L2_CID_BRIGHTNESS; control.value = queryctrl.default_value; - if (-1 == ioctl (fd, &VIDIOC-S-CTRL;, &control)) { - perror ("VIDIOC_S_CTRL"); - exit (EXIT_FAILURE); + if (-1 == ioctl(fd, &VIDIOC-S-CTRL;, &control)) { + perror("VIDIOC_S_CTRL"); + exit(EXIT_FAILURE); } } -memset (&control, 0, sizeof (control)); +memset(&control, 0, sizeof(control)); control.id = V4L2_CID_CONTRAST; -if (0 == ioctl (fd, &VIDIOC-G-CTRL;, &control)) { +if (0 == ioctl(fd, &VIDIOC-G-CTRL;, &control)) { control.value += 1; /* The driver may clamp the value or return ERANGE, ignored here */ - if (-1 == ioctl (fd, &VIDIOC-S-CTRL;, &control) + if (-1 == ioctl(fd, &VIDIOC-S-CTRL;, &control) && errno != ERANGE) { - perror ("VIDIOC_S_CTRL"); - exit (EXIT_FAILURE); + perror("VIDIOC_S_CTRL"); + exit(EXIT_FAILURE); } /* Ignore if V4L2_CID_CONTRAST is unsupported */ } else if (errno != EINVAL) { - perror ("VIDIOC_G_CTRL"); - exit (EXIT_FAILURE); + perror("VIDIOC_G_CTRL"); + exit(EXIT_FAILURE); } control.id = V4L2_CID_AUDIO_MUTE; -control.value = TRUE; /* silence */ +control.value = 1; /* silence */ /* Errors ignored */ -ioctl (fd, VIDIOC_S_CTRL, &control); +ioctl(fd, VIDIOC_S_CTRL, &control); </programlisting> </example> </section> @@ -625,16 +663,29 @@ supported.</para> &v4l2-control;, except for the fact that it also allows for 64-bit values and pointers to be passed.</para> + <para>Since the &v4l2-ext-control; supports pointers it is now +also possible to have controls with compound types such as N-dimensional arrays +and/or structures. You need to specify the <constant>V4L2_CTRL_FLAG_NEXT_COMPOUND</constant> +when enumerating controls to actually be able to see such compound controls. +In other words, these controls with compound types should only be used +programmatically.</para> + + <para>Since such compound controls need to expose more information +about themselves than is possible with &VIDIOC-QUERYCTRL; the +&VIDIOC-QUERY-EXT-CTRL; ioctl was added. In particular, this ioctl gives +the dimensions of the N-dimensional array if this control consists of more than +one element.</para> + <para>It is important to realize that due to the flexibility of controls it is necessary to check whether the control you want to set actually is supported in the driver and what the valid range of values -is. So use the &VIDIOC-QUERYCTRL; and &VIDIOC-QUERYMENU; ioctls to -check this. Also note that it is possible that some of the menu -indices in a control of type <constant>V4L2_CTRL_TYPE_MENU</constant> -may not be supported (<constant>VIDIOC_QUERYMENU</constant> will -return an error). A good example is the list of supported MPEG audio -bitrates. Some drivers only support one or two bitrates, others -support a wider range.</para> +is. So use the &VIDIOC-QUERYCTRL; (or &VIDIOC-QUERY-EXT-CTRL;) and +&VIDIOC-QUERYMENU; ioctls to check this. Also note that it is possible +that some of the menu indices in a control of type +<constant>V4L2_CTRL_TYPE_MENU</constant> may not be supported +(<constant>VIDIOC_QUERYMENU</constant> will return an error). A good +example is the list of supported MPEG audio bitrates. Some drivers only +support one or two bitrates, others support a wider range.</para> <para> All controls use machine endianness. @@ -675,12 +726,12 @@ control class is found:</para> <informalexample> <programlisting> qctrl.id = V4L2_CTRL_CLASS_MPEG | V4L2_CTRL_FLAG_NEXT_CTRL; -while (0 == ioctl (fd, &VIDIOC-QUERYCTRL;, &qctrl)) { - if (V4L2_CTRL_ID2CLASS (qctrl.id) != V4L2_CTRL_CLASS_MPEG) +while (0 == ioctl(fd, &VIDIOC-QUERYCTRL;, &qctrl)) { + if (V4L2_CTRL_ID2CLASS(qctrl.id) != V4L2_CTRL_CLASS_MPEG) break; /* ... */ - qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL; - } + qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL; +} </programlisting> </informalexample> @@ -700,7 +751,7 @@ ID based on a control ID.</para> <constant>VIDIOC_QUERYCTRL</constant> will fail when used in combination with <constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant>. In that case the old method of enumerating control should be used (see -1.8). But if it is supported, then it is guaranteed to enumerate over +<xref linkend="enum_all_controls" />). But if it is supported, then it is guaranteed to enumerate over all controls, including driver-private controls.</para> </section> @@ -4000,6 +4051,68 @@ to find receivers which can scroll strings sized as 32 x N or 64 x N characters. with steps of 32 or 64 characters. The result is it must always contain a string with size multiple of 32 or 64. </entry> </row> <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_MONO_STEREO</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Sets the Mono/Stereo bit of the Decoder Identification code. If set, +then the audio was recorded as stereo.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_ARTIFICIAL_HEAD</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Sets the +<ulink url="http://en.wikipedia.org/wiki/Artificial_head">Artificial Head</ulink> bit of the Decoder +Identification code. If set, then the audio was recorded using an artificial head.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_COMPRESSED</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Sets the Compressed bit of the Decoder Identification code. If set, +then the audio is compressed.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_DYNAMIC_PTY</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Sets the Dynamic PTY bit of the Decoder Identification code. If set, +then the PTY code is dynamically switched.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_TRAFFIC_ANNOUNCEMENT</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">If set, then a traffic announcement is in progress.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_TRAFFIC_PROGRAM</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">If set, then the tuned programme carries traffic announcements.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_MUSIC_SPEECH</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">If set, then this channel broadcasts music. If cleared, then it +broadcasts speech. If the transmitter doesn't make this distinction, then it should be set.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_ALT_FREQS_ENABLE</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">If set, then transmit alternate frequencies.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_ALT_FREQS</constant> </entry> + <entry>__u32 array</entry> + </row> + <row><entry spanname="descr">The alternate frequencies in kHz units. The RDS standard allows +for up to 25 frequencies to be defined. Drivers may support fewer frequencies so check +the array size.</entry> + </row> + <row> <entry spanname="id"><constant>V4L2_CID_AUDIO_LIMITER_ENABLED</constant> </entry> <entry>boolean</entry> </row> @@ -4976,6 +5089,57 @@ description of this control class.</entry> </row><row><entry spanname="descr">Enables/disables RDS reception by the radio tuner</entry> </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_RX_PTY</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Gets RDS Programme Type field. +This encodes up to 31 pre-defined programme types.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_RX_PS_NAME</constant> </entry> + <entry>string</entry> + </row> + <row><entry spanname="descr">Gets the Programme Service name (PS_NAME). +It is intended for static display on a receiver. It is the primary aid to listeners in programme service +identification and selection. In Annex E of <xref linkend="iec62106" />, the RDS specification, +there is a full description of the correct character encoding for Programme Service name strings. +Also from RDS specification, PS is usually a single eight character text. However, it is also possible +to find receivers which can scroll strings sized as 8 x N characters. So, this control must be configured +with steps of 8 characters. The result is it must always contain a string with size multiple of 8.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_RX_RADIO_TEXT</constant> </entry> + <entry>string</entry> + </row> + <row><entry spanname="descr">Gets the Radio Text info. It is a textual description of +what is being broadcasted. RDS Radio Text can be applied when broadcaster wishes to transmit longer PS names, +programme-related information or any other text. In these cases, RadioText can be used in addition to +<constant>V4L2_CID_RDS_RX_PS_NAME</constant>. The encoding for Radio Text strings is also fully described +in Annex E of <xref linkend="iec62106" />. The length of Radio Text strings depends on which RDS Block is being +used to transmit it, either 32 (2A block) or 64 (2B block). However, it is also possible +to find receivers which can scroll strings sized as 32 x N or 64 x N characters. So, this control must be configured +with steps of 32 or 64 characters. The result is it must always contain a string with size multiple of 32 or 64. </entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_RX_TRAFFIC_ANNOUNCEMENT</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">If set, then a traffic announcement is in progress.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_RX_TRAFFIC_PROGRAM</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">If set, then the tuned programme carries traffic announcements.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_RX_MUSIC_SPEECH</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">If set, then this channel broadcasts music. If cleared, then it +broadcasts speech. If the transmitter doesn't make this distinction, then it will be set.</entry> + </row> <row> <entry spanname="id"><constant>V4L2_CID_TUNE_DEEMPHASIS</constant> </entry> <entry>enum v4l2_deemphasis</entry> @@ -5007,6 +5171,102 @@ defines possible values for de-emphasis. Here they are:</entry> </tbody> </tgroup> </table> + </section> + + <section id="detect-controls"> + <title>Detect Control Reference</title> + + <para>The Detect class includes controls for common features of + various motion or object detection capable devices.</para> + + <table pgwide="1" frame="none" id="detect-control-id"> + <title>Detect Control IDs</title> + + <tgroup cols="4"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="6*" /> + <colspec colname="c3" colwidth="2*" /> + <colspec colname="c4" colwidth="6*" /> + <spanspec namest="c1" nameend="c2" spanname="id" /> + <spanspec namest="c2" nameend="c4" spanname="descr" /> + <thead> + <row> + <entry spanname="id" align="left">ID</entry> + <entry align="left">Type</entry> + </row><row rowsep="1"><entry spanname="descr" align="left">Description</entry> + </row> + </thead> + <tbody valign="top"> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_DETECT_CLASS</constant> </entry> + <entry>class</entry> + </row><row><entry spanname="descr">The Detect class +descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a +description of this control class.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DETECT_MD_MODE</constant> </entry> + <entry>menu</entry> + </row><row><entry spanname="descr">Sets the motion detection mode.</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_DETECT_MD_MODE_DISABLED</constant> + </entry><entry>Disable motion detection.</entry> + </row> + <row> + <entry><constant>V4L2_DETECT_MD_MODE_GLOBAL</constant> + </entry><entry>Use a single motion detection threshold.</entry> + </row> + <row> + <entry><constant>V4L2_DETECT_MD_MODE_THRESHOLD_GRID</constant> + </entry><entry>The image is divided into a grid, each cell with its own + motion detection threshold. These thresholds are set through the + <constant>V4L2_CID_DETECT_MD_THRESHOLD_GRID</constant> matrix control.</entry> + </row> + <row> + <entry><constant>V4L2_DETECT_MD_MODE_REGION_GRID</constant> + </entry><entry>The image is divided into a grid, each cell with its own + region value that specifies which per-region motion detection thresholds + should be used. Each region has its own thresholds. How these per-region + thresholds are set up is driver-specific. The region values for the grid are set + through the <constant>V4L2_CID_DETECT_MD_REGION_GRID</constant> matrix + control.</entry> + </row> + </tbody> + </entrytbl> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DETECT_MD_GLOBAL_THRESHOLD</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Sets the global motion detection threshold to be + used with the <constant>V4L2_DETECT_MD_MODE_GLOBAL</constant> motion detection mode.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DETECT_MD_THRESHOLD_GRID</constant> </entry> + <entry>__u16 matrix</entry> + </row> + <row><entry spanname="descr">Sets the motion detection thresholds for each cell in the grid. + To be used with the <constant>V4L2_DETECT_MD_MODE_THRESHOLD_GRID</constant> + motion detection mode. Matrix element (0, 0) represents the cell at the top-left of the + grid.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DETECT_MD_REGION_GRID</constant> </entry> + <entry>__u8 matrix</entry> + </row> + <row><entry spanname="descr">Sets the motion detection region value for each cell in the grid. + To be used with the <constant>V4L2_DETECT_MD_MODE_REGION_GRID</constant> + motion detection mode. Matrix element (0, 0) represents the cell at the top-left of the + grid.</entry> + </row> + </tbody> + </tgroup> + </table> </section> diff --git a/Documentation/DocBook/media/v4l/dev-raw-vbi.xml b/Documentation/DocBook/media/v4l/dev-raw-vbi.xml index b788c72c885e..f4b61b6ce3c2 100644 --- a/Documentation/DocBook/media/v4l/dev-raw-vbi.xml +++ b/Documentation/DocBook/media/v4l/dev-raw-vbi.xml @@ -150,9 +150,15 @@ signal. Drivers shall not convert the sample format by software.</para></entry> <entry>This is the scanning system line number associated with the first line of the VBI image, of the first and the second field respectively. See <xref linkend="vbi-525" /> and -<xref linkend="vbi-625" /> for valid values. VBI input drivers can -return start values 0 if the hardware cannot reliable identify -scanning lines, VBI acquisition may not require this +<xref linkend="vbi-625" /> for valid values. +The <constant>V4L2_VBI_ITU_525_F1_START</constant>, +<constant>V4L2_VBI_ITU_525_F2_START</constant>, +<constant>V4L2_VBI_ITU_625_F1_START</constant> and +<constant>V4L2_VBI_ITU_625_F2_START</constant> defines give the start line +numbers for each field for each 525 or 625 line format as a convenience. +Don't forget that ITU line numbering starts at 1, not 0. +VBI input drivers can return start values 0 if the hardware cannot +reliable identify scanning lines, VBI acquisition may not require this information.</entry> </row> <row> diff --git a/Documentation/DocBook/media/v4l/dev-sdr.xml b/Documentation/DocBook/media/v4l/dev-sdr.xml index dc14804f5436..f8903568a243 100644 --- a/Documentation/DocBook/media/v4l/dev-sdr.xml +++ b/Documentation/DocBook/media/v4l/dev-sdr.xml @@ -72,9 +72,12 @@ To use the <link linkend="format">format</link> ioctls applications set the <constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant> and use the &v4l2-sdr-format; <structfield>sdr</structfield> member of the <structfield>fmt</structfield> union as needed per the desired operation. -Currently only the <structfield>pixelformat</structfield> field of -&v4l2-sdr-format; is used. The content of that field is the V4L2 fourcc code -of the data format. +Currently there is two fields, <structfield>pixelformat</structfield> and +<structfield>buffersize</structfield>, of struct &v4l2-sdr-format; which are +used. Content of the <structfield>pixelformat</structfield> is V4L2 FourCC +code of the data format. The <structfield>buffersize</structfield> field is +maximum buffer size in bytes required for data transfer, set by the driver in +order to inform application. </para> <table pgwide="1" frame="none" id="v4l2-sdr-format"> @@ -92,8 +95,15 @@ V4L2 defines SDR formats in <xref linkend="sdr-formats" />. </entry> </row> <row> + <entry>__u32</entry> + <entry><structfield>buffersize</structfield></entry> + <entry> +Maximum size in bytes required for data. Value is set by the driver. + </entry> + </row> + <row> <entry>__u8</entry> - <entry><structfield>reserved[28]</structfield></entry> + <entry><structfield>reserved[24]</structfield></entry> <entry>This array is reserved for future extensions. Drivers and applications must set it to zero.</entry> </row> diff --git a/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml b/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml index 548f8ea28dee..7a8bf3011ee9 100644 --- a/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml +++ b/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml @@ -185,7 +185,14 @@ tables, sigh. --></para></entry> <entry></entry> <entry spanname="hspan">Drivers must set <structfield>service_lines</structfield>[0][0] and -<structfield>service_lines</structfield>[1][0] to zero.</entry> +<structfield>service_lines</structfield>[1][0] to zero. +The <constant>V4L2_VBI_ITU_525_F1_START</constant>, +<constant>V4L2_VBI_ITU_525_F2_START</constant>, +<constant>V4L2_VBI_ITU_625_F1_START</constant> and +<constant>V4L2_VBI_ITU_625_F2_START</constant> defines give the start +line numbers for each field for each 525 or 625 line format as a +convenience. Don't forget that ITU line numbering starts at 1, not 0. +</entry> </row> <row> <entry>__u32</entry> diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index a086a5db7a18..e5e8325aa3d7 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -870,7 +870,8 @@ should set this to 0.</entry> If the application sets this to 0 for an output stream, then <structfield>bytesused</structfield> will be set to the size of the plane (see the <structfield>length</structfield> field of this struct) - by the driver.</entry> + by the driver. Note that the actual image data starts at + <structfield>data_offset</structfield> which may not be 0.</entry> </row> <row> <entry>__u32</entry> @@ -919,6 +920,10 @@ should set this to 0.</entry> <entry>Offset in bytes to video data in the plane. Drivers must set this field when <structfield>type</structfield> refers to an input stream, applications when it refers to an output stream. + Note that data_offset is included in <structfield>bytesused</structfield>. + So the size of the image in the plane is + <structfield>bytesused</structfield>-<structfield>data_offset</structfield> at + offset <structfield>data_offset</structfield> from the start of the plane. </entry> </row> <row> @@ -1066,7 +1071,7 @@ state, in the application domain so to say.</entry> <entry>Drivers set or clear this flag when calling the <constant>VIDIOC_DQBUF</constant> ioctl. It may be set by video capture devices when the buffer contains a compressed image which is a -key frame (or field), &ie; can be decompressed on its own. Also know as +key frame (or field), &ie; can be decompressed on its own. Also known as an I-frame. Applications can set this bit when <structfield>type</structfield> refers to an output stream.</entry> </row> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index e1c4f8b4c0b3..2aae8e9452a4 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml @@ -15,9 +15,6 @@ typical PC graphics frame buffers. They occupy 8, 16, 24 or 32 bits per pixel. These are all packed-pixel formats, meaning all the data for a pixel lie next to each other in memory.</para> - <para>When one of these formats is used, drivers shall report the -colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> - <table pgwide="1" frame="none" id="rgb-formats"> <title>Packed RGB Image Formats</title> <tgroup cols="37" align="center"> @@ -130,9 +127,9 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>b<subscript>1</subscript></entry> <entry>b<subscript>0</subscript></entry> </row> - <row id="V4L2-PIX-FMT-RGB444"> - <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry> - <entry>'R444'</entry> + <row id="V4L2-PIX-FMT-ARGB444"> + <entry><constant>V4L2_PIX_FMT_ARGB444</constant></entry> + <entry>'AR12'</entry> <entry></entry> <entry>g<subscript>3</subscript></entry> <entry>g<subscript>2</subscript></entry> @@ -152,9 +149,31 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>r<subscript>1</subscript></entry> <entry>r<subscript>0</subscript></entry> </row> - <row id="V4L2-PIX-FMT-RGB555"> - <entry><constant>V4L2_PIX_FMT_RGB555</constant></entry> - <entry>'RGBO'</entry> + <row id="V4L2-PIX-FMT-XRGB444"> + <entry><constant>V4L2_PIX_FMT_XRGB444</constant></entry> + <entry>'XR12'</entry> + <entry></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-ARGB555"> + <entry><constant>V4L2_PIX_FMT_ARGB555</constant></entry> + <entry>'AR15'</entry> <entry></entry> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> @@ -174,6 +193,28 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>g<subscript>4</subscript></entry> <entry>g<subscript>3</subscript></entry> </row> + <row id="V4L2-PIX-FMT-XRGB555"> + <entry><constant>V4L2_PIX_FMT_XRGB555</constant></entry> + <entry>'XR15'</entry> + <entry></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>-</entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + </row> <row id="V4L2-PIX-FMT-RGB565"> <entry><constant>V4L2_PIX_FMT_RGB565</constant></entry> <entry>'RGBP'</entry> @@ -341,9 +382,9 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>b<subscript>1</subscript></entry> <entry>b<subscript>0</subscript></entry> </row> - <row id="V4L2-PIX-FMT-BGR32"> - <entry><constant>V4L2_PIX_FMT_BGR32</constant></entry> - <entry>'BGR4'</entry> + <row id="V4L2-PIX-FMT-ABGR32"> + <entry><constant>V4L2_PIX_FMT_ABGR32</constant></entry> + <entry>'AR24'</entry> <entry></entry> <entry>b<subscript>7</subscript></entry> <entry>b<subscript>6</subscript></entry> @@ -381,9 +422,49 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>a<subscript>1</subscript></entry> <entry>a<subscript>0</subscript></entry> </row> - <row id="V4L2-PIX-FMT-RGB32"> - <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> - <entry>'RGB4'</entry> + <row id="V4L2-PIX-FMT-XBGR32"> + <entry><constant>V4L2_PIX_FMT_XBGR32</constant></entry> + <entry>'XR24'</entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + </row> + <row id="V4L2-PIX-FMT-ARGB32"> + <entry><constant>V4L2_PIX_FMT_ARGB32</constant></entry> + <entry>'AX24'</entry> <entry></entry> <entry>a<subscript>7</subscript></entry> <entry>a<subscript>6</subscript></entry> @@ -421,18 +502,76 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>b<subscript>1</subscript></entry> <entry>b<subscript>0</subscript></entry> </row> + <row id="V4L2-PIX-FMT-XRGB32"> + <entry><constant>V4L2_PIX_FMT_XRGB32</constant></entry> + <entry>'BX24'</entry> + <entry></entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry>-</entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + </row> </tbody> </tgroup> </table> - <para>Bit 7 is the most significant bit. The value of the a = alpha -bits is undefined when reading from the driver, ignored when writing -to the driver, except when alpha blending has been negotiated for a -<link linkend="overlay">Video Overlay</link> or <link linkend="osd"> -Video Output Overlay</link> or when the alpha component has been configured -for a <link linkend="capture">Video Capture</link> by means of <link -linkend="v4l2-alpha-component"> <constant>V4L2_CID_ALPHA_COMPONENT -</constant> </link> control.</para> + <para>Bit 7 is the most significant bit.</para> + + <para>The usage and value of the alpha bits (a) in the ARGB and ABGR formats + (collectively referred to as alpha formats) depend on the device type and + hardware operation. <link linkend="capture">Capture</link> devices + (including capture queues of mem-to-mem devices) fill the alpha component in + memory. When the device outputs an alpha channel the alpha component will + have a meaningful value. Otherwise, when the device doesn't output an alpha + channel but can set the alpha bit to a user-configurable value, the <link + linkend="v4l2-alpha-component"><constant>V4L2_CID_ALPHA_COMPONENT</constant> + </link> control is used to specify that alpha value, and the alpha component + of all pixels will be set to the value specified by that control. Otherwise + a corresponding format without an alpha component (XRGB or XBGR) must be + used instead of an alpha format.</para> + + <para><link linkend="output">Output</link> devices (including output queues + of mem-to-mem devices and <link linkend="osd">video output overlay</link> + devices) read the alpha component from memory. When the device processes the + alpha channel the alpha component must be filled with meaningful values by + applications. Otherwise a corresponding format without an alpha component + (XRGB or XBGR) must be used instead of an alpha format.</para> + + <para>The XRGB and XBGR formats contain undefined bits (-). Applications, + devices and drivers must ignore those bits, for both <link + linkend="capture">capture</link> and <link linkend="output">output</link> + devices.</para> <example> <title><constant>V4L2_PIX_FMT_BGR24</constant> 4 × 4 pixel @@ -512,6 +651,239 @@ image</title> </formalpara> </example> + <para>Formats defined in <xref linkend="rgb-formats-deprecated"/> are + deprecated and must not be used by new drivers. They are documented here for + reference. The meaning of their alpha bits (a) is ill-defined and + interpreted as in either the corresponding ARGB or XRGB format, depending on + the driver.</para> + + <table pgwide="1" frame="none" id="rgb-formats-deprecated"> + <title>Deprecated Packed RGB Image Formats</title> + <tgroup cols="37" align="center"> + <colspec colname="id" align="left" /> + <colspec colname="fourcc" /> + <colspec colname="bit" /> + + <colspec colnum="4" colname="b07" align="center" /> + <colspec colnum="5" colname="b06" align="center" /> + <colspec colnum="6" colname="b05" align="center" /> + <colspec colnum="7" colname="b04" align="center" /> + <colspec colnum="8" colname="b03" align="center" /> + <colspec colnum="9" colname="b02" align="center" /> + <colspec colnum="10" colname="b01" align="center" /> + <colspec colnum="11" colname="b00" align="center" /> + + <colspec colnum="13" colname="b17" align="center" /> + <colspec colnum="14" colname="b16" align="center" /> + <colspec colnum="15" colname="b15" align="center" /> + <colspec colnum="16" colname="b14" align="center" /> + <colspec colnum="17" colname="b13" align="center" /> + <colspec colnum="18" colname="b12" align="center" /> + <colspec colnum="19" colname="b11" align="center" /> + <colspec colnum="20" colname="b10" align="center" /> + + <colspec colnum="22" colname="b27" align="center" /> + <colspec colnum="23" colname="b26" align="center" /> + <colspec colnum="24" colname="b25" align="center" /> + <colspec colnum="25" colname="b24" align="center" /> + <colspec colnum="26" colname="b23" align="center" /> + <colspec colnum="27" colname="b22" align="center" /> + <colspec colnum="28" colname="b21" align="center" /> + <colspec colnum="29" colname="b20" align="center" /> + + <colspec colnum="31" colname="b37" align="center" /> + <colspec colnum="32" colname="b36" align="center" /> + <colspec colnum="33" colname="b35" align="center" /> + <colspec colnum="34" colname="b34" align="center" /> + <colspec colnum="35" colname="b33" align="center" /> + <colspec colnum="36" colname="b32" align="center" /> + <colspec colnum="37" colname="b31" align="center" /> + <colspec colnum="38" colname="b30" align="center" /> + + <spanspec namest="b07" nameend="b00" spanname="b0" /> + <spanspec namest="b17" nameend="b10" spanname="b1" /> + <spanspec namest="b27" nameend="b20" spanname="b2" /> + <spanspec namest="b37" nameend="b30" spanname="b3" /> + <thead> + <row> + <entry>Identifier</entry> + <entry>Code</entry> + <entry> </entry> + <entry spanname="b0">Byte 0 in memory</entry> + <entry spanname="b1">Byte 1</entry> + <entry spanname="b2">Byte 2</entry> + <entry spanname="b3">Byte 3</entry> + </row> + <row> + <entry> </entry> + <entry> </entry> + <entry>Bit</entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + </row> + </thead> + <tbody> + <row id="V4L2-PIX-FMT-RGB444"> + <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry> + <entry>'R444'</entry> + <entry></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-RGB555"> + <entry><constant>V4L2_PIX_FMT_RGB555</constant></entry> + <entry>'RGBO'</entry> + <entry></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>a</entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-BGR32"> + <entry><constant>V4L2_PIX_FMT_BGR32</constant></entry> + <entry>'BGR4'</entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-RGB32"> + <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> + <entry>'RGB4'</entry> + <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + </row> + </tbody> + </tgroup> + </table> + <para>A test utility to determine which RGB formats a driver actually supports is available from the LinuxTV v4l-dvb repository. See &v4l-dvb; for access instructions.</para> diff --git a/Documentation/DocBook/media/v4l/pixfmt-sdr-cs08.xml b/Documentation/DocBook/media/v4l/pixfmt-sdr-cs08.xml new file mode 100644 index 000000000000..6118d8f7a20c --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sdr-cs08.xml @@ -0,0 +1,44 @@ +<refentry id="V4L2-SDR-FMT-CS08"> + <refmeta> + <refentrytitle>V4L2_SDR_FMT_CS8 ('CS08')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname> + <constant>V4L2_SDR_FMT_CS8</constant> + </refname> + <refpurpose>Complex signed 8-bit IQ sample</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + <para> +This format contains sequence of complex number samples. Each complex number +consist two parts, called In-phase and Quadrature (IQ). Both I and Q are +represented as a 8 bit signed number. I value comes first and Q value after +that. + </para> + <example> + <title><constant>V4L2_SDR_FMT_CS8</constant> 1 sample</title> + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="2" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>I'<subscript>0</subscript></entry> + </row> + <row> + <entry>start + 1:</entry> + <entry>Q'<subscript>0</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> +</refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt-sdr-cs14le.xml b/Documentation/DocBook/media/v4l/pixfmt-sdr-cs14le.xml new file mode 100644 index 000000000000..e4b494ce1369 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sdr-cs14le.xml @@ -0,0 +1,47 @@ +<refentry id="V4L2-SDR-FMT-CS14LE"> + <refmeta> + <refentrytitle>V4L2_SDR_FMT_CS14LE ('CS14')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname> + <constant>V4L2_SDR_FMT_CS14LE</constant> + </refname> + <refpurpose>Complex signed 14-bit little endian IQ sample</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + <para> +This format contains sequence of complex number samples. Each complex number +consist two parts, called In-phase and Quadrature (IQ). Both I and Q are +represented as a 14 bit signed little endian number. I value comes first +and Q value after that. 14 bit value is stored in 16 bit space with unused +high bits padded with 0. + </para> + <example> + <title><constant>V4L2_SDR_FMT_CS14LE</constant> 1 sample</title> + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="3" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>I'<subscript>0[7:0]</subscript></entry> + <entry>I'<subscript>0[13:8]</subscript></entry> + </row> + <row> + <entry>start + 2:</entry> + <entry>Q'<subscript>0[7:0]</subscript></entry> + <entry>Q'<subscript>0[13:8]</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> +</refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt-sdr-ru12le.xml b/Documentation/DocBook/media/v4l/pixfmt-sdr-ru12le.xml new file mode 100644 index 000000000000..3df076b99f94 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sdr-ru12le.xml @@ -0,0 +1,40 @@ +<refentry id="V4L2-SDR-FMT-RU12LE"> + <refmeta> + <refentrytitle>V4L2_SDR_FMT_RU12LE ('RU12')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname> + <constant>V4L2_SDR_FMT_RU12LE</constant> + </refname> + <refpurpose>Real unsigned 12-bit little endian sample</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + <para> +This format contains sequence of real number samples. Each sample is +represented as a 12 bit unsigned little endian number. Sample is stored +in 16 bit space with unused high bits padded with 0. + </para> + <example> + <title><constant>V4L2_SDR_FMT_RU12LE</constant> 1 sample</title> + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="3" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>I'<subscript>0[7:0]</subscript></entry> + <entry>I'<subscript>0[11:8]</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> +</refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml index 9ba4fb690bc0..96947f17fca1 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb12.xml @@ -18,7 +18,7 @@ <title>Description</title> <para>The following four pixel formats are raw sRGB / Bayer formats with -12 bits per colour. Each colour component is stored in a 16-bit word, with 6 +12 bits per colour. Each colour component is stored in a 16-bit word, with 4 unused high bits filled with zeros. Each n-pixel row contains n/2 green samples and n/2 blue or red samples, with alternating red and blue rows. Bytes are stored in memory in little endian order. They are conventionally described diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 91dcbc84f3f8..df5b23d46552 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -112,9 +112,34 @@ see <xref linkend="colorspaces" />.</entry> <row> <entry>__u32</entry> <entry><structfield>priv</structfield></entry> - <entry>Reserved for custom (driver defined) additional -information about formats. When not used drivers and applications must -set this field to zero.</entry> + <entry><para>This field indicates whether the remaining fields of the +<structname>v4l2_pix_format</structname> structure, also called the extended +fields, are valid. When set to <constant>V4L2_PIX_FMT_PRIV_MAGIC</constant>, it +indicates that the extended fields have been correctly initialized. When set to +any other value it indicates that the extended fields contain undefined values. +</para> +<para>Applications that wish to use the pixel format extended fields must first +ensure that the feature is supported by querying the device for the +<link linkend="querycap"><constant>V4L2_CAP_EXT_PIX_FORMAT</constant></link> +capability. If the capability isn't set the pixel format extended fields are not +supported and using the extended fields will lead to undefined results.</para> +<para>To use the extended fields, applications must set the +<structfield>priv</structfield> field to +<constant>V4L2_PIX_FMT_PRIV_MAGIC</constant>, initialize all the extended fields +and zero the unused bytes of the <structname>v4l2_format</structname> +<structfield>raw_data</structfield> field.</para> +<para>When the <structfield>priv</structfield> field isn't set to +<constant>V4L2_PIX_FMT_PRIV_MAGIC</constant> drivers must act as if all the +extended fields were set to zero. On return drivers must set the +<structfield>priv</structfield> field to +<constant>V4L2_PIX_FMT_PRIV_MAGIC</constant> and all the extended fields to +applicable values.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry>Flags set by the application or driver, see <xref +linkend="format-flags" />.</entry> </row> </tbody> </tgroup> @@ -201,9 +226,15 @@ codes can be used.</entry> and the number of valid entries in the <structfield>plane_fmt</structfield> array.</entry> </row> + <row> + <entry>__u8</entry> + <entry><structfield>flags</structfield></entry> + <entry>Flags set by the application or driver, see <xref +linkend="format-flags" />.</entry> + </row> <row> <entry>__u8</entry> - <entry><structfield>reserved[11]</structfield></entry> + <entry><structfield>reserved[10]</structfield></entry> <entry>Reserved for future extensions. Should be zeroed by the application.</entry> </row> @@ -248,7 +279,7 @@ has just as many pad bytes after it as the other rows.</para> <para>In V4L2 each format has an identifier which looks like <constant>PIX_FMT_XXX</constant>, defined in the <link -linkend="videodev">videodev.h</link> header file. These identifiers +linkend="videodev">videodev2.h</link> header file. These identifiers represent <link linkend="v4l2-fourcc">four character (FourCC) codes</link> which are also listed below, however they are not the same as those used in the Windows world.</para> @@ -828,6 +859,9 @@ interface only.</para> &sub-sdr-cu08; &sub-sdr-cu16le; + &sub-sdr-cs08; + &sub-sdr-cs14le; + &sub-sdr-ru12le; </section> @@ -1060,4 +1094,21 @@ concatenated to form the JPEG stream. </para> </tbody> </tgroup> </table> + + <table frame="none" pgwide="1" id="format-flags"> + <title>Format Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_PIX_FMT_FLAG_PREMUL_ALPHA</constant></entry> + <entry>0x00000001</entry> + <entry>The color values are premultiplied by the alpha channel +value. For example, if a light blue pixel with 50% transparency was described by +RGBA values (128, 192, 255, 128), the same pixel described with premultiplied +colors would be described by RGBA values (64, 96, 128, 128) </entry> + </row> + </tbody> + </tgroup> + </table> </section> diff --git a/Documentation/DocBook/media/v4l/selection-api.xml b/Documentation/DocBook/media/v4l/selection-api.xml index 4c238ce068b0..28cbded766c9 100644 --- a/Documentation/DocBook/media/v4l/selection-api.xml +++ b/Documentation/DocBook/media/v4l/selection-api.xml @@ -86,47 +86,47 @@ selection targets available for a video capture device. It is recommended to configure the cropping targets before to the composing targets.</para> <para>The range of coordinates of the top left corner, width and height of -areas that can be sampled is given by the <constant> V4L2_SEL_TGT_CROP_BOUNDS -</constant> target. It is recommended for the driver developers to put the -top/left corner at position <constant> (0,0) </constant>. The rectangle's +areas that can be sampled is given by the <constant>V4L2_SEL_TGT_CROP_BOUNDS</constant> +target. It is recommended for the driver developers to put the +top/left corner at position <constant>(0,0)</constant>. The rectangle's coordinates are expressed in pixels.</para> <para>The top left corner, width and height of the source rectangle, that is -the area actually sampled, is given by the <constant> V4L2_SEL_TGT_CROP -</constant> target. It uses the same coordinate system as <constant> -V4L2_SEL_TGT_CROP_BOUNDS </constant>. The active cropping area must lie -completely inside the capture boundaries. The driver may further adjust the -requested size and/or position according to hardware limitations.</para> +the area actually sampled, is given by the <constant>V4L2_SEL_TGT_CROP</constant> +target. It uses the same coordinate system as <constant>V4L2_SEL_TGT_CROP_BOUNDS</constant>. +The active cropping area must lie completely inside the capture boundaries. The +driver may further adjust the requested size and/or position according to hardware +limitations.</para> <para>Each capture device has a default source rectangle, given by the -<constant> V4L2_SEL_TGT_CROP_DEFAULT </constant> target. This rectangle shall +<constant>V4L2_SEL_TGT_CROP_DEFAULT</constant> target. This rectangle shall over what the driver writer considers the complete picture. Drivers shall set the active crop rectangle to the default when the driver is first loaded, but not later.</para> <para>The composing targets refer to a memory buffer. The limits of composing -coordinates are obtained using <constant> V4L2_SEL_TGT_COMPOSE_BOUNDS -</constant>. All coordinates are expressed in pixels. The rectangle's top/left -corner must be located at position <constant> (0,0) </constant>. The width and -height are equal to the image size set by <constant> VIDIOC_S_FMT </constant>. +coordinates are obtained using <constant>V4L2_SEL_TGT_COMPOSE_BOUNDS</constant>. +All coordinates are expressed in pixels. The rectangle's top/left +corner must be located at position <constant>(0,0)</constant>. The width and +height are equal to the image size set by <constant>VIDIOC_S_FMT</constant>. </para> <para>The part of a buffer into which the image is inserted by the hardware is -controlled by the <constant> V4L2_SEL_TGT_COMPOSE </constant> target. +controlled by the <constant>V4L2_SEL_TGT_COMPOSE</constant> target. The rectangle's coordinates are also expressed in the same coordinate system as the bounds rectangle. The composing rectangle must lie completely inside bounds rectangle. The driver must adjust the composing rectangle to fit to the bounding limits. Moreover, the driver can perform other adjustments according to hardware limitations. The application can control rounding behaviour using -<link linkend="v4l2-selection-flags"> constraint flags </link>.</para> +<link linkend="v4l2-selection-flags"> constraint flags</link>.</para> <para>For capture devices the default composing rectangle is queried using -<constant> V4L2_SEL_TGT_COMPOSE_DEFAULT </constant>. It is usually equal to the +<constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant>. It is usually equal to the bounding rectangle.</para> <para>The part of a buffer that is modified by the hardware is given by -<constant> V4L2_SEL_TGT_COMPOSE_PADDED </constant>. It contains all pixels -defined using <constant> V4L2_SEL_TGT_COMPOSE </constant> plus all +<constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant>. It contains all pixels +defined using <constant>V4L2_SEL_TGT_COMPOSE</constant> plus all padding data modified by hardware during insertion process. All pixels outside this rectangle <emphasis>must not</emphasis> be changed by the hardware. The content of pixels that lie inside the padded area but outside active area is @@ -140,52 +140,51 @@ where the rubbish pixels are located and remove them if needed.</para> <title>Configuration of video output</title> <para>For output devices targets and ioctls are used similarly to the video -capture case. The <emphasis> composing </emphasis> rectangle refers to the +capture case. The <emphasis>composing</emphasis> rectangle refers to the insertion of an image into a video signal. The cropping rectangles refer to a memory buffer. It is recommended to configure the composing targets before to the cropping targets.</para> <para>The cropping targets refer to the memory buffer that contains an image to be inserted into a video signal or graphical screen. The limits of cropping -coordinates are obtained using <constant> V4L2_SEL_TGT_CROP_BOUNDS </constant>. +coordinates are obtained using <constant>V4L2_SEL_TGT_CROP_BOUNDS</constant>. All coordinates are expressed in pixels. The top/left corner is always point -<constant> (0,0) </constant>. The width and height is equal to the image size -specified using <constant> VIDIOC_S_FMT </constant> ioctl.</para> +<constant>(0,0)</constant>. The width and height is equal to the image size +specified using <constant>VIDIOC_S_FMT</constant> ioctl.</para> <para>The top left corner, width and height of the source rectangle, that is the area from which image date are processed by the hardware, is given by the -<constant> V4L2_SEL_TGT_CROP </constant>. Its coordinates are expressed +<constant>V4L2_SEL_TGT_CROP</constant>. Its coordinates are expressed in in the same coordinate system as the bounds rectangle. The active cropping area must lie completely inside the crop boundaries and the driver may further adjust the requested size and/or position according to hardware limitations.</para> <para>For output devices the default cropping rectangle is queried using -<constant> V4L2_SEL_TGT_CROP_DEFAULT </constant>. It is usually equal to the +<constant>V4L2_SEL_TGT_CROP_DEFAULT</constant>. It is usually equal to the bounding rectangle.</para> <para>The part of a video signal or graphics display where the image is -inserted by the hardware is controlled by <constant> -V4L2_SEL_TGT_COMPOSE </constant> target. The rectangle's coordinates -are expressed in pixels. The composing rectangle must lie completely inside the -bounds rectangle. The driver must adjust the area to fit to the bounding -limits. Moreover, the driver can perform other adjustments according to -hardware limitations. </para> - -<para>The device has a default composing rectangle, given by the <constant> -V4L2_SEL_TGT_COMPOSE_DEFAULT </constant> target. This rectangle shall cover what +inserted by the hardware is controlled by <constant>V4L2_SEL_TGT_COMPOSE</constant> +target. The rectangle's coordinates are expressed in pixels. The composing +rectangle must lie completely inside the bounds rectangle. The driver must +adjust the area to fit to the bounding limits. Moreover, the driver can +perform other adjustments according to hardware limitations.</para> + +<para>The device has a default composing rectangle, given by the +<constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant> target. This rectangle shall cover what the driver writer considers the complete picture. It is recommended for the -driver developers to put the top/left corner at position <constant> (0,0) -</constant>. Drivers shall set the active composing rectangle to the default +driver developers to put the top/left corner at position <constant>(0,0)</constant>. +Drivers shall set the active composing rectangle to the default one when the driver is first loaded.</para> <para>The devices may introduce additional content to video signal other than an image from memory buffers. It includes borders around an image. However, such a padded area is driver-dependent feature not covered by this document. Driver developers are encouraged to keep padded rectangle equal to active one. -The padded target is accessed by the <constant> V4L2_SEL_TGT_COMPOSE_PADDED -</constant> identifier. It must contain all pixels from the <constant> -V4L2_SEL_TGT_COMPOSE </constant> target.</para> +The padded target is accessed by the <constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant> +identifier. It must contain all pixels from the <constant>V4L2_SEL_TGT_COMPOSE</constant> +target.</para> </section> @@ -194,8 +193,8 @@ V4L2_SEL_TGT_COMPOSE </constant> target.</para> <title>Scaling control</title> <para>An application can detect if scaling is performed by comparing the width -and the height of rectangles obtained using <constant> V4L2_SEL_TGT_CROP -</constant> and <constant> V4L2_SEL_TGT_COMPOSE </constant> targets. If +and the height of rectangles obtained using <constant>V4L2_SEL_TGT_CROP</constant> +and <constant>V4L2_SEL_TGT_COMPOSE</constant> targets. If these are not equal then the scaling is applied. The application can compute the scaling ratios using these values.</para> @@ -208,7 +207,7 @@ the scaling ratios using these values.</para> <title>Comparison with old cropping API</title> <para>The selection API was introduced to cope with deficiencies of previous -<link linkend="crop"> API </link>, that was designed to control simple capture +<link linkend="crop"> API</link>, that was designed to control simple capture devices. Later the cropping API was adopted by video output drivers. The ioctls are used to select a part of the display were the video signal is inserted. It should be considered as an API abuse because the described operation is @@ -220,7 +219,7 @@ part of an image by abusing V4L2 API. Cropping a smaller image from a larger one is achieved by setting the field &v4l2-pix-format;<structfield>::bytesperline</structfield>. Introducing an image offsets could be done by modifying field &v4l2-buffer;<structfield>::m_userptr</structfield> -before calling <constant> VIDIOC_QBUF </constant>. Those +before calling <constant>VIDIOC_QBUF</constant>. Those operations should be avoided because they are not portable (endianness), and do not work for macroblock and Bayer formats and mmap buffers. The selection API deals with configuration of buffer cropping/composing in a clear, intuitive and @@ -229,7 +228,7 @@ and constraints flags are introduced. Finally, &v4l2-crop; and &v4l2-cropcap; have no reserved fields. Therefore there is no way to extend their functionality. The new &v4l2-selection; provides a lot of place for future extensions. Driver developers are encouraged to implement only selection API. -The former cropping API would be simulated using the new one. </para> +The former cropping API would be simulated using the new one.</para> </section> @@ -238,9 +237,9 @@ The former cropping API would be simulated using the new one. </para> <example> <title>Resetting the cropping parameters</title> - <para>(A video capture device is assumed; change <constant> -V4L2_BUF_TYPE_VIDEO_CAPTURE </constant> for other devices; change target to -<constant> V4L2_SEL_TGT_COMPOSE_* </constant> family to configure composing + <para>(A video capture device is assumed; change +<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> for other devices; change target to +<constant>V4L2_SEL_TGT_COMPOSE_*</constant> family to configure composing area)</para> <programlisting> @@ -292,8 +291,8 @@ area)</para> <example> <title>Querying for scaling factors</title> - <para>A video output device is assumed; change <constant> -V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> for other devices</para> + <para>A video output device is assumed; change +<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> for other devices</para> <programlisting> &v4l2-selection; compose = { diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index b445161b912c..f2f81f06a17b 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -152,6 +152,14 @@ structs, ioctls) must be noted in more detail in the history chapter applications. --> <revision> + <revnumber>3.16</revnumber> + <date>2014-05-27</date> + <authorinitials>lp</authorinitials> + <revremark>Extended &v4l2-pix-format;. Added format flags. + </revremark> + </revision> + + <revision> <revnumber>3.15</revnumber> <date>2014-02-03</date> <authorinitials>hv, ap</authorinitials> diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 820f86e8744b..cb7732582f03 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml @@ -94,6 +94,18 @@ </row> <row> <entry></entry> + <entry>&v4l2-event-motion-det;</entry> + <entry><structfield>motion_det</structfield></entry> + <entry>Event data for event V4L2_EVENT_MOTION_DET.</entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-event-src-change;</entry> + <entry><structfield>src_change</structfield></entry> + <entry>Event data for event V4L2_EVENT_SOURCE_CHANGE.</entry> + </row> + <row> + <entry></entry> <entry>__u8</entry> <entry><structfield>data</structfield>[64]</entry> <entry>Event data. Defined by the event type. The union @@ -258,6 +270,44 @@ </tgroup> </table> + <table frame="none" pgwide="1" id="v4l2-event-motion-det"> + <title>struct <structname>v4l2_event_motion_det</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry> + Currently only one flag is available: if <constant>V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ</constant> + is set, then the <structfield>frame_sequence</structfield> field is valid, + otherwise that field should be ignored. + </entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>frame_sequence</structfield></entry> + <entry> + The sequence number of the frame being received. Only valid if the + <constant>V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ</constant> flag was set. + </entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>region_mask</structfield></entry> + <entry> + The bitmask of the regions that reported motion. There is at least one + region. If this field is 0, then no motion was detected at all. + If there is no <constant>V4L2_CID_DETECT_MD_REGION_GRID</constant> control + (see <xref linkend="detect-controls" />) to assign a different region + to each cell in the motion detection grid, then that all cells + are automatically assigned to the default region 0. + </entry> + </row> + </tbody> + </tgroup> + </table> + <table pgwide="1" frame="none" id="changes-flags"> <title>Changes</title> <tgroup cols="3"> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index e9f6735c0823..c5bdbfcc42b3 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml @@ -72,23 +72,30 @@ initialize the <structfield>id</structfield>, <structfield>size</structfield> and <structfield>reserved2</structfield> fields of each &v4l2-ext-control; and call the <constant>VIDIOC_G_EXT_CTRLS</constant> ioctl. String controls controls -must also set the <structfield>string</structfield> field.</para> +must also set the <structfield>string</structfield> field. Controls +of compound types (<constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is set) +must set the <structfield>ptr</structfield> field.</para> <para>If the <structfield>size</structfield> is too small to receive the control result (only relevant for pointer-type controls like strings), then the driver will set <structfield>size</structfield> to a valid value and return an &ENOSPC;. You should re-allocate the -string memory to this new size and try again. It is possible that the -same issue occurs again if the string has grown in the meantime. It is +memory to this new size and try again. For the string type it is possible that +the same issue occurs again if the string has grown in the meantime. It is recommended to call &VIDIOC-QUERYCTRL; first and use <structfield>maximum</structfield>+1 as the new <structfield>size</structfield> value. It is guaranteed that that is sufficient memory. </para> + <para>N-dimensional arrays are set and retrieved row-by-row. You cannot set a partial +array, all elements have to be set or retrieved. The total size is calculated +as <structfield>elems</structfield> * <structfield>elem_size</structfield>. +These values can be obtained by calling &VIDIOC-QUERY-EXT-CTRL;.</para> + <para>To change the value of a set of controls applications initialize the <structfield>id</structfield>, <structfield>size</structfield>, <structfield>reserved2</structfield> and -<structfield>value/string</structfield> fields of each &v4l2-ext-control; and +<structfield>value/value64/string/ptr</structfield> fields of each &v4l2-ext-control; and call the <constant>VIDIOC_S_EXT_CTRLS</constant> ioctl. The controls will only be set if <emphasis>all</emphasis> control values are valid.</para> @@ -96,7 +103,7 @@ valid.</para> <para>To check if a set of controls have correct values applications initialize the <structfield>id</structfield>, <structfield>size</structfield>, <structfield>reserved2</structfield> and -<structfield>value/string</structfield> fields of each &v4l2-ext-control; and +<structfield>value/value64/string/ptr</structfield> fields of each &v4l2-ext-control; and call the <constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctl. It is up to the driver whether wrong values are automatically adjusted to a valid value or if an error is returned.</para> @@ -158,19 +165,47 @@ applications must set the array to zero.</entry> <entry></entry> <entry>__s32</entry> <entry><structfield>value</structfield></entry> - <entry>New value or current value.</entry> + <entry>New value or current value. Valid if this control is not of +type <constant>V4L2_CTRL_TYPE_INTEGER64</constant> and +<constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is not set.</entry> </row> <row> <entry></entry> <entry>__s64</entry> <entry><structfield>value64</structfield></entry> - <entry>New value or current value.</entry> + <entry>New value or current value. Valid if this control is of +type <constant>V4L2_CTRL_TYPE_INTEGER64</constant> and +<constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is not set.</entry> </row> <row> <entry></entry> <entry>char *</entry> <entry><structfield>string</structfield></entry> - <entry>A pointer to a string.</entry> + <entry>A pointer to a string. Valid if this control is of +type <constant>V4L2_CTRL_TYPE_STRING</constant>.</entry> + </row> + <row> + <entry></entry> + <entry>__u8 *</entry> + <entry><structfield>p_u8</structfield></entry> + <entry>A pointer to a matrix control of unsigned 8-bit values. +Valid if this control is of type <constant>V4L2_CTRL_TYPE_U8</constant>.</entry> + </row> + <row> + <entry></entry> + <entry>__u16 *</entry> + <entry><structfield>p_u16</structfield></entry> + <entry>A pointer to a matrix control of unsigned 16-bit values. +Valid if this control is of type <constant>V4L2_CTRL_TYPE_U16</constant>.</entry> + </row> + <row> + <entry></entry> + <entry>void *</entry> + <entry><structfield>ptr</structfield></entry> + <entry>A pointer to a compound type which can be an N-dimensional array and/or a +compound type (the control's type is >= <constant>V4L2_CTRL_COMPOUND_TYPES</constant>). +Valid if <constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant> is set for this control. +</entry> </row> </tbody> </tgroup> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml b/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml index 7c63815e7afd..20460730b02c 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml @@ -152,13 +152,10 @@ a valid base address, so applications can find the corresponding Linux framebuffer device (see <xref linkend="osd" />).</entry> </row> <row> - <entry>&v4l2-pix-format;</entry> + <entry>struct</entry> <entry><structfield>fmt</structfield></entry> <entry></entry> - <entry>Layout of the frame buffer. The -<structname>v4l2_pix_format</structname> structure is defined in <xref -linkend="pixfmt" />, for clarification the fields and acceptable values - are listed below:</entry> + <entry>Layout of the frame buffer.</entry> </row> <row> <entry></entry> @@ -276,9 +273,8 @@ see <xref linkend="colorspaces" />.</entry> <entry></entry> <entry>__u32</entry> <entry><structfield>priv</structfield></entry> - <entry>Reserved for additional information about custom -(driver defined) formats. When not used drivers and applications must -set this field to zero.</entry> + <entry>Reserved. Drivers and applications must set this field to +zero.</entry> </row> </tbody> </tgroup> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml index b11ec75e21a1..9c04ac8661b1 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml @@ -58,17 +58,16 @@ <para>The ioctls are used to query and configure selection rectangles.</para> -<para> To query the cropping (composing) rectangle set &v4l2-selection; +<para>To query the cropping (composing) rectangle set &v4l2-selection; <structfield> type </structfield> field to the respective buffer type. -Do not use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE -</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE -</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of -<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is +Do not use multiplanar buffers. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> +instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>. Use +<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of +<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>. The next step is setting the value of &v4l2-selection; <structfield>target</structfield> field -to <constant> V4L2_SEL_TGT_CROP </constant> (<constant> -V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref -linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional -targets. The <structfield>flags</structfield> and <structfield>reserved +to <constant>V4L2_SEL_TGT_CROP</constant> (<constant>V4L2_SEL_TGT_COMPOSE</constant>). +Please refer to table <xref linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> +for additional targets. The <structfield>flags</structfield> and <structfield>reserved </structfield> fields of &v4l2-selection; are ignored and they must be filled with zeros. The driver fills the rest of the structure or returns &EINVAL; if incorrect buffer type or target was used. If cropping @@ -77,19 +76,18 @@ always equal to the bounds rectangle. Finally, the &v4l2-rect; <structfield>r</structfield> rectangle is filled with the current cropping (composing) coordinates. The coordinates are expressed in driver-dependent units. The only exception are rectangles for images in raw formats, whose -coordinates are always expressed in pixels. </para> +coordinates are always expressed in pixels.</para> -<para> To change the cropping (composing) rectangle set the &v4l2-selection; +<para>To change the cropping (composing) rectangle set the &v4l2-selection; <structfield>type</structfield> field to the respective buffer type. Do not -use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE -</constant> instead of <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE -</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of -<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is +use multiplanar buffers. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> +instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>. Use +<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of +<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>. The next step is setting the value of &v4l2-selection; <structfield>target</structfield> to -<constant>V4L2_SEL_TGT_CROP</constant> (<constant> -V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref -linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional -targets. The &v4l2-rect; <structfield>r</structfield> rectangle need to be +<constant>V4L2_SEL_TGT_CROP</constant> (<constant>V4L2_SEL_TGT_COMPOSE</constant>). +Please refer to table <xref linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> +for additional targets. The &v4l2-rect; <structfield>r</structfield> rectangle need to be set to the desired active area. Field &v4l2-selection; <structfield> reserved </structfield> is ignored and must be filled with zeros. The driver may adjust coordinates of the requested rectangle. An application may @@ -149,8 +147,8 @@ On success the &v4l2-rect; <structfield>r</structfield> field contains the adjusted rectangle. When the parameters are unsuitable the application may modify the cropping (composing) or image parameters and repeat the cycle until satisfactory parameters have been negotiated. If constraints flags have to be -violated at then ERANGE is returned. The error indicates that <emphasis> there -exist no rectangle </emphasis> that satisfies the constraints.</para> +violated at then ERANGE is returned. The error indicates that <emphasis>there +exist no rectangle</emphasis> that satisfies the constraints.</para> <para>Selection targets and flags are documented in <xref linkend="v4l2-selections-common"/>.</para> diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index 370d49d6fb64..d0c5e604f014 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -302,6 +302,12 @@ modulator programming see <link linkend="sdr">SDR Capture</link> interface.</entry> </row> <row> + <entry><constant>V4L2_CAP_EXT_PIX_FORMAT</constant></entry> + <entry>0x00200000</entry> + <entry>The device supports the &v4l2-pix-format; extended +fields.</entry> + </row> + <row> <entry><constant>V4L2_CAP_READWRITE</constant></entry> <entry>0x01000000</entry> <entry>The device supports the <link diff --git a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml index e6645b996558..2bd98fd7a4e5 100644 --- a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml +++ b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml @@ -1,11 +1,12 @@ <refentry id="vidioc-queryctrl"> <refmeta> - <refentrytitle>ioctl VIDIOC_QUERYCTRL, VIDIOC_QUERYMENU</refentrytitle> + <refentrytitle>ioctl VIDIOC_QUERYCTRL, VIDIOC_QUERY_EXT_CTRL, VIDIOC_QUERYMENU</refentrytitle> &manvol; </refmeta> <refnamediv> <refname>VIDIOC_QUERYCTRL</refname> + <refname>VIDIOC_QUERY_EXT_CTRL</refname> <refname>VIDIOC_QUERYMENU</refname> <refpurpose>Enumerate controls and menu control items</refpurpose> </refnamediv> @@ -24,6 +25,14 @@ <funcdef>int <function>ioctl</function></funcdef> <paramdef>int <parameter>fd</parameter></paramdef> <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>struct v4l2_query_ext_ctrl *<parameter>argp</parameter></paramdef> + </funcprototype> + </funcsynopsis> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> <paramdef>struct v4l2_querymenu *<parameter>argp</parameter></paramdef> </funcprototype> </funcsynopsis> @@ -42,7 +51,7 @@ <varlistentry> <term><parameter>request</parameter></term> <listitem> - <para>VIDIOC_QUERYCTRL, VIDIOC_QUERYMENU</para> + <para>VIDIOC_QUERYCTRL, VIDIOC_QUERY_EXT_CTRL, VIDIOC_QUERYMENU</para> </listitem> </varlistentry> <varlistentry> @@ -67,7 +76,7 @@ structure. The driver fills the rest of the structure or returns an <constant>VIDIOC_QUERYCTRL</constant> with successive <structfield>id</structfield> values starting from <constant>V4L2_CID_BASE</constant> up to and exclusive -<constant>V4L2_CID_BASE_LASTP1</constant>. Drivers may return +<constant>V4L2_CID_LASTP1</constant>. Drivers may return <errorcode>EINVAL</errorcode> if a control in this range is not supported. Further applications can enumerate private controls, which are not defined in this specification, by starting at @@ -89,9 +98,23 @@ prematurely end the enumeration).</para></footnote></para> <para>When the application ORs <structfield>id</structfield> with <constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> the driver returns the -next supported control, or <errorcode>EINVAL</errorcode> if there is -none. Drivers which do not support this flag yet always return -<errorcode>EINVAL</errorcode>.</para> +next supported non-compound control, or <errorcode>EINVAL</errorcode> +if there is none. In addition, the <constant>V4L2_CTRL_FLAG_NEXT_COMPOUND</constant> +flag can be specified to enumerate all compound controls (i.e. controls +with type ≥ <constant>V4L2_CTRL_COMPOUND_TYPES</constant>). Specify both +<constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> and +<constant>V4L2_CTRL_FLAG_NEXT_COMPOUND</constant> in order to enumerate +all controls, compound or not. Drivers which do not support these flags yet +always return <errorcode>EINVAL</errorcode>.</para> + + <para>The <constant>VIDIOC_QUERY_EXT_CTRL</constant> ioctl was +introduced in order to better support controls that can use compound +types, and to expose additional control information that cannot be +returned in &v4l2-queryctrl; since that structure is full.</para> + + <para><constant>VIDIOC_QUERY_EXT_CTRL</constant> is used in the +same way as <constant>VIDIOC_QUERYCTRL</constant>, except that the +<structfield>reserved</structfield> array must be zeroed as well.</para> <para>Additional information is required for menu controls: the names of the menu items. To query them applications set the @@ -142,38 +165,23 @@ string. This information is intended for the user.</entry> <entry>__s32</entry> <entry><structfield>minimum</structfield></entry> <entry>Minimum value, inclusive. This field gives a lower -bound for <constant>V4L2_CTRL_TYPE_INTEGER</constant> controls and the -lowest valid index for <constant>V4L2_CTRL_TYPE_MENU</constant> controls. -For <constant>V4L2_CTRL_TYPE_STRING</constant> controls the minimum value -gives the minimum length of the string. This length <emphasis>does not include the terminating -zero</emphasis>. It may not be valid for any other type of control, including -<constant>V4L2_CTRL_TYPE_INTEGER64</constant> controls. Note that this is a -signed value.</entry> +bound for the control. See &v4l2-ctrl-type; how the minimum value is to +be used for each possible control type. Note that this a signed 32-bit value.</entry> </row> <row> <entry>__s32</entry> <entry><structfield>maximum</structfield></entry> <entry>Maximum value, inclusive. This field gives an upper -bound for <constant>V4L2_CTRL_TYPE_INTEGER</constant> controls and the -highest valid index for <constant>V4L2_CTRL_TYPE_MENU</constant> -controls. For <constant>V4L2_CTRL_TYPE_BITMASK</constant> controls it is the -set of usable bits. -For <constant>V4L2_CTRL_TYPE_STRING</constant> controls the maximum value -gives the maximum length of the string. This length <emphasis>does not include the terminating -zero</emphasis>. It may not be valid for any other type of control, including -<constant>V4L2_CTRL_TYPE_INTEGER64</constant> controls. Note that this is a -signed value.</entry> +bound for the control. See &v4l2-ctrl-type; how the maximum value is to +be used for each possible control type. Note that this a signed 32-bit value.</entry> </row> <row> <entry>__s32</entry> <entry><structfield>step</structfield></entry> - <entry><para>This field gives a step size for -<constant>V4L2_CTRL_TYPE_INTEGER</constant> controls. For -<constant>V4L2_CTRL_TYPE_STRING</constant> controls this field refers to -the string length that has to be a multiple of this step size. -It may not be valid for any other type of control, including -<constant>V4L2_CTRL_TYPE_INTEGER64</constant> -controls.</para><para>Generally drivers should not scale hardware + <entry><para>This field gives a step size for the control. +See &v4l2-ctrl-type; how the step value is to be used for each possible +control type. Note that this an unsigned 32-bit value. +</para><para>Generally drivers should not scale hardware control values. It may be necessary for example when the <structfield>name</structfield> or <structfield>id</structfield> imply a particular unit and the hardware actually accepts only multiples of @@ -192,10 +200,11 @@ be always positive.</para></entry> <entry><structfield>default_value</structfield></entry> <entry>The default value of a <constant>V4L2_CTRL_TYPE_INTEGER</constant>, -<constant>_BOOLEAN</constant> or <constant>_MENU</constant> control. -Not valid for other types of controls. Drivers reset controls only -when the driver is loaded, not later, in particular not when the -func-open; is called.</entry> +<constant>_BOOLEAN</constant>, <constant>_BITMASK</constant>, +<constant>_MENU</constant> or <constant>_INTEGER_MENU</constant> control. +Not valid for other types of controls. +Note that drivers reset controls to their default value only when the +driver is first loaded, never afterwards.</entry> </row> <row> <entry>__u32</entry> @@ -213,6 +222,126 @@ the array to zero.</entry> </tgroup> </table> + <table pgwide="1" frame="none" id="v4l2-query-ext-ctrl"> + <title>struct <structname>v4l2_query_ext_ctrl</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>id</structfield></entry> + <entry>Identifies the control, set by the application. See +<xref linkend="control-id" /> for predefined IDs. When the ID is ORed +with <constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> the driver clears the +flag and returns the first non-compound control with a higher ID. When the +ID is ORed with <constant>V4L2_CTRL_FLAG_NEXT_COMPOUND</constant> the driver +clears the flag and returns the first compound control with a higher ID. +Set both to get the first control (compound or not) with a higher ID.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>type</structfield></entry> + <entry>Type of control, see <xref + linkend="v4l2-ctrl-type" />.</entry> + </row> + <row> + <entry>char</entry> + <entry><structfield>name</structfield>[32]</entry> + <entry>Name of the control, a NUL-terminated ASCII +string. This information is intended for the user.</entry> + </row> + <row> + <entry>__s64</entry> + <entry><structfield>minimum</structfield></entry> + <entry>Minimum value, inclusive. This field gives a lower +bound for the control. See &v4l2-ctrl-type; how the minimum value is to +be used for each possible control type. Note that this a signed 64-bit value.</entry> + </row> + <row> + <entry>__s64</entry> + <entry><structfield>maximum</structfield></entry> + <entry>Maximum value, inclusive. This field gives an upper +bound for the control. See &v4l2-ctrl-type; how the maximum value is to +be used for each possible control type. Note that this a signed 64-bit value.</entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>step</structfield></entry> + <entry><para>This field gives a step size for the control. +See &v4l2-ctrl-type; how the step value is to be used for each possible +control type. Note that this an unsigned 64-bit value. +</para><para>Generally drivers should not scale hardware +control values. It may be necessary for example when the +<structfield>name</structfield> or <structfield>id</structfield> imply +a particular unit and the hardware actually accepts only multiples of +said unit. If so, drivers must take care values are properly rounded +when scaling, such that errors will not accumulate on repeated +read-write cycles.</para><para>This field gives the smallest change of +an integer control actually affecting hardware. Often the information +is needed when the user can change controls by keyboard or GUI +buttons, rather than a slider. When for example a hardware register +accepts values 0-511 and the driver reports 0-65535, step should be +128.</para></entry> + </row> + <row> + <entry>__s64</entry> + <entry><structfield>default_value</structfield></entry> + <entry>The default value of a +<constant>V4L2_CTRL_TYPE_INTEGER</constant>, <constant>_INTEGER64</constant>, +<constant>_BOOLEAN</constant>, <constant>_BITMASK</constant>, +<constant>_MENU</constant>, <constant>_INTEGER_MENU</constant>, +<constant>_U8</constant> or <constant>_U16</constant> control. +Not valid for other types of controls. +Note that drivers reset controls to their default value only when the +driver is first loaded, never afterwards. +</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry>Control flags, see <xref + linkend="control-flags" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>elem_size</structfield></entry> + <entry>The size in bytes of a single element of the array. +Given a char pointer <constant>p</constant> to a 3-dimensional array you can find the +position of cell <constant>(z, y, x)</constant> as follows: +<constant>p + ((z * dims[1] + y) * dims[0] + x) * elem_size</constant>. <structfield>elem_size</structfield> +is always valid, also when the control isn't an array. For string controls +<structfield>elem_size</structfield> is equal to <structfield>maximum + 1</structfield>. +</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>elems</structfield></entry> + <entry>The number of elements in the N-dimensional array. If this control +is not an array, then <structfield>elems</structfield> is 1. The <structfield>elems</structfield> +field can never be 0.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>nr_of_dims</structfield></entry> + <entry>The number of dimension in the N-dimensional array. If this control +is not an array, then this field is 0.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>dims[V4L2_CTRL_MAX_DIMS]</structfield></entry> + <entry>The size of each dimension. The first <structfield>nr_of_dims</structfield> +elements of this array must be non-zero, all remaining elements must be zero.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[32]</entry> + <entry>Reserved for future extensions. Applications and drivers +must set the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + <table pgwide="1" frame="none" id="v4l2-querymenu"> <title>struct <structname>v4l2_querymenu</structname></title> <tgroup cols="4"> @@ -347,11 +476,14 @@ Drivers must ignore the value passed with </row> <row> <entry><constant>V4L2_CTRL_TYPE_INTEGER64</constant></entry> - <entry>n/a</entry> - <entry>n/a</entry> - <entry>n/a</entry> + <entry>any</entry> + <entry>any</entry> + <entry>any</entry> <entry>A 64-bit integer valued control. Minimum, maximum -and step size cannot be queried.</entry> +and step size cannot be queried using <constant>VIDIOC_QUERYCTRL</constant>. +Only <constant>VIDIOC_QUERY_EXT_CTRL</constant> can retrieve the 64-bit +min/max/step values, they should be interpreted as n/a when using +<constant>VIDIOC_QUERYCTRL</constant>.</entry> </row> <row> <entry><constant>V4L2_CTRL_TYPE_STRING</constant></entry> @@ -379,6 +511,26 @@ ioctl returns the name of the control class and this control type. Older drivers which do not support this feature return an &EINVAL;.</entry> </row> + <row> + <entry><constant>V4L2_CTRL_TYPE_U8</constant></entry> + <entry>any</entry> + <entry>any</entry> + <entry>any</entry> + <entry>An unsigned 8-bit valued control ranging from minimum to +maximum inclusive. The step value indicates the increment between +values which are actually different on the hardware. +</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_TYPE_U16</constant></entry> + <entry>any</entry> + <entry>any</entry> + <entry>any</entry> + <entry>An unsigned 16-bit valued control ranging from minimum to +maximum inclusive. The step value indicates the increment between +values which are actually different on the hardware. +</entry> + </row> </tbody> </tgroup> </table> @@ -450,6 +602,14 @@ is in auto-gain mode. In such a case the hardware calculates the gain value base the lighting conditions which can change over time. Note that setting a new value for a volatile control will have no effect. The new value will just be ignored.</entry> </row> + <row> + <entry><constant>V4L2_CTRL_FLAG_HAS_PAYLOAD</constant></entry> + <entry>0x0100</entry> + <entry>This control has a pointer type, so its value has to be accessed +using one of the pointer fields of &v4l2-ext-control;. This flag is set for controls +that are an array, string, or have a compound type. In all cases you have to set a +pointer to memory containing the payload of the control.</entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 17efa870d4d2..9f6095608837 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml @@ -175,6 +175,14 @@ </entry> </row> <row> + <entry><constant>V4L2_EVENT_MOTION_DET</constant></entry> + <entry>5</entry> + <entry> + <para>Triggered whenever the motion detection state for one or more of the regions + changes. This event has a &v4l2-event-motion-det; associated with it.</para> + </entry> + </row> + <row> <entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry> <entry>0x08000000</entry> <entry>Base event number for driver-private events.</entry> diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt index 2f0fcb2112d2..f29bcbc463e7 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt @@ -2451,8 +2451,8 @@ lot of {Linux} into your technology!!!" ,month="February" ,year="2010" ,note="Available: -\url{http://kerneltrap.com/mailarchive/linux-netdev/2010/2/26/6270589} -[Viewed March 20, 2011]" +\url{http://thread.gmane.org/gmane.linux.network/153338} +[Viewed June 9, 2014]" ,annotation={ Use a pair of list_head structures to support RCU-protected resizable hash tables. diff --git a/Documentation/RCU/rcuref.txt b/Documentation/RCU/rcuref.txt index 141d531aa14b..613033ff2b9b 100644 --- a/Documentation/RCU/rcuref.txt +++ b/Documentation/RCU/rcuref.txt @@ -1,5 +1,14 @@ Reference-count design for elements of lists/arrays protected by RCU. + +Please note that the percpu-ref feature is likely your first +stop if you need to combine reference counts and RCU. Please see +include/linux/percpu-refcount.h for more information. However, in +those unusual cases where percpu-ref would consume too much memory, +please read on. + +------------------------------------------------------------------------ + Reference counting on elements of lists which are protected by traditional reader/writer spinlocks or semaphores are straightforward: diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index fd786ea13a1f..e182be5e3c83 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -60,12 +60,6 @@ If the driver needs to perform more complex initialization like getting and configuring GPIOs it can get its ACPI handle and extract this information from ACPI tables. -Currently the kernel is not able to automatically determine from which ACPI -device it should make the corresponding platform device so we need to add -the ACPI device explicitly to acpi_platform_device_ids list defined in -drivers/acpi/acpi_platform.c. This limitation is only for the platform -devices, SPI and I2C devices are created automatically as described below. - DMA support ~~~~~~~~~~~ DMA controllers enumerated via ACPI should be registered in the system to diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index 37fc4f632176..85af34d55cee 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -72,27 +72,54 @@ The decompressed kernel image contains a 64-byte header as follows: u32 code0; /* Executable code */ u32 code1; /* Executable code */ - u64 text_offset; /* Image load offset */ - u64 res0 = 0; /* reserved */ - u64 res1 = 0; /* reserved */ + u64 text_offset; /* Image load offset, little endian */ + u64 image_size; /* Effective Image size, little endian */ + u64 flags; /* kernel flags, little endian */ u64 res2 = 0; /* reserved */ u64 res3 = 0; /* reserved */ u64 res4 = 0; /* reserved */ u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */ - u32 res5 = 0; /* reserved */ + u32 res5; /* reserved (used for PE COFF offset) */ Header notes: +- As of v3.17, all fields are little endian unless stated otherwise. + - code0/code1 are responsible for branching to stext. + - when booting through EFI, code0/code1 are initially skipped. res5 is an offset to the PE header and the PE header has the EFI - entry point (efi_stub_entry). When the stub has done its work, it + entry point (efi_stub_entry). When the stub has done its work, it jumps to code0 to resume the normal boot process. -The image must be placed at the specified offset (currently 0x80000) -from the start of the system RAM and called there. The start of the -system RAM must be aligned to 2MB. +- Prior to v3.17, the endianness of text_offset was not specified. In + these cases image_size is zero and text_offset is 0x80000 in the + endianness of the kernel. Where image_size is non-zero image_size is + little-endian and must be respected. Where image_size is zero, + text_offset can be assumed to be 0x80000. + +- The flags field (introduced in v3.17) is a little-endian 64-bit field + composed as follows: + Bit 0: Kernel endianness. 1 if BE, 0 if LE. + Bits 1-63: Reserved. + +- When image_size is zero, a bootloader should attempt to keep as much + memory as possible free for use by the kernel immediately after the + end of the kernel image. The amount of space required will vary + depending on selected features, and is effectively unbound. + +The Image must be placed text_offset bytes from a 2MB aligned base +address near the start of usable system RAM and called there. Memory +below that base address is currently unusable by Linux, and therefore it +is strongly recommended that this location is the start of system RAM. +At least image_size bytes from the start of the image must be free for +use by the kernel. + +Any memory described to the kernel (even that below the 2MB aligned base +address) which is not marked as reserved from the kernel e.g. with a +memreserve region in the device tree) will be considered as available to +the kernel. Before jumping into the kernel, the following conditions must be met: diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt index d50fa618371b..344e85cc7323 100644 --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -2,18 +2,18 @@ ============================== Author: Catalin Marinas <catalin.marinas@arm.com> -Date : 20 February 2012 This document describes the virtual memory layout used by the AArch64 Linux kernel. The architecture allows up to 4 levels of translation tables with a 4KB page size and up to 3 levels with a 64KB page size. -AArch64 Linux uses 3 levels of translation tables with the 4KB page -configuration, allowing 39-bit (512GB) virtual addresses for both user -and kernel. With 64KB pages, only 2 levels of translation tables are -used but the memory layout is the same. +AArch64 Linux uses either 3 levels or 4 levels of translation tables +with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit +(256TB) virtual addresses, respectively, for both user and kernel. With +64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB) +virtual address, are used but the memory layout is the same. -User addresses have bits 63:39 set to 0 while the kernel addresses have +User addresses have bits 63:48 set to 0 while the kernel addresses have the same bits set to 1. TTBRx selection is given by bit 63 of the virtual address. The swapper_pg_dir contains only kernel (global) mappings while the user pgd contains only user (non-global) mappings. @@ -21,58 +21,40 @@ The swapper_pgd_dir address is written to TTBR1 and never written to TTBR0. -AArch64 Linux memory layout with 4KB pages: +AArch64 Linux memory layout with 4KB pages + 3 levels: Start End Size Use ----------------------------------------------------------------------- 0000000000000000 0000007fffffffff 512GB user +ffffff8000000000 ffffffffffffffff 512GB kernel -ffffff8000000000 ffffffbbfffeffff ~240GB vmalloc -ffffffbbffff0000 ffffffbbffffffff 64KB [guard page] +AArch64 Linux memory layout with 4KB pages + 4 levels: -ffffffbc00000000 ffffffbdffffffff 8GB vmemmap - -ffffffbe00000000 ffffffbffbbfffff ~8GB [guard, future vmmemap] - -ffffffbffa000000 ffffffbffaffffff 16MB PCI I/O space - -ffffffbffb000000 ffffffbffbbfffff 12MB [guard] - -ffffffbffbc00000 ffffffbffbdfffff 2MB fixed mappings - -ffffffbffbe00000 ffffffbffbffffff 2MB [guard] - -ffffffbffc000000 ffffffbfffffffff 64MB modules - -ffffffc000000000 ffffffffffffffff 256GB kernel logical memory map +Start End Size Use +----------------------------------------------------------------------- +0000000000000000 0000ffffffffffff 256TB user +ffff000000000000 ffffffffffffffff 256TB kernel -AArch64 Linux memory layout with 64KB pages: +AArch64 Linux memory layout with 64KB pages + 2 levels: Start End Size Use ----------------------------------------------------------------------- 0000000000000000 000003ffffffffff 4TB user +fffffc0000000000 ffffffffffffffff 4TB kernel -fffffc0000000000 fffffdfbfffeffff ~2TB vmalloc -fffffdfbffff0000 fffffdfbffffffff 64KB [guard page] +AArch64 Linux memory layout with 64KB pages + 3 levels: -fffffdfc00000000 fffffdfdffffffff 8GB vmemmap - -fffffdfe00000000 fffffdfffbbfffff ~8GB [guard, future vmmemap] - -fffffdfffa000000 fffffdfffaffffff 16MB PCI I/O space - -fffffdfffb000000 fffffdfffbbfffff 12MB [guard] - -fffffdfffbc00000 fffffdfffbdfffff 2MB fixed mappings - -fffffdfffbe00000 fffffdfffbffffff 2MB [guard] +Start End Size Use +----------------------------------------------------------------------- +0000000000000000 0000ffffffffffff 256TB user +ffff000000000000 ffffffffffffffff 256TB kernel -fffffdfffc000000 fffffdffffffffff 64MB modules -fffffe0000000000 ffffffffffffffff 2TB kernel logical memory map +For details of the virtual kernel memory layout please see the kernel +booting log. Translation table lookup with 4KB pages: @@ -86,7 +68,7 @@ Translation table lookup with 4KB pages: | | | | +-> [20:12] L3 index | | | +-----------> [29:21] L2 index | | +---------------------> [38:30] L1 index - | +-------------------------------> [47:39] L0 index (not used) + | +-------------------------------> [47:39] L0 index +-------------------------------------------------> [63] TTBR0/1 @@ -99,10 +81,11 @@ Translation table lookup with 64KB pages: | | | | v | | | | [15:0] in-page offset | | | +----------> [28:16] L3 index - | | +--------------------------> [41:29] L2 index (only 38:29 used) - | +-------------------------------> [47:42] L1 index (not used) + | | +--------------------------> [41:29] L2 index + | +-------------------------------> [47:42] L1 index +-------------------------------------------------> [63] TTBR0/1 + When using KVM, the hypervisor maps kernel pages in EL2, at a fixed offset from the kernel VA (top 24bits of the kernel VA set to zero): diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index 821de56d1580..10c949b293e4 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -599,6 +599,20 @@ fork. If this method returns 0 (success) then this should remain valid while the caller holds cgroup_mutex and it is ensured that either attach() or cancel_attach() will be called in future. +void css_reset(struct cgroup_subsys_state *css) +(cgroup_mutex held by caller) + +An optional operation which should restore @css's configuration to the +initial state. This is currently only used on the unified hierarchy +when a subsystem is disabled on a cgroup through +"cgroup.subtree_control" but should remain enabled because other +subsystems depend on it. cgroup core makes such a css invisible by +removing the associated interface files and invokes this callback so +that the hidden subsystem can return to the initial neutral state. +This prevents unexpected resource control from a hidden css and +ensures that the configuration is in the initial state when it is made +visible again later. + void cancel_attach(struct cgroup *cgrp, struct cgroup_taskset *tset) (cgroup_mutex held by caller) diff --git a/Documentation/cgroups/unified-hierarchy.txt b/Documentation/cgroups/unified-hierarchy.txt index 324b182e6000..4f4563277864 100644 --- a/Documentation/cgroups/unified-hierarchy.txt +++ b/Documentation/cgroups/unified-hierarchy.txt @@ -94,12 +94,35 @@ change soon. mount -t cgroup -o __DEVEL__sane_behavior cgroup $MOUNT_POINT -All controllers which are not bound to other hierarchies are -automatically bound to unified hierarchy and show up at the root of -it. Controllers which are enabled only in the root of unified -hierarchy can be bound to other hierarchies at any time. This allows -mixing unified hierarchy with the traditional multiple hierarchies in -a fully backward compatible way. +All controllers which support the unified hierarchy and are not bound +to other hierarchies are automatically bound to unified hierarchy and +show up at the root of it. Controllers which are enabled only in the +root of unified hierarchy can be bound to other hierarchies. This +allows mixing unified hierarchy with the traditional multiple +hierarchies in a fully backward compatible way. + +For development purposes, the following boot parameter makes all +controllers to appear on the unified hierarchy whether supported or +not. + + cgroup__DEVEL__legacy_files_on_dfl + +A controller can be moved across hierarchies only after the controller +is no longer referenced in its current hierarchy. Because per-cgroup +controller states are destroyed asynchronously and controllers may +have lingering references, a controller may not show up immediately on +the unified hierarchy after the final umount of the previous +hierarchy. Similarly, a controller should be fully disabled to be +moved out of the unified hierarchy and it may take some time for the +disabled controller to become available for other hierarchies; +furthermore, due to dependencies among controllers, other controllers +may need to be disabled too. + +While useful for development and manual configurations, dynamically +moving controllers between the unified and other hierarchies is +strongly discouraged for production use. It is recommended to decide +the hierarchies and controller associations before starting using the +controllers. 2-2. cgroup.subtree_control diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt index fb88585cfb93..4139db353d0a 100644 --- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt @@ -10,6 +10,7 @@ Required properties: - compatible : Should be "ti,irq-crossbar" - reg: Base address and the size of the crossbar registers. - ti,max-irqs: Total number of irqs available at the interrupt controller. +- ti,max-crossbar-sources: Maximum number of crossbar sources that can be routed. - ti,reg-size: Size of a individual register in bytes. Every individual register is assumed to be of same size. Valid sizes are 1, 2, 4. - ti,irqs-reserved: List of the reserved irq lines that are not muxed using @@ -17,11 +18,46 @@ Required properties: so crossbar bar driver should not consider them as free lines. +Optional properties: +- ti,irqs-skip: This is similar to "ti,irqs-reserved", but these are for + SOC-specific hard-wiring of those irqs which unexpectedly bypasses the + crossbar. These irqs have a crossbar register, but still cannot be used. + +- ti,irqs-safe-map: integer which maps to a safe configuration to use + when the interrupt controller irq is unused (when not provided, default is 0) + Examples: crossbar_mpu: @4a020000 { compatible = "ti,irq-crossbar"; reg = <0x4a002a48 0x130>; ti,max-irqs = <160>; + ti,max-crossbar-sources = <400>; ti,reg-size = <2>; ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>; + ti,irqs-skip = <10 133 139 140>; }; + +Consumer: +======== +See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and +Documentation/devicetree/bindings/arm/gic.txt for further details. + +An interrupt consumer on an SoC using crossbar will use: + interrupts = <GIC_SPI request_number interrupt_level> +When the request number is between 0 to that described by +"ti,max-crossbar-sources", it is assumed to be a crossbar mapping. If the +request_number is greater than "ti,max-crossbar-sources", then it is mapped as a +quirky hardware mapping direct to GIC. + +Example: + device_x@0x4a023000 { + /* Crossbar 8 used */ + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; + ... + }; + + device_y@0x4a033000 { + /* Direct mapped GIC SPI 1 used */ + interrupts = <GIC_SPI DIRECT_IRQ(1) IRQ_TYPE_LEVEL_HIGH>; + ... + }; diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt index 832fe8cc24d7..adc61b095bd1 100644 --- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt @@ -14,14 +14,21 @@ Required properties: for exynos4412/5250 controllers. Must be "samsung,exynos-adc-v2" for future controllers. + Must be "samsung,exynos3250-adc" for + controllers compatible with ADC of Exynos3250. - reg: Contains ADC register address range (base address and length) and the address of the phy enable register. - interrupts: Contains the interrupt information for the timer. The format is being dependent on which interrupt controller the Samsung device uses. - #io-channel-cells = <1>; As ADC has multiple outputs -- clocks From common clock binding: handle to adc clock. -- clock-names From common clock binding: Shall be "adc". +- clocks From common clock bindings: handles to clocks specified + in "clock-names" property, in the same order. +- clock-names From common clock bindings: list of clock input names + used by ADC block: + - "adc" : ADC bus clock + - "sclk" : ADC special clock (only for Exynos3250 and + compatible ADC block) - vdd-supply VDD input supply. Note: child nodes can be added for auto probing from device tree. @@ -41,6 +48,20 @@ adc: adc@12D10000 { vdd-supply = <&buck5_reg>; }; +Example: adding device info in dtsi file for Exynos3250 with additional sclk + +adc: adc@126C0000 { + compatible = "samsung,exynos3250-adc", "samsung,exynos-adc-v2; + reg = <0x126C0000 0x100>, <0x10020718 0x4>; + interrupts = <0 137 0>; + #io-channel-cells = <1>; + io-channel-ranges; + + clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>; + clock-names = "adc", "sclk"; + + vdd-supply = <&buck5_reg>; +}; Example: Adding child nodes in dts file diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt index 2a4ab046a8a1..f9865e77e0b0 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt @@ -12,8 +12,38 @@ Properties: - reg : offset and length of the register set. + - #clock-cells : must be <1>, since PMU requires once cell as clock specifier. + The single specifier cell is used as index to list of clocks + provided by PMU, which is currently: + 0 : SoC clock output (CLKOUT pin) + + - clock-names : list of clock names for particular CLKOUT mux inputs in + following format: + "clkoutN", where N is a decimal number corresponding to + CLKOUT mux control bits value for given input, e.g. + "clkout0", "clkout7", "clkout15". + + - clocks : list of phandles and specifiers to all input clocks listed in + clock-names property. + Example : pmu_system_controller: system-controller@10040000 { compatible = "samsung,exynos5250-pmu", "syscon"; reg = <0x10040000 0x5000>; + #clock-cells = <1>; + clock-names = "clkout0", "clkout1", "clkout2", "clkout3", + "clkout4", "clkout8", "clkout9"; + clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>, + <&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>, + <&clock CLK_OUT_CPU>, <&clock CLK_XXTI>, + <&clock CLK_XUSBXTI>; +}; + +Example of clock consumer : + +usb3503: usb3503@08 { + /* ... */ + clock-names = "refclk"; + clocks = <&pmu_system_controller 0>; + /* ... */ }; diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index c96d8dcf98fd..4ab09f2202d4 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -3,28 +3,43 @@ SATA nodes are defined to describe on-chip Serial ATA controllers. Each SATA controller should have its own node. +It is possible, but not required, to represent each port as a sub-node. +It allows to enable each port independently when dealing with multiple +PHYs. + Required properties: - compatible : compatible string, one of: - "allwinner,sun4i-a10-ahci" - - "fsl,imx53-ahci" - - "fsl,imx6q-ahci" - "hisilicon,hisi-ahci" - "ibm,476gtr-ahci" - "marvell,armada-380-ahci" - "snps,dwc-ahci" - "snps,exynos5440-ahci" - "snps,spear-ahci" + - "generic-ahci" - interrupts : <interrupt mapping for SATA IRQ> - reg : <registers mapping> +Please note that when using "generic-ahci" you must also specify a SoC specific +compatible: + compatible = "manufacturer,soc-model-ahci", "generic-ahci"; + Optional properties: - dma-coherent : Present if dma operations are coherent - clocks : a list of phandle + clock specifier pairs - target-supply : regulator for SATA target power +- phys : reference to the SATA PHY node +- phy-names : must be "sata-phy" + +Required properties when using sub-nodes: +- #address-cells : number of cells to encode an address +- #size-cells : number of cells representing the size of an address + + +Sub-nodes required properties: +- reg : the port number +- phys : reference to the SATA PHY node -"fsl,imx53-ahci", "fsl,imx6q-ahci" required properties: -- clocks : must contain the sata, sata_ref and ahb clocks -- clock-names : must contain "ahb" for the ahb clock Examples: sata@ffe08000 { @@ -40,3 +55,23 @@ Examples: clocks = <&pll6 0>, <&ahb_gates 25>; target-supply = <®_ahci_5v>; }; + +With sub-nodes: + sata@f7e90000 { + compatible = "marvell,berlin2q-achi", "generic-ahci"; + reg = <0xe90000 0x1000>; + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&chip CLKID_SATA>; + #address-cells = <1>; + #size-cells = <0>; + + sata0: sata-port@0 { + reg = <0>; + phys = <&sata_phy 0>; + }; + + sata1: sata-port@1 { + reg = <1>; + phys = <&sata_phy 1>; + }; + }; diff --git a/Documentation/devicetree/bindings/ata/ahci-st.txt b/Documentation/devicetree/bindings/ata/ahci-st.txt new file mode 100644 index 000000000000..0574a77a0b9f --- /dev/null +++ b/Documentation/devicetree/bindings/ata/ahci-st.txt @@ -0,0 +1,31 @@ +STMicroelectronics STi SATA controller + +This binding describes a SATA device. + +Required properties: + - compatible : Must be "st,sti-ahci" + - reg : Physical base addresses and length of register sets + - interrupts : Interrupt associated with the SATA device + - interrupt-names : Associated name must be; "hostc" + - resets : The power-down and soft-reset lines of SATA IP + - reset-names : Associated names must be; "pwr-dwn" and "sw-rst" + - clocks : The phandle for the clock + - clock-names : Associated name must be; "ahci_clk" + - phys : The phandle for the PHY device + - phy-names : Associated name must be; "ahci_phy" + +Example: + + sata0: sata@fe380000 { + compatible = "st,sti-ahci"; + reg = <0xfe380000 0x1000>; + interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>; + interrupt-names = "hostc"; + phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>; + phy-names = "ahci_phy"; + resets = <&powerdown STIH416_SATA0_POWERDOWN>, + <&softreset STIH416_SATA0_SOFTRESET>; + reset-names = "pwr-dwn", "sw-rst"; + clocks = <&clk_s_a0_ls CLK_ICN_REG>; + clock-names = "ahci_clk"; + }; diff --git a/Documentation/devicetree/bindings/ata/imx-sata.txt b/Documentation/devicetree/bindings/ata/imx-sata.txt new file mode 100644 index 000000000000..fa511db18408 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/imx-sata.txt @@ -0,0 +1,36 @@ +* Freescale i.MX AHCI SATA Controller + +The Freescale i.MX SATA controller mostly conforms to the AHCI interface +with some special extensions at integration level. + +Required properties: +- compatible : should be one of the following: + - "fsl,imx53-ahci" for i.MX53 SATA controller + - "fsl,imx6q-ahci" for i.MX6Q SATA controller +- interrupts : interrupt mapping for SATA IRQ +- reg : registers mapping +- clocks : list of clock specifiers, must contain an entry for each + required entry in clock-names +- clock-names : should include "sata", "sata_ref" and "ahb" entries + +Optional properties: +- fsl,transmit-level-mV : transmit voltage level, in millivolts. +- fsl,transmit-boost-mdB : transmit boost level, in milli-decibels +- fsl,transmit-atten-16ths : transmit attenuation, in 16ths +- fsl,receive-eq-mdB : receive equalisation, in milli-decibels + Please refer to the technical documentation or the driver source code + for the list of legal values for these options. +- fsl,no-spread-spectrum : disable spread-spectrum clocking on the SATA + link. + +Examples: + +sata@02200000 { + compatible = "fsl,imx6q-ahci"; + reg = <0x02200000 0x4000>; + interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks IMX6QDL_CLK_SATA>, + <&clks IMX6QDL_CLK_SATA_REF_100M>, + <&clks IMX6QDL_CLK_AHB>; + clock-names = "sata", "sata_ref", "ahb"; +}; diff --git a/Documentation/devicetree/bindings/ata/tegra-sata.txt b/Documentation/devicetree/bindings/ata/tegra-sata.txt new file mode 100644 index 000000000000..946f2072570b --- /dev/null +++ b/Documentation/devicetree/bindings/ata/tegra-sata.txt @@ -0,0 +1,30 @@ +Tegra124 SoC SATA AHCI controller + +Required properties : +- compatible : "nvidia,tegra124-ahci". +- reg : Should contain 2 entries: + - AHCI register set (SATA BAR5) + - SATA register set +- interrupts : Defines the interrupt used by SATA +- 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: + - sata + - sata-oob + - cml1 + - pll_e +- resets : Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names : Must include the following entries: + - sata + - sata-oob + - sata-cold +- phys : Must contain an entry for each entry in phy-names. + See ../phy/phy-bindings.txt for details. +- phy-names : Must include the following entries: + - sata-phy : XUSB PADCTL SATA PHY +- hvdd-supply : Defines the SATA HVDD regulator +- vddio-supply : Defines the SATA VDDIO regulator +- avdd-supply : Defines the SATA AVDD regulator +- target-5v-supply : Defines the SATA 5V power regulator +- target-12v-supply : Defines the SATA 12V power regulator diff --git a/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt b/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt new file mode 100644 index 000000000000..4208886d834a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt @@ -0,0 +1,35 @@ +* Palmas 32KHz clocks * + +Palmas device has two clock output pins for 32KHz, KG and KG_AUDIO. + +This binding uses the common clock binding ./clock-bindings.txt. + +Required properties: +- compatible : "ti,palmas-clk32kg" for clk32kg clock + "ti,palmas-clk32kgaudio" for clk32kgaudio clock +- #clock-cells : shall be set to 0. + +Optional property: +- ti,external-sleep-control: The external enable input pins controlled the + enable/disable of clocks. The external enable input pins ENABLE1, + ENABLE2 and NSLEEP. The valid values for the external pins are: + PALMAS_EXT_CONTROL_PIN_ENABLE1 for ENABLE1 pin + PALMAS_EXT_CONTROL_PIN_ENABLE2 for ENABLE2 pin + PALMAS_EXT_CONTROL_PIN_NSLEEP for NSLEEP pin + Option 0 or missing this property means the clock is enabled/disabled + via register access and these pins do not have any control. + The macros of external control pins for DTS is defined at + dt-bindings/mfd/palmas.h + +Example: + #include <dt-bindings/mfd/palmas.h> + ... + palmas: tps65913@58 { + ... + clk32kg: palmas_clk32k@0 { + compatible = "ti,palmas-clk32kg"; + #clock-cells = <0>; + ti,external-sleep-control = <PALMAS_EXT_CONTROL_PIN_NSLEEP>; + }; + ... + }; diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt b/Documentation/devicetree/bindings/clock/clock-bindings.txt index f15787817d6b..06fc6d541c89 100644 --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt @@ -131,3 +131,39 @@ clock signal, and a UART. ("pll" and "pll-switched"). * The UART has its baud clock connected the external oscillator and its register clock connected to the PLL clock (the "pll-switched" signal) + +==Assigned clock parents and rates== + +Some platforms may require initial configuration of default parent clocks +and clock frequencies. Such a configuration can be specified in a device tree +node through assigned-clocks, assigned-clock-parents and assigned-clock-rates +properties. The assigned-clock-parents property should contain a list of parent +clocks in form of phandle and clock specifier pairs, the assigned-clock-parents +property the list of assigned clock frequency values - corresponding to clocks +listed in the assigned-clocks property. + +To skip setting parent or rate of a clock its corresponding entry should be +set to 0, or can be omitted if it is not followed by any non-zero entry. + + uart@a000 { + compatible = "fsl,imx-uart"; + reg = <0xa000 0x1000>; + ... + clocks = <&osc 0>, <&pll 1>; + clock-names = "baud", "register"; + + assigned-clocks = <&clkcon 0>, <&pll 2>; + assigned-clock-parents = <&pll 2>; + assigned-clock-rates = <0>, <460800>; + }; + +In this example the <&pll 2> clock is set as parent of clock <&clkcon 0> and +the <&pll 2> clock is assigned a frequency value of 460800 Hz. + +Configuring a clock's parent and rate through the device node that consumes +the clock can be done only for clocks that have a single user. Specifying +conflicting parent or rate configuration in multiple consumer nodes for +a shared clock is forbidden. + +Configuration of common clocks, which affect multiple consumer devices can +be similarly specified in the clock provider node. diff --git a/Documentation/devicetree/bindings/clock/clps711x-clock.txt b/Documentation/devicetree/bindings/clock/clps711x-clock.txt new file mode 100644 index 000000000000..ce5a7476f05d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/clps711x-clock.txt @@ -0,0 +1,19 @@ +* Clock bindings for the Cirrus Logic CLPS711X CPUs + +Required properties: +- compatible : Shall contain "cirrus,clps711x-clk". +- reg : Address of the internal register set. +- startup-frequency: Factory set CPU startup frequency in HZ. +- #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/clps711x-clock.h +for the full list of CLPS711X clock IDs. + +Example: + clks: clks@80000000 { + #clock-cells = <1>; + compatible = "cirrus,ep7312-clk", "cirrus,clps711x-clk"; + reg = <0x80000000 0xc000>; + startup-frequency = <73728000>; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 9cfcb4f2bc97..aba3d254e037 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -5,6 +5,8 @@ Required properties : - compatible : shall contain only one of the following: "qcom,gcc-apq8064" + "qcom,gcc-apq8084" + "qcom,gcc-ipq8064" "qcom,gcc-msm8660" "qcom,gcc-msm8960" "qcom,gcc-msm8974" diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt index d572e9964c54..29ebf84d25af 100644 --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt @@ -4,6 +4,8 @@ Qualcomm Multimedia Clock & Reset Controller Binding Required properties : - compatible : shall contain only one of the following: + "qcom,mmcc-apq8064" + "qcom,mmcc-apq8084" "qcom,mmcc-msm8660" "qcom,mmcc-msm8960" "qcom,mmcc-msm8974" diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.txt new file mode 100644 index 000000000000..0c2bf5eba43e --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.txt @@ -0,0 +1,61 @@ +* Rockchip RK3188/RK3066 Clock and Reset Unit + +The RK3188/RK3066 clock controller generates and supplies clock to various +controllers within the SoC and also implements a reset controller for SoC +peripherals. + +Required Properties: + +- compatible: should be "rockchip,rk3188-cru", "rockchip,rk3188a-cru" or + "rockchip,rk3066a-cru" +- reg: physical base address of the controller and length of memory mapped + region. +- #clock-cells: should be 1. +- #reset-cells: should be 1. + +Optional Properties: + +- rockchip,grf: phandle to the syscon managing the "general register files" + If missing pll rates are not changable, due to the missing pll lock status. + +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. All available clocks are defined as +preprocessor macros in the dt-bindings/clock/rk3188-cru.h and +dt-bindings/clock/rk3066-cru.h headers and can be used in device tree sources. +Similar macros exist for the reset sources in these files. + +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: + - "xin24m" - crystal input - required, + - "xin32k" - rtc clock - optional, + - "xin27m" - 27mhz crystal input on rk3066 - optional, + - "ext_hsadc" - external HSADC clock - optional, + - "ext_cif0" - external camera clock - optional, + - "ext_rmii" - external RMII clock - optional, + - "ext_jtag" - externalJTAG clock - optional + +Example: Clock controller node: + + cru: cru@20000000 { + compatible = "rockchip,rk3188-cru"; + reg = <0x20000000 0x1000>; + rockchip,grf = <&grf>; + + #clock-cells = <1>; + #reset-cells = <1>; + }; + +Example: UART controller node that consumes the clock generated by the clock + controller: + + uart0: serial@10124000 { + compatible = "snps,dw-apb-uart"; + reg = <0x10124000 0x400>; + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>; + reg-shift = <2>; + reg-io-width = <1>; + clocks = <&cru SCLK_UART0>; + }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt new file mode 100644 index 000000000000..c9fbb76573e1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt @@ -0,0 +1,61 @@ +* Rockchip RK3288 Clock and Reset Unit + +The RK3288 clock controller generates and supplies clock to various +controllers within the SoC and also implements a reset controller for SoC +peripherals. + +Required Properties: + +- compatible: should be "rockchip,rk3288-cru" +- reg: physical base address of the controller and length of memory mapped + region. +- #clock-cells: should be 1. +- #reset-cells: should be 1. + +Optional Properties: + +- rockchip,grf: phandle to the syscon managing the "general register files" + If missing pll rates are not changable, due to the missing pll lock status. + +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. All available clocks are defined as +preprocessor macros in the dt-bindings/clock/rk3288-cru.h headers and can be +used in device tree sources. Similar macros exist for the reset sources in +these files. + +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: + - "xin24m" - crystal input - required, + - "xin32k" - rtc clock - optional, + - "ext_i2s" - external I2S clock - optional, + - "ext_hsadc" - external HSADC clock - optional, + - "ext_edp_24m" - external display port clock - optional, + - "ext_vip" - external VIP clock - optional, + - "ext_isp" - external ISP clock - optional, + - "ext_jtag" - external JTAG clock - optional + +Example: Clock controller node: + + cru: cru@20000000 { + compatible = "rockchip,rk3188-cru"; + reg = <0x20000000 0x1000>; + rockchip,grf = <&grf>; + + #clock-cells = <1>; + #reset-cells = <1>; + }; + +Example: UART controller node that consumes the clock generated by the clock + controller: + + uart0: serial@10124000 { + compatible = "snps,dw-apb-uart"; + reg = <0x10124000 0x400>; + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>; + reg-shift = <2>; + reg-io-width = <1>; + clocks = <&cru SCLK_UART0>; + }; diff --git a/Documentation/devicetree/bindings/clock/rockchip.txt b/Documentation/devicetree/bindings/clock/rockchip.txt index a891c823ed44..22f6769e5d4a 100644 --- a/Documentation/devicetree/bindings/clock/rockchip.txt +++ b/Documentation/devicetree/bindings/clock/rockchip.txt @@ -6,6 +6,9 @@ This binding uses the common clock binding[1]. == Gate clocks == +These bindings are deprecated! +Please use the soc specific CRU bindings instead. + The gate registers form a continuos block which makes the dt node structure a matter of taste, as either all gates can be put into one gate clock spanning all registers or they can be divided into diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt index ae56315fcec5..6247652044a0 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt @@ -24,26 +24,26 @@ Required properties: Example: - clockgenA@fd345000 { + clockgen-a@fd345000 { reg = <0xfd345000 0xb50>; - CLK_M_A1_DIV1: CLK_M_A1_DIV1 { + clk_m_a1_div1: clk-m-a1-div1 { #clock-cells = <1>; compatible = "st,clkgena-divmux-c32-odf1", "st,clkgena-divmux"; - clocks = <&CLK_M_A1_OSC_PREDIV>, - <&CLK_M_A1_PLL0 1>, /* PLL0 PHI1 */ - <&CLK_M_A1_PLL1 1>; /* PLL1 PHI1 */ - - clock-output-names = "CLK_M_RX_ICN_TS", - "CLK_M_RX_ICN_VDP_0", - "", /* Unused */ - "CLK_M_PRV_T1_BUS", - "CLK_M_ICN_REG_12", - "CLK_M_ICN_REG_10", - "", /* Unused */ - "CLK_M_ICN_ST231"; + clocks = <&clk_m_a1_osc_prediv>, + <&clk_m_a1_pll0 1>, /* PLL0 PHI1 */ + <&clk_m_a1_pll1 1>; /* PLL1 PHI1 */ + + clock-output-names = "clk-m-rx-icn-ts", + "clk-m-rx-icn-vdp-0", + "", /* unused */ + "clk-m-prv-t1-bus", + "clk-m-icn-reg-12", + "clk-m-icn-reg-10", + "", /* unused */ + "clk-m-icn-st231"; }; }; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt index 943e0808e212..f1fa91c68768 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt @@ -17,7 +17,7 @@ Required properties: "st,stih416-clkgenf-vcc-sd", "st,clkgen-mux" "st,stih415-clkgen-a9-mux", "st,clkgen-mux" "st,stih416-clkgen-a9-mux", "st,clkgen-mux" - + "st,stih407-clkgen-a9-mux", "st,clkgen-mux" - #clock-cells : from common clock binding; shall be set to 0. @@ -27,10 +27,10 @@ Required properties: Example: - CLK_M_HVA: CLK_M_HVA { + clk_m_hva: clk-m-hva@fd690868 { #clock-cells = <0>; compatible = "st,stih416-clkgenf-vcc-hva", "st,clkgen-mux"; reg = <0xfd690868 4>; - clocks = <&CLOCKGEN_F 1>, <&CLK_M_A1_DIV0 3>; + clocks = <&clockgen_f 1>, <&clk_m_a1_div0 3>; }; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt index 81eb3855ab92..efb51cf0c845 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt @@ -19,11 +19,14 @@ Required properties: "st,stih415-plls-c32-ddr", "st,clkgen-plls-c32" "st,stih416-plls-c32-a9", "st,clkgen-plls-c32" "st,stih416-plls-c32-ddr", "st,clkgen-plls-c32" + "st,stih407-plls-c32-a0", "st,clkgen-plls-c32" + "st,stih407-plls-c32-a9", "st,clkgen-plls-c32" + "st,stih407-plls-c32-c0_0", "st,clkgen-plls-c32" + "st,stih407-plls-c32-c0_1", "st,clkgen-plls-c32" "st,stih415-gpu-pll-c32", "st,clkgengpu-pll-c32" "st,stih416-gpu-pll-c32", "st,clkgengpu-pll-c32" - - #clock-cells : From common clock binding; shall be set to 1. - clocks : From common clock binding @@ -32,17 +35,17 @@ Required properties: Example: - clockgenA@fee62000 { + clockgen-a@fee62000 { reg = <0xfee62000 0xb48>; - CLK_S_A0_PLL: CLK_S_A0_PLL { + clk_s_a0_pll: clk-s-a0-pll { #clock-cells = <1>; compatible = "st,clkgena-plls-c65"; - clocks = <&CLK_SYSIN>; + clocks = <&clk_sysin>; - clock-output-names = "CLK_S_A0_PLL0_HS", - "CLK_S_A0_PLL0_LS", - "CLK_S_A0_PLL1"; + clock-output-names = "clk-s-a0-pll0-hs", + "clk-s-a0-pll0-ls", + "clk-s-a0-pll1"; }; }; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt index 566c9d79ed32..604766c2619e 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt @@ -20,17 +20,17 @@ Required properties: Example: - clockgenA@fd345000 { + clockgen-a@fd345000 { reg = <0xfd345000 0xb50>; - CLK_M_A2_OSC_PREDIV: CLK_M_A2_OSC_PREDIV { + clk_m_a2_osc_prediv: clk-m-a2-osc-prediv { #clock-cells = <0>; compatible = "st,clkgena-prediv-c32", "st,clkgena-prediv"; - clocks = <&CLK_SYSIN>; + clocks = <&clk_sysin>; - clock-output-names = "CLK_M_A2_OSC_PREDIV"; + clock-output-names = "clk-m-a2-osc-prediv"; }; }; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt index 4e3ff28b04c3..109b3eddcb17 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt @@ -32,22 +32,30 @@ Required properties: Example: - CLOCKGEN_C_VCC: CLOCKGEN_C_VCC { + clockgen_c_vcc: clockgen-c-vcc@0xfe8308ac { #clock-cells = <1>; compatible = "st,stih416-clkgenc", "st,clkgen-vcc"; reg = <0xfe8308ac 12>; - clocks = <&CLK_S_VCC_HD>, <&CLOCKGEN_C 1>, - <&CLK_S_TMDS_FROMPHY>, <&CLOCKGEN_C 2>; - - clock-output-names = - "CLK_S_PIX_HDMI", "CLK_S_PIX_DVO", - "CLK_S_OUT_DVO", "CLK_S_PIX_HD", - "CLK_S_HDDAC", "CLK_S_DENC", - "CLK_S_SDDAC", "CLK_S_PIX_MAIN", - "CLK_S_PIX_AUX", "CLK_S_STFE_FRC_0", - "CLK_S_REF_MCRU", "CLK_S_SLAVE_MCRU", - "CLK_S_TMDS_HDMI", "CLK_S_HDMI_REJECT_PLL", - "CLK_S_THSENS"; + clocks = <&clk_s_vcc_hd>, + <&clockgen_c 1>, + <&clk_s_tmds_fromphy>, + <&clockgen_c 2>; + + clock-output-names = "clk-s-pix-hdmi", + "clk-s-pix-dvo", + "clk-s-out-dvo", + "clk-s-pix-hd", + "clk-s-hddac", + "clk-s-denc", + "clk-s-sddac", + "clk-s-pix-main", + "clk-s-pix-aux", + "clk-s-stfe-frc-0", + "clk-s-ref-mcru", + "clk-s-slave-mcru", + "clk-s-tmds-hdmi", + "clk-s-hdmi-reject-pll", + "clk-s-thsens"; }; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt index 49ec5ae18b5b..78978f1f5158 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt @@ -24,60 +24,77 @@ address is common of all subnode. quadfs_node { ... }; + + mux_node { + ... + }; + + vcc_node { + ... + }; + + flexgen_node { + ... + }; ... }; This binding uses the common clock binding[1]. -Each subnode should use the binding discribe in [2]..[4] +Each subnode should use the binding discribe in [2]..[7] [1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/clock/st,quadfs.txt -[3] Documentation/devicetree/bindings/clock/st,quadfs.txt -[4] Documentation/devicetree/bindings/clock/st,quadfs.txt +[2] Documentation/devicetree/bindings/clock/st,clkgen-divmux.txt +[3] Documentation/devicetree/bindings/clock/st,clkgen-mux.txt +[4] Documentation/devicetree/bindings/clock/st,clkgen-pll.txt +[5] Documentation/devicetree/bindings/clock/st,clkgen-prediv.txt +[6] Documentation/devicetree/bindings/clock/st,vcc.txt +[7] Documentation/devicetree/bindings/clock/st,quadfs.txt +[8] Documentation/devicetree/bindings/clock/st,flexgen.txt + Required properties: - reg : A Base address and length of the register set. Example: - clockgenA@fee62000 { + clockgen-a@fee62000 { reg = <0xfee62000 0xb48>; - CLK_S_A0_PLL: CLK_S_A0_PLL { + clk_s_a0_pll: clk-s-a0-pll { #clock-cells = <1>; compatible = "st,clkgena-plls-c65"; - clocks = <&CLK_SYSIN>; + clocks = <&clk-sysin>; - clock-output-names = "CLK_S_A0_PLL0_HS", - "CLK_S_A0_PLL0_LS", - "CLK_S_A0_PLL1"; + clock-output-names = "clk-s-a0-pll0-hs", + "clk-s-a0-pll0-ls", + "clk-s-a0-pll1"; }; - CLK_S_A0_OSC_PREDIV: CLK_S_A0_OSC_PREDIV { + clk_s_a0_osc_prediv: clk-s-a0-osc-prediv { #clock-cells = <0>; compatible = "st,clkgena-prediv-c65", "st,clkgena-prediv"; - clocks = <&CLK_SYSIN>; + clocks = <&clk_sysin>; - clock-output-names = "CLK_S_A0_OSC_PREDIV"; + clock-output-names = "clk-s-a0-osc-prediv"; }; - CLK_S_A0_HS: CLK_S_A0_HS { + clk_s_a0_hs: clk-s-a0-hs { #clock-cells = <1>; compatible = "st,clkgena-divmux-c65-hs", "st,clkgena-divmux"; - clocks = <&CLK_S_A0_OSC_PREDIV>, - <&CLK_S_A0_PLL 0>, /* PLL0 HS */ - <&CLK_S_A0_PLL 2>; /* PLL1 */ + clocks = <&clk-s_a0_osc_prediv>, + <&clk-s_a0_pll 0>, /* pll0 hs */ + <&clk-s_a0_pll 2>; /* pll1 */ - clock-output-names = "CLK_S_FDMA_0", - "CLK_S_FDMA_1", - ""; /* CLK_S_JIT_SENSE */ - /* Fourth output unused */ + clock-output-names = "clk-s-fdma-0", + "clk-s-fdma-1", + ""; /* clk-s-jit-sense */ + /* fourth output unused */ }; }; diff --git a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt new file mode 100644 index 000000000000..1d3ace088172 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt @@ -0,0 +1,119 @@ +Binding for a type of flexgen structure found on certain +STMicroelectronics consumer electronics SoC devices + +This structure includes: +- a clock cross bar (represented by a mux element) +- a pre and final dividers (represented by a divider and gate elements) + +Flexgen structure is a part of Clockgen[1]. + +Please find an example below: + + Clockgen block diagram + ------------------------------------------------------------------- + | Flexgen stucture | + | --------------------------------------------- | + | | ------- -------- -------- | | +clk_sysin | | | | | | | | | +---|-----------------|-->| | | | | | | | + | | | | | | | | | | | + | | ------- | | | |Pre | |Final | | | + | | |PLL0 | | | | |Dividers| |Dividers| | | + | |->| | | | | | x32 | | x32 | | | + | | | odf_0|----|-->| | | | | | | | + | | | | | | | | | | | | | + | | | | | | | | | | | | | + | | | | | | | | | | | | | + | | | | | | | | | | | | | + | | ------- | | | | | | | | | + | | | | | | | | | | | + | | ------- | | Clock | | | | | | | + | | |PLL1 | | | | | | | | | | + | |->| | | | Cross | | | | | | | + | | | odf_0|----|-->| | | | | | CLK_DIV[31:0] + | | | | | | Bar |====>| |====>| |===|=========> + | | | | | | | | | | | | | + | | | | | | | | | | | | | + | | | | | | | | | | | | | + | | ------- | | | | | | | | | + | | | | | | | | | | | + | | ------- | | | | | | | | | + | | |QUADFS | | | | | | | | | | + | |->| ch0|----|-->| | | | | | | | + | | | | | | | | | | | | + | | ch1|----|-->| | | | | | | | + | | | | | | | | | | | | + | | ch2|----|-->| | | DIV | | DIV | | | + | | | | | | | 1 to | | 1 to | | | + | | ch3|----|-->| | | 1024 | | 64 | | | + | ------- | | | | | | | | | + | | ------- -------- -------- | | + | -------------------------------------------- | + | | + ------------------------------------------------------------------- + +This binding uses the common clock binding[2]. + +[1] Documentation/devicetree/bindings/clock/st/st,clkgen.txt +[2] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be: + "st,flexgen" + +- #clock-cells : from common clock binding; shall be set to 1 (multiple clock + outputs). + +- clocks : must be set to the parent's phandle. it's could be output clocks of + a quadsfs or/and a pll or/and clk_sysin (up to 7 clocks) + +- clock-output-names : List of strings used to name the clock outputs. + +Example: + + clk_s_c0_flexgen: clk-s-c0-flexgen { + + #clock-cells = <1>; + compatible = "st,flexgen"; + + clocks = <&clk_s_c0_pll0 0>, + <&clk_s_c0_pll1 0>, + <&clk_s_c0_quadfs 0>, + <&clk_s_c0_quadfs 1>, + <&clk_s_c0_quadfs 2>, + <&clk_s_c0_quadfs 3>, + <&clk_sysin>; + + clock-output-names = "clk-icn-gpu", + "clk-fdma", + "clk-nand", + "clk-hva", + "clk-proc-stfe", + "clk-proc-tp", + "clk-rx-icn-dmu", + "clk-rx-icn-hva", + "clk-icn-cpu", + "clk-tx-icn-dmu", + "clk-mmc-0", + "clk-mmc-1", + "clk-jpegdec", + "clk-ext2fa9", + "clk-ic-bdisp-0", + "clk-ic-bdisp-1", + "clk-pp-dmu", + "clk-vid-dmu", + "clk-dss-lpc", + "clk-st231-aud-0", + "clk-st231-gp-1", + "clk-st231-dmu", + "clk-icn-lmi", + "clk-tx-icn-disp-1", + "clk-icn-sbc", + "clk-stfe-frc2", + "clk-eth-phy", + "clk-eth-ref-phyclk", + "clk-flash-promip", + "clk-main-disp", + "clk-aux-disp", + "clk-compo-dvp"; + }; diff --git a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt index ec86d62ca283..cedeb9cc8208 100644 --- a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt +++ b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt @@ -15,6 +15,9 @@ Required properties: "st,stih416-quadfs432", "st,quadfs" "st,stih416-quadfs660-E", "st,quadfs" "st,stih416-quadfs660-F", "st,quadfs" + "st,stih407-quadfs660-C", "st,quadfs" + "st,stih407-quadfs660-D", "st,quadfs" + - #clock-cells : from common clock binding; shall be set to 1. @@ -32,14 +35,14 @@ Required properties: Example: - CLOCKGEN_E: CLOCKGEN_E { + clockgen_e: clockgen-e@fd3208bc { #clock-cells = <1>; compatible = "st,stih416-quadfs660-E", "st,quadfs"; reg = <0xfd3208bc 0xB0>; - clocks = <&CLK_SYSIN>; - clock-output-names = "CLK_M_PIX_MDTP_0", - "CLK_M_PIX_MDTP_1", - "CLK_M_PIX_MDTP_2", - "CLK_M_MPELPC"; + clocks = <&clk_sysin>; + clock-output-names = "clk-m-pix-mdtp-0", + "clk-m-pix-mdtp-1", + "clk-m-pix-mdtp-2", + "clk-m-mpelpc"; }; diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index b9ec668bfe62..d3a5c3c6d677 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -9,11 +9,13 @@ Required properties: "allwinner,sun4i-a10-osc-clk" - for a gatable oscillator "allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4 "allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31 + "allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23 "allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock "allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock "allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31 "allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock "allwinner,sun4i-a10-axi-clk" - for the AXI clock + "allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23 "allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates "allwinner,sun4i-a10-ahb-clk" - for the AHB clock "allwinner,sun4i-a10-ahb-gates-clk" - for the AHB gates on A10 @@ -23,13 +25,16 @@ Required properties: "allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31 "allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31 "allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31 + "allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23 "allwinner,sun4i-a10-apb0-clk" - for the APB0 clock "allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31 + "allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23 "allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10 "allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13 "allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s "allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31 "allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20 + "allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23 "allwinner,sun4i-a10-apb1-clk" - for the APB1 clock "allwinner,sun4i-a10-apb1-mux-clk" - for the APB1 clock muxing "allwinner,sun4i-a10-apb1-gates-clk" - for the APB1 gates on A10 @@ -37,8 +42,10 @@ Required properties: "allwinner,sun5i-a10s-apb1-gates-clk" - for the APB1 gates on A10s "allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31 "allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20 + "allwinner,sun8i-a23-apb1-gates-clk" - for the APB1 gates on A23 "allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31 "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31 + "allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23 "allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks "allwinner,sun7i-a20-out-clk" - for the external output clocks "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31 diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt index f055515d2b62..366690cb86a3 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt @@ -8,10 +8,12 @@ Both required and optional properties listed below must be defined under node /cpus/cpu@0. Required properties: -- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt - for details +- None Optional properties: +- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt for + details. OPPs *must* be supplied either via DT, i.e. this property, or + populated at runtime. - clock-latency: Specify the possible maximum transition latency for clock, in unit of nanoseconds. - voltage-tolerance: Specify the CPU voltage tolerance in percentage. diff --git a/Documentation/devicetree/bindings/crypto/amd-ccp.txt b/Documentation/devicetree/bindings/crypto/amd-ccp.txt new file mode 100644 index 000000000000..8c61183b41e0 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/amd-ccp.txt @@ -0,0 +1,19 @@ +* AMD Cryptographic Coprocessor driver (ccp) + +Required properties: +- compatible: Should be "amd,ccp-seattle-v1a" +- reg: Address and length of the register set for the device +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the CCP interrupt + +Optional properties: +- dma-coherent: Present if dma operations are coherent + +Example: + ccp@e0100000 { + compatible = "amd,ccp-seattle-v1a"; + reg = <0 0xe0100000 0 0x10000>; + interrupt-parent = <&gic>; + interrupts = <0 3 4>; + }; diff --git a/Documentation/devicetree/bindings/crypto/qcom-qce.txt b/Documentation/devicetree/bindings/crypto/qcom-qce.txt new file mode 100644 index 000000000000..fdd53b184ba8 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/qcom-qce.txt @@ -0,0 +1,25 @@ +Qualcomm crypto engine driver + +Required properties: + +- compatible : should be "qcom,crypto-v5.1" +- reg : specifies base physical address and size of the registers map +- clocks : phandle to clock-controller plus clock-specifier pair +- clock-names : "iface" clocks register interface + "bus" clocks data transfer interface + "core" clocks rest of the crypto block +- dmas : DMA specifiers for tx and rx dma channels. For more see + Documentation/devicetree/bindings/dma/dma.txt +- dma-names : DMA request names should be "rx" and "tx" + +Example: + crypto@fd45a000 { + compatible = "qcom,crypto-v5.1"; + reg = <0xfd45a000 0x6000>; + clocks = <&gcc GCC_CE2_AHB_CLK>, + <&gcc GCC_CE2_AXI_CLK>, + <&gcc GCC_CE2_CLK>; + clock-names = "iface", "bus", "core"; + dmas = <&cryptobam 2>, <&cryptobam 3>; + dma-names = "rx", "tx"; + }; diff --git a/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt b/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt new file mode 100644 index 000000000000..4ecda224955f --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt @@ -0,0 +1,23 @@ + +* SM5502 MUIC (Micro-USB Interface Controller) device + +The Silicon Mitus SM5502 is a MUIC (Micro-USB Interface Controller) device +which can detect the state of external accessory when external accessory is +attached or detached and button is pressed or released. It is interfaced to +the host controller using an I2C interface. + +Required properties: +- compatible: Should be "siliconmitus,sm5502-muic" +- reg: Specifies the I2C slave address of the MUIC block. It should be 0x25 +- interrupt-parent: Specifies the phandle of the interrupt controller to which + the interrupts from sm5502 are delivered to. +- interrupts: Interrupt specifiers for detection interrupt sources. + +Example: + + sm5502@25 { + compatible = "siliconmitus,sm5502-muic"; + interrupt-parent = <&gpx1>; + interrupts = <5 0>; + reg = <0x25>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt new file mode 100644 index 000000000000..f93242be60a1 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt @@ -0,0 +1,23 @@ +IBM POWERNV platform sensors +---------------------------- + +Required node properties: +- compatible: must be one of + "ibm,opal-sensor-cooling-fan" + "ibm,opal-sensor-amb-temp" + "ibm,opal-sensor-power-supply" + "ibm,opal-sensor-power" +- sensor-id: an opaque id provided by the firmware to the kernel, identifies a + given sensor and its attribute data + +Example sensors node: + +cooling-fan#8-data { + sensor-id = <0x7052107>; + compatible = "ibm,opal-sensor-cooling-fan"; +}; + +amb-temp#1-thrs { + sensor-id = <0x5096000>; + compatible = "ibm,opal-sensor-amb-temp"; +}; diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt index b117b2e9e1a7..2391e5c41999 100644 --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt @@ -3,6 +3,7 @@ NTC Thermistor hwmon sensors Requires node properties: - "compatible" value : one of + "epcos,b57330v2103" "murata,ncp15wb473" "murata,ncp18wb473" "murata,ncp21wb473" diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt new file mode 100644 index 000000000000..610757ce4492 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt @@ -0,0 +1,12 @@ +Bindings for a fan connected to the PWM lines + +Required properties: +- compatible : "pwm-fan" +- pwms : the PWM that is used to control the PWM fan + +Example: + pwm-fan { + compatible = "pwm-fan"; + status = "okay"; + pwms = <&pwm 0 10000 0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index bef86e57c388..37803eb5521e 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -50,6 +50,7 @@ epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer fsl,mc13892 MC13892: Power Management Integrated Circuit (PMIC) for i.MX35/51 fsl,mma8450 MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer +fsl,mma8452 MMA8452Q: 3-axis 12-bit / 8-bit Digital Accelerometer fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface @@ -83,5 +84,6 @@ stm,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface ti,tsc2003 I2C Touch-Screen Controller ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface +ti,tmp103 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface ti,tmp275 Digital Temperature Sensor winbond,wpct301 i2c trusted platform module (TPM) diff --git a/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt b/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt new file mode 100644 index 000000000000..a8770cc6bcad --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/max1027-adc.txt @@ -0,0 +1,22 @@ +* Maxim 1027/1029/1031 Analog to Digital Converter (ADC) + +Required properties: + - compatible: Should be "maxim,max1027" or "maxim,max1029" or "maxim,max1031" + - reg: SPI chip select number for the device + - interrupt-parent: phandle to the parent interrupt controller + see: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt + - interrupts: IRQ line for the ADC + see: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt + +Recommended properties: +- spi-max-frequency: Definition as per + Documentation/devicetree/bindings/spi/spi-bus.txt + +Example: +adc@0 { + compatible = "maxim,max1027"; + reg = <0>; + interrupt-parent = <&gpio5>; + interrupts = <15 IRQ_TYPE_EDGE_RISING>; + spi-max-frequency = <1000000>; +}; diff --git a/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt b/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt index 90d5f34db04e..8e191eef014e 100644 --- a/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt +++ b/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt @@ -3,6 +3,10 @@ Required properties: - compatible : should be "honeywell,hmc5843" + Other models which are supported with driver are: + "honeywell,hmc5883" + "honeywell,hmc5883l" + "honeywell,hmc5983" - reg : the I2C address of the magnetometer - typically 0x1e Optional properties: diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt b/Documentation/devicetree/bindings/iio/st-sensors.txt new file mode 100644 index 000000000000..a7a0a15913ad --- /dev/null +++ b/Documentation/devicetree/bindings/iio/st-sensors.txt @@ -0,0 +1,54 @@ +STMicroelectronics MEMS sensors + +The STMicroelectronics sensor devices are pretty straight-forward I2C or +SPI devices, all sharing the same device tree descriptions no matter what +type of sensor it is. + +Required properties: +- compatible: see the list of valid compatible strings below +- reg: the I2C or SPI address the device will respond to + +Optional properties: +- vdd-supply: an optional regulator that needs to be on to provide VDD + power to the sensor. +- vddio-supply: an optional regulator that needs to be on to provide the + VDD IO power to the sensor. +- st,drdy-int-pin: the pin on the package that will be used to signal + "data ready" (valid values: 1 or 2). This property is not configurable + on all sensors. + +Sensors may also have applicable pin control settings, those use the +standard bindings from pinctrl/pinctrl-bindings.txt. + +Valid compatible strings: + +Accelerometers: +- st,lsm303dlh-accel +- st,lsm303dlhc-accel +- st,lis3dh-accel +- st,lsm330d-accel +- st,lsm330dl-accel +- st,lsm330dlc-accel +- st,lis331dlh-accel +- st,lsm303dl-accel +- st,lsm303dlm-accel +- st,lsm330-accel + +Gyroscopes: +- st,l3g4200d-gyro +- st,lsm330d-gyro +- st,lsm330dl-gyro +- st,lsm330dlc-gyro +- st,l3gd20-gyro +- st,l3g4is-gyro +- st,lsm330-gyro + +Magnetometers: +- st,lsm303dlhc-magn +- st,lsm303dlm-magn +- st,lis3mdl-magn + +Pressure sensors: +- st,lps001wp-press +- st,lps25h-press +- st,lps331ap-press diff --git a/Documentation/devicetree/bindings/arm/atmel-aic.txt b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt index 2742e9cfd6b1..2742e9cfd6b1 100644 --- a/Documentation/devicetree/bindings/arm/atmel-aic.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt diff --git a/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.txt b/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.txt new file mode 100644 index 000000000000..55c04faa3f3f --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/opencores,or1k-pic.txt @@ -0,0 +1,23 @@ +OpenRISC 1000 Programmable Interrupt Controller + +Required properties: + +- compatible : should be "opencores,or1k-pic-level" for variants with + level triggered interrupt lines, "opencores,or1k-pic-edge" for variants with + edge triggered interrupt lines or "opencores,or1200-pic" for machines + with the non-spec compliant or1200 type implementation. + + "opencores,or1k-pic" is also provided as an alias to "opencores,or1200-pic", + but this is only for backwards compatibility. + +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The value shall be 1. + +Example: + +intc: interrupt-controller { + compatible = "opencores,or1k-pic-level"; + interrupt-controller; + #interrupt-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt index f284b99402bc..2d0f7cd867ea 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt @@ -42,12 +42,6 @@ conditions. ** System MMU optional properties: -- smmu-parent : When multiple SMMUs are chained together, this - property can be used to provide a phandle to the - parent SMMU (that is the next SMMU on the path going - from the mmu-masters towards memory) node for this - SMMU. - - calxeda,smmu-secure-config-access : Enable proper handling of buggy implementations that always use secure access to SMMU configuration registers. In this case non-secure diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt b/Documentation/devicetree/bindings/iommu/iommu.txt new file mode 100644 index 000000000000..5a8b4624defc --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/iommu.txt @@ -0,0 +1,182 @@ +This document describes the generic device tree binding for IOMMUs and their +master(s). + + +IOMMU device node: +================== + +An IOMMU can provide the following services: + +* Remap address space to allow devices to access physical memory ranges that + they otherwise wouldn't be capable of accessing. + + Example: 32-bit DMA to 64-bit physical addresses + +* Implement scatter-gather at page level granularity so that the device does + not have to. + +* Provide system protection against "rogue" DMA by forcing all accesses to go + through the IOMMU and faulting when encountering accesses to unmapped + address regions. + +* Provide address space isolation between multiple contexts. + + Example: Virtualization + +Device nodes compatible with this binding represent hardware with some of the +above capabilities. + +IOMMUs can be single-master or multiple-master. Single-master IOMMU devices +typically have a fixed association to the master device, whereas multiple- +master IOMMU devices can translate accesses from more than one master. + +The device tree node of the IOMMU device's parent bus must contain a valid +"dma-ranges" property that describes how the physical address space of the +IOMMU maps to memory. An empty "dma-ranges" property means that there is a +1:1 mapping from IOMMU to memory. + +Required properties: +-------------------- +- #iommu-cells: The number of cells in an IOMMU specifier needed to encode an + address. + +The meaning of the IOMMU specifier is defined by the device tree binding of +the specific IOMMU. Below are a few examples of typical use-cases: + +- #iommu-cells = <0>: Single master IOMMU devices are not configurable and + therefore no additional information needs to be encoded in the specifier. + This may also apply to multiple master IOMMU devices that do not allow the + association of masters to be configured. Note that an IOMMU can by design + be multi-master yet only expose a single master in a given configuration. + In such cases the number of cells will usually be 1 as in the next case. +- #iommu-cells = <1>: Multiple master IOMMU devices may need to be configured + in order to enable translation for a given master. In such cases the single + address cell corresponds to the master device's ID. In some cases more than + one cell can be required to represent a single master ID. +- #iommu-cells = <4>: Some IOMMU devices allow the DMA window for masters to + be configured. The first cell of the address in this may contain the master + device's ID for example, while the second cell could contain the start of + the DMA window for the given device. The length of the DMA window is given + by the third and fourth cells. + +Note that these are merely examples and real-world use-cases may use different +definitions to represent their individual needs. Always refer to the specific +IOMMU binding for the exact meaning of the cells that make up the specifier. + + +IOMMU master node: +================== + +Devices that access memory through an IOMMU are called masters. A device can +have multiple master interfaces (to one or more IOMMU devices). + +Required properties: +-------------------- +- iommus: A list of phandle and IOMMU specifier pairs that describe the IOMMU + master interfaces of the device. One entry in the list describes one master + interface of the device. + +When an "iommus" property is specified in a device tree node, the IOMMU will +be used for address translation. If a "dma-ranges" property exists in the +device's parent node it will be ignored. An exception to this rule is if the +referenced IOMMU is disabled, in which case the "dma-ranges" property of the +parent shall take effect. Note that merely disabling a device tree node does +not guarantee that the IOMMU is really disabled since the hardware may not +have a means to turn off translation. But it is invalid in such cases to +disable the IOMMU's device tree node in the first place because it would +prevent any driver from properly setting up the translations. + + +Notes: +====== + +One possible extension to the above is to use an "iommus" property along with +a "dma-ranges" property in a bus device node (such as PCI host bridges). This +can be useful to describe how children on the bus relate to the IOMMU if they +are not explicitly listed in the device tree (e.g. PCI devices). However, the +requirements of that use-case haven't been fully determined yet. Implementing +this is therefore not recommended without further discussion and extension of +this binding. + + +Examples: +========= + +Single-master IOMMU: +-------------------- + + iommu { + #iommu-cells = <0>; + }; + + master { + iommus = <&{/iommu}>; + }; + +Multiple-master IOMMU with fixed associations: +---------------------------------------------- + + /* multiple-master IOMMU */ + iommu { + /* + * Masters are statically associated with this IOMMU and share + * the same address translations because the IOMMU does not + * have sufficient information to distinguish between masters. + * + * Consequently address translation is always on or off for + * all masters at any given point in time. + */ + #iommu-cells = <0>; + }; + + /* static association with IOMMU */ + master@1 { + reg = <1>; + iommus = <&{/iommu}>; + }; + + /* static association with IOMMU */ + master@2 { + reg = <2>; + iommus = <&{/iommu}>; + }; + +Multiple-master IOMMU: +---------------------- + + iommu { + /* the specifier represents the ID of the master */ + #iommu-cells = <1>; + }; + + master@1 { + /* device has master ID 42 in the IOMMU */ + iommus = <&{/iommu} 42>; + }; + + master@2 { + /* device has master IDs 23 and 24 in the IOMMU */ + iommus = <&{/iommu} 23>, <&{/iommu} 24>; + }; + +Multiple-master IOMMU with configurable DMA window: +--------------------------------------------------- + + / { + iommu { + /* + * One cell for the master ID and one cell for the + * address of the DMA window. The length of the DMA + * window is encoded in two cells. + * + * The DMA window is the range addressable by the + * master (i.e. the I/O virtual address space). + */ + #iommu-cells = <4>; + }; + + master { + /* master ID 42, 4 GiB DMA window starting at 0 */ + iommus = <&{/iommu} 42 0 0x1 0x0>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt b/Documentation/devicetree/bindings/media/atmel-isi.txt new file mode 100644 index 000000000000..17e71b7b44c6 --- /dev/null +++ b/Documentation/devicetree/bindings/media/atmel-isi.txt @@ -0,0 +1,51 @@ +Atmel Image Sensor Interface (ISI) SoC Camera Subsystem +---------------------------------------------- + +Required properties: +- compatible: must be "atmel,at91sam9g45-isi" +- reg: physical base address and length of the registers set for the device; +- interrupts: should contain IRQ line for the ISI; +- clocks: list of clock specifiers, corresponding to entries in + the clock-names property; +- clock-names: must contain "isi_clk", which is the isi peripherial clock. + +ISI supports a single port node with parallel bus. It should contain one +'port' child node with child 'endpoint' node. Please refer to the bindings +defined in Documentation/devicetree/bindings/media/video-interfaces.txt. + +Example: + isi: isi@f0034000 { + compatible = "atmel,at91sam9g45-isi"; + reg = <0xf0034000 0x4000>; + interrupts = <37 IRQ_TYPE_LEVEL_HIGH 5>; + + clocks = <&isi_clk>; + clock-names = "isi_clk"; + + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_isi>; + + port { + #address-cells = <1>; + #size-cells = <0>; + + isi_0: endpoint { + remote-endpoint = <&ov2640_0>; + bus-width = <8>; + }; + }; + }; + + i2c1: i2c@f0018000 { + ov2640: camera@0x30 { + compatible = "omnivision,ov2640"; + reg = <0x30>; + + port { + ov2640_0: endpoint { + remote-endpoint = <&isi_0>; + bus-width = <8>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt index 937b755baf8f..bf52ed4a5067 100644 --- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt +++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt @@ -3,9 +3,13 @@ Samsung S5P/EXYNOS SoC series JPEG codec Required properties: - compatible : should be one of: - "samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg"; + "samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg", + "samsung,exynos3250-jpeg"; - reg : address and length of the JPEG codec IP register set; - interrupts : specifies the JPEG codec IP interrupt; -- clocks : should contain the JPEG codec IP gate clock specifier, from the - common clock bindings; -- clock-names : should contain "jpeg" entry. +- clock-names : should contain: + - "jpeg" for the core gate clock, + - "sclk" for the special clock (optional). +- clocks : should contain the clock specifier and clock ID list + matching entries in the clock-names property; from + the common clock bindings. diff --git a/Documentation/devicetree/bindings/media/i2c/mt9m111.txt b/Documentation/devicetree/bindings/media/i2c/mt9m111.txt new file mode 100644 index 000000000000..ed5a334b1e57 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/mt9m111.txt @@ -0,0 +1,28 @@ +Micron 1.3Mp CMOS Digital Image Sensor + +The Micron MT9M111 is a CMOS active pixel digital image sensor with an active +array size of 1280H x 1024V. It is programmable through a simple two-wire serial +interface. + +Required Properties: +- compatible: value should be "micron,mt9m111" + +For further reading on port node refer to +Documentation/devicetree/bindings/media/video-interfaces.txt. + +Example: + + i2c_master { + mt9m111@5d { + compatible = "micron,mt9m111"; + reg = <0x5d>; + + remote = <&pxa_camera>; + port { + mt9m111_1: endpoint { + bus-width = <8>; + remote-endpoint = <&pxa_camera>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/pxa-camera.txt b/Documentation/devicetree/bindings/media/pxa-camera.txt new file mode 100644 index 000000000000..11f5b5d51af8 --- /dev/null +++ b/Documentation/devicetree/bindings/media/pxa-camera.txt @@ -0,0 +1,43 @@ +Marvell PXA camera host interface + +Required properties: + - compatible: Should be "marvell,pxa270-qci" + - reg: register base and size + - interrupts: the interrupt number + - any required generic properties defined in video-interfaces.txt + +Optional properties: + - clocks: input clock (see clock-bindings.txt) + - clock-output-names: should contain the name of the clock driving the + sensor master clock MCLK + - clock-frequency: host interface is driving MCLK, and MCLK rate is this rate + +Example: + + pxa_camera: pxa_camera@50000000 { + compatible = "marvell,pxa270-qci"; + reg = <0x50000000 0x1000>; + interrupts = <33>; + + clocks = <&pxa2xx_clks 24>; + clock-names = "ciclk"; + clock-frequency = <50000000>; + clock-output-names = "qci_mclk"; + + status = "okay"; + + port { + #address-cells = <1>; + #size-cells = <0>; + + /* Parallel bus endpoint */ + qci: endpoint@0 { + reg = <0>; /* Local endpoint # */ + remote-endpoint = <&mt9m111_1>; + bus-width = <8>; /* Used data lines */ + hsync-active = <0>; /* Active low */ + vsync-active = <0>; /* Active low */ + pclk-sample = <1>; /* Rising */ + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt new file mode 100644 index 000000000000..ba61782c2af9 --- /dev/null +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt @@ -0,0 +1,86 @@ +Renesas RCar Video Input driver (rcar_vin) +------------------------------------------ + +The rcar_vin device provides video input capabilities for the Renesas R-Car +family of devices. The current blocks are always slaves and suppot one input +channel which can be either RGB, YUYV or BT656. + + - compatible: Must be one of the following + - "renesas,vin-r8a7791" for the R8A7791 device + - "renesas,vin-r8a7790" for the R8A7790 device + - "renesas,vin-r8a7779" for the R8A7779 device + - "renesas,vin-r8a7778" for the R8A7778 device + - reg: the register base and size for the device registers + - interrupts: the interrupt for the device + - clocks: Reference to the parent clock + +Additionally, an alias named vinX will need to be created to specify +which video input device this is. + +The per-board settings: + - port sub-node describing a single endpoint connected to the vin + as described in video-interfaces.txt[1]. Only the first one will + be considered as each vin interface has one input port. + + These settings are used to work out video input format and widths + into the system. + + +Device node example +------------------- + + aliases { + vin0 = &vin0; + }; + + vin0: vin@0xe6ef0000 { + compatible = "renesas,vin-r8a7790"; + clocks = <&mstp8_clks R8A7790_CLK_VIN0>; + reg = <0 0xe6ef0000 0 0x1000>; + interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + }; + +Board setup example (vin1 composite video input) +------------------------------------------------ + +&i2c2 { + status = "ok"; + pinctrl-0 = <&i2c2_pins>; + pinctrl-names = "default"; + + adv7180@20 { + compatible = "adi,adv7180"; + reg = <0x20>; + remote = <&vin1>; + + port { + adv7180: endpoint { + bus-width = <8>; + remote-endpoint = <&vin1ep0>; + }; + }; + }; +}; + +/* composite video input */ +&vin1 { + pinctrl-0 = <&vin1_pins>; + pinctrl-names = "default"; + + status = "ok"; + + port { + #address-cells = <1>; + #size-cells = <0>; + + vin1ep0: endpoint { + remote-endpoint = <&adv7180>; + bus-width = <8>; + }; + }; +}; + + + +[1] video-interfaces.txt common video media interface diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt new file mode 100644 index 000000000000..23dd5ad07b7c --- /dev/null +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt @@ -0,0 +1,23 @@ +Device-Tree bindings for SUNXI IR controller found in sunXi SoC family + +Required properties: +- compatible : should be "allwinner,sun4i-a10-ir"; +- clocks : list of clock specifiers, corresponding to + entries in clock-names property; +- clock-names : should contain "apb" and "ir" entries; +- interrupts : should contain IR IRQ number; +- reg : should contain IO map address for IR. + +Optional properties: +- linux,rc-map-name : Remote control map name. + +Example: + +ir0: ir@01c21800 { + compatible = "allwinner,sun4i-a10-ir"; + clocks = <&apb0_gates 6>, <&ir0_clk>; + clock-names = "apb", "ir"; + interrupts = <0 5 1>; + reg = <0x01C21800 0x40>; + linux,rc-map-name = "rc-rc6-mce"; +}; diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index e5f0f8303461..eda898978d33 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -6,6 +6,7 @@ twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) tps659038 +tps65917 Required properties: - compatible : Should be from the list @@ -16,6 +17,7 @@ Required properties: ti,tps65914 ti,tps80036 ti,tps659038 + ti,tps65917 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs diff --git a/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt b/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt new file mode 100644 index 000000000000..88f8c23384c0 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt @@ -0,0 +1,34 @@ +Berlin SATA PHY +--------------- + +Required properties: +- compatible: should be "marvell,berlin2q-sata-phy" +- address-cells: should be 1 +- size-cells: should be 0 +- phy-cells: from the generic PHY bindings, must be 1 +- reg: address and length of the register +- clocks: reference to the clock entry + +Sub-nodes: +Each PHY should be represented as a sub-node. + +Sub-nodes required properties: +- reg: the PHY number + +Example: + sata_phy: phy@f7e900a0 { + compatible = "marvell,berlin2q-sata-phy"; + reg = <0xf7e900a0 0x200>; + clocks = <&chip CLKID_SATA>; + #address-cells = <1>; + #size-cells = <0>; + #phy-cells = <1>; + + sata-phy@0 { + reg = <0>; + }; + + sata-phy@1 { + reg = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/hix5hd2-phy.txt b/Documentation/devicetree/bindings/phy/hix5hd2-phy.txt new file mode 100644 index 000000000000..296168b74d24 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/hix5hd2-phy.txt @@ -0,0 +1,22 @@ +Hisilicon hix5hd2 SATA PHY +----------------------- + +Required properties: +- compatible: should be "hisilicon,hix5hd2-sata-phy" +- reg: offset and length of the PHY registers +- #phy-cells: must be 0 +Refer to phy/phy-bindings.txt for the generic PHY binding properties + +Optional Properties: +- hisilicon,peripheral-syscon: phandle of syscon used to control peripheral. +- hisilicon,power-reg: offset and bit number within peripheral-syscon, + register of controlling sata power supply. + +Example: + sata_phy: phy@f9900000 { + compatible = "hisilicon,hix5hd2-sata-phy"; + reg = <0xf9900000 0x10000>; + #phy-cells = <0>; + hisilicon,peripheral-syscon = <&peripheral_ctrl>; + hisilicon,power-reg = <0x8 10>; + }; diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt index 8ae844fc0c60..2aa1840200ed 100644 --- a/Documentation/devicetree/bindings/phy/phy-bindings.txt +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt @@ -10,6 +10,10 @@ Required Properties: provider can use the values in cells to find the appropriate PHY. +Optional Properties: +phy-supply: Phandle to a regulator that provides power to the PHY. This + regulator will be managed during the PHY power on/off sequence. + For example: phys: phy { diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt new file mode 100644 index 000000000000..42c880886cf7 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt @@ -0,0 +1,76 @@ +STMicroelectronics STi MIPHY365x PHY binding +============================================ + +This binding describes a miphy device that is used to control PHY hardware +for SATA and PCIe. + +Required properties (controller (parent) node): +- compatible : Should be "st,miphy365x-phy" +- st,syscfg : Should be a phandle of the system configuration register group + which contain the SATA, PCIe mode setting bits + +Required nodes : A sub-node is required for each channel the controller + provides. Address range information including the usual + 'reg' and 'reg-names' properties are used inside these + nodes to describe the controller's topology. These nodes + are translated by the driver's .xlate() function. + +Required properties (port (child) node): +- #phy-cells : Should be 1 (See second example) + Cell after port phandle is device type from: + - MIPHY_TYPE_SATA + - MIPHY_TYPE_PCI +- reg : Address and length of register sets for each device in + "reg-names" +- reg-names : The names of the register addresses corresponding to the + registers filled in "reg": + - sata: For SATA devices + - pcie: For PCIe devices + - syscfg: To specify the syscfg based config register + +Optional properties (port (child) node): +- st,sata-gen : Generation of locally attached SATA IP. Expected values + are {1,2,3). If not supplied generation 1 hardware will + be expected +- st,pcie-tx-pol-inv : Bool property to invert the polarity PCIe Tx (Txn/Txp) +- st,sata-tx-pol-inv : Bool property to invert the polarity SATA Tx (Txn/Txp) + +Example: + + miphy365x_phy: miphy365x@fe382000 { + compatible = "st,miphy365x-phy"; + st,syscfg = <&syscfg_rear>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + phy_port0: port@fe382000 { + reg = <0xfe382000 0x100>, <0xfe394000 0x100>, <0x824 0x4>; + reg-names = "sata", "pcie", "syscfg"; + #phy-cells = <1>; + st,sata-gen = <3>; + }; + + phy_port1: port@fe38a000 { + reg = <0xfe38a000 0x100>, <0xfe804000 0x100>, <0x828 0x4>;; + reg-names = "sata", "pcie", "syscfg"; + #phy-cells = <1>; + st,pcie-tx-pol-inv; + }; + }; + +Specifying phy control of devices +================================= + +Device nodes should specify the configuration required in their "phys" +property, containing a phandle to the phy port node and a device type. + +Example: + +#include <dt-bindings/phy/phy-miphy365x.h> + + sata0: sata@fe380000 { + ... + phys = <&phy_port0 MIPHY_TYPE_SATA>; + ... + }; diff --git a/Documentation/devicetree/bindings/phy/qcom-apq8064-sata-phy.txt b/Documentation/devicetree/bindings/phy/qcom-apq8064-sata-phy.txt new file mode 100644 index 000000000000..952f6c96bab9 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom-apq8064-sata-phy.txt @@ -0,0 +1,24 @@ +Qualcomm APQ8064 SATA PHY Controller +------------------------------------ + +SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers. +Each SATA PHY controller should have its own node. + +Required properties: +- compatible: compatible list, contains "qcom,apq8064-sata-phy". +- reg: offset and length of the SATA PHY register set; +- #phy-cells: must be zero +- clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. +- clock-names: must be "cfg" for phy config clock. + +Example: + sata_phy: sata-phy@1b400000 { + compatible = "qcom,apq8064-sata-phy"; + reg = <0x1b400000 0x200>; + + clocks = <&gcc SATA_PHY_CFG_CLK>; + clock-names = "cfg"; + + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom-ipq806x-sata-phy.txt b/Documentation/devicetree/bindings/phy/qcom-ipq806x-sata-phy.txt new file mode 100644 index 000000000000..76bfbd056202 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom-ipq806x-sata-phy.txt @@ -0,0 +1,23 @@ +Qualcomm IPQ806x SATA PHY Controller +------------------------------------ + +SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers. +Each SATA PHY controller should have its own node. + +Required properties: +- compatible: compatible list, contains "qcom,ipq806x-sata-phy" +- reg: offset and length of the SATA PHY register set; +- #phy-cells: must be zero +- clocks: must be exactly one entry +- clock-names: must be "cfg" + +Example: + sata_phy: sata-phy@1b400000 { + compatible = "qcom,ipq806x-sata-phy"; + reg = <0x1b400000 0x200>; + + clocks = <&gcc SATA_PHY_CFG_CLK>; + clock-names = "cfg"; + + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 2049261d8c31..6099a5c94283 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -26,6 +26,7 @@ Samsung S5P/EXYNOS SoC series USB PHY Required properties: - compatible : should be one of the listed compatibles: + - "samsung,exynos3250-usb2-phy" - "samsung,exynos4210-usb2-phy" - "samsung,exynos4x12-usb2-phy" - "samsung,exynos5250-usb2-phy" @@ -46,6 +47,7 @@ and Exynos 4212) it is as follows: 1 - USB host ("host"), 2 - HSIC0 ("hsic0"), 3 - HSIC1 ("hsic1"), +Exynos3250 has only USB device phy available as phy 0. Exynos 4210 and Exynos 4212 use mode switching and require that mode switch register is supplied. diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index 9ce458f32945..305e3df3d9b1 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -9,15 +9,17 @@ Required properties: e.g. USB2_PHY on OMAP5. "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control e.g. USB3 PHY and SATA PHY on OMAP5. + "ti,control-phy-pcie" - for pcie to support external clock for pcie and to + set PCS delay value. + e.g. PCIE PHY in DRA7x "ti,control-phy-usb2-dra7" - if it has power down register like USB2 PHY on DRA7 platform. "ti,control-phy-usb2-am437" - if it has power down register like USB2 PHY on AM437 platform. - - reg : Address and length of the register set for the device. It contains - the address of "otghs_control" for control-phy-otghs or "power" register - for other types. - - reg-names: should be "otghs_control" control-phy-otghs and "power" for - other types. + - reg : register ranges as listed in the reg-names property + - reg-names: "otghs_control" for control-phy-otghs + "power", "pcie_pcs" and "control_sma" for control-phy-pcie + "power" for all other types omap_control_usb: omap-control-usb@4a002300 { compatible = "ti,control-phy-otghs"; @@ -56,8 +58,8 @@ usb2phy@4a0ad080 { TI PIPE3 PHY Required properties: - - compatible: Should be "ti,phy-usb3" or "ti,phy-pipe3-sata". - "ti,omap-usb3" is deprecated. + - compatible: Should be "ti,phy-usb3", "ti,phy-pipe3-sata" or + "ti,phy-pipe3-pcie. "ti,omap-usb3" is deprecated. - reg : Address and length of the register set for the device. - reg-names: The names of the register addresses corresponding to the registers filled in "reg". @@ -69,10 +71,17 @@ Required properties: * "wkupclk" - wakeup clock. * "sysclk" - system clock. * "refclk" - reference clock. + * "dpll_ref" - external dpll ref clk + * "dpll_ref_m2" - external dpll ref clk + * "phy-div" - divider for apll + * "div-clk" - apll clock Optional properties: - ctrl-module : phandle of the control module used by PHY driver to power on the PHY. + - id: If there are multiple instance of the same type, in order to + differentiate between each instance "id" can be used (e.g., multi-lane PCIe + PHY). If "id" is not provided, it is set to default value of '1'. This is usually a subnode of ocp2scp to which it is connected. diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt index bef1fbb647ca..865614b34d6f 100644 --- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt @@ -1,13 +1,16 @@ -ACT8865 regulator +ACT88xx regulators ------------------- Required properties: -- compatible: "active-semi,act8865" +- compatible: "active-semi,act8846" or "active-semi,act8865" - reg: I2C slave address Any standard regulator properties can be used to configure the single regulator. The valid names for regulators are: + - for act8846: + REG1, REG2, REG3, REG4, REG5, REG6, REG7, REG8, REG9, REG10, REG11, REG12 + - for act8865: DCDC_REG1, DCDC_REG2, DCDC_REG3, LDO_REG1, LDO_REG2, LDO_REG3, LDO_REG4. Example: diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index 42e6b6bc48ff..725393c8a7f2 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -7,6 +7,7 @@ Required properties: ti,twl6037-pmic ti,tps65913-pmic ti,tps65914-pmic + ti,tps65917-pmic and also the generic series names ti,palmas-pmic - interrupt-parent : The parent interrupt controller which is palmas. diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt b/Documentation/devicetree/bindings/regulator/tps65218.txt new file mode 100644 index 000000000000..fccc1d24af58 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/tps65218.txt @@ -0,0 +1,23 @@ +TPS65218 family of regulators + +Required properties: +For tps65218 regulators/LDOs +- compatible: + - "ti,tps65218-dcdc1" for DCDC1 + - "ti,tps65218-dcdc2" for DCDC2 + - "ti,tps65218-dcdc3" for DCDC3 + - "ti,tps65218-dcdc4" for DCDC4 + - "ti,tps65218-dcdc5" for DCDC5 + - "ti,tps65218-dcdc6" for DCDC6 + - "ti,tps65218-ldo1" for LDO1 + +Optional properties: +- Any optional property defined in bindings/regulator/regulator.txt + +Example: + + xyz: regulator@0 { + compatible = "ti,tps65218-dcdc1"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <3000000>; + }; diff --git a/Documentation/devicetree/bindings/serial/efm32-uart.txt b/Documentation/devicetree/bindings/serial/efm32-uart.txt index 3ca01336b837..8adbab268ca3 100644 --- a/Documentation/devicetree/bindings/serial/efm32-uart.txt +++ b/Documentation/devicetree/bindings/serial/efm32-uart.txt @@ -6,7 +6,7 @@ Required properties: - interrupts : Should contain uart interrupt Optional properties: -- 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 .. 5] Default: 0 @@ -16,5 +16,5 @@ uart@0x4000c400 { compatible = "energymicro,efm32-uart"; reg = <0x4000c400 0x400>; interrupts = <15>; - efm32,location = <0>; + energymicro,location = <0>; }; diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt index a1d1205d8185..c95005efbcb8 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt @@ -1,7 +1,11 @@ * Freescale low power universal asynchronous receiver/transmitter (lpuart) Required properties: -- compatible : Should be "fsl,<soc>-lpuart" +- compatible : + - "fsl,vf610-lpuart" for lpuart compatible with the one integrated + on Vybrid vf610 SoC with 8-bit register organization + - "fsl,ls1021a-lpuart" for lpuart compatible with the one integrated + on LS1021A SoC with 32-bit big-endian register organization - reg : Address and length of the register set for the device - interrupts : Should contain uart interrupt - clocks : phandle + clock specifier pairs, one for each entry in clock-names diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.txt b/Documentation/devicetree/bindings/serial/samsung_uart.txt index 2c8a17cf5cb5..e85f37ec33f0 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.txt +++ b/Documentation/devicetree/bindings/serial/samsung_uart.txt @@ -1,14 +1,58 @@ * Samsung's UART Controller -The Samsung's UART controller is used for interfacing SoC with serial communicaion -devices. +The Samsung's UART controller is used for interfacing SoC with serial +communicaion devices. Required properties: -- compatible: should be - - "samsung,exynos4210-uart", for UART's compatible with Exynos4210 uart ports. +- compatible: should be one of following: + - "samsung,exynos4210-uart" - Exynos4210 SoC, + - "samsung,s3c2410-uart" - compatible with ports present on S3C2410 SoC, + - "samsung,s3c2412-uart" - compatible with ports present on S3C2412 SoC, + - "samsung,s3c2440-uart" - compatible with ports present on S3C2440 SoC, + - "samsung,s3c6400-uart" - compatible with ports present on S3C6400 SoC, + - "samsung,s5pv210-uart" - compatible with ports present on S5PV210 SoC. - reg: base physical address of the controller and length of memory mapped region. -- interrupts: interrupt number to the cpu. The interrupt specifier format depends - on the interrupt controller parent. +- interrupts: a single interrupt signal to SoC interrupt controller, + according to interrupt bindings documentation [1]. + +- clock-names: input names of clocks used by the controller: + - "uart" - controller bus clock, + - "clk_uart_baudN" - Nth baud base clock input (N = 0, 1, ...), + according to SoC User's Manual (only N = 0 is allowedfor SoCs without + internal baud clock mux). +- clocks: phandles and specifiers for all clocks specified in "clock-names" + property, in the same order, according to clock bindings documentation [2]. + +[1] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +[2] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Optional properties: +- samsung,uart-fifosize: The fifo size supported by the UART channel + +Note: Each Samsung UART should have an alias correctly numbered in the +"aliases" node, according to serialN format, where N is the port number +(non-negative decimal integer) as specified by User's Manual of respective +SoC. + +Example: + aliases { + serial0 = &uart0; + serial1 = &uart1; + serial2 = &uart2; + }; + +Example: + uart1: serial@7f005400 { + compatible = "samsung,s3c6400-uart"; + reg = <0x7f005400 0x100>; + interrupt-parent = <&vic1>; + interrupts = <6>; + clock-names = "uart", "clk_uart_baud2", + "clk_uart_baud3"; + clocks = <&clocks PCLK_UART1>, <&clocks PCLK_UART1>, + <&clocks SCLK_UART>; + samsung,uart-fifosize = <16>; + }; diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt index f13f1c5be91c..7f76214f728a 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt @@ -4,9 +4,18 @@ Required properties: - compatible : "snps,dw-apb-uart" - reg : offset and length of the register set for the device. - interrupts : should contain uart interrupt. + +Clock handling: +The clock rate of the input clock needs to be supplied by one of - clock-frequency : the input clock frequency for the UART. +- clocks : phandle to the input clock + +The supplying peripheral clock can also be handled, needing a second property +- clock-names: tuple listing input clock names. + Required elements: "baudclk", "apb_pclk" Optional properties: +- resets : phandle to the parent reset controller. - reg-shift : quantity to shift the register offsets by. If this property is not present then the register offsets are not shifted. - reg-io-width : the size (in bytes) of the IO accesses that should be @@ -23,3 +32,26 @@ Example: reg-shift = <2>; reg-io-width = <4>; }; + +Example with one clock: + + uart@80230000 { + compatible = "snps,dw-apb-uart"; + reg = <0x80230000 0x100>; + clocks = <&baudclk>; + interrupts = <10>; + reg-shift = <2>; + reg-io-width = <4>; + }; + +Example with two clocks: + + uart@80230000 { + compatible = "snps,dw-apb-uart"; + reg = <0x80230000 0x100>; + clocks = <&baudclk>, <&apb_pclk>; + clock-names = "baudclk", "apb_pclk"; + interrupts = <10>; + reg-shift = <2>; + reg-io-width = <4>; + }; diff --git a/Documentation/devicetree/bindings/spi/efm32-spi.txt b/Documentation/devicetree/bindings/spi/efm32-spi.txt index 130cd17e3680..750e29aff9bc 100644 --- a/Documentation/devicetree/bindings/spi/efm32-spi.txt +++ b/Documentation/devicetree/bindings/spi/efm32-spi.txt @@ -10,11 +10,12 @@ Required properties: - cs-gpios: see spi-bus.txt Recommended properties : -- efm32,location: Value to write to the ROUTE register's LOCATION bitfield to - configure the pinmux for the device, see datasheet for values. - If "efm32,location" property is not provided, keeping what is - already configured in the hardware, so its either the reset - default 0 or whatever the bootloader did. +- energymicro,location: Value to write to the ROUTE register's LOCATION + bitfield to configure the pinmux for the device, see + datasheet for values. + If this property is not provided, keeping what is + already configured in the hardware, so its either the + reset default 0 or whatever the bootloader did. Example: @@ -26,7 +27,7 @@ spi1: spi@0x4000c400 { /* USART1 */ interrupts = <15 16>; clocks = <&cmu 20>; cs-gpios = <&gpio 51 1>; // D3 - efm32,location = <1>; + energymicro,location = <1>; status = "ok"; ks8851@0 { diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt index bee6ff204baf..e2c88df2cc15 100644 --- a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt @@ -7,7 +7,11 @@ SPI in master mode supports up to 50MHz, up to four chip selects, programmable data path from 4 bits to 32 bits and numerous protocol variants. Required properties: -- compatible: Should contain "qcom,spi-qup-v2.1.1" or "qcom,spi-qup-v2.2.1" +- compatible: Should contain: + "qcom,spi-qup-v1.1.1" for 8660, 8960 and 8064. + "qcom,spi-qup-v2.1.1" for 8974 and later + "qcom,spi-qup-v2.2.1" for 8974 v2 and later. + - reg: Should contain base register location and length - interrupts: Interrupt number used by this controller diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt new file mode 100644 index 000000000000..bd99193e87b9 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt @@ -0,0 +1,28 @@ +Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface. + +Required properties: +- compatible : "snps,dw-apb-ssi" +- reg : The register base for the controller. +- interrupts : One interrupt, used by the controller. +- #address-cells : <1>, as required by generic SPI binding. +- #size-cells : <0>, also as required by generic SPI binding. + +Optional properties: +- cs-gpios : Specifies the gpio pis to be used for chipselects. +- num-cs : The number of chipselects. If omitted, this will default to 4. + +Child nodes as per the generic SPI binding. + +Example: + + spi@fff00000 { + compatible = "snps,dw-apb-ssi"; + reg = <0xfff00000 0x1000>; + interrupts = <0 154 4>; + #address-cells = <1>; + #size-cells = <0>; + num-cs = <2>; + cs-gpios = <&gpio0 13 0>, + <&gpio0 14 0>; + }; + diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt b/Documentation/devicetree/bindings/spi/spi-davinci.txt index 6d0ac8d0ad9b..f80887bca0d6 100644 --- a/Documentation/devicetree/bindings/spi/spi-davinci.txt +++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt @@ -8,7 +8,8 @@ Required properties: - "ti,dm6441-spi" for SPI used similar to that on DM644x SoC family - "ti,da830-spi" for SPI used similar to that on DA8xx SoC family - reg: Offset and length of SPI controller register space -- num-cs: Number of chip selects +- num-cs: Number of chip selects. This includes internal as well as + GPIO chip selects. - ti,davinci-spi-intr-line: interrupt line used to connect the SPI IP to the interrupt controller within the SoC. Possible values are 0 and 1. Manual says one of the two possible interrupt @@ -17,6 +18,12 @@ Required properties: - interrupts: interrupt number mapped to CPU. - clocks: spi clk phandle +Optional: +- cs-gpios: gpio chip selects + For example to have 3 internal CS and 2 GPIO CS, user could define + cs-gpios = <0>, <0>, <0>, <&gpio1 30 0>, <&gpio1 31 0>; + where first three are internal CS and last two are GPIO CS. + Example of a NOR flash slave device (n25q032) connected to DaVinci SPI controller device over the SPI bus. diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt b/Documentation/devicetree/bindings/spi/spi-rockchip.txt new file mode 100644 index 000000000000..7bab35575817 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt @@ -0,0 +1,37 @@ +* Rockchip SPI Controller + +The Rockchip SPI controller is used to interface with various devices such as flash +and display controllers using the SPI communication interface. + +Required Properties: + +- compatible: should be one of the following. + "rockchip,rk3066-spi" for rk3066. + "rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188. + "rockchip,rk3288-spi", "rockchip,rk3066-spi" for rk3288. +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: The interrupt number to the cpu. The interrupt specifier format + depends on the interrupt controller. +- clocks: Must contain an entry for each entry in clock-names. +- clock-names: Shall be "spiclk" for the transfer-clock, and "apb_pclk" for + the peripheral clock. +- dmas: DMA specifiers for tx and rx dma. See the DMA client binding, + Documentation/devicetree/bindings/dma/dma.txt +- dma-names: DMA request names should include "tx" and "rx" if present. +- #address-cells: should be 1. +- #size-cells: should be 0. + +Example: + + spi0: spi@ff110000 { + compatible = "rockchip,rk3066-spi"; + reg = <0xff110000 0x1000>; + dmas = <&pdma1 11>, <&pdma1 12>; + dma-names = "tx", "rx"; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_SPI0>, <&cru PCLK_SPI0>; + clock-names = "spiclk", "apb_pclk"; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt b/Documentation/devicetree/bindings/spi/spi-samsung.txt index 86aa061f069f..792efbaedc54 100644 --- a/Documentation/devicetree/bindings/spi/spi-samsung.txt +++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt @@ -18,14 +18,11 @@ Required SoC Specific Properties: - interrupts: The interrupt number to the cpu. The interrupt specifier format depends on the interrupt controller. -[PRELIMINARY: the dma channel allocation will change once there are -official DMA bindings] +- dmas : Two or more DMA channel specifiers following the convention outlined + in bindings/dma/dma.txt -- tx-dma-channel: The dma channel specifier for tx operations. The format of - the dma specifier depends on the dma controller. - -- rx-dma-channel: The dma channel specifier for rx operations. The format of - the dma specifier depends on the dma controller. +- dma-names: Names for the dma channels. There must be at least one channel + named "tx" for transmit and named "rx" for receive. Required Board Specific Properties: @@ -42,15 +39,13 @@ Optional Board Specific Properties: - num-cs: Specifies the number of chip select lines supported. If not specified, the default number of chip select lines is set to 1. +- cs-gpios: should specify GPIOs used for chipselects (see spi-bus.txt) + SPI Controller specific data in SPI slave nodes: - The spi slave nodes should provide the following information which is required by the spi controller. - - cs-gpio: A gpio specifier that specifies the gpio line used as - the slave select line by the spi controller. The format of the gpio - specifier depends on the gpio controller. - - samsung,spi-feedback-delay: The sampling phase shift to be applied on the miso line (to account for any lag in the miso line). The following are the valid values. @@ -74,8 +69,11 @@ Example: compatible = "samsung,exynos4210-spi"; reg = <0x12d20000 0x100>; interrupts = <0 66 0>; - tx-dma-channel = <&pdma0 5>; - rx-dma-channel = <&pdma0 4>; + dmas = <&pdma0 5 + &pdma0 4>; + dma-names = "tx", "rx"; + #address-cells = <1>; + #size-cells = <0>; }; - Board Specific Portion: @@ -85,6 +83,7 @@ Example: #size-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&spi0_bus>; + cs-gpios = <&gpa2 5 0>; w25q80bw@0 { #address-cells = <1>; @@ -94,7 +93,6 @@ Example: spi-max-frequency = <10000>; controller-data { - cs-gpio = <&gpa2 5 1 0 3>; samsung,spi-feedback-delay = <0>; }; diff --git a/Documentation/devicetree/bindings/timer/cirrus,clps711x-timer.txt b/Documentation/devicetree/bindings/timer/cirrus,clps711x-timer.txt new file mode 100644 index 000000000000..cd55b52548e4 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/cirrus,clps711x-timer.txt @@ -0,0 +1,29 @@ +* Cirrus Logic CLPS711X Timer Counter + +Required properties: +- compatible: Shall contain "cirrus,clps711x-timer". +- reg : Address and length of the register set. +- interrupts: The interrupt number of the timer. +- clocks : phandle of timer reference clock. + +Note: Each timer should have an alias correctly numbered in "aliases" node. + +Example: + aliases { + timer0 = &timer1; + timer1 = &timer2; + }; + + timer1: timer@80000300 { + compatible = "cirrus,ep7312-timer", "cirrus,clps711x-timer"; + reg = <0x80000300 0x4>; + interrupts = <8>; + clocks = <&clks 5>; + }; + + timer2: timer@80000340 { + compatible = "cirrus,ep7312-timer", "cirrus,clps711x-timer"; + reg = <0x80000340 0x4>; + interrupts = <9>; + clocks = <&clks 6>; + }; diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt new file mode 100644 index 000000000000..7c4408ff4b83 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt @@ -0,0 +1,17 @@ +Mediatek MT6577, MT6572 and MT6589 Timers +--------------------------------------- + +Required properties: +- compatible: Should be "mediatek,mt6577-timer" +- reg: Should contain location and length for timers register. +- clocks: Clocks driving the timer hardware. This list should include two + clocks. The order is system clock and as second clock the RTC clock. + +Examples: + + timer@10008000 { + compatible = "mediatek,mt6577-timer"; + reg = <0x10008000 0x80>; + interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_LOW>; + clocks = <&system_clk>, <&rtc_clk>; + }; diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt b/Documentation/devicetree/bindings/timer/renesas,cmt.txt new file mode 100644 index 000000000000..a17418b0ece3 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt @@ -0,0 +1,47 @@ +* Renesas R-Car Compare Match Timer (CMT) + +The CMT is a multi-channel 16/32/48-bit timer/counter with configurable clock +inputs and programmable compare match. + +Channels share hardware resources but their counter and compare match value +are independent. A particular CMT instance can implement only a subset of the +channels supported by the CMT model. Channel indices represent the hardware +position of the channel in the CMT and don't match the channel numbers in the +datasheets. + +Required Properties: + + - compatible: must contain one of the following. + - "renesas,cmt-32" for the 32-bit CMT + (CMT0 on sh7372, sh73a0 and r8a7740) + - "renesas,cmt-32-fast" for the 32-bit CMT with fast clock support + (CMT[234] on sh7372, sh73a0 and r8a7740) + - "renesas,cmt-48" for the 48-bit CMT + (CMT1 on sh7372, sh73a0 and r8a7740) + - "renesas,cmt-48-gen2" for the second generation 48-bit CMT + (CMT[01] on r8a73a4, r8a7790 and r8a7791) + + - reg: base address and length of the registers block for the timer module. + - interrupts: interrupt-specifier for the timer, one per channel. + - clocks: a list of phandle + clock-specifier pairs, one for each entry + in clock-names. + - clock-names: must contain "fck" for the functional clock. + + - renesas,channels-mask: bitmask of the available channels. + + +Example: R8A7790 (R-Car H2) CMT0 node + + CMT0 on R8A7790 implements hardware channels 5 and 6 only and names + them channels 0 and 1 in the documentation. + + cmt0: timer@ffca0000 { + compatible = "renesas,cmt-48-gen2"; + reg = <0 0xffca0000 0 0x1004>; + interrupts = <0 142 IRQ_TYPE_LEVEL_HIGH>, + <0 142 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp1_clks R8A7790_CLK_CMT0>; + clock-names = "fck"; + + renesas,channels-mask = <0x60>; + }; diff --git a/Documentation/devicetree/bindings/timer/renesas,mtu2.txt b/Documentation/devicetree/bindings/timer/renesas,mtu2.txt new file mode 100644 index 000000000000..917453f826bc --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,mtu2.txt @@ -0,0 +1,39 @@ +* Renesas R-Car Multi-Function Timer Pulse Unit 2 (MTU2) + +The MTU2 is a multi-purpose, multi-channel timer/counter with configurable +clock inputs and programmable compare match. + +Channels share hardware resources but their counter and compare match value +are independent. The MTU2 hardware supports five channels indexed from 0 to 4. + +Required Properties: + + - compatible: must contain "renesas,mtu2" + + - reg: base address and length of the registers block for the timer module. + + - interrupts: interrupt specifiers for the timer, one for each entry in + interrupt-names. + - interrupt-names: must contain one entry named "tgi?a" for each enabled + channel, where "?" is the channel index expressed as one digit from "0" to + "4". + + - clocks: a list of phandle + clock-specifier pairs, one for each entry + in clock-names. + - clock-names: must contain "fck" for the functional clock. + + +Example: R7S72100 (RZ/A1H) MTU2 node + + mtu2: timer@fcff0000 { + compatible = "renesas,mtu2"; + reg = <0xfcff0000 0x400>; + interrupts = <0 139 IRQ_TYPE_LEVEL_HIGH>, + <0 146 IRQ_TYPE_LEVEL_HIGH>, + <0 150 IRQ_TYPE_LEVEL_HIGH>, + <0 154 IRQ_TYPE_LEVEL_HIGH>, + <0 159 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "tgi0a", "tgi1a", "tgi2a", "tgi3a", "tgi4a"; + clocks = <&mstp3_clks R7S72100_CLK_MTU2>; + clock-names = "fck"; + }; diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt b/Documentation/devicetree/bindings/timer/renesas,tmu.txt new file mode 100644 index 000000000000..425d0c5f4aee --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.txt @@ -0,0 +1,39 @@ +* Renesas R-Car Timer Unit (TMU) + +The TMU is a 32-bit timer/counter with configurable clock inputs and +programmable compare match. + +Channels share hardware resources but their counter and compare match value +are independent. The TMU hardware supports up to three channels. + +Required Properties: + + - compatible: must contain "renesas,tmu" + + - reg: base address and length of the registers block for the timer module. + + - interrupts: interrupt-specifier for the timer, one per channel. + + - clocks: a list of phandle + clock-specifier pairs, one for each entry + in clock-names. + - clock-names: must contain "fck" for the functional clock. + +Optional Properties: + + - #renesas,channels: number of channels implemented by the timer, must be 2 + or 3 (if not specified the value defaults to 3). + + +Example: R8A7779 (R-Car H1) TMU0 node + + tmu0: timer@ffd80000 { + compatible = "renesas,tmu"; + reg = <0xffd80000 0x30>; + interrupts = <0 32 IRQ_TYPE_LEVEL_HIGH>, + <0 33 IRQ_TYPE_LEVEL_HIGH>, + <0 34 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp0_clks R8A7779_CLK_TMU0>; + clock-names = "fck"; + + #renesas,channels = <3>; + }; diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt index a6a32cb7f777..1bae71e9ad47 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt @@ -4,6 +4,7 @@ Required properties: - compatible: Should be "fsl,imx27-usb" - reg: Should contain registers location and length - interrupts: Should contain controller interrupt +- fsl,usbphy: phandle of usb phy that connects to the port Recommended properies: - phy_type: the type of the phy connected to the core. Should be one @@ -12,7 +13,6 @@ Recommended properies: - dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg" Optional properties: -- fsl,usbphy: phandler of usb phy that connects to the only one port - fsl,usbmisc: phandler of non-core register device, with one argument that indicate usb controller index - vbus-supply: regulator for vbus diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt index ba797d3e6326..c9205fbf26e2 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt @@ -20,6 +20,12 @@ Required properties : Present if phy_type == utmi. - ulpi-link: The clock Tegra provides to the ULPI PHY (cdev2). Present if phy_type == ulpi, and ULPI link mode is in use. + - resets : Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names : Must include the following entries: + - usb: The PHY's own reset signal. + - utmi-pads: The reset of the PHY containing the chip-wide UTMI pad control + registers. Required even if phy_type == ulpi. Required properties for phy_type == ulpi: - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. @@ -56,6 +62,8 @@ Optional properties: host means this is a host controller peripheral means it is device controller otg means it can operate as either ("on the go") + - nvidia,has-utmi-pad-registers : boolean indicates whether this controller + contains the UTMI pad control registers common to all USB controllers. VBUS control (required for dr_mode == otg, optional for dr_mode == host): - vbus-supply: regulator for VBUS diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index 5a79377c6a96..86f67f0886bc 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -9,8 +9,9 @@ Required properties: register set for the device. - interrupts: one XHCI interrupt should be described here. -Optional property: +Optional properties: - clocks: reference to a clock + - usb3-lpm-capable: determines if platform is USB3 LPM capable Example: usb@f0931000 { diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 46a311e728a8..d415b38ec8ca 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -42,6 +42,7 @@ dmo Data Modul AG ebv EBV Elektronik edt Emerging Display Technologies emmicro EM Microelectronic +epcos EPCOS AG epfl Ecole Polytechnique Fédérale de Lausanne epson Seiko Epson Corp. est ESTeem Wireless Modems @@ -77,6 +78,7 @@ lsi LSI Corp. (LSI Logic) lltc Linear Technology Corporation marvell Marvell Technology Group Ltd. maxim Maxim Integrated Products +mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. mosaixtech Mosaix Technologies, Inc. diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 1525e30483fd..d14710b04439 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -233,66 +233,78 @@ certainly invest a bit more effort into libata core layer). 6. List of managed interfaces ----------------------------- -MEM - devm_kzalloc() - devm_kfree() - devm_kmemdup() - devm_get_free_pages() - devm_free_pages() +CLOCK + devm_clk_get() + devm_clk_put() + +DMA + dmam_alloc_coherent() + dmam_alloc_noncoherent() + dmam_declare_coherent_memory() + dmam_free_coherent() + dmam_free_noncoherent() + dmam_pool_create() + dmam_pool_destroy() + +GPIO + devm_gpiod_get() + devm_gpiod_get_index() + devm_gpiod_get_index_optional() + devm_gpiod_get_optional() + devm_gpiod_put() IIO devm_iio_device_alloc() devm_iio_device_free() - devm_iio_trigger_alloc() - devm_iio_trigger_free() devm_iio_device_register() devm_iio_device_unregister() + devm_iio_trigger_alloc() + devm_iio_trigger_free() IO region - devm_request_region() - devm_request_mem_region() - devm_release_region() devm_release_mem_region() - -IRQ - devm_request_irq() - devm_free_irq() - -DMA - dmam_alloc_coherent() - dmam_free_coherent() - dmam_alloc_noncoherent() - dmam_free_noncoherent() - dmam_declare_coherent_memory() - dmam_pool_create() - dmam_pool_destroy() - -PCI - pcim_enable_device() : after success, all PCI ops become managed - pcim_pin_device() : keep PCI device enabled after release + devm_release_region() + devm_request_mem_region() + devm_request_region() IOMAP devm_ioport_map() devm_ioport_unmap() devm_ioremap() devm_ioremap_nocache() - devm_iounmap() devm_ioremap_resource() : checks resource, requests memory region, ioremaps - devm_request_and_ioremap() : obsoleted by devm_ioremap_resource() + devm_iounmap() pcim_iomap() - pcim_iounmap() - pcim_iomap_table() : array of mapped addresses indexed by BAR pcim_iomap_regions() : do request_region() and iomap() on multiple BARs + pcim_iomap_table() : array of mapped addresses indexed by BAR + pcim_iounmap() -REGULATOR - devm_regulator_get() - devm_regulator_put() - devm_regulator_bulk_get() - devm_regulator_register() +IRQ + devm_free_irq() + devm_request_irq() -CLOCK - devm_clk_get() - devm_clk_put() +MDIO + devm_mdiobus_alloc() + devm_mdiobus_alloc_size() + devm_mdiobus_free() + +MEM + devm_free_pages() + devm_get_free_pages() + devm_kcalloc() + devm_kfree() + devm_kmalloc() + devm_kmalloc_array() + devm_kmemdup() + devm_kzalloc() + +PCI + pcim_enable_device() : after success, all PCI ops become managed + pcim_pin_device() : keep PCI device enabled after release + +PHY + devm_usb_get_phy() + devm_usb_put_phy() PINCTRL devm_pinctrl_get() @@ -302,24 +314,14 @@ PWM devm_pwm_get() devm_pwm_put() -PHY - devm_usb_get_phy() - devm_usb_put_phy() +REGULATOR + devm_regulator_bulk_get() + devm_regulator_get() + devm_regulator_put() + devm_regulator_register() SLAVE DMA ENGINE devm_acpi_dma_controller_register() SPI devm_spi_register_master() - -GPIO - devm_gpiod_get() - devm_gpiod_get_index() - devm_gpiod_get_optional() - devm_gpiod_get_index_optional() - devm_gpiod_put() - -MDIO - devm_mdiobus_alloc() - devm_mdiobus_alloc_size() - devm_mdiobus_free() diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index d91b8be80b66..26c623dd3aa3 100755 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -29,7 +29,7 @@ use IO::Handle; "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395", "lme2510c_s7395_old", "drxk", "drxk_terratec_h5", "drxk_hauppauge_hvr930c", "tda10071", "it9135", "drxk_pctv", - "drxk_terratec_htc_stick", "sms1xxx_hcw"); + "drxk_terratec_htc_stick", "sms1xxx_hcw", "si2165"); # Check args syntax() if (scalar(@ARGV) != 1); @@ -783,6 +783,37 @@ sub sms1xxx_hcw { $allfiles; } +sub si2165 { + my $sourcefile = "model_111xxx_122xxx_driver_6_0_119_31191_WHQL.zip"; + my $url = "http://www.hauppauge.de/files/drivers/"; + my $hash = "76633e7c76b0edee47c3ba18ded99336"; + my $fwfile = "dvb-demod-si2165.fw"; + my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); + + checkstandard(); + + wgetfile($sourcefile, $url . $sourcefile); + verify($sourcefile, $hash); + unzip($sourcefile, $tmpdir); + extract("$tmpdir/Driver10/Hcw10bda.sys", 0x80788, 0x81E08-0x80788, "$tmpdir/fw1"); + + delzero("$tmpdir/fw1","$tmpdir/fw1-1"); + #verify("$tmpdir/fw1","5e0909858fdf0b5b09ad48b9fe622e70"); + + my $CRC="\x0A\xCC"; + my $BLOCKS_MAIN="\x27"; + open FW,">$fwfile"; + print FW "\x01\x00"; # just a version id for the driver itself + print FW "\x9A"; # fw version + print FW "\x00"; # padding + print FW "$BLOCKS_MAIN"; # number of blocks of main part + print FW "\x00"; # padding + print FW "$CRC"; # 16bit crc value of main part + appendfile(FW,"$tmpdir/fw1"); + + "$fwfile"; +} + # --------------------------------------------------------------- # Utilities diff --git a/Documentation/filesystems/caching/operations.txt b/Documentation/filesystems/caching/operations.txt index bee2a5f93d60..a1c052cbba35 100644 --- a/Documentation/filesystems/caching/operations.txt +++ b/Documentation/filesystems/caching/operations.txt @@ -90,7 +90,7 @@ operations: to be cleared before proceeding: wait_on_bit(&op->flags, FSCACHE_OP_WAITING, - fscache_wait_bit, TASK_UNINTERRUPTIBLE); + TASK_UNINTERRUPTIBLE); (2) The operation may be fast asynchronous (FSCACHE_OP_FAST), in which case it diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index 51afba17bbae..a2046a7d0a9d 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -126,6 +126,11 @@ flush_merge Merge concurrent cache_flush commands as much as possible to eliminate redundant command issues. If the underlying device handles the cache_flush command relatively slowly, recommend to enable this option. +nobarrier This option can be used if underlying storage guarantees + its cached data should be written to the novolatile area. + If this option is set, no cache_flush commands are issued + but f2fs still guarantees the write ordering of all the + data writes. ================================================================================ DEBUGFS ENTRIES diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index ddc531a74d04..eb8a10e22f7c 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1743,6 +1743,25 @@ pair provide additional information particular to the objects they represent. While the first three lines are mandatory and always printed, the rest is optional and may be omitted if no marks created yet. + Timerfd files + ~~~~~~~~~~~~~ + + pos: 0 + flags: 02 + mnt_id: 9 + clockid: 0 + ticks: 0 + settime flags: 01 + it_value: (0, 49406829) + it_interval: (1, 0) + + where 'clockid' is the clock type and 'ticks' is the number of the timer expirations + that have occurred [see timerfd_create(2) for details]. 'settime flags' are + flags in octal form been used to setup the timer [see timerfd_settime(2) for + details]. 'it_value' is remaining time until the timer exiration. + 'it_interval' is the interval for the timer. Note the timer might be set up + with TIMER_ABSTIME option which will be shown in 'settime flags', but 'it_value' + still exhibits timer's remaining time. ------------------------------------------------------------------------------ Configuring procfs diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README index 43fada989e65..71f86859d7d8 100644 --- a/Documentation/firmware_class/README +++ b/Documentation/firmware_class/README @@ -64,7 +64,7 @@ if(request_firmware(&fw_entry, $FIRMWARE, device) == 0) copy_fw_to_device(fw_entry->data, fw_entry->size); - release(fw_entry); + release_firmware(fw_entry); Sample/simple hotplug script: ============================ @@ -74,7 +74,7 @@ HOTPLUG_FW_DIR=/usr/lib/hotplug/firmware/ echo 1 > /sys/$DEVPATH/loading - cat $HOTPLUG_FW_DIR/$FIRMWARE > /sysfs/$DEVPATH/data + cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data echo 0 > /sys/$DEVPATH/loading Random notes: @@ -123,6 +123,6 @@ -------------------- After firmware cache mechanism is introduced during system sleep, request_firmware can be called safely inside device's suspend and - resume callback, and callers need't cache the firmware by + resume callback, and callers needn't cache the firmware by themselves any more for dealing with firmware loss during system resume. diff --git a/Documentation/hwmon/ibmpowernv b/Documentation/hwmon/ibmpowernv new file mode 100644 index 000000000000..8826ba29db36 --- /dev/null +++ b/Documentation/hwmon/ibmpowernv @@ -0,0 +1,41 @@ +Kernel Driver IBMPOWERNV +======================== + +Supported systems: + * Any recent IBM P servers based on POWERNV platform + +Author: Neelesh Gupta + +Description +----------- + +This driver implements reading the platform sensors data like temperature/fan/ +voltage/power for 'POWERNV' platform. + +The driver uses the platform device infrastructure. It probes the device tree +for sensor devices during the __init phase and registers them with the 'hwmon'. +'hwmon' populates the 'sysfs' tree having attribute files, each for a given +sensor type and its attribute data. + +All the nodes in the DT appear under "/ibm,opal/sensors" and each valid node in +the DT maps to an attribute file in 'sysfs'. The node exports unique 'sensor-id' +which the driver uses to make an OPAL call to the firmware. + +Usage notes +----------- +The driver is built statically with the kernel by enabling the config +CONFIG_SENSORS_IBMPOWERNV. It can also be built as module 'ibmpowernv'. + +Sysfs attributes +---------------- + +fanX_input Measured RPM value. +fanX_min Threshold RPM for alert generation. +fanX_fault 0: No fail condition + 1: Failing fan +tempX_input Measured ambient temperature. +tempX_max Threshold ambient temperature for alert generation. +inX_input Measured power supply voltage +inX_fault 0: No fail condition. + 1: Failing power supply. +power1_input System power consumption (microWatt) diff --git a/Documentation/hwmon/lm75 b/Documentation/hwmon/lm75 index 2560a9c6d445..c6a5ff1b4641 100644 --- a/Documentation/hwmon/lm75 +++ b/Documentation/hwmon/lm75 @@ -42,13 +42,14 @@ Supported chips: Addresses scanned: none Datasheet: Publicly available at the ST website http://www.st.com/internet/analog/product/121769.jsp - * Texas Instruments TMP100, TMP101, TMP105, TMP75, TMP175, TMP275 - Prefixes: 'tmp100', 'tmp101', 'tmp105', 'tmp175', 'tmp75', 'tmp275' + * Texas Instruments TMP100, TMP101, TMP105, TMP112, TMP75, TMP175, TMP275 + Prefixes: 'tmp100', 'tmp101', 'tmp105', 'tmp112', 'tmp175', 'tmp75', 'tmp275' Addresses scanned: none Datasheet: Publicly available at the Texas Instruments website http://www.ti.com/product/tmp100 http://www.ti.com/product/tmp101 http://www.ti.com/product/tmp105 + http://www.ti.com/product/tmp112 http://www.ti.com/product/tmp75 http://www.ti.com/product/tmp175 http://www.ti.com/product/tmp275 diff --git a/Documentation/hwmon/ntc_thermistor b/Documentation/hwmon/ntc_thermistor index 057b77029f26..c5e05e2900a3 100644 --- a/Documentation/hwmon/ntc_thermistor +++ b/Documentation/hwmon/ntc_thermistor @@ -6,6 +6,11 @@ Supported thermistors from Murata: Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473', 'ncp15wl333' Datasheet: Publicly available at Murata +Supported thermistors from EPCOS: +* EPCOS NTC Thermistors B57330V2103 + Prefixes: b57330v2103 + Datasheet: Publicly available at EPCOS + Other NTC thermistors can be supported simply by adding compensation tables; e.g., NCP15WL333 support is added by the table ncpXXwl333. diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus index cf756ed48ff9..a3557da8f5b4 100644 --- a/Documentation/hwmon/pmbus +++ b/Documentation/hwmon/pmbus @@ -23,12 +23,11 @@ Supported chips: http://www.lineagepower.com/oem/pdf/PDT012A0X.pdf http://www.lineagepower.com/oem/pdf/UDT020A0X.pdf http://www.lineagepower.com/oem/pdf/MDT040A0X.pdf - * Texas Instruments TPS40400, TPS40422 - Prefixes: 'tps40400', 'tps40422' + * Texas Instruments TPS40400 + Prefixes: 'tps40400' Addresses scanned: - Datasheets: http://www.ti.com/lit/gpn/tps40400 - http://www.ti.com/lit/gpn/tps40422 * Generic PMBus devices Prefix: 'pmbus' Addresses scanned: - diff --git a/Documentation/hwmon/powr1220 b/Documentation/hwmon/powr1220 new file mode 100644 index 000000000000..21e44f71ae6e --- /dev/null +++ b/Documentation/hwmon/powr1220 @@ -0,0 +1,45 @@ +Kernel driver powr1220 +================== + +Supported chips: + * Lattice POWR1220AT8 + Prefix: 'powr1220' + Addresses scanned: none + Datasheet: Publicly available at the Lattice website + http://www.latticesemi.com/ + +Author: Scott Kanowitz <scott.kanowitz@gmail.com> + +Description +----------- + +This driver supports the Lattice POWR1220AT8 chip. The POWR1220 +includes voltage monitoring for 14 inputs as well as trim settings +for output voltages and GPIOs. This driver implements the voltage +monitoring portion of the chip. + +Voltages are sampled by a 12-bit ADC with a step size of 2 mV. +An in-line attenuator allows measurements from 0 to 6 V. The +attenuator is enabled or disabled depending on the setting of the +input's max value. The driver will enable the attenuator for any +value over the low measurement range maximum of 2 V. + +The input naming convention is as follows: + +driver name pin name +in0 VMON1 +in1 VMON2 +in2 VMON3 +in2 VMON4 +in4 VMON5 +in5 VMON6 +in6 VMON7 +in7 VMON8 +in8 VMON9 +in9 VMON10 +in10 VMON11 +in11 VMON12 +in12 VCCA +in13 VCCINP + +The ADC readings are updated on request with a minimum period of 1s. diff --git a/Documentation/hwmon/pwm-fan b/Documentation/hwmon/pwm-fan new file mode 100644 index 000000000000..18529d2e3bcf --- /dev/null +++ b/Documentation/hwmon/pwm-fan @@ -0,0 +1,17 @@ +Kernel driver pwm-fan +===================== + +This driver enables the use of a PWM module to drive a fan. It uses the +generic PWM interface thus it is hardware independent. It can be used on +many SoCs, as long as the SoC supplies a PWM line driver that exposes +the generic PWM API. + +Author: Kamil Debski <k.debski@samsung.com> + +Description +----------- + +The driver implements a simple interface for driving a fan connected to +a PWM output. It uses the generic PWM interface, thus it can be used with +a range of SoCs. The driver exposes the fan to the user space through +the hwmon's sysfs interface. diff --git a/Documentation/hwmon/tmp103 b/Documentation/hwmon/tmp103 new file mode 100644 index 000000000000..ec00a15645ba --- /dev/null +++ b/Documentation/hwmon/tmp103 @@ -0,0 +1,28 @@ +Kernel driver tmp103 +==================== + +Supported chips: + * Texas Instruments TMP103 + Prefix: 'tmp103' + Addresses scanned: none + Product info and datasheet: http://www.ti.com/product/tmp103 + +Author: + Heiko Schocher <hs@denx.de> + +Description +----------- + +The TMP103 is a digital output temperature sensor in a four-ball +wafer chip-scale package (WCSP). The TMP103 is capable of reading +temperatures to a resolution of 1°C. The TMP103 is specified for +operation over a temperature range of –40°C to +125°C. + +Resolution: 8 Bits +Accuracy: ±1°C Typ (–10°C to +100°C) + +The driver provides the common sysfs-interface for temperatures (see +Documentation/hwmon/sysfs-interface under Temperatures). + +Please refer how to instantiate this driver: +Documentation/i2c/instantiating-devices diff --git a/Documentation/hwmon/tmp421 b/Documentation/hwmon/tmp421 index 0cf07f824741..9e6fe5549ca1 100644 --- a/Documentation/hwmon/tmp421 +++ b/Documentation/hwmon/tmp421 @@ -8,12 +8,20 @@ Supported chips: Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html * Texas Instruments TMP422 Prefix: 'tmp422' - Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f + Addresses scanned: I2C 0x4c, 0x4d, 0x4e and 0x4f Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html * Texas Instruments TMP423 Prefix: 'tmp423' - Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f + Addresses scanned: I2C 0x4c and 0x4d Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html + * Texas Instruments TMP441 + Prefix: 'tmp441' + Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f + Datasheet: http://www.ti.com/product/tmp441 + * Texas Instruments TMP442 + Prefix: 'tmp442' + Addresses scanned: I2C 0x4c and 0x4d + Datasheet: http://www.ti.com/product/tmp442 Authors: Andre Prendel <andre.prendel@gmx.de> @@ -21,13 +29,13 @@ Authors: Description ----------- -This driver implements support for Texas Instruments TMP421, TMP422 -and TMP423 temperature sensor chips. These chips implement one local -and up to one (TMP421), up to two (TMP422) or up to three (TMP423) -remote sensors. Temperature is measured in degrees Celsius. The chips -are wired over I2C/SMBus and specified over a temperature range of -40 -to +125 degrees Celsius. Resolution for both the local and remote -channels is 0.0625 degree C. +This driver implements support for Texas Instruments TMP421, TMP422, +TMP423, TMP441, and TMP442 temperature sensor chips. These chips +implement one local and up to one (TMP421, TMP441), up to two (TMP422, +TMP442) or up to three (TMP423) remote sensors. Temperature is measured +in degrees Celsius. The chips are wired over I2C/SMBus and specified +over a temperature range of -40 to +125 degrees Celsius. Resolution +for both the local and remote channels is 0.0625 degree C. The chips support only temperature measurement. The driver exports the temperature values via the following sysfs files: diff --git a/Documentation/hwmon/tps40422 b/Documentation/hwmon/tps40422 new file mode 100644 index 000000000000..24bb0688d515 --- /dev/null +++ b/Documentation/hwmon/tps40422 @@ -0,0 +1,64 @@ +Kernel driver tps40422 +====================== + +Supported chips: + * TI TPS40422 + Prefix: 'tps40422' + Addresses scanned: - + Datasheet: http://www.ti.com/lit/gpn/tps40422 + +Author: Zhu Laiwen <richard.zhu@nsn.com> + + +Description +----------- + +This driver supports TI TPS40422 Dual-Output or Two-Phase Synchronous Buck +Controller with PMBus + +The driver is a client driver to the core PMBus driver. +Please see Documentation/hwmon/pmbus for details on PMBus client drivers. + + +Usage Notes +----------- + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices for +details. + + +Platform data support +--------------------- + +The driver supports standard PMBus driver platform data. + + +Sysfs entries +------------- + +The following attributes are supported. + +in[1-2]_label "vout[1-2]" +in[1-2]_input Measured voltage. From READ_VOUT register. +in[1-2]_alarm voltage alarm. + +curr[1-2]_input Measured current. From READ_IOUT register. +curr[1-2]_label "iout[1-2]" +curr1_max Maximum current. From IOUT_OC_WARN_LIMIT register. +curr1_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register. +curr1_max_alarm Current high alarm. From IOUT_OC_WARN_LIMIT status. +curr1_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status. +curr2_alarm Current high alarm. From IOUT_OC_WARNING status. + +temp1_input Measured temperature. From READ_TEMPERATURE_2 register on page 0. +temp1_max Maximum temperature. From OT_WARN_LIMIT register. +temp1_crit Critical high temperature. From OT_FAULT_LIMIT register. +temp1_max_alarm Chip temperature high alarm. Set by comparing + READ_TEMPERATURE_2 on page 0 with OT_WARN_LIMIT if TEMP_OT_WARNING + status is set. +temp1_crit_alarm Chip temperature critical high alarm. Set by comparing + READ_TEMPERATURE_2 on page 0 with OT_FAULT_LIMIT if TEMP_OT_FAULT + status is set. +temp2_input Measured temperature. From READ_TEMPERATURE_2 register on page 1. +temp2_alarm Chip temperature alarm on page 1. diff --git a/Documentation/input/event-codes.txt b/Documentation/input/event-codes.txt index f1ea2c69648d..c587a966413e 100644 --- a/Documentation/input/event-codes.txt +++ b/Documentation/input/event-codes.txt @@ -281,6 +281,19 @@ gestures can normally be extracted from it. If INPUT_PROP_SEMI_MT is not set, the device is assumed to be a true MT device. +INPUT_PROP_TOPBUTTONPAD: +----------------------- +Some laptops, most notably the Lenovo *40 series provide a trackstick +device but do not have physical buttons associated with the trackstick +device. Instead, the top area of the touchpad is marked to show +visual/haptic areas for left, middle, right buttons intended to be used +with the trackstick. + +If INPUT_PROP_TOPBUTTONPAD is set, userspace should emulate buttons +accordingly. This property does not affect kernel behavior. +The kernel does not provide button emulation for such devices but treats +them as any other INPUT_PROP_BUTTONPAD device. + Guidelines: ========== The guidelines below ensure proper single-touch and multi-finger functionality. diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index d7e43fa88575..7e240a7c9ab1 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -197,6 +197,7 @@ Code Seq#(hex) Include File Comments <mailto:gregkh@linuxfoundation.org> 'a' all linux/atm*.h, linux/sonet.h ATM on linux <http://lrcwww.epfl.ch/> +'a' 00-0F drivers/crypto/qat/qat_common/adf_cfg_common.h conflict! qat driver 'b' 00-FF conflict! bit3 vme host bridge <mailto:natalia@nikhefk.nikhef.nl> 'c' all linux/cm4000_cs.h conflict! diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c1b9aa8c5a52..883901b9ac4f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -566,6 +566,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. possible to determine what the correct size should be. This option provides an override for these situations. + ca_keys= [KEYS] This parameter identifies a specific key(s) on + the system trusted keyring to be used for certificate + trust validation. + format: { id:<keyid> | builtin } + ccw_timeout_log [S390] See Documentation/s390/CommonIO for details. @@ -1097,6 +1102,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. that can be changed at run time by the set_graph_function file in the debugfs tracing directory. + ftrace_graph_notrace=[function-list] + [FTRACE] Do not trace from the functions specified in + function-list. This list is a comma separated list of + functions that can be changed at run time by the + set_graph_notrace file in the debugfs tracing directory. + gamecon.map[2|3]= [HW,JOY] Multisystem joystick and NES/SNES/PSX pad support via parallel port (up to 5 devices per port) @@ -1313,6 +1324,23 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Formats: { "ima" | "ima-ng" } Default: "ima-ng" + ima.ahash_minsize= [IMA] Minimum file size for asynchronous hash usage + Format: <min_file_size> + Set the minimal file size for using asynchronous hash. + If left unspecified, ahash usage is disabled. + + ahash performance varies for different data sizes on + different crypto accelerators. This option can be used + to achieve the best performance for a particular HW. + + ima.ahash_bufsize= [IMA] Asynchronous hash buffer size + Format: <bufsize> + Set hashing buffer size. Default: 4k. + + ahash performance varies for different chunk sizes on + different crypto accelerators. This option can be used + to achieve best performance for particular HW. + init= [KNL] Format: <full_path> Run specified binary instead of /sbin/init as init @@ -1416,10 +1444,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. ip= [IP_PNP] See Documentation/filesystems/nfs/nfsroot.txt. - ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards - See comment before ip2_setup() in - drivers/char/ip2/ip2base.c. - irqfixup [HW] When an interrupt is not handled search all handlers for it. Intended to get systems with badly broken @@ -2790,6 +2814,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. leaf rcu_node structure. Useful for very large systems. + rcutree.jiffies_till_sched_qs= [KNL] + Set required age in jiffies for a + given grace period before RCU starts + soliciting quiescent-state help from + rcu_note_context_switch(). + rcutree.jiffies_till_first_fqs= [KNL] Set delay from grace-period initialization to first attempt to force quiescent states. @@ -2801,6 +2831,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. quiescent states. Units are jiffies, minimum value is one, and maximum value is HZ. + rcutree.rcu_nocb_leader_stride= [KNL] + Set the number of NOCB kthread groups, which + defaults to the square root of the number of + CPUs. Larger numbers reduces the wakeup overhead + on the per-CPU grace-period kthreads, but increases + that same overhead on each group's leader. + rcutree.qhimark= [KNL] Set threshold of queued RCU callbacks beyond which batch limiting is disabled. @@ -3526,7 +3563,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. the allocated input device; If set to 0, video driver will only send out the event without touching backlight brightness level. - default: 0 + default: 1 virtio_mmio.device= [VMMIO] Memory mapped virtio (platform) device. diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index f1dc4a215593..a4de88fb55f0 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -757,10 +757,14 @@ SMP BARRIER PAIRING When dealing with CPU-CPU interactions, certain types of memory barrier should always be paired. A lack of appropriate pairing is almost certainly an error. -A write barrier should always be paired with a data dependency barrier or read -barrier, though a general barrier would also be viable. Similarly a read -barrier or a data dependency barrier should always be paired with at least an -write barrier, though, again, a general barrier is viable: +General barriers pair with each other, though they also pair with +most other types of barriers, albeit without transitivity. An acquire +barrier pairs with a release barrier, but both may also pair with other +barriers, including of course general barriers. A write barrier pairs +with a data dependency barrier, an acquire barrier, a release barrier, +a read barrier, or a general barrier. Similarly a read barrier or a +data dependency barrier pairs with a write barrier, an acquire barrier, +a release barrier, or a general barrier: CPU 1 CPU 2 =============== =============== @@ -1893,6 +1897,21 @@ between the STORE to indicate the event and the STORE to set TASK_RUNNING: <general barrier> STORE current->state LOAD event_indicated +To repeat, this write memory barrier is present if and only if something +is actually awakened. To see this, consider the following sequence of +events, where X and Y are both initially zero: + + CPU 1 CPU 2 + =============================== =============================== + X = 1; STORE event_indicated + smp_mb(); wake_up(); + Y = 1; wait_event(wq, Y == 1); + wake_up(); load from Y sees 1, no memory barrier + load from X might see 0 + +In contrast, if a wakeup does occur, CPU 2's load from X would be guaranteed +to see 1. + The available waker functions include: complete(); diff --git a/Documentation/mic/mic_overview.txt b/Documentation/mic/mic_overview.txt index b41929224804..77c541802ad9 100644 --- a/Documentation/mic/mic_overview.txt +++ b/Documentation/mic/mic_overview.txt @@ -17,35 +17,50 @@ for applications. A key benefit of our solution is that it leverages the standard virtio framework for network, disk and console devices, though in our case the virtio framework is used across a PCIe bus. +MIC PCIe card has a dma controller with 8 channels. These channels are +shared between the host s/w and the card s/w. 0 to 3 are used by host +and 4 to 7 by card. As the dma device doesn't show up as PCIe device, +a virtual bus called mic bus is created and virtual dma devices are +created on it by the host/card drivers. On host the channels are private +and used only by the host driver to transfer data for the virtio devices. + Here is a block diagram of the various components described above. The virtio backends are situated on the host rather than the card given better single threaded performance for the host compared to MIC, the ability of the host to initiate DMA's to/from the card using the MIC DMA engine and the fact that the virtio block storage backend can only be on the host. - | - +----------+ | +----------+ - | Card OS | | | Host OS | - +----------+ | +----------+ - | -+-------+ +--------+ +------+ | +---------+ +--------+ +--------+ -| Virtio| |Virtio | |Virtio| | |Virtio | |Virtio | |Virtio | -| Net | |Console | |Block | | |Net | |Console | |Block | -| Driver| |Driver | |Driver| | |backend | |backend | |backend | -+-------+ +--------+ +------+ | +---------+ +--------+ +--------+ - | | | | | | | - | | | |User | | | - | | | |------|------------|---------|------- - +-------------------+ |Kernel +--------------------------+ - | | | Virtio over PCIe IOCTLs | - | | +--------------------------+ - +--------------+ | | - |Intel MIC | | +---------------+ - |Card Driver | | |Intel MIC | - +--------------+ | |Host Driver | - | | +---------------+ - | | | - +-------------------------------------------------------------+ - | | - | PCIe Bus | - +-------------------------------------------------------------+ + | + +----------+ | +----------+ + | Card OS | | | Host OS | + +----------+ | +----------+ + | + +-------+ +--------+ +------+ | +---------+ +--------+ +--------+ + | Virtio| |Virtio | |Virtio| | |Virtio | |Virtio | |Virtio | + | Net | |Console | |Block | | |Net | |Console | |Block | + | Driver| |Driver | |Driver| | |backend | |backend | |backend | + +-------+ +--------+ +------+ | +---------+ +--------+ +--------+ + | | | | | | | + | | | |User | | | + | | | |------|------------|---------|------- + +-------------------+ |Kernel +--------------------------+ + | | | Virtio over PCIe IOCTLs | + | | +--------------------------+ ++-----------+ | | | +-----------+ +| MIC DMA | | | | | MIC DMA | +| Driver | | | | | Driver | ++-----------+ | | | +-----------+ + | | | | | ++---------------+ | | | +----------------+ +|MIC virtual Bus| | | | |MIC virtual Bus | ++---------------+ | | | +----------------+ + | | | | | + | +--------------+ | +---------------+ | + | |Intel MIC | | |Intel MIC | | + +---|Card Driver | | |Host Driver | | + +--------------+ | +---------------+-----+ + | | | + +-------------------------------------------------------------+ + | | + | PCIe Bus | + +-------------------------------------------------------------+ diff --git a/Documentation/mic/mpssd/mpss b/Documentation/mic/mpssd/mpss index 3136c68dad0b..cacbdb0aefb9 100755 --- a/Documentation/mic/mpssd/mpss +++ b/Documentation/mic/mpssd/mpss @@ -48,18 +48,18 @@ start() fi echo -e $"Starting MPSS Stack" - echo -e $"Loading MIC_HOST Module" + echo -e $"Loading MIC_X100_DMA & MIC_HOST Modules" - # Ensure the driver is loaded - if [ ! -d "$sysfs" ]; then - modprobe mic_host + for f in "mic_host" "mic_x100_dma" + do + modprobe $f RETVAL=$? if [ $RETVAL -ne 0 ]; then failure echo return $RETVAL fi - fi + done # Start the daemon echo -n $"Starting MPSSD " @@ -170,8 +170,8 @@ unload() stop sleep 5 - echo -n $"Removing MIC_HOST Module: " - modprobe -r mic_host + echo -n $"Removing MIC_HOST & MIC_X100_DMA Modules: " + modprobe -r mic_host mic_x100_dma RETVAL=$? [ $RETVAL -ne 0 ] && failure || success echo diff --git a/Documentation/phy.txt b/Documentation/phy.txt index ebff6ee52441..c6594af94d25 100644 --- a/Documentation/phy.txt +++ b/Documentation/phy.txt @@ -53,10 +53,12 @@ unregister the PHY. The PHY driver should create the PHY in order for other peripheral controllers to make use of it. The PHY framework provides 2 APIs to create the PHY. -struct phy *phy_create(struct device *dev, const struct phy_ops *ops, - struct phy_init_data *init_data); -struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops, - struct phy_init_data *init_data); +struct phy *phy_create(struct device *dev, struct device_node *node, + const struct phy_ops *ops, + struct phy_init_data *init_data); +struct phy *devm_phy_create(struct device *dev, struct device_node *node, + const struct phy_ops *ops, + struct phy_init_data *init_data); The PHY drivers can use one of the above 2 APIs to create the PHY by passing the device pointer, phy ops and init_data. diff --git a/Documentation/power/regulator/consumer.txt b/Documentation/power/regulator/consumer.txt index 55c4175d8099..81c0e2b49cd8 100644 --- a/Documentation/power/regulator/consumer.txt +++ b/Documentation/power/regulator/consumer.txt @@ -180,3 +180,38 @@ int regulator_unregister_notifier(struct regulator *regulator, Regulators use the kernel notifier framework to send event to their interested consumers. + +7. Regulator Direct Register Access +=================================== +Some kinds of power management hardware or firmware are designed such that +they need to do low-level hardware access to regulators, with no involvement +from the kernel. Examples of such devices are: + +- clocksource with a voltage-controlled oscillator and control logic to change + the supply voltage over I2C to achieve a desired output clock rate +- thermal management firmware that can issue an arbitrary I2C transaction to + perform system poweroff during overtemperature conditions + +To set up such a device/firmware, various parameters like I2C address of the +regulator, addresses of various regulator registers etc. need to be configured +to it. The regulator framework provides the following helpers for querying +these details. + +Bus-specific details, like I2C addresses or transfer rates are handled by the +regmap framework. To get the regulator's regmap (if supported), use :- + +struct regmap *regulator_get_regmap(struct regulator *regulator); + +To obtain the hardware register offset and bitmask for the regulator's voltage +selector register, use :- + +int regulator_get_hardware_vsel_register(struct regulator *regulator, + unsigned *vsel_reg, + unsigned *vsel_mask); + +To convert a regulator framework voltage selector code (used by +regulator_list_voltage) to a hardware-specific voltage selector that can be +directly written to the voltage selector register, use :- + +int regulator_list_hardware_vsel(struct regulator *regulator, + unsigned selector); diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt index a4c33f1a7c6d..8727c194ca16 100644 --- a/Documentation/security/keys.txt +++ b/Documentation/security/keys.txt @@ -1150,20 +1150,24 @@ The structure has a number of fields, some of which are mandatory: const void *data; size_t datalen; size_t quotalen; + time_t expiry; }; Before calling the method, the caller will fill in data and datalen with the payload blob parameters; quotalen will be filled in with the default - quota size from the key type and the rest will be cleared. + quota size from the key type; expiry will be set to TIME_T_MAX and the + rest will be cleared. If a description can be proposed from the payload contents, that should be attached as a string to the description field. This will be used for the key description if the caller of add_key() passes NULL or "". The method can attach anything it likes to type_data[] and payload. These - are merely passed along to the instantiate() or update() operations. + are merely passed along to the instantiate() or update() operations. If + set, the expiry time will be applied to the key if it is instantiated from + this data. - The method should return 0 if success ful or a negative error code + The method should return 0 if successful or a negative error code otherwise. @@ -1172,7 +1176,9 @@ The structure has a number of fields, some of which are mandatory: This method is only required if the preparse() method is provided, otherwise it is unused. It cleans up anything attached to the description, type_data and payload fields of the key_preparsed_payload - struct as filled in by the preparse() method. + struct as filled in by the preparse() method. It will always be called + after preparse() returns successfully, even if instantiate() or update() + succeed. (*) int (*instantiate)(struct key *key, struct key_preparsed_payload *prep); diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index cbc2f03056bd..aee73e78c7d4 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -29,6 +29,9 @@ Rules on what kind of patches are accepted, and which ones are not, into the Procedure for submitting patches to the -stable tree: + - If the patch covers files in net/ or drivers/net please follow netdev stable + submission guidelines as described in + Documentation/networking/netdev-FAQ.txt - Send the patch, after verifying that it follows the above rules, to stable@vger.kernel.org. You must note the upstream commit ID in the changelog of your submission, as well as the kernel version you wish diff --git a/Documentation/timers/00-INDEX b/Documentation/timers/00-INDEX index 6d042dc1cce0..ee212a27772f 100644 --- a/Documentation/timers/00-INDEX +++ b/Documentation/timers/00-INDEX @@ -12,6 +12,8 @@ Makefile - Build and link hpet_example NO_HZ.txt - Summary of the different methods for the scheduler clock-interrupts management. +timekeeping.txt + - Clock sources, clock events, sched_clock() and delay timer notes timers-howto.txt - how to insert delays in the kernel the right (tm) way. timer_stats.txt diff --git a/Documentation/timers/timekeeping.txt b/Documentation/timers/timekeeping.txt new file mode 100644 index 000000000000..f3a8cf28f802 --- /dev/null +++ b/Documentation/timers/timekeeping.txt @@ -0,0 +1,179 @@ +Clock sources, Clock events, sched_clock() and delay timers +----------------------------------------------------------- + +This document tries to briefly explain some basic kernel timekeeping +abstractions. It partly pertains to the drivers usually found in +drivers/clocksource in the kernel tree, but the code may be spread out +across the kernel. + +If you grep through the kernel source you will find a number of architecture- +specific implementations of clock sources, clockevents and several likewise +architecture-specific overrides of the sched_clock() function and some +delay timers. + +To provide timekeeping for your platform, the clock source provides +the basic timeline, whereas clock events shoot interrupts on certain points +on this timeline, providing facilities such as high-resolution timers. +sched_clock() is used for scheduling and timestamping, and delay timers +provide an accurate delay source using hardware counters. + + +Clock sources +------------- + +The purpose of the clock source is to provide a timeline for the system that +tells you where you are in time. For example issuing the command 'date' on +a Linux system will eventually read the clock source to determine exactly +what time it is. + +Typically the clock source is a monotonic, atomic counter which will provide +n bits which count from 0 to 2^(n-1) and then wraps around to 0 and start over. +It will ideally NEVER stop ticking as long as the system is running. It +may stop during system suspend. + +The clock source shall have as high resolution as possible, and the frequency +shall be as stable and correct as possible as compared to a real-world wall +clock. It should not move unpredictably back and forth in time or miss a few +cycles here and there. + +It must be immune to the kind of effects that occur in hardware where e.g. +the counter register is read in two phases on the bus lowest 16 bits first +and the higher 16 bits in a second bus cycle with the counter bits +potentially being updated in between leading to the risk of very strange +values from the counter. + +When the wall-clock accuracy of the clock source isn't satisfactory, there +are various quirks and layers in the timekeeping code for e.g. synchronizing +the user-visible time to RTC clocks in the system or against networked time +servers using NTP, but all they do basically is update an offset against +the clock source, which provides the fundamental timeline for the system. +These measures does not affect the clock source per se, they only adapt the +system to the shortcomings of it. + +The clock source struct shall provide means to translate the provided counter +into a nanosecond value as an unsigned long long (unsigned 64 bit) number. +Since this operation may be invoked very often, doing this in a strict +mathematical sense is not desirable: instead the number is taken as close as +possible to a nanosecond value using only the arithmetic operations +multiply and shift, so in clocksource_cyc2ns() you find: + + ns ~= (clocksource * mult) >> shift + +You will find a number of helper functions in the clock source code intended +to aid in providing these mult and shift values, such as +clocksource_khz2mult(), clocksource_hz2mult() that help determine the +mult factor from a fixed shift, and clocksource_register_hz() and +clocksource_register_khz() which will help out assigning both shift and mult +factors using the frequency of the clock source as the only input. + +For real simple clock sources accessed from a single I/O memory location +there is nowadays even clocksource_mmio_init() which will take a memory +location, bit width, a parameter telling whether the counter in the +register counts up or down, and the timer clock rate, and then conjure all +necessary parameters. + +Since a 32-bit counter at say 100 MHz will wrap around to zero after some 43 +seconds, the code handling the clock source will have to compensate for this. +That is the reason why the clock source struct also contains a 'mask' +member telling how many bits of the source are valid. This way the timekeeping +code knows when the counter will wrap around and can insert the necessary +compensation code on both sides of the wrap point so that the system timeline +remains monotonic. + + +Clock events +------------ + +Clock events are the conceptual reverse of clock sources: they take a +desired time specification value and calculate the values to poke into +hardware timer registers. + +Clock events are orthogonal to clock sources. The same hardware +and register range may be used for the clock event, but it is essentially +a different thing. The hardware driving clock events has to be able to +fire interrupts, so as to trigger events on the system timeline. On an SMP +system, it is ideal (and customary) to have one such event driving timer per +CPU core, so that each core can trigger events independently of any other +core. + +You will notice that the clock event device code is based on the same basic +idea about translating counters to nanoseconds using mult and shift +arithmetic, and you find the same family of helper functions again for +assigning these values. The clock event driver does not need a 'mask' +attribute however: the system will not try to plan events beyond the time +horizon of the clock event. + + +sched_clock() +------------- + +In addition to the clock sources and clock events there is a special weak +function in the kernel called sched_clock(). This function shall return the +number of nanoseconds since the system was started. An architecture may or +may not provide an implementation of sched_clock() on its own. If a local +implementation is not provided, the system jiffy counter will be used as +sched_clock(). + +As the name suggests, sched_clock() is used for scheduling the system, +determining the absolute timeslice for a certain process in the CFS scheduler +for example. It is also used for printk timestamps when you have selected to +include time information in printk for things like bootcharts. + +Compared to clock sources, sched_clock() has to be very fast: it is called +much more often, especially by the scheduler. If you have to do trade-offs +between accuracy compared to the clock source, you may sacrifice accuracy +for speed in sched_clock(). It however requires some of the same basic +characteristics as the clock source, i.e. it should be monotonic. + +The sched_clock() function may wrap only on unsigned long long boundaries, +i.e. after 64 bits. Since this is a nanosecond value this will mean it wraps +after circa 585 years. (For most practical systems this means "never".) + +If an architecture does not provide its own implementation of this function, +it will fall back to using jiffies, making its maximum resolution 1/HZ of the +jiffy frequency for the architecture. This will affect scheduling accuracy +and will likely show up in system benchmarks. + +The clock driving sched_clock() may stop or reset to zero during system +suspend/sleep. This does not matter to the function it serves of scheduling +events on the system. However it may result in interesting timestamps in +printk(). + +The sched_clock() function should be callable in any context, IRQ- and +NMI-safe and return a sane value in any context. + +Some architectures may have a limited set of time sources and lack a nice +counter to derive a 64-bit nanosecond value, so for example on the ARM +architecture, special helper functions have been created to provide a +sched_clock() nanosecond base from a 16- or 32-bit counter. Sometimes the +same counter that is also used as clock source is used for this purpose. + +On SMP systems, it is crucial for performance that sched_clock() can be called +independently on each CPU without any synchronization performance hits. +Some hardware (such as the x86 TSC) will cause the sched_clock() function to +drift between the CPUs on the system. The kernel can work around this by +enabling the CONFIG_HAVE_UNSTABLE_SCHED_CLOCK option. This is another aspect +that makes sched_clock() different from the ordinary clock source. + + +Delay timers (some architectures only) +-------------------------------------- + +On systems with variable CPU frequency, the various kernel delay() functions +will sometimes behave strangely. Basically these delays usually use a hard +loop to delay a certain number of jiffy fractions using a "lpj" (loops per +jiffy) value, calibrated on boot. + +Let's hope that your system is running on maximum frequency when this value +is calibrated: as an effect when the frequency is geared down to half the +full frequency, any delay() will be twice as long. Usually this does not +hurt, as you're commonly requesting that amount of delay *or more*. But +basically the semantics are quite unpredictable on such systems. + +Enter timer-based delays. Using these, a timer read may be used instead of +a hard-coded loop for providing the desired delay. + +This is done by declaring a struct delay_timer and assigning the appropriate +function pointers and rate settings for this delay timer. + +This is available on some architectures like OpenRISC or ARM. diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt index 3f669b9e8852..dd5f916b351d 100644 --- a/Documentation/trace/ftrace-design.txt +++ b/Documentation/trace/ftrace-design.txt @@ -102,30 +102,6 @@ extern void mcount(void); EXPORT_SYMBOL(mcount); -HAVE_FUNCTION_TRACE_MCOUNT_TEST -------------------------------- - -This is an optional optimization for the normal case when tracing is turned off -in the system. If you do not enable this Kconfig option, the common ftrace -code will take care of doing the checking for you. - -To support this feature, you only need to check the function_trace_stop -variable in the mcount function. If it is non-zero, there is no tracing to be -done at all, so you can return. - -This additional pseudo code would simply be: -void mcount(void) -{ - /* save any bare state needed in order to do initial checking */ - -+ if (function_trace_stop) -+ return; - - extern void (*ftrace_trace_function)(unsigned long, unsigned long); - if (ftrace_trace_function != ftrace_stub) -... - - HAVE_FUNCTION_GRAPH_TRACER -------------------------- @@ -328,8 +304,6 @@ void mcount(void) void ftrace_caller(void) { - /* implement HAVE_FUNCTION_TRACE_MCOUNT_TEST if you desire */ - /* save all state needed by the ABI (see paragraph above) */ unsigned long frompc = ...; diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index 2479b2a0c77c..4da42616939f 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -1515,7 +1515,7 @@ Doing the same with chrt -r 5 and function-trace set. <idle>-0 3d.h4 1us+: 0:120:R + [003] 2448: 94:R sleep <idle>-0 3d.h4 2us : ttwu_do_activate.constprop.87 <-try_to_wake_up <idle>-0 3d.h3 3us : check_preempt_curr <-ttwu_do_wakeup - <idle>-0 3d.h3 3us : resched_task <-check_preempt_curr + <idle>-0 3d.h3 3us : resched_curr <-check_preempt_curr <idle>-0 3dNh3 4us : task_woken_rt <-ttwu_do_wakeup <idle>-0 3dNh3 4us : _raw_spin_unlock <-try_to_wake_up <idle>-0 3dNh3 4us : sub_preempt_count <-_raw_spin_unlock diff --git a/Documentation/usb/hotplug.txt b/Documentation/usb/hotplug.txt index 6424b130485c..a80b0e9a7a0b 100644 --- a/Documentation/usb/hotplug.txt +++ b/Documentation/usb/hotplug.txt @@ -105,13 +105,13 @@ macros such as these, and use driver_info to store more information. A short example, for a driver that supports several specific USB devices and their quirks, might have a MODULE_DEVICE_TABLE like this: - static const struct usb_device_id mydriver_id_table = { + static const struct usb_device_id mydriver_id_table[] = { { USB_DEVICE (0x9999, 0xaaaa), driver_info: QUIRK_X }, { USB_DEVICE (0xbbbb, 0x8888), driver_info: QUIRK_Y|QUIRK_Z }, ... { } /* end with an all-zeroes entry */ - } - MODULE_DEVICE_TABLE (usb, mydriver_id_table); + }; + MODULE_DEVICE_TABLE(usb, mydriver_id_table); Most USB device drivers should pass these tables to the USB subsystem as well as to the module management subsystem. Not all, though: some driver @@ -134,7 +134,7 @@ something like this: if exposing any operations through usbdevfs: .ioctl = my_ioctl, */ - } + }; When the USB subsystem knows about a driver's device ID table, it's used when choosing drivers to probe(). The thread doing new device processing checks diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt index 1392b61d6ebe..7b90fe034c4b 100644 --- a/Documentation/usb/power-management.txt +++ b/Documentation/usb/power-management.txt @@ -2,8 +2,27 @@ Alan Stern <stern@rowland.harvard.edu> - October 28, 2010 - + Last-updated: February 2014 + + + Contents: + --------- + * What is Power Management? + * What is Remote Wakeup? + * When is a USB device idle? + * Forms of dynamic PM + * The user interface for dynamic PM + * Changing the default idle-delay time + * Warnings + * The driver interface for Power Management + * The driver interface for autosuspend and autoresume + * Other parts of the driver interface + * Mutual exclusion + * Interaction between dynamic PM and system PM + * xHCI hardware link PM + * USB Port Power Control + * User Interface for Port Power Control + * Suggested Userspace Port Power Policy What is Power Management? @@ -516,3 +535,225 @@ relevant attribute files is usb2_hardware_lpm. driver will enable hardware LPM for the device. You can write y/Y/1 or n/N/0 to the file to enable/disable USB2 hardware LPM manually. This is for test purpose mainly. + + + USB Port Power Control + ---------------------- + +In addition to suspending endpoint devices and enabling hardware +controlled link power management, the USB subsystem also has the +capability to disable power to ports under some conditions. Power is +controlled through Set/ClearPortFeature(PORT_POWER) requests to a hub. +In the case of a root or platform-internal hub the host controller +driver translates PORT_POWER requests into platform firmware (ACPI) +method calls to set the port power state. For more background see the +Linux Plumbers Conference 2012 slides [1] and video [2]: + +Upon receiving a ClearPortFeature(PORT_POWER) request a USB port is +logically off, and may trigger the actual loss of VBUS to the port [3]. +VBUS may be maintained in the case where a hub gangs multiple ports into +a shared power well causing power to remain until all ports in the gang +are turned off. VBUS may also be maintained by hub ports configured for +a charging application. In any event a logically off port will lose +connection with its device, not respond to hotplug events, and not +respond to remote wakeup events*. + +WARNING: turning off a port may result in the inability to hot add a device. +Please see "User Interface for Port Power Control" for details. + +As far as the effect on the device itself it is similar to what a device +goes through during system suspend, i.e. the power session is lost. Any +USB device or driver that misbehaves with system suspend will be +similarly affected by a port power cycle event. For this reason the +implementation shares the same device recovery path (and honors the same +quirks) as the system resume path for the hub. + +[1]: http://dl.dropbox.com/u/96820575/sarah-sharp-lpt-port-power-off2-mini.pdf +[2]: http://linuxplumbers.ubicast.tv/videos/usb-port-power-off-kerneluserspace-api/ +[3]: USB 3.1 Section 10.12 +* wakeup note: if a device is configured to send wakeup events the port + power control implementation will block poweroff attempts on that + port. + + + User Interface for Port Power Control + ------------------------------------- + +The port power control mechanism uses the PM runtime system. Poweroff is +requested by clearing the power/pm_qos_no_power_off flag of the port device +(defaults to 1). If the port is disconnected it will immediately receive a +ClearPortFeature(PORT_POWER) request. Otherwise, it will honor the pm runtime +rules and require the attached child device and all descendants to be suspended. +This mechanism is dependent on the hub advertising port power switching in its +hub descriptor (wHubCharacteristics logical power switching mode field). + +Note, some interface devices/drivers do not support autosuspend. Userspace may +need to unbind the interface drivers before the usb_device will suspend. An +unbound interface device is suspended by default. When unbinding, be careful +to unbind interface drivers, not the driver of the parent usb device. Also, +leave hub interface drivers bound. If the driver for the usb device (not +interface) is unbound the kernel is no longer able to resume the device. If a +hub interface driver is unbound, control of its child ports is lost and all +attached child-devices will disconnect. A good rule of thumb is that if the +'driver/module' link for a device points to /sys/module/usbcore then unbinding +it will interfere with port power control. + +Example of the relevant files for port power control. Note, in this example +these files are relative to a usb hub device (prefix). + + prefix=/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1 + + attached child device + + hub port device + | + hub interface device + | | + v v v + $prefix/3-1:1.0/3-1-port1/device + + $prefix/3-1:1.0/3-1-port1/power/pm_qos_no_power_off + $prefix/3-1:1.0/3-1-port1/device/power/control + $prefix/3-1:1.0/3-1-port1/device/3-1.1:<intf0>/driver/unbind + $prefix/3-1:1.0/3-1-port1/device/3-1.1:<intf1>/driver/unbind + ... + $prefix/3-1:1.0/3-1-port1/device/3-1.1:<intfN>/driver/unbind + +In addition to these files some ports may have a 'peer' link to a port on +another hub. The expectation is that all superspeed ports have a +hi-speed peer. + +$prefix/3-1:1.0/3-1-port1/peer -> ../../../../usb2/2-1/2-1:1.0/2-1-port1 +../../../../usb2/2-1/2-1:1.0/2-1-port1/peer -> ../../../../usb3/3-1/3-1:1.0/3-1-port1 + +Distinct from 'companion ports', or 'ehci/xhci shared switchover ports' +peer ports are simply the hi-speed and superspeed interface pins that +are combined into a single usb3 connector. Peer ports share the same +ancestor XHCI device. + +While a superspeed port is powered off a device may downgrade its +connection and attempt to connect to the hi-speed pins. The +implementation takes steps to prevent this: + +1/ Port suspend is sequenced to guarantee that hi-speed ports are powered-off + before their superspeed peer is permitted to power-off. The implication is + that the setting pm_qos_no_power_off to zero on a superspeed port may not cause + the port to power-off until its highspeed peer has gone to its runtime suspend + state. Userspace must take care to order the suspensions if it wants to + guarantee that a superspeed port will power-off. + +2/ Port resume is sequenced to force a superspeed port to power-on prior to its + highspeed peer. + +3/ Port resume always triggers an attached child device to resume. After a + power session is lost the device may have been removed, or need reset. + Resuming the child device when the parent port regains power resolves those + states and clamps the maximum port power cycle frequency at the rate the child + device can suspend (autosuspend-delay) and resume (reset-resume latency). + +Sysfs files relevant for port power control: + <hubdev-portX>/power/pm_qos_no_power_off: + This writable flag controls the state of an idle port. + Once all children and descendants have suspended the + port may suspend/poweroff provided that + pm_qos_no_power_off is '0'. If pm_qos_no_power_off is + '1' the port will remain active/powered regardless of + the stats of descendants. Defaults to 1. + + <hubdev-portX>/power/runtime_status: + This file reflects whether the port is 'active' (power is on) + or 'suspended' (logically off). There is no indication to + userspace whether VBUS is still supplied. + + <hubdev-portX>/connect_type: + An advisory read-only flag to userspace indicating the + location and connection type of the port. It returns + one of four values 'hotplug', 'hardwired', 'not used', + and 'unknown'. All values, besides unknown, are set by + platform firmware. + + "hotplug" indicates an externally connectable/visible + port on the platform. Typically userspace would choose + to keep such a port powered to handle new device + connection events. + + "hardwired" refers to a port that is not visible but + connectable. Examples are internal ports for USB + bluetooth that can be disconnected via an external + switch or a port with a hardwired USB camera. It is + expected to be safe to allow these ports to suspend + provided pm_qos_no_power_off is coordinated with any + switch that gates connections. Userspace must arrange + for the device to be connected prior to the port + powering off, or to activate the port prior to enabling + connection via a switch. + + "not used" refers to an internal port that is expected + to never have a device connected to it. These may be + empty internal ports, or ports that are not physically + exposed on a platform. Considered safe to be + powered-off at all times. + + "unknown" means platform firmware does not provide + information for this port. Most commonly refers to + external hub ports which should be considered 'hotplug' + for policy decisions. + + NOTE1: since we are relying on the BIOS to get this ACPI + information correct, the USB port descriptions may be + missing or wrong. + + NOTE2: Take care in clearing pm_qos_no_power_off. Once + power is off this port will + not respond to new connect events. + + Once a child device is attached additional constraints are + applied before the port is allowed to poweroff. + + <child>/power/control: + Must be 'auto', and the port will not + power down until <child>/power/runtime_status + reflects the 'suspended' state. Default + value is controlled by child device driver. + + <child>/power/persist: + This defaults to '1' for most devices and indicates if + kernel can persist the device's configuration across a + power session loss (suspend / port-power event). When + this value is '0' (quirky devices), port poweroff is + disabled. + + <child>/driver/unbind: + Wakeup capable devices will block port poweroff. At + this time the only mechanism to clear the usb-internal + wakeup-capability for an interface device is to unbind + its driver. + +Summary of poweroff pre-requisite settings relative to a port device: + + echo 0 > power/pm_qos_no_power_off + echo 0 > peer/power/pm_qos_no_power_off # if it exists + echo auto > power/control # this is the default value + echo auto > <child>/power/control + echo 1 > <child>/power/persist # this is the default value + + Suggested Userspace Port Power Policy + ------------------------------------- + +As noted above userspace needs to be careful and deliberate about what +ports are enabled for poweroff. + +The default configuration is that all ports start with +power/pm_qos_no_power_off set to '1' causing ports to always remain +active. + +Given confidence in the platform firmware's description of the ports +(ACPI _PLD record for a port populates 'connect_type') userspace can +clear pm_qos_no_power_off for all 'not used' ports. The same can be +done for 'hardwired' ports provided poweroff is coordinated with any +connection switch for the port. + +A more aggressive userspace policy is to enable USB port power off for +all ports (set <hubdev-portX>/power/pm_qos_no_power_off to '0') when +some external factor indicates the user has stopped interacting with the +system. For example, a distro may want to enable power off all USB +ports when the screen blanks, and re-power them when the screen becomes +active. Smart phones and tablets may want to power off USB ports when +the user pushes the power button. diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index fc009d0ee7d6..a74eeccfe700 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 @@ -41,3 +41,5 @@ 40 -> TurboSight TBS 6981 [6981:8888] 41 -> TurboSight TBS 6980 [6980:8888] 42 -> Leadtek Winfast PxPVR2200 [107d:6f21] + 43 -> Hauppauge ImpactVCB-e [0070:7133] + 44 -> DViCO FusionHDTV DVB-T Dual Express2 [18ac:db98] diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index 5a3ddcd340d3..bc3351bb48b4 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -77,7 +77,7 @@ 76 -> KWorld PlusTV 340U or UB435-Q (ATSC) (em2870) [1b80:a340] 77 -> EM2874 Leadership ISDBT (em2874) 78 -> PCTV nanoStick T2 290e (em28174) - 79 -> Terratec Cinergy H5 (em2884) [0ccd:10a2,0ccd:10ad,0ccd:10b6] + 79 -> Terratec Cinergy H5 (em2884) [eb1a:2885,0ccd:10a2,0ccd:10ad,0ccd:10b6] 80 -> PCTV DVB-S2 Stick (460e) (em28174) 81 -> Hauppauge WinTV HVR 930C (em2884) [2040:1605] 82 -> Terratec Cinergy HTC Stick (em2884) [0ccd:00b2] diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt index 06cf3ac83631..0f84ce8c9a7b 100644 --- a/Documentation/video4linux/v4l2-controls.txt +++ b/Documentation/video4linux/v4l2-controls.txt @@ -77,9 +77,9 @@ Basic usage for V4L2 and sub-device drivers Where foo->v4l2_dev is of type struct v4l2_device. - Finally, remove all control functions from your v4l2_ioctl_ops: - vidioc_queryctrl, vidioc_querymenu, vidioc_g_ctrl, vidioc_s_ctrl, - vidioc_g_ext_ctrls, vidioc_try_ext_ctrls and vidioc_s_ext_ctrls. + Finally, remove all control functions from your v4l2_ioctl_ops (if any): + vidioc_queryctrl, vidioc_query_ext_ctrl, vidioc_querymenu, vidioc_g_ctrl, + vidioc_s_ctrl, vidioc_g_ext_ctrls, vidioc_try_ext_ctrls and vidioc_s_ext_ctrls. Those are now no longer needed. 1.3.2) For sub-device drivers do this: @@ -258,8 +258,8 @@ The new control value has already been validated, so all you need to do is to actually update the hardware registers. You're done! And this is sufficient for most of the drivers we have. No need -to do any validation of control values, or implement QUERYCTRL/QUERYMENU. And -G/S_CTRL as well as G/TRY/S_EXT_CTRLS are automatically supported. +to do any validation of control values, or implement QUERYCTRL, QUERY_EXT_CTRL +and QUERYMENU. And G/S_CTRL as well as G/TRY/S_EXT_CTRLS are automatically supported. ============================================================================== @@ -288,30 +288,45 @@ of v4l2_device. Accessing Control Values ======================== -The v4l2_ctrl struct contains these two unions: +The following union is used inside the control framework to access control +values: - /* The current control value. */ - union { +union v4l2_ctrl_ptr { + s32 *p_s32; + s64 *p_s64; + char *p_char; + void *p; +}; + +The v4l2_ctrl struct contains these fields that can be used to access both +current and new values: + + s32 val; + struct { s32 val; - s64 val64; - char *string; } cur; - /* The new control value. */ - union { - s32 val; - s64 val64; - char *string; - }; -Within the control ops you can freely use these. The val and val64 speak for -themselves. The string pointers point to character buffers of length + union v4l2_ctrl_ptr p_new; + union v4l2_ctrl_ptr p_cur; + +If the control has a simple s32 type type, then: + + &ctrl->val == ctrl->p_new.p_s32 + &ctrl->cur.val == ctrl->p_cur.p_s32 + +For all other types use ctrl->p_cur.p<something>. Basically the val +and cur.val fields can be considered an alias since these are used so often. + +Within the control ops you can freely use these. The val and cur.val speak for +themselves. The p_char pointers point to character buffers of length ctrl->maximum + 1, and are always 0-terminated. -In most cases 'cur' contains the current cached control value. When you create -a new control this value is made identical to the default value. After calling -v4l2_ctrl_handler_setup() this value is passed to the hardware. It is generally -a good idea to call this function. +Unless the control is marked volatile the p_cur field points to the the +current cached control value. When you create a new control this value is made +identical to the default value. After calling v4l2_ctrl_handler_setup() this +value is passed to the hardware. It is generally a good idea to call this +function. Whenever a new value is set that new value is automatically cached. This means that most drivers do not need to implement the g_volatile_ctrl() op. The @@ -362,8 +377,8 @@ will result in a deadlock since these helpers lock the handler as well. You can also take the handler lock yourself: mutex_lock(&state->ctrl_handler.lock); - printk(KERN_INFO "String value is '%s'\n", ctrl1->cur.string); - printk(KERN_INFO "Integer value is '%s'\n", ctrl2->cur.val); + pr_info("String value is '%s'\n", ctrl1->p_cur.p_char); + pr_info("Integer value is '%s'\n", ctrl2->cur.val); mutex_unlock(&state->ctrl_handler.lock); diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 667a43361706..a11dff07ef71 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -675,11 +675,6 @@ You should also set these fields: video_device is initialized you *do* know which parent PCI device to use and so you set dev_device to the correct PCI device. -- flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework - handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct - v4l2_fh. Eventually this flag will disappear once all drivers use the core - priority handling. But for now it has to be set explicitly. - If you use v4l2_ioctl_ops, then you should set .unlocked_ioctl to video_ioctl2 in your v4l2_file_operations struct. @@ -909,8 +904,7 @@ struct v4l2_fh struct v4l2_fh provides a way to easily keep file handle specific data that is used by the V4L2 framework. New drivers must use struct v4l2_fh -since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY) -if the video_device flag V4L2_FL_USE_FH_PRIO is also set. +since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY). The users of v4l2_fh (in the V4L2 framework, not the driver) know whether a driver uses v4l2_fh as its file->private_data pointer by diff --git a/Documentation/video4linux/v4l2-pci-skeleton.c b/Documentation/video4linux/v4l2-pci-skeleton.c index 46904fe49609..006721e43b2a 100644 --- a/Documentation/video4linux/v4l2-pci-skeleton.c +++ b/Documentation/video4linux/v4l2-pci-skeleton.c @@ -883,11 +883,6 @@ static int skeleton_probe(struct pci_dev *pdev, const struct pci_device_id *ent) vdev->v4l2_dev = &skel->v4l2_dev; /* Supported SDTV standards, if any */ vdev->tvnorms = SKEL_TVNORMS; - /* If this bit is set, then the v4l2 core will provide the support - * for the VIDIOC_G/S_PRIORITY ioctls. This flag will eventually - * go away once all drivers have been converted to use struct v4l2_fh. - */ - set_bit(V4L2_FL_USE_FH_PRIO, &vdev->flags); video_set_drvdata(vdev, skel); ret = video_register_device(vdev, VFL_TYPE_GRABBER, -1); diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 0fe36497642c..68cda1fc3d52 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -297,6 +297,15 @@ struct kvm_regs { __u64 rip, rflags; }; +/* mips */ +struct kvm_regs { + /* out (KVM_GET_REGS) / in (KVM_SET_REGS) */ + __u64 gpr[32]; + __u64 hi; + __u64 lo; + __u64 pc; +}; + 4.12 KVM_SET_REGS @@ -378,7 +387,7 @@ struct kvm_translation { 4.16 KVM_INTERRUPT Capability: basic -Architectures: x86, ppc +Architectures: x86, ppc, mips Type: vcpu ioctl Parameters: struct kvm_interrupt (in) Returns: 0 on success, -1 on error @@ -423,6 +432,11 @@ c) KVM_INTERRUPT_SET_LEVEL Note that any value for 'irq' other than the ones stated above is invalid and incurs unexpected behavior. +MIPS: + +Queues an external interrupt to be injected into the virtual CPU. A negative +interrupt number dequeues the interrupt. + 4.17 KVM_DEBUG_GUEST @@ -512,7 +526,7 @@ struct kvm_cpuid { 4.21 KVM_SET_SIGNAL_MASK Capability: basic -Architectures: x86 +Architectures: all Type: vcpu ioctl Parameters: struct kvm_signal_mask (in) Returns: 0 on success, -1 on error @@ -974,7 +988,7 @@ for vm-wide capabilities. 4.38 KVM_GET_MP_STATE Capability: KVM_CAP_MP_STATE -Architectures: x86, ia64 +Architectures: x86, ia64, s390 Type: vcpu ioctl Parameters: struct kvm_mp_state (out) Returns: 0 on success; -1 on error @@ -988,24 +1002,32 @@ uniprocessor guests). Possible values are: - - KVM_MP_STATE_RUNNABLE: the vcpu is currently running + - KVM_MP_STATE_RUNNABLE: the vcpu is currently running [x86, ia64] - KVM_MP_STATE_UNINITIALIZED: the vcpu is an application processor (AP) - which has not yet received an INIT signal + which has not yet received an INIT signal [x86, + ia64] - KVM_MP_STATE_INIT_RECEIVED: the vcpu has received an INIT signal, and is - now ready for a SIPI + now ready for a SIPI [x86, ia64] - KVM_MP_STATE_HALTED: the vcpu has executed a HLT instruction and - is waiting for an interrupt + is waiting for an interrupt [x86, ia64] - KVM_MP_STATE_SIPI_RECEIVED: the vcpu has just received a SIPI (vector - accessible via KVM_GET_VCPU_EVENTS) + accessible via KVM_GET_VCPU_EVENTS) [x86, ia64] + - KVM_MP_STATE_STOPPED: the vcpu is stopped [s390] + - KVM_MP_STATE_CHECK_STOP: the vcpu is in a special error state [s390] + - KVM_MP_STATE_OPERATING: the vcpu is operating (running or halted) + [s390] + - KVM_MP_STATE_LOAD: the vcpu is in a special load/startup state + [s390] -This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel -irqchip, the multiprocessing state must be maintained by userspace. +On x86 and ia64, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an +in-kernel irqchip, the multiprocessing state must be maintained by userspace on +these architectures. 4.39 KVM_SET_MP_STATE Capability: KVM_CAP_MP_STATE -Architectures: x86, ia64 +Architectures: x86, ia64, s390 Type: vcpu ioctl Parameters: struct kvm_mp_state (in) Returns: 0 on success; -1 on error @@ -1013,8 +1035,9 @@ Returns: 0 on success; -1 on error Sets the vcpu's current "multiprocessing state"; see KVM_GET_MP_STATE for arguments. -This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel -irqchip, the multiprocessing state must be maintained by userspace. +On x86 and ia64, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an +in-kernel irqchip, the multiprocessing state must be maintained by userspace on +these architectures. 4.40 KVM_SET_IDENTITY_MAP_ADDR @@ -1774,122 +1797,151 @@ and architecture specific registers. Each have their own range of operation and their own constants and width. To keep track of the implemented registers, find a list below: - Arch | Register | Width (bits) - | | - PPC | KVM_REG_PPC_HIOR | 64 - PPC | KVM_REG_PPC_IAC1 | 64 - PPC | KVM_REG_PPC_IAC2 | 64 - PPC | KVM_REG_PPC_IAC3 | 64 - PPC | KVM_REG_PPC_IAC4 | 64 - PPC | KVM_REG_PPC_DAC1 | 64 - PPC | KVM_REG_PPC_DAC2 | 64 - PPC | KVM_REG_PPC_DABR | 64 - PPC | KVM_REG_PPC_DSCR | 64 - PPC | KVM_REG_PPC_PURR | 64 - PPC | KVM_REG_PPC_SPURR | 64 - PPC | KVM_REG_PPC_DAR | 64 - PPC | KVM_REG_PPC_DSISR | 32 - PPC | KVM_REG_PPC_AMR | 64 - PPC | KVM_REG_PPC_UAMOR | 64 - PPC | KVM_REG_PPC_MMCR0 | 64 - PPC | KVM_REG_PPC_MMCR1 | 64 - PPC | KVM_REG_PPC_MMCRA | 64 - PPC | KVM_REG_PPC_MMCR2 | 64 - PPC | KVM_REG_PPC_MMCRS | 64 - PPC | KVM_REG_PPC_SIAR | 64 - PPC | KVM_REG_PPC_SDAR | 64 - PPC | KVM_REG_PPC_SIER | 64 - PPC | KVM_REG_PPC_PMC1 | 32 - PPC | KVM_REG_PPC_PMC2 | 32 - PPC | KVM_REG_PPC_PMC3 | 32 - PPC | KVM_REG_PPC_PMC4 | 32 - PPC | KVM_REG_PPC_PMC5 | 32 - PPC | KVM_REG_PPC_PMC6 | 32 - PPC | KVM_REG_PPC_PMC7 | 32 - PPC | KVM_REG_PPC_PMC8 | 32 - PPC | KVM_REG_PPC_FPR0 | 64 + Arch | Register | Width (bits) + | | + PPC | KVM_REG_PPC_HIOR | 64 + PPC | KVM_REG_PPC_IAC1 | 64 + PPC | KVM_REG_PPC_IAC2 | 64 + PPC | KVM_REG_PPC_IAC3 | 64 + PPC | KVM_REG_PPC_IAC4 | 64 + PPC | KVM_REG_PPC_DAC1 | 64 + PPC | KVM_REG_PPC_DAC2 | 64 + PPC | KVM_REG_PPC_DABR | 64 + PPC | KVM_REG_PPC_DSCR | 64 + PPC | KVM_REG_PPC_PURR | 64 + PPC | KVM_REG_PPC_SPURR | 64 + PPC | KVM_REG_PPC_DAR | 64 + PPC | KVM_REG_PPC_DSISR | 32 + PPC | KVM_REG_PPC_AMR | 64 + PPC | KVM_REG_PPC_UAMOR | 64 + PPC | KVM_REG_PPC_MMCR0 | 64 + PPC | KVM_REG_PPC_MMCR1 | 64 + PPC | KVM_REG_PPC_MMCRA | 64 + PPC | KVM_REG_PPC_MMCR2 | 64 + PPC | KVM_REG_PPC_MMCRS | 64 + PPC | KVM_REG_PPC_SIAR | 64 + PPC | KVM_REG_PPC_SDAR | 64 + PPC | KVM_REG_PPC_SIER | 64 + PPC | KVM_REG_PPC_PMC1 | 32 + PPC | KVM_REG_PPC_PMC2 | 32 + PPC | KVM_REG_PPC_PMC3 | 32 + PPC | KVM_REG_PPC_PMC4 | 32 + PPC | KVM_REG_PPC_PMC5 | 32 + PPC | KVM_REG_PPC_PMC6 | 32 + PPC | KVM_REG_PPC_PMC7 | 32 + PPC | KVM_REG_PPC_PMC8 | 32 + PPC | KVM_REG_PPC_FPR0 | 64 + ... + PPC | KVM_REG_PPC_FPR31 | 64 + PPC | KVM_REG_PPC_VR0 | 128 ... - PPC | KVM_REG_PPC_FPR31 | 64 - PPC | KVM_REG_PPC_VR0 | 128 + PPC | KVM_REG_PPC_VR31 | 128 + PPC | KVM_REG_PPC_VSR0 | 128 ... - PPC | KVM_REG_PPC_VR31 | 128 - PPC | KVM_REG_PPC_VSR0 | 128 + PPC | KVM_REG_PPC_VSR31 | 128 + PPC | KVM_REG_PPC_FPSCR | 64 + PPC | KVM_REG_PPC_VSCR | 32 + PPC | KVM_REG_PPC_VPA_ADDR | 64 + PPC | KVM_REG_PPC_VPA_SLB | 128 + PPC | KVM_REG_PPC_VPA_DTL | 128 + PPC | KVM_REG_PPC_EPCR | 32 + PPC | KVM_REG_PPC_EPR | 32 + PPC | KVM_REG_PPC_TCR | 32 + PPC | KVM_REG_PPC_TSR | 32 + PPC | KVM_REG_PPC_OR_TSR | 32 + PPC | KVM_REG_PPC_CLEAR_TSR | 32 + PPC | KVM_REG_PPC_MAS0 | 32 + PPC | KVM_REG_PPC_MAS1 | 32 + PPC | KVM_REG_PPC_MAS2 | 64 + PPC | KVM_REG_PPC_MAS7_3 | 64 + PPC | KVM_REG_PPC_MAS4 | 32 + PPC | KVM_REG_PPC_MAS6 | 32 + PPC | KVM_REG_PPC_MMUCFG | 32 + PPC | KVM_REG_PPC_TLB0CFG | 32 + PPC | KVM_REG_PPC_TLB1CFG | 32 + PPC | KVM_REG_PPC_TLB2CFG | 32 + PPC | KVM_REG_PPC_TLB3CFG | 32 + PPC | KVM_REG_PPC_TLB0PS | 32 + PPC | KVM_REG_PPC_TLB1PS | 32 + PPC | KVM_REG_PPC_TLB2PS | 32 + PPC | KVM_REG_PPC_TLB3PS | 32 + PPC | KVM_REG_PPC_EPTCFG | 32 + PPC | KVM_REG_PPC_ICP_STATE | 64 + PPC | KVM_REG_PPC_TB_OFFSET | 64 + PPC | KVM_REG_PPC_SPMC1 | 32 + PPC | KVM_REG_PPC_SPMC2 | 32 + PPC | KVM_REG_PPC_IAMR | 64 + PPC | KVM_REG_PPC_TFHAR | 64 + PPC | KVM_REG_PPC_TFIAR | 64 + PPC | KVM_REG_PPC_TEXASR | 64 + PPC | KVM_REG_PPC_FSCR | 64 + PPC | KVM_REG_PPC_PSPB | 32 + PPC | KVM_REG_PPC_EBBHR | 64 + PPC | KVM_REG_PPC_EBBRR | 64 + PPC | KVM_REG_PPC_BESCR | 64 + PPC | KVM_REG_PPC_TAR | 64 + PPC | KVM_REG_PPC_DPDES | 64 + PPC | KVM_REG_PPC_DAWR | 64 + PPC | KVM_REG_PPC_DAWRX | 64 + PPC | KVM_REG_PPC_CIABR | 64 + PPC | KVM_REG_PPC_IC | 64 + PPC | KVM_REG_PPC_VTB | 64 + PPC | KVM_REG_PPC_CSIGR | 64 + PPC | KVM_REG_PPC_TACR | 64 + PPC | KVM_REG_PPC_TCSCR | 64 + 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_PPR | 64 + PPC | KVM_REG_PPC_ARCH_COMPAT | 32 + PPC | KVM_REG_PPC_DABRX | 32 + PPC | KVM_REG_PPC_WORT | 64 + PPC | KVM_REG_PPC_TM_GPR0 | 64 ... - PPC | KVM_REG_PPC_VSR31 | 128 - PPC | KVM_REG_PPC_FPSCR | 64 - PPC | KVM_REG_PPC_VSCR | 32 - PPC | KVM_REG_PPC_VPA_ADDR | 64 - PPC | KVM_REG_PPC_VPA_SLB | 128 - PPC | KVM_REG_PPC_VPA_DTL | 128 - PPC | KVM_REG_PPC_EPCR | 32 - PPC | KVM_REG_PPC_EPR | 32 - PPC | KVM_REG_PPC_TCR | 32 - PPC | KVM_REG_PPC_TSR | 32 - PPC | KVM_REG_PPC_OR_TSR | 32 - PPC | KVM_REG_PPC_CLEAR_TSR | 32 - PPC | KVM_REG_PPC_MAS0 | 32 - PPC | KVM_REG_PPC_MAS1 | 32 - PPC | KVM_REG_PPC_MAS2 | 64 - PPC | KVM_REG_PPC_MAS7_3 | 64 - PPC | KVM_REG_PPC_MAS4 | 32 - PPC | KVM_REG_PPC_MAS6 | 32 - PPC | KVM_REG_PPC_MMUCFG | 32 - PPC | KVM_REG_PPC_TLB0CFG | 32 - PPC | KVM_REG_PPC_TLB1CFG | 32 - PPC | KVM_REG_PPC_TLB2CFG | 32 - PPC | KVM_REG_PPC_TLB3CFG | 32 - PPC | KVM_REG_PPC_TLB0PS | 32 - PPC | KVM_REG_PPC_TLB1PS | 32 - PPC | KVM_REG_PPC_TLB2PS | 32 - PPC | KVM_REG_PPC_TLB3PS | 32 - PPC | KVM_REG_PPC_EPTCFG | 32 - PPC | KVM_REG_PPC_ICP_STATE | 64 - PPC | KVM_REG_PPC_TB_OFFSET | 64 - PPC | KVM_REG_PPC_SPMC1 | 32 - PPC | KVM_REG_PPC_SPMC2 | 32 - PPC | KVM_REG_PPC_IAMR | 64 - PPC | KVM_REG_PPC_TFHAR | 64 - PPC | KVM_REG_PPC_TFIAR | 64 - PPC | KVM_REG_PPC_TEXASR | 64 - PPC | KVM_REG_PPC_FSCR | 64 - PPC | KVM_REG_PPC_PSPB | 32 - PPC | KVM_REG_PPC_EBBHR | 64 - PPC | KVM_REG_PPC_EBBRR | 64 - PPC | KVM_REG_PPC_BESCR | 64 - PPC | KVM_REG_PPC_TAR | 64 - PPC | KVM_REG_PPC_DPDES | 64 - PPC | KVM_REG_PPC_DAWR | 64 - PPC | KVM_REG_PPC_DAWRX | 64 - PPC | KVM_REG_PPC_CIABR | 64 - PPC | KVM_REG_PPC_IC | 64 - PPC | KVM_REG_PPC_VTB | 64 - PPC | KVM_REG_PPC_CSIGR | 64 - PPC | KVM_REG_PPC_TACR | 64 - PPC | KVM_REG_PPC_TCSCR | 64 - 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_PPR | 64 - PPC | KVM_REG_PPC_ARCH_COMPAT 32 - PPC | KVM_REG_PPC_DABRX | 32 - PPC | KVM_REG_PPC_WORT | 64 - PPC | KVM_REG_PPC_TM_GPR0 | 64 + PPC | KVM_REG_PPC_TM_GPR31 | 64 + PPC | KVM_REG_PPC_TM_VSR0 | 128 ... - PPC | KVM_REG_PPC_TM_GPR31 | 64 - PPC | KVM_REG_PPC_TM_VSR0 | 128 + PPC | KVM_REG_PPC_TM_VSR63 | 128 + PPC | KVM_REG_PPC_TM_CR | 64 + PPC | KVM_REG_PPC_TM_LR | 64 + PPC | KVM_REG_PPC_TM_CTR | 64 + PPC | KVM_REG_PPC_TM_FPSCR | 64 + PPC | KVM_REG_PPC_TM_AMR | 64 + PPC | KVM_REG_PPC_TM_PPR | 64 + PPC | KVM_REG_PPC_TM_VRSAVE | 64 + PPC | KVM_REG_PPC_TM_VSCR | 32 + PPC | KVM_REG_PPC_TM_DSCR | 64 + PPC | KVM_REG_PPC_TM_TAR | 64 + | | + MIPS | KVM_REG_MIPS_R0 | 64 ... - PPC | KVM_REG_PPC_TM_VSR63 | 128 - PPC | KVM_REG_PPC_TM_CR | 64 - PPC | KVM_REG_PPC_TM_LR | 64 - PPC | KVM_REG_PPC_TM_CTR | 64 - PPC | KVM_REG_PPC_TM_FPSCR | 64 - PPC | KVM_REG_PPC_TM_AMR | 64 - PPC | KVM_REG_PPC_TM_PPR | 64 - PPC | KVM_REG_PPC_TM_VRSAVE | 64 - PPC | KVM_REG_PPC_TM_VSCR | 32 - PPC | KVM_REG_PPC_TM_DSCR | 64 - PPC | KVM_REG_PPC_TM_TAR | 64 + MIPS | KVM_REG_MIPS_R31 | 64 + MIPS | KVM_REG_MIPS_HI | 64 + MIPS | KVM_REG_MIPS_LO | 64 + MIPS | KVM_REG_MIPS_PC | 64 + MIPS | KVM_REG_MIPS_CP0_INDEX | 32 + MIPS | KVM_REG_MIPS_CP0_CONTEXT | 64 + MIPS | KVM_REG_MIPS_CP0_USERLOCAL | 64 + MIPS | KVM_REG_MIPS_CP0_PAGEMASK | 32 + MIPS | KVM_REG_MIPS_CP0_WIRED | 32 + MIPS | KVM_REG_MIPS_CP0_HWRENA | 32 + MIPS | KVM_REG_MIPS_CP0_BADVADDR | 64 + MIPS | KVM_REG_MIPS_CP0_COUNT | 32 + MIPS | KVM_REG_MIPS_CP0_ENTRYHI | 64 + MIPS | KVM_REG_MIPS_CP0_COMPARE | 32 + MIPS | KVM_REG_MIPS_CP0_STATUS | 32 + MIPS | KVM_REG_MIPS_CP0_CAUSE | 32 + MIPS | KVM_REG_MIPS_CP0_EPC | 64 + MIPS | KVM_REG_MIPS_CP0_CONFIG | 32 + MIPS | KVM_REG_MIPS_CP0_CONFIG1 | 32 + MIPS | KVM_REG_MIPS_CP0_CONFIG2 | 32 + MIPS | KVM_REG_MIPS_CP0_CONFIG3 | 32 + MIPS | KVM_REG_MIPS_CP0_CONFIG7 | 32 + MIPS | KVM_REG_MIPS_CP0_ERROREPC | 64 + MIPS | KVM_REG_MIPS_COUNT_CTL | 64 + MIPS | KVM_REG_MIPS_COUNT_RESUME | 64 + MIPS | KVM_REG_MIPS_COUNT_HZ | 64 ARM registers are mapped using the lower 32 bits. The upper 16 of that is the register group type, or coprocessor number: @@ -1928,6 +1980,22 @@ arm64 CCSIDR registers are demultiplexed by CSSELR value: arm64 system registers have the following id bit patterns: 0x6030 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3> + +MIPS registers are mapped using the lower 32 bits. The upper 16 of that is +the register group type: + +MIPS core registers (see above) have the following id bit patterns: + 0x7030 0000 0000 <reg:16> + +MIPS CP0 registers (see KVM_REG_MIPS_CP0_* above) have the following id bit +patterns depending on whether they're 32-bit or 64-bit registers: + 0x7020 0000 0001 00 <reg:5> <sel:3> (32-bit) + 0x7030 0000 0001 00 <reg:5> <sel:3> (64-bit) + +MIPS KVM control registers (see above) have the following id bit patterns: + 0x7030 0000 0002 <reg:16> + + 4.69 KVM_GET_ONE_REG Capability: KVM_CAP_ONE_REG @@ -2415,7 +2483,7 @@ in VCPU matching underlying host. 4.84 KVM_GET_REG_LIST Capability: basic -Architectures: arm, arm64 +Architectures: arm, arm64, mips Type: vcpu ioctl Parameters: struct kvm_reg_list (in/out) Returns: 0 on success; -1 on error @@ -2866,15 +2934,18 @@ The fields in each entry are defined as follows: 6. Capabilities that can be enabled ----------------------------------- -There are certain capabilities that change the behavior of the virtual CPU when -enabled. To enable them, please see section 4.37. Below you can find a list of -capabilities and what their effect on the vCPU is when enabling them. +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. +Below you can find a list of capabilities and what their effect on the vCPU or +the virtual machine 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. + Target: whether this is a per-vcpu or per-vm capability. + Parameters: what parameters are accepted by the capability. Returns: the return value. General error numbers (EBADF, ENOMEM, EINVAL) @@ -2884,6 +2955,7 @@ The following information is provided along with the description: 6.1 KVM_CAP_PPC_OSI Architectures: ppc +Target: vcpu Parameters: none Returns: 0 on success; -1 on error @@ -2898,6 +2970,7 @@ When this capability is enabled, KVM_EXIT_OSI can occur. 6.2 KVM_CAP_PPC_PAPR Architectures: ppc +Target: vcpu Parameters: none Returns: 0 on success; -1 on error @@ -2917,6 +2990,7 @@ When this capability is enabled, KVM_EXIT_PAPR_HCALL can occur. 6.3 KVM_CAP_SW_TLB Architectures: ppc +Target: vcpu Parameters: args[0] is the address of a struct kvm_config_tlb Returns: 0 on success; -1 on error @@ -2959,6 +3033,7 @@ For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV: 6.4 KVM_CAP_S390_CSS_SUPPORT Architectures: s390 +Target: vcpu Parameters: none Returns: 0 on success; -1 on error @@ -2970,9 +3045,13 @@ handled in-kernel, while the other I/O instructions are passed to userspace. When this capability is enabled, KVM_EXIT_S390_TSCH will occur on TEST SUBCHANNEL intercepts. +Note that even though this capability is enabled per-vcpu, the complete +virtual machine is affected. + 6.5 KVM_CAP_PPC_EPR Architectures: ppc +Target: vcpu Parameters: args[0] defines whether the proxy facility is active Returns: 0 on success; -1 on error @@ -2998,7 +3077,17 @@ This capability connects the vcpu to an in-kernel MPIC device. 6.7 KVM_CAP_IRQ_XICS Architectures: ppc +Target: vcpu Parameters: args[0] is the XICS device fd args[1] is the XICS CPU number (server ID) for this vcpu This capability connects the vcpu to an in-kernel XICS device. + +6.8 KVM_CAP_S390_IRQCHIP + +Architectures: s390 +Target: vm +Parameters: none + +This capability enables the in-kernel irqchip for s390. Please refer to +"4.24 KVM_CREATE_IRQCHIP" for details. diff --git a/Documentation/w1/slaves/w1_ds2406 b/Documentation/w1/slaves/w1_ds2406 new file mode 100644 index 000000000000..8137fe6f6c3d --- /dev/null +++ b/Documentation/w1/slaves/w1_ds2406 @@ -0,0 +1,25 @@ +w1_ds2406 kernel driver +======================= + +Supported chips: + * Maxim DS2406 (and other family 0x12) addressable switches + +Author: Scott Alfter <scott@alfter.us> + +Description +----------- + +The w1_ds2406 driver allows connected devices to be switched on and off. +These chips also provide 128 bytes of OTP EPROM, but reading/writing it is +not supported. In TSOC-6 form, the DS2406 provides two switch outputs and +can be provided with power on a dedicated input. In TO-92 form, it provides +one output and uses parasitic power only. + +The driver provides two sysfs files. state is readable; it gives the +current state of each switch, with PIO A in bit 0 and PIO B in bit 1. The +driver ORs this state with 0x30, so shell scripts get an ASCII 0/1/2/3 to +work with. output is writable; bits 0 and 1 control PIO A and B, +respectively. Bits 2-7 are ignored, so it's safe to write ASCII data. + +CRCs are checked on read and write. Failed checks cause an I/O error to be +returned. On a failed write, the switch status is not changed. diff --git a/Documentation/x86/tlb.txt b/Documentation/x86/tlb.txt new file mode 100644 index 000000000000..2b3a82e69151 --- /dev/null +++ b/Documentation/x86/tlb.txt @@ -0,0 +1,75 @@ +When the kernel unmaps or modified the attributes of a range of +memory, it has two choices: + 1. Flush the entire TLB with a two-instruction sequence. This is + a quick operation, but it causes collateral damage: TLB entries + from areas other than the one we are trying to flush will be + destroyed and must be refilled later, at some cost. + 2. Use the invlpg instruction to invalidate a single page at a + time. This could potentialy cost many more instructions, but + it is a much more precise operation, causing no collateral + damage to other TLB entries. + +Which method to do depends on a few things: + 1. The size of the flush being performed. A flush of the entire + address space is obviously better performed by flushing the + entire TLB than doing 2^48/PAGE_SIZE individual flushes. + 2. The contents of the TLB. If the TLB is empty, then there will + be no collateral damage caused by doing the global flush, and + all of the individual flush will have ended up being wasted + work. + 3. The size of the TLB. The larger the TLB, the more collateral + damage we do with a full flush. So, the larger the TLB, the + more attrative an individual flush looks. Data and + instructions have separate TLBs, as do different page sizes. + 4. The microarchitecture. The TLB has become a multi-level + cache on modern CPUs, and the global flushes have become more + expensive relative to single-page flushes. + +There is obviously no way the kernel can know all these things, +especially the contents of the TLB during a given flush. The +sizes of the flush will vary greatly depending on the workload as +well. There is essentially no "right" point to choose. + +You may be doing too many individual invalidations if you see the +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 + +This will cause us to do the global flush for more cases. +Lowering it to 0 will disable the use of the individual flushes. +Setting it to 1 is a very conservative setting and it should +never need to be 0 under normal circumstances. + +Despite the fact that a single individual flush on x86 is +guaranteed to flush a full 2MB [1], hugetlbfs always uses the full +flushes. THP is treated exactly the same as normal memory. + +You might see invlpg inside of flush_tlb_mm_range() show up in +profiles, or you can use the trace_tlb_flush() tracepoints. to +determine how long the flush operations are taking. + +Essentially, you are balancing the cycles you spend doing invlpg +with the cycles that you spend refilling the TLB later. + +You can measure how expensive TLB refills are by using +performance counters and 'perf stat', like this: + +perf stat -e + cpu/event=0x8,umask=0x84,name=dtlb_load_misses_walk_duration/, + cpu/event=0x8,umask=0x82,name=dtlb_load_misses_walk_completed/, + cpu/event=0x49,umask=0x4,name=dtlb_store_misses_walk_duration/, + cpu/event=0x49,umask=0x2,name=dtlb_store_misses_walk_completed/, + cpu/event=0x85,umask=0x4,name=itlb_misses_walk_duration/, + cpu/event=0x85,umask=0x2,name=itlb_misses_walk_completed/ + +That works on an IvyBridge-era CPU (i5-3320M). Different CPUs +may have differently-named counters, but they should at least +be there in some form. You can use pmu-tools 'ocperf list' +(https://github.com/andikleen/pmu-tools) to find the right +counters for a given CPU. + +1. A footnote in Intel's SDM "4.10.4.2 Recommended Invalidation" + says: "One execution of INVLPG is sufficient even for a page + with size greater than 4 KBytes." diff --git a/Documentation/zh_CN/video4linux/v4l2-framework.txt b/Documentation/zh_CN/video4linux/v4l2-framework.txt index 0da95dbaef34..2b828e631e31 100644 --- a/Documentation/zh_CN/video4linux/v4l2-framework.txt +++ b/Documentation/zh_CN/video4linux/v4l2-framework.txt @@ -580,11 +580,6 @@ release()回调必须被设置，且在最后一个 video_device 用户退出之 v4l2_device 无法与特定的 PCI 设备关联，所有没有设置父设备。但当 video_device 配置后，就知道使用哪个父 PCI 设备了。 -- flags：可选。如果你要让框架处理设置 VIDIOC_G/S_PRIORITY ioctls， - 请设置 V4L2_FL_USE_FH_PRIO。这要求你使用 v4l2_fh 结构体。 - 一旦所有驱动使用了核心的优先级处理，最终这个标志将消失。但现在它 - 必须被显式设置。 - 如果你使用 v4l2_ioctl_ops，则应该在 v4l2_file_operations 结构体中 设置 .unlocked_ioctl 指向 video_ioctl2。 @@ -789,7 +784,7 @@ v4l2_fh 结构体 ------------- v4l2_fh 结构体提供一个保存用于 V4L2 框架的文件句柄特定数据的简单方法。 -如果 video_device 的 flag 设置了 V4L2_FL_USE_FH_PRIO 标志，新驱动 +如果 video_device 标志，新驱动 必须使用 v4l2_fh 结构体，因为它也用于实现优先级处理（VIDIOC_G/S_PRIORITY）。 v4l2_fh 的用户（位于 V4l2 框架中，并非驱动）可通过测试 |