diff options
Diffstat (limited to 'Documentation')
730 files changed, 27404 insertions, 5048 deletions
diff --git a/Documentation/ABI/stable/sysfs-bus-usb b/Documentation/ABI/stable/sysfs-bus-usb index a6b6857..e2bc700 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/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu new file mode 100644 index 0000000..33c133e --- /dev/null +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu @@ -0,0 +1,25 @@ +What: /sys/devices/system/cpu/dscr_default +Date: 13-May-2014 +KernelVersion: v3.15.0 +Contact: +Description: Writes are equivalent to writing to + /sys/devices/system/cpu/cpuN/dscr on all CPUs. + Reads return the last written value or 0. + This value is not a global default: it is a way to set + all per-CPU defaults at the same time. +Values: 64 bit unsigned integer (bit field) + +What: /sys/devices/system/cpu/cpu[0-9]+/dscr +Date: 13-May-2014 +KernelVersion: v3.15.0 +Contact: +Description: Default value for the Data Stream Control Register (DSCR) on + a CPU. + This default value is used when the kernel is executing and + for any process that has not set the DSCR itself. + If a process ever sets the DSCR (via direct access to the + SPR) that value will be persisted for that process and used + on any CPU where it executes (overriding the value described + here). + If set by a process it will be inherited by child processes. +Values: 64 bit unsigned integer (bit field) diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget index 37559a0..95a3658 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget +++ b/Documentation/ABI/testing/configfs-usb-gadget @@ -62,6 +62,40 @@ KernelVersion: 3.11 Description: This group contains functions available to this USB gadget. +What: /config/usb-gadget/gadget/functions/<func>.<inst>/interface.<n> +Date: May 2014 +KernelVersion: 3.16 +Description: + This group contains "Feature Descriptors" specific for one + gadget's USB interface or one interface group described + by an IAD. + + The attributes: + + compatible_id - 8-byte string for "Compatible ID" + sub_compatible_id - 8-byte string for "Sub Compatible ID" + +What: /config/usb-gadget/gadget/functions/<func>.<inst>/interface.<n>/<property> +Date: May 2014 +KernelVersion: 3.16 +Description: + This group contains "Extended Property Descriptors" specific for one + gadget's USB interface or one interface group described + by an IAD. + + The attributes: + + type - value 1..7 for interpreting the data + 1: unicode string + 2: unicode string with environment variable + 3: binary + 4: little-endian 32-bit + 5: big-endian 32-bit + 6: unicode string with a symbolic link + 7: multiple unicode strings + data - blob of data to be interpreted depending on + type + What: /config/usb-gadget/gadget/strings Date: Jun 2013 KernelVersion: 3.11 @@ -79,3 +113,14 @@ Description: product - gadget's product description manufacturer - gadget's manufacturer description +What: /config/usb-gadget/gadget/os_desc +Date: May 2014 +KernelVersion: 3.16 +Description: + This group contains "OS String" extension handling attributes. + + use - flag turning "OS Desctiptors" support on/off + b_vendor_code - one-byte value used for custom per-device and + per-interface requests + qw_sign - an identifier to be reported as "OS String" + proper diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index f1c5cc9..d0d0c57 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -23,9 +23,10 @@ Description: [fowner]] lsm: [[subj_user=] [subj_role=] [subj_type=] [obj_user=] [obj_role=] [obj_type=]] - option: [[appraise_type=]] + 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-block-zram b/Documentation/ABI/testing/sysfs-block-zram index 3f0b9ae..70ec992 100644 --- a/Documentation/ABI/testing/sysfs-block-zram +++ b/Documentation/ABI/testing/sysfs-block-zram @@ -43,6 +43,36 @@ Description: The invalid_io file is read-only and specifies the number of non-page-size-aligned I/O requests issued to this device. +What: /sys/block/zram<id>/failed_reads +Date: February 2014 +Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> +Description: + The failed_reads file is read-only and specifies the number of + failed reads happened on this device. + +What: /sys/block/zram<id>/failed_writes +Date: February 2014 +Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> +Description: + The failed_writes file is read-only and specifies the number of + failed writes happened on this device. + +What: /sys/block/zram<id>/max_comp_streams +Date: February 2014 +Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> +Description: + The max_comp_streams file is read-write and specifies the + number of backend's zcomp_strm compression streams (number of + concurrent compress operations). + +What: /sys/block/zram<id>/comp_algorithm +Date: February 2014 +Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> +Description: + The comp_algorithm file is read-write and lets to show + available and selected compression algorithms, change + compression algorithm selection. + What: /sys/block/zram<id>/notify_free Date: August 2010 Contact: Nitin Gupta <ngupta@vflare.org> @@ -53,15 +83,6 @@ Description: is freed. This statistic is applicable only when this disk is being used as a swap disk. -What: /sys/block/zram<id>/discard -Date: August 2010 -Contact: Nitin Gupta <ngupta@vflare.org> -Description: - The discard file is read-only and specifies the number of - discard requests received by this device. These requests - provide information to block device regarding blocks which are - no longer used by filesystem. - What: /sys/block/zram<id>/zero_pages Date: August 2010 Contact: Nitin Gupta <ngupta@vflare.org> diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6e02c50..d760b02 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -114,14 +114,17 @@ What: /sys/bus/iio/devices/iio:deviceX/in_temp_raw What: /sys/bus/iio/devices/iio:deviceX/in_tempX_raw What: /sys/bus/iio/devices/iio:deviceX/in_temp_x_raw What: /sys/bus/iio/devices/iio:deviceX/in_temp_y_raw -What: /sys/bus/iio/devices/iio:deviceX/in_temp_z_raw +What: /sys/bus/iio/devices/iio:deviceX/in_temp_ambient_raw +What: /sys/bus/iio/devices/iio:deviceX/in_temp_object_raw KernelVersion: 2.6.35 Contact: linux-iio@vger.kernel.org Description: Raw (unscaled no bias removal etc.) temperature measurement. If an axis is specified it generally means that the temperature sensor is associated with one part of a compound device (e.g. - a gyroscope axis). Units after application of scale and offset + a gyroscope axis). The ambient and object modifiers distinguish + between ambient (reference) and distant temperature for contact- + less measurements. Units after application of scale and offset are milli degrees Celsius. What: /sys/bus/iio/devices/iio:deviceX/in_tempX_input @@ -210,6 +213,14 @@ Contact: linux-iio@vger.kernel.org Description: Scaled humidity measurement in milli percent. +What: /sys/bus/iio/devices/iio:deviceX/in_X_mean_raw +KernelVersion: 3.5 +Contact: linux-iio@vger.kernel.org +Description: + Averaged raw measurement from channel X. The number of values + used for averaging is device specific. The converting rules for + normal raw values also applies to the averaged raw values. + What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset @@ -249,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 @@ -436,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 @@ -481,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 @@ -527,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 @@ -577,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 @@ -624,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 @@ -679,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 @@ -776,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 @@ -784,6 +863,7 @@ What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en What: /sys/.../iio:deviceX/scan_elements/in_pressure_en +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -799,6 +879,7 @@ What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type What: /sys/.../iio:deviceX/scan_elements/in_pressure_type +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -840,11 +921,16 @@ 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 What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index What: /sys/.../iio:deviceX/scan_elements/in_pressure_index +What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -881,6 +967,38 @@ 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 +KernelVersion: 3.4 +Contact: linux-iio@vger.kernel.org +Description: + Illuminance measurement, units after application of scale + and offset are lux. + +What: /sys/.../iio:deviceX/in_intensityY_raw +What: /sys/.../iio:deviceX/in_intensityY_ir_raw +What: /sys/.../iio:deviceX/in_intensityY_both_raw +KernelVersion: 3.4 +Contact: linux-iio@vger.kernel.org +Description: + Unit-less light intensity. Modifiers both and ir indicate + that measurements contains visible and infrared light + components or just infrared light, respectively. + What: /sys/.../iio:deviceX/in_intensity_red_integration_time What: /sys/.../iio:deviceX/in_intensity_green_integration_time What: /sys/.../iio:deviceX/in_intensity_blue_integration_time @@ -891,3 +1009,22 @@ Contact: linux-iio@vger.kernel.org Description: This attribute is used to get/set the integration time in seconds. + +What: /sys/bus/iio/devices/iio:deviceX/in_rot_quaternion_raw +KernelVersion: 3.15 +Contact: linux-iio@vger.kernel.org +Description: + Raw value of quaternion components using a format + 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-proximity-as3935 b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 new file mode 100644 index 0000000..6708c5e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 @@ -0,0 +1,16 @@ +What /sys/bus/iio/devices/iio:deviceX/in_proximity_raw +Date: March 2014 +KernelVersion: 3.15 +Contact: Matt Ranostay <mranostay@gmail.com> +Description: + Get the current distance in meters of storm (1km steps) + 1000-40000 = distance in meters + +What /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity +Date: March 2014 +KernelVersion: 3.15 +Contact: Matt Ranostay <mranostay@gmail.com> +Description: + Show or set the gain boost of the amp, from 0-31 range. + 18 = indoors (default) + 14 = outdoors 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 0000000..5235e6c --- /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-mdio b/Documentation/ABI/testing/sysfs-bus-mdio index 6349749..491baaf 100644 --- a/Documentation/ABI/testing/sysfs-bus-mdio +++ b/Documentation/ABI/testing/sysfs-bus-mdio @@ -7,3 +7,23 @@ Description: by the device during bus enumeration, encoded in hexadecimal. This ID is used to match the device with the appropriate driver. + +What: /sys/bus/mdio_bus/devices/.../phy_interface +Date: February 2014 +KernelVersion: 3.15 +Contact: netdev@vger.kernel.org +Description: + This attribute contains the PHY interface as configured by the + Ethernet driver during bus enumeration, encoded in string. + This interface mode is used to configure the Ethernet MAC with the + appropriate mode for its data lines to the PHY hardware. + +What: /sys/bus/mdio_bus/devices/.../phy_has_fixups +Date: February 2014 +KernelVersion: 3.15 +Contact: netdev@vger.kernel.org +Description: + This attribute contains the boolean value whether a given PHY + device has had any "fixup" workaround running on it, encoded as + a boolean. This information is provided to help troubleshooting + PHY configurations. diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index a3c5a66..6615fda 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -117,7 +117,7 @@ Description: What: /sys/bus/pci/devices/.../vpd Date: February 2008 -Contact: Ben Hutchings <bhutchings@solarflare.com> +Contact: Ben Hutchings <bwh@kernel.org> Description: A file named vpd in a device directory will be a binary file containing the Vital Product Data for the @@ -250,3 +250,24 @@ Description: valid. For example, writing a 2 to this file when sriov_numvfs is not 0 and not 2 already will return an error. Writing a 10 when the value of sriov_totalvfs is 8 will return an error. + +What: /sys/bus/pci/devices/.../driver_override +Date: April 2014 +Contact: Alex Williamson <alex.williamson@redhat.com> +Description: + This file allows the driver for a device to be specified which + will override standard static and dynamic ID 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 pci-stub > 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-platform b/Documentation/ABI/testing/sysfs-bus-platform new file mode 100644 index 0000000..5172a61 --- /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 0000000..aae68fc --- /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 0000000..6d0a1b4 --- /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 0000000..d6ba8e8 --- /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 0000000..258cc246 --- /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 0000000..0ec8b81 --- /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-class-net b/Documentation/ABI/testing/sysfs-class-net new file mode 100644 index 0000000..d322b05 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-net @@ -0,0 +1,218 @@ +What: /sys/class/net/<iface>/name_assign_type +Date: July 2014 +KernelVersion: 3.17 +Contact: netdev@vger.kernel.org +Description: + Indicates the name assignment type. Possible values are: + 1: enumerated by the kernel, possibly in an unpredictable way + 2: predictably named by the kernel + 3: named by userspace + 4: renamed + +What: /sys/class/net/<iface>/addr_assign_type +Date: July 2010 +KernelVersion: 3.2 +Contact: netdev@vger.kernel.org +Description: + Indicates the address assignment type. Possible values are: + 0: permanent address + 1: randomly generated + 2: stolen from another device + 3: set using dev_set_mac_address + +What: /sys/class/net/<iface>/addr_len +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the hardware address size in bytes. + Values vary based on the lower-level protocol used by the + interface (Ethernet, FDDI, ATM, IEEE 802.15.4...). See + include/uapi/linux/if_*.h for actual values. + +What: /sys/class/net/<iface>/address +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Hardware address currently assigned to this interface. + Format is a string, e.g: 00:11:22:33:44:55 for an Ethernet MAC + address. + +What: /sys/class/net/<iface>/broadcast +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Hardware broadcast address for this interface. Format is a + string, e.g: ff:ff:ff:ff:ff:ff for an Ethernet broadcast MAC + address. + +What: /sys/class/net/<iface>/carrier +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the current physical link state of the interface. + Posssible values are: + 0: physical link is down + 1: physical link is up + + Note: some special devices, e.g: bonding and team drivers will + allow this attribute to be written to force a link state for + operating correctly and designating another fallback interface. + +What: /sys/class/net/<iface>/dev_id +Date: April 2008 +KernelVersion: 2.6.26 +Contact: netdev@vger.kernel.org +Description: + Indicates the device unique identifier. Format is an hexadecimal + value. This is used to disambiguate interfaces which might be + stacked (e.g: VLAN interfaces) but still have the same MAC + address as their parent device. + +What: /sys/class/net/<iface>/dormant +Date: March 2006 +KernelVersion: 2.6.17 +Contact: netdev@vger.kernel.org +Description: + Indicates whether the interface is in dormant state. Possible + values are: + 0: interface is not dormant + 1: interface is dormant + + This attribute can be used by supplicant software to signal that + the device is not usable unless some supplicant-based + authentication is performed (e.g: 802.1x). 'link_mode' attribute + will also reflect the dormant state. + +What: /sys/clas/net/<iface>/duplex +Date: October 2009 +KernelVersion: 2.6.33 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface latest or current duplex value. Possible + values are: + half: half duplex + full: full duplex + + Note: This attribute is only valid for interfaces that implement + the ethtool get_settings method (mostly Ethernet). + +What: /sys/class/net/<iface>/flags +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface flags as a bitmask in hexadecimal. See + include/uapi/linux/if.h for a list of all possible values and + the flags semantics. + +What: /sys/class/net/<iface>/ifalias +Date: September 2008 +KernelVersion: 2.6.28 +Contact: netdev@vger.kernel.org +Description: + Indicates/stores an interface alias name as a string. This can + be used for system management purposes. + +What: /sys/class/net/<iface>/ifindex +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the system-wide interface unique index identifier as a + decimal number. This attribute is used for mapping an interface + identifier to an interface name. It is used throughout the + networking stack for specifying the interface specific + requests/events. + +What: /sys/class/net/<iface>/iflink +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the system-wide interface unique index identifier a + the interface is linked to. Format is decimal. This attribute is + used to resolve interfaces chaining, linking and stacking. + Physical interfaces have the same 'ifindex' and 'iflink' values. + +What: /sys/class/net/<iface>/link_mode +Date: March 2006 +KernelVersion: 2.6.17 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface link mode, as a decimal number. This + attribute should be used in conjunction with 'dormant' attribute + to determine the interface usability. Possible values: + 0: default link mode + 1: dormant link mode + +What: /sys/class/net/<iface>/mtu +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface currently configured MTU value, in + bytes, and in decimal format. Specific values depends on the + lower-level interface protocol used. Ethernet devices will show + a 'mtu' attribute value of 1500 unless changed. + +What: /sys/calss/net/<iface>/netdev_group +Date: January 2011 +KernelVersion: 2.6.39 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface network device group, as a decimal + integer. Default value is 0 which corresponds to the initial + network devices group. The group can be changed to affect + routing decisions (see: net/ipv4/fib_rules and + net/ipv6/fib6_rules.c). + +What: /sys/class/net/<iface>/operstate +Date: March 2006 +KernelVersion: 2.6.17 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface RFC2863 operational state as a string. + Possible values are: + "unknown", "notpresent", "down", "lowerlayerdown", "testing", + "dormant", "up". + +What: /sys/class/net/<iface>/phys_port_id +Date: July 2013 +KernelVersion: 3.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface unique physical port identifier within + the NIC, as a string. + +What: /sys/class/net/<iface>/speed +Date: October 2009 +KernelVersion: 2.6.33 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface latest or current speed value. Value is + an integer representing the link speed in Mbits/sec. + + Note: this attribute is only valid for interfaces that implement + the ethtool get_settings method (mostly Ethernet ). + +What: /sys/class/net/<iface>/tx_queue_len +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface transmit queue len in number of packets, + as an integer value. Value depend on the type of interface, + Ethernet network adapters have a default value of 1000 unless + configured otherwise + +What: /sys/class/net/<iface>/type +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface protocol type as a decimal value. See + include/uapi/linux/if_arp.h for all possible values. diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm new file mode 100644 index 0000000..5cedf72d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm @@ -0,0 +1,149 @@ +What: /sys/class/net/<iface>/cdc_ncm/min_tx_pkt +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + The driver will pad NCM Transfer Blocks (NTBs) longer + than this to tx_max, allowing the device to receive + tx_max sized frames with no terminating short + packet. NTBs shorter than this limit are transmitted + as-is, without any padding, and are terminated with a + short USB packet. + + Padding to tx_max allows the driver to transmit NTBs + back-to-back without any interleaving short USB + packets. This reduces the number of short packet + interrupts in the device, and represents a tradeoff + between USB bus bandwidth and device DMA optimization. + + Set to 0 to pad all frames. Set greater than tx_max to + disable all padding. + +What: /sys/class/net/<iface>/cdc_ncm/rx_max +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + The maximum NTB size for RX. Cannot exceed the + maximum value supported by the device. Must allow at + least one max sized datagram plus headers. + + The actual limits are device dependent. See + dwNtbInMaxSize. + + Note: Some devices will silently ignore changes to + this value, resulting in oversized NTBs and + corresponding framing errors. + +What: /sys/class/net/<iface>/cdc_ncm/tx_max +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + The maximum NTB size for TX. Cannot exceed the + maximum value supported by the device. Must allow at + least one max sized datagram plus headers. + + The actual limits are device dependent. See + dwNtbOutMaxSize. + +What: /sys/class/net/<iface>/cdc_ncm/tx_timer_usecs +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + Datagram aggregation timeout in µs. The driver will + wait up to 3 times this timeout for more datagrams to + aggregate before transmitting an NTB frame. + + Valid range: 5 to 4000000 + + Set to 0 to disable aggregation. + +The following read-only attributes all represent fields of the +structure defined in section 6.2.1 "GetNtbParameters" of "Universal +Serial Bus Communications Class Subclass Specifications for Network +Control Model Devices" (CDC NCM), Revision 1.0 (Errata 1), November +24, 2010 from USB Implementers Forum, Inc. The descriptions are +quoted from table 6-3 of CDC NCM: "NTB Parameter Structure". + +What: /sys/class/net/<iface>/cdc_ncm/bmNtbFormatsSupported +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + Bit 0: 16-bit NTB supported (set to 1) + Bit 1: 32-bit NTB supported + Bits 2 – 15: reserved (reset to zero; must be ignored by host) + +What: /sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + IN NTB Maximum Size in bytes + +What: /sys/class/net/<iface>/cdc_ncm/wNdpInDivisor +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + Divisor used for IN NTB Datagram payload alignment + +What: /sys/class/net/<iface>/cdc_ncm/wNdpInPayloadRemainder +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + Remainder used to align input datagram payload within + the NTB: (Payload Offset) mod (wNdpInDivisor) = + wNdpInPayloadRemainder + +What: /sys/class/net/<iface>/cdc_ncm/wNdpInAlignment +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + NDP alignment modulus for NTBs on the IN pipe. Shall + be a power of 2, and shall be at least 4. + +What: /sys/class/net/<iface>/cdc_ncm/dwNtbOutMaxSize +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + OUT NTB Maximum Size + +What: /sys/class/net/<iface>/cdc_ncm/wNdpOutDivisor +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + OUT NTB Datagram alignment modulus + +What: /sys/class/net/<iface>/cdc_ncm/wNdpOutPayloadRemainder +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + Remainder used to align output datagram payload + offsets within the NTB: Padding, shall be transmitted + as zero by function, and ignored by host. (Payload + Offset) mod (wNdpOutDivisor) = wNdpOutPayloadRemainder + +What: /sys/class/net/<iface>/cdc_ncm/wNdpOutAlignment +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + NDP alignment modulus for use in NTBs on the OUT + pipe. Shall be a power of 2, and shall be at least 4. + +What: /sys/class/net/<iface>/cdc_ncm/wNtbOutMaxDatagrams +Date: May 2014 +KernelVersion: 3.16 +Contact: Bjørn Mork <bjorn@mork.no> +Description: + Maximum number of datagrams that the host may pack + into a single OUT NTB. Zero means that the device + imposes no limit. diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh index 4793d3d..c464062 100644 --- a/Documentation/ABI/testing/sysfs-class-net-mesh +++ b/Documentation/ABI/testing/sysfs-class-net-mesh @@ -76,6 +76,15 @@ Description: is used to classify clients as "isolated" by the Extended Isolation feature. +What: /sys/class/net/<mesh_iface>/mesh/multicast_mode +Date: Feb 2014 +Contact: Linus Lüssing <linus.luessing@web.de> +Description: + Indicates whether multicast optimizations are enabled + or disabled. If set to zero then all nodes in the + mesh are going to use classic flooding for any + multicast packet with no optimizations. + What: /sys/class/net/<mesh_iface>/mesh/network_coding Date: Nov 2012 Contact: Martin Hundeboll <martin@hundeboll.net> diff --git a/Documentation/ABI/testing/sysfs-class-net-queues b/Documentation/ABI/testing/sysfs-class-net-queues new file mode 100644 index 0000000..5e9aeb9 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-net-queues @@ -0,0 +1,79 @@ +What: /sys/class/<iface>/queues/rx-<queue>/rps_cpus +Date: March 2010 +KernelVersion: 2.6.35 +Contact: netdev@vger.kernel.org +Description: + Mask of the CPU(s) currently enabled to participate into the + Receive Packet Steering packet processing flow for this + network device queue. Possible values depend on the number + of available CPU(s) in the system. + +What: /sys/class/<iface>/queues/rx-<queue>/rps_flow_cnt +Date: April 2010 +KernelVersion: 2.6.35 +Contact: netdev@vger.kernel.org +Description: + Number of Receive Packet Steering flows being currently + processed by this particular network device receive queue. + +What: /sys/class/<iface>/queues/tx-<queue>/tx_timeout +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of transmit timeout events seen by this + network interface transmit queue. + +What: /sys/class/<iface>/queues/tx-<queue>/xps_cpus +Date: November 2010 +KernelVersion: 2.6.38 +Contact: netdev@vger.kernel.org +Description: + Mask of the CPU(s) currently enabled to participate into the + Transmit Packet Steering packet processing flow for this + network device transmit queue. Possible vaules depend on the + number of available CPU(s) in the system. + +What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the hold time in milliseconds to measure the slack + of this particular network device transmit queue. + Default value is 1000. + +What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/inflight +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of bytes (objects) in flight on this + network device transmit queue. + +What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the current limit of bytes allowed to be queued + on this network device transmit queue. This value is clamped + to be within the bounds defined by limit_max and limit_min. + +What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit_max +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the absolute maximum limit of bytes allowed to be + queued on this network device transmit queue. See + include/linux/dynamic_queue_limits.h for the default value. + +What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit_min +Date: November 2011 +KernelVersion: 3.3 +Contact: netdev@vger.kernel.org +Description: + Indicates the absolute minimum limit of bytes allowed to be + queued on this network device transmit queue. Default value is + 0. diff --git a/Documentation/ABI/testing/sysfs-class-net-statistics b/Documentation/ABI/testing/sysfs-class-net-statistics new file mode 100644 index 0000000..397118d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-net-statistics @@ -0,0 +1,201 @@ +What: /sys/class/<iface>/statistics/collisions +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of collisions seen by this network device. + This value might not be relevant with all MAC layers. + +What: /sys/class/<iface>/statistics/multicast +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of multicast packets received by this + network device. + +What: /sys/class/<iface>/statistics/rx_bytes +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of bytes received by this network device. + See the network driver for the exact meaning of when this + value is incremented. + +What: /sys/class/<iface>/statistics/rx_compressed +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of compressed packets received by this + network device. This value might only be relevant for interfaces + that support packet compression (e.g: PPP). + +What: /sys/class/<iface>/statistics/rx_crc_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets received with a CRC (FCS) error + by this network device. Note that the specific meaning might + depend on the MAC layer used by the interface. + +What: /sys/class/<iface>/statistics/rx_dropped +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets received by the network device + but dropped, that are not forwarded to the upper layers for + packet processing. See the network driver for the exact + meaning of this value. + +What: /sys/class/<iface>/statistics/rx_fifo_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of receive FIFO errors seen by this + network device. See the network driver for the exact + meaning of this value. + +What: /sys/class/<iface>/statistics/rx_frame_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of received frames with error, such as + alignment errors. Note that the specific meaning depends on + on the MAC layer protocol used. See the network driver for + the exact meaning of this value. + +What: /sys/class/<iface>/statistics/rx_length_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of received error packet with a length + error, oversized or undersized. See the network driver for the + exact meaning of this value. + +What: /sys/class/<iface>/statistics/rx_missed_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of received packets that have been missed + due to lack of capacity in the receive side. See the network + driver for the exact meaning of this value. + +What: /sys/class/<iface>/statistics/rx_over_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of received packets that are oversized + compared to what the network device is configured to accept + (e.g: larger than MTU). See the network driver for the exact + meaning of this value. + +What: /sys/class/<iface>/statistics/rx_packets +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the total number of good packets received by this + network device. + +What: /sys/class/<iface>/statistics/tx_aborted_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets that have been aborted + during transmission by a network device (e.g: because of + a medium collision). See the network driver for the exact + meaning of this value. + +What: /sys/class/<iface>/statistics/tx_bytes +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of bytes transmitted by a network + device. See the network driver for the exact meaning of this + value, in particular whether this accounts for all successfully + transmitted packets or all packets that have been queued for + transmission. + +What: /sys/class/<iface>/statistics/tx_carrier_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets that could not be transmitted + because of carrier errors (e.g: physical link down). See the + network driver for the exact meaning of this value. + +What: /sys/class/<iface>/statistics/tx_compressed +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of transmitted compressed packets. Note + this might only be relevant for devices that support + compression (e.g: PPP). + +What: /sys/class/<iface>/statistics/tx_dropped +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets dropped during transmission. + See the driver for the exact reasons as to why the packets were + dropped. + +What: /sys/class/<iface>/statistics/tx_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets in error during transmission by + a network device. See the driver for the exact reasons as to + why the packets were dropped. + +What: /sys/class/<iface>/statistics/tx_fifo_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets having caused a transmit + FIFO error. See the driver for the exact reasons as to why the + packets were dropped. + +What: /sys/class/<iface>/statistics/tx_heartbeat_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets transmitted that have been + reported as heartbeat errors. See the driver for the exact + reasons as to why the packets were dropped. + +What: /sys/class/<iface>/statistics/tx_packets +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets transmitted by a network + device. See the driver for whether this reports the number of all + attempted or successful transmissions. + +What: /sys/class/<iface>/statistics/tx_window_errors +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the number of packets not successfully transmitted + due to a window collision. The specific meaning depends on the + MAC layer used. On Ethernet this is usually used to report + late collisions errors. diff --git a/Documentation/ABI/testing/sysfs-class-rc b/Documentation/ABI/testing/sysfs-class-rc new file mode 100644 index 0000000..b65674d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-rc @@ -0,0 +1,111 @@ +What: /sys/class/rc/ +Date: Apr 2010 +KernelVersion: 2.6.35 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + The rc/ class sub-directory belongs to the Remote Controller + core and provides a sysfs interface for configuring infrared + remote controller receivers. + +What: /sys/class/rc/rcN/ +Date: Apr 2010 +KernelVersion: 2.6.35 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + A /sys/class/rc/rcN directory is created for each remote + control receiver device where N is the number of the receiver. + +What: /sys/class/rc/rcN/protocols +Date: Jun 2010 +KernelVersion: 2.6.36 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Reading this file returns a list of available protocols, + something like: + "rc5 [rc6] nec jvc [sony]" + Enabled protocols are shown in [] brackets. + Writing "+proto" will add a protocol to the list of enabled + protocols. + Writing "-proto" will remove a protocol from the list of enabled + protocols. + Writing "proto" will enable only "proto". + Writing "none" will disable all protocols. + Write fails with EINVAL if an invalid protocol combination or + unknown protocol name is used. + +What: /sys/class/rc/rcN/filter +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Sets the scancode filter expected value. + Use in combination with /sys/class/rc/rcN/filter_mask to set the + expected value of the bits set in the filter mask. + If the hardware supports it then scancodes which do not match + the filter will be ignored. Otherwise the write will fail with + an error. + This value may be reset to 0 if the current protocol is altered. + +What: /sys/class/rc/rcN/filter_mask +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Sets the scancode filter mask of bits to compare. + Use in combination with /sys/class/rc/rcN/filter to set the bits + of the scancode which should be compared against the expected + value. A value of 0 disables the filter to allow all valid + scancodes to be processed. + If the hardware supports it then scancodes which do not match + the filter will be ignored. Otherwise the write will fail with + an error. + This value may be reset to 0 if the current protocol is altered. + +What: /sys/class/rc/rcN/wakeup_protocols +Date: Feb 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Reading this file returns a list of available protocols to use + for the wakeup filter, something like: + "rc5 rc6 nec jvc [sony]" + The enabled wakeup protocol is shown in [] brackets. + Writing "+proto" will add a protocol to the list of enabled + wakeup protocols. + Writing "-proto" will remove a protocol from the list of enabled + wakeup protocols. + Writing "proto" will use "proto" for wakeup events. + Writing "none" will disable wakeup. + Write fails with EINVAL if an invalid protocol combination or + unknown protocol name is used, or if wakeup is not supported by + the hardware. + +What: /sys/class/rc/rcN/wakeup_filter +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Sets the scancode wakeup filter expected value. + Use in combination with /sys/class/rc/rcN/wakeup_filter_mask to + set the expected value of the bits set in the wakeup filter mask + to trigger a system wake event. + If the hardware supports it and wakeup_filter_mask is not 0 then + scancodes which match the filter will wake the system from e.g. + suspend to RAM or power off. + Otherwise the write will fail with an error. + This value may be reset to 0 if the wakeup protocol is altered. + +What: /sys/class/rc/rcN/wakeup_filter_mask +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Sets the scancode wakeup filter mask of bits to compare. + Use in combination with /sys/class/rc/rcN/wakeup_filter to set + the bits of the scancode which should be compared against the + expected value to trigger a system wake event. + If the hardware supports it and wakeup_filter_mask is not 0 then + scancodes which match the filter will wake the system from e.g. + suspend to RAM or power off. + Otherwise the write will fail with an error. + This value may be reset to 0 if the wakeup protocol is altered. diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 7dbf96b..676fdf5 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -83,8 +83,10 @@ Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../wakeup_count attribute contains the number of signaled wakeup events associated with the device. This - attribute is read-only. If the device is not enabled to wake up + attribute is read-only. If the device is not capable to wake up the system from sleep states, this attribute is not present. + If the device is not enabled to wake up the system from sleep + states, this attribute is empty. What: /sys/devices/.../power/wakeup_active_count Date: September 2010 @@ -93,8 +95,10 @@ Description: The /sys/devices/.../wakeup_active_count attribute contains the number of times the processing of wakeup events associated with the device was completed (at the kernel level). This attribute - is read-only. If the device is not enabled to wake up the - system from sleep states, this attribute is not present. + is read-only. If the device is not capable to wake up the + system from sleep states, this attribute is not present. If + the device is not enabled to wake up the system from sleep + states, this attribute is empty. What: /sys/devices/.../power/wakeup_abort_count Date: February 2012 @@ -104,8 +108,9 @@ Description: number of times the processing of a wakeup event associated with the device might have aborted system transition into a sleep state in progress. This attribute is read-only. If the device - is not enabled to wake up the system from sleep states, this - attribute is not present. + is not capable to wake up the system from sleep states, this + attribute is not present. If the device is not enabled to wake + up the system from sleep states, this attribute is empty. What: /sys/devices/.../power/wakeup_expire_count Date: February 2012 @@ -114,8 +119,10 @@ Description: The /sys/devices/.../wakeup_expire_count attribute contains the number of times a wakeup event associated with the device has been reported with a timeout that expired. This attribute is - read-only. If the device is not enabled to wake up the system - from sleep states, this attribute is not present. + read-only. If the device is not capable to wake up the system + from sleep states, this attribute is not present. If the + device is not enabled to wake up the system from sleep states, + this attribute is empty. What: /sys/devices/.../power/wakeup_active Date: September 2010 @@ -124,8 +131,10 @@ Description: The /sys/devices/.../wakeup_active attribute contains either 1, or 0, depending on whether or not a wakeup event associated with the device is being processed (1). This attribute is read-only. - If the device is not enabled to wake up the system from sleep - states, this attribute is not present. + If the device is not capable to wake up the system from sleep + states, this attribute is not present. If the device is not + enabled to wake up the system from sleep states, this attribute + is empty. What: /sys/devices/.../power/wakeup_total_time_ms Date: September 2010 @@ -134,8 +143,9 @@ Description: The /sys/devices/.../wakeup_total_time_ms attribute contains the total time of processing wakeup events associated with the device, in milliseconds. This attribute is read-only. If the - device is not enabled to wake up the system from sleep states, - this attribute is not present. + device is not capable to wake up the system from sleep states, + this attribute is not present. If the device is not enabled to + wake up the system from sleep states, this attribute is empty. What: /sys/devices/.../power/wakeup_max_time_ms Date: September 2010 @@ -144,8 +154,10 @@ Description: The /sys/devices/.../wakeup_max_time_ms attribute contains the maximum time of processing a single wakeup event associated with the device, in milliseconds. This attribute is read-only. - If the device is not enabled to wake up the system from sleep - states, this attribute is not present. + If the device is not capable to wake up the system from sleep + states, this attribute is not present. If the device is not + enabled to wake up the system from sleep states, this attribute + is empty. What: /sys/devices/.../power/wakeup_last_time_ms Date: September 2010 @@ -156,7 +168,8 @@ Description: signaling the last wakeup event associated with the device, in milliseconds. This attribute is read-only. If the device is not enabled to wake up the system from sleep states, this - attribute is not present. + attribute is not present. If the device is not enabled to wake + up the system from sleep states, this attribute is empty. What: /sys/devices/.../power/wakeup_prevent_sleep_time_ms Date: February 2012 @@ -165,9 +178,10 @@ Description: The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute contains the total time the device has been preventing opportunistic transitions to sleep states from occurring. - This attribute is read-only. If the device is not enabled to + This attribute is read-only. If the device is not capable to wake up the system from sleep states, this attribute is not - present. + present. If the device is not enabled to wake up the system + from sleep states, this attribute is empty. What: /sys/devices/.../power/autosuspend_delay_ms Date: September 2010 diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index d5a0d33..acb9bfc 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -128,7 +128,7 @@ Description: Discover cpuidle policy and mechanism What: /sys/devices/system/cpu/cpu#/cpufreq/* Date: pre-git history -Contact: cpufreq@vger.kernel.org +Contact: linux-pm@vger.kernel.org Description: Discover and change clock speed of CPUs Clock scaling allows you to change the clock speed of the @@ -146,7 +146,7 @@ Description: Discover and change clock speed of CPUs What: /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus Date: June 2013 -Contact: cpufreq@vger.kernel.org +Contact: linux-pm@vger.kernel.org Description: Discover CPUs in the same CPU frequency coordination domain freqdomain_cpus is the list of CPUs (online+offline) that share diff --git a/Documentation/ABI/testing/sysfs-driver-genwqe b/Documentation/ABI/testing/sysfs-driver-genwqe index 1870737..64ac6d5 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-driver-hid-lenovo-tpkbd b/Documentation/ABI/testing/sysfs-driver-hid-lenovo index 57b92cb..53a0725 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-lenovo-tpkbd +++ b/Documentation/ABI/testing/sysfs-driver-hid-lenovo @@ -4,18 +4,21 @@ Contact: linux-input@vger.kernel.org Description: This controls if mouse clicks should be generated if the trackpoint is quickly pressed. How fast this press has to be is being controlled by press_speed. Values are 0 or 1. + Applies to Thinkpad USB Keyboard with TrackPoint. What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/dragging Date: July 2011 Contact: linux-input@vger.kernel.org Description: If this setting is enabled, it is possible to do dragging by pressing the trackpoint. This requires press_to_select to be enabled. Values are 0 or 1. + Applies to Thinkpad USB Keyboard with TrackPoint. What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/release_to_select Date: July 2011 Contact: linux-input@vger.kernel.org Description: For details regarding this setting please refer to http://www.pc.ibm.com/ww/healthycomputing/trkpntb.html Values are 0 or 1. + Applies to Thinkpad USB Keyboard with TrackPoint. What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/select_right Date: July 2011 @@ -23,16 +26,25 @@ Contact: linux-input@vger.kernel.org Description: This setting controls if the mouse click events generated by pressing the trackpoint (if press_to_select is enabled) generate a left or right mouse button click. Values are 0 or 1. + Applies to Thinkpad USB Keyboard with TrackPoint. What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/sensitivity Date: July 2011 Contact: linux-input@vger.kernel.org Description: This file contains the trackpoint sensitivity. Values are decimal integers from 1 (lowest sensitivity) to 255 (highest sensitivity). + Applies to Thinkpad USB Keyboard with TrackPoint. What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_speed Date: July 2011 Contact: linux-input@vger.kernel.org Description: This setting controls how fast the trackpoint needs to be pressed to generate a mouse click if press_to_select is enabled. Values are decimal integers from 1 (slowest) to 255 (fastest). + Applies to Thinkpad USB Keyboard with TrackPoint. +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/fn_lock +Date: July 2014 +Contact: linux-input@vger.kernel.org +Description: This setting controls whether Fn Lock is enabled on the keyboard (i.e. if F1 is Mute or F1) + Values are 0 or 1 + Applies to ThinkPad Compact (USB|Bluetooth) Keyboard with TrackPoint. diff --git a/Documentation/ABI/testing/sysfs-driver-hid-thingm b/Documentation/ABI/testing/sysfs-driver-hid-thingm deleted file mode 100644 index abcffee..0000000 --- a/Documentation/ABI/testing/sysfs-driver-hid-thingm +++ /dev/null @@ -1,23 +0,0 @@ -What: /sys/class/leds/blink1::<serial>/rgb -Date: January 2013 -Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com> -Description: The ThingM blink1 is an USB RGB LED. The color notation is - 3-byte hexadecimal. Read this attribute to get the last set - color. Write the 24-bit hexadecimal color to change the current - LED color. The default color is full white (0xFFFFFF). - For instance, set the color to green with: echo 00FF00 > rgb - -What: /sys/class/leds/blink1::<serial>/fade -Date: January 2013 -Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com> -Description: This attribute allows to set a fade time in milliseconds for - the next color change. Read the attribute to know the current - fade time. The default value is set to 0 (no fade time). For - instance, set a fade time of 2 seconds with: echo 2000 > fade - -What: /sys/class/leds/blink1::<serial>/play -Date: January 2013 -Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com> -Description: This attribute is used to play/pause the light patterns. Write 1 - to start playing, 0 to stop. Reading this attribute returns the - current playing status. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 32b0809..62dd725 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -55,3 +55,15 @@ Date: January 2014 Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> Description: Controls the number of trials to find a victim segment. + +What: /sys/fs/f2fs/<disk>/dir_level +Date: March 2014 +Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> +Description: + Controls the directory level for large directory. + +What: /sys/fs/f2fs/<disk>/ram_thresh +Date: March 2014 +Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> +Description: + Controls the memory footprint used by f2fs. diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module index 47064c2..0aac02e 100644 --- a/Documentation/ABI/testing/sysfs-module +++ b/Documentation/ABI/testing/sysfs-module @@ -49,3 +49,4 @@ Description: Module taint flags: O - out-of-tree module F - force-loaded module C - staging driver module + E - unsigned module diff --git a/Documentation/ABI/testing/sysfs-platform-brcmstb-gisb-arb b/Documentation/ABI/testing/sysfs-platform-brcmstb-gisb-arb new file mode 100644 index 0000000..f1bad92 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-brcmstb-gisb-arb @@ -0,0 +1,8 @@ +What: /sys/devices/../../gisb_arb_timeout +Date: May 2014 +KernelVersion: 3.17 +Contact: Florian Fainelli <f.fainelli@gmail.com> +Description: + Returns the currently configured raw timeout value of the + Broadcom Set Top Box internal GISB bus arbiter. Minimum value + is 1, and maximum value is 0xffffffff. diff --git a/Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg b/Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg new file mode 100644 index 0000000..151c595 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg @@ -0,0 +1,56 @@ +What: /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req +Date: Feb 2014 +Contact: Li Jun <b47624@freescale.com> +Description: + Can be set and read. + Set a_bus_req(A-device bus request) input to be 1 if + the application running on the A-device wants to use the bus, + and to be 0 when the application no longer wants to use + the bus(or wants to work as peripheral). a_bus_req can also + be set to 1 by kernel in response to remote wakeup signaling + from the B-device, the A-device should decide to resume the bus. + + Valid values are "1" and "0". + + Reading: returns 1 if the application running on the A-device + is using the bus as host role, otherwise 0. + +What: /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop +Date: Feb 2014 +Contact: Li Jun <b47624@freescale.com> +Description: + Can be set and read + The a_bus_drop(A-device bus drop) input is 1 when the + application running on the A-device wants to power down + the bus, and is 0 otherwise, When a_bus_drop is 1, then + the a_bus_req shall be 0. + + Valid values are "1" and "0". + + Reading: returns 1 if the bus is off(vbus is turned off) by + A-device, otherwise 0. + +What: /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req +Date: Feb 2014 +Contact: Li Jun <b47624@freescale.com> +Description: + Can be set and read. + The b_bus_req(B-device bus request) input is 1 during the time + that the application running on the B-device wants to use the + bus as host, and is 0 when the application no longer wants to + work as host and decides to switch back to be peripheral. + + Valid values are "1" and "0". + + Reading: returns if the application running on the B device + is using the bus as host role, otherwise 0. + +What: /sys/bus/platform/devices/ci_hdrc.0/inputs/a_clr_err +Date: Feb 2014 +Contact: Li Jun <b47624@freescale.com> +Description: + Only can be set. + The a_clr_err(A-device Vbus error clear) input is used to clear + vbus error, then A-device will power down the bus. + + Valid value is "1" diff --git a/Documentation/ABI/testing/sysfs-platform-ts5500 b/Documentation/ABI/testing/sysfs-platform-ts5500 index c88375a..e685957 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-power b/Documentation/ABI/testing/sysfs-power index 64c9276..f455181 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -7,19 +7,30 @@ Description: subsystem. What: /sys/power/state -Date: August 2006 +Date: May 2014 Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: - The /sys/power/state file controls the system power state. - Reading from this file returns what states are supported, - which is hard-coded to 'freeze' (Low-Power Idle), 'standby' - (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk' - (Suspend-to-Disk). + The /sys/power/state file controls system sleep states. + Reading from this file returns the available sleep state + labels, which may be "mem", "standby", "freeze" and "disk" + (hibernation). The meanings of the first three labels depend on + the relative_sleep_states command line argument as follows: + 1) relative_sleep_states = 1 + "mem", "standby", "freeze" represent non-hibernation sleep + states from the deepest ("mem", always present) to the + shallowest ("freeze"). "standby" and "freeze" may or may + not be present depending on the capabilities of the + platform. "freeze" can only be present if "standby" is + present. + 2) relative_sleep_states = 0 (default) + "mem" - "suspend-to-RAM", present if supported. + "standby" - "power-on suspend", present if supported. + "freeze" - "suspend-to-idle", always present. Writing to this file one of these strings causes the system to - transition into that state. Please see the file - Documentation/power/states.txt for a description of each of - these states. + transition into the corresponding state, if available. See + Documentation/power/states.txt for a description of what + "suspend-to-RAM", "power-on suspend" and "suspend-to-idle" mean. What: /sys/power/disk Date: September 2006 diff --git a/Documentation/ABI/testing/sysfs-ptp b/Documentation/ABI/testing/sysfs-ptp index 05aeedf..44806a6 100644 --- a/Documentation/ABI/testing/sysfs-ptp +++ b/Documentation/ABI/testing/sysfs-ptp @@ -54,6 +54,26 @@ Description: This file contains the number of programmable periodic output channels offered by the PTP hardware clock. +What: /sys/class/ptp/ptpN/n_pins +Date: March 2014 +Contact: Richard Cochran <richardcochran@gmail.com> +Description: + This file contains the number of programmable pins + offered by the PTP hardware clock. + +What: /sys/class/ptp/ptpN/pins +Date: March 2014 +Contact: Richard Cochran <richardcochran@gmail.com> +Description: + This directory contains one file for each programmable + pin offered by the PTP hardware clock. The file name + is the hardware dependent pin name. Reading from this + file produces two numbers, the assigned function (see + the PTP_PF_ enumeration values in linux/ptp_clock.h) + and the channel number. The function and channel + assignment may be changed by two writing numbers into + the file. + What: /sys/class/ptp/ptpN/pps_avaiable Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> diff --git a/Documentation/ABI/testing/sysfs-tty b/Documentation/ABI/testing/sysfs-tty index ad22fb0..9eb3c2b 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/Changes b/Documentation/Changes index 2254db0..227bec8 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -280,12 +280,9 @@ that is possible. mcelog ------ -In Linux 2.6.31+ the i386 kernel needs to run the mcelog utility -as a regular cronjob similar to the x86-64 kernel to process and log -machine check events when CONFIG_X86_NEW_MCE is enabled. Machine check -events are errors reported by the CPU. Processing them is strongly encouraged. -All x86-64 kernels since 2.6.4 require the mcelog utility to -process machine checks. +On x86 kernels the mcelog utility is needed to process and log machine check +events when CONFIG_X86_MCE is enabled. Machine check events are errors reported +by the CPU. Processing them is strongly encouraged. Getting updated software ======================== diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 7fe0546..6b6bef3 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -660,15 +660,23 @@ There are a number of driver model diagnostic macros in <linux/device.h> which you should use to make sure messages are matched to the right device and driver, and are tagged with the right level: dev_err(), dev_warn(), dev_info(), and so forth. For messages that aren't associated with a -particular device, <linux/printk.h> defines pr_debug() and pr_info(). +particular device, <linux/printk.h> defines pr_notice(), pr_info(), +pr_warn(), pr_err(), etc. Coming up with good debugging messages can be quite a challenge; and once -you have them, they can be a huge help for remote troubleshooting. Such -messages should be compiled out when the DEBUG symbol is not defined (that -is, by default they are not included). When you use dev_dbg() or pr_debug(), -that's automatic. Many subsystems have Kconfig options to turn on -DDEBUG. -A related convention uses VERBOSE_DEBUG to add dev_vdbg() messages to the -ones already enabled by DEBUG. +you have them, they can be a huge help for remote troubleshooting. However +debug message printing is handled differently than printing other non-debug +messages. While the other pr_XXX() functions print unconditionally, +pr_debug() does not; it is compiled out by default, unless either DEBUG is +defined or CONFIG_DYNAMIC_DEBUG is set. That is true for dev_dbg() also, +and a related convention uses VERBOSE_DEBUG to add dev_vdbg() messages to +the ones already enabled by DEBUG. + +Many subsystems have Kconfig debug options to turn on -DDEBUG in the +corresponding Makefile; in other cases specific files #define DEBUG. And +when a debug message should be unconditionally printed, such as if it is +already inside a debug-related #ifdef secton, printk(KERN_DEBUG ...) can be +used. Chapter 14: Allocating memory diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 5e98303..dcbbe36 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -9,16 +9,76 @@ This is a guide to device driver writers on how to use the DMA API with example pseudo-code. For a concise description of the API, see DMA-API.txt. -Most of the 64bit platforms have special hardware that translates bus -addresses (DMA addresses) into physical addresses. This is similar to -how page tables and/or a TLB translates virtual addresses to physical -addresses on a CPU. This is needed so that e.g. PCI devices can -access with a Single Address Cycle (32bit DMA address) any page in the -64bit physical address space. Previously in Linux those 64bit -platforms had to set artificial limits on the maximum RAM size in the -system, so that the virt_to_bus() static scheme works (the DMA address -translation tables were simply filled on bootup to map each bus -address to the physical page __pa(bus_to_virt())). + CPU and DMA addresses + +There are several kinds of addresses involved in the DMA API, and it's +important to understand the differences. + +The kernel normally uses virtual addresses. Any address returned by +kmalloc(), vmalloc(), and similar interfaces is a virtual address and can +be stored in a "void *". + +The virtual memory system (TLB, page tables, etc.) translates virtual +addresses to CPU physical addresses, which are stored as "phys_addr_t" or +"resource_size_t". The kernel manages device resources like registers as +physical addresses. These are the addresses in /proc/iomem. The physical +address is not directly useful to a driver; it must use ioremap() to map +the space and produce a virtual address. + +I/O devices use a third kind of address: a "bus address" or "DMA address". +If a device has registers at an MMIO address, or if it performs DMA to read +or write system memory, the addresses used by the device are bus addresses. +In some systems, bus addresses are identical to CPU physical addresses, but +in general they are not. IOMMUs and host bridges can produce arbitrary +mappings between physical and bus addresses. + +Here's a picture and some examples: + + CPU CPU Bus + Virtual Physical Address + Address Address Space + Space Space + + +-------+ +------+ +------+ + | | |MMIO | Offset | | + | | Virtual |Space | applied | | + C +-------+ --------> B +------+ ----------> +------+ A + | | mapping | | by host | | + +-----+ | | | | bridge | | +--------+ + | | | | +------+ | | | | + | CPU | | | | RAM | | | | Device | + | | | | | | | | | | + +-----+ +-------+ +------+ +------+ +--------+ + | | Virtual |Buffer| Mapping | | + X +-------+ --------> Y +------+ <---------- +------+ Z + | | mapping | RAM | by IOMMU + | | | | + | | | | + +-------+ +------+ + +During the enumeration process, the kernel learns about I/O devices and +their MMIO space and the host bridges that connect them to the system. For +example, if a PCI device has a BAR, the kernel reads the bus address (A) +from the BAR and converts it to a CPU physical address (B). The address B +is stored in a struct resource and usually exposed via /proc/iomem. When a +driver claims a device, it typically uses ioremap() to map physical address +B at a virtual address (C). It can then use, e.g., ioread32(C), to access +the device registers at bus address A. + +If the device supports DMA, the driver sets up a buffer using kmalloc() or +a similar interface, which returns a virtual address (X). The virtual +memory system maps X to a physical address (Y) in system RAM. The driver +can use virtual address X to access the buffer, but the device itself +cannot because DMA doesn't go through the CPU virtual memory system. + +In some simple systems, the device can do DMA directly to physical address +Y. But in many others, there is IOMMU hardware that translates bus +addresses to physical addresses, e.g., it translates Z to Y. This is part +of the reason for the DMA API: the driver can give a virtual address X to +an interface like dma_map_single(), which sets up any required IOMMU +mapping and returns the bus address Z. The driver then tells the device to +do DMA to Z, and the IOMMU maps it to the buffer at address Y in system +RAM. So that Linux can use the dynamic DMA mapping, it needs some help from the drivers, namely it has to take into account that DMA addresses should be @@ -29,17 +89,17 @@ The following API will work of course even on platforms where no such hardware exists. Note that the DMA API works with any bus independent of the underlying -microprocessor architecture. You should use the DMA API rather than -the bus specific DMA API (e.g. pci_dma_*). +microprocessor architecture. You should use the DMA API rather than the +bus-specific DMA API, i.e., use the dma_map_*() interfaces rather than the +pci_map_*() interfaces. First of all, you should make sure #include <linux/dma-mapping.h> -is in your driver. This file will obtain for you the definition of the -dma_addr_t (which can hold any valid DMA address for the platform) -type which should be used everywhere you hold a DMA (bus) address -returned from the DMA mapping functions. +is in your driver, which provides the definition of dma_addr_t. This type +can hold any valid DMA or bus address for the platform and should be used +everywhere you hold a DMA address returned from the DMA mapping functions. What memory is DMA'able? @@ -123,9 +183,9 @@ Here, dev is a pointer to the device struct of your device, and mask is a bit mask describing which bits of an address your device supports. It returns zero if your card can perform DMA properly on the machine given the address mask you provided. In general, the -device struct of your device is embedded in the bus specific device -struct of your device. For example, a pointer to the device struct of -your PCI device is pdev->dev (pdev is a pointer to the PCI device +device struct of your device is embedded in the bus-specific device +struct of your device. For example, &pdev->dev is a pointer to the +device struct of a PCI device (pdev is a pointer to the PCI device struct of your device). If it returns non-zero, your device cannot perform DMA properly on @@ -147,8 +207,7 @@ exactly why. The standard 32-bit addressing device would do something like this: if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) { - printk(KERN_WARNING - "mydev: No suitable DMA available.\n"); + dev_warn(dev, "mydev: No suitable DMA available\n"); goto ignore_this_device; } @@ -170,8 +229,7 @@ all 64-bits when accessing streaming DMA: } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) { using_dac = 0; } else { - printk(KERN_WARNING - "mydev: No suitable DMA available.\n"); + dev_warn(dev, "mydev: No suitable DMA available\n"); goto ignore_this_device; } @@ -187,22 +245,20 @@ the case would look like this: using_dac = 0; consistent_using_dac = 0; } else { - printk(KERN_WARNING - "mydev: No suitable DMA available.\n"); + dev_warn(dev, "mydev: No suitable DMA available\n"); goto ignore_this_device; } -The coherent coherent mask will always be able to set the same or a -smaller mask as the streaming mask. However for the rare case that a -device driver only uses consistent allocations, one would have to -check the return value from dma_set_coherent_mask(). +The coherent mask will always be able to set the same or a smaller mask as +the streaming mask. However for the rare case that a device driver only +uses consistent allocations, one would have to check the return value from +dma_set_coherent_mask(). Finally, if your device can only drive the low 24-bits of address you might do something like: if (dma_set_mask(dev, DMA_BIT_MASK(24))) { - printk(KERN_WARNING - "mydev: 24-bit DMA addressing not available.\n"); + dev_warn(dev, "mydev: 24-bit DMA addressing not available\n"); goto ignore_this_device; } @@ -232,14 +288,14 @@ Here is pseudo-code showing how this might be done: card->playback_enabled = 1; } else { card->playback_enabled = 0; - printk(KERN_WARNING "%s: Playback disabled due to DMA limitations.\n", + dev_warn(dev, "%s: Playback disabled due to DMA limitations\n", card->name); } if (!dma_set_mask(dev, RECORD_ADDRESS_BITS)) { card->record_enabled = 1; } else { card->record_enabled = 0; - printk(KERN_WARNING "%s: Record disabled due to DMA limitations.\n", + dev_warn(dev, "%s: Record disabled due to DMA limitations\n", card->name); } @@ -331,7 +387,7 @@ context with the GFP_ATOMIC flag. Size is the length of the region you want to allocate, in bytes. This routine will allocate RAM for that region, so it acts similarly to -__get_free_pages (but takes size instead of a page order). If your +__get_free_pages() (but takes size instead of a page order). If your driver needs regions sized smaller than a page, you may prefer using the dma_pool interface, described below. @@ -343,11 +399,11 @@ the consistent DMA mask has been explicitly changed via dma_set_coherent_mask(). This is true of the dma_pool interface as well. -dma_alloc_coherent returns two values: the virtual address which you +dma_alloc_coherent() returns two values: the virtual address which you can use to access it from the CPU and dma_handle which you pass to the card. -The cpu return address and the DMA bus master address are both +The CPU virtual address and the DMA bus address are both guaranteed to be aligned to the smallest PAGE_SIZE order which is greater than or equal to the requested size. This invariant exists (for example) to guarantee that if you allocate a chunk @@ -359,13 +415,13 @@ To unmap and free such a DMA region, you call: dma_free_coherent(dev, size, cpu_addr, dma_handle); where dev, size are the same as in the above call and cpu_addr and -dma_handle are the values dma_alloc_coherent returned to you. +dma_handle are the values dma_alloc_coherent() returned to you. This function may not be called in interrupt context. If your driver needs lots of smaller memory regions, you can write -custom code to subdivide pages returned by dma_alloc_coherent, +custom code to subdivide pages returned by dma_alloc_coherent(), or you can use the dma_pool API to do that. A dma_pool is like -a kmem_cache, but it uses dma_alloc_coherent not __get_free_pages. +a kmem_cache, but it uses dma_alloc_coherent(), not __get_free_pages(). Also, it understands common hardware constraints for alignment, like queue heads needing to be aligned on N byte boundaries. @@ -373,37 +429,37 @@ Create a dma_pool like this: struct dma_pool *pool; - pool = dma_pool_create(name, dev, size, align, alloc); + pool = dma_pool_create(name, dev, size, align, boundary); The "name" is for diagnostics (like a kmem_cache name); dev and size are as above. The device's hardware alignment requirement for this type of data is "align" (which is expressed in bytes, and must be a power of two). If your device has no boundary crossing restrictions, -pass 0 for alloc; passing 4096 says memory allocated from this pool +pass 0 for boundary; passing 4096 says memory allocated from this pool must not cross 4KByte boundaries (but at that time it may be better to -go for dma_alloc_coherent directly instead). +use dma_alloc_coherent() directly instead). -Allocate memory from a dma pool like this: +Allocate memory from a DMA pool like this: cpu_addr = dma_pool_alloc(pool, flags, &dma_handle); -flags are SLAB_KERNEL if blocking is permitted (not in_interrupt nor -holding SMP locks), SLAB_ATOMIC otherwise. Like dma_alloc_coherent, +flags are GFP_KERNEL if blocking is permitted (not in_interrupt nor +holding SMP locks), GFP_ATOMIC otherwise. Like dma_alloc_coherent(), this returns two values, cpu_addr and dma_handle. Free memory that was allocated from a dma_pool like this: dma_pool_free(pool, cpu_addr, dma_handle); -where pool is what you passed to dma_pool_alloc, and cpu_addr and -dma_handle are the values dma_pool_alloc returned. This function +where pool is what you passed to dma_pool_alloc(), and cpu_addr and +dma_handle are the values dma_pool_alloc() returned. This function may be called in interrupt context. Destroy a dma_pool by calling: dma_pool_destroy(pool); -Make sure you've called dma_pool_free for all memory allocated +Make sure you've called dma_pool_free() for all memory allocated from a pool before you destroy the pool. This function may not be called in interrupt context. @@ -418,7 +474,7 @@ one of the following values: DMA_FROM_DEVICE DMA_NONE -One should provide the exact DMA direction if you know it. +You should provide the exact DMA direction if you know it. DMA_TO_DEVICE means "from main memory to the device" DMA_FROM_DEVICE means "from the device to main memory" @@ -489,14 +545,14 @@ and to unmap it: dma_unmap_single(dev, dma_handle, size, direction); You should call dma_mapping_error() as dma_map_single() could fail and return -error. Not all dma implementations support dma_mapping_error() interface. +error. Not all DMA implementations support the dma_mapping_error() interface. However, it is a good practice to call dma_mapping_error() interface, which will invoke the generic mapping error check interface. Doing so will ensure -that the mapping code will work correctly on all dma implementations without +that the mapping code will work correctly on all DMA implementations without any dependency on the specifics of the underlying implementation. Using the returned address without checking for errors could result in failures ranging from panics to silent data corruption. A couple of examples of incorrect ways -to check for errors that make assumptions about the underlying dma +to check for errors that make assumptions about the underlying DMA implementation are as follows and these are applicable to dma_map_page() as well. @@ -516,13 +572,13 @@ Incorrect example 2: goto map_error; } -You should call dma_unmap_single when the DMA activity is finished, e.g. +You should call dma_unmap_single() when the DMA activity is finished, e.g., from the interrupt which told you that the DMA transfer is done. -Using cpu pointers like this for single mappings has a disadvantage, +Using CPU pointers like this for single mappings has a disadvantage: you cannot reference HIGHMEM memory in this way. Thus, there is a -map/unmap interface pair akin to dma_{map,unmap}_single. These -interfaces deal with page/offset pairs instead of cpu pointers. +map/unmap interface pair akin to dma_{map,unmap}_single(). These +interfaces deal with page/offset pairs instead of CPU pointers. Specifically: struct device *dev = &my_dev->dev; @@ -550,7 +606,7 @@ Here, "offset" means byte offset within the given page. You should call dma_mapping_error() as dma_map_page() could fail and return error as outlined under the dma_map_single() discussion. -You should call dma_unmap_page when the DMA activity is finished, e.g. +You should call dma_unmap_page() when the DMA activity is finished, e.g., from the interrupt which told you that the DMA transfer is done. With scatterlists, you map a region gathered from several regions by: @@ -588,18 +644,16 @@ PLEASE NOTE: The 'nents' argument to the dma_unmap_sg call must be it should _NOT_ be the 'count' value _returned_ from the dma_map_sg call. -Every dma_map_{single,sg} call should have its dma_unmap_{single,sg} -counterpart, because the bus address space is a shared resource (although -in some ports the mapping is per each BUS so less devices contend for the -same bus address space) and you could render the machine unusable by eating -all bus addresses. +Every dma_map_{single,sg}() call should have its dma_unmap_{single,sg}() +counterpart, because the bus address space is a shared resource and +you could render the machine unusable by consuming all bus addresses. If you need to use the same streaming DMA region multiple times and touch the data in between the DMA transfers, the buffer needs to be synced -properly in order for the cpu and device to see the most uptodate and +properly in order for the CPU and device to see the most up-to-date and correct copy of the DMA buffer. -So, firstly, just map it with dma_map_{single,sg}, and after each DMA +So, firstly, just map it with dma_map_{single,sg}(), and after each DMA transfer call either: dma_sync_single_for_cpu(dev, dma_handle, size, direction); @@ -611,7 +665,7 @@ or: as appropriate. Then, if you wish to let the device get at the DMA area again, -finish accessing the data with the cpu, and then before actually +finish accessing the data with the CPU, and then before actually giving the buffer to the hardware call either: dma_sync_single_for_device(dev, dma_handle, size, direction); @@ -623,9 +677,9 @@ or: as appropriate. After the last DMA transfer call one of the DMA unmap routines -dma_unmap_{single,sg}. If you don't touch the data from the first dma_map_* -call till dma_unmap_*, then you don't have to call the dma_sync_* -routines at all. +dma_unmap_{single,sg}(). If you don't touch the data from the first +dma_map_*() call till dma_unmap_*(), then you don't have to call the +dma_sync_*() routines at all. Here is pseudo code which shows a situation in which you would need to use the dma_sync_*() interfaces. @@ -690,12 +744,12 @@ to use the dma_sync_*() interfaces. } } -Drivers converted fully to this interface should not use virt_to_bus any -longer, nor should they use bus_to_virt. Some drivers have to be changed a -little bit, because there is no longer an equivalent to bus_to_virt in the +Drivers converted fully to this interface should not use virt_to_bus() any +longer, nor should they use bus_to_virt(). Some drivers have to be changed a +little bit, because there is no longer an equivalent to bus_to_virt() in the dynamic DMA mapping scheme - you have to always store the DMA addresses -returned by the dma_alloc_coherent, dma_pool_alloc, and dma_map_single -calls (dma_map_sg stores them in the scatterlist itself if the platform +returned by the dma_alloc_coherent(), dma_pool_alloc(), and dma_map_single() +calls (dma_map_sg() stores them in the scatterlist itself if the platform supports dynamic DMA mapping in hardware) in your driver structures and/or in the card registers. @@ -709,9 +763,9 @@ as it is impossible to correctly support them. DMA address space is limited on some architectures and an allocation failure can be determined by: -- checking if dma_alloc_coherent returns NULL or dma_map_sg returns 0 +- checking if dma_alloc_coherent() returns NULL or dma_map_sg returns 0 -- checking the returned dma_addr_t of dma_map_single and dma_map_page +- checking the dma_addr_t returned from dma_map_single() and dma_map_page() by using dma_mapping_error(): dma_addr_t dma_handle; @@ -794,7 +848,7 @@ Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when dma_unmap_single(array[i].dma_addr); } -Networking drivers must call dev_kfree_skb to free the socket buffer +Networking drivers must call dev_kfree_skb() to free the socket buffer and return NETDEV_TX_OK if the DMA mapping fails on the transmit hook (ndo_start_xmit). This means that the socket buffer is just dropped in the failure case. @@ -831,7 +885,7 @@ transform some example code. DEFINE_DMA_UNMAP_LEN(len); }; -2) Use dma_unmap_{addr,len}_set to set these values. +2) Use dma_unmap_{addr,len}_set() to set these values. Example, before: ringp->mapping = FOO; @@ -842,7 +896,7 @@ transform some example code. dma_unmap_addr_set(ringp, mapping, FOO); dma_unmap_len_set(ringp, len, BAR); -3) Use dma_unmap_{addr,len} to access these values. +3) Use dma_unmap_{addr,len}() to access these values. Example, before: dma_unmap_single(dev, ringp->mapping, ringp->len, diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index e865279..5208840 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -4,22 +4,26 @@ James E.J. Bottomley <James.Bottomley@HansenPartnership.com> This document describes the DMA API. For a more gentle introduction -of the API (and actual examples) see -Documentation/DMA-API-HOWTO.txt. +of the API (and actual examples), see Documentation/DMA-API-HOWTO.txt. -This API is split into two pieces. Part I describes the API. Part II -describes the extensions to the API for supporting non-consistent -memory machines. Unless you know that your driver absolutely has to -support non-consistent platforms (this is usually only legacy -platforms) you should only use the API described in part I. +This API is split into two pieces. Part I describes the basic API. +Part II describes extensions for supporting non-consistent memory +machines. Unless you know that your driver absolutely has to support +non-consistent platforms (this is usually only legacy platforms) you +should only use the API described in part I. Part I - dma_ API ------------------------------------- -To get the dma_ API, you must #include <linux/dma-mapping.h> +To get the dma_ API, you must #include <linux/dma-mapping.h>. This +provides dma_addr_t and the interfaces described below. +A dma_addr_t can hold any valid DMA or bus address for the platform. It +can be given to a device to use as a DMA source or target. A CPU cannot +reference a dma_addr_t directly because there may be translation between +its physical address space and the bus address space. -Part Ia - Using large dma-coherent buffers +Part Ia - Using large DMA-coherent buffers ------------------------------------------ void * @@ -33,20 +37,21 @@ to make sure to flush the processor's write buffers before telling devices to read that memory.) This routine allocates a region of <size> bytes of consistent memory. -It also returns a <dma_handle> which may be cast to an unsigned -integer the same width as the bus and used as the physical address -base of the region. -Returns: a pointer to the allocated region (in the processor's virtual +It returns a pointer to the allocated region (in the processor's virtual address space) or NULL if the allocation failed. +It also returns a <dma_handle> which may be cast to an unsigned integer the +same width as the bus and given to the device as the bus address base of +the region. + Note: consistent memory can be expensive on some platforms, and the minimum allocation length may be as big as a page, so you should consolidate your requests for consistent memory as much as possible. The simplest way to do that is to use the dma_pool calls (see below). -The flag parameter (dma_alloc_coherent only) allows the caller to -specify the GFP_ flags (see kmalloc) for the allocation (the +The flag parameter (dma_alloc_coherent() only) allows the caller to +specify the GFP_ flags (see kmalloc()) for the allocation (the implementation may choose to ignore flags that affect the location of the returned memory, like GFP_DMA). @@ -61,24 +66,24 @@ void dma_free_coherent(struct device *dev, size_t size, void *cpu_addr, dma_addr_t dma_handle) -Free the region of consistent memory you previously allocated. dev, -size and dma_handle must all be the same as those passed into the -consistent allocate. cpu_addr must be the virtual address returned by -the consistent allocate. +Free a region of consistent memory you previously allocated. dev, +size and dma_handle must all be the same as those passed into +dma_alloc_coherent(). cpu_addr must be the virtual address returned by +the dma_alloc_coherent(). Note that unlike their sibling allocation calls, these routines may only be called with IRQs enabled. -Part Ib - Using small dma-coherent buffers +Part Ib - Using small DMA-coherent buffers ------------------------------------------ To get this part of the dma_ API, you must #include <linux/dmapool.h> -Many drivers need lots of small dma-coherent memory regions for DMA +Many drivers need lots of small DMA-coherent memory regions for DMA descriptors or I/O buffers. Rather than allocating in units of a page or more using dma_alloc_coherent(), you can use DMA pools. These work -much like a struct kmem_cache, except that they use the dma-coherent allocator, +much like a struct kmem_cache, except that they use the DMA-coherent allocator, not __get_free_pages(). Also, they understand common hardware constraints for alignment, like queue heads needing to be aligned on N-byte boundaries. @@ -87,7 +92,7 @@ for alignment, like queue heads needing to be aligned on N-byte boundaries. dma_pool_create(const char *name, struct device *dev, size_t size, size_t align, size_t alloc); -The pool create() routines initialize a pool of dma-coherent buffers +dma_pool_create() initializes a pool of DMA-coherent buffers for use with a given device. It must be called in a context which can sleep. @@ -102,25 +107,26 @@ from this pool must not cross 4KByte boundaries. void *dma_pool_alloc(struct dma_pool *pool, gfp_t gfp_flags, dma_addr_t *dma_handle); -This allocates memory from the pool; the returned memory will meet the size -and alignment requirements specified at creation time. Pass GFP_ATOMIC to -prevent blocking, or if it's permitted (not in_interrupt, not holding SMP locks), -pass GFP_KERNEL to allow blocking. Like dma_alloc_coherent(), this returns -two values: an address usable by the cpu, and the dma address usable by the -pool's device. +This allocates memory from the pool; the returned memory will meet the +size and alignment requirements specified at creation time. Pass +GFP_ATOMIC to prevent blocking, or if it's permitted (not +in_interrupt, not holding SMP locks), pass GFP_KERNEL to allow +blocking. Like dma_alloc_coherent(), this returns two values: an +address usable by the CPU, and the DMA address usable by the pool's +device. void dma_pool_free(struct dma_pool *pool, void *vaddr, dma_addr_t addr); This puts memory back into the pool. The pool is what was passed to -the pool allocation routine; the cpu (vaddr) and dma addresses are what +dma_pool_alloc(); the CPU (vaddr) and DMA addresses are what were returned when that routine allocated the memory being freed. void dma_pool_destroy(struct dma_pool *pool); -The pool destroy() routines free the resources of the pool. They must be +dma_pool_destroy() frees the resources of the pool. It must be called in a context which can sleep. Make sure you've freed all allocated memory back to the pool before you destroy it. @@ -187,9 +193,9 @@ dma_map_single(struct device *dev, void *cpu_addr, size_t size, enum dma_data_direction direction) Maps a piece of processor virtual memory so it can be accessed by the -device and returns the physical handle of the memory. +device and returns the bus address of the memory. -The direction for both api's may be converted freely by casting. +The direction for both APIs may be converted freely by casting. However the dma_ API uses a strongly typed enumerator for its direction: @@ -198,31 +204,30 @@ DMA_TO_DEVICE data is going from the memory to the device DMA_FROM_DEVICE data is coming from the device to the memory DMA_BIDIRECTIONAL direction isn't known -Notes: Not all memory regions in a machine can be mapped by this -API. Further, regions that appear to be physically contiguous in -kernel virtual space may not be contiguous as physical memory. Since -this API does not provide any scatter/gather capability, it will fail -if the user tries to map a non-physically contiguous piece of memory. -For this reason, it is recommended that memory mapped by this API be -obtained only from sources which guarantee it to be physically contiguous -(like kmalloc). - -Further, the physical address of the memory must be within the -dma_mask of the device (the dma_mask represents a bit mask of the -addressable region for the device. I.e., if the physical address of -the memory anded with the dma_mask is still equal to the physical -address, then the device can perform DMA to the memory). In order to +Notes: Not all memory regions in a machine can be mapped by this API. +Further, contiguous kernel virtual space may not be contiguous as +physical memory. Since this API does not provide any scatter/gather +capability, it will fail if the user tries to map a non-physically +contiguous piece of memory. For this reason, memory to be mapped by +this API should be obtained from sources which guarantee it to be +physically contiguous (like kmalloc). + +Further, the bus address of the memory must be within the +dma_mask of the device (the dma_mask is a bit mask of the +addressable region for the device, i.e., if the bus address of +the memory ANDed with the dma_mask is still equal to the bus +address, then the device can perform DMA to the memory). To ensure that the memory allocated by kmalloc is within the dma_mask, the driver may specify various platform-dependent flags to restrict -the physical memory range of the allocation (e.g. on x86, GFP_DMA -guarantees to be within the first 16Mb of available physical memory, +the bus address range of the allocation (e.g., on x86, GFP_DMA +guarantees to be within the first 16MB of available bus addresses, as required by ISA devices). Note also that the above constraints on physical contiguity and dma_mask may not apply if the platform has an IOMMU (a device which -supplies a physical to virtual mapping between the I/O memory bus and -the device). However, to be portable, device driver writers may *not* -assume that such an IOMMU exists. +maps an I/O bus address to a physical memory address). However, to be +portable, device driver writers may *not* assume that such an IOMMU +exists. Warnings: Memory coherency operates at a granularity called the cache line width. In order for memory mapped by this API to operate @@ -281,9 +286,9 @@ cache width is. int dma_mapping_error(struct device *dev, dma_addr_t dma_addr) -In some circumstances dma_map_single and dma_map_page will fail to create +In some circumstances dma_map_single() and dma_map_page() will fail to create a mapping. A driver can check for these errors by testing the returned -dma address with dma_mapping_error(). A non-zero return value means the mapping +DMA address with dma_mapping_error(). A non-zero return value means the mapping could not be created and the driver should take appropriate action (e.g. reduce current DMA mapping usage or delay and try again later). @@ -291,7 +296,7 @@ reduce current DMA mapping usage or delay and try again later). dma_map_sg(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction direction) -Returns: the number of physical segments mapped (this may be shorter +Returns: the number of bus address segments mapped (this may be shorter than <nents> passed in if some elements of the scatter/gather list are physically or virtually adjacent and an IOMMU maps them with a single entry). @@ -299,7 +304,7 @@ entry). Please note that the sg cannot be mapped again if it has been mapped once. The mapping process is allowed to destroy information in the sg. -As with the other mapping interfaces, dma_map_sg can fail. When it +As with the other mapping interfaces, dma_map_sg() can fail. When it does, 0 is returned and a driver must take appropriate action. It is critical that the driver do something, in the case of a block driver aborting the request or even oopsing is better than doing nothing and @@ -335,7 +340,7 @@ must be the same as those and passed in to the scatter/gather mapping API. Note: <nents> must be the number you passed in, *not* the number of -physical entries returned. +bus address entries returned. void dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size, @@ -350,7 +355,7 @@ void dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems, enum dma_data_direction direction) -Synchronise a single contiguous or scatter/gather mapping for the cpu +Synchronise a single contiguous or scatter/gather mapping for the CPU and device. With the sync_sg API, all the parameters must be the same as those passed into the single mapping API. With the sync_single API, you can use dma_handle and size parameters that aren't identical to @@ -391,10 +396,10 @@ The four functions above are just like the counterpart functions without the _attrs suffixes, except that they pass an optional struct dma_attrs*. -struct dma_attrs encapsulates a set of "dma attributes". For the +struct dma_attrs encapsulates a set of "DMA attributes". For the definition of struct dma_attrs see linux/dma-attrs.h. -The interpretation of dma attributes is architecture-specific, and +The interpretation of DMA attributes is architecture-specific, and each attribute should be documented in Documentation/DMA-attributes.txt. If struct dma_attrs* is NULL, the semantics of each of these @@ -458,7 +463,7 @@ Note: where the platform can return consistent memory, it will guarantee that the sync points become nops. Warning: Handling non-consistent memory is a real pain. You should -only ever use this API if you positively know your driver will be +only use this API if you positively know your driver will be required to work on one of the rare (usually non-PCI) architectures that simply cannot make consistent memory. @@ -492,30 +497,29 @@ continuing on for size. Again, you *must* observe the cache line boundaries when doing this. int -dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr, +dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr, dma_addr_t device_addr, size_t size, int flags) -Declare region of memory to be handed out by dma_alloc_coherent when +Declare region of memory to be handed out by dma_alloc_coherent() when it's asked for coherent memory for this device. -bus_addr is the physical address to which the memory is currently -assigned in the bus responding region (this will be used by the -platform to perform the mapping). +phys_addr is the CPU physical address to which the memory is currently +assigned (this will be ioremapped so the CPU can access the region). -device_addr is the physical address the device needs to be programmed -with actually to address this memory (this will be handed out as the +device_addr is the bus address the device needs to be programmed +with to actually address this memory (this will be handed out as the dma_addr_t in dma_alloc_coherent()). size is the size of the area (must be multiples of PAGE_SIZE). -flags can be or'd together and are: +flags can be ORed together and are: DMA_MEMORY_MAP - request that the memory returned from dma_alloc_coherent() be directly writable. DMA_MEMORY_IO - request that the memory returned from -dma_alloc_coherent() be addressable using read/write/memcpy_toio etc. +dma_alloc_coherent() be addressable using read()/write()/memcpy_toio() etc. One or both of these flags must be present. @@ -572,7 +576,7 @@ region is occupied. Part III - Debug drivers use of the DMA-API ------------------------------------------- -The DMA-API as described above as some constraints. DMA addresses must be +The DMA-API as described above has some constraints. DMA addresses must be released with the corresponding function with the same size for example. With the advent of hardware IOMMUs it becomes more and more important that drivers do not violate those constraints. In the worst case such a violation can @@ -690,11 +694,11 @@ architectural default. void debug_dmap_mapping_error(struct device *dev, dma_addr_t dma_addr); dma-debug interface debug_dma_mapping_error() to debug drivers that fail -to check dma mapping errors on addresses returned by dma_map_single() and +to check DMA mapping errors on addresses returned by dma_map_single() and dma_map_page() interfaces. This interface clears a flag set by debug_dma_map_page() to indicate that dma_mapping_error() has been called by the driver. When driver does unmap, debug_dma_unmap() checks the flag and if this flag is still set, prints warning message that includes call trace that leads up to the unmap. This interface can be called from dma_mapping_error() -routines to enable dma mapping error check debugging. +routines to enable DMA mapping error check debugging. diff --git a/Documentation/DMA-ISA-LPC.txt b/Documentation/DMA-ISA-LPC.txt index e767805..b1a1983 100644 --- a/Documentation/DMA-ISA-LPC.txt +++ b/Documentation/DMA-ISA-LPC.txt @@ -16,7 +16,7 @@ To do ISA style DMA you need to include two headers: #include <asm/dma.h> The first is the generic DMA API used to convert virtual addresses to -physical addresses (see Documentation/DMA-API.txt for details). +bus addresses (see Documentation/DMA-API.txt for details). The second contains the routines specific to ISA DMA transfers. Since this is not present on all platforms make sure you construct your @@ -50,7 +50,7 @@ early as possible and not release it until the driver is unloaded.) Part III - Address translation ------------------------------ -To translate the virtual address to a physical use the normal DMA +To translate the virtual address to a bus address, use the normal DMA API. Do _not_ use isa_virt_to_phys() even though it does the same thing. The reason for this is that the function isa_virt_to_phys() will require a Kconfig dependency to ISA, not just ISA_DMA_API which diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index 46ad6fa..d9b9416 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -98,6 +98,9 @@ !Finclude/net/cfg80211.h priv_to_wiphy !Finclude/net/cfg80211.h set_wiphy_dev !Finclude/net/cfg80211.h wdev_priv +!Finclude/net/cfg80211.h ieee80211_iface_limit +!Finclude/net/cfg80211.h ieee80211_iface_combination +!Finclude/net/cfg80211.h cfg80211_check_combinations </chapter> <chapter> <title>Actions and configuration</title> diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 8d96ebf..bec0665 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -14,9 +14,10 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml drm.xml media_api.xml w1.xml + tracepoint.xml drm.xml media_api.xml w1.xml \ + writing_musb_glue_layer.xml -include $(srctree)/Documentation/DocBook/media/Makefile +include Documentation/DocBook/media/Makefile ### # The build process is as follows (targets): @@ -36,6 +37,7 @@ PS_METHOD = $(prefer-db2x) # The targets that may be used. PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs +targets += $(DOCBOOKS) BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) xmldocs: $(BOOKS) sgmldocs: xmldocs @@ -58,14 +60,14 @@ mandocs: $(MAN) installmandocs: mandocs mkdir -p /usr/local/man/man9/ - install Documentation/DocBook/man/*.9.gz /usr/local/man/man9/ + install $(obj)/man/*.9.gz /usr/local/man/man9/ ### #External programs used KERNELDOC = $(srctree)/scripts/kernel-doc DOCPROC = $(objtree)/scripts/docproc -XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl +XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl XMLTOFLAGS += --skip-validation ### @@ -87,21 +89,9 @@ define rule_docproc ) > $(dir $@).$(notdir $@).cmd endef -%.xml: %.tmpl FORCE +%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE $(call if_changed_rule,docproc) -### -#Read in all saved dependency files -cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd)) - -ifneq ($(cmd_files),) - include $(cmd_files) -endif - -### -# Changes in kernel-doc force a rebuild of all documentation -$(BOOKS): $(KERNELDOC) - # Tell kbuild to always build the programs always := $(hostprogs-y) @@ -139,7 +129,7 @@ quiet_cmd_db2pdf = PDF $@ index = index.html -main_idx = Documentation/DocBook/$(index) +main_idx = $(obj)/$(index) build_main_index = rm -rf $(main_idx); \ echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \ echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \ @@ -148,7 +138,7 @@ build_main_index = rm -rf $(main_idx); \ quiet_cmd_db2html = HTML $@ cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \ echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \ - $(patsubst %.html,%,$(notdir $@))</a><p>' > $@ + $(patsubst %.html,%,$(notdir $@))</a><p>' > $@ %.html: %.xml @(which xmlto > /dev/null 2>&1) || \ diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index f517008..f213058 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 @@ -276,7 +280,7 @@ X!Isound/sound_firmware.c </para> <sect1><title>Frame Buffer Memory</title> -!Edrivers/video/fbmem.c +!Edrivers/video/fbdev/core/fbmem.c </sect1> <!-- <sect1><title>Frame Buffer Console</title> @@ -284,7 +288,7 @@ X!Edrivers/video/console/fbcon.c </sect1> --> <sect1><title>Frame Buffer Colormap</title> -!Edrivers/video/fbcmap.c +!Edrivers/video/fbdev/core/fbcmap.c </sect1> <!-- FIXME: drivers/video/fbgen.c has no docs, which stuffs up the sgml. Comment @@ -294,11 +298,11 @@ X!Idrivers/video/fbgen.c </sect1> KAO --> <sect1><title>Frame Buffer Video Mode Database</title> -!Idrivers/video/modedb.c -!Edrivers/video/modedb.c +!Idrivers/video/fbdev/core/modedb.c +!Edrivers/video/fbdev/core/modedb.c </sect1> <sect1><title>Frame Buffer Macintosh Video Mode Database</title> -!Edrivers/video/macmodes.c +!Edrivers/video/fbdev/macmodes.c </sect1> <sect1><title>Frame Buffer Fonts</title> <para> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ed1d6d2..7df3134 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -29,12 +29,26 @@ </address> </affiliation> </author> + <author> + <firstname>Daniel</firstname> + <surname>Vetter</surname> + <contrib>Contributions all over the place</contrib> + <affiliation> + <orgname>Intel Corporation</orgname> + <address> + <email>daniel.vetter@ffwll.ch</email> + </address> + </affiliation> + </author> </authorgroup> <copyright> <year>2008-2009</year> - <year>2012</year> + <year>2013-2014</year> <holder>Intel Corporation</holder> + </copyright> + <copyright> + <year>2012</year> <holder>Laurent Pinchart</holder> </copyright> @@ -60,7 +74,15 @@ <toc></toc> - <!-- Introduction --> +<part id="drmCore"> + <title>DRM Core</title> + <partintro> + <para> + This first part of the DRM Developer's Guide documents core DRM code, + helper libraries for writing drivers and generic userspace interfaces + exposed by DRM drivers. + </para> + </partintro> <chapter id="drmIntroduction"> <title>Introduction</title> @@ -120,6 +142,12 @@ to register it with the DRM subsystem. </para> <para> + Newer drivers that no longer require a <structname>drm_bus</structname> + structure can alternatively use the low-level device initialization and + registration functions such as <function>drm_dev_alloc()</function> and + <function>drm_dev_register()</function> directly. + </para> + <para> The <structname>drm_driver</structname> structure contains static information that describes the driver and features it supports, and pointers to methods that the DRM core will call to implement the DRM API. @@ -260,12 +288,42 @@ char *date;</synopsis> </sect3> </sect2> <sect2> + <title>Device Registration</title> + <para> + A number of functions are provided to help with device registration. + The functions deal with PCI, USB and platform devices, respectively. + </para> +!Edrivers/gpu/drm/drm_pci.c +!Edrivers/gpu/drm/drm_usb.c +!Edrivers/gpu/drm/drm_platform.c + <para> + New drivers that no longer rely on the services provided by the + <structname>drm_bus</structname> structure can call the low-level + device registration functions directly. The + <function>drm_dev_alloc()</function> function can be used to allocate + and initialize a new <structname>drm_device</structname> structure. + Drivers will typically want to perform some additional setup on this + structure, such as allocating driver-specific data and storing a + pointer to it in the DRM device's <structfield>dev_private</structfield> + field. Drivers should also set the device's unique name using the + <function>drm_dev_set_unique()</function> function. After it has been + set up a device can be registered with the DRM subsystem by calling + <function>drm_dev_register()</function>. This will cause the device to + be exposed to userspace and will call the driver's + <structfield>.load()</structfield> implementation. When a device is + removed, the DRM device can safely be unregistered and freed by calling + <function>drm_dev_unregister()</function> followed by a call to + <function>drm_dev_unref()</function>. + </para> +!Edrivers/gpu/drm/drm_stub.c + </sect2> + <sect2> <title>Driver Load</title> <para> The <methodname>load</methodname> method is the driver and device initialization entry point. The method is responsible for allocating and - initializing driver private data, specifying supported performance - counters, performing resource allocation and mapping (e.g. acquiring + initializing driver private data, performing resource allocation and + mapping (e.g. acquiring clocks, mapping registers or allocating command buffers), initializing the memory manager (<xref linkend="drm-memory-management"/>), installing the IRQ handler (<xref linkend="drm-irq-registration"/>), setting up @@ -295,7 +353,7 @@ char *date;</synopsis> their <methodname>load</methodname> method called with flags to 0. </para> <sect3> - <title>Driver Private & Performance Counters</title> + <title>Driver Private Data</title> <para> The driver private hangs off the main <structname>drm_device</structname> structure and can be used for @@ -307,14 +365,6 @@ char *date;</synopsis> <structname>drm_device</structname>.<structfield>dev_priv</structfield> set to NULL when the driver is unloaded. </para> - <para> - DRM supports several counters which were used for rough performance - characterization. This stat counter system is deprecated and should not - be used. If performance monitoring is desired, the developer should - investigate and potentially enhance the kernel perf and tracing - infrastructure to export GPU related performance information for - consumption by performance monitoring tools and applications. - </para> </sect3> <sect3 id="drm-irq-registration"> <title>IRQ Registration</title> @@ -328,21 +378,13 @@ char *date;</synopsis> <sect4> <title>Managed IRQ Registration</title> <para> - Both the <function>drm_irq_install</function> and - <function>drm_irq_uninstall</function> functions get the device IRQ by - calling <function>drm_dev_to_irq</function>. This inline function will - call a bus-specific operation to retrieve the IRQ number. For platform - devices, <function>platform_get_irq</function>(..., 0) is used to - retrieve the IRQ number. - </para> - <para> <function>drm_irq_install</function> starts by calling the <methodname>irq_preinstall</methodname> driver operation. The operation is optional and must make sure that the interrupt will not get fired by clearing all pending interrupt flags or disabling the interrupt. </para> <para> - The IRQ will then be requested by a call to + The passed-in IRQ will then be requested by a call to <function>request_irq</function>. If the DRIVER_IRQ_SHARED driver feature flag is set, a shared (IRQF_SHARED) IRQ handler will be requested. @@ -445,7 +487,7 @@ char *date;</synopsis> providing a solution to every graphics memory-related problems, GEM identified common code between drivers and created a support library to share it. GEM has simpler initialization and execution requirements than - TTM, but has no video RAM management capabitilies and is thus limited to + TTM, but has no video RAM management capabilities and is thus limited to UMA devices. </para> <sect2> @@ -697,55 +739,16 @@ char *date;</synopsis> respectively. The conversion is handled by the DRM core without any driver-specific support. </para> - <para> - Similar to global names, GEM file descriptors are also used to share GEM - objects across processes. They offer additional security: as file - descriptors must be explicitly sent over UNIX domain sockets to be shared - between applications, they can't be guessed like the globally unique GEM - names. - </para> - <para> - Drivers that support GEM file descriptors, also known as the DRM PRIME - API, must set the DRIVER_PRIME bit in the struct - <structname>drm_driver</structname> - <structfield>driver_features</structfield> field, and implement the - <methodname>prime_handle_to_fd</methodname> and - <methodname>prime_fd_to_handle</methodname> operations. - </para> - <para> - <synopsis>int (*prime_handle_to_fd)(struct drm_device *dev, - struct drm_file *file_priv, uint32_t handle, - uint32_t flags, int *prime_fd); - int (*prime_fd_to_handle)(struct drm_device *dev, - struct drm_file *file_priv, int prime_fd, - uint32_t *handle);</synopsis> - Those two operations convert a handle to a PRIME file descriptor and - vice versa. Drivers must use the kernel dma-buf buffer sharing framework - to manage the PRIME file descriptors. - </para> - <para> - While non-GEM drivers must implement the operations themselves, GEM - drivers must use the <function>drm_gem_prime_handle_to_fd</function> - and <function>drm_gem_prime_fd_to_handle</function> helper functions. - Those helpers rely on the driver - <methodname>gem_prime_export</methodname> and - <methodname>gem_prime_import</methodname> operations to create a dma-buf - instance from a GEM object (dma-buf exporter role) and to create a GEM - object from a dma-buf instance (dma-buf importer role). - </para> - <para> - <synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev, - struct drm_gem_object *obj, - int flags); - struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev, - struct dma_buf *dma_buf);</synopsis> - These two operations are mandatory for GEM drivers that support DRM - PRIME. - </para> - <sect4> - <title>DRM PRIME Helper Functions Reference</title> -!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers - </sect4> + <para> + GEM also supports buffer sharing with dma-buf file descriptors through + PRIME. GEM-based drivers must use the provided helpers functions to + implement the exporting and importing correctly. See <xref linkend="drm-prime-support" />. + Since sharing file descriptors is inherently more secure than the + easily guessable and global GEM names it is the preferred buffer + sharing mechanism. Sharing buffers through GEM names is only supported + for legacy userspace. Furthermore PRIME also allows cross-device + buffer sharing since it is based on dma-bufs. + </para> </sect3> <sect3 id="drm-gem-objects-mapping"> <title>GEM Objects Mapping</title> @@ -830,62 +833,6 @@ char *date;</synopsis> </para> </sect3> <sect3> - <title>Dumb GEM Objects</title> - <para> - The GEM API doesn't standardize GEM objects creation and leaves it to - driver-specific ioctls. While not an issue for full-fledged graphics - stacks that include device-specific userspace components (in libdrm for - instance), this limit makes DRM-based early boot graphics unnecessarily - complex. - </para> - <para> - Dumb GEM objects partly alleviate the problem by providing a standard - API to create dumb buffers suitable for scanout, which can then be used - to create KMS frame buffers. - </para> - <para> - To support dumb GEM objects drivers must implement the - <methodname>dumb_create</methodname>, - <methodname>dumb_destroy</methodname> and - <methodname>dumb_map_offset</methodname> operations. - </para> - <itemizedlist> - <listitem> - <synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev, - struct drm_mode_create_dumb *args);</synopsis> - <para> - The <methodname>dumb_create</methodname> operation creates a GEM - object suitable for scanout based on the width, height and depth - from the struct <structname>drm_mode_create_dumb</structname> - argument. It fills the argument's <structfield>handle</structfield>, - <structfield>pitch</structfield> and <structfield>size</structfield> - fields with a handle for the newly created GEM object and its line - pitch and size in bytes. - </para> - </listitem> - <listitem> - <synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev, - uint32_t handle);</synopsis> - <para> - The <methodname>dumb_destroy</methodname> operation destroys a dumb - GEM object created by <methodname>dumb_create</methodname>. - </para> - </listitem> - <listitem> - <synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev, - uint32_t handle, uint64_t *offset);</synopsis> - <para> - The <methodname>dumb_map_offset</methodname> operation associates an - mmap fake offset with the GEM object given by the handle and returns - it. Drivers must use the - <function>drm_gem_create_mmap_offset</function> function to - associate the fake offset as described in - <xref linkend="drm-gem-objects-mapping"/>. - </para> - </listitem> - </itemizedlist> - </sect3> - <sect3> <title>Memory Coherency</title> <para> When mapped to the device or used in a command buffer, backing pages @@ -924,7 +871,99 @@ char *date;</synopsis> abstracted from the client in libdrm. </para> </sect3> - </sect2> + <sect3> + <title>GEM Function Reference</title> +!Edrivers/gpu/drm/drm_gem.c + </sect3> + </sect2> + <sect2> + <title>VMA Offset Manager</title> +!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager +!Edrivers/gpu/drm/drm_vma_manager.c +!Iinclude/drm/drm_vma_manager.h + </sect2> + <sect2 id="drm-prime-support"> + <title>PRIME Buffer Sharing</title> + <para> + PRIME is the cross device buffer sharing framework in drm, originally + created for the OPTIMUS range of multi-gpu platforms. To userspace + PRIME buffers are dma-buf based file descriptors. + </para> + <sect3> + <title>Overview and Driver Interface</title> + <para> + Similar to GEM global names, PRIME file descriptors are + also used to share buffer objects across processes. They offer + additional security: as file descriptors must be explicitly sent over + UNIX domain sockets to be shared between applications, they can't be + guessed like the globally unique GEM names. + </para> + <para> + Drivers that support the PRIME + API must set the DRIVER_PRIME bit in the struct + <structname>drm_driver</structname> + <structfield>driver_features</structfield> field, and implement the + <methodname>prime_handle_to_fd</methodname> and + <methodname>prime_fd_to_handle</methodname> operations. + </para> + <para> + <synopsis>int (*prime_handle_to_fd)(struct drm_device *dev, + struct drm_file *file_priv, uint32_t handle, + uint32_t flags, int *prime_fd); +int (*prime_fd_to_handle)(struct drm_device *dev, + struct drm_file *file_priv, int prime_fd, + uint32_t *handle);</synopsis> + Those two operations convert a handle to a PRIME file descriptor and + vice versa. Drivers must use the kernel dma-buf buffer sharing framework + to manage the PRIME file descriptors. Similar to the mode setting + API PRIME is agnostic to the underlying buffer object manager, as + long as handles are 32bit unsigned integers. + </para> + <para> + While non-GEM drivers must implement the operations themselves, GEM + drivers must use the <function>drm_gem_prime_handle_to_fd</function> + and <function>drm_gem_prime_fd_to_handle</function> helper functions. + Those helpers rely on the driver + <methodname>gem_prime_export</methodname> and + <methodname>gem_prime_import</methodname> operations to create a dma-buf + instance from a GEM object (dma-buf exporter role) and to create a GEM + object from a dma-buf instance (dma-buf importer role). + </para> + <para> + <synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev, + struct drm_gem_object *obj, + int flags); +struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev, + struct dma_buf *dma_buf);</synopsis> + These two operations are mandatory for GEM drivers that support + PRIME. + </para> + </sect3> + <sect3> + <title>PRIME Helper Functions</title> +!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers + </sect3> + </sect2> + <sect2> + <title>PRIME Function References</title> +!Edrivers/gpu/drm/drm_prime.c + </sect2> + <sect2> + <title>DRM MM Range Allocator</title> + <sect3> + <title>Overview</title> +!Pdrivers/gpu/drm/drm_mm.c Overview + </sect3> + <sect3> + <title>LRU Scan/Eviction Support</title> +!Pdrivers/gpu/drm/drm_mm.c lru scan roaster + </sect3> + </sect2> + <sect2> + <title>DRM MM Range Allocator Function References</title> +!Edrivers/gpu/drm/drm_mm.c +!Iinclude/drm/drm_mm.h + </sect2> </sect1> <!-- Internals: mode setting --> @@ -953,6 +992,11 @@ int max_width, max_height;</synopsis> </listitem> </itemizedlist> <sect2> + <title>Display Modes Function Reference</title> +!Iinclude/drm/drm_modes.h +!Edrivers/gpu/drm/drm_modes.c + </sect2> + <sect2> <title>Frame Buffer Creation</title> <synopsis>struct drm_framebuffer *(*fb_create)(struct drm_device *dev, struct drm_file *file_priv, @@ -968,9 +1012,11 @@ int max_width, max_height;</synopsis> Frame buffers rely on the underneath memory manager for low-level memory operations. When creating a frame buffer applications pass a memory handle (or a list of memory handles for multi-planar formats) through - the <parameter>drm_mode_fb_cmd2</parameter> argument. This document - assumes that the driver uses GEM, those handles thus reference GEM - objects. + the <parameter>drm_mode_fb_cmd2</parameter> argument. For drivers using + GEM as their userspace buffer management interface this would be a GEM + handle. Drivers are however free to use their own backing storage object + handles, e.g. vmwgfx directly exposes special TTM handles to userspace + and so expects TTM handles in the create ioctl and not GEM handles. </para> <para> Drivers must first validate the requested frame buffer parameters passed @@ -992,7 +1038,7 @@ int max_width, max_height;</synopsis> </para> <para> - The initailization of the new framebuffer instance is finalized with a + The initialization of the new framebuffer instance is finalized with a call to <function>drm_framebuffer_init</function> which takes a pointer to DRM frame buffer operations (struct <structname>drm_framebuffer_funcs</structname>). Note that this function @@ -1042,7 +1088,7 @@ int max_width, max_height;</synopsis> <para> The lifetime of a drm framebuffer is controlled with a reference count, drivers can grab additional references with - <function>drm_framebuffer_reference</function> </para> and drop them + <function>drm_framebuffer_reference</function>and drop them again with <function>drm_framebuffer_unreference</function>. For driver-private framebuffers for which the last reference is never dropped (e.g. for the fbdev framebuffer when the struct @@ -1050,6 +1096,72 @@ int max_width, max_height;</synopsis> helper struct) drivers can manually clean up a framebuffer at module unload time with <function>drm_framebuffer_unregister_private</function>. + </para> + </sect2> + <sect2> + <title>Dumb Buffer Objects</title> + <para> + The KMS API doesn't standardize backing storage object creation and + leaves it to driver-specific ioctls. Furthermore actually creating a + buffer object even for GEM-based drivers is done through a + driver-specific ioctl - GEM only has a common userspace interface for + sharing and destroying objects. While not an issue for full-fledged + graphics stacks that include device-specific userspace components (in + libdrm for instance), this limit makes DRM-based early boot graphics + unnecessarily complex. + </para> + <para> + Dumb objects partly alleviate the problem by providing a standard + API to create dumb buffers suitable for scanout, which can then be used + to create KMS frame buffers. + </para> + <para> + To support dumb objects drivers must implement the + <methodname>dumb_create</methodname>, + <methodname>dumb_destroy</methodname> and + <methodname>dumb_map_offset</methodname> operations. + </para> + <itemizedlist> + <listitem> + <synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev, + struct drm_mode_create_dumb *args);</synopsis> + <para> + The <methodname>dumb_create</methodname> operation creates a driver + object (GEM or TTM handle) suitable for scanout based on the + width, height and depth from the struct + <structname>drm_mode_create_dumb</structname> argument. It fills the + argument's <structfield>handle</structfield>, + <structfield>pitch</structfield> and <structfield>size</structfield> + fields with a handle for the newly created object and its line + pitch and size in bytes. + </para> + </listitem> + <listitem> + <synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev, + uint32_t handle);</synopsis> + <para> + The <methodname>dumb_destroy</methodname> operation destroys a dumb + object created by <methodname>dumb_create</methodname>. + </para> + </listitem> + <listitem> + <synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev, + uint32_t handle, uint64_t *offset);</synopsis> + <para> + The <methodname>dumb_map_offset</methodname> operation associates an + mmap fake offset with the object given by the handle and returns + it. Drivers must use the + <function>drm_gem_create_mmap_offset</function> function to + associate the fake offset as described in + <xref linkend="drm-gem-objects-mapping"/>. + </para> + </listitem> + </itemizedlist> + <para> + Note that dumb objects may not be used for gpu acceleration, as has been + attempted on some ARM embedded platforms. Such drivers really must have + a hardware-specific ioctl to allocate suitable buffer objects. + </para> </sect2> <sect2> <title>Output Polling</title> @@ -1110,7 +1222,7 @@ int max_width, max_height;</synopsis> pointer to CRTC functions. </para> </sect3> - <sect3> + <sect3 id="drm-kms-crtcops"> <title>CRTC Operations</title> <sect4> <title>Set Configuration</title> @@ -1130,8 +1242,11 @@ int max_width, max_height;</synopsis> This operation is called with the mode config lock held. </para> <note><para> - FIXME: How should set_config interact with DPMS? If the CRTC is - suspended, should it be resumed? + Note that the drm core has no notion of restoring the mode setting + state after resume, since all resume handling is in the full + responsibility of the driver. The common mode setting helper library + though provides a helper which can be used for this: + <function>drm_helper_resume_force_mode</function>. </para></note> </sect4> <sect4> @@ -1248,15 +1363,47 @@ int max_width, max_height;</synopsis> optionally scale it to a destination size. The result is then blended with or overlayed on top of a CRTC. </para> + <para> + The DRM core recognizes three types of planes: + <itemizedlist> + <listitem> + DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC. Primary + planes are the planes operated upon by by CRTC modesetting and flipping + operations described in <xref linkend="drm-kms-crtcops"/>. + </listitem> + <listitem> + DRM_PLANE_TYPE_CURSOR represents a "cursor" plane for a CRTC. Cursor + planes are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and + DRM_IOCTL_MODE_CURSOR2 ioctls. + </listitem> + <listitem> + DRM_PLANE_TYPE_OVERLAY represents all non-primary, non-cursor planes. + Some drivers refer to these types of planes as "sprites" internally. + </listitem> + </itemizedlist> + For compatibility with legacy userspace, only overlay planes are made + available to userspace by default. Userspace clients may set the + DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that + they wish to receive a universal plane list containing all plane types. + </para> <sect3> <title>Plane Initialization</title> <para> - Planes are optional. To create a plane, a KMS drivers allocates and + To create a plane, a KMS drivers allocates and zeroes an instances of struct <structname>drm_plane</structname> (possibly as part of a larger structure) and registers it with a call - to <function>drm_plane_init</function>. The function takes a bitmask + to <function>drm_universal_plane_init</function>. The function takes a bitmask of the CRTCs that can be associated with the plane, a pointer to the - plane functions and a list of format supported formats. + plane functions, a list of format supported formats, and the type of + plane (primary, cursor, or overlay) being initialized. + </para> + <para> + Cursor and overlay planes are optional. All drivers should provide + one primary plane per CRTC (although this requirement may change in + the future); drivers that do not wish to provide special handling for + primary planes may make use of the helper functions described in + <xref linkend="drm-kms-planehelpers"/> to create and register a + primary plane with standard capabilities. </para> </sect3> <sect3> @@ -1680,6 +1827,12 @@ void intel_crt_init(struct drm_device *dev) <title>KMS API Functions</title> !Edrivers/gpu/drm/drm_crtc.c </sect2> + <sect2> + <title>KMS Locking</title> +!Pdrivers/gpu/drm/drm_modeset_lock.c kms locking +!Iinclude/drm/drm_modeset_lock.h +!Edrivers/gpu/drm/drm_modeset_lock.c + </sect2> </sect1> <!-- Internals: kms helper functions --> @@ -1687,7 +1840,7 @@ void intel_crt_init(struct drm_device *dev) <sect1> <title>Mode Setting Helper Functions</title> <para> - The CRTC, encoder and connector functions provided by the drivers + The plane, CRTC, encoder and connector functions provided by the drivers implement the DRM API. They're called by the DRM core and ioctl handlers to handle device state changes and configuration request. As implementing those functions often requires logic not specific to drivers, mid-layer @@ -1695,8 +1848,8 @@ void intel_crt_init(struct drm_device *dev) </para> <para> The DRM core contains one mid-layer implementation. The mid-layer provides - implementations of several CRTC, encoder and connector functions (called - from the top of the mid-layer) that pre-process requests and call + implementations of several plane, CRTC, encoder and connector functions + (called from the top of the mid-layer) that pre-process requests and call lower-level functions provided by the driver (at the bottom of the mid-layer). For instance, the <function>drm_crtc_helper_set_config</function> function can be used to @@ -1784,8 +1937,8 @@ void intel_crt_init(struct drm_device *dev) <para> The function filters out modes larger than <parameter>max_width</parameter> and <parameter>max_height</parameter> - if specified. It then calls the connector - <methodname>mode_valid</methodname> helper operation for each mode in + if specified. It then calls the optional connector + <methodname>mode_valid</methodname> helper operation for each mode in the probed list to check whether the mode is valid for the connector. </para> </listitem> @@ -2134,7 +2287,7 @@ void intel_crt_init(struct drm_device *dev) set the <structfield>display_info</structfield> <structfield>width_mm</structfield> and <structfield>height_mm</structfield> fields if they haven't been set - already (for instance at initilization time when a fixed-size panel is + already (for instance at initialization time when a fixed-size panel is attached to the connector). The mode <structfield>width_mm</structfield> and <structfield>height_mm</structfield> fields are only used internally during EDID parsing and should not be set when creating modes manually. @@ -2146,7 +2299,7 @@ void intel_crt_init(struct drm_device *dev) <para> Verify whether a mode is valid for the connector. Return MODE_OK for supported modes and one of the enum drm_mode_status values (MODE_*) - for unsupported modes. This operation is mandatory. + for unsupported modes. This operation is optional. </para> <para> As the mode rejection reason is currently not used beside for @@ -2168,6 +2321,11 @@ void intel_crt_init(struct drm_device *dev) !Edrivers/gpu/drm/drm_crtc_helper.c </sect2> <sect2> + <title>Output Probing Helper Functions Reference</title> +!Pdrivers/gpu/drm/drm_probe_helper.c output probing helper overview +!Edrivers/gpu/drm/drm_probe_helper.c + </sect2> + <sect2> <title>fbdev Helper Functions Reference</title> !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers !Edrivers/gpu/drm/drm_fb_helper.c @@ -2196,10 +2354,19 @@ void intel_crt_init(struct drm_device *dev) !Edrivers/gpu/drm/drm_flip_work.c </sect2> <sect2> - <title>VMA Offset Manager</title> -!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager -!Edrivers/gpu/drm/drm_vma_manager.c -!Iinclude/drm/drm_vma_manager.h + <title>HDMI Infoframes Helper Reference</title> + <para> + Strictly speaking this is not a DRM helper library but generally useable + by any driver interfacing with HDMI outputs like v4l or alsa drivers. + But it nicely fits into the overall topic of mode setting helper + libraries and hence is also included here. + </para> +!Iinclude/linux/hdmi.h +!Edrivers/video/hdmi.c + </sect2> + <sect2> + <title id="drm-kms-planehelpers">Plane Helper Reference</title> +!Edrivers/gpu/drm/drm_plane_helper.c Plane Helpers </sect2> </sect1> @@ -2223,7 +2390,7 @@ void intel_crt_init(struct drm_device *dev) first create properties and then create and associate individual instances of those properties to objects. A property can be instantiated multiple times and associated with different objects. Values are stored in property - instances, and all other property information are stored in the propery + instances, and all other property information are stored in the property and shared between all instances of the property. </para> <para> @@ -2317,6 +2484,863 @@ void intel_crt_init(struct drm_device *dev) pointer to the target object, a pointer to the previously created property and an initial instance value. </para> + <sect2> + <title>Existing KMS Properties</title> + <para> + The following table gives description of drm properties exposed by various + modules/drivers. + </para> + <table border="1" cellpadding="0" cellspacing="0"> + <tbody> + <tr style="font-weight: bold;"> + <td valign="top" >Owner Module/Drivers</td> + <td valign="top" >Group</td> + <td valign="top" >Property Name</td> + <td valign="top" >Type</td> + <td valign="top" >Property Values</td> + <td valign="top" >Object attached</td> + <td valign="top" >Description/Restrictions</td> + </tr> + <tr> + <td rowspan="20" valign="top" >DRM</td> + <td rowspan="2" valign="top" >Generic</td> + <td valign="top" >“EDID”</td> + <td valign="top" >BLOB | IMMUTABLE</td> + <td valign="top" >0</td> + <td valign="top" >Connector</td> + <td valign="top" >Contains id of edid blob ptr object.</td> + </tr> + <tr> + <td valign="top" >“DPMS”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ “On”, “Standby”, “Suspend”, “Off” }</td> + <td valign="top" >Connector</td> + <td valign="top" >Contains DPMS operation mode value.</td> + </tr> + <tr> + <td rowspan="1" valign="top" >Plane</td> + <td valign="top" >“type”</td> + <td valign="top" >ENUM | IMMUTABLE</td> + <td valign="top" >{ "Overlay", "Primary", "Cursor" }</td> + <td valign="top" >Plane</td> + <td valign="top" >Plane type</td> + </tr> + <tr> + <td rowspan="2" valign="top" >DVI-I</td> + <td valign="top" >“subconnector”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ “Unknown”, “DVI-D”, “DVI-A” }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“select subconnector”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ “Automatic”, “DVI-D”, “DVI-A” }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="13" valign="top" >TV</td> + <td valign="top" >“subconnector”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "Unknown", "Composite", "SVIDEO", "Component", "SCART" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“select subconnector”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "Automatic", "Composite", "SVIDEO", "Component", "SCART" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“mode”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“left margin”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=100</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“right margin”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=100</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“top margin”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=100</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“bottom margin”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=100</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“brightness”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=100</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“contrast”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=100</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“flicker reduction”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=100</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“overscan”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=100</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“saturation”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=100</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“hue”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=100</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="2" valign="top" >Optional</td> + <td valign="top" >“scaling mode”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“dirty”</td> + <td valign="top" >ENUM | IMMUTABLE</td> + <td valign="top" >{ "Off", "On", "Annotate" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="21" valign="top" >i915</td> + <td rowspan="3" valign="top" >Generic</td> + <td valign="top" >"Broadcast RGB"</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "Automatic", "Full", "Limited 16:235" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“audio”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "force-dvi", "off", "auto", "on" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >Standard name as in DRM</td> + <td valign="top" >Standard type as in DRM</td> + <td valign="top" >Standard value as in DRM</td> + <td valign="top" >Standard Object as in DRM</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="17" valign="top" >SDVO-TV</td> + <td valign="top" >“mode”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"left_margin"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"right_margin"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"top_margin"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"bottom_margin"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“hpos”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“vpos”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“contrast”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“saturation”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“hue”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“sharpness”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“flicker_filter”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“flicker_filter_adaptive”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“flicker_filter_2d”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“tv_chroma_filter”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“tv_luma_filter”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“dot_crawl”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=1</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >SDVO-TV/LVDS</td> + <td valign="top" >“brightness”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="3" valign="top" >CDV gma-500</td> + <td rowspan="3" valign="top" >Generic</td> + <td valign="top" >"Broadcast RGB"</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ “Full”, “Limited 16:235” }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"Broadcast RGB"</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ “off”, “auto”, “on” }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >Standard name as in DRM</td> + <td valign="top" >Standard type as in DRM</td> + <td valign="top" >Standard value as in DRM</td> + <td valign="top" >Standard Object as in DRM</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="20" valign="top" >Poulsbo</td> + <td rowspan="2" valign="top" >Generic</td> + <td valign="top" >“backlight”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=100</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >Standard name as in DRM</td> + <td valign="top" >Standard type as in DRM</td> + <td valign="top" >Standard value as in DRM</td> + <td valign="top" >Standard Object as in DRM</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="17" valign="top" >SDVO-TV</td> + <td valign="top" >“mode”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"left_margin"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"right_margin"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"top_margin"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"bottom_margin"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“hpos”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“vpos”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“contrast”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“saturation”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“hue”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“sharpness”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“flicker_filter”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“flicker_filter_adaptive”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“flicker_filter_2d”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“tv_chroma_filter”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“tv_luma_filter”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“dot_crawl”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=1</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >SDVO-TV/LVDS</td> + <td valign="top" >“brightness”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max= SDVO dependent</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="11" valign="top" >armada</td> + <td rowspan="2" valign="top" >CRTC</td> + <td valign="top" >"CSC_YUV"</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "Auto" , "CCIR601", "CCIR709" }</td> + <td valign="top" >CRTC</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"CSC_RGB"</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "Auto", "Computer system", "Studio" }</td> + <td valign="top" >CRTC</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="9" valign="top" >Overlay</td> + <td valign="top" >"colorkey"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0xffffff</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"colorkey_min"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0xffffff</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"colorkey_max"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0xffffff</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"colorkey_val"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0xffffff</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"colorkey_alpha"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0xffffff</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"colorkey_mode"</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "disabled", "Y component", "U component" + , "V component", "RGB", “R component", "G component", "B component" }</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"brightness"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=256 + 255</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"contrast"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0x7fff</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"saturation"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0x7fff</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="2" valign="top" >exynos</td> + <td valign="top" >CRTC</td> + <td valign="top" >“mode”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "normal", "blank" }</td> + <td valign="top" >CRTC</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >Overlay</td> + <td valign="top" >“zpos”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=MAX_PLANE-1</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="3" valign="top" >i2c/ch7006_drv</td> + <td valign="top" >Generic</td> + <td valign="top" >“scale”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=2</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="2" valign="top" >TV</td> + <td valign="top" >Standard names as in DRM</td> + <td valign="top" >Standard types as in DRM</td> + <td valign="top" >Standard Values as in DRM</td> + <td valign="top" >Standard object as in DRM</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“mode”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc" + , "PAL-60", "NTSC-M", "NTSC-J" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="16" valign="top" >nouveau</td> + <td rowspan="6" valign="top" >NV10 Overlay</td> + <td valign="top" >"colorkey"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0x01ffffff</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“contrast”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=8192-1</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“brightness”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=1024</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“hue”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=359</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“saturation”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=8192-1</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“iturbt_709”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=1</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="2" valign="top" >Nv04 Overlay</td> + <td valign="top" >“colorkey”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0x01ffffff</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“brightness”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=1024</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="7" valign="top" >Display</td> + <td valign="top" >“dithering mode”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "auto", "off", "on" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“dithering depth”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "auto", "off", "on", "static 2x2", "dynamic 2x2", "temporal" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“underscan”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "auto", "6 bpc", "8 bpc" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“underscan hborder”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=128</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“underscan vborder”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=128</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“vibrant hue”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=180</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“color vibrance”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=200</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >Generic</td> + <td valign="top" >Standard name as in DRM</td> + <td valign="top" >Standard type as in DRM</td> + <td valign="top" >Standard value as in DRM</td> + <td valign="top" >Standard Object as in DRM</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="2" valign="top" >omap</td> + <td rowspan="2" valign="top" >Generic</td> + <td valign="top" >“rotation”</td> + <td valign="top" >BITMASK</td> + <td valign="top" >{ 0, "rotate-0" }, + { 1, "rotate-90" }, + { 2, "rotate-180" }, + { 3, "rotate-270" }, + { 4, "reflect-x" }, + { 5, "reflect-y" }</td> + <td valign="top" >CRTC, Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >“zorder”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=3</td> + <td valign="top" >CRTC, Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >qxl</td> + <td valign="top" >Generic</td> + <td valign="top" >“hotplug_mode_update"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=1</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="10" valign="top" >radeon</td> + <td valign="top" >DVI-I</td> + <td valign="top" >“coherent”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=1</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >DAC enable load detect</td> + <td valign="top" >“load detection”</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=1</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >TV Standard</td> + <td valign="top" >"tv standard"</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "ntsc", "pal", "pal-m", "pal-60", "ntsc-j" + , "scart-pal", "pal-cn", "secam" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >legacy TMDS PLL detect</td> + <td valign="top" >"tmds_pll"</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "driver", "bios" }</td> + <td valign="top" >-</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="3" valign="top" >Underscan</td> + <td valign="top" >"underscan"</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "off", "on", "auto" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"underscan hborder"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=128</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"underscan vborder"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=128</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >Audio</td> + <td valign="top" >“audio”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "off", "on", "auto" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >FMT Dithering</td> + <td valign="top" >“dither”</td> + <td valign="top" >ENUM</td> + <td valign="top" >{ "off", "on" }</td> + <td valign="top" >Connector</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >Generic</td> + <td valign="top" >Standard name as in DRM</td> + <td valign="top" >Standard type as in DRM</td> + <td valign="top" >Standard value as in DRM</td> + <td valign="top" >Standard Object as in DRM</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td rowspan="3" valign="top" >rcar-du</td> + <td rowspan="3" valign="top" >Generic</td> + <td valign="top" >"alpha"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=255</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"colorkey"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=0, Max=0x01ffffff</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + <tr> + <td valign="top" >"zpos"</td> + <td valign="top" >RANGE</td> + <td valign="top" >Min=1, Max=7</td> + <td valign="top" >Plane</td> + <td valign="top" >TBD</td> + </tr> + </tbody> + </table> + </sect2> </sect1> <!-- Internals: vertical blanking --> @@ -2394,6 +3418,10 @@ void (*disable_vblank) (struct drm_device *dev, int crtc);</synopsis> with a call to <function>drm_vblank_cleanup</function> in the driver <methodname>unload</methodname> operation handler. </para> + <sect2> + <title>Vertical Blanking and Interrupt Handling Functions Reference</title> +!Edrivers/gpu/drm/drm_irq.c + </sect2> </sect1> <!-- Internals: open/close, file operations and ioctls --> @@ -2561,42 +3589,44 @@ int num_ioctls;</synopsis> </para> </sect2> </sect1> - <sect1> - <title>Command submission & fencing</title> + <title>Legacy Support Code</title> <para> - This should cover a few device-specific command submission - implementations. + The section very briefly covers some of the old legacy support code which + is only used by old DRM drivers which have done a so-called shadow-attach + to the underlying device instead of registering as a real driver. This + also includes some of the old generic buffer management and command + submission code. Do not use any of this in new and modern drivers. </para> - </sect1> - <!-- Internals: suspend/resume --> - - <sect1> - <title>Suspend/Resume</title> - <para> - The DRM core provides some suspend/resume code, but drivers wanting full - suspend/resume support should provide save() and restore() functions. - These are called at suspend, hibernate, or resume time, and should perform - any state save or restore required by your device across suspend or - hibernate states. - </para> - <synopsis>int (*suspend) (struct drm_device *, pm_message_t state); -int (*resume) (struct drm_device *);</synopsis> - <para> - Those are legacy suspend and resume methods. New driver should use the - power management interface provided by their bus type (usually through - the struct <structname>device_driver</structname> dev_pm_ops) and set - these methods to NULL. - </para> - </sect1> + <sect2> + <title>Legacy Suspend/Resume</title> + <para> + The DRM core provides some suspend/resume code, but drivers wanting full + suspend/resume support should provide save() and restore() functions. + These are called at suspend, hibernate, or resume time, and should perform + any state save or restore required by your device across suspend or + hibernate states. + </para> + <synopsis>int (*suspend) (struct drm_device *, pm_message_t state); + int (*resume) (struct drm_device *);</synopsis> + <para> + Those are legacy suspend and resume methods which + <emphasis>only</emphasis> work with the legacy shadow-attach driver + registration functions. New driver should use the power management + interface provided by their bus type (usually through + the struct <structname>device_driver</structname> dev_pm_ops) and set + these methods to NULL. + </para> + </sect2> - <sect1> - <title>DMA services</title> - <para> - This should cover how DMA mapping etc. is supported by the core. - These functions are deprecated and should not be used. - </para> + <sect2> + <title>Legacy DMA Services</title> + <para> + This should cover how DMA mapping etc. is supported by the core. + These functions are deprecated and should not be used. + </para> + </sect2> </sect1> </chapter> @@ -2658,8 +3688,8 @@ int (*resume) (struct drm_device *);</synopsis> DRM core provides multiple character-devices for user-space to use. Depending on which device is opened, user-space can perform a different set of operations (mainly ioctls). The primary node is always created - and called <term>card<num></term>. Additionally, a currently - unused control node, called <term>controlD<num></term> is also + and called card<num>. Additionally, a currently + unused control node, called controlD<num> is also created. The primary node provides all legacy operations and historically was the only interface used by userspace. With KMS, the control node was introduced. However, the planned KMS control interface @@ -2674,21 +3704,21 @@ int (*resume) (struct drm_device *);</synopsis> nodes were introduced. Render nodes solely serve render clients, that is, no modesetting or privileged ioctls can be issued on render nodes. Only non-global rendering commands are allowed. If a driver supports - render nodes, it must advertise it via the <term>DRIVER_RENDER</term> + render nodes, it must advertise it via the DRIVER_RENDER DRM driver capability. If not supported, the primary node must be used for render clients together with the legacy drmAuth authentication procedure. </para> <para> If a driver advertises render node support, DRM core will create a - separate render node called <term>renderD<num></term>. There will + separate render node called renderD<num>. There will be one render node per device. No ioctls except PRIME-related ioctls - will be allowed on this node. Especially <term>GEM_OPEN</term> will be + will be allowed on this node. Especially GEM_OPEN will be explicitly prohibited. Render nodes are designed to avoid the buffer-leaks, which occur if clients guess the flink names or mmap offsets on the legacy interface. Additionally to this basic interface, drivers must mark their driver-dependent render-only ioctls as - <term>DRM_RENDER_ALLOW</term> so render clients can use them. Driver + DRM_RENDER_ALLOW so render clients can use them. Driver authors must be careful not to allow any privileged ioctls on render nodes. </para> @@ -2734,30 +3764,182 @@ int (*resume) (struct drm_device *);</synopsis> <term>DRM_IOCTL_MODESET_CTL</term> <listitem> <para> - This should be called by application level drivers before and - after mode setting, since on many devices the vertical blank - counter is reset at that time. Internally, the DRM snapshots - the last vblank count when the ioctl is called with the - _DRM_PRE_MODESET command, so that the counter won't go backwards - (which is dealt with when _DRM_POST_MODESET is used). + This was only used for user-mode-settind drivers around + modesetting changes to allow the kernel to update the vblank + interrupt after mode setting, since on many devices the vertical + blank counter is reset to 0 at some point during modeset. Modern + drivers should not call this any more since with kernel mode + setting it is a no-op. </para> </listitem> </varlistentry> </variablelist> -<!--!Edrivers/char/drm/drm_irq.c--> </para> </sect1> </chapter> +</part> +<part id="drmDrivers"> + <title>DRM Drivers</title> - <!-- API reference --> + <partintro> + <para> + This second part of the DRM Developer's Guide documents driver code, + implementation details and also all the driver-specific userspace + interfaces. Especially since all hardware-acceleration interfaces to + userspace are driver specific for efficiency and other reasons these + interfaces can be rather substantial. Hence every driver has its own + chapter. + </para> + </partintro> - <appendix id="drmDriverApi"> - <title>DRM Driver API</title> + <chapter id="drmI915"> + <title>drm/i915 Intel GFX Driver</title> <para> - Include auto-generated API reference here (need to reference it - from paragraphs above too). + The drm/i915 driver supports all (with the exception of some very early + models) integrated GFX chipsets with both Intel display and rendering + blocks. This excludes a set of SoC platforms with an SGX rendering unit, + those have basic support through the gma500 drm driver. </para> - </appendix> + <sect1> + <title>Display Hardware Handling</title> + <para> + This section covers everything related to the display hardware including + the mode setting infrastructure, plane, sprite and cursor handling and + display, output probing and related topics. + </para> + <sect2> + <title>Mode Setting Infrastructure</title> + <para> + The i915 driver is thus far the only DRM driver which doesn't use the + common DRM helper code to implement mode setting sequences. Thus it + has its own tailor-made infrastructure for executing a display + configuration change. + </para> + </sect2> + <sect2> + <title>Plane Configuration</title> + <para> + This section covers plane configuration and composition with the + primary plane, sprites, cursors and overlays. This includes the + infrastructure to do atomic vsync'ed updates of all this state and + also tightly coupled topics like watermark setup and computation, + framebuffer compression and panel self refresh. + </para> + </sect2> + <sect2> + <title>Output Probing</title> + <para> + This section covers output probing and related infrastructure like the + hotplug interrupt storm detection and mitigation code. Note that the + i915 driver still uses most of the common DRM helper code for output + probing, so those sections fully apply. + </para> + </sect2> + <sect2> + <title>DPIO</title> +!Pdrivers/gpu/drm/i915/i915_reg.h DPIO + <table id="dpiox2"> + <title>Dual channel PHY (VLV/CHV)</title> + <tgroup cols="8"> + <colspec colname="c0" /> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <colspec colname="c4" /> + <colspec colname="c5" /> + <colspec colname="c6" /> + <colspec colname="c7" /> + <spanspec spanname="ch0" namest="c0" nameend="c3" /> + <spanspec spanname="ch1" namest="c4" nameend="c7" /> + <spanspec spanname="ch0pcs01" namest="c0" nameend="c1" /> + <spanspec spanname="ch0pcs23" namest="c2" nameend="c3" /> + <spanspec spanname="ch1pcs01" namest="c4" nameend="c5" /> + <spanspec spanname="ch1pcs23" namest="c6" nameend="c7" /> + <thead> + <row> + <entry spanname="ch0">CH0</entry> + <entry spanname="ch1">CH1</entry> + </row> + </thead> + <tbody valign="top" align="center"> + <row> + <entry spanname="ch0">CMN/PLL/REF</entry> + <entry spanname="ch1">CMN/PLL/REF</entry> + </row> + <row> + <entry spanname="ch0pcs01">PCS01</entry> + <entry spanname="ch0pcs23">PCS23</entry> + <entry spanname="ch1pcs01">PCS01</entry> + <entry spanname="ch1pcs23">PCS23</entry> + </row> + <row> + <entry>TX0</entry> + <entry>TX1</entry> + <entry>TX2</entry> + <entry>TX3</entry> + <entry>TX0</entry> + <entry>TX1</entry> + <entry>TX2</entry> + <entry>TX3</entry> + </row> + <row> + <entry spanname="ch0">DDI0</entry> + <entry spanname="ch1">DDI1</entry> + </row> + </tbody> + </tgroup> + </table> + <table id="dpiox1"> + <title>Single channel PHY (CHV)</title> + <tgroup cols="4"> + <colspec colname="c0" /> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <spanspec spanname="ch0" namest="c0" nameend="c3" /> + <spanspec spanname="ch0pcs01" namest="c0" nameend="c1" /> + <spanspec spanname="ch0pcs23" namest="c2" nameend="c3" /> + <thead> + <row> + <entry spanname="ch0">CH0</entry> + </row> + </thead> + <tbody valign="top" align="center"> + <row> + <entry spanname="ch0">CMN/PLL/REF</entry> + </row> + <row> + <entry spanname="ch0pcs01">PCS01</entry> + <entry spanname="ch0pcs23">PCS23</entry> + </row> + <row> + <entry>TX0</entry> + <entry>TX1</entry> + <entry>TX2</entry> + <entry>TX3</entry> + </row> + <row> + <entry spanname="ch0">DDI2</entry> + </row> + </tbody> + </tgroup> + </table> + </sect2> + </sect1> + <sect1> + <title>Memory Management and Command Submission</title> + <para> + This sections covers all things related to the GEM implementation in the + i915 driver. + </para> + <sect2> + <title>Batchbuffer Parsing</title> +!Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser +!Idrivers/gpu/drm/i915/i915_cmd_parser.c + </sect2> + </sect1> + </chapter> +</part> </book> diff --git a/Documentation/DocBook/filesystems.tmpl b/Documentation/DocBook/filesystems.tmpl index 4f67683..bcdfdb9 100644 --- a/Documentation/DocBook/filesystems.tmpl +++ b/Documentation/DocBook/filesystems.tmpl @@ -62,7 +62,7 @@ !Efs/mpage.c !Efs/namei.c !Efs/buffer.c -!Efs/bio.c +!Eblock/bio.c !Efs/seq_file.c !Efs/filesystems.c !Efs/fs-writeback.c diff --git a/Documentation/DocBook/gadget.tmpl b/Documentation/DocBook/gadget.tmpl index 4017f14..6416292 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> @@ -708,7 +708,7 @@ hardware level details could be very different. <para>Systems need specialized hardware support to implement OTG, notably including a special <emphasis>Mini-AB</emphasis> jack -and associated transciever to support <emphasis>Dual-Role</emphasis> +and associated transceiver to support <emphasis>Dual-Role</emphasis> operation: they can act either as a host, using the standard Linux-USB host side driver stack, diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl index 46347f6..59fb5c0 100644 --- a/Documentation/DocBook/genericirq.tmpl +++ b/Documentation/DocBook/genericirq.tmpl @@ -182,7 +182,7 @@ <para> Each interrupt is described by an interrupt descriptor structure irq_desc. The interrupt is referenced by an 'unsigned int' numeric - value which selects the corresponding interrupt decription structure + value which selects the corresponding interrupt description structure in the descriptor structures array. The descriptor structure contains status information and pointers to the interrupt flow method and the interrupt chip structure @@ -470,7 +470,7 @@ if (desc->irq_data.chip->irq_eoi) <para> To avoid copies of identical implementations of IRQ chips the core provides a configurable generic interrupt chip - implementation. Developers should check carefuly whether the + implementation. Developers should check carefully whether the generic chip fits their needs before implementing the same functionality slightly differently themselves. </para> diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl index d0758b2..e84f094 100644 --- a/Documentation/DocBook/kernel-hacking.tmpl +++ b/Documentation/DocBook/kernel-hacking.tmpl @@ -671,7 +671,7 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress); <sect1 id="routines-local-irqs"> <title><function>local_irq_save()</function>/<function>local_irq_restore()</function> - <filename class="headerfile">include/asm/system.h</filename> + <filename class="headerfile">include/linux/irqflags.h</filename> </title> <para> @@ -850,16 +850,6 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress); <returnvalue>-ERESTARTSYS</returnvalue> if a signal is received. The <function>wait_event()</function> version ignores signals. </para> - <para> - Do not use the <function>sleep_on()</function> function family - - it is very easy to accidentally introduce races; almost certainly - one of the <function>wait_event()</function> family will do, or a - loop around <function>schedule_timeout()</function>. If you choose - to loop around <function>schedule_timeout()</function> remember - you must set the task state (with - <function>set_current_state()</function>) on each iteration to avoid - busy-looping. - </para> </sect1> diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index 19f2a5a..e584ee1 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl @@ -1760,7 +1760,7 @@ as it would be on UP. </para> <para> -There is a furthur optimization possible here: remember our original +There is a further optimization possible here: remember our original cache code, where there were no reference counts and the caller simply held the lock whenever using the object? This is still possible: if you hold the lock, no one can delete the object, so you don't need to diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index deb71ba..d7fcdc5 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -677,7 +677,7 @@ and other resources, etc. <listitem> <para> - ATA_QCFLAG_ACTIVE is clared from qc->flags. + ATA_QCFLAG_ACTIVE is cleared from qc->flags. </para> </listitem> @@ -708,7 +708,7 @@ and other resources, etc. <listitem> <para> - qc->waiting is claread & completed (in that order). + qc->waiting is cleared & completed (in that order). </para> </listitem> @@ -1163,7 +1163,7 @@ and other resources, etc. <para> Once sense data is acquired, this type of errors can be - handled similary to other SCSI errors. Note that sense data + handled similarly to other SCSI errors. Note that sense data may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR && ASC/ASCQ 47h/00h SCSI PARITY ERROR). In such cases, the error should be considered as an ATA bus error and diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index f9fd615..df2962d 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" @@ -195,15 +195,15 @@ DVB_DOCUMENTED = \ # install_media_images = \ - $(Q)cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api + $(Q)-cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api $(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64 $(Q)base64 -d $< >$@ $(MEDIA_OBJ_DIR)/v4l2.xml: $(OBJIMGFILES) @$($(quiet)gen_xml) - @(ln -sf $(MEDIA_SRC_DIR)/v4l/*xml $(MEDIA_OBJ_DIR)/) - @(ln -sf $(MEDIA_SRC_DIR)/dvb/*xml $(MEDIA_OBJ_DIR)/) + @(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/v4l/*xml $(MEDIA_OBJ_DIR)/) + @(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/dvb/*xml $(MEDIA_OBJ_DIR)/) $(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/uapi/linux/videodev2.h $(MEDIA_OBJ_DIR)/v4l2.xml @$($(quiet)gen_xml) diff --git a/Documentation/DocBook/media/dvb/demux.xml b/Documentation/DocBook/media/dvb/demux.xml index 86de89c..c8683d6 100644 --- a/Documentation/DocBook/media/dvb/demux.xml +++ b/Documentation/DocBook/media/dvb/demux.xml @@ -1042,7 +1042,14 @@ role="subsection"><title>DMX_ADD_PID</title> </para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> -<para>This ioctl is undocumented. Documentation is welcome.</para> +<para>This ioctl call allows to add multiple PIDs to a transport stream filter +previously set up with DMX_SET_PES_FILTER and output equal to DMX_OUT_TSDEMUX_TAP. +</para></entry></row><row><entry align="char"><para> +It is used by readers of /dev/dvb/adapterX/demuxY. +</para></entry></row><row><entry align="char"><para> +It may be called at any time, i.e. before or after the first filter on the +shared file descriptor was started. It makes it possible to record multiple +services without the need to de-multiplex or re-multiplex TS packets.</para> </entry> </row></tbody></tgroup></informaltable> <para>SYNOPSIS @@ -1075,7 +1082,7 @@ role="subsection"><title>DMX_ADD_PID</title> </para> </entry><entry align="char"> -<para>Undocumented.</para> +<para>PID number to be filtered.</para> </entry> </row></tbody></tgroup></informaltable> &return-value-dvb; @@ -1087,7 +1094,15 @@ role="subsection"><title>DMX_REMOVE_PID</title> </para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> -<para>This ioctl is undocumented. Documentation is welcome.</para> +<para>This ioctl call allows to remove a PID when multiple PIDs are set on a +transport stream filter, e. g. a filter previously set up with output equal to +DMX_OUT_TSDEMUX_TAP, created via either DMX_SET_PES_FILTER or DMX_ADD_PID. +</para></entry></row><row><entry align="char"><para> +It is used by readers of /dev/dvb/adapterX/demuxY. +</para></entry></row><row><entry align="char"><para> +It may be called at any time, i.e. before or after the first filter on the +shared file descriptor was started. It makes it possible to record multiple +services without the need to de-multiplex or re-multiplex TS packets.</para> </entry> </row></tbody></tgroup></informaltable> <para>SYNOPSIS @@ -1120,7 +1135,7 @@ role="subsection"><title>DMX_REMOVE_PID</title> </para> </entry><entry align="char"> -<para>Undocumented.</para> +<para>PID of the PES filter to be removed.</para> </entry> </row></tbody></tgroup></informaltable> &return-value-dvb; diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml index 0197bcc..4c15396 100644 --- a/Documentation/DocBook/media/dvb/dvbapi.xml +++ b/Documentation/DocBook/media/dvb/dvbapi.xml @@ -18,7 +18,7 @@ <firstname>Mauro</firstname> <othername role="mi">Carvalho</othername> <surname>Chehab</surname> -<affiliation><address><email>mchehab@redhat.com</email></address></affiliation> +<affiliation><address><email>m.chehab@samsung.com</email></address></affiliation> <contrib>Ported document to Docbook XML.</contrib> </author> </authorgroup> @@ -28,7 +28,7 @@ <holder>Convergence GmbH</holder> </copyright> <copyright> - <year>2009-2012</year> + <year>2009-2014</year> <holder>Mauro Carvalho Chehab</holder> </copyright> diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index 24c22ca..948ddaa 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/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml index 0d6e81b..8a6a6ff 100644 --- a/Documentation/DocBook/media/dvb/frontend.xml +++ b/Documentation/DocBook/media/dvb/frontend.xml @@ -744,7 +744,7 @@ typedef enum fe_hierarchy { </para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> -<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, int16_t +<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, uint16_t ⋆snr);</para> </entry> </row></tbody></tgroup></informaltable> @@ -766,7 +766,7 @@ typedef enum fe_hierarchy { </entry> </row><row><entry align="char"> -<para>int16_t *snr</para> +<para>uint16_t *snr</para> </entry><entry align="char"> <para>The signal-to-noise ratio is stored into *snr.</para> @@ -791,7 +791,7 @@ typedef enum fe_hierarchy { <informaltable><tgroup cols="1"><tbody><row><entry align="char"> <para>int ioctl( int fd, int request = - <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, int16_t ⋆strength);</para> + <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, uint16_t ⋆strength);</para> </entry> </row></tbody></tgroup></informaltable> @@ -814,7 +814,7 @@ typedef enum fe_hierarchy { </entry> </row><row><entry align="char"> -<para>int16_t *strength</para> +<para>uint16_t *strength</para> </entry><entry align="char"> <para>The signal strength value is stored into *strength.</para> diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index 1ddf354..71f6bf9 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -38,70 +38,41 @@ the basic concepts applicable to all devices.</para> <para>V4L2 drivers are implemented as kernel modules, loaded manually by the system administrator or automatically when a device is -first opened. The driver modules plug into the "videodev" kernel +first discovered. The driver modules plug into the "videodev" kernel module. It provides helper functions and a common application interface specified in this document.</para> <para>Each driver thus loaded registers one or more device nodes -with major number 81 and a minor number between 0 and 255. Assigning -minor numbers to V4L2 devices is entirely up to the system administrator, -this is primarily intended to solve conflicts between devices.<footnote> - <para>Access permissions are associated with character -device special files, hence we must ensure device numbers cannot -change with the module load order. To this end minor numbers are no -longer automatically assigned by the "videodev" module as in V4L but -requested by the driver. The defaults will suffice for most people -unless two drivers compete for the same minor numbers.</para> - </footnote> The module options to select minor numbers are named -after the device special file with a "_nr" suffix. For example "video_nr" -for <filename>/dev/video</filename> video capture devices. The number is -an offset to the base minor number associated with the device type. -<footnote> - <para>In earlier versions of the V4L2 API the module options -where named after the device special file with a "unit_" prefix, expressing -the minor number itself, not an offset. Rationale for this change is unknown. -Lastly the naming and semantics are just a convention among driver writers, -the point to note is that minor numbers are not supposed to be hardcoded -into drivers.</para> - </footnote> When the driver supports multiple devices of the same -type more than one minor number can be assigned, separated by commas: -<informalexample> +with major number 81 and a minor number between 0 and 255. Minor numbers +are allocated dynamically unless the kernel is compiled with the kernel +option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers are +allocated in ranges depending on the device node type (video, radio, etc.).</para> + + <para>Many drivers support "video_nr", "radio_nr" or "vbi_nr" +module options to select specific video/radio/vbi node numbers. This allows +the user to request that the device node is named e.g. /dev/video5 instead +of leaving it to chance. When the driver supports multiple devices of the same +type more than one device node number can be assigned, separated by commas: + <informalexample> <screen> -> insmod mydriver.o video_nr=0,1 radio_nr=0,1</screen> +> modprobe mydriver video_nr=0,1 radio_nr=0,1</screen> </informalexample></para> <para>In <filename>/etc/modules.conf</filename> this may be written as: <informalexample> <screen> -alias char-major-81-0 mydriver -alias char-major-81-1 mydriver -alias char-major-81-64 mydriver <co id="alias" /> -options mydriver video_nr=0,1 radio_nr=0,1 <co id="options" /> +options mydriver video_nr=0,1 radio_nr=0,1 </screen> - <calloutlist> - <callout arearefs="alias"> - <para>When an application attempts to open a device -special file with major number 81 and minor number 0, 1, or 64, load -"mydriver" (and the "videodev" module it depends upon).</para> - </callout> - <callout arearefs="options"> - <para>Register the first two video capture devices with -minor number 0 and 1 (base number is 0), the first two radio device -with minor number 64 and 65 (base 64).</para> - </callout> - </calloutlist> - </informalexample> When no minor number is given as module -option the driver supplies a default. <xref linkend="devices" /> -recommends the base minor numbers to be used for the various device -types. Obviously minor numbers must be unique. When the number is -already in use the <emphasis>offending device</emphasis> will not be -registered. <!-- Blessed by Linus Torvalds on -linux-kernel@vger.kernel.org, 2002-11-20. --></para> - - <para>By convention system administrators create various -character device special files with these major and minor numbers in -the <filename>/dev</filename> directory. The names recommended for the -different V4L2 device types are listed in <xref linkend="devices" />. + </informalexample> When no device node number is given as module +option the driver supplies a default.</para> + + <para>Normally udev will create the device nodes in /dev automatically +for you. If udev is not installed, then you need to enable the +CONFIG_VIDEO_FIXED_MINOR_RANGES kernel option in order to be able to correctly +relate a minor number to a device node number. I.e., you need to be certain +that minor number 5 maps to device node name video5. With this kernel option +different device types have different minor number ranges. These ranges are +listed in <xref linkend="devices" />. </para> <para>The creation of character special files (with @@ -110,85 +81,66 @@ devices cannot be opened by major and minor number. That means applications cannot <emphasis>reliable</emphasis> scan for loaded or installed drivers. The user must enter a device name, or the application can try the conventional device names.</para> - - <para>Under the device filesystem (devfs) the minor number -options are ignored. V4L2 drivers (or by proxy the "videodev" module) -automatically create the required device files in the -<filename>/dev/v4l</filename> directory using the conventional device -names above.</para> </section> <section id="related"> <title>Related Devices</title> - <para>Devices can support several related functions. For example -video capturing, video overlay and VBI capturing are related because -these functions share, amongst other, the same video input and tuner -frequency. V4L and earlier versions of V4L2 used the same device name -and minor number for video capturing and overlay, but different ones -for VBI. Experience showed this approach has several problems<footnote> - <para>Given a device file name one cannot reliable find -related devices. For once names are arbitrary and in a system with -multiple devices, where only some support VBI capturing, a -<filename>/dev/video2</filename> is not necessarily related to -<filename>/dev/vbi2</filename>. The V4L -<constant>VIDIOCGUNIT</constant> ioctl would require a search for a -device file with a particular major and minor number.</para> - </footnote>, and to make things worse the V4L videodev module -used to prohibit multiple opens of a device.</para> - - <para>As a remedy the present version of the V4L2 API relaxed the -concept of device types with specific names and minor numbers. For -compatibility with old applications drivers must still register different -minor numbers to assign a default function to the device. But if related -functions are supported by the driver they must be available under all -registered minor numbers. The desired function can be selected after -opening the device as described in <xref linkend="devices" />.</para> - - <para>Imagine a driver supporting video capturing, video -overlay, raw VBI capturing, and FM radio reception. It registers three -devices with minor number 0, 64 and 224 (this numbering scheme is -inherited from the V4L API). Regardless if -<filename>/dev/video</filename> (81, 0) or -<filename>/dev/vbi</filename> (81, 224) is opened the application can -select any one of the video capturing, overlay or VBI capturing -functions. Without programming (e. g. reading from the device -with <application>dd</application> or <application>cat</application>) -<filename>/dev/video</filename> captures video images, while -<filename>/dev/vbi</filename> captures raw VBI data. -<filename>/dev/radio</filename> (81, 64) is invariable a radio device, -unrelated to the video functions. Being unrelated does not imply the -devices can be used at the same time, however. The &func-open; -function may very well return an &EBUSY;.</para> + <para>Devices can support several functions. For example +video capturing, VBI capturing and radio support.</para> + + <para>The V4L2 API creates different nodes for each of these functions.</para> + + <para>The V4L2 API was designed with the idea that one device node could support +all functions. However, in practice this never worked: this 'feature' +was never used by applications and many drivers did not support it and if +they did it was certainly never tested. In addition, switching a device +node between different functions only works when using the streaming I/O +API, not with the read()/write() API.</para> + + <para>Today each device node supports just one function.</para> <para>Besides video input or output the hardware may also support audio sampling or playback. If so, these functions are -implemented as OSS or ALSA PCM devices and eventually OSS or ALSA -audio mixer. The V4L2 API makes no provisions yet to find these -related devices. If you have an idea please write to the linux-media -mailing list: &v4l-ml;.</para> +implemented as ALSA PCM devices with optional ALSA audio mixer +devices.</para> + + <para>One problem with all these devices is that the V4L2 API +makes no provisions to find these related devices. Some really +complex devices use the Media Controller (see <xref linkend="media_controller" />) +which can be used for this purpose. But most drivers do not use it, +and while some code exists that uses sysfs to discover related devices +(see libmedia_dev in the <ulink url="http://git.linuxtv.org/v4l-utils/">v4l-utils</ulink> +git repository), there is no library yet that can provide a single API towards +both Media Controller-based devices and devices that do not use the Media Controller. +If you want to work on this please write to the linux-media mailing list: &v4l-ml;.</para> </section> <section> <title>Multiple Opens</title> - <para>In general, V4L2 devices can be opened more than once. + <para>V4L2 devices can be opened more than once.<footnote><para> +There are still some old and obscure drivers that have not been updated to +allow for multiple opens. This implies that for such drivers &func-open; can +return an &EBUSY; when the device is already in use.</para></footnote> When this is supported by the driver, users can for example start a "panel" application to change controls like brightness or audio volume, while another application captures video and audio. In other words, panel -applications are comparable to an OSS or ALSA audio mixer application. -When a device supports multiple functions like capturing and overlay -<emphasis>simultaneously</emphasis>, multiple opens allow concurrent -use of the device by forked processes or specialized applications.</para> - - <para>Multiple opens are optional, although drivers should -permit at least concurrent accesses without data exchange, &ie; panel -applications. This implies &func-open; can return an &EBUSY; when the -device is already in use, as well as &func-ioctl; functions initiating -data exchange (namely the &VIDIOC-S-FMT; ioctl), and the &func-read; -and &func-write; functions.</para> - - <para>Mere opening a V4L2 device does not grant exclusive +applications are comparable to an ALSA audio mixer application. +Just opening a V4L2 device should not change the state of the device.<footnote> +<para>Unfortunately, opening a radio device often switches the state of the +device to radio mode in many drivers. This behavior should be fixed eventually +as it violates the V4L2 specification.</para></footnote></para> + + <para>Once an application has allocated the memory buffers needed for +streaming data (by calling the &VIDIOC-REQBUFS; or &VIDIOC-CREATE-BUFS; ioctls, +or implicitly by calling the &func-read; or &func-write; functions) that +application (filehandle) becomes the owner of the device. It is no longer +allowed to make changes that would affect the buffer sizes (e.g. by calling +the &VIDIOC-S-FMT; ioctl) and other applications are no longer allowed to allocate +buffers or start or stop streaming. The &EBUSY; will be returned instead.</para> + + <para>Merely opening a V4L2 device does not grant exclusive access.<footnote> <para>Drivers could recognize the <constant>O_EXCL</constant> open flag. Presently this is not required, @@ -206,12 +158,7 @@ additional access privileges using the priority mechanism described in <para>V4L2 drivers should not support multiple applications reading or writing the same data stream on a device by copying buffers, time multiplexing or similar means. This is better handled by -a proxy application in user space. When the driver supports stream -sharing anyway it must be implemented transparently. The V4L2 API does -not specify how conflicts are solved. <!-- For example O_EXCL when the -application does not want to be preempted, PROT_READ mmapped buffers -which can be mapped twice, what happens when image formats do not -match etc.--></para> +a proxy application in user space.</para> </section> <section> @@ -240,15 +187,15 @@ methods</link> supported by the device.</para> <para>Starting with kernel version 3.1, VIDIOC-QUERYCAP will return the V4L2 API version used by the driver, with generally matches the Kernel version. -There's no need of using &VIDIOC-QUERYCAP; to check if an specific ioctl is -supported, the V4L2 core now returns ENOIOCTLCMD if a driver doesn't provide +There's no need of using &VIDIOC-QUERYCAP; to check if a specific ioctl is +supported, the V4L2 core now returns ENOTTY if a driver doesn't provide support for an ioctl.</para> <para>Other features can be queried by calling the respective ioctl, for example &VIDIOC-ENUMINPUT; to learn about the number, types and names of video connectors on the device. Although abstraction is a major objective of this API, the -ioctl also allows driver specific applications to reliable identify +&VIDIOC-QUERYCAP; ioctl also allows driver specific applications to reliably identify the driver.</para> <para>All V4L2 drivers must support @@ -278,9 +225,7 @@ Applications requiring a different priority will usually call the &VIDIOC-QUERYCAP; ioctl.</para> <para>Ioctls changing driver properties, such as &VIDIOC-S-INPUT;, -return an &EBUSY; after another application obtained higher priority. -An event mechanism to notify applications about asynchronous property -changes has been proposed but not added yet.</para> +return an &EBUSY; after another application obtained higher priority.</para> </section> <section id="video"> @@ -288,9 +233,9 @@ changes has been proposed but not added yet.</para> <para>Video inputs and outputs are physical connectors of a device. These can be for example RF connectors (antenna/cable), CVBS -a.k.a. Composite Video, S-Video or RGB connectors. Only video and VBI -capture devices have inputs, output devices have outputs, at least one -each. Radio devices have no video inputs or outputs.</para> +a.k.a. Composite Video, S-Video or RGB connectors. Video and VBI +capture devices have inputs. Video and VBI output devices have outputs, +at least one each. Radio devices have no video inputs or outputs.</para> <para>To learn about the number and attributes of the available inputs and outputs applications can enumerate them with the @@ -299,30 +244,13 @@ available inputs and outputs applications can enumerate them with the ioctl also contains signal status information applicable when the current video input is queried.</para> - <para>The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctl return the + <para>The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctls return the index of the current video input or output. To select a different input or output applications call the &VIDIOC-S-INPUT; and -&VIDIOC-S-OUTPUT; ioctl. Drivers must implement all the input ioctls +&VIDIOC-S-OUTPUT; ioctls. Drivers must implement all the input ioctls when the device has one or more inputs, all the output ioctls when the device has one or more outputs.</para> - <!-- - <figure id=io-tree> - <title>Input and output enumeration is the root of most device properties.</title> - <mediaobject> - <imageobject> - <imagedata fileref="links.pdf" format="ps" /> - </imageobject> - <imageobject> - <imagedata fileref="links.gif" format="gif" /> - </imageobject> - <textobject> - <phrase>Links between various device property structures.</phrase> - </textobject> - </mediaobject> - </figure> - --> - <example> <title>Information about the current video input</title> @@ -330,20 +258,20 @@ device has one or more outputs.</para> &v4l2-input; input; int index; -if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &index)) { - perror ("VIDIOC_G_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &index)) { + perror("VIDIOC_G_INPUT"); + exit(EXIT_FAILURE); } -memset (&input, 0, sizeof (input)); +memset(&input, 0, sizeof(input)); input.index = index; -if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { - perror ("VIDIOC_ENUMINPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &input)) { + perror("VIDIOC_ENUMINPUT"); + exit(EXIT_FAILURE); } -printf ("Current input: %s\n", input.name); +printf("Current input: %s\n", input.name); </programlisting> </example> @@ -355,9 +283,9 @@ int index; index = 0; -if (-1 == ioctl (fd, &VIDIOC-S-INPUT;, &index)) { - perror ("VIDIOC_S_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-S-INPUT;, &index)) { + perror("VIDIOC_S_INPUT"); + exit(EXIT_FAILURE); } </programlisting> </example> @@ -397,7 +325,7 @@ available inputs and outputs applications can enumerate them with the also contains signal status information applicable when the current audio input is queried.</para> - <para>The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctl report + <para>The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctls report the current audio input and output, respectively. Note that, unlike &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; these ioctls return a structure as <constant>VIDIOC_ENUMAUDIO</constant> and @@ -408,11 +336,11 @@ applications call the &VIDIOC-S-AUDIO; ioctl. To select an audio output (which presently has no changeable properties) applications call the &VIDIOC-S-AUDOUT; ioctl.</para> - <para>Drivers must implement all input ioctls when the device -has one or more inputs, all output ioctls when the device has one -or more outputs. When the device has any audio inputs or outputs the -driver must set the <constant>V4L2_CAP_AUDIO</constant> flag in the -&v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para> + <para>Drivers must implement all audio input ioctls when the device +has multiple selectable audio inputs, all audio output ioctls when the +device has multiple selectable audio outputs. When the device has any +audio inputs or outputs the driver must set the <constant>V4L2_CAP_AUDIO</constant> +flag in the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para> <example> <title>Information about the current audio input</title> @@ -420,14 +348,14 @@ driver must set the <constant>V4L2_CAP_AUDIO</constant> flag in the <programlisting> &v4l2-audio; audio; -memset (&audio, 0, sizeof (audio)); +memset(&audio, 0, sizeof(audio)); -if (-1 == ioctl (fd, &VIDIOC-G-AUDIO;, &audio)) { - perror ("VIDIOC_G_AUDIO"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-G-AUDIO;, &audio)) { + perror("VIDIOC_G_AUDIO"); + exit(EXIT_FAILURE); } -printf ("Current input: %s\n", audio.name); +printf("Current input: %s\n", audio.name); </programlisting> </example> @@ -437,13 +365,13 @@ printf ("Current input: %s\n", audio.name); <programlisting> &v4l2-audio; audio; -memset (&audio, 0, sizeof (audio)); /* clear audio.mode, audio.reserved */ +memset(&audio, 0, sizeof(audio)); /* clear audio.mode, audio.reserved */ audio.index = 0; -if (-1 == ioctl (fd, &VIDIOC-S-AUDIO;, &audio)) { - perror ("VIDIOC_S_AUDIO"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-S-AUDIO;, &audio)) { + perror("VIDIOC_S_AUDIO"); + exit(EXIT_FAILURE); } </programlisting> </example> @@ -468,7 +396,7 @@ the tuner.</para> video inputs.</para> <para>To query and change tuner properties applications use the -&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The +&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctls, respectively. The &v4l2-tuner; returned by <constant>VIDIOC_G_TUNER</constant> also contains signal status information applicable when the tuner of the current video or radio input is queried. Note that @@ -533,7 +461,7 @@ standards or variations of standards. Each video input and output may support another set of standards. This set is reported by the <structfield>std</structfield> field of &v4l2-input; and &v4l2-output; returned by the &VIDIOC-ENUMINPUT; and -&VIDIOC-ENUMOUTPUT; ioctl, respectively.</para> +&VIDIOC-ENUMOUTPUT; ioctls, respectively.</para> <para>V4L2 defines one bit for each analog video standard currently in use worldwide, and sets aside bits for driver defined @@ -564,28 +492,10 @@ automatically.</para> <para>To query and select the standard used by the current video input or output applications call the &VIDIOC-G-STD; and &VIDIOC-S-STD; ioctl, respectively. The <emphasis>received</emphasis> -standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), <emphasis>not</emphasis> an index into the standard enumeration.<footnote> - <para>An alternative to the current scheme is to use pointers -to indices as arguments of <constant>VIDIOC_G_STD</constant> and -<constant>VIDIOC_S_STD</constant>, the &v4l2-input; and -&v4l2-output; <structfield>std</structfield> field would be a set of -indices like <structfield>audioset</structfield>.</para> - <para>Indices are consistent with the rest of the API -and identify the standard unambiguously. In the present scheme of -things an enumerated standard is looked up by &v4l2-std-id;. Now the -standards supported by the inputs of a device can overlap. Just -assume the tuner and composite input in the example above both -exist on a device. An enumeration of "PAL-B/G", "PAL-H/I" suggests -a choice which does not exist. We cannot merge or omit sets, because -applications would be unable to find the standards reported by -<constant>VIDIOC_G_STD</constant>. That leaves separate enumerations -for each input. Also selecting a standard by &v4l2-std-id; can be -ambiguous. Advantage of this method is that applications need not -identify the standard indirectly, after enumerating.</para><para>So in -summary, the lookup itself is unavoidable. The difference is only -whether the lookup is necessary to find an enumerated standard or to -switch to a standard by &v4l2-std-id;.</para> - </footnote> Drivers must implement all video standard ioctls +standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the +parameter of all these ioctls is a pointer to a &v4l2-std-id; type +(a standard set), <emphasis>not</emphasis> an index into the standard +enumeration. Drivers must implement all video standard ioctls when the device has one or more video inputs or outputs.</para> <para>Special rules apply to devices such as USB cameras where the notion of video @@ -604,17 +514,10 @@ to zero and the <constant>VIDIOC_G_STD</constant>, <constant>VIDIOC_S_STD</constant>, <constant>VIDIOC_QUERYSTD</constant> and <constant>VIDIOC_ENUMSTD</constant> ioctls shall return the -&ENOTTY;.<footnote> - <para>See <xref linkend="buffer" /> for a rationale.</para> +&ENOTTY; or the &EINVAL;.</para> <para>Applications can make use of the <xref linkend="input-capabilities" /> and <xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls -are available for the device.</para> - - <para>See <xref linkend="buffer" /> for a rationale. Probably -even USB cameras follow some well known video standard. It might have -been better to explicitly indicate elsewhere if a device cannot live -up to normal expectations, instead of this exception.</para> - </footnote></para> +can be used with the given input or output.</para> <example> <title>Information about the current video standard</title> @@ -623,22 +526,22 @@ up to normal expectations, instead of this exception.</para> &v4l2-std-id; std_id; &v4l2-standard; standard; -if (-1 == ioctl (fd, &VIDIOC-G-STD;, &std_id)) { +if (-1 == ioctl(fd, &VIDIOC-G-STD;, &std_id)) { /* Note when VIDIOC_ENUMSTD always returns ENOTTY this is no video device or it falls under the USB exception, and VIDIOC_G_STD returning ENOTTY is no error. */ - perror ("VIDIOC_G_STD"); - exit (EXIT_FAILURE); + perror("VIDIOC_G_STD"); + exit(EXIT_FAILURE); } -memset (&standard, 0, sizeof (standard)); +memset(&standard, 0, sizeof(standard)); standard.index = 0; -while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { +while (0 == ioctl(fd, &VIDIOC-ENUMSTD;, &standard)) { if (standard.id & std_id) { - printf ("Current video standard: %s\n", standard.name); - exit (EXIT_SUCCESS); + printf("Current video standard: %s\n", standard.name); + exit(EXIT_SUCCESS); } standard.index++; @@ -648,8 +551,8 @@ while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { empty unless this device falls under the USB exception. */ if (errno == EINVAL || standard.index == 0) { - perror ("VIDIOC_ENUMSTD"); - exit (EXIT_FAILURE); + perror("VIDIOC_ENUMSTD"); + exit(EXIT_FAILURE); } </programlisting> </example> @@ -662,26 +565,26 @@ input</title> &v4l2-input; input; &v4l2-standard; standard; -memset (&input, 0, sizeof (input)); +memset(&input, 0, sizeof(input)); -if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &input.index)) { - perror ("VIDIOC_G_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &input.index)) { + perror("VIDIOC_G_INPUT"); + exit(EXIT_FAILURE); } -if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { - perror ("VIDIOC_ENUM_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &input)) { + perror("VIDIOC_ENUM_INPUT"); + exit(EXIT_FAILURE); } -printf ("Current input %s supports:\n", input.name); +printf("Current input %s supports:\n", input.name); -memset (&standard, 0, sizeof (standard)); +memset(&standard, 0, sizeof(standard)); standard.index = 0; -while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { +while (0 == ioctl(fd, &VIDIOC-ENUMSTD;, &standard)) { if (standard.id & input.std) - printf ("%s\n", standard.name); + printf("%s\n", standard.name); standard.index++; } @@ -690,8 +593,8 @@ while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { empty unless this device falls under the USB exception. */ if (errno != EINVAL || standard.index == 0) { - perror ("VIDIOC_ENUMSTD"); - exit (EXIT_FAILURE); + perror("VIDIOC_ENUMSTD"); + exit(EXIT_FAILURE); } </programlisting> </example> @@ -703,21 +606,21 @@ if (errno != EINVAL || standard.index == 0) { &v4l2-input; input; &v4l2-std-id; std_id; -memset (&input, 0, sizeof (input)); +memset(&input, 0, sizeof(input)); -if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &input.index)) { - perror ("VIDIOC_G_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &input.index)) { + perror("VIDIOC_G_INPUT"); + exit(EXIT_FAILURE); } -if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { - perror ("VIDIOC_ENUM_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &input)) { + perror("VIDIOC_ENUM_INPUT"); + exit(EXIT_FAILURE); } if (0 == (input.std & V4L2_STD_PAL_BG)) { - fprintf (stderr, "Oops. B/G PAL is not supported.\n"); - exit (EXIT_FAILURE); + fprintf(stderr, "Oops. B/G PAL is not supported.\n"); + exit(EXIT_FAILURE); } /* Note this is also supposed to work when only B @@ -725,9 +628,9 @@ if (0 == (input.std & V4L2_STD_PAL_BG)) { std_id = V4L2_STD_PAL_BG; -if (-1 == ioctl (fd, &VIDIOC-S-STD;, &std_id)) { - perror ("VIDIOC_S_STD"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-S-STD;, &std_id)) { + perror("VIDIOC_S_STD"); + exit(EXIT_FAILURE); } </programlisting> </example> @@ -740,26 +643,25 @@ corresponding video timings. Today there are many more different hardware interf such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry video signals and there is a need to extend the API to select the video timings for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to -the limited bits available, a new set of IOCTLs was added to set/get video timings at -the input and output: </para><itemizedlist> - <listitem> - <para>DV Timings: This will allow applications to define detailed -video timings for the interface. This includes parameters such as width, height, -polarities, frontporch, backporch etc. The <filename>linux/v4l2-dv-timings.h</filename> +the limited bits available, a new set of ioctls was added to set/get video timings at +the input and output.</para> + + <para>These ioctls deal with the detailed digital video timings that define +each video format. This includes parameters such as the active video width and height, +signal polarities, frontporches, backporches, sync widths etc. The <filename>linux/v4l2-dv-timings.h</filename> header can be used to get the timings of the formats in the <xref linkend="cea861" /> and <xref linkend="vesadmt" /> standards. </para> - </listitem> - </itemizedlist> - <para>To enumerate and query the attributes of the DV timings supported by a device, + + <para>To enumerate and query the attributes of the DV timings supported by a device applications use the &VIDIOC-ENUM-DV-TIMINGS; and &VIDIOC-DV-TIMINGS-CAP; ioctls. - To set DV timings for the device, applications use the + To set DV timings for the device applications use the &VIDIOC-S-DV-TIMINGS; ioctl and to get current DV timings they use the &VIDIOC-G-DV-TIMINGS; ioctl. To detect the DV timings as seen by the video receiver applications use the &VIDIOC-QUERY-DV-TIMINGS; ioctl.</para> <para>Applications can make use of the <xref linkend="input-capabilities" /> and -<xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the -video timings for the device.</para> +<xref linkend="output-capabilities"/> flags to determine whether the digital video ioctls +can be used with the given input or output.</para> </section> &sub-controls; diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 86c6dd2..eee6f0f 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2535,6 +2535,16 @@ fields changed from _s32 to _u32. </orderedlist> </section> + <section> + <title>V4L2 in Linux 3.15</title> + <orderedlist> + <listitem> + <para>Added Software Defined Radio (SDR) Interface. + </para> + </listitem> + </orderedlist> + </section> + <section id="other"> <title>Relation of V4L2 to other Linux multimedia APIs</title> @@ -2651,6 +2661,9 @@ ioctls.</para> <listitem> <para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para> </listitem> + <listitem> + <para>Software Defined Radio (SDR) Interface, <xref linkend="sdr" />.</para> + </listitem> </itemizedlist> </section> diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index a5a3188..9f5ffd8 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> @@ -2258,6 +2309,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry> VBV buffer control.</entry> </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-video-hor-search-range"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Horizontal search range defines maximum horizontal search area in pixels +to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set +horizontal search range for motion estimation module in video encoder.</entry> + </row> + + <row><entry></entry></row> + <row id="v4l2-mpeg-video-vert-search-range"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Vertical search range defines maximum vertical search area in pixels +to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set +vertical search range for motion estimation module in video encoder.</entry> + </row> + <row><entry></entry></row> <row> <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry> @@ -3980,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> @@ -4370,6 +4503,24 @@ interface and may change in the future.</para> <entry>The flash controller has detected a short or open circuit condition on the indicator LED.</entry> </row> + <row> + <entry><constant>V4L2_FLASH_FAULT_UNDER_VOLTAGE</constant></entry> + <entry>Flash controller voltage to the flash LED + has been below the minimum limit specific to the flash + controller.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_FAULT_INPUT_VOLTAGE</constant></entry> + <entry>The input voltage of the flash controller is below + the limit under which strobing the flash at full current + will not be possible.The condition persists until this flag + is no longer set.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_FAULT_LED_OVER_TEMPERATURE</constant></entry> + <entry>The temperature of the LED has exceeded its + allowed upper limit.</entry> + </row> </tbody> </entrytbl> </row> @@ -4938,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> @@ -4969,6 +5171,240 @@ 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> + + <section id="rf-tuner-controls"> + <title>RF Tuner Control Reference</title> + + <para> +The RF Tuner (RF_TUNER) class includes controls for common features of devices +having RF tuner. + </para> + <para> +In this context, RF tuner is radio receiver circuit between antenna and +demodulator. It receives radio frequency (RF) from the antenna and converts that +received signal to lower intermediate frequency (IF) or baseband frequency (BB). +Tuners that could do baseband output are often called Zero-IF tuners. Older +tuners were typically simple PLL tuners inside a metal box, whilst newer ones +are highly integrated chips without a metal box "silicon tuners". These controls +are mostly applicable for new feature rich silicon tuners, just because older +tuners does not have much adjustable features. + </para> + <para> +For more information about RF tuners see +<ulink url="http://en.wikipedia.org/wiki/Tuner_%28radio%29">Tuner (radio)</ulink> +and +<ulink url="http://en.wikipedia.org/wiki/RF_front_end">RF front end</ulink> +from Wikipedia. + </para> + + <table pgwide="1" frame="none" id="rf-tuner-control-id"> + <title>RF_TUNER 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_RF_TUNER_CLASS</constant> </entry> + <entry>class</entry> + </row><row><entry spanname="descr">The RF_TUNER 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_RF_TUNER_BANDWIDTH_AUTO</constant> </entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Enables/disables tuner radio channel +bandwidth configuration. In automatic mode bandwidth configuration is performed +by the driver.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_BANDWIDTH</constant> </entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">Filter(s) on tuner signal path are used to +filter signal according to receiving party needs. Driver configures filters to +fulfill desired bandwidth requirement. Used when V4L2_CID_RF_TUNER_BANDWIDTH_AUTO is not +set. Unit is in Hz. The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant> </entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Enables/disables LNA automatic gain control (AGC)</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant> </entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Enables/disables mixer automatic gain control (AGC)</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant> </entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Enables/disables IF automatic gain control (AGC)</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN</constant> </entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">LNA (low noise amplifier) gain is first +gain stage on the RF tuner signal path. It is located very close to tuner +antenna input. Used when <constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant> is not set. +The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN</constant> </entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">Mixer gain is second gain stage on the RF +tuner signal path. It is located inside mixer block, where RF signal is +down-converted by the mixer. Used when <constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant> +is not set. The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN</constant> </entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">IF gain is last gain stage on the RF tuner +signal path. It is located on output of RF tuner. It controls signal level of +intermediate frequency output or baseband output. Used when +<constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant> is not set. The range and step are +driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_PLL_LOCK</constant> </entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Is synthesizer PLL locked? RF tuner is +receiving given frequency when that control is set. This is a read-only control. +</entry> + </row> + </tbody> + </tgroup> + </table> + </section> </section> diff --git a/Documentation/DocBook/media/v4l/dev-osd.xml b/Documentation/DocBook/media/v4l/dev-osd.xml index dd91d61..5485332 100644 --- a/Documentation/DocBook/media/v4l/dev-osd.xml +++ b/Documentation/DocBook/media/v4l/dev-osd.xml @@ -56,18 +56,18 @@ framebuffer device.</para> unsigned int i; int fb_fd; -if (-1 == ioctl (fd, VIDIOC_G_FBUF, &fbuf)) { - perror ("VIDIOC_G_FBUF"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, VIDIOC_G_FBUF, &fbuf)) { + perror("VIDIOC_G_FBUF"); + exit(EXIT_FAILURE); } -for (i = 0; i > 30; ++i) { +for (i = 0; i < 30; i++) { char dev_name[16]; struct fb_fix_screeninfo si; - snprintf (dev_name, sizeof (dev_name), "/dev/fb%u", i); + snprintf(dev_name, sizeof(dev_name), "/dev/fb%u", i); - fb_fd = open (dev_name, O_RDWR); + fb_fd = open(dev_name, O_RDWR); if (-1 == fb_fd) { switch (errno) { case ENOENT: /* no such file */ @@ -75,19 +75,19 @@ for (i = 0; i > 30; ++i) { continue; default: - perror ("open"); - exit (EXIT_FAILURE); + perror("open"); + exit(EXIT_FAILURE); } } - if (0 == ioctl (fb_fd, FBIOGET_FSCREENINFO, &si)) { - if (si.smem_start == (unsigned long) fbuf.base) + if (0 == ioctl(fb_fd, FBIOGET_FSCREENINFO, &si)) { + if (si.smem_start == (unsigned long)fbuf.base) break; } else { /* Apparently not a framebuffer device. */ } - close (fb_fd); + close(fb_fd); fb_fd = -1; } diff --git a/Documentation/DocBook/media/v4l/dev-raw-vbi.xml b/Documentation/DocBook/media/v4l/dev-raw-vbi.xml index b788c72..f4b61b6 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 new file mode 100644 index 0000000..f890356 --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-sdr.xml @@ -0,0 +1,120 @@ + <title>Software Defined Radio Interface (SDR)</title> + + <note> + <title>Experimental</title> + <para>This is an <link linkend="experimental"> experimental </link> + interface and may change in the future.</para> + </note> + + <para> +SDR is an abbreviation of Software Defined Radio, the radio device +which uses application software for modulation or demodulation. This interface +is intended for controlling and data streaming of such devices. + </para> + + <para> +SDR devices are accessed through character device special files named +<filename>/dev/swradio0</filename> to <filename>/dev/swradio255</filename> +with major number 81 and dynamically allocated minor numbers 0 to 255. + </para> + + <section> + <title>Querying Capabilities</title> + + <para> +Devices supporting the SDR receiver interface set the +<constant>V4L2_CAP_SDR_CAPTURE</constant> and +<constant>V4L2_CAP_TUNER</constant> flag in the +<structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device has an +Analog to Digital Converter (ADC), which is a mandatory element for the SDR receiver. +At least one of the read/write, streaming or asynchronous I/O methods must +be supported. + </para> + </section> + + <section> + <title>Supplemental Functions</title> + + <para> +SDR devices can support <link linkend="control">controls</link>, and must +support the <link linkend="tuner">tuner</link> ioctls. Tuner ioctls are used +for setting the ADC sampling rate (sampling frequency) and the possible RF tuner +frequency. + </para> + + <para> +The <constant>V4L2_TUNER_ADC</constant> tuner type is used for ADC tuners, and +the <constant>V4L2_TUNER_RF</constant> tuner type is used for RF tuners. The +tuner index of the RF tuner (if any) must always follow the ADC tuner index. +Normally the ADC tuner is #0 and the RF tuner is #1. + </para> + + <para> +The &VIDIOC-S-HW-FREQ-SEEK; ioctl is not supported. + </para> + </section> + + <section> + <title>Data Format Negotiation</title> + + <para> +The SDR capture device uses the <link linkend="format">format</link> ioctls to +select the capture format. Both the sampling resolution and the data streaming +format are bound to that selectable format. In addition to the basic +<link linkend="format">format</link> ioctls, the &VIDIOC-ENUM-FMT; ioctl +must be supported as well. + </para> + + <para> +To use the <link linkend="format">format</link> ioctls applications set the +<structfield>type</structfield> field of a &v4l2-format; to +<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 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"> + <title>struct <structname>v4l2_sdr_format</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>pixelformat</structfield></entry> + <entry> +The data format or type of compression, set by the application. This is a +little endian <link linkend="v4l2-fourcc">four character code</link>. +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[24]</structfield></entry> + <entry>This array is reserved for future extensions. +Drivers and applications must set it to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para> +An SDR device may support <link linkend="rw">read/write</link> +and/or streaming (<link linkend="mmap">memory mapping</link> +or <link linkend="userp">user pointer</link>) I/O. + </para> + + </section> diff --git a/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml b/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml index 548f8ea..7a8bf30 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 2c4c068..e5e8325 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -125,7 +125,7 @@ location of the buffers in device memory can be determined with the <structfield>m.offset</structfield> and <structfield>length</structfield> returned in a &v4l2-buffer; are passed as sixth and second parameter to the <function>mmap()</function> function. When using the multi-planar API, -struct &v4l2-buffer; contains an array of &v4l2-plane; structures, each +&v4l2-buffer; contains an array of &v4l2-plane; structures, each containing its own <structfield>m.offset</structfield> and <structfield>length</structfield>. When using the multi-planar API, every plane of every buffer has to be mapped separately, so the number of @@ -339,8 +339,8 @@ returns immediately with an &EAGAIN; when no buffer is available. The queues as a side effect. Since there is no notion of doing anything "now" on a multitasking system, if an application needs to synchronize with another event it should examine the &v4l2-buffer; -<structfield>timestamp</structfield> of captured buffers, or set the -field before enqueuing buffers for output.</para> +<structfield>timestamp</structfield> of captured or outputted buffers. +</para> <para>Drivers implementing memory mapping I/O must support the <constant>VIDIOC_REQBUFS</constant>, @@ -457,7 +457,7 @@ queues and unlocks all buffers as a side effect. Since there is no notion of doing anything "now" on a multitasking system, if an application needs to synchronize with another event it should examine the &v4l2-buffer; <structfield>timestamp</structfield> of captured -buffers, or set the field before enqueuing buffers for output.</para> +or outputted buffers.</para> <para>Drivers implementing user pointer I/O must support the <constant>VIDIOC_REQBUFS</constant>, @@ -620,8 +620,7 @@ returns immediately with an &EAGAIN; when no buffer is available. The unlocks all buffers as a side effect. Since there is no notion of doing anything "now" on a multitasking system, if an application needs to synchronize with another event it should examine the &v4l2-buffer; -<structfield>timestamp</structfield> of captured buffers, or set the field -before enqueuing buffers for output.</para> +<structfield>timestamp</structfield> of captured or outputted buffers.</para> <para>Drivers implementing DMABUF importing I/O must support the <constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>, @@ -654,38 +653,19 @@ plane, are stored in struct <structname>v4l2_plane</structname> instead. In that case, struct <structname>v4l2_buffer</structname> contains an array of plane structures.</para> - <para>Nominally timestamps refer to the first data byte transmitted. -In practice however the wide range of hardware covered by the V4L2 API -limits timestamp accuracy. Often an interrupt routine will -sample the system clock shortly after the field or frame was stored -completely in memory. So applications must expect a constant -difference up to one field or frame period plus a small (few scan -lines) random error. The delay and error can be much -larger due to compression or transmission over an external bus when -the frames are not properly stamped by the sender. This is frequently -the case with USB cameras. Here timestamps refer to the instant the -field or frame was received by the driver, not the capture time. These -devices identify by not enumerating any video standards, see <xref -linkend="standard" />.</para> - - <para>Similar limitations apply to output timestamps. Typically -the video hardware locks to a clock controlling the video timing, the -horizontal and vertical synchronization pulses. At some point in the -line sequence, possibly the vertical blanking, an interrupt routine -samples the system clock, compares against the timestamp and programs -the hardware to repeat the previous field or frame, or to display the -buffer contents.</para> - - <para>Apart of limitations of the video device and natural -inaccuracies of all clocks, it should be noted system time itself is -not perfectly stable. It can be affected by power saving cycles, -warped to insert leap seconds, or even turned back or forth by the -system administrator affecting long term measurements. <footnote> - <para>Since no other Linux multimedia -API supports unadjusted time it would be foolish to introduce here. We -must use a universally supported clock to synchronize different media, -hence time of day.</para> - </footnote></para> + <para>Dequeued video buffers come with timestamps. The driver + decides at which part of the frame and with which clock the + timestamp is taken. Please see flags in the masks + <constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant> and + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> in <xref + linkend="buffer-flags" />. These flags are always valid and constant + across all buffers during the whole video stream. Changes in these + flags may take place as a side effect of &VIDIOC-S-INPUT; or + &VIDIOC-S-OUTPUT; however. The + <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> timestamp type + which is used by e.g. on mem-to-mem devices is an exception to the + rule: the timestamp source flags are copied from the OUTPUT video + buffer to the CAPTURE video buffer.</para> <table frame="none" pgwide="1" id="v4l2-buffer"> <title>struct <structname>v4l2_buffer</structname></title> @@ -696,10 +676,11 @@ hence time of day.</para> <entry>__u32</entry> <entry><structfield>index</structfield></entry> <entry></entry> - <entry>Number of the buffer, set by the application. This -field is only used for <link linkend="mmap">memory mapping</link> I/O -and can range from zero to the number of buffers allocated -with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>) minus one.</entry> + <entry>Number of the buffer, set by the application except +when calling &VIDIOC-DQBUF;, then it is set by the driver. +This field can range from zero to the number of buffers allocated +with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>), +plus any buffers allocated with &VIDIOC-CREATE-BUFS; minus one.</entry> </row> <row> <entry>__u32</entry> @@ -718,7 +699,12 @@ linkend="v4l2-buf-type" /></entry> buffer. It depends on the negotiated data format and may change with each buffer for compressed variable size data like JPEG images. Drivers must set this field when <structfield>type</structfield> -refers to an input stream, applications when an output stream.</entry> +refers to an input stream, applications when it refers to an output stream. +If the application sets this to 0 for an output stream, then +<structfield>bytesused</structfield> will be set to the size of the +buffer (see the <structfield>length</structfield> field of this struct) by +the driver. For multiplanar formats this field is ignored and the +<structfield>planes</structfield> pointer is used instead.</entry> </row> <row> <entry>__u32</entry> @@ -735,7 +721,7 @@ linkend="buffer-flags" />.</entry> buffer, see <xref linkend="v4l2-field" />. This field is not used when the buffer contains VBI data. Drivers must set it when <structfield>type</structfield> refers to an input stream, -applications when an output stream.</entry> +applications when it refers to an output stream.</entry> </row> <row> <entry>struct timeval</entry> @@ -745,15 +731,13 @@ applications when an output stream.</entry> byte was captured, as returned by the <function>clock_gettime()</function> function for the relevant clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in - <xref linkend="buffer-flags" />. For output streams the data - will not be displayed before this time, secondary to the nominal - frame rate determined by the current video standard in enqueued - order. Applications can for example zero this field to display - frames as soon as possible. The driver stores the time at which - the first data byte was actually sent out in the - <structfield>timestamp</structfield> field. This permits + <xref linkend="buffer-flags" />. For output streams the driver + stores the time at which the last data byte was actually sent out + in the <structfield>timestamp</structfield> field. This permits applications to monitor the drift between the video and system - clock.</para></entry> + clock. For output streams that use <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> + the application has to fill in the timestamp which will be copied + by the driver to the capture stream.</para></entry> </row> <row> <entry>&v4l2-timecode;</entry> @@ -846,7 +830,8 @@ is the file descriptor associated with a DMABUF buffer.</entry> <entry><structfield>length</structfield></entry> <entry></entry> <entry>Size of the buffer (not the payload) in bytes for the - single-planar API. For the multi-planar API the application sets + single-planar API. This is set by the driver based on the calls to + &VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;. For the multi-planar API the application sets this to the number of elements in the <structfield>planes</structfield> array. The driver will fill in the actual number of valid elements in that array. @@ -880,13 +865,20 @@ should set this to 0.</entry> <entry><structfield>bytesused</structfield></entry> <entry></entry> <entry>The number of bytes occupied by data in the plane - (its payload).</entry> + (its payload). Drivers must set this field when <structfield>type</structfield> + refers to an input stream, applications when it refers to an output stream. + 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. Note that the actual image data starts at + <structfield>data_offset</structfield> which may not be 0.</entry> </row> <row> <entry>__u32</entry> <entry><structfield>length</structfield></entry> <entry></entry> - <entry>Size in bytes of the plane (not its payload).</entry> + <entry>Size in bytes of the plane (not its payload). This is set by the driver + based on the calls to &VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;.</entry> </row> <row> <entry>union</entry> @@ -925,7 +917,13 @@ should set this to 0.</entry> <entry>__u32</entry> <entry><structfield>data_offset</structfield></entry> <entry></entry> - <entry>Offset in bytes to video data in the plane, if applicable. + <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> @@ -1005,6 +1003,12 @@ should set this to 0.</entry> <entry>Buffer for video output overlay (OSD), see <xref linkend="osd" />.</entry> </row> + <row> + <entry><constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant></entry> + <entry>11</entry> + <entry>Buffer for Software Defined Radio (SDR), see <xref + linkend="sdr" />.</entry> + </row> </tbody> </tgroup> </table> @@ -1016,7 +1020,7 @@ should set this to 0.</entry> <tbody valign="top"> <row> <entry><constant>V4L2_BUF_FLAG_MAPPED</constant></entry> - <entry>0x0001</entry> + <entry>0x00000001</entry> <entry>The buffer resides in device memory and has been mapped into the application's address space, see <xref linkend="mmap" /> for details. Drivers set or clear this flag when the @@ -1026,7 +1030,7 @@ Drivers set or clear this flag when the </row> <row> <entry><constant>V4L2_BUF_FLAG_QUEUED</constant></entry> - <entry>0x0002</entry> + <entry>0x00000002</entry> <entry>Internally drivers maintain two buffer queues, an incoming and outgoing queue. When this flag is set, the buffer is currently on the incoming queue. It automatically moves to the @@ -1039,7 +1043,7 @@ cleared.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_DONE</constant></entry> - <entry>0x0004</entry> + <entry>0x00000004</entry> <entry>When this flag is set, the buffer is currently on the outgoing queue, ready to be dequeued from the driver. Drivers set or clear this flag when the <constant>VIDIOC_QUERYBUF</constant> ioctl @@ -1049,11 +1053,11 @@ buffer cannot be on both queues at the same time, the <constant>V4L2_BUF_FLAG_QUEUED</constant> and <constant>V4L2_BUF_FLAG_DONE</constant> flag are mutually exclusive. They can be both cleared however, then the buffer is in "dequeued" -state, in the application domain to say so.</entry> +state, in the application domain so to say.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_ERROR</constant></entry> - <entry>0x0040</entry> + <entry>0x00000040</entry> <entry>When this flag is set, the buffer has been dequeued successfully, although the data might have been corrupted. This is recoverable, streaming may continue as normal and @@ -1063,35 +1067,43 @@ state, in the application domain to say so.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_KEYFRAME</constant></entry> - <entry>0x0008</entry> + <entry>0x00000008</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.</entry> +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> <row> <entry><constant>V4L2_BUF_FLAG_PFRAME</constant></entry> - <entry>0x0010</entry> + <entry>0x00000010</entry> <entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant> this flags predicted frames or fields which contain only differences to a -previous key frame.</entry> +previous key frame. Applications can set this bit when <structfield>type</structfield> +refers to an output stream.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_BFRAME</constant></entry> - <entry>0x0020</entry> - <entry>Similar to <constant>V4L2_BUF_FLAG_PFRAME</constant> - this is a bidirectional predicted frame or field. [ooc tbd]</entry> + <entry>0x00000020</entry> + <entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant> +this flags a bi-directional predicted frame or field which contains only +the differences between the current frame and both the preceding and following +key frames to specify its content. Applications can set this bit when +<structfield>type</structfield> refers to an output stream.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_TIMECODE</constant></entry> - <entry>0x0100</entry> + <entry>0x00000100</entry> <entry>The <structfield>timecode</structfield> field is valid. Drivers set or clear this flag when the <constant>VIDIOC_DQBUF</constant> -ioctl is called.</entry> +ioctl is called. Applications can set this bit and the corresponding +<structfield>timecode</structfield> structure when <structfield>type</structfield> +refers to an output stream.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry> - <entry>0x0400</entry> + <entry>0x00000400</entry> <entry>The buffer has been prepared for I/O and can be queued by the application. Drivers set or clear this flag when the <link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link @@ -1101,7 +1113,7 @@ application. Drivers set or clear this flag when the </row> <row> <entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry> - <entry>0x0800</entry> + <entry>0x00000800</entry> <entry>Caches do not have to be invalidated for this buffer. Typically applications shall use this flag if the data captured in the buffer is not going to be touched by the CPU, instead the buffer will, probably, be @@ -1110,7 +1122,7 @@ passed on to a DMA-capable hardware unit for further processing or output. </row> <row> <entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry> - <entry>0x1000</entry> + <entry>0x00001000</entry> <entry>Caches do not have to be cleaned for this buffer. Typically applications shall use this flag for output buffers if the data in this buffer has not been created by the CPU but by some DMA-capable unit, @@ -1118,7 +1130,7 @@ in which case caches have not been used.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry> - <entry>0xe000</entry> + <entry>0x0000e000</entry> <entry>Mask for timestamp types below. To test the timestamp type, mask out bits not belonging to timestamp type by performing a logical and operation with buffer @@ -1126,7 +1138,7 @@ in which case caches have not been used.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry> - <entry>0x0000</entry> + <entry>0x00000000</entry> <entry>Unknown timestamp type. This type is used by drivers before Linux 3.9 and may be either monotonic (see below) or realtime (wall clock). Monotonic clock has been @@ -1139,7 +1151,7 @@ in which case caches have not been used.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry> - <entry>0x2000</entry> + <entry>0x00002000</entry> <entry>The buffer timestamp has been taken from the <constant>CLOCK_MONOTONIC</constant> clock. To access the same clock outside V4L2, use @@ -1147,10 +1159,42 @@ in which case caches have not been used.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry> - <entry>0x4000</entry> + <entry>0x00004000</entry> <entry>The CAPTURE buffer timestamp has been taken from the corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry> </row> + <row> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry> + <entry>0x00070000</entry> + <entry>Mask for timestamp sources below. The timestamp source + defines the point of time the timestamp is taken in relation to + the frame. Logical 'and' operation between the + <structfield>flags</structfield> field and + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the + value of the timestamp source. Applications must set the timestamp + source when <structfield>type</structfield> refers to an output stream + and <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> is set.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry> + <entry>0x00000000</entry> + <entry>End Of Frame. The buffer timestamp has been taken + when the last pixel of the frame has been received or the + last pixel of the frame has been transmitted. In practice, + software generated timestamps will typically be read from + the clock a small amount of time after the last pixel has + been received or transmitten, depending on the system and + other activity in it.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry> + <entry>0x00010000</entry> + <entry>Start Of Exposure. The buffer timestamp has been + taken when the exposure of the frame has begun. This is + only valid for the + <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> buffer + type.</entry> + </row> </tbody> </tgroup> </table> @@ -1440,10 +1484,9 @@ or application, depending on data direction, must set &v4l2-buffer; <constant>V4L2_FIELD_BOTTOM</constant>. Any two successive fields pair to build a frame. If fields are successive, without any dropped fields between them (fields can drop individually), can be determined from -the &v4l2-buffer; <structfield>sequence</structfield> field. Image -sizes refer to the frame, not fields. This format cannot be selected -when using the read/write I/O method.<!-- Where it's indistinguishable -from V4L2_FIELD_SEQ_*. --></entry> +the &v4l2-buffer; <structfield>sequence</structfield> field. This format +cannot be selected when using the read/write I/O method since there +is no way to communicate if a field was a top or bottom field.</entry> </row> <row> <entry><constant>V4L2_FIELD_INTERLACED_TB</constant></entry> diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml index cf85485..74fb394 100644 --- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml +++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml @@ -79,13 +79,13 @@ <entry>Entity id, set by the application.</entry> </row> <row> - <entry>struct &media-pad-desc;</entry> + <entry>&media-pad-desc;</entry> <entry>*<structfield>pads</structfield></entry> <entry>Pointer to a pads array allocated by the application. Ignored if NULL.</entry> </row> <row> - <entry>struct &media-link-desc;</entry> + <entry>&media-link-desc;</entry> <entry>*<structfield>links</structfield></entry> <entry>Pointer to a links array allocated by the application. Ignored if NULL.</entry> @@ -153,12 +153,12 @@ &cs-str; <tbody valign="top"> <row> - <entry>struct &media-pad-desc;</entry> + <entry>&media-pad-desc;</entry> <entry><structfield>source</structfield></entry> <entry>Pad at the origin of this link.</entry> </row> <row> - <entry>struct &media-pad-desc;</entry> + <entry>&media-pad-desc;</entry> <entry><structfield>sink</structfield></entry> <entry>Pad at the target of this link.</entry> </row> diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml index c51d5a4..fb2b5e3 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml @@ -12,18 +12,17 @@ <refsect1> <title>Description</title> - <para>This is a multi-planar, two-plane version of the YUV 4:2:0 format. + <para>This is a multi-planar, two-plane version of the YUV 4:2:2 format. The three components are separated into two sub-images or planes. <constant>V4L2_PIX_FMT_NV16M</constant> differs from <constant>V4L2_PIX_FMT_NV16 </constant> in that the two planes are non-contiguous in memory, i.e. the chroma -plane does not necessarily immediately follows the luma plane. +plane does not necessarily immediately follow the luma plane. The luminance data occupies the first plane. The Y plane has one byte per pixel. In the second plane there is chrominance data with alternating chroma samples. The CbCr plane is the same width and height, in bytes, as the Y plane. -Each CbCr pair belongs to four pixels. For example, +Each CbCr pair belongs to two pixels. For example, Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to -Y'<subscript>00</subscript>, Y'<subscript>01</subscript>, -Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. +Y'<subscript>00</subscript>, Y'<subscript>01</subscript>. <constant>V4L2_PIX_FMT_NV61M</constant> is the same as <constant>V4L2_PIX_FMT_NV16M</constant> except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index 166c8d6..2aae8e9 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"> @@ -121,18 +118,18 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry><constant>V4L2_PIX_FMT_RGB332</constant></entry> <entry>'RGB1'</entry> <entry></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> <entry>r<subscript>2</subscript></entry> <entry>r<subscript>1</subscript></entry> <entry>r<subscript>0</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <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,46 +149,90 @@ 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>r<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>-</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>a</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-RGB565"> - <entry><constant>V4L2_PIX_FMT_RGB565</constant></entry> - <entry>'RGBP'</entry> + <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> <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>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>5</subscript></entry> <entry>g<subscript>4</subscript></entry> <entry>g<subscript>3</subscript></entry> @@ -201,32 +242,32 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>'RGBQ'</entry> <entry></entry> <entry>a</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>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></entry> - <entry></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</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> - </row> - <row id="V4L2-PIX-FMT-RGB565X"> - <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry> - <entry>'RGBR'</entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></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> + </row> + <row id="V4L2-PIX-FMT-RGB565X"> + <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry> + <entry>'RGBR'</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>5</subscript></entry> <entry>g<subscript>4</subscript></entry> <entry>g<subscript>3</subscript></entry> @@ -234,11 +275,11 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</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>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> <row id="V4L2-PIX-FMT-BGR666"> <entry><constant>V4L2_PIX_FMT_BGR666</constant></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,58 @@ 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> + <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> @@ -411,28 +501,77 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>b<subscript>2</subscript></entry> <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>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>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 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 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,16 +651,14 @@ image</title> </formalpara> </example> - <important> - <para>Drivers may interpret these formats differently.</para> - </important> - - <para>Some RGB formats above are uncommon and were probably -defined in error. Drivers may interpret them as in <xref - linkend="rgb-formats-corrected" />.</para> + <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-corrected"> - <title>Packed RGB Image Formats (corrected)</title> + <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" /> @@ -618,21 +755,8 @@ defined in error. Drivers may interpret them as in <xref <entry>0</entry> </row> </thead> - <tbody valign="top"> - <row><!-- id="V4L2-PIX-FMT-RGB332" --> - <entry><constant>V4L2_PIX_FMT_RGB332</constant></entry> - <entry>'RGB1'</entry> - <entry></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-RGB444" --> + <tbody> + <row id="V4L2-PIX-FMT-RGB444"> <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry> <entry>'R444'</entry> <entry></entry> @@ -654,7 +778,7 @@ defined in error. Drivers may interpret them as in <xref <entry>r<subscript>1</subscript></entry> <entry>r<subscript>0</subscript></entry> </row> - <row><!-- id="V4L2-PIX-FMT-RGB555" --> + <row id="V4L2-PIX-FMT-RGB555"> <entry><constant>V4L2_PIX_FMT_RGB555</constant></entry> <entry>'RGBO'</entry> <entry></entry> @@ -676,174 +800,7 @@ defined in error. Drivers may interpret them as in <xref <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> - <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>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>5</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-RGB555X" --> - <entry><constant>V4L2_PIX_FMT_RGB555X</constant></entry> - <entry>'RGBQ'</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> - <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> - </row> - <row><!-- id="V4L2-PIX-FMT-RGB565X" --> - <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry> - <entry>'RGBR'</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>5</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></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> - </row> - <row><!-- id="V4L2-PIX-FMT-BGR666" --> - <entry><constant>V4L2_PIX_FMT_BGR666</constant></entry> - <entry>'BGRH'</entry> - <entry></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>g<subscript>5</subscript></entry> - <entry>g<subscript>4</subscript></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>r<subscript>5</subscript></entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry></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> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-BGR24" --> - <entry><constant>V4L2_PIX_FMT_BGR24</constant></entry> - <entry>'BGR3'</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> - </row> - <row><!-- id="V4L2-PIX-FMT-RGB24" --> - <entry><constant>V4L2_PIX_FMT_RGB24</constant></entry> - <entry>'RGB3'</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> - <row><!-- id="V4L2-PIX-FMT-BGR32" --> + <row id="V4L2-PIX-FMT-BGR32"> <entry><constant>V4L2_PIX_FMT_BGR32</constant></entry> <entry>'BGR4'</entry> <entry></entry> @@ -883,7 +840,7 @@ defined in error. Drivers may interpret them as in <xref <entry>a<subscript>1</subscript></entry> <entry>a<subscript>0</subscript></entry> </row> - <row><!-- id="V4L2-PIX-FMT-RGB32" --> + <row id="V4L2-PIX-FMT-RGB32"> <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> <entry>'RGB4'</entry> <entry></entry> 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 0000000..6118d8f --- /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 0000000..e4b494c --- /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-cu08.xml b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml new file mode 100644 index 0000000..2d80104 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml @@ -0,0 +1,44 @@ +<refentry id="V4L2-SDR-FMT-CU08"> + <refmeta> + <refentrytitle>V4L2_SDR_FMT_CU8 ('CU08')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname> + <constant>V4L2_SDR_FMT_CU8</constant> + </refname> + <refpurpose>Complex unsigned 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 unsigned number. I value comes first and Q value after +that. + </para> + <example> + <title><constant>V4L2_SDR_FMT_CU8</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-cu16le.xml b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml new file mode 100644 index 0000000..26288ff --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml @@ -0,0 +1,46 @@ +<refentry id="V4L2-SDR-FMT-CU16LE"> + <refmeta> + <refentrytitle>V4L2_SDR_FMT_CU16LE ('CU16')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname> + <constant>V4L2_SDR_FMT_CU16LE</constant> + </refname> + <refpurpose>Complex unsigned 16-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 16 bit unsigned little endian number. I value comes first +and Q value after that. + </para> + <example> + <title><constant>V4L2_SDR_FMT_CU16LE</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[15:8]</subscript></entry> + </row> + <row> + <entry>start + 2:</entry> + <entry>Q'<subscript>0[7:0]</subscript></entry> + <entry>Q'<subscript>0[15: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 0000000..3df076b --- /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 9ba4fb6..96947f1 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 72d72bd..df5b23d 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -25,7 +25,12 @@ capturing and output, for overlay frame buffer formats see also <row> <entry>__u32</entry> <entry><structfield>height</structfield></entry> - <entry>Image height in pixels.</entry> + <entry>Image height in pixels. If <structfield>field</structfield> is + one of <constant>V4L2_FIELD_TOP</constant>, <constant>V4L2_FIELD_BOTTOM</constant> + or <constant>V4L2_FIELD_ALTERNATE</constant> then height refers to the + number of lines in the field, otherwise it refers to the number of + lines in the frame (which is twice the field height for interlaced + formats).</entry> </row> <row> <entry spanname="hspan">Applications set these fields to @@ -54,7 +59,7 @@ linkend="reserved-formats" /></entry> can request to capture or output only the top or bottom field, or both fields interlaced or sequentially stored in one buffer or alternating in separate buffers. Drivers return the actual field order selected. -For details see <xref linkend="field-order" />.</entry> +For more details on fields see <xref linkend="field-order" />.</entry> </row> <row> <entry>__u32</entry> @@ -81,7 +86,10 @@ plane and is divided by the same factor as the example the Cb and Cr planes of a YUV 4:2:0 image have half as many padding bytes following each line as the Y plane. To avoid ambiguities drivers must return a <structfield>bytesperline</structfield> value -rounded up to a multiple of the scale factor.</para></entry> +rounded up to a multiple of the scale factor.</para> +<para>For compressed formats the <structfield>bytesperline</structfield> +value makes no sense. Applications and drivers must set this to 0 in +that case.</para></entry> </row> <row> <entry>__u32</entry> @@ -97,15 +105,41 @@ hold an image.</entry> <entry>&v4l2-colorspace;</entry> <entry><structfield>colorspace</structfield></entry> <entry>This information supplements the -<structfield>pixelformat</structfield> and must be set by the driver, +<structfield>pixelformat</structfield> and must be set by the driver for +capture streams and by the application for output streams, see <xref linkend="colorspaces" />.</entry> </row> <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> @@ -135,7 +169,7 @@ set this field to zero.</entry> <entry>__u16</entry> <entry><structfield>bytesperline</structfield></entry> <entry>Distance in bytes between the leftmost pixels in two adjacent - lines.</entry> + lines. See &v4l2-pix-format;.</entry> </row> <row> <entry>__u16</entry> @@ -154,12 +188,12 @@ set this field to zero.</entry> <row> <entry>__u32</entry> <entry><structfield>width</structfield></entry> - <entry>Image width in pixels.</entry> + <entry>Image width in pixels. See &v4l2-pix-format;.</entry> </row> <row> <entry>__u32</entry> <entry><structfield>height</structfield></entry> - <entry>Image height in pixels.</entry> + <entry>Image height in pixels. See &v4l2-pix-format;.</entry> </row> <row> <entry>__u32</entry> @@ -192,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> @@ -239,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> @@ -763,7 +803,7 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see </row> <row id="V4L2-PIX-FMT-H264-MVC"> <entry><constant>V4L2_PIX_FMT_H264_MVC</constant></entry> - <entry>'MVC'</entry> + <entry>'M264'</entry> <entry>H264 MVC video elementary stream.</entry> </row> <row id="V4L2-PIX-FMT-H263"> @@ -803,7 +843,7 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see </row> <row id="V4L2-PIX-FMT-VP8"> <entry><constant>V4L2_PIX_FMT_VP8</constant></entry> - <entry>'VP8'</entry> + <entry>'VP80'</entry> <entry>VP8 video elementary stream.</entry> </row> </tbody> @@ -811,6 +851,20 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see </table> </section> + <section id="sdr-formats"> + <title>SDR Formats</title> + + <para>These formats are used for <link linkend="sdr">SDR Capture</link> +interface only.</para> + + &sub-sdr-cu08; + &sub-sdr-cu16le; + &sub-sdr-cs08; + &sub-sdr-cs14le; + &sub-sdr-ru12le; + + </section> + <section id="pixfmt-reserved"> <title>Reserved Format Identifiers</title> @@ -1040,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/remote_controllers.xml b/Documentation/DocBook/media/v4l/remote_controllers.xml index 160e464..5124a6c 100644 --- a/Documentation/DocBook/media/v4l/remote_controllers.xml +++ b/Documentation/DocBook/media/v4l/remote_controllers.xml @@ -1,10 +1,152 @@ +<partinfo> +<authorgroup> +<author> +<firstname>Mauro</firstname> +<surname>Chehab</surname> +<othername role="mi">Carvalho</othername> +<affiliation><address><email>m.chehab@samsung.com</email></address></affiliation> +<contrib>Initial version.</contrib> +</author> +</authorgroup> +<copyright> + <year>2009-2014</year> + <holder>Mauro Carvalho Chehab</holder> +</copyright> + +<revhistory> +<!-- Put document revisions here, newest first. --> +<revision> +<revnumber>3.15</revnumber> +<date>2014-02-06</date> +<authorinitials>mcc</authorinitials> +<revremark>Added the interface description and the RC sysfs class description.</revremark> +</revision> +<revision> +<revnumber>1.0</revnumber> +<date>2009-09-06</date> +<authorinitials>mcc</authorinitials> +<revremark>Initial revision</revremark> +</revision> +</revhistory> +</partinfo> + + <title>Remote Controller API</title> + <chapter id="remote_controllers"> + <title>Remote Controllers</title> + <section id="Remote_controllers_Intro"> <title>Introduction</title> <para>Currently, most analog and digital devices have a Infrared input for remote controllers. Each manufacturer has their own type of control. It is not rare for the same manufacturer to ship different types of controls, depending on the device.</para> +<para>A Remote Controller interface is mapped as a normal evdev/input interface, just like a keyboard or a mouse. +So, it uses all ioctls already defined for any other input devices.</para> +<para>However, remove controllers are more flexible than a normal input device, as the IR +receiver (and/or transmitter) can be used in conjunction with a wide variety of different IR remotes.</para> +<para>In order to allow flexibility, the Remote Controller subsystem allows controlling the +RC-specific attributes via <link linkend="remote_controllers_sysfs_nodes">the sysfs class nodes</link>.</para> +</section> + +<section id="remote_controllers_sysfs_nodes"> +<title>Remote Controller's sysfs nodes</title> +<para>As defined at <constant>Documentation/ABI/testing/sysfs-class-rc</constant>, those are the sysfs nodes that control the Remote Controllers:</para> + +<section id="sys_class_rc"> +<title>/sys/class/rc/</title> +<para>The <constant>/sys/class/rc/</constant> class sub-directory belongs to the Remote Controller +core and provides a sysfs interface for configuring infrared remote controller receivers. +</para> + +</section> +<section id="sys_class_rc_rcN"> +<title>/sys/class/rc/rcN/</title> +<para>A <constant>/sys/class/rc/rcN</constant> directory is created for each remote + control receiver device where N is the number of the receiver.</para> + +</section> +<section id="sys_class_rc_rcN_protocols"> +<title>/sys/class/rc/rcN/protocols</title> +<para>Reading this file returns a list of available protocols, something like:</para> +<para><constant>rc5 [rc6] nec jvc [sony]</constant></para> +<para>Enabled protocols are shown in [] brackets.</para> +<para>Writing "+proto" will add a protocol to the list of enabled protocols.</para> +<para>Writing "-proto" will remove a protocol from the list of enabled protocols.</para> +<para>Writing "proto" will enable only "proto".</para> +<para>Writing "none" will disable all protocols.</para> +<para>Write fails with EINVAL if an invalid protocol combination or unknown protocol name is used.</para> + +</section> +<section id="sys_class_rc_rcN_filter"> +<title>/sys/class/rc/rcN/filter</title> +<para>Sets the scancode filter expected value.</para> +<para>Use in combination with <constant>/sys/class/rc/rcN/filter_mask</constant> to set the +expected value of the bits set in the filter mask. +If the hardware supports it then scancodes which do not match +the filter will be ignored. Otherwise the write will fail with +an error.</para> +<para>This value may be reset to 0 if the current protocol is altered.</para> + +</section> +<section id="sys_class_rc_rcN_filter_mask"> +<title>/sys/class/rc/rcN/filter_mask</title> +<para>Sets the scancode filter mask of bits to compare. +Use in combination with <constant>/sys/class/rc/rcN/filter</constant> to set the bits +of the scancode which should be compared against the expected +value. A value of 0 disables the filter to allow all valid +scancodes to be processed.</para> +<para>If the hardware supports it then scancodes which do not match +the filter will be ignored. Otherwise the write will fail with +an error.</para> +<para>This value may be reset to 0 if the current protocol is altered.</para> + +</section> +<section id="sys_class_rc_rcN_wakeup_protocols"> +<title>/sys/class/rc/rcN/wakeup_protocols</title> +<para>Reading this file returns a list of available protocols to use for the +wakeup filter, something like:</para> +<para><constant>rc5 rc6 nec jvc [sony]</constant></para> +<para>The enabled wakeup protocol is shown in [] brackets.</para> +<para>Writing "+proto" will add a protocol to the list of enabled wakeup +protocols.</para> +<para>Writing "-proto" will remove a protocol from the list of enabled wakeup +protocols.</para> +<para>Writing "proto" will use "proto" for wakeup events.</para> +<para>Writing "none" will disable wakeup.</para> +<para>Write fails with EINVAL if an invalid protocol combination or unknown +protocol name is used, or if wakeup is not supported by the hardware.</para> + +</section> +<section id="sys_class_rc_rcN_wakeup_filter"> +<title>/sys/class/rc/rcN/wakeup_filter</title> +<para>Sets the scancode wakeup filter expected value. +Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter_mask</constant> to +set the expected value of the bits set in the wakeup filter mask +to trigger a system wake event.</para> +<para>If the hardware supports it and wakeup_filter_mask is not 0 then +scancodes which match the filter will wake the system from e.g. +suspend to RAM or power off. +Otherwise the write will fail with an error.</para> +<para>This value may be reset to 0 if the wakeup protocol is altered.</para> + +</section> +<section id="sys_class_rc_rcN_wakeup_filter_mask"> +<title>/sys/class/rc/rcN/wakeup_filter_mask</title> +<para>Sets the scancode wakeup filter mask of bits to compare. +Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter</constant> to set +the bits of the scancode which should be compared against the +expected value to trigger a system wake event.</para> +<para>If the hardware supports it and wakeup_filter_mask is not 0 then +scancodes which match the filter will wake the system from e.g. +suspend to RAM or power off. +Otherwise the write will fail with an error.</para> +<para>This value may be reset to 0 if the wakeup protocol is altered.</para> +</section> +</section> + +<section id="Remote_controllers_tables"> +<title>Remote controller tables</title> <para>Unfortunately, for several years, there was no effort to create uniform IR keycodes for different devices. This caused the same IR keyname to be mapped completely differently on different IR devices. This resulted that the same IR keyname to be mapped completely different on @@ -175,3 +317,4 @@ keymapping.</para> </section> &sub-lirc_device_interface; +</chapter> diff --git a/Documentation/DocBook/media/v4l/selection-api.xml b/Documentation/DocBook/media/v4l/selection-api.xml index 4c238ce..28cbded 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/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 7331ce1..b2d5a03 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -1898,6 +1898,134 @@ <entry>y<subscript>1</subscript></entry> <entry>y<subscript>0</subscript></entry> </row> + <row id="V4L2-MBUS-FMT-UYVY10-2X10"> + <entry>V4L2_MBUS_FMT_UYVY10_2X10</entry> + <entry>0x2018</entry> + <entry></entry> + &dash-ent-22; + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-22; + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-22; + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-22; + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-VYUY10-2X10"> + <entry>V4L2_MBUS_FMT_VYUY10_2X10</entry> + <entry>0x2019</entry> + <entry></entry> + &dash-ent-22; + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-22; + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-22; + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-22; + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> <row id="V4L2-MBUS-FMT-YUYV10-2X10"> <entry>V4L2_MBUS_FMT_YUYV10_2X10</entry> <entry>0x200b</entry> @@ -2308,6 +2436,110 @@ <entry>v<subscript>1</subscript></entry> <entry>v<subscript>0</subscript></entry> </row> + <row id="V4L2-MBUS-FMT-UYVY10-1X20"> + <entry>V4L2_MBUS_FMT_UYVY10_1X20</entry> + <entry>0x201a</entry> + <entry></entry> + &dash-ent-12; + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-12; + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-VYUY10-1X20"> + <entry>V4L2_MBUS_FMT_VYUY10_1X20</entry> + <entry>0x201b</entry> + <entry></entry> + &dash-ent-12; + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-12; + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> <row id="V4L2-MBUS-FMT-YUYV10-1X20"> <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry> <entry>0x200d</entry> @@ -2486,6 +2718,534 @@ <entry>v<subscript>1</subscript></entry> <entry>v<subscript>0</subscript></entry> </row> + <row id="V4L2-MBUS-FMT-UYVY12-2X12"> + <entry>V4L2_MBUS_FMT_UYVY12_2X12</entry> + <entry>0x201c</entry> + <entry></entry> + &dash-ent-20; + <entry>u<subscript>11</subscript></entry> + <entry>u<subscript>10</subscript></entry> + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>v<subscript>11</subscript></entry> + <entry>v<subscript>10</subscript></entry> + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-VYUY12-2X12"> + <entry>V4L2_MBUS_FMT_VYUY12_2X12</entry> + <entry>0x201d</entry> + <entry></entry> + &dash-ent-20; + <entry>v<subscript>11</subscript></entry> + <entry>v<subscript>10</subscript></entry> + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>u<subscript>11</subscript></entry> + <entry>u<subscript>10</subscript></entry> + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-YUYV12-2X12"> + <entry>V4L2_MBUS_FMT_YUYV12_2X12</entry> + <entry>0x201e</entry> + <entry></entry> + &dash-ent-20; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>u<subscript>11</subscript></entry> + <entry>u<subscript>10</subscript></entry> + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>v<subscript>11</subscript></entry> + <entry>v<subscript>10</subscript></entry> + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-YVYU12-2X12"> + <entry>V4L2_MBUS_FMT_YVYU12_2X12</entry> + <entry>0x201f</entry> + <entry></entry> + &dash-ent-20; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>v<subscript>11</subscript></entry> + <entry>v<subscript>10</subscript></entry> + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-20; + <entry>u<subscript>11</subscript></entry> + <entry>u<subscript>10</subscript></entry> + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-UYVY12-1X24"> + <entry>V4L2_MBUS_FMT_UYVY12_1X24</entry> + <entry>0x2020</entry> + <entry></entry> + &dash-ent-8; + <entry>u<subscript>11</subscript></entry> + <entry>u<subscript>10</subscript></entry> + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-8; + <entry>v<subscript>11</subscript></entry> + <entry>v<subscript>10</subscript></entry> + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-VYUY12-1X24"> + <entry>V4L2_MBUS_FMT_VYUY12_1X24</entry> + <entry>0x2021</entry> + <entry></entry> + &dash-ent-8; + <entry>v<subscript>11</subscript></entry> + <entry>v<subscript>10</subscript></entry> + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-8; + <entry>u<subscript>11</subscript></entry> + <entry>u<subscript>10</subscript></entry> + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-YUYV12-1X24"> + <entry>V4L2_MBUS_FMT_YUYV12_1X24</entry> + <entry>0x2022</entry> + <entry></entry> + &dash-ent-8; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + <entry>u<subscript>11</subscript></entry> + <entry>u<subscript>10</subscript></entry> + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-8; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + <entry>v<subscript>11</subscript></entry> + <entry>v<subscript>10</subscript></entry> + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> + <row id="V4L2-MBUS-FMT-YVYU12-1X24"> + <entry>V4L2_MBUS_FMT_YVYU12_1X24</entry> + <entry>0x2023</entry> + <entry></entry> + &dash-ent-8; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + <entry>v<subscript>11</subscript></entry> + <entry>v<subscript>10</subscript></entry> + <entry>v<subscript>9</subscript></entry> + <entry>v<subscript>8</subscript></entry> + <entry>v<subscript>7</subscript></entry> + <entry>v<subscript>6</subscript></entry> + <entry>v<subscript>5</subscript></entry> + <entry>v<subscript>4</subscript></entry> + <entry>v<subscript>3</subscript></entry> + <entry>v<subscript>2</subscript></entry> + <entry>v<subscript>1</subscript></entry> + <entry>v<subscript>0</subscript></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + &dash-ent-8; + <entry>y<subscript>11</subscript></entry> + <entry>y<subscript>10</subscript></entry> + <entry>y<subscript>9</subscript></entry> + <entry>y<subscript>8</subscript></entry> + <entry>y<subscript>7</subscript></entry> + <entry>y<subscript>6</subscript></entry> + <entry>y<subscript>5</subscript></entry> + <entry>y<subscript>4</subscript></entry> + <entry>y<subscript>3</subscript></entry> + <entry>y<subscript>2</subscript></entry> + <entry>y<subscript>1</subscript></entry> + <entry>y<subscript>0</subscript></entry> + <entry>u<subscript>11</subscript></entry> + <entry>u<subscript>10</subscript></entry> + <entry>u<subscript>9</subscript></entry> + <entry>u<subscript>8</subscript></entry> + <entry>u<subscript>7</subscript></entry> + <entry>u<subscript>6</subscript></entry> + <entry>u<subscript>5</subscript></entry> + <entry>u<subscript>4</subscript></entry> + <entry>u<subscript>3</subscript></entry> + <entry>u<subscript>2</subscript></entry> + <entry>u<subscript>1</subscript></entry> + <entry>u<subscript>0</subscript></entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 74b7f27..f2f81f0 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -70,7 +70,7 @@ MPEG stream embedded, sliced VBI data format in this specification. Remote Controller chapter.</contrib> <affiliation> <address> - <email>mchehab@redhat.com</email> + <email>m.chehab@samsung.com</email> </address> </affiliation> </author> @@ -107,6 +107,16 @@ Remote Controller chapter.</contrib> </address> </affiliation> </author> + <author> + <firstname>Antti</firstname> + <surname>Palosaari</surname> + <contrib>SDR API.</contrib> + <affiliation> + <address> + <email>crope@iki.fi</email> + </address> + </affiliation> + </author> </authorgroup> <copyright> @@ -125,6 +135,7 @@ Remote Controller chapter.</contrib> <year>2011</year> <year>2012</year> <year>2013</year> + <year>2014</year> <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab, Pawel Osciak</holder> @@ -141,6 +152,24 @@ 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> + <revremark>Update several sections of "Common API Elements": "Opening and Closing Devices" +"Querying Capabilities", "Application Priority", "Video Inputs and Outputs", "Audio Inputs and Outputs" +"Tuners and Modulators", "Video Standards" and "Digital Video (DV) Timings". Added SDR API. + </revremark> + </revision> + + <revision> <revnumber>3.14</revnumber> <date>2013-11-25</date> <authorinitials>rr</authorinitials> @@ -537,6 +566,7 @@ and discussions on the V4L mailing list.</revremark> <section id="ttx"> &sub-dev-teletext; </section> <section id="radio"> &sub-dev-radio; </section> <section id="rds"> &sub-dev-rds; </section> + <section id="sdr"> &sub-dev-sdr; </section> <section id="event"> &sub-dev-event; </section> <section id="subdev"> &sub-dev-subdev; </section> </chapter> @@ -585,6 +615,7 @@ and discussions on the V4L mailing list.</revremark> &sub-g-crop; &sub-g-ctrl; &sub-g-dv-timings; + &sub-g-edid; &sub-g-enc-index; &sub-g-ext-ctrls; &sub-g-fbuf; @@ -616,7 +647,6 @@ and discussions on the V4L mailing list.</revremark> &sub-subdev-enum-frame-size; &sub-subdev-enum-mbus-code; &sub-subdev-g-crop; - &sub-subdev-g-edid; &sub-subdev-g-fmt; &sub-subdev-g-frame-interval; &sub-subdev-g-selection; diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 89891ad..cb77325 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 @@ -242,6 +254,60 @@ </tgroup> </table> + <table frame="none" pgwide="1" id="v4l2-event-src-change"> + <title>struct <structname>v4l2_event_src_change</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>changes</structfield></entry> + <entry> + A bitmask that tells what has changed. See <xref linkend="src-changes-flags" />. + </entry> + </row> + </tbody> + </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"> @@ -270,6 +336,23 @@ </tbody> </tgroup> </table> + + <table pgwide="1" frame="none" id="src-changes-flags"> + <title>Source Changes</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_EVENT_SRC_CH_RESOLUTION</constant></entry> + <entry>0x0001</entry> + <entry>This event gets triggered when a resolution change is + detected at an input. This can come from an input connector or + from a video decoder. + </entry> + </row> + </tbody> + </tgroup> + </table> </refsect1> <refsect1> &return-value; diff --git a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml index cd7720d..28a8c1e 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml @@ -1,11 +1,12 @@ <refentry id="vidioc-dv-timings-cap"> <refmeta> - <refentrytitle>ioctl VIDIOC_DV_TIMINGS_CAP</refentrytitle> + <refentrytitle>ioctl VIDIOC_DV_TIMINGS_CAP, VIDIOC_SUBDEV_DV_TIMINGS_CAP</refentrytitle> &manvol; </refmeta> <refnamediv> <refname>VIDIOC_DV_TIMINGS_CAP</refname> + <refname>VIDIOC_SUBDEV_DV_TIMINGS_CAP</refname> <refpurpose>The capabilities of the Digital Video receiver/transmitter</refpurpose> </refnamediv> @@ -33,7 +34,7 @@ <varlistentry> <term><parameter>request</parameter></term> <listitem> - <para>VIDIOC_DV_TIMINGS_CAP</para> + <para>VIDIOC_DV_TIMINGS_CAP, VIDIOC_SUBDEV_DV_TIMINGS_CAP</para> </listitem> </varlistentry> <varlistentry> @@ -54,10 +55,19 @@ interface and may change in the future.</para> </note> - <para>To query the capabilities of the DV receiver/transmitter applications can call -this ioctl and the driver will fill in the structure. Note that drivers may return + <para>To query the capabilities of the DV receiver/transmitter applications +can call the <constant>VIDIOC_DV_TIMINGS_CAP</constant> ioctl on a video node +and the driver will fill in the structure. Note that drivers may return different values after switching the video input or output.</para> + <para>When implemented by the driver DV capabilities of subdevices can be +queried by calling the <constant>VIDIOC_SUBDEV_DV_TIMINGS_CAP</constant> ioctl +directly on a subdevice node. The capabilities are specific to inputs (for DV +receivers) or outputs (for DV transmitters), applications must specify the +desired pad number in the &v4l2-dv-timings-cap; <structfield>pad</structfield> +field. Attempts to query capabilities on a pad that doesn't support them will +return an &EINVAL;.</para> + <table pgwide="1" frame="none" id="v4l2-bt-timings-cap"> <title>struct <structname>v4l2_bt_timings_cap</structname></title> <tgroup cols="3"> @@ -127,7 +137,14 @@ different values after switching the video input or output.</para> </row> <row> <entry>__u32</entry> - <entry><structfield>reserved</structfield>[3]</entry> + <entry><structfield>pad</structfield></entry> + <entry>Pad number as reported by the media controller API. This field + is only used when operating on a subdevice node. When operating on a + video node applications must set this field to zero.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[2]</entry> <entry>Reserved for future extensions. Drivers must set the array to zero.</entry> </row> <row> diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml index b3e17c1..b9fdfea 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml @@ -1,11 +1,12 @@ <refentry id="vidioc-enum-dv-timings"> <refmeta> - <refentrytitle>ioctl VIDIOC_ENUM_DV_TIMINGS</refentrytitle> + <refentrytitle>ioctl VIDIOC_ENUM_DV_TIMINGS, VIDIOC_SUBDEV_ENUM_DV_TIMINGS</refentrytitle> &manvol; </refmeta> <refnamediv> <refname>VIDIOC_ENUM_DV_TIMINGS</refname> + <refname>VIDIOC_SUBDEV_ENUM_DV_TIMINGS</refname> <refpurpose>Enumerate supported Digital Video timings</refpurpose> </refnamediv> @@ -33,7 +34,7 @@ <varlistentry> <term><parameter>request</parameter></term> <listitem> - <para>VIDIOC_ENUM_DV_TIMINGS</para> + <para>VIDIOC_ENUM_DV_TIMINGS, VIDIOC_SUBDEV_ENUM_DV_TIMINGS</para> </listitem> </varlistentry> <varlistentry> @@ -61,14 +62,21 @@ standards or even custom timings that are not in this list.</para> <para>To query the available timings, applications initialize the <structfield>index</structfield> field and zero the reserved array of &v4l2-enum-dv-timings; -and call the <constant>VIDIOC_ENUM_DV_TIMINGS</constant> ioctl with a pointer to this -structure. Drivers fill the rest of the structure or return an +and call the <constant>VIDIOC_ENUM_DV_TIMINGS</constant> ioctl on a video node with a +pointer to this structure. Drivers fill the rest of the structure or return an &EINVAL; when the index is out of bounds. To enumerate all supported DV timings, applications shall begin at index zero, incrementing by one until the driver returns <errorcode>EINVAL</errorcode>. Note that drivers may enumerate a different set of DV timings after switching the video input or output.</para> + <para>When implemented by the driver DV timings of subdevices can be queried +by calling the <constant>VIDIOC_SUBDEV_ENUM_DV_TIMINGS</constant> ioctl directly +on a subdevice node. The DV timings are specific to inputs (for DV receivers) or +outputs (for DV transmitters), applications must specify the desired pad number +in the &v4l2-enum-dv-timings; <structfield>pad</structfield> field. Attempts to +enumerate timings on a pad that doesn't support them will return an &EINVAL;.</para> + <table pgwide="1" frame="none" id="v4l2-enum-dv-timings"> <title>struct <structname>v4l2_enum_dv_timings</structname></title> <tgroup cols="3"> @@ -82,8 +90,16 @@ application.</entry> </row> <row> <entry>__u32</entry> - <entry><structfield>reserved</structfield>[3]</entry> - <entry>Reserved for future extensions. Drivers must set the array to zero.</entry> + <entry><structfield>pad</structfield></entry> + <entry>Pad number as reported by the media controller API. This field + is only used when operating on a subdevice node. When operating on a + video node applications must set this field to zero.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[2]</entry> + <entry>Reserved for future extensions. Drivers and applications must + set the array to zero.</entry> </row> <row> <entry>&v4l2-dv-timings;</entry> @@ -103,7 +119,7 @@ application.</entry> <term><errorcode>EINVAL</errorcode></term> <listitem> <para>The &v4l2-enum-dv-timings; <structfield>index</structfield> -is out of bounds.</para> +is out of bounds or the <structfield>pad</structfield> number is invalid.</para> </listitem> </varlistentry> <varlistentry> diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml index 6541ba0..4e8ea65 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml @@ -100,7 +100,7 @@ See <xref linkend="v4l2-tuner-type" /></entry> <entry><structfield>capability</structfield></entry> <entry spanname="hspan">The tuner/modulator capability flags for this frequency band, see <xref linkend="tuner-capability" />. The <constant>V4L2_TUNER_CAP_LOW</constant> -capability must be the same for all frequency bands of the selected tuner/modulator. +or <constant>V4L2_TUNER_CAP_1HZ</constant> capability must be the same for all frequency bands of the selected tuner/modulator. So either all bands have that capability set, or none of them have that capability.</entry> </row> <row> @@ -109,7 +109,8 @@ So either all bands have that capability set, or none of them have that capabili <entry spanname="hspan">The lowest tunable frequency in units of 62.5 kHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz, for this frequency band.</entry> +Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry> </row> <row> <entry>__u32</entry> @@ -117,7 +118,8 @@ Hz, for this frequency band.</entry> <entry spanname="hspan">The highest tunable frequency in units of 62.5 kHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz, for this frequency band.</entry> +Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry> </row> <row> <entry>__u32</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml b/Documentation/DocBook/media/v4l/vidioc-g-edid.xml index bbd18f0..ce4563b 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-edid.xml @@ -1,12 +1,12 @@ -<refentry id="vidioc-subdev-g-edid"> +<refentry id="vidioc-g-edid"> <refmeta> - <refentrytitle>ioctl VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</refentrytitle> + <refentrytitle>ioctl VIDIOC_G_EDID, VIDIOC_S_EDID</refentrytitle> &manvol; </refmeta> <refnamediv> - <refname>VIDIOC_SUBDEV_G_EDID</refname> - <refname>VIDIOC_SUBDEV_S_EDID</refname> + <refname>VIDIOC_G_EDID</refname> + <refname>VIDIOC_S_EDID</refname> <refpurpose>Get or set the EDID of a video receiver/transmitter</refpurpose> </refnamediv> @@ -16,7 +16,7 @@ <funcdef>int <function>ioctl</function></funcdef> <paramdef>int <parameter>fd</parameter></paramdef> <paramdef>int <parameter>request</parameter></paramdef> - <paramdef>struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef> + <paramdef>struct v4l2_edid *<parameter>argp</parameter></paramdef> </funcprototype> </funcsynopsis> <funcsynopsis> @@ -24,7 +24,7 @@ <funcdef>int <function>ioctl</function></funcdef> <paramdef>int <parameter>fd</parameter></paramdef> <paramdef>int <parameter>request</parameter></paramdef> - <paramdef>const struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef> + <paramdef>const struct v4l2_edid *<parameter>argp</parameter></paramdef> </funcprototype> </funcsynopsis> </refsynopsisdiv> @@ -42,7 +42,7 @@ <varlistentry> <term><parameter>request</parameter></term> <listitem> - <para>VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</para> + <para>VIDIOC_G_EDID, VIDIOC_S_EDID</para> </listitem> </varlistentry> <varlistentry> @@ -56,12 +56,20 @@ <refsect1> <title>Description</title> - <para>These ioctls can be used to get or set an EDID associated with an input pad - from a receiver or an output pad of a transmitter subdevice.</para> + <para>These ioctls can be used to get or set an EDID associated with an input + from a receiver or an output of a transmitter device. They can be + used with subdevice nodes (/dev/v4l-subdevX) or with video nodes (/dev/videoX).</para> + + <para>When used with video nodes the <structfield>pad</structfield> field represents the + input (for video capture devices) or output (for video output devices) index as + is returned by &VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively. When used + with subdevice nodes the <structfield>pad</structfield> field represents the + input or output pad of the subdevice. If there is no EDID support for the given + <structfield>pad</structfield> value, then the &EINVAL; will be returned.</para> <para>To get the EDID data the application has to fill in the <structfield>pad</structfield>, <structfield>start_block</structfield>, <structfield>blocks</structfield> and <structfield>edid</structfield> - fields and call <constant>VIDIOC_SUBDEV_G_EDID</constant>. The current EDID from block + fields and call <constant>VIDIOC_G_EDID</constant>. The current EDID from block <structfield>start_block</structfield> and of size <structfield>blocks</structfield> will be placed in the memory <structfield>edid</structfield> points to. The <structfield>edid</structfield> pointer must point to memory at least <structfield>blocks</structfield> * 128 bytes @@ -91,15 +99,17 @@ data in some way. In any case, the end result is the same: the EDID is no longer available. </para> - <table pgwide="1" frame="none" id="v4l2-subdev-edid"> - <title>struct <structname>v4l2_subdev_edid</structname></title> + <table pgwide="1" frame="none" id="v4l2-edid"> + <title>struct <structname>v4l2_edid</structname></title> <tgroup cols="3"> &cs-str; <tbody valign="top"> <row> <entry>__u32</entry> <entry><structfield>pad</structfield></entry> - <entry>Pad for which to get/set the EDID blocks.</entry> + <entry>Pad for which to get/set the EDID blocks. When used with a video device + node the pad represents the input or output index as returned by + &VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively.</entry> </row> <row> <entry>__u32</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index b3bb957..c5bdbfc 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> @@ -327,7 +362,12 @@ These controls are described in <xref These controls are described in <xref linkend="fm-rx-controls" />.</entry> </row> - + <row> + <entry><constant>V4L2_CTRL_CLASS_RF_TUNER</constant></entry> + <entry>0xa20000</entry> + <entry>The class containing RF tuner controls. +These controls are described in <xref linkend="rf-tuner-controls" />.</entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml b/Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml index 7c63815..2046073 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-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml index ee8f56e..4fe19a7a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml @@ -172,6 +172,13 @@ capture and output devices.</entry> </row> <row> <entry></entry> + <entry>&v4l2-sdr-format;</entry> + <entry><structfield>sdr</structfield></entry> + <entry>Definition of a data format, see +<xref linkend="pixfmt" />, used by SDR capture devices.</entry> + </row> + <row> + <entry></entry> <entry>__u8</entry> <entry><structfield>raw_data</structfield>[200]</entry> <entry>Place holder for future extensions.</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml index c7a1c46..d1034fb 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml @@ -109,9 +109,10 @@ See <xref linkend="v4l2-tuner-type" /></entry> <entry>__u32</entry> <entry><structfield>frequency</structfield></entry> <entry>Tuning frequency in units of 62.5 kHz, or if the -&v4l2-tuner; or &v4l2-modulator; <structfield>capabilities</structfield> flag +&v4l2-tuner; or &v4l2-modulator; <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz.</entry> +Hz. A 1 Hz unit is used when the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry> </row> <row> <entry>__u32</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml index 7f4ac7e..7068b59 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml @@ -113,7 +113,8 @@ change for example with the current video standard.</entry> <entry>The lowest tunable frequency in units of 62.5 KHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz.</entry> +Hz, or if the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry> </row> <row> <entry>__u32</entry> @@ -121,7 +122,8 @@ Hz.</entry> <entry>The highest tunable frequency in units of 62.5 KHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz.</entry> +Hz, or if the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry> </row> <row> <entry>__u32</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml index b11ec75..9c04ac8 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-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml index 6cc8201..b0d8659 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml @@ -134,7 +134,9 @@ the structure refers to a radio tuner the <entry spanname="hspan">The lowest tunable frequency in units of 62.5 kHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz. If multiple frequency bands are supported, then +Hz, or if the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz. +If multiple frequency bands are supported, then <structfield>rangelow</structfield> is the lowest frequency of all the frequency bands.</entry> </row> @@ -144,7 +146,9 @@ of all the frequency bands.</entry> <entry spanname="hspan">The highest tunable frequency in units of 62.5 kHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz. If multiple frequency bands are supported, then +Hz, or if the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz. +If multiple frequency bands are supported, then <structfield>rangehigh</structfield> is the highest frequency of all the frequency bands.</entry> </row> @@ -270,7 +274,7 @@ applications must set the array to zero.</entry> <entry><constant>V4L2_TUNER_CAP_LOW</constant></entry> <entry>0x0001</entry> <entry>When set, tuning frequencies are expressed in units of -62.5 Hz, otherwise in units of 62.5 kHz.</entry> +62.5 Hz instead of 62.5 kHz.</entry> </row> <row> <entry><constant>V4L2_TUNER_CAP_NORM</constant></entry> @@ -360,6 +364,11 @@ radio tuners.</entry> <entry>The range to search when using the hardware seek functionality is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details.</entry> </row> + <row> + <entry><constant>V4L2_TUNER_CAP_1HZ</constant></entry> + <entry>0x1000</entry> + <entry>When set, tuning frequencies are expressed in units of 1 Hz instead of 62.5 kHz.</entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index d5a3c97..d0c5e60 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -296,6 +296,18 @@ modulator programming see <xref linkend="tuner" />.</entry> </row> <row> + <entry><constant>V4L2_CAP_SDR_CAPTURE</constant></entry> + <entry>0x00100000</entry> + <entry>The device supports the +<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 e6645b9..2bd98fd 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-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml index 5b379e7..a5fc4c4 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -121,7 +121,9 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry> <entry>If non-zero, the lowest tunable frequency of the band to search in units of 62.5 kHz, or if the &v4l2-tuner; <structfield>capability</structfield> field has the -<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz. +<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz or if the &v4l2-tuner; +<structfield>capability</structfield> field has the +<constant>V4L2_TUNER_CAP_1HZ</constant> flag set, in units of 1 Hz. If <structfield>rangelow</structfield> is zero a reasonable default value is used.</entry> </row> @@ -131,7 +133,9 @@ is used.</entry> <entry>If non-zero, the highest tunable frequency of the band to search in units of 62.5 kHz, or if the &v4l2-tuner; <structfield>capability</structfield> field has the -<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz. +<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz or if the &v4l2-tuner; +<structfield>capability</structfield> field has the +<constant>V4L2_TUNER_CAP_1HZ</constant> flag set, in units of 1 Hz. If <structfield>rangehigh</structfield> is zero a reasonable default value is used.</entry> </row> diff --git a/Documentation/DocBook/media/v4l/vidioc-streamon.xml b/Documentation/DocBook/media/v4l/vidioc-streamon.xml index 65dff55..df2c63d 100644 --- a/Documentation/DocBook/media/v4l/vidioc-streamon.xml +++ b/Documentation/DocBook/media/v4l/vidioc-streamon.xml @@ -52,16 +52,24 @@ <para>The <constant>VIDIOC_STREAMON</constant> and <constant>VIDIOC_STREAMOFF</constant> ioctl start and stop the capture or output process during streaming (<link linkend="mmap">memory -mapping</link> or <link linkend="userp">user pointer</link>) I/O.</para> +mapping</link>, <link linkend="userp">user pointer</link> or +<link linkend="dmabuf">DMABUF</link>) I/O.</para> - <para>Specifically the capture hardware is disabled and no input + <para>Capture hardware is disabled and no input buffers are filled (if there are any empty buffers in the incoming queue) until <constant>VIDIOC_STREAMON</constant> has been called. -Accordingly the output hardware is disabled, no video signal is +Output hardware is disabled and no video signal is produced until <constant>VIDIOC_STREAMON</constant> has been called. The ioctl will succeed when at least one output buffer is in the incoming queue.</para> + <para>Memory-to-memory devices will not start until +<constant>VIDIOC_STREAMON</constant> has been called for both the capture +and output stream types.</para> + + <para>If <constant>VIDIOC_STREAMON</constant> fails then any already +queued buffers will remain queued.</para> + <para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of aborting or finishing any DMA in progress, unlocks any user pointer buffers locked in physical memory, and it removes all buffers from the @@ -70,14 +78,22 @@ dequeued yet will be lost, likewise all images enqueued for output but not transmitted yet. I/O returns to the same state as after calling &VIDIOC-REQBUFS; and can be restarted accordingly.</para> + <para>If buffers have been queued with &VIDIOC-QBUF; and +<constant>VIDIOC_STREAMOFF</constant> is called without ever having +called <constant>VIDIOC_STREAMON</constant>, then those queued buffers +will also be removed from the incoming queue and all are returned to the +same state as after calling &VIDIOC-REQBUFS; and can be restarted +accordingly.</para> + <para>Both ioctls take a pointer to an integer, the desired buffer or stream type. This is the same as &v4l2-requestbuffers; <structfield>type</structfield>.</para> <para>If <constant>VIDIOC_STREAMON</constant> is called when streaming is already in progress, or if <constant>VIDIOC_STREAMOFF</constant> is called -when streaming is already stopped, then the ioctl does nothing and 0 is -returned.</para> +when streaming is already stopped, then 0 is returned. Nothing happens in the +case of <constant>VIDIOC_STREAMON</constant>, but <constant>VIDIOC_STREAMOFF</constant> +will return queued buffers to their starting state as mentioned above.</para> <para>Note that applications can be preempted for unknown periods right before or after the <constant>VIDIOC_STREAMON</constant> or @@ -93,7 +109,7 @@ synchronize with other events.</para> <varlistentry> <term><errorcode>EINVAL</errorcode></term> <listitem> - <para>The buffer<structfield>type</structfield> is not supported, + <para>The buffer <structfield>type</structfield> is not supported, or no buffers have been allocated (memory mapping) or enqueued (output) yet.</para> </listitem> diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 5c70b61..9f60956 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml @@ -155,6 +155,34 @@ </entry> </row> <row> + <entry><constant>V4L2_EVENT_SOURCE_CHANGE</constant></entry> + <entry>5</entry> + <entry> + <para>This event is triggered when a source parameter change is + detected during runtime by the video device. It can be a + runtime resolution change triggered by a video decoder or the + format change happening on an input connector. + This event requires that the <structfield>id</structfield> + matches the input index (when used with a video device node) + or the pad index (when used with a subdevice node) from which + you want to receive events.</para> + + <para>This event has a &v4l2-event-src-change; associated + with it. The <structfield>changes</structfield> bitfield denotes + what has changed for the subscribed pad. If multiple events + occurred before application could dequeue them, then the changes + will have the ORed value of all the events generated.</para> + </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/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index ab56f89c..03f9a1f 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -34,22 +34,20 @@ <book id="media_api"> <bookinfo> -<title>LINUX MEDIA INFRASTRUCTURE API</title> - -<copyright> - <year>2009-2012</year> - <holder>LinuxTV Developers</holder> -</copyright> - -<legalnotice> - -<para>Permission is granted to copy, distribute and/or modify -this document under the terms of the GNU Free Documentation License, -Version 1.1 or any later version published by the Free Software -Foundation. A copy of the license is included in the chapter entitled -"GNU Free Documentation License"</para> -</legalnotice> - + <title>LINUX MEDIA INFRASTRUCTURE API</title> + + <copyright> + <year>2009-2014</year> + <holder>LinuxTV Developers</holder> + </copyright> + + <legalnotice> + <para>Permission is granted to copy, distribute and/or modify + this document under the terms of the GNU Free Documentation License, + Version 1.1 or any later version published by the Free Software + Foundation. A copy of the license is included in the chapter entitled + "GNU Free Documentation License"</para> + </legalnotice> </bookinfo> <toc></toc> <!-- autogenerated --> @@ -60,70 +58,30 @@ Foundation. A copy of the license is included in the chapter entitled <para>This document covers the Linux Kernel to Userspace API's used by video and radio streaming devices, including video cameras, analog and digital TV receiver cards, AM/FM receiver cards, - streaming capture devices.</para> + streaming capture and output devices, codec devices and remote + controllers.</para> <para>It is divided into four parts.</para> - <para>The first part covers radio, capture, - cameras and analog TV devices.</para> + <para>The first part covers radio, video capture and output, + cameras, analog TV devices and codecs.</para> <para>The second part covers the API used for digital TV and Internet reception via one of the several digital tv standards. While it is called as DVB API, in fact it covers several different video standards including DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated - to documment support also for DVB-S2, ISDB-T and ISDB-S.</para> + to document support also for DVB-S2, ISDB-T and ISDB-S.</para> <para>The third part covers the Remote Controller API.</para> <para>The fourth part covers the Media Controller API.</para> <para>For additional information and for the latest development code, see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para> <para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para> - </preface> -<part id="v4l2spec"> -&sub-v4l2; -</part> -<part id="dvbapi"> -&sub-dvbapi; -</part> -<part id="v4ldvb_common"> -<partinfo> -<authorgroup> -<author> -<firstname>Mauro</firstname> -<surname>Chehab</surname> -<othername role="mi">Carvalho</othername> -<affiliation><address><email>mchehab@redhat.com</email></address></affiliation> -<contrib>Initial version.</contrib> -</author> -</authorgroup> -<copyright> - <year>2009-2012</year> - <holder>Mauro Carvalho Chehab</holder> -</copyright> - -<revhistory> -<!-- Put document revisions here, newest first. --> -<revision> -<revnumber>1.0.0</revnumber> -<date>2009-09-06</date> -<authorinitials>mcc</authorinitials> -<revremark>Initial revision</revremark> -</revision> -</revhistory> -</partinfo> - -<title>Remote Controller API</title> -<chapter id="remote_controllers"> -&sub-remote_controllers; -</chapter> -</part> -<part id="media_common"> -&sub-media-controller; -</part> - -<chapter id="gen_errors"> -&sub-gen-errors; -</chapter> +<part id="v4l2spec">&sub-v4l2;</part> +<part id="dvbapi">&sub-dvbapi;</part> +<part id="remotes">&sub-remote_controllers;</part> +<part id="media_common">&sub-media-controller;</part> +<chapter id="gen_errors">&sub-gen-errors;</chapter> &sub-fdl-appendix; diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index cd11926..7da8f04 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -91,7 +91,7 @@ <listitem><para> [MTD Interface]</para><para> These functions provide the interface to the MTD kernel API. - They are not replacable and provide functionality + They are not replaceable and provide functionality which is complete hardware independent. </para></listitem> <listitem><para> @@ -100,14 +100,14 @@ </para></listitem> <listitem><para> [GENERIC]</para><para> - Generic functions are not replacable and provide functionality + Generic functions are not replaceable and provide functionality which is complete hardware independent. </para></listitem> <listitem><para> [DEFAULT]</para><para> Default functions provide hardware related functionality which is suitable for most of the implementations. These functions can be replaced by the - board driver if neccecary. Those functions are called via pointers in the + board driver if necessary. Those functions are called via pointers in the NAND chip description structure. The board driver can set the functions which should be replaced by board dependent functions before calling nand_scan(). If the function pointer is NULL on entry to nand_scan() then the pointer @@ -264,7 +264,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd) is set up nand_scan() is called. This function tries to detect and identify then chip. If a chip is found all the internal data fields are initialized accordingly. - The structure(s) have to be zeroed out first and then filled with the neccecary + The structure(s) have to be zeroed out first and then filled with the necessary information about the device. </para> <programlisting> @@ -327,7 +327,7 @@ module_init(board_init); <sect1 id="Exit_function"> <title>Exit function</title> <para> - The exit function is only neccecary if the driver is + The exit function is only necessary if the driver is compiled as a module. It releases all resources which are held by the chip driver and unregisters the partitions in the MTD layer. @@ -494,7 +494,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) in this case. See rts_from4.c and diskonchip.c for implementation reference. In those cases we must also use bad block tables on FLASH, because the ECC layout is - interferring with the bad block marker positions. + interfering with the bad block marker positions. See bad block table support for details. </para> </sect2> @@ -542,7 +542,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) <para> nand_scan() calls the function nand_default_bbt(). nand_default_bbt() selects appropriate default - bad block table desriptors depending on the chip information + bad block table descriptors depending on the chip information which was retrieved by nand_scan(). </para> <para> @@ -554,7 +554,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) <sect2 id="Flash_based_tables"> <title>Flash based tables</title> <para> - It may be desired or neccecary to keep a bad block table in FLASH. + It may be desired or necessary to keep a bad block table in FLASH. For AG-AND chips this is mandatory, as they have no factory marked bad blocks. They have factory marked good blocks. The marker pattern is erased when the block is erased to be reused. So in case of @@ -565,10 +565,10 @@ static void board_select_chip (struct mtd_info *mtd, int chip) of the blocks. </para> <para> - The blocks in which the tables are stored are procteted against + The blocks in which the tables are stored are protected against accidental access by marking them bad in the memory bad block table. The bad block table management functions are allowed - to circumvernt this protection. + to circumvent this protection. </para> <para> The simplest way to activate the FLASH based bad block table support @@ -592,7 +592,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) User defined tables are created by filling out a nand_bbt_descr structure and storing the pointer in the nand_chip structure member bbt_td before calling nand_scan(). - If a mirror table is neccecary a second structure must be + If a mirror table is necessary a second structure must be created and a pointer to this structure must be stored in bbt_md inside the nand_chip structure. If the bbt_md member is set to NULL then only the main table is used @@ -666,7 +666,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) <para> For automatic placement some blocks must be reserved for bad block table storage. The number of reserved blocks is defined - in the maxblocks member of the babd block table description structure. + in the maxblocks member of the bad block table description structure. Reserving 4 blocks for mirrored tables should be a reasonable number. This also limits the number of blocks which are scanned for the bad block table ident pattern. @@ -1068,11 +1068,11 @@ in this page</entry> <chapter id="filesystems"> <title>Filesystem support</title> <para> - The NAND driver provides all neccecary functions for a + The NAND driver provides all necessary functions for a filesystem via the MTD interface. </para> <para> - Filesystems must be aware of the NAND pecularities and + Filesystems must be aware of the NAND peculiarities and restrictions. One major restrictions of NAND Flash is, that you cannot write as often as you want to a page. The consecutive writes to a page, before erasing it again, are restricted to 1-3 writes, depending on the @@ -1222,7 +1222,7 @@ in this page</entry> #define NAND_BBT_VERSION 0x00000100 /* Create a bbt if none axists */ #define NAND_BBT_CREATE 0x00000200 -/* Write bbt if neccecary */ +/* Write bbt if necessary */ #define NAND_BBT_WRITE 0x00001000 /* Read and write back block contents when writing bbt */ #define NAND_BBT_SAVECONTENT 0x00002000 diff --git a/Documentation/DocBook/regulator.tmpl b/Documentation/DocBook/regulator.tmpl index 346e552..3b08a08 100644 --- a/Documentation/DocBook/regulator.tmpl +++ b/Documentation/DocBook/regulator.tmpl @@ -155,7 +155,7 @@ release regulators. Functions are provided to <link linkend='API-regulator-enable'>enable</link> and <link linkend='API-regulator-disable'>disable</link> the - reguator and to get and set the runtime parameters of the + regulator and to get and set the runtime parameters of the regulator. </para> <para> diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index 9561815..bbe9c1f 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl @@ -766,10 +766,10 @@ framework to set up sysfs files for this region. Simply leave it alone. <para> The dynamic memory regions will be allocated when the UIO device file, <varname>/dev/uioX</varname> is opened. - Simiar to static memory resources, the memory region information for + Similar to static memory resources, the memory region information for dynamic regions is then visible via sysfs at <varname>/sys/class/uio/uioX/maps/mapY/*</varname>. - The dynmaic memory regions will be freed when the UIO device file is + The dynamic memory regions will be freed when the UIO device file is closed. When no processes are holding the device file open, the address returned to userspace is ~0. </para> diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl index 8d57c18..85fc0e2 100644 --- a/Documentation/DocBook/usb.tmpl +++ b/Documentation/DocBook/usb.tmpl @@ -153,7 +153,7 @@ <listitem><para>The Linux USB API supports synchronous calls for control and bulk messages. - It also supports asynchnous calls for all kinds of data transfer, + It also supports asynchronous calls for all kinds of data transfer, using request structures called "URBs" (USB Request Blocks). </para></listitem> diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl index d0056a4..6f639d9 100644 --- a/Documentation/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl @@ -5696,7 +5696,7 @@ struct _snd_pcm_runtime { suspending the PCM operations via <function>snd_pcm_suspend_all()</function> or <function>snd_pcm_suspend()</function>. It means that the PCM - streams are already stoppped when the register snapshot is + streams are already stopped when the register snapshot is taken. But, remember that you don't have to restart the PCM stream in the resume callback. It'll be restarted via trigger call with <constant>SNDRV_PCM_TRIGGER_RESUME</constant> diff --git a/Documentation/DocBook/writing_musb_glue_layer.tmpl b/Documentation/DocBook/writing_musb_glue_layer.tmpl new file mode 100644 index 0000000..837eca7 --- /dev/null +++ b/Documentation/DocBook/writing_musb_glue_layer.tmpl @@ -0,0 +1,873 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" + "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> + +<book id="Writing-MUSB-Glue-Layer"> + <bookinfo> + <title>Writing an MUSB Glue Layer</title> + + <authorgroup> + <author> + <firstname>Apelete</firstname> + <surname>Seketeli</surname> + <affiliation> + <address> + <email>apelete at seketeli.net</email> + </address> + </affiliation> + </author> + </authorgroup> + + <copyright> + <year>2014</year> + <holder>Apelete Seketeli</holder> + </copyright> + + <legalnotice> + <para> + This documentation is free software; you can redistribute it + and/or modify it under the terms of the GNU General Public + License as published by the Free Software Foundation; either + version 2 of the License, or (at your option) any later version. + </para> + + <para> + This documentation is distributed in the hope that it will be + useful, but WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + See the GNU General Public License for more details. + </para> + + <para> + You should have received a copy of the GNU General Public License + along with this documentation; if not, write to the Free Software + Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA + </para> + + <para> + For more details see the file COPYING in the Linux kernel source + tree. + </para> + </legalnotice> + </bookinfo> + +<toc></toc> + + <chapter id="introduction"> + <title>Introduction</title> + <para> + The Linux MUSB subsystem is part of the larger Linux USB + subsystem. It provides support for embedded USB Device Controllers + (UDC) that do not use Universal Host Controller Interface (UHCI) + or Open Host Controller Interface (OHCI). + </para> + <para> + Instead, these embedded UDC rely on the USB On-the-Go (OTG) + specification which they implement at least partially. The silicon + reference design used in most cases is the Multipoint USB + Highspeed Dual-Role Controller (MUSB HDRC) found in the Mentor + Graphics Inventra™ design. + </para> + <para> + As a self-taught exercise I have written an MUSB glue layer for + the Ingenic JZ4740 SoC, modelled after the many MUSB glue layers + in the kernel source tree. This layer can be found at + drivers/usb/musb/jz4740.c. In this documentation I will walk + through the basics of the jz4740.c glue layer, explaining the + different pieces and what needs to be done in order to write your + own device glue layer. + </para> + </chapter> + + <chapter id="linux-musb-basics"> + <title>Linux MUSB Basics</title> + <para> + To get started on the topic, please read USB On-the-Go Basics (see + Resources) which provides an introduction of USB OTG operation at + the hardware level. A couple of wiki pages by Texas Instruments + and Analog Devices also provide an overview of the Linux kernel + MUSB configuration, albeit focused on some specific devices + provided by these companies. Finally, getting acquainted with the + USB specification at USB home page may come in handy, with + practical instance provided through the Writing USB Device Drivers + documentation (again, see Resources). + </para> + <para> + Linux USB stack is a layered architecture in which the MUSB + controller hardware sits at the lowest. The MUSB controller driver + abstract the MUSB controller hardware to the Linux USB stack. + </para> + <programlisting> + ------------------------ + | | <------- drivers/usb/gadget + | Linux USB Core Stack | <------- drivers/usb/host + | | <------- drivers/usb/core + ------------------------ + ⬍ + -------------------------- + | | <------ drivers/usb/musb/musb_gadget.c + | MUSB Controller driver | <------ drivers/usb/musb/musb_host.c + | | <------ drivers/usb/musb/musb_core.c + -------------------------- + ⬍ + --------------------------------- + | MUSB Platform Specific Driver | + | | <-- drivers/usb/musb/jz4740.c + | aka "Glue Layer" | + --------------------------------- + ⬍ + --------------------------------- + | MUSB Controller Hardware | + --------------------------------- + </programlisting> + <para> + As outlined above, the glue layer is actually the platform + specific code sitting in between the controller driver and the + controller hardware. + </para> + <para> + Just like a Linux USB driver needs to register itself with the + Linux USB subsystem, the MUSB glue layer needs first to register + itself with the MUSB controller driver. This will allow the + controller driver to know about which device the glue layer + supports and which functions to call when a supported device is + detected or released; remember we are talking about an embedded + controller chip here, so no insertion or removal at run-time. + </para> + <para> + All of this information is passed to the MUSB controller driver + through a platform_driver structure defined in the glue layer as: + </para> + <programlisting linenumbering="numbered"> +static struct platform_driver jz4740_driver = { + .probe = jz4740_probe, + .remove = jz4740_remove, + .driver = { + .name = "musb-jz4740", + }, +}; + </programlisting> + <para> + The probe and remove function pointers are called when a matching + device is detected and, respectively, released. The name string + describes the device supported by this glue layer. In the current + case it matches a platform_device structure declared in + arch/mips/jz4740/platform.c. Note that we are not using device + tree bindings here. + </para> + <para> + In order to register itself to the controller driver, the glue + layer goes through a few steps, basically allocating the + controller hardware resources and initialising a couple of + circuits. To do so, it needs to keep track of the information used + throughout these steps. This is done by defining a private + jz4740_glue structure: + </para> + <programlisting linenumbering="numbered"> +struct jz4740_glue { + struct device *dev; + struct platform_device *musb; + struct clk *clk; +}; + </programlisting> + <para> + The dev and musb members are both device structure variables. The + first one holds generic information about the device, since it's + the basic device structure, and the latter holds information more + closely related to the subsystem the device is registered to. The + clk variable keeps information related to the device clock + operation. + </para> + <para> + Let's go through the steps of the probe function that leads the + glue layer to register itself to the controller driver. + </para> + <para> + N.B.: For the sake of readability each function will be split in + logical parts, each part being shown as if it was independent from + the others. + </para> + <programlisting linenumbering="numbered"> +static int jz4740_probe(struct platform_device *pdev) +{ + struct platform_device *musb; + struct jz4740_glue *glue; + struct clk *clk; + int ret; + + glue = devm_kzalloc(&pdev->dev, sizeof(*glue), GFP_KERNEL); + if (!glue) + return -ENOMEM; + + musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO); + if (!musb) { + dev_err(&pdev->dev, "failed to allocate musb device\n"); + return -ENOMEM; + } + + clk = devm_clk_get(&pdev->dev, "udc"); + if (IS_ERR(clk)) { + dev_err(&pdev->dev, "failed to get clock\n"); + ret = PTR_ERR(clk); + goto err_platform_device_put; + } + + ret = clk_prepare_enable(clk); + if (ret) { + dev_err(&pdev->dev, "failed to enable clock\n"); + goto err_platform_device_put; + } + + musb->dev.parent = &pdev->dev; + + glue->dev = &pdev->dev; + glue->musb = musb; + glue->clk = clk; + + return 0; + +err_platform_device_put: + platform_device_put(musb); + return ret; +} + </programlisting> + <para> + The first few lines of the probe function allocate and assign the + glue, musb and clk variables. The GFP_KERNEL flag (line 8) allows + the allocation process to sleep and wait for memory, thus being + usable in a blocking situation. The PLATFORM_DEVID_AUTO flag (line + 12) allows automatic allocation and management of device IDs in + order to avoid device namespace collisions with explicit IDs. With + devm_clk_get() (line 18) the glue layer allocates the clock -- the + <literal>devm_</literal> prefix indicates that clk_get() is + managed: it automatically frees the allocated clock resource data + when the device is released -- and enable it. + </para> + <para> + Then comes the registration steps: + </para> + <programlisting linenumbering="numbered"> +static int jz4740_probe(struct platform_device *pdev) +{ + struct musb_hdrc_platform_data *pdata = &jz4740_musb_platform_data; + + pdata->platform_ops = &jz4740_musb_ops; + + platform_set_drvdata(pdev, glue); + + ret = platform_device_add_resources(musb, pdev->resource, + pdev->num_resources); + if (ret) { + dev_err(&pdev->dev, "failed to add resources\n"); + goto err_clk_disable; + } + + ret = platform_device_add_data(musb, pdata, sizeof(*pdata)); + if (ret) { + dev_err(&pdev->dev, "failed to add platform_data\n"); + goto err_clk_disable; + } + + return 0; + +err_clk_disable: + clk_disable_unprepare(clk); +err_platform_device_put: + platform_device_put(musb); + return ret; +} + </programlisting> + <para> + The first step is to pass the device data privately held by the + glue layer on to the controller driver through + platform_set_drvdata() (line 7). Next is passing on the device + resources information, also privately held at that point, through + platform_device_add_resources() (line 9). + </para> + <para> + Finally comes passing on the platform specific data to the + controller driver (line 16). Platform data will be discussed in + <link linkend="device-platform-data">Chapter 4</link>, but here + we are looking at the platform_ops function pointer (line 5) in + musb_hdrc_platform_data structure (line 3). This function + pointer allows the MUSB controller driver to know which function + to call for device operation: + </para> + <programlisting linenumbering="numbered"> +static const struct musb_platform_ops jz4740_musb_ops = { + .init = jz4740_musb_init, + .exit = jz4740_musb_exit, +}; + </programlisting> + <para> + Here we have the minimal case where only init and exit functions + are called by the controller driver when needed. Fact is the + JZ4740 MUSB controller is a basic controller, lacking some + features found in other controllers, otherwise we may also have + pointers to a few other functions like a power management function + or a function to switch between OTG and non-OTG modes, for + instance. + </para> + <para> + At that point of the registration process, the controller driver + actually calls the init function: + </para> + <programlisting linenumbering="numbered"> +static int jz4740_musb_init(struct musb *musb) +{ + musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2); + if (!musb->xceiv) { + pr_err("HS UDC: no transceiver configured\n"); + return -ENODEV; + } + + /* Silicon does not implement ConfigData register. + * Set dyn_fifo to avoid reading EP config from hardware. + */ + musb->dyn_fifo = true; + + musb->isr = jz4740_musb_interrupt; + + return 0; +} + </programlisting> + <para> + The goal of jz4740_musb_init() is to get hold of the transceiver + driver data of the MUSB controller hardware and pass it on to the + MUSB controller driver, as usual. The transceiver is the circuitry + inside the controller hardware responsible for sending/receiving + the USB data. Since it is an implementation of the physical layer + of the OSI model, the transceiver is also referred to as PHY. + </para> + <para> + Getting hold of the MUSB PHY driver data is done with + usb_get_phy() which returns a pointer to the structure + containing the driver instance data. The next couple of + instructions (line 12 and 14) are used as a quirk and to setup + IRQ handling respectively. Quirks and IRQ handling will be + discussed later in <link linkend="device-quirks">Chapter + 5</link> and <link linkend="handling-irqs">Chapter 3</link>. + </para> + <programlisting linenumbering="numbered"> +static int jz4740_musb_exit(struct musb *musb) +{ + usb_put_phy(musb->xceiv); + + return 0; +} + </programlisting> + <para> + Acting as the counterpart of init, the exit function releases the + MUSB PHY driver when the controller hardware itself is about to be + released. + </para> + <para> + Again, note that init and exit are fairly simple in this case due + to the basic set of features of the JZ4740 controller hardware. + When writing an musb glue layer for a more complex controller + hardware, you might need to take care of more processing in those + two functions. + </para> + <para> + Returning from the init function, the MUSB controller driver jumps + back into the probe function: + </para> + <programlisting linenumbering="numbered"> +static int jz4740_probe(struct platform_device *pdev) +{ + ret = platform_device_add(musb); + if (ret) { + dev_err(&pdev->dev, "failed to register musb device\n"); + goto err_clk_disable; + } + + return 0; + +err_clk_disable: + clk_disable_unprepare(clk); +err_platform_device_put: + platform_device_put(musb); + return ret; +} + </programlisting> + <para> + This is the last part of the device registration process where the + glue layer adds the controller hardware device to Linux kernel + device hierarchy: at this stage, all known information about the + device is passed on to the Linux USB core stack. + </para> + <programlisting linenumbering="numbered"> +static int jz4740_remove(struct platform_device *pdev) +{ + struct jz4740_glue *glue = platform_get_drvdata(pdev); + + platform_device_unregister(glue->musb); + clk_disable_unprepare(glue->clk); + + return 0; +} + </programlisting> + <para> + Acting as the counterpart of probe, the remove function unregister + the MUSB controller hardware (line 5) and disable the clock (line + 6), allowing it to be gated. + </para> + </chapter> + + <chapter id="handling-irqs"> + <title>Handling IRQs</title> + <para> + Additionally to the MUSB controller hardware basic setup and + registration, the glue layer is also responsible for handling the + IRQs: + </para> + <programlisting linenumbering="numbered"> +static irqreturn_t jz4740_musb_interrupt(int irq, void *__hci) +{ + unsigned long flags; + irqreturn_t retval = IRQ_NONE; + struct musb *musb = __hci; + + spin_lock_irqsave(&musb->lock, flags); + + musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB); + musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX); + musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX); + + /* + * The controller is gadget only, the state of the host mode IRQ bits is + * undefined. Mask them to make sure that the musb driver core will + * never see them set + */ + musb->int_usb &= MUSB_INTR_SUSPEND | MUSB_INTR_RESUME | + MUSB_INTR_RESET | MUSB_INTR_SOF; + + if (musb->int_usb || musb->int_tx || musb->int_rx) + retval = musb_interrupt(musb); + + spin_unlock_irqrestore(&musb->lock, flags); + + return retval; +} + </programlisting> + <para> + Here the glue layer mostly has to read the relevant hardware + registers and pass their values on to the controller driver which + will handle the actual event that triggered the IRQ. + </para> + <para> + The interrupt handler critical section is protected by the + spin_lock_irqsave() and counterpart spin_unlock_irqrestore() + functions (line 7 and 24 respectively), which prevent the + interrupt handler code to be run by two different threads at the + same time. + </para> + <para> + Then the relevant interrupt registers are read (line 9 to 11): + </para> + <itemizedlist> + <listitem> + <para> + MUSB_INTRUSB: indicates which USB interrupts are currently + active, + </para> + </listitem> + <listitem> + <para> + MUSB_INTRTX: indicates which of the interrupts for TX + endpoints are currently active, + </para> + </listitem> + <listitem> + <para> + MUSB_INTRRX: indicates which of the interrupts for TX + endpoints are currently active. + </para> + </listitem> + </itemizedlist> + <para> + Note that musb_readb() is used to read 8-bit registers at most, + while musb_readw() allows us to read at most 16-bit registers. + There are other functions that can be used depending on the size + of your device registers. See musb_io.h for more information. + </para> + <para> + Instruction on line 18 is another quirk specific to the JZ4740 + USB device controller, which will be discussed later in <link + linkend="device-quirks">Chapter 5</link>. + </para> + <para> + The glue layer still needs to register the IRQ handler though. + Remember the instruction on line 14 of the init function: + </para> + <programlisting linenumbering="numbered"> +static int jz4740_musb_init(struct musb *musb) +{ + musb->isr = jz4740_musb_interrupt; + + return 0; +} + </programlisting> + <para> + This instruction sets a pointer to the glue layer IRQ handler + function, in order for the controller hardware to call the handler + back when an IRQ comes from the controller hardware. The interrupt + handler is now implemented and registered. + </para> + </chapter> + + <chapter id="device-platform-data"> + <title>Device Platform Data</title> + <para> + In order to write an MUSB glue layer, you need to have some data + describing the hardware capabilities of your controller hardware, + which is called the platform data. + </para> + <para> + Platform data is specific to your hardware, though it may cover a + broad range of devices, and is generally found somewhere in the + arch/ directory, depending on your device architecture. + </para> + <para> + For instance, platform data for the JZ4740 SoC is found in + arch/mips/jz4740/platform.c. In the platform.c file each device of + the JZ4740 SoC is described through a set of structures. + </para> + <para> + Here is the part of arch/mips/jz4740/platform.c that covers the + USB Device Controller (UDC): + </para> + <programlisting linenumbering="numbered"> +/* USB Device Controller */ +struct platform_device jz4740_udc_xceiv_device = { + .name = "usb_phy_gen_xceiv", + .id = 0, +}; + +static struct resource jz4740_udc_resources[] = { + [0] = { + .start = JZ4740_UDC_BASE_ADDR, + .end = JZ4740_UDC_BASE_ADDR + 0x10000 - 1, + .flags = IORESOURCE_MEM, + }, + [1] = { + .start = JZ4740_IRQ_UDC, + .end = JZ4740_IRQ_UDC, + .flags = IORESOURCE_IRQ, + .name = "mc", + }, +}; + +struct platform_device jz4740_udc_device = { + .name = "musb-jz4740", + .id = -1, + .dev = { + .dma_mask = &jz4740_udc_device.dev.coherent_dma_mask, + .coherent_dma_mask = DMA_BIT_MASK(32), + }, + .num_resources = ARRAY_SIZE(jz4740_udc_resources), + .resource = jz4740_udc_resources, +}; + </programlisting> + <para> + The jz4740_udc_xceiv_device platform device structure (line 2) + describes the UDC transceiver with a name and id number. + </para> + <para> + At the time of this writing, note that + "usb_phy_gen_xceiv" is the specific name to be used for + all transceivers that are either built-in with reference USB IP or + autonomous and doesn't require any PHY programming. You will need + to set CONFIG_NOP_USB_XCEIV=y in the kernel configuration to make + use of the corresponding transceiver driver. The id field could be + set to -1 (equivalent to PLATFORM_DEVID_NONE), -2 (equivalent to + PLATFORM_DEVID_AUTO) or start with 0 for the first device of this + kind if we want a specific id number. + </para> + <para> + The jz4740_udc_resources resource structure (line 7) defines the + UDC registers base addresses. + </para> + <para> + The first array (line 9 to 11) defines the UDC registers base + memory addresses: start points to the first register memory + address, end points to the last register memory address and the + flags member defines the type of resource we are dealing with. So + IORESOURCE_MEM is used to define the registers memory addresses. + The second array (line 14 to 17) defines the UDC IRQ registers + addresses. Since there is only one IRQ register available for the + JZ4740 UDC, start and end point at the same address. The + IORESOURCE_IRQ flag tells that we are dealing with IRQ resources, + and the name "mc" is in fact hard-coded in the MUSB core + in order for the controller driver to retrieve this IRQ resource + by querying it by its name. + </para> + <para> + Finally, the jz4740_udc_device platform device structure (line 21) + describes the UDC itself. + </para> + <para> + The "musb-jz4740" name (line 22) defines the MUSB + driver that is used for this device; remember this is in fact + the name that we used in the jz4740_driver platform driver + structure in <link linkend="linux-musb-basics">Chapter + 2</link>. The id field (line 23) is set to -1 (equivalent to + PLATFORM_DEVID_NONE) since we do not need an id for the device: + the MUSB controller driver was already set to allocate an + automatic id in <link linkend="linux-musb-basics">Chapter + 2</link>. In the dev field we care for DMA related information + here. The dma_mask field (line 25) defines the width of the DMA + mask that is going to be used, and coherent_dma_mask (line 26) + has the same purpose but for the alloc_coherent DMA mappings: in + both cases we are using a 32 bits mask. Then the resource field + (line 29) is simply a pointer to the resource structure defined + before, while the num_resources field (line 28) keeps track of + the number of arrays defined in the resource structure (in this + case there were two resource arrays defined before). + </para> + <para> + With this quick overview of the UDC platform data at the arch/ + level now done, let's get back to the MUSB glue layer specific + platform data in drivers/usb/musb/jz4740.c: + </para> + <programlisting linenumbering="numbered"> +static struct musb_hdrc_config jz4740_musb_config = { + /* Silicon does not implement USB OTG. */ + .multipoint = 0, + /* Max EPs scanned, driver will decide which EP can be used. */ + .num_eps = 4, + /* RAMbits needed to configure EPs from table */ + .ram_bits = 9, + .fifo_cfg = jz4740_musb_fifo_cfg, + .fifo_cfg_size = ARRAY_SIZE(jz4740_musb_fifo_cfg), +}; + +static struct musb_hdrc_platform_data jz4740_musb_platform_data = { + .mode = MUSB_PERIPHERAL, + .config = &jz4740_musb_config, +}; + </programlisting> + <para> + First the glue layer configures some aspects of the controller + driver operation related to the controller hardware specifics. + This is done through the jz4740_musb_config musb_hdrc_config + structure. + </para> + <para> + Defining the OTG capability of the controller hardware, the + multipoint member (line 3) is set to 0 (equivalent to false) + since the JZ4740 UDC is not OTG compatible. Then num_eps (line + 5) defines the number of USB endpoints of the controller + hardware, including endpoint 0: here we have 3 endpoints + + endpoint 0. Next is ram_bits (line 7) which is the width of the + RAM address bus for the MUSB controller hardware. This + information is needed when the controller driver cannot + automatically configure endpoints by reading the relevant + controller hardware registers. This issue will be discussed when + we get to device quirks in <link linkend="device-quirks">Chapter + 5</link>. Last two fields (line 8 and 9) are also about device + quirks: fifo_cfg points to the USB endpoints configuration table + and fifo_cfg_size keeps track of the size of the number of + entries in that configuration table. More on that later in <link + linkend="device-quirks">Chapter 5</link>. + </para> + <para> + Then this configuration is embedded inside + jz4740_musb_platform_data musb_hdrc_platform_data structure (line + 11): config is a pointer to the configuration structure itself, + and mode tells the controller driver if the controller hardware + may be used as MUSB_HOST only, MUSB_PERIPHERAL only or MUSB_OTG + which is a dual mode. + </para> + <para> + Remember that jz4740_musb_platform_data is then used to convey + platform data information as we have seen in the probe function + in <link linkend="linux-musb-basics">Chapter 2</link> + </para> + </chapter> + + <chapter id="device-quirks"> + <title>Device Quirks</title> + <para> + Completing the platform data specific to your device, you may also + need to write some code in the glue layer to work around some + device specific limitations. These quirks may be due to some + hardware bugs, or simply be the result of an incomplete + implementation of the USB On-the-Go specification. + </para> + <para> + The JZ4740 UDC exhibits such quirks, some of which we will discuss + here for the sake of insight even though these might not be found + in the controller hardware you are working on. + </para> + <para> + Let's get back to the init function first: + </para> + <programlisting linenumbering="numbered"> +static int jz4740_musb_init(struct musb *musb) +{ + musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2); + if (!musb->xceiv) { + pr_err("HS UDC: no transceiver configured\n"); + return -ENODEV; + } + + /* Silicon does not implement ConfigData register. + * Set dyn_fifo to avoid reading EP config from hardware. + */ + musb->dyn_fifo = true; + + musb->isr = jz4740_musb_interrupt; + + return 0; +} + </programlisting> + <para> + Instruction on line 12 helps the MUSB controller driver to work + around the fact that the controller hardware is missing registers + that are used for USB endpoints configuration. + </para> + <para> + Without these registers, the controller driver is unable to read + the endpoints configuration from the hardware, so we use line 12 + instruction to bypass reading the configuration from silicon, and + rely on a hard-coded table that describes the endpoints + configuration instead: + </para> + <programlisting linenumbering="numbered"> +static struct musb_fifo_cfg jz4740_musb_fifo_cfg[] = { +{ .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, }, +{ .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, }, +{ .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 64, }, +}; + </programlisting> + <para> + Looking at the configuration table above, we see that each + endpoints is described by three fields: hw_ep_num is the endpoint + number, style is its direction (either FIFO_TX for the controller + driver to send packets in the controller hardware, or FIFO_RX to + receive packets from hardware), and maxpacket defines the maximum + size of each data packet that can be transmitted over that + endpoint. Reading from the table, the controller driver knows that + endpoint 1 can be used to send and receive USB data packets of 512 + bytes at once (this is in fact a bulk in/out endpoint), and + endpoint 2 can be used to send data packets of 64 bytes at once + (this is in fact an interrupt endpoint). + </para> + <para> + Note that there is no information about endpoint 0 here: that one + is implemented by default in every silicon design, with a + predefined configuration according to the USB specification. For + more examples of endpoint configuration tables, see musb_core.c. + </para> + <para> + Let's now get back to the interrupt handler function: + </para> + <programlisting linenumbering="numbered"> +static irqreturn_t jz4740_musb_interrupt(int irq, void *__hci) +{ + unsigned long flags; + irqreturn_t retval = IRQ_NONE; + struct musb *musb = __hci; + + spin_lock_irqsave(&musb->lock, flags); + + musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB); + musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX); + musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX); + + /* + * The controller is gadget only, the state of the host mode IRQ bits is + * undefined. Mask them to make sure that the musb driver core will + * never see them set + */ + musb->int_usb &= MUSB_INTR_SUSPEND | MUSB_INTR_RESUME | + MUSB_INTR_RESET | MUSB_INTR_SOF; + + if (musb->int_usb || musb->int_tx || musb->int_rx) + retval = musb_interrupt(musb); + + spin_unlock_irqrestore(&musb->lock, flags); + + return retval; +} + </programlisting> + <para> + Instruction on line 18 above is a way for the controller driver to + work around the fact that some interrupt bits used for USB host + mode operation are missing in the MUSB_INTRUSB register, thus left + in an undefined hardware state, since this MUSB controller + hardware is used in peripheral mode only. As a consequence, the + glue layer masks these missing bits out to avoid parasite + interrupts by doing a logical AND operation between the value read + from MUSB_INTRUSB and the bits that are actually implemented in + the register. + </para> + <para> + These are only a couple of the quirks found in the JZ4740 USB + device controller. Some others were directly addressed in the MUSB + core since the fixes were generic enough to provide a better + handling of the issues for others controller hardware eventually. + </para> + </chapter> + + <chapter id="conclusion"> + <title>Conclusion</title> + <para> + Writing a Linux MUSB glue layer should be a more accessible task, + as this documentation tries to show the ins and outs of this + exercise. + </para> + <para> + The JZ4740 USB device controller being fairly simple, I hope its + glue layer serves as a good example for the curious mind. Used + with the current MUSB glue layers, this documentation should + provide enough guidance to get started; should anything gets out + of hand, the linux-usb mailing list archive is another helpful + resource to browse through. + </para> + </chapter> + + <chapter id="acknowledgements"> + <title>Acknowledgements</title> + <para> + Many thanks to Lars-Peter Clausen and Maarten ter Huurne for + answering my questions while I was writing the JZ4740 glue layer + and for helping me out getting the code in good shape. + </para> + <para> + I would also like to thank the Qi-Hardware community at large for + its cheerful guidance and support. + </para> + </chapter> + + <chapter id="resources"> + <title>Resources</title> + <para> + USB Home Page: + <ulink url="http://www.usb.org">http://www.usb.org</ulink> + </para> + <para> + linux-usb Mailing List Archives: + <ulink url="http://marc.info/?l=linux-usb">http://marc.info/?l=linux-usb</ulink> + </para> + <para> + USB On-the-Go Basics: + <ulink url="http://www.maximintegrated.com/app-notes/index.mvp/id/1822">http://www.maximintegrated.com/app-notes/index.mvp/id/1822</ulink> + </para> + <para> + Writing USB Device Drivers: + <ulink url="https://www.kernel.org/doc/htmldocs/writing_usb_driver/index.html">https://www.kernel.org/doc/htmldocs/writing_usb_driver/index.html</ulink> + </para> + <para> + Texas Instruments USB Configuration Wiki Page: + <ulink url="http://processors.wiki.ti.com/index.php/Usbgeneralpage">http://processors.wiki.ti.com/index.php/Usbgeneralpage</ulink> + </para> + <para> + Analog Devices Blackfin MUSB Configuration: + <ulink url="http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:musb">http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:musb</ulink> + </para> + </chapter> + +</book> diff --git a/Documentation/EDID/1024x768.S b/Documentation/EDID/1024x768.S index 4b486fe..6f3e4b7 100644 --- a/Documentation/EDID/1024x768.S +++ b/Documentation/EDID/1024x768.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux XGA" -#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */ +#define ESTABLISHED_TIMING2_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */ #define HSYNC_POL 0 #define VSYNC_POL 0 #define CRC 0x55 diff --git a/Documentation/EDID/1280x1024.S b/Documentation/EDID/1280x1024.S index a2799fe..bd9bef2a 100644 --- a/Documentation/EDID/1280x1024.S +++ b/Documentation/EDID/1280x1024.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux SXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0xa0 diff --git a/Documentation/EDID/1600x1200.S b/Documentation/EDID/1600x1200.S index 0ded64c..a45101c 100644 --- a/Documentation/EDID/1600x1200.S +++ b/Documentation/EDID/1600x1200.S @@ -36,7 +36,7 @@ #define DPI 72 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux UXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x9d diff --git a/Documentation/EDID/1680x1050.S b/Documentation/EDID/1680x1050.S index 96f67ca..b0d7c69 100644 --- a/Documentation/EDID/1680x1050.S +++ b/Documentation/EDID/1680x1050.S @@ -36,7 +36,7 @@ #define DPI 96 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux WSXGA" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x26 diff --git a/Documentation/EDID/1920x1080.S b/Documentation/EDID/1920x1080.S index 36ed5d5..3084355e 100644 --- a/Documentation/EDID/1920x1080.S +++ b/Documentation/EDID/1920x1080.S @@ -36,7 +36,7 @@ #define DPI 96 #define VFREQ 60 /* Hz */ #define TIMING_NAME "Linux FHD" -#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +/* No ESTABLISHED_TIMINGx_BITS */ #define HSYNC_POL 1 #define VSYNC_POL 1 #define CRC 0x05 diff --git a/Documentation/EDID/800x600.S b/Documentation/EDID/800x600.S new file mode 100644 index 0000000..6644e26 --- /dev/null +++ b/Documentation/EDID/800x600.S @@ -0,0 +1,41 @@ +/* + 800x600.S: EDID data set for standard 800x600 60 Hz monitor + + Copyright (C) 2011 Carsten Emde <C.Emde@osadl.org> + Copyright (C) 2014 Linaro Limited + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version 2 + of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. +*/ + +/* EDID */ +#define VERSION 1 +#define REVISION 3 + +/* Display */ +#define CLOCK 40000 /* kHz */ +#define XPIX 800 +#define YPIX 600 +#define XY_RATIO XY_RATIO_4_3 +#define XBLANK 256 +#define YBLANK 28 +#define XOFFSET 40 +#define XPULSE 128 +#define YOFFSET (63+1) +#define YPULSE (63+4) +#define DPI 72 +#define VFREQ 60 /* Hz */ +#define TIMING_NAME "Linux SVGA" +#define ESTABLISHED_TIMING1_BITS 0x01 /* Bit 0: 800x600 @ 60Hz */ +#define HSYNC_POL 1 +#define VSYNC_POL 1 +#define CRC 0xc2 + +#include "edid.S" diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt index 7146db1..835db33 100644 --- a/Documentation/EDID/HOWTO.txt +++ b/Documentation/EDID/HOWTO.txt @@ -18,7 +18,7 @@ CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an individually prepared or corrected EDID data set in the /lib/firmware directory from where it is loaded via the firmware interface. The code (see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for -commonly used screen resolutions (1024x768, 1280x1024, 1600x1200, +commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200, 1680x1050, 1920x1080) as binary blobs, but the kernel source tree does not contain code to create these data. In order to elucidate the origin of the built-in binary EDID blobs and to facilitate the creation of diff --git a/Documentation/EDID/edid.S b/Documentation/EDID/edid.S index ea97ae2..7ac0327 100644 --- a/Documentation/EDID/edid.S +++ b/Documentation/EDID/edid.S @@ -33,6 +33,17 @@ #define XY_RATIO_5_4 0b10 #define XY_RATIO_16_9 0b11 +/* Provide defaults for the timing bits */ +#ifndef ESTABLISHED_TIMING1_BITS +#define ESTABLISHED_TIMING1_BITS 0x00 +#endif +#ifndef ESTABLISHED_TIMING2_BITS +#define ESTABLISHED_TIMING2_BITS 0x00 +#endif +#ifndef ESTABLISHED_TIMING3_BITS +#define ESTABLISHED_TIMING3_BITS 0x00 +#endif + #define mfgname2id(v1,v2,v3) \ ((((v1-'@')&0x1f)<<10)+(((v2-'@')&0x1f)<<5)+((v3-'@')&0x1f)) #define swap16(v1) ((v1>>8)+((v1&0xff)<<8)) @@ -139,7 +150,7 @@ white_x_y_msb: .byte 0x50,0x54 Bit 2 640x480 @ 75 Hz Bit 1 800x600 @ 56 Hz Bit 0 800x600 @ 60 Hz */ -estbl_timing1: .byte 0x00 +estbl_timing1: .byte ESTABLISHED_TIMING1_BITS /* Bit 7 800x600 @ 72 Hz Bit 6 800x600 @ 75 Hz @@ -149,11 +160,11 @@ estbl_timing1: .byte 0x00 Bit 2 1024x768 @ 72 Hz Bit 1 1024x768 @ 75 Hz Bit 0 1280x1024 @ 75 Hz */ -estbl_timing2: .byte ESTABLISHED_TIMINGS_BITS +estbl_timing2: .byte ESTABLISHED_TIMING2_BITS /* Bit 7 1152x870 @ 75 Hz (Apple Macintosh II) Bits 6-0 Other manufacturer-specific display mod */ -estbl_timing3: .byte 0x00 +estbl_timing3: .byte ESTABLISHED_TIMING3_BITS /* Standard timing */ /* X resolution, less 31, divided by 8 (256-2288 pixels) */ diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt index 03df71a..8a8b82c 100644 --- a/Documentation/IRQ-domain.txt +++ b/Documentation/IRQ-domain.txt @@ -41,8 +41,7 @@ An interrupt controller driver creates and registers an irq_domain by calling one of the irq_domain_add_*() functions (each mapping method has a different allocator function, more on that later). The function will return a pointer to the irq_domain on success. The caller must -provide the allocator function with an irq_domain_ops structure with -the .map callback populated as a minimum. +provide the allocator function with an irq_domain_ops structure. In most cases, the irq_domain will begin empty without any mappings between hwirq and IRQ numbers. Mappings are added to the irq_domain diff --git a/Documentation/RCU/00-INDEX b/Documentation/RCU/00-INDEX index fa57139..f773a26 100644 --- a/Documentation/RCU/00-INDEX +++ b/Documentation/RCU/00-INDEX @@ -12,6 +12,8 @@ lockdep-splat.txt - RCU Lockdep splats explained. NMI-RCU.txt - Using RCU to Protect Dynamic NMI Handlers +rcu_dereference.txt + - Proper care and feeding of return values from rcu_dereference() rcubarrier.txt - RCU and Unloadable Modules rculist_nulls.txt diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 9d10d1d..8779471 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -114,12 +114,16 @@ over a rather long period of time, but improvements are always welcome! http://www.openvms.compaq.com/wizard/wiz_2637.html The rcu_dereference() primitive is also an excellent - documentation aid, letting the person reading the code - know exactly which pointers are protected by RCU. + documentation aid, letting the person reading the + code know exactly which pointers are protected by RCU. Please note that compilers can also reorder code, and they are becoming increasingly aggressive about doing - just that. The rcu_dereference() primitive therefore - also prevents destructive compiler optimizations. + just that. The rcu_dereference() primitive therefore also + prevents destructive compiler optimizations. However, + with a bit of devious creativity, it is possible to + mishandle the return value from rcu_dereference(). + Please see rcu_dereference.txt in this directory for + more information. The rcu_dereference() primitive is used by the various "_rcu()" list-traversal primitives, such diff --git a/Documentation/RCU/rcu_dereference.txt b/Documentation/RCU/rcu_dereference.txt new file mode 100644 index 0000000..ceb05da --- /dev/null +++ b/Documentation/RCU/rcu_dereference.txt @@ -0,0 +1,371 @@ +PROPER CARE AND FEEDING OF RETURN VALUES FROM rcu_dereference() + +Most of the time, you can use values from rcu_dereference() or one of +the similar primitives without worries. Dereferencing (prefix "*"), +field selection ("->"), assignment ("="), address-of ("&"), addition and +subtraction of constants, and casts all work quite naturally and safely. + +It is nevertheless possible to get into trouble with other operations. +Follow these rules to keep your RCU code working properly: + +o You must use one of the rcu_dereference() family of primitives + to load an RCU-protected pointer, otherwise CONFIG_PROVE_RCU + will complain. Worse yet, your code can see random memory-corruption + bugs due to games that compilers and DEC Alpha can play. + Without one of the rcu_dereference() primitives, compilers + can reload the value, and won't your code have fun with two + different values for a single pointer! Without rcu_dereference(), + DEC Alpha can load a pointer, dereference that pointer, and + return data preceding initialization that preceded the store of + the pointer. + + In addition, the volatile cast in rcu_dereference() prevents the + compiler from deducing the resulting pointer value. Please see + the section entitled "EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH" + for an example where the compiler can in fact deduce the exact + value of the pointer, and thus cause misordering. + +o Do not use single-element RCU-protected arrays. The compiler + is within its right to assume that the value of an index into + such an array must necessarily evaluate to zero. The compiler + could then substitute the constant zero for the computation, so + that the array index no longer depended on the value returned + by rcu_dereference(). If the array index no longer depends + on rcu_dereference(), then both the compiler and the CPU + are within their rights to order the array access before the + rcu_dereference(), which can cause the array access to return + garbage. + +o Avoid cancellation when using the "+" and "-" infix arithmetic + operators. For example, for a given variable "x", avoid + "(x-x)". There are similar arithmetic pitfalls from other + arithmetic operatiors, such as "(x*0)", "(x/(x+1))" or "(x%1)". + The compiler is within its rights to substitute zero for all of + these expressions, so that subsequent accesses no longer depend + on the rcu_dereference(), again possibly resulting in bugs due + to misordering. + + Of course, if "p" is a pointer from rcu_dereference(), and "a" + and "b" are integers that happen to be equal, the expression + "p+a-b" is safe because its value still necessarily depends on + the rcu_dereference(), thus maintaining proper ordering. + +o Avoid all-zero operands to the bitwise "&" operator, and + similarly avoid all-ones operands to the bitwise "|" operator. + If the compiler is able to deduce the value of such operands, + it is within its rights to substitute the corresponding constant + for the bitwise operation. Once again, this causes subsequent + accesses to no longer depend on the rcu_dereference(), causing + bugs due to misordering. + + Please note that single-bit operands to bitwise "&" can also + be dangerous. At this point, the compiler knows that the + resulting value can only take on one of two possible values. + Therefore, a very small amount of additional information will + allow the compiler to deduce the exact value, which again can + result in misordering. + +o If you are using RCU to protect JITed functions, so that the + "()" function-invocation operator is applied to a value obtained + (directly or indirectly) from rcu_dereference(), you may need to + interact directly with the hardware to flush instruction caches. + This issue arises on some systems when a newly JITed function is + using the same memory that was used by an earlier JITed function. + +o Do not use the results from the boolean "&&" and "||" when + dereferencing. For example, the following (rather improbable) + code is buggy: + + int a[2]; + int index; + int force_zero_index = 1; + + ... + + r1 = rcu_dereference(i1) + r2 = a[r1 && force_zero_index]; /* BUGGY!!! */ + + The reason this is buggy is that "&&" and "||" are often compiled + using branches. While weak-memory machines such as ARM or PowerPC + do order stores after such branches, they can speculate loads, + which can result in misordering bugs. + +o Do not use the results from relational operators ("==", "!=", + ">", ">=", "<", or "<=") when dereferencing. For example, + the following (quite strange) code is buggy: + + int a[2]; + int index; + int flip_index = 0; + + ... + + r1 = rcu_dereference(i1) + r2 = a[r1 != flip_index]; /* BUGGY!!! */ + + As before, the reason this is buggy is that relational operators + are often compiled using branches. And as before, although + weak-memory machines such as ARM or PowerPC do order stores + after such branches, but can speculate loads, which can again + result in misordering bugs. + +o Be very careful about comparing pointers obtained from + rcu_dereference() against non-NULL values. As Linus Torvalds + explained, if the two pointers are equal, the compiler could + substitute the pointer you are comparing against for the pointer + obtained from rcu_dereference(). For example: + + p = rcu_dereference(gp); + if (p == &default_struct) + do_default(p->a); + + Because the compiler now knows that the value of "p" is exactly + the address of the variable "default_struct", it is free to + transform this code into the following: + + p = rcu_dereference(gp); + if (p == &default_struct) + do_default(default_struct.a); + + On ARM and Power hardware, the load from "default_struct.a" + can now be speculated, such that it might happen before the + rcu_dereference(). This could result in bugs due to misordering. + + However, comparisons are OK in the following cases: + + o The comparison was against the NULL pointer. If the + compiler knows that the pointer is NULL, you had better + not be dereferencing it anyway. If the comparison is + non-equal, the compiler is none the wiser. Therefore, + it is safe to compare pointers from rcu_dereference() + against NULL pointers. + + o The pointer is never dereferenced after being compared. + Since there are no subsequent dereferences, the compiler + cannot use anything it learned from the comparison + to reorder the non-existent subsequent dereferences. + This sort of comparison occurs frequently when scanning + RCU-protected circular linked lists. + + o The comparison is against a pointer that references memory + that was initialized "a long time ago." The reason + this is safe is that even if misordering occurs, the + misordering will not affect the accesses that follow + the comparison. So exactly how long ago is "a long + time ago"? Here are some possibilities: + + o Compile time. + + o Boot time. + + o Module-init time for module code. + + o Prior to kthread creation for kthread code. + + o During some prior acquisition of the lock that + we now hold. + + o Before mod_timer() time for a timer handler. + + There are many other possibilities involving the Linux + kernel's wide array of primitives that cause code to + be invoked at a later time. + + o The pointer being compared against also came from + rcu_dereference(). In this case, both pointers depend + on one rcu_dereference() or another, so you get proper + ordering either way. + + That said, this situation can make certain RCU usage + bugs more likely to happen. Which can be a good thing, + at least if they happen during testing. An example + of such an RCU usage bug is shown in the section titled + "EXAMPLE OF AMPLIFIED RCU-USAGE BUG". + + o All of the accesses following the comparison are stores, + so that a control dependency preserves the needed ordering. + That said, it is easy to get control dependencies wrong. + Please see the "CONTROL DEPENDENCIES" section of + Documentation/memory-barriers.txt for more details. + + o The pointers are not equal -and- the compiler does + not have enough information to deduce the value of the + pointer. Note that the volatile cast in rcu_dereference() + will normally prevent the compiler from knowing too much. + +o Disable any value-speculation optimizations that your compiler + might provide, especially if you are making use of feedback-based + optimizations that take data collected from prior runs. Such + value-speculation optimizations reorder operations by design. + + There is one exception to this rule: Value-speculation + optimizations that leverage the branch-prediction hardware are + safe on strongly ordered systems (such as x86), but not on weakly + ordered systems (such as ARM or Power). Choose your compiler + command-line options wisely! + + +EXAMPLE OF AMPLIFIED RCU-USAGE BUG + +Because updaters can run concurrently with RCU readers, RCU readers can +see stale and/or inconsistent values. If RCU readers need fresh or +consistent values, which they sometimes do, they need to take proper +precautions. To see this, consider the following code fragment: + + struct foo { + int a; + int b; + int c; + }; + struct foo *gp1; + struct foo *gp2; + + void updater(void) + { + struct foo *p; + + p = kmalloc(...); + if (p == NULL) + deal_with_it(); + p->a = 42; /* Each field in its own cache line. */ + p->b = 43; + p->c = 44; + rcu_assign_pointer(gp1, p); + p->b = 143; + p->c = 144; + rcu_assign_pointer(gp2, p); + } + + void reader(void) + { + struct foo *p; + struct foo *q; + int r1, r2; + + p = rcu_dereference(gp2); + if (p == NULL) + return; + r1 = p->b; /* Guaranteed to get 143. */ + q = rcu_dereference(gp1); /* Guaranteed non-NULL. */ + if (p == q) { + /* The compiler decides that q->c is same as p->c. */ + r2 = p->c; /* Could get 44 on weakly order system. */ + } + do_something_with(r1, r2); + } + +You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible, +but you should not be. After all, the updater might have been invoked +a second time between the time reader() loaded into "r1" and the time +that it loaded into "r2". The fact that this same result can occur due +to some reordering from the compiler and CPUs is beside the point. + +But suppose that the reader needs a consistent view? + +Then one approach is to use locking, for example, as follows: + + struct foo { + int a; + int b; + int c; + spinlock_t lock; + }; + struct foo *gp1; + struct foo *gp2; + + void updater(void) + { + struct foo *p; + + p = kmalloc(...); + if (p == NULL) + deal_with_it(); + spin_lock(&p->lock); + p->a = 42; /* Each field in its own cache line. */ + p->b = 43; + p->c = 44; + spin_unlock(&p->lock); + rcu_assign_pointer(gp1, p); + spin_lock(&p->lock); + p->b = 143; + p->c = 144; + spin_unlock(&p->lock); + rcu_assign_pointer(gp2, p); + } + + void reader(void) + { + struct foo *p; + struct foo *q; + int r1, r2; + + p = rcu_dereference(gp2); + if (p == NULL) + return; + spin_lock(&p->lock); + r1 = p->b; /* Guaranteed to get 143. */ + q = rcu_dereference(gp1); /* Guaranteed non-NULL. */ + if (p == q) { + /* The compiler decides that q->c is same as p->c. */ + r2 = p->c; /* Locking guarantees r2 == 144. */ + } + spin_unlock(&p->lock); + do_something_with(r1, r2); + } + +As always, use the right tool for the job! + + +EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH + +If a pointer obtained from rcu_dereference() compares not-equal to some +other pointer, the compiler normally has no clue what the value of the +first pointer might be. This lack of knowledge prevents the compiler +from carrying out optimizations that otherwise might destroy the ordering +guarantees that RCU depends on. And the volatile cast in rcu_dereference() +should prevent the compiler from guessing the value. + +But without rcu_dereference(), the compiler knows more than you might +expect. Consider the following code fragment: + + struct foo { + int a; + int b; + }; + static struct foo variable1; + static struct foo variable2; + static struct foo *gp = &variable1; + + void updater(void) + { + initialize_foo(&variable2); + rcu_assign_pointer(gp, &variable2); + /* + * The above is the only store to gp in this translation unit, + * and the address of gp is not exported in any way. + */ + } + + int reader(void) + { + struct foo *p; + + p = gp; + barrier(); + if (p == &variable1) + return p->a; /* Must be variable1.a. */ + else + return p->b; /* Must be variable2.b. */ + } + +Because the compiler can see all stores to "gp", it knows that the only +possible values of "gp" are "variable1" on the one hand and "variable2" +on the other. The comparison in reader() therefore tells the compiler +the exact value of "p" even in the not-equals case. This allows the +compiler to make the return values independent of the load from "gp", +in turn destroying the ordering between this load and the loads of the +return values. This can result in "p->b" returning pre-initialization +garbage values. + +In short, rcu_dereference() is -not- optional when you are going to +dereference the resulting pointer. diff --git a/Documentation/RCU/rcuref.txt b/Documentation/RCU/rcuref.txt index 141d531..613033f 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/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt index 6f3a005..68fe3ad 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.txt @@ -24,7 +24,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT timing of the next warning for the current stall. Stall-warning messages may be enabled and disabled completely via - /sys/module/rcutree/parameters/rcu_cpu_stall_suppress. + /sys/module/rcupdate/parameters/rcu_cpu_stall_suppress. CONFIG_RCU_CPU_STALL_VERBOSE diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 0f0fb7c..49b8551 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -326,11 +326,11 @@ used as follows: a. synchronize_rcu() rcu_read_lock() / rcu_read_unlock() call_rcu() rcu_dereference() -b. call_rcu_bh() rcu_read_lock_bh() / rcu_read_unlock_bh() - rcu_dereference_bh() +b. synchronize_rcu_bh() rcu_read_lock_bh() / rcu_read_unlock_bh() + call_rcu_bh() rcu_dereference_bh() c. synchronize_sched() rcu_read_lock_sched() / rcu_read_unlock_sched() - preempt_disable() / preempt_enable() + call_rcu_sched() preempt_disable() / preempt_enable() local_irq_save() / local_irq_restore() hardirq enter / hardirq exit NMI enter / NMI exit @@ -794,10 +794,22 @@ in docbook. Here is the list, by category. RCU list traversal: + list_entry_rcu + list_first_entry_rcu + list_next_rcu list_for_each_entry_rcu + list_for_each_entry_continue_rcu + hlist_first_rcu + hlist_next_rcu + hlist_pprev_rcu hlist_for_each_entry_rcu + hlist_for_each_entry_rcu_bh + hlist_for_each_entry_continue_rcu + hlist_for_each_entry_continue_rcu_bh + hlist_nulls_first_rcu hlist_nulls_for_each_entry_rcu - list_for_each_entry_continue_rcu + hlist_bl_first_rcu + hlist_bl_for_each_entry_rcu RCU pointer/list update: @@ -806,28 +818,38 @@ RCU pointer/list update: list_add_tail_rcu list_del_rcu list_replace_rcu - hlist_del_rcu hlist_add_after_rcu hlist_add_before_rcu hlist_add_head_rcu + hlist_del_rcu + hlist_del_init_rcu hlist_replace_rcu list_splice_init_rcu() + hlist_nulls_del_init_rcu + hlist_nulls_del_rcu + hlist_nulls_add_head_rcu + hlist_bl_add_head_rcu + hlist_bl_del_init_rcu + hlist_bl_del_rcu + hlist_bl_set_first_rcu RCU: Critical sections Grace period Barrier rcu_read_lock synchronize_net rcu_barrier rcu_read_unlock synchronize_rcu rcu_dereference synchronize_rcu_expedited - call_rcu - kfree_rcu - + rcu_read_lock_held call_rcu + rcu_dereference_check kfree_rcu + rcu_dereference_protected bh: Critical sections Grace period Barrier rcu_read_lock_bh call_rcu_bh rcu_barrier_bh rcu_read_unlock_bh synchronize_rcu_bh rcu_dereference_bh synchronize_rcu_bh_expedited - + rcu_dereference_bh_check + rcu_dereference_bh_protected + rcu_read_lock_bh_held sched: Critical sections Grace period Barrier @@ -835,7 +857,12 @@ sched: Critical sections Grace period Barrier rcu_read_unlock_sched call_rcu_sched [preempt_disable] synchronize_sched_expedited [and friends] + rcu_read_lock_sched_notrace + rcu_read_unlock_sched_notrace rcu_dereference_sched + rcu_dereference_sched_check + rcu_dereference_sched_protected + rcu_read_lock_sched_held SRCU: Critical sections Grace period Barrier @@ -843,6 +870,8 @@ SRCU: Critical sections Grace period Barrier srcu_read_lock synchronize_srcu srcu_barrier srcu_read_unlock call_srcu srcu_dereference synchronize_srcu_expedited + srcu_dereference_check + srcu_read_lock_held SRCU: Initialization/cleanup init_srcu_struct @@ -850,9 +879,13 @@ SRCU: Initialization/cleanup All: lockdep-checked RCU-protected pointer access - rcu_dereference_check - rcu_dereference_protected + rcu_access_index rcu_access_pointer + rcu_dereference_index_check + rcu_dereference_raw + rcu_lockdep_assert + rcu_sleep_check + RCU_NONIDLE See the comment headers in the source code (or the docbook generated from them) for more information. diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 04c1edd..dcadffc 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -14,7 +14,10 @@ Read Documentation/SubmitChecklist for a list of items to check before submitting code. If you are submitting a driver, also read Documentation/SubmittingDrivers. - +Many of these steps describe the default behavior of the git version +control system; if you use git to prepare your patches, you'll find much +of the mechanical work done for you, though you'll still need to prepare +and document a sensible set of patches. -------------------------------------------- SECTION 1 - CREATING AND SENDING YOUR CHANGE @@ -25,7 +28,9 @@ SECTION 1 - CREATING AND SENDING YOUR CHANGE 1) "diff -up" ------------ -Use "diff -up" or "diff -uprN" to create patches. +Use "diff -up" or "diff -uprN" to create patches. git generates patches +in this form by default; if you're using git, you can skip this section +entirely. All changes to the Linux kernel occur in the form of patches, as generated by diff(1). When creating your patch, make sure to create it @@ -66,19 +71,14 @@ Make sure your patch does not include any extra files which do not belong in a patch submission. Make sure to review your patch -after- generated it with diff(1), to ensure accuracy. -If your changes produce a lot of deltas, you may want to look into -splitting them into individual patches which modify things in -logical stages. This will facilitate easier reviewing by other -kernel developers, very important if you want your patch accepted. -There are a number of scripts which can aid in this: - -Quilt: -http://savannah.nongnu.org/projects/quilt +If your changes produce a lot of deltas, you need to split them into +individual patches which modify things in logical stages; see section +#3. This will facilitate easier reviewing by other kernel developers, +very important if you want your patch accepted. -Andrew Morton's patch scripts: -http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz -Instead of these scripts, quilt is the recommended patch management -tool (see above). +If you're using git, "git rebase -i" can help you with this process. If +you're not using git, quilt <http://savannah.nongnu.org/projects/quilt> +is another popular alternative. @@ -106,8 +106,21 @@ I.e., the patch (series) and its description should be self-contained. This benefits both the patch merger(s) and reviewers. Some reviewers probably didn't even receive earlier versions of the patch. +Describe your changes in imperative mood, e.g. "make xyzzy do frotz" +instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy +to do frotz", as if you are giving orders to the codebase to change +its behaviour. + If the patch fixes a logged bug entry, refer to that bug entry by -number and URL. +number and URL. If the patch follows from a mailing list discussion, +give a URL to the mailing list archive; use the https://lkml.kernel.org/ +redirector with a Message-Id, to ensure that the links cannot become +stale. + +However, try to make your explanation understandable without external +resources. In addition to giving a URL to a mailing list archive or +bug, summarize the relevant points of the discussion that led to the +patch as submitted. If you want to refer to a specific commit, don't just refer to the SHA-1 ID of the commit. Please also include the oneline summary of @@ -119,6 +132,20 @@ Example: platform_set_drvdata(), but left the variable "dev" unused, delete it. +If your patch fixes a bug in a specific commit, e.g. you found an issue using +git-bisect, please use the 'Fixes:' tag with the first 12 characters of the +SHA-1 ID, and the one line summary. +Example: + + Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()") + +The following git-config settings can be used to add a pretty format for +outputting the above style in the git log or git show commands + + [core] + abbrev = 12 + [pretty] + fixes = Fixes: %h (\"%s\") 3) Separate your changes. @@ -430,7 +457,7 @@ person it names. This tag documents that potentially interested parties have been included in the discussion -14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by: +14) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes: If this patch fixes a problem reported by somebody else, consider adding a Reported-by: tag to credit the reporter for their contribution. Please @@ -485,6 +512,12 @@ idea was not posted in a public forum. That said, if we diligently credit our idea reporters, they will, hopefully, be inspired to help us again in the future. +A Fixes: tag indicates that the patch fixes an issue in a previous commit. It +is used to make it easy to determine where a bug originated, which can help +review a bug fix. This tag also assists the stable kernel team in determining +which stable kernel versions should receive your fix. This is the preferred +method for indicating a bug fixed by the patch. See #2 above for more details. + 15) The canonical patch format @@ -594,7 +627,8 @@ patch. If you are going to include a diffstat after the "---" marker, please use diffstat options "-p 1 -w 70" so that filenames are listed from the top of the kernel source tree and don't use too much horizontal -space (easily fit in 80 columns, maybe with some indentation). +space (easily fit in 80 columns, maybe with some indentation). (git +generates appropriate diffstats by default.) See more details on the proper patch format in the following references. @@ -725,7 +759,7 @@ SECTION 3 - REFERENCES ---------------------- Andrew Morton, "The perfect patch" (tpp). - <http://userweb.kernel.org/~akpm/stuff/tpp.txt> + <http://www.ozlabs.org/~akpm/stuff/tpp.txt> Jeff Garzik, "Linux kernel patch submission format". <http://linux.yyz.us/patch-format.html> @@ -738,7 +772,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". <http://www.kroah.com/log/linux/maintainer-05.html> NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! - <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> + <https://lkml.org/lkml/2005/7/11/336> Kernel Documentation/CodingStyle: <http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle> diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index c6a06b7..f405780 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -314,6 +314,7 @@ int main(int argc, char *argv[]) break; case 'm': strncpy(cpumask, optarg, sizeof(cpumask)); + cpumask[sizeof(cpumask) - 1] = '\0'; maskset = 1; printf("cpumask %s maskset %d\n", cpumask, maskset); break; diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index 2a1519b..e182be5 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 @@ -296,7 +290,7 @@ specifies the path to the controller. In order to use these GPIOs in Linux we need to translate them to the corresponding Linux GPIO descriptors. There is a standard GPIO API for that and is documented in -Documentation/gpio.txt. +Documentation/gpio/. In the above example we can get the corresponding two GPIO descriptors with a code like this: diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX index a94090c..3b08bc2 100644 --- a/Documentation/arm/00-INDEX +++ b/Documentation/arm/00-INDEX @@ -46,5 +46,7 @@ swp_emulation - SWP/SWPB emulation handler/logging description tcm.txt - ARM Tightly Coupled Memory +uefi.txt + - [U]EFI configuration and runtime services documentation vlocks.txt - Voting locks, low-level mechanism relying on memory system atomic writes. diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README index 5a930c1..2cce540 100644 --- a/Documentation/arm/Marvell/README +++ b/Documentation/arm/Marvell/README @@ -83,14 +83,24 @@ EBU Armada family 88F6710 88F6707 88F6W11 + Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf + + Armada 375 Flavors: + 88F6720 + Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf + + Armada 380/385 Flavors: + 88F6810 + 88F6820 + 88F6828 Armada XP Flavors: MV78230 MV78260 MV78460 NOTE: not to be confused with the non-SMP 78xx0 SoCs + Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf - Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf No public datasheet available. Core: Sheeva ARMv7 compatible @@ -224,6 +234,11 @@ Berlin family (Digital Entertainment) Core: Marvell PJ4B (ARMv7), Tauros3 L2CC Homepage: http://www.marvell.com/digital-entertainment/armada-1500/ Product Brief: http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf + 88DE3114, Armada 1500 Pro + Design name: BG2-Q + Core: Quad Core ARM Cortex-A9, PL310 L2CC + Homepage: http://www.marvell.com/digital-entertainment/armada-1500-pro/ + Product Brief: http://www.marvell.com/digital-entertainment/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf 88DE???? Design name: BG3 Core: ARM Cortex-A15, CA15 integrated L2CC diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt index 4bfb9ff..38dc06d 100644 --- a/Documentation/arm/memory.txt +++ b/Documentation/arm/memory.txt @@ -41,16 +41,9 @@ fffe8000 fffeffff DTCM mapping area for platforms with fffe0000 fffe7fff ITCM mapping area for platforms with ITCM mounted inside the CPU. -fff00000 fffdffff Fixmap mapping region. Addresses provided +ffc00000 ffdfffff Fixmap mapping region. Addresses provided by fix_to_virt() will be located here. -ffc00000 ffefffff DMA memory mapping region. Memory returned - by the dma_alloc_xxx functions will be - dynamically mapped here. - -ff000000 ffbfffff Reserved for future expansion of DMA - mapping region. - fee00000 feffffff Mapping of PCI I/O space. This is a static mapping within the vmalloc space. diff --git a/Documentation/arm/sti/stih407-overview.txt b/Documentation/arm/sti/stih407-overview.txt new file mode 100644 index 0000000..3343f32 --- /dev/null +++ b/Documentation/arm/sti/stih407-overview.txt @@ -0,0 +1,18 @@ + STiH407 Overview + ================ + +Introduction +------------ + + The STiH407 is the new generation of SoC for Multi-HD, AVC set-top boxes + and server/connected client application for satellite, cable, terrestrial + and IP-STB markets. + + Features + - ARM Cortex-A9 1.5 GHz dual core CPU (28nm) + - SATA2, USB 3.0, PCIe, Gbit Ethernet + + Document Author + --------------- + + Maxime Coquelin <maxime.coquelin@st.com>, (c) 2014 ST Microelectronics diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt new file mode 100644 index 0000000..d60030a --- /dev/null +++ b/Documentation/arm/uefi.txt @@ -0,0 +1,64 @@ +UEFI, the Unified Extensible Firmware Interface, is a specification +governing the behaviours of compatible firmware interfaces. It is +maintained by the UEFI Forum - http://www.uefi.org/. + +UEFI is an evolution of its predecessor 'EFI', so the terms EFI and +UEFI are used somewhat interchangeably in this document and associated +source code. As a rule, anything new uses 'UEFI', whereas 'EFI' refers +to legacy code or specifications. + +UEFI support in Linux +===================== +Booting on a platform with firmware compliant with the UEFI specification +makes it possible for the kernel to support additional features: +- UEFI Runtime Services +- Retrieving various configuration information through the standardised + interface of UEFI configuration tables. (ACPI, SMBIOS, ...) + +For actually enabling [U]EFI support, enable: +- CONFIG_EFI=y +- CONFIG_EFI_VARS=y or m + +The implementation depends on receiving information about the UEFI environment +in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF. + +UEFI stub +========= +The "stub" is a feature that extends the Image/zImage into a valid UEFI +PE/COFF executable, including a loader application that makes it possible to +load the kernel directly from the UEFI shell, boot menu, or one of the +lightweight bootloaders like Gummiboot or rEFInd. + +The kernel image built with stub support remains a valid kernel image for +booting in non-UEFI environments. + +UEFI kernel support on ARM +========================== +UEFI kernel support on the ARM architectures (arm and arm64) is only available +when boot is performed through the stub. + +When booting in UEFI mode, the stub deletes any memory nodes from a provided DT. +Instead, the kernel reads the UEFI memory map. + +The stub populates the FDT /chosen node with (and the kernel scans for) the +following parameters: +________________________________________________________________________________ +Name | Size | Description +================================================================================ +linux,uefi-system-table | 64-bit | Physical address of the UEFI System Table. +-------------------------------------------------------------------------------- +linux,uefi-mmap-start | 64-bit | Physical address of the UEFI memory map, + | | populated by the UEFI GetMemoryMap() call. +-------------------------------------------------------------------------------- +linux,uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map + | | pointed to in previous entry. +-------------------------------------------------------------------------------- +linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI + | | memory map. +-------------------------------------------------------------------------------- +linux,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format. +-------------------------------------------------------------------------------- +linux,uefi-stub-kern-ver | string | Copy of linux_banner from build. +-------------------------------------------------------------------------------- + +For verbose debug messages, specify 'uefi_debug' on the kernel command line. diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index a9691cc..85af34d 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -72,23 +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. -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. +- 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 + jumps to code0 to resume the normal boot process. + +- 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: @@ -111,8 +142,14 @@ Before jumping into the kernel, the following conditions must be met: - Caches, MMUs The MMU must be off. Instruction cache may be on or off. - Data cache must be off and invalidated. - External caches (if present) must be configured and disabled. + The address range corresponding to the loaded kernel image must be + cleaned to the PoC. In the presence of a system cache or other + coherent masters with caches enabled, this will typically require + cache maintenance by VA rather than set/way operations. + System caches which respect the architected cache maintenance by VA + operations must be configured and may be enabled. + System caches which do not respect architected cache maintenance by VA + operations (not recommended) must be configured and disabled. - Architected timers CNTFRQ must be programmed with the timer frequency and CNTVOFF must diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt index 85e24c4..344e85c 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 earlyprintk device - -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 earlyprintk device - -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/atomic_ops.txt b/Documentation/atomic_ops.txt index d9ca5be..68542fe 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt @@ -285,15 +285,13 @@ If a caller requires memory barrier semantics around an atomic_t operation which does not return a value, a set of interfaces are defined which accomplish this: - void smp_mb__before_atomic_dec(void); - void smp_mb__after_atomic_dec(void); - void smp_mb__before_atomic_inc(void); - void smp_mb__after_atomic_inc(void); + void smp_mb__before_atomic(void); + void smp_mb__after_atomic(void); -For example, smp_mb__before_atomic_dec() can be used like so: +For example, smp_mb__before_atomic() can be used like so: obj->dead = 1; - smp_mb__before_atomic_dec(); + smp_mb__before_atomic(); atomic_dec(&obj->ref_count); It makes sure that all memory operations preceding the atomic_dec() @@ -302,15 +300,10 @@ operation. In the above example, it guarantees that the assignment of "1" to obj->dead will be globally visible to other cpus before the atomic counter decrement. -Without the explicit smp_mb__before_atomic_dec() call, the +Without the explicit smp_mb__before_atomic() call, the implementation could legally allow the atomic counter update visible to other cpus before the "obj->dead = 1;" assignment. -The other three interfaces listed are used to provide explicit -ordering with respect to memory operations after an atomic_dec() call -(smp_mb__after_atomic_dec()) and around atomic_inc() calls -(smp_mb__{before,after}_atomic_inc()). - A missing memory barrier in the cases where they are required by the atomic_t implementation above can have disastrous results. Here is an example, which follows a pattern occurring frequently in the Linux @@ -487,12 +480,12 @@ Finally there is the basic operation: Which returns a boolean indicating if bit "nr" is set in the bitmask pointed to by "addr". -If explicit memory barriers are required around clear_bit() (which -does not return a value, and thus does not need to provide memory -barrier semantics), two interfaces are provided: +If explicit memory barriers are required around {set,clear}_bit() (which do +not return a value, and thus does not need to provide memory barrier +semantics), two interfaces are provided: - void smp_mb__before_clear_bit(void); - void smp_mb__after_clear_bit(void); + void smp_mb__before_atomic(void); + void smp_mb__after_atomic(void); They are used as follows, and are akin to their atomic_t operation brothers: @@ -500,13 +493,13 @@ brothers: /* All memory operations before this call will * be globally visible before the clear_bit(). */ - smp_mb__before_clear_bit(); + smp_mb__before_atomic(); clear_bit( ... ); /* The clear_bit() will be visible before all * subsequent memory operations. */ - smp_mb__after_clear_bit(); + smp_mb__after_atomic(); There are two special bitops with lock barrier semantics (acquire/release, same as spinlocks). These operate in the same way as their non-_lock/unlock diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt index 2eccddf..0595c3f 100644 --- a/Documentation/blockdev/zram.txt +++ b/Documentation/blockdev/zram.txt @@ -21,7 +21,43 @@ Following shows a typical sequence of steps for using zram. This creates 4 devices: /dev/zram{0,1,2,3} (num_devices parameter is optional. Default: 1) -2) Set Disksize +2) Set max number of compression streams + Compression backend may use up to max_comp_streams compression streams, + thus allowing up to max_comp_streams concurrent compression operations. + By default, compression backend uses single compression stream. + + Examples: + #show max compression streams number + cat /sys/block/zram0/max_comp_streams + + #set max compression streams number to 3 + echo 3 > /sys/block/zram0/max_comp_streams + +Note: +In order to enable compression backend's multi stream support max_comp_streams +must be initially set to desired concurrency level before ZRAM device +initialisation. Once the device initialised as a single stream compression +backend (max_comp_streams equals to 1), you will see error if you try to change +the value of max_comp_streams because single stream compression backend +implemented as a special case by lock overhead issue and does not support +dynamic max_comp_streams. Only multi stream backend supports dynamic +max_comp_streams adjustment. + +3) Select compression algorithm + Using comp_algorithm device attribute one can see available and + currently selected (shown in square brackets) compression algortithms, + change selected compression algorithm (once the device is initialised + there is no way to change compression algorithm). + + Examples: + #show supported compression algorithms + cat /sys/block/zram0/comp_algorithm + lzo [lz4] + + #select lzo compression algorithm + echo lzo > /sys/block/zram0/comp_algorithm + +4) Set Disksize Set disk size by writing the value to sysfs node 'disksize'. The value can be either in bytes or you can use mem suffixes. Examples: @@ -33,32 +69,38 @@ Following shows a typical sequence of steps for using zram. echo 512M > /sys/block/zram0/disksize echo 1G > /sys/block/zram0/disksize -3) Activate: +Note: +There is little point creating a zram of greater than twice the size of memory +since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the +size of the disk when not in use so a huge zram is wasteful. + +5) Activate: mkswap /dev/zram0 swapon /dev/zram0 mkfs.ext4 /dev/zram1 mount /dev/zram1 /tmp -4) Stats: +6) Stats: Per-device statistics are exported as various nodes under /sys/block/zram<id>/ disksize num_reads num_writes + failed_reads + failed_writes invalid_io notify_free - discard zero_pages orig_data_size compr_data_size mem_used_total -5) Deactivate: +7) Deactivate: swapoff /dev/zram0 umount /dev/zram1 -6) Reset: +8) Reset: Write any positive value to 'reset' sysfs node echo 1 > /sys/block/zram0/reset echo 1 > /sys/block/zram1/reset diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index 821de56..10c949b 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/memcg_test.txt b/Documentation/cgroups/memcg_test.txt index ce94a83..80ac454 100644 --- a/Documentation/cgroups/memcg_test.txt +++ b/Documentation/cgroups/memcg_test.txt @@ -24,7 +24,7 @@ Please note that implementation details can be changed. a page/swp_entry may be charged (usage += PAGE_SIZE) at - mem_cgroup_newpage_charge() + mem_cgroup_charge_anon() Called at new page fault and Copy-On-Write. mem_cgroup_try_charge_swapin() @@ -32,7 +32,7 @@ Please note that implementation details can be changed. Followed by charge-commit-cancel protocol. (With swap accounting) At commit, a charge recorded in swap_cgroup is removed. - mem_cgroup_cache_charge() + mem_cgroup_charge_file() Called at add_to_page_cache() mem_cgroup_cache_charge_swapin() diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 2622115..02ab997 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -270,6 +270,11 @@ When oom event notifier is registered, event will be delivered. 2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM) +WARNING: Current implementation lacks reclaim support. That means allocation + attempts will fail when close to the limit even if there are plenty of + kmem available for reclaim. That makes this option unusable in real + life so DO NOT SELECT IT unless for development purposes. + With the Kernel memory extension, the Memory Controller is able to limit the amount of kernel memory used by the system. Kernel memory is fundamentally different than user memory, since it can't be swapped out, which makes it @@ -453,15 +458,11 @@ About use_hierarchy, see Section 6. 5.1 force_empty memory.force_empty interface is provided to make cgroup's memory usage empty. - You can use this interface only when the cgroup has no tasks. When writing anything to this # echo 0 > memory.force_empty - Almost all pages tracked by this memory cgroup will be unmapped and freed. - Some pages cannot be freed because they are locked or in-use. Such pages are - moved to parent (if use_hierarchy==1) or root (if use_hierarchy==0) and this - cgroup will be empty. + the cgroup will be reclaimed and as many pages reclaimed as possible. The typical use case for this interface is before calling rmdir(). Because rmdir() moves all pages to parent, some out-of-use page caches can be @@ -535,16 +536,13 @@ Note: 5.3 swappiness -Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only. -Please note that unlike the global swappiness, memcg knob set to 0 -really prevents from any swapping even if there is a swap storage -available. This might lead to memcg OOM killer if there are no file -pages to reclaim. +Overrides /proc/sys/vm/swappiness for the particular group. The tunable +in the root cgroup corresponds to the global swappiness setting. -Following cgroups' swappiness can't be changed. -- root cgroup (uses /proc/sys/vm/swappiness). -- a cgroup which uses hierarchy and it has other cgroup(s) below it. -- a cgroup which uses hierarchy and not the root of hierarchy. +Please note that unlike during the global reclaim, limit reclaim +enforces that 0 swappiness really prevents from any swapping even if +there is a swap storage available. This might lead to memcg OOM killer +if there are no file pages to reclaim. 5.4 failcnt @@ -754,7 +752,6 @@ You can disable the OOM-killer by writing "1" to memory.oom_control file, as: #echo 1 > memory.oom_control -This operation is only allowed to the top cgroup of a sub-hierarchy. If OOM-killer is disabled, tasks under cgroup will hang/sleep in memory cgroup's OOM-waitqueue when they request accountable memory. diff --git a/Documentation/cgroups/resource_counter.txt b/Documentation/cgroups/resource_counter.txt index 5108afb..762ca54 100644 --- a/Documentation/cgroups/resource_counter.txt +++ b/Documentation/cgroups/resource_counter.txt @@ -76,15 +76,7 @@ to work with it. limit_fail_at parameter is set to the particular res_counter element where the charging failed. - d. int res_counter_charge_locked - (struct res_counter *rc, unsigned long val, bool force) - - The same as res_counter_charge(), but it must not acquire/release the - res_counter->lock internally (it must be called with res_counter->lock - held). The force parameter indicates whether we can bypass the limit. - - e. u64 res_counter_uncharge[_locked] - (struct res_counter *rc, unsigned long val) + d. u64 res_counter_uncharge(struct res_counter *rc, unsigned long val) When a resource is released (freed) it should be de-accounted from the resource counter it was accounted to. This is called @@ -93,7 +85,7 @@ to work with it. The _locked routines imply that the res_counter->lock is taken. - f. u64 res_counter_uncharge_until + e. u64 res_counter_uncharge_until (struct res_counter *rc, struct res_counter *top, unsigned long val) diff --git a/Documentation/cgroups/unified-hierarchy.txt b/Documentation/cgroups/unified-hierarchy.txt new file mode 100644 index 0000000..4f45632 --- /dev/null +++ b/Documentation/cgroups/unified-hierarchy.txt @@ -0,0 +1,382 @@ + +Cgroup unified hierarchy + +April, 2014 Tejun Heo <tj@kernel.org> + +This document describes the changes made by unified hierarchy and +their rationales. It will eventually be merged into the main cgroup +documentation. + +CONTENTS + +1. Background +2. Basic Operation + 2-1. Mounting + 2-2. cgroup.subtree_control + 2-3. cgroup.controllers +3. Structural Constraints + 3-1. Top-down + 3-2. No internal tasks +4. Other Changes + 4-1. [Un]populated Notification + 4-2. Other Core Changes + 4-3. Per-Controller Changes + 4-3-1. blkio + 4-3-2. cpuset + 4-3-3. memory +5. Planned Changes + 5-1. CAP for resource control + + +1. Background + +cgroup allows an arbitrary number of hierarchies and each hierarchy +can host any number of controllers. While this seems to provide a +high level of flexibility, it isn't quite useful in practice. + +For example, as there is only one instance of each controller, utility +type controllers such as freezer which can be useful in all +hierarchies can only be used in one. The issue is exacerbated by the +fact that controllers can't be moved around once hierarchies are +populated. Another issue is that all controllers bound to a hierarchy +are forced to have exactly the same view of the hierarchy. It isn't +possible to vary the granularity depending on the specific controller. + +In practice, these issues heavily limit which controllers can be put +on the same hierarchy and most configurations resort to putting each +controller on its own hierarchy. Only closely related ones, such as +the cpu and cpuacct controllers, make sense to put on the same +hierarchy. This often means that userland ends up managing multiple +similar hierarchies repeating the same steps on each hierarchy +whenever a hierarchy management operation is necessary. + +Unfortunately, support for multiple hierarchies comes at a steep cost. +Internal implementation in cgroup core proper is dazzlingly +complicated but more importantly the support for multiple hierarchies +restricts how cgroup is used in general and what controllers can do. + +There's no limit on how many hierarchies there may be, which means +that a task's cgroup membership can't be described in finite length. +The key may contain any varying number of entries and is unlimited in +length, which makes it highly awkward to handle and leads to addition +of controllers which exist only to identify membership, which in turn +exacerbates the original problem. + +Also, as a controller can't have any expectation regarding what shape +of hierarchies other controllers would be on, each controller has to +assume that all other controllers are operating on completely +orthogonal hierarchies. This makes it impossible, or at least very +cumbersome, for controllers to cooperate with each other. + +In most use cases, putting controllers on hierarchies which are +completely orthogonal to each other isn't necessary. What usually is +called for is the ability to have differing levels of granularity +depending on the specific controller. In other words, hierarchy may +be collapsed from leaf towards root when viewed from specific +controllers. For example, a given configuration might not care about +how memory is distributed beyond a certain level while still wanting +to control how CPU cycles are distributed. + +Unified hierarchy is the next version of cgroup interface. It aims to +address the aforementioned issues by having more structure while +retaining enough flexibility for most use cases. Various other +general and controller-specific interface issues are also addressed in +the process. + + +2. Basic Operation + +2-1. Mounting + +Currently, unified hierarchy can be mounted with the following mount +command. Note that this is still under development and scheduled to +change soon. + + mount -t cgroup -o __DEVEL__sane_behavior cgroup $MOUNT_POINT + +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 + +All cgroups on unified hierarchy have a "cgroup.subtree_control" file +which governs which controllers are enabled on the children of the +cgroup. Let's assume a hierarchy like the following. + + root - A - B - C + \ D + +root's "cgroup.subtree_control" file determines which controllers are +enabled on A. A's on B. B's on C and D. This coincides with the +fact that controllers on the immediate sub-level are used to +distribute the resources of the parent. In fact, it's natural to +assume that resource control knobs of a child belong to its parent. +Enabling a controller in a "cgroup.subtree_control" file declares that +distribution of the respective resources of the cgroup will be +controlled. Note that this means that controller enable states are +shared among siblings. + +When read, the file contains a space-separated list of currently +enabled controllers. A write to the file should contain a +space-separated list of controllers with '+' or '-' prefixed (without +the quotes). Controllers prefixed with '+' are enabled and '-' +disabled. If a controller is listed multiple times, the last entry +wins. The specific operations are executed atomically - either all +succeed or fail. + + +2-3. cgroup.controllers + +Read-only "cgroup.controllers" file contains a space-separated list of +controllers which can be enabled in the cgroup's +"cgroup.subtree_control" file. + +In the root cgroup, this lists controllers which are not bound to +other hierarchies and the content changes as controllers are bound to +and unbound from other hierarchies. + +In non-root cgroups, the content of this file equals that of the +parent's "cgroup.subtree_control" file as only controllers enabled +from the parent can be used in its children. + + +3. Structural Constraints + +3-1. Top-down + +As it doesn't make sense to nest control of an uncontrolled resource, +all non-root "cgroup.subtree_control" files can only contain +controllers which are enabled in the parent's "cgroup.subtree_control" +file. A controller can be enabled only if the parent has the +controller enabled and a controller can't be disabled if one or more +children have it enabled. + + +3-2. No internal tasks + +One long-standing issue that cgroup faces is the competition between +tasks belonging to the parent cgroup and its children cgroups. This +is inherently nasty as two different types of entities compete and +there is no agreed-upon obvious way to handle it. Different +controllers are doing different things. + +The cpu controller considers tasks and cgroups as equivalents and maps +nice levels to cgroup weights. This works for some cases but falls +flat when children should be allocated specific ratios of CPU cycles +and the number of internal tasks fluctuates - the ratios constantly +change as the number of competing entities fluctuates. There also are +other issues. The mapping from nice level to weight isn't obvious or +universal, and there are various other knobs which simply aren't +available for tasks. + +The blkio controller implicitly creates a hidden leaf node for each +cgroup to host the tasks. The hidden leaf has its own copies of all +the knobs with "leaf_" prefixed. While this allows equivalent control +over internal tasks, it's with serious drawbacks. It always adds an +extra layer of nesting which may not be necessary, makes the interface +messy and significantly complicates the implementation. + +The memory controller currently doesn't have a way to control what +happens between internal tasks and child cgroups and the behavior is +not clearly defined. There have been attempts to add ad-hoc behaviors +and knobs to tailor the behavior to specific workloads. Continuing +this direction will lead to problems which will be extremely difficult +to resolve in the long term. + +Multiple controllers struggle with internal tasks and came up with +different ways to deal with it; unfortunately, all the approaches in +use now are severely flawed and, furthermore, the widely different +behaviors make cgroup as whole highly inconsistent. + +It is clear that this is something which needs to be addressed from +cgroup core proper in a uniform way so that controllers don't need to +worry about it and cgroup as a whole shows a consistent and logical +behavior. To achieve that, unified hierarchy enforces the following +structural constraint: + + Except for the root, only cgroups which don't contain any task may + have controllers enabled in their "cgroup.subtree_control" files. + +Combined with other properties, this guarantees that, when a +controller is looking at the part of the hierarchy which has it +enabled, tasks are always only on the leaves. This rules out +situations where child cgroups compete against internal tasks of the +parent. + +There are two things to note. Firstly, the root cgroup is exempt from +the restriction. Root contains tasks and anonymous resource +consumption which can't be associated with any other cgroup and +requires special treatment from most controllers. How resource +consumption in the root cgroup is governed is up to each controller. + +Secondly, the restriction doesn't take effect if there is no enabled +controller in the cgroup's "cgroup.subtree_control" file. This is +important as otherwise it wouldn't be possible to create children of a +populated cgroup. To control resource distribution of a cgroup, the +cgroup must create children and transfer all its tasks to the children +before enabling controllers in its "cgroup.subtree_control" file. + + +4. Other Changes + +4-1. [Un]populated Notification + +cgroup users often need a way to determine when a cgroup's +subhierarchy becomes empty so that it can be cleaned up. cgroup +currently provides release_agent for it; unfortunately, this mechanism +is riddled with issues. + +- It delivers events by forking and execing a userland binary + specified as the release_agent. This is a long deprecated method of + notification delivery. It's extremely heavy, slow and cumbersome to + integrate with larger infrastructure. + +- There is single monitoring point at the root. There's no way to + delegate management of a subtree. + +- The event isn't recursive. It triggers when a cgroup doesn't have + any tasks or child cgroups. Events for internal nodes trigger only + after all children are removed. This again makes it impossible to + delegate management of a subtree. + +- Events are filtered from the kernel side. A "notify_on_release" + file is used to subscribe to or suppress release events. This is + unnecessarily complicated and probably done this way because event + delivery itself was expensive. + +Unified hierarchy implements an interface file "cgroup.populated" +which can be used to monitor whether the cgroup's subhierarchy has +tasks in it or not. Its value is 0 if there is no task in the cgroup +and its descendants; otherwise, 1. poll and [id]notify events are +triggered when the value changes. + +This is significantly lighter and simpler and trivially allows +delegating management of subhierarchy - subhierarchy monitoring can +block further propagation simply by putting itself or another process +in the subhierarchy and monitor events that it's interested in from +there without interfering with monitoring higher in the tree. + +In unified hierarchy, the release_agent mechanism is no longer +supported and the interface files "release_agent" and +"notify_on_release" do not exist. + + +4-2. Other Core Changes + +- None of the mount options is allowed. + +- remount is disallowed. + +- rename(2) is disallowed. + +- The "tasks" file is removed. Everything should at process + granularity. Use the "cgroup.procs" file instead. + +- The "cgroup.procs" file is not sorted. pids will be unique unless + they got recycled in-between reads. + +- The "cgroup.clone_children" file is removed. + + +4-3. Per-Controller Changes + +4-3-1. blkio + +- blk-throttle becomes properly hierarchical. + + +4-3-2. cpuset + +- Tasks are kept in empty cpusets after hotplug and take on the masks + of the nearest non-empty ancestor, instead of being moved to it. + +- A task can be moved into an empty cpuset, and again it takes on the + masks of the nearest non-empty ancestor. + + +4-3-3. memory + +- use_hierarchy is on by default and the cgroup file for the flag is + not created. + + +5. Planned Changes + +5-1. CAP for resource control + +Unified hierarchy will require one of the capabilities(7), which is +yet to be decided, for all resource control related knobs. Process +organization operations - creation of sub-cgroups and migration of +processes in sub-hierarchies may be delegated by changing the +ownership and/or permissions on the cgroup directory and +"cgroup.procs" interface file; however, all operations which affect +resource control - writes to a "cgroup.subtree_control" file or any +controller-specific knobs - will require an explicit CAP privilege. + +This, in part, is to prevent the cgroup interface from being +inadvertently promoted to programmable API used by non-privileged +binaries. cgroup exposes various aspects of the system in ways which +aren't properly abstracted for direct consumption by regular programs. +This is an administration interface much closer to sysctl knobs than +system calls. Even the basic access model, being filesystem path +based, isn't suitable for direct consumption. There's no way to +access "my cgroup" in a race-free way or make multiple operations +atomic against migration to another cgroup. + +Another aspect is that, for better or for worse, the cgroup interface +goes through far less scrutiny than regular interfaces for +unprivileged userland. The upside is that cgroup is able to expose +useful features which may not be suitable for general consumption in a +reasonable time frame. It provides a relatively short path between +internal details and userland-visible interface. Of course, this +shortcut comes with high risk. We go through what we go through for +general kernel APIs for good reasons. It may end up leaking internal +details in a way which can exert significant pain by locking the +kernel into a contract that can't be maintained in a reasonable +manner. + +Also, due to the specific nature, cgroup and its controllers don't +tend to attract attention from a wide scope of developers. cgroup's +short history is already fraught with severely mis-designed +interfaces, unnecessary commitments to and exposing of internal +details, broken and dangerous implementations of various features. + +Keeping cgroup as an administration interface is both advantageous for +its role and imperative given its nature. Some of the cgroup features +may make sense for unprivileged access. If deemed justified, those +must be further abstracted and implemented as a different interface, +be it a system call or process-private filesystem, and survive through +the scrutiny that any interface for general consumption is required to +go through. + +Requiring CAP is not a complete solution but should serve as a +significant deterrent against spraying cgroup usages in non-privileged +programs. diff --git a/Documentation/clk.txt b/Documentation/clk.txt index 699ef2a..1fee72f 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -68,21 +68,27 @@ the operations defined in clk.h: int (*is_enabled)(struct clk_hw *hw); unsigned long (*recalc_rate)(struct clk_hw *hw, unsigned long parent_rate); - long (*round_rate)(struct clk_hw *hw, unsigned long, - unsigned long *); + long (*round_rate)(struct clk_hw *hw, + unsigned long rate, + unsigned long *parent_rate); long (*determine_rate)(struct clk_hw *hw, unsigned long rate, unsigned long *best_parent_rate, struct clk **best_parent_clk); int (*set_parent)(struct clk_hw *hw, u8 index); u8 (*get_parent)(struct clk_hw *hw); - int (*set_rate)(struct clk_hw *hw, unsigned long); + int (*set_rate)(struct clk_hw *hw, + unsigned long rate, + unsigned long parent_rate); int (*set_rate_and_parent)(struct clk_hw *hw, unsigned long rate, - unsigned long parent_rate, u8 index); + unsigned long parent_rate, + u8 index); unsigned long (*recalc_accuracy)(struct clk_hw *hw, - unsigned long parent_accuracy); + unsigned long parent_accuracy); void (*init)(struct clk_hw *hw); + int (*debug_init)(struct clk_hw *hw, + struct dentry *dentry); }; Part 3 - hardware clk implementations @@ -255,3 +261,37 @@ are sorted out. To bypass this disabling, include "clk_ignore_unused" in the bootargs to the kernel. + + Part 7 - Locking + +The common clock framework uses two global locks, the prepare lock and the +enable lock. + +The enable lock is a spinlock and is held across calls to the .enable, +.disable and .is_enabled operations. Those operations are thus not allowed to +sleep, and calls to the clk_enable(), clk_disable() and clk_is_enabled() API +functions are allowed in atomic context. + +The prepare lock is a mutex and is held across calls to all other operations. +All those operations are allowed to sleep, and calls to the corresponding API +functions are not allowed in atomic context. + +This effectively divides operations in two groups from a locking perspective. + +Drivers don't need to manually protect resources shared between the operations +of one group, regardless of whether those resources are shared by multiple +clocks or not. However, access to resources that are shared between operations +of the two groups needs to be protected by the drivers. An example of such a +resource would be a register that controls both the clock rate and the clock +enable/disable state. + +The clock framework is reentrant, in that a driver is allowed to call clock +framework functions from within its implementation of clock operations. This +can for instance cause a .set_rate operation of one clock being called from +within the .set_rate operation of another clock. This case must be considered +in the driver implementations, but the code flow is usually controlled by the +driver in that case. + +Note that locking must also be considered when code outside of the common +clock framework needs to access resources used by the clock operations. This +is considered out of scope of this document. diff --git a/Documentation/connector/connector.txt b/Documentation/connector/connector.txt index e5c5f5e..f6215f9 100644 --- a/Documentation/connector/connector.txt +++ b/Documentation/connector/connector.txt @@ -24,7 +24,8 @@ netlink based networking for inter-process communication in a significantly easier way: int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *)); -void cn_netlink_send(struct cn_msg *msg, u32 __group, int gfp_mask); +void cn_netlink_send_multi(struct cn_msg *msg, u16 len, u32 portid, u32 __group, int gfp_mask); +void cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __group, int gfp_mask); struct cb_id { @@ -71,15 +72,21 @@ void cn_del_callback(struct cb_id *id); struct cb_id *id - unique connector's user identifier. -int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask); +int cn_netlink_send_multi(struct cn_msg *msg, u16 len, u32 portid, u32 __groups, int gfp_mask); +int cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __groups, int gfp_mask); Sends message to the specified groups. It can be safely called from softirq context, but may silently fail under strong memory pressure. If there are no listeners for given group -ESRCH can be returned. struct cn_msg * - message header(with attached data). + u16 len - for *_multi multiple cn_msg messages can be sent + u32 port - destination port. + If non-zero the message will be sent to the + given port, which should be set to the + original sender. u32 __group - destination group. - If __group is zero, then appropriate group will + If port and __group is zero, then appropriate group will be searched through all registered connector users, and message will be delivered to the group which was created for user with the same ID as in msg. @@ -111,7 +118,7 @@ acknowledge number MUST be the same + 1. If we receive a message and its sequence number is not equal to one we are expecting, then it is a new message. If we receive a message and its sequence number is the same as one we are expecting, but its -acknowledge is not equal to the acknowledge number in the original +acknowledge is not equal to the sequence number in the original message + 1, then it is a new message. Obviously, the protocol header contains the above id. diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt index 0060d76..70933ea 100644 --- a/Documentation/cpu-freq/core.txt +++ b/Documentation/cpu-freq/core.txt @@ -20,6 +20,7 @@ Contents: --------- 1. CPUFreq core and interfaces 2. CPUFreq notifiers +3. CPUFreq Table Generation with Operating Performance Point (OPP) 1. General Information ======================= @@ -92,3 +93,31 @@ values: cpu - number of the affected CPU old - old frequency new - new frequency + +3. CPUFreq Table Generation with Operating Performance Point (OPP) +================================================================== +For details about OPP, see Documentation/power/opp.txt + +dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with + cpufreq_frequency_table_cpuinfo which is provided with the list of + frequencies that are available for operation. This function provides + a ready to use conversion routine to translate the OPP layer's internal + information about the available frequencies into a format readily + providable to cpufreq. + + WARNING: Do not use this function in interrupt context. + + Example: + soc_pm_init() + { + /* Do things */ + r = dev_pm_opp_init_cpufreq_table(dev, &freq_table); + if (!r) + cpufreq_frequency_table_cpuinfo(policy, freq_table); + /* Do other things */ + } + + NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in + addition to CONFIG_PM_OPP. + +dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index 48da5fd..14f4e63 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -26,6 +26,7 @@ Contents: 1.4 target/target_index or setpolicy? 1.5 target/target_index 1.6 setpolicy +1.7 get_intermediate and target_intermediate 2. Frequency Table Helpers @@ -79,6 +80,10 @@ cpufreq_driver.attr - A pointer to a NULL-terminated list of "struct freq_attr" which allow to export values to sysfs. +cpufreq_driver.get_intermediate +and target_intermediate Used to switch to stable frequency while + changing CPU frequency. + 1.2 Per-CPU Initialization -------------------------- @@ -151,7 +156,7 @@ Some cpufreq-capable processors switch the frequency between certain limits on their own. These shall use the ->setpolicy call -1.4. target/target_index +1.5. target/target_index ------------- The target_index call has two arguments: struct cpufreq_policy *policy, @@ -160,6 +165,9 @@ and unsigned int index (into the exposed frequency table). The CPUfreq driver must set the new frequency when called here. The actual frequency must be determined by freq_table[index].frequency. +It should always restore to earlier frequency (i.e. policy->restore_freq) in +case of errors, even if we switched to intermediate frequency earlier. + Deprecated: ---------- The target call has three arguments: struct cpufreq_policy *policy, @@ -179,7 +187,7 @@ Here again the frequency table helper might assist you - see section 2 for details. -1.5 setpolicy +1.6 setpolicy --------------- The setpolicy call only takes a struct cpufreq_policy *policy as @@ -190,6 +198,23 @@ setting when policy->policy is CPUFREQ_POLICY_PERFORMANCE, and a powersaving-oriented setting when CPUFREQ_POLICY_POWERSAVE. Also check the reference implementation in drivers/cpufreq/longrun.c +1.7 get_intermediate and target_intermediate +-------------------------------------------- + +Only for drivers with target_index() and CPUFREQ_ASYNC_NOTIFICATION unset. + +get_intermediate should return a stable intermediate frequency platform wants to +switch to, and target_intermediate() should set CPU to to that frequency, before +jumping to the frequency corresponding to 'index'. Core will take care of +sending notifications and driver doesn't have to handle them in +target_intermediate() or target_index(). + +Drivers can return '0' from get_intermediate() in case they don't wish to switch +to intermediate frequency for some target frequency. In that case core will +directly call ->target_index(). + +NOTE: ->target_index() should restore to policy->restore_freq in case of +failures as core would send notifications for that. 2. Frequency Table Helpers @@ -228,3 +253,22 @@ is the corresponding frequency table helper for the ->target stage. Just pass the values to this function, and the unsigned int index returns the number of the frequency table entry which contains the frequency the CPU shall be set to. + +The following macros can be used as iterators over cpufreq_frequency_table: + +cpufreq_for_each_entry(pos, table) - iterates over all entries of frequency +table. + +cpufreq-for_each_valid_entry(pos, table) - iterates over all entries, +excluding CPUFREQ_ENTRY_INVALID frequencies. +Use arguments "pos" - a cpufreq_frequency_table * as a loop cursor and +"table" - the cpufreq_frequency_table * you want to iterate over. + +For example: + + struct cpufreq_frequency_table *pos, *driver_freq_table; + + cpufreq_for_each_entry(pos, driver_freq_table) { + /* Do something with pos */ + pos->frequency = ... + } diff --git a/Documentation/cpu-freq/index.txt b/Documentation/cpu-freq/index.txt index 3d0b915..dc024ab 100644 --- a/Documentation/cpu-freq/index.txt +++ b/Documentation/cpu-freq/index.txt @@ -35,8 +35,8 @@ Mailing List ------------ There is a CPU frequency changing CVS commit and general list where you can report bugs, problems or submit patches. To post a message, -send an email to cpufreq@vger.kernel.org, to subscribe go to -http://vger.kernel.org/vger-lists.html#cpufreq and follow the +send an email to linux-pm@vger.kernel.org, to subscribe go to +http://vger.kernel.org/vger-lists.html#linux-pm and follow the instructions there. Links diff --git a/Documentation/cpu-freq/intel-pstate.txt b/Documentation/cpu-freq/intel-pstate.txt index e742d21..a69ffe1 100644 --- a/Documentation/cpu-freq/intel-pstate.txt +++ b/Documentation/cpu-freq/intel-pstate.txt @@ -15,10 +15,13 @@ New sysfs files for controlling P state selection have been added to /sys/devices/system/cpu/intel_pstate/ max_perf_pct: limits the maximum P state that will be requested by - the driver stated as a percentage of the available performance. + the driver stated as a percentage of the available performance. The + available (P states) performance may be reduced by the no_turbo + setting described below. min_perf_pct: limits the minimum P state that will be requested by - the driver stated as a percentage of the available performance. + the driver stated as a percentage of the max (non-turbo) + performance level. no_turbo: limits the driver to selecting P states below the turbo frequency range. diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index be675d2..a0b005d 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -312,12 +312,57 @@ things will happen if a notifier in path sent a BAD notify code. Q: I don't see my action being called for all CPUs already up and running? A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined. If you need to perform some action for each cpu already in the system, then + do this: for_each_online_cpu(i) { foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i); foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i); } + However, if you want to register a hotplug callback, as well as perform + some initialization for CPUs that are already online, then do this: + + Version 1: (Correct) + --------- + + cpu_notifier_register_begin(); + + for_each_online_cpu(i) { + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_UP_PREPARE, i); + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_ONLINE, i); + } + + /* Note the use of the double underscored version of the API */ + __register_cpu_notifier(&foobar_cpu_notifier); + + cpu_notifier_register_done(); + + Note that the following code is *NOT* the right way to achieve this, + because it is prone to an ABBA deadlock between the cpu_add_remove_lock + and the cpu_hotplug.lock. + + Version 2: (Wrong!) + --------- + + get_online_cpus(); + + for_each_online_cpu(i) { + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_UP_PREPARE, i); + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_ONLINE, i); + } + + register_cpu_notifier(&foobar_cpu_notifier); + + put_online_cpus(); + + So always use the first version shown above when you want to register + callbacks as well as initialize the already online CPUs. + + Q: If i would like to develop cpu hotplug support for a new architecture, what do i need at a minimum? A: The following are what is required for CPU hotplug infrastructure to work diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt index fa0151a..5c9a567 100644 --- a/Documentation/debugging-via-ohci1394.txt +++ b/Documentation/debugging-via-ohci1394.txt @@ -25,9 +25,11 @@ using data transfer rates in the order of 10MB/s or more. With most FireWire controllers, memory access is limited to the low 4 GB of physical address space. This can be a problem on IA64 machines where memory is located mostly above that limit, but it is rarely a problem on -more common hardware such as x86, x86-64 and PowerPC. However, at least -Agere/LSI FW643e and FW643e2 controllers are known to support access to -physical addresses above 4 GB. +more common hardware such as x86, x86-64 and PowerPC. + +At least LSI FW643e and FW643e2 controllers are known to support access to +physical addresses above 4 GB, but this feature is currently not enabled by +Linux. Together with a early initialization of the OHCI-1394 controller for debugging, this facility proved most useful for examining long debugs logs in the printk @@ -101,8 +103,9 @@ Step-by-step instructions for using firescope with early OHCI initialization: compliant, they are based on TI PCILynx chips and require drivers for Win- dows operating systems. - The mentioned kernel log message contains ">4 GB phys DMA" in case of - OHCI-1394 controllers which support accesses above this limit. + The mentioned kernel log message contains the string "physUB" if the + controller implements a writable Physical Upper Bound register. This is + required for physical DMA above 4 GB (but not utilized by Linux yet). 2) Establish a working FireWire cable connection: diff --git a/Documentation/device-mapper/era.txt b/Documentation/device-mapper/era.txt new file mode 100644 index 0000000..3c6d01b --- /dev/null +++ b/Documentation/device-mapper/era.txt @@ -0,0 +1,108 @@ +Introduction +============ + +dm-era is a target that behaves similar to the linear target. In +addition it keeps track of which blocks were written within a user +defined period of time called an 'era'. Each era target instance +maintains the current era as a monotonically increasing 32-bit +counter. + +Use cases include tracking changed blocks for backup software, and +partially invalidating the contents of a cache to restore cache +coherency after rolling back a vendor snapshot. + +Constructor +=========== + + era <metadata dev> <origin dev> <block size> + + metadata dev : fast device holding the persistent metadata + origin dev : device holding data blocks that may change + block size : block size of origin data device, granularity that is + tracked by the target + +Messages +======== + +None of the dm messages take any arguments. + +checkpoint +---------- + +Possibly move to a new era. You shouldn't assume the era has +incremented. After sending this message, you should check the +current era via the status line. + +take_metadata_snap +------------------ + +Create a clone of the metadata, to allow a userland process to read it. + +drop_metadata_snap +------------------ + +Drop the metadata snapshot. + +Status +====== + +<metadata block size> <#used metadata blocks>/<#total metadata blocks> +<current era> <held metadata root | '-'> + +metadata block size : Fixed block size for each metadata block in + sectors +#used metadata blocks : Number of metadata blocks used +#total metadata blocks : Total number of metadata blocks +current era : The current era +held metadata root : The location, in blocks, of the metadata root + that has been 'held' for userspace read + access. '-' indicates there is no held root + +Detailed use case +================= + +The scenario of invalidating a cache when rolling back a vendor +snapshot was the primary use case when developing this target: + +Taking a vendor snapshot +------------------------ + +- Send a checkpoint message to the era target +- Make a note of the current era in its status line +- Take vendor snapshot (the era and snapshot should be forever + associated now). + +Rolling back to an vendor snapshot +---------------------------------- + +- Cache enters passthrough mode (see: dm-cache's docs in cache.txt) +- Rollback vendor storage +- Take metadata snapshot +- Ascertain which blocks have been written since the snapshot was taken + by checking each block's era +- Invalidate those blocks in the caching software +- Cache returns to writeback/writethrough mode + +Memory usage +============ + +The target uses a bitset to record writes in the current era. It also +has a spare bitset ready for switching over to a new era. Other than +that it uses a few 4k blocks for updating metadata. + + (4 * nr_blocks) bytes + buffers + +Resilience +========== + +Metadata is updated on disk before a write to a previously unwritten +block is performed. As such dm-era should not be effected by a hard +crash such as power failure. + +Userland tools +============== + +Userland tools are found in the increasingly poorly named +thin-provisioning-tools project: + + https://github.com/jthornber/thin-provisioning-tools diff --git a/Documentation/device-mapper/thin-provisioning.txt b/Documentation/device-mapper/thin-provisioning.txt index 05a27e9..2f51735 100644 --- a/Documentation/device-mapper/thin-provisioning.txt +++ b/Documentation/device-mapper/thin-provisioning.txt @@ -309,7 +309,10 @@ ii) Status error_if_no_space|queue_if_no_space If the pool runs out of data or metadata space, the pool will either queue or error the IO destined to the data device. The - default is to queue the IO until more space is added. + default is to queue the IO until more space is added or the + 'no_space_timeout' expires. The 'no_space_timeout' dm-thin-pool + module parameter can be used to change this timeout -- it + defaults to 60 seconds but may be disabled using a value of 0. iii) Messages diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 087d212..87b4c5e 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -353,6 +353,7 @@ Your cooperation is appreciated. 133 = /dev/exttrp External device trap 134 = /dev/apm_bios Advanced Power Management BIOS 135 = /dev/rtc Real Time Clock + 137 = /dev/vhci Bluetooth virtual HCI driver 139 = /dev/openprom SPARC OpenBoot PROM 140 = /dev/relay8 Berkshire Products Octal relay card 141 = /dev/relay16 Berkshire Products ISO-16 relay card @@ -1493,10 +1494,17 @@ Your cooperation is appreciated. 64 = /dev/radio0 Radio device ... 127 = /dev/radio63 Radio device + 128 = /dev/swradio0 Software Defined Radio device + ... + 191 = /dev/swradio63 Software Defined Radio device 224 = /dev/vbi0 Vertical blank interrupt ... 255 = /dev/vbi31 Vertical blank interrupt + Minor numbers are allocated dynamically unless + CONFIG_VIDEO_FIXED_MINOR_RANGES (default n) + configuration option is set. + 81 block I2O hard disk 0 = /dev/i2o/hdq 17th I2O hard disk, whole disk 16 = /dev/i2o/hdr 18th I2O hard disk, whole disk diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt index 06fc760..37b2caf 100644 --- a/Documentation/devicetree/bindings/arm/arch_timer.txt +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt @@ -19,6 +19,9 @@ to deliver its interrupts via SPIs. - clock-frequency : The frequency of the main counter, in Hz. Optional. +- always-on : a boolean property. If present, the timer is powered through an + always-on power domain, therefore it never loses context. + Example: timer { diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt index 926b4d6..26799ef 100644 --- a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt +++ b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt @@ -1,20 +1,21 @@ Power Management Service Unit(PMSU) ----------------------------------- -Available on Marvell SOCs: Armada 370 and Armada XP +Available on Marvell SOCs: Armada 370, Armada 38x and Armada XP Required properties: -- compatible: "marvell,armada-370-xp-pmsu" +- compatible: should be one of: + - "marvell,armada-370-pmsu" for Armada 370 or Armada XP + - "marvell,armada-380-pmsu" for Armada 38x + - "marvell,armada-370-xp-pmsu" was used for Armada 370/XP but is now + deprecated and will be removed -- reg: Should contain PMSU registers location and length. First pair - for the per-CPU SW Reset Control registers, second pair for the - Power Management Service Unit. +- reg: Should contain PMSU registers location and length. Example: -armada-370-xp-pmsu@d0022000 { - compatible = "marvell,armada-370-xp-pmsu"; - reg = <0xd0022100 0x430>, - <0xd0020800 0x20>; +armada-370-xp-pmsu@22000 { + compatible = "marvell,armada-370-pmsu"; + reg = <0x22000 0x1000>; }; diff --git a/Documentation/devicetree/bindings/arm/armada-375.txt b/Documentation/devicetree/bindings/arm/armada-375.txt new file mode 100644 index 0000000..867d0b8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-375.txt @@ -0,0 +1,9 @@ +Marvell Armada 375 Platforms Device Tree Bindings +------------------------------------------------- + +Boards with a SoC of the Marvell Armada 375 family shall have the +following property: + +Required root node property: + +compatible: must contain "marvell,armada375" diff --git a/Documentation/devicetree/bindings/arm/armada-38x.txt b/Documentation/devicetree/bindings/arm/armada-38x.txt new file mode 100644 index 0000000..ad9f8ed --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-38x.txt @@ -0,0 +1,20 @@ +Marvell Armada 38x Platforms Device Tree Bindings +------------------------------------------------- + +Boards with a SoC of the Marvell Armada 38x family shall have the +following property: + +Required root node property: + + - compatible: must contain "marvell,armada380" + +In addition, boards using the Marvell Armada 385 SoC shall have the +following property before the previous one: + +Required root node property: + +compatible: must contain "marvell,armada385" + +Example: + +compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380"; diff --git a/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt b/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt new file mode 100644 index 0000000..b63a7b6 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt @@ -0,0 +1,14 @@ +Marvell Armada CPU reset controller +=================================== + +Required properties: + +- compatible: Should be "marvell,armada-370-cpu-reset". + +- reg: should be register base and length as documented in the + datasheet for the CPU reset registers + +cpurst: cpurst@20800 { + compatible = "marvell,armada-370-cpu-reset"; + reg = <0x20800 0x20>; +}; diff --git a/Documentation/devicetree/bindings/arm/axxia.txt b/Documentation/devicetree/bindings/arm/axxia.txt new file mode 100644 index 0000000..7b4ef9c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/axxia.txt @@ -0,0 +1,12 @@ +Axxia AXM55xx device tree bindings + +Boards using the AXM55xx SoC need to have the following properties: + +Required root node property: + + - compatible = "lsi,axm5516" + +Boards: + + LSI AXM5516 Validation board (Amarillo) + compatible = "lsi,axm5516-amarillo", "lsi,axm5516" diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt b/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt new file mode 100644 index 0000000..e077425 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt @@ -0,0 +1,15 @@ +Broadcom BCM21664 device tree bindings +-------------------------------------- + +This document describes the device tree bindings for boards with the BCM21664 +SoC. + +Required root node property: + - compatible: brcm,bcm21664 + +Example: + / { + model = "BCM21664 SoC"; + compatible = "brcm,bcm21664"; + [...] + } diff --git a/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt b/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt new file mode 100644 index 0000000..93f31ca --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt @@ -0,0 +1,14 @@ +Broadcom Kona Family Reset Manager +---------------------------------- + +The reset manager is used on the Broadcom BCM21664 SoC. + +Required properties: + - compatible: brcm,bcm21664-resetmgr + - reg: memory address & range + +Example: + brcm,resetmgr@35001f00 { + compatible = "brcm,bcm21664-resetmgr"; + reg = <0x35001f00 0x24>; + }; diff --git a/Documentation/devicetree/bindings/arm/bcm4708.txt b/Documentation/devicetree/bindings/arm/bcm4708.txt new file mode 100644 index 0000000..6b0f49f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm4708.txt @@ -0,0 +1,8 @@ +Broadcom BCM4708 device tree bindings +------------------------------------------- + +Boards with the BCM4708 SoC shall have the following properties: + +Required root node property: + +compatible = "brcm,bcm4708"; diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt index 17d8cd1..8dd4661 100644 --- a/Documentation/devicetree/bindings/arm/coherency-fabric.txt +++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt @@ -1,16 +1,33 @@ Coherency fabric ---------------- -Available on Marvell SOCs: Armada 370 and Armada XP +Available on Marvell SOCs: Armada 370, Armada 375, Armada 38x and Armada XP Required properties: -- compatible: "marvell,coherency-fabric" +- compatible: the possible values are: + + * "marvell,coherency-fabric", to be used for the coherency fabric of + the Armada 370 and Armada XP. + + * "marvell,armada-375-coherency-fabric", for the Armada 375 coherency + fabric. + + * "marvell,armada-380-coherency-fabric", for the Armada 38x coherency + fabric. - reg: Should contain coherency fabric registers location and - length. First pair for the coherency fabric registers, second pair - for the per-CPU fabric registers registers. + length. + + * For "marvell,coherency-fabric", the first pair for the coherency + fabric registers, second pair for the per-CPU fabric registers. -Example: + * For "marvell,armada-375-coherency-fabric", only one pair is needed + for the per-CPU fabric registers. + + * For "marvell,armada-380-coherency-fabric", only one pair is needed + for the per-CPU fabric registers. + +Examples: coherency-fabric@d0020200 { compatible = "marvell,coherency-fabric"; @@ -19,3 +36,8 @@ coherency-fabric@d0020200 { }; +coherency-fabric@21810 { + compatible = "marvell,armada-375-coherency-fabric"; + reg = <0x21810 0x1c>; +}; + diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 9130435..1fe72a0 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -178,9 +178,19 @@ nodes to be present and contain the properties described below. Usage and definition depend on ARM architecture version. # On ARM v8 64-bit this property is required and must be one of: - "spin-table" "psci" - # On ARM 32-bit systems this property is optional. + "spin-table" + # On ARM 32-bit systems this property is optional and + can be one of: + "allwinner,sun6i-a31" + "arm,psci" + "marvell,armada-375-smp" + "marvell,armada-380-smp" + "marvell,armada-xp-smp" + "qcom,gcc-msm8660" + "qcom,kpss-acc-v1" + "qcom,kpss-acc-v2" + "rockchip,rk3066-smp" - cpu-release-addr Usage: required for systems that have an "enable-method" @@ -191,6 +201,21 @@ nodes to be present and contain the properties described below. property identifying a 64-bit zero-initialised memory location. + - qcom,saw + Usage: required for systems that have an "enable-method" + property value of "qcom,kpss-acc-v1" or + "qcom,kpss-acc-v2" + Value type: <phandle> + Definition: Specifies the SAW[1] node associated with this CPU. + + - qcom,acc + Usage: required for systems that have an "enable-method" + property value of "qcom,kpss-acc-v1" or + "qcom,kpss-acc-v2" + Value type: <phandle> + Definition: Specifies the ACC[2] node associated with this CPU. + + Example 1 (dual-cluster big.LITTLE system 32-bit): cpus { @@ -382,3 +407,7 @@ cpus { cpu-release-addr = <0 0x20000000>; }; }; + +-- +[1] arm/msm/qcom,saw2.txt +[2] arm/msm/qcom,kpss-acc.txt diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt index 5216b41..8b4f7b7f 100644 --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt @@ -9,6 +9,18 @@ Required Properties: - reg: physical base address of the controller and length of memory mapped region. +Optional Properties: +- clocks: List of clock handles. The parent clocks of the input clocks to the + devices in this power domain are set to oscclk before power gating + and restored back after powering on a domain. This is required for + all domains which are powered on and off and not required for unused + domains. +- clock-names: The following clocks can be specified: + - oscclk: Oscillator clock. + - pclkN, clkN: Pairs of parent of input clock and input clock to the + devices in this power domain. Maximum of 4 pairs (N = 0 to 3) + are supported currently. + Node of a device using power domains must have a samsung,power-domain property defined with a phandle to respective power domain. @@ -19,6 +31,14 @@ Example: reg = <0x10023C00 0x10>; }; + mfc_pd: power-domain@10044060 { + compatible = "samsung,exynos4210-pd"; + reg = <0x10044060 0x20>; + clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>, + <&clock CLK_MOUT_USER_ACLK333>; + clock-names = "oscclk", "pclk0", "clk0"; + }; + Example of the node using power domain: node { diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt b/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt new file mode 100644 index 0000000..4a0a4f7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt @@ -0,0 +1,38 @@ +Samsung Exynos SYSRAM for SMP bringup: +------------------------------------ + +Samsung SMP-capable Exynos SoCs use part of the SYSRAM for the bringup +of the secondary cores. Once the core gets powered up it executes the +code that is residing at some specific location of the SYSRAM. + +Therefore reserved section sub-nodes have to be added to the mmio-sram +declaration. These nodes are of two types depending upon secure or +non-secure execution environment. + +Required sub-node properties: +- compatible : depending upon boot mode, should be + "samsung,exynos4210-sysram" : for Secure SYSRAM + "samsung,exynos4210-sysram-ns" : for Non-secure SYSRAM + +The rest of the properties should follow the generic mmio-sram discription +found in ../../misc/sysram.txt + +Example: + + sysram@02020000 { + compatible = "mmio-sram"; + reg = <0x02020000 0x54000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x02020000 0x54000>; + + smp-sysram@0 { + compatible = "samsung,exynos4210-sysram"; + reg = <0x0 0x1000>; + }; + + smp-sysram@53000 { + compatible = "samsung,exynos4210-sysram-ns"; + reg = <0x53000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index bae0d87..5573c08 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -50,6 +50,11 @@ Optional regions, used when the GIC doesn't have banked registers. The offset is cpu-offset * cpu-nr. +- arm,routable-irqs : Total number of gic irq inputs which are not directly + connected from the peripherals, but are routed dynamically + by a crossbar/multiplexer preceding the GIC. The GIC irq + input line is assigned dynamically when the corresponding + peripheral's crossbar line is mapped. Example: intc: interrupt-controller@fff11000 { @@ -57,6 +62,7 @@ Example: #interrupt-cells = <3>; #address-cells = <1>; interrupt-controller; + arm,routable-irqs = <160>; reg = <0xfff11000 0x1000>, <0xfff10100 0x100>; }; diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt b/Documentation/devicetree/bindings/arm/global_timer.txt index 1e54898..bdae3a8 100644 --- a/Documentation/devicetree/bindings/arm/global_timer.txt +++ b/Documentation/devicetree/bindings/arm/global_timer.txt @@ -4,8 +4,11 @@ ** Timer node required properties: -- compatible : Should be "arm,cortex-a9-global-timer" - Driver supports versions r2p0 and above. +- compatible : should contain + * "arm,cortex-a5-global-timer" for Cortex-A5 global timers. + * "arm,cortex-a9-global-timer" for Cortex-A9 global + timers or any compatible implementation. Note: driver + supports versions r2p0 and above. - interrupts : One interrupt to each core diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt index 8c7a465..df0a452 100644 --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt @@ -30,3 +30,17 @@ Example: resume-offset = <0x308>; reboot-offset = <0x4>; }; + +PCTRL: Peripheral misc control register + +Required Properties: +- compatible: "hisilicon,pctrl" +- reg: Address and size of pctrl. + +Example: + + /* for Hi3620 */ + pctrl: pctrl@fca09000 { + compatible = "hisilicon,pctrl"; + reg = <0xfca09000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt index 63c0e6a..59d7a46 100644 --- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt +++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt @@ -8,3 +8,13 @@ Required properties: - compatible: All TI specific devices present in Keystone SOC should be in the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550 type UART should use the specified compatible for those devices. + +Boards: +- Keystone 2 Hawking/Kepler EVM + compatible = "ti,k2hk-evm","ti,keystone" + +- Keystone 2 Lamarr EVM + compatible = "ti,k2l-evm","ti,keystone" + +- Keystone 2 Edison EVM + compatible = "ti,k2e-evm","ti,keystone" diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt index b513cb8..af527ee 100644 --- a/Documentation/devicetree/bindings/arm/l2cc.txt +++ b/Documentation/devicetree/bindings/arm/l2cc.txt @@ -40,6 +40,9 @@ Optional properties: - arm,filter-ranges : <start length> Starting address and length of window to filter. Addresses in the filter window are directed to the M1 port. Other addresses will go to the M0 port. +- arm,io-coherent : indicates that the system is operating in an hardware + I/O coherent mode. Valid only when the arm,pl310-cache compatible + string is used. - interrupts : 1 combined interrupt. - cache-id-part: cache id part number to be used if it is not present on hardware diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell,berlin.txt index 737afa5..94013a9 100644 --- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt +++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt @@ -12,6 +12,7 @@ SoC and board used. Currently known SoC compatibles are: "marvell,berlin2" for Marvell Armada 1500 (BG2, 88DE3100), "marvell,berlin2cd" for Marvell Armada 1500-mini (BG2CD, 88DE3005) "marvell,berlin2ct" for Marvell Armada ? (BG2CT, 88DE????) + "marvell,berlin2q" for Marvell Armada 1500-pro (BG2Q, 88DE3114) "marvell,berlin3" for Marvell Armada ? (BG3, 88DE????) * Example: @@ -22,3 +23,104 @@ SoC and board used. Currently known SoC compatibles are: ... } + +* Marvell Berlin2 chip control binding + +Marvell Berlin SoCs have a chip control register set providing several +individual registers dealing with pinmux, padmux, clock, reset, and secondary +CPU boot address. Unfortunately, the individual registers are spread among the +chip control registers, so there should be a single DT node only providing the +different functions which are described below. + +Required properties: +- compatible: shall be one of + "marvell,berlin2-chip-ctrl" for BG2 + "marvell,berlin2cd-chip-ctrl" for BG2CD + "marvell,berlin2q-chip-ctrl" for BG2Q +- reg: address and length of following register sets for + BG2/BG2CD: chip control register set + BG2Q: chip control register set and cpu pll registers + +* Marvell Berlin2 system control binding + +Marvell Berlin SoCs have a system control register set providing several +individual registers dealing with pinmux, padmux, and reset. + +Required properties: +- compatible: should be one of + "marvell,berlin2-system-ctrl" for BG2 + "marvell,berlin2cd-system-ctrl" for BG2CD + "marvell,berlin2q-system-ctrl" for BG2Q +- reg: address and length of the system control register set + +* Clock provider binding + +As clock related registers are spread among the chip control registers, the +chip control node also provides the clocks. Marvell Berlin2 (BG2, BG2CD, BG2Q) +SoCs share the same IP for PLLs and clocks, with some minor differences in +features and register layout. + +Required properties: +- #clock-cells: shall be set to 1 +- clocks: clock specifiers referencing the core clock input clocks +- clock-names: array of strings describing the input clock specifiers above. + Allowed clock-names for the reference clocks are + "refclk" for the SoCs osciallator input on all SoCs, + and SoC-specific input clocks for + BG2/BG2CD: "video_ext0" for the external video clock input + +Clocks provided by core clocks shall be referenced by a clock specifier +indexing one of the provided clocks. Refer to dt-bindings/clock/berlin<soc>.h +for the corresponding index mapping. + +* Pin controller binding + +Pin control registers are part of both register sets, chip control and system +control. The pins controlled are organized in groups, so no actual pin +information is needed. + +A pin-controller node should contain subnodes representing the pin group +configurations, one per function. Each subnode has the group name and the muxing +function used. + +Be aware the Marvell Berlin datasheets use the keyword 'mode' for what is called +a 'function' in the pin-controller subsystem. + +Required subnode-properties: +- groups: a list of strings describing the group names. +- function: a string describing the function used to mux the groups. + +Example: + +chip: chip-control@ea0000 { + compatible = "marvell,berlin2-chip-ctrl"; + #clock-cells = <1>; + reg = <0xea0000 0x400>; + clocks = <&refclk>, <&externaldev 0>; + clock-names = "refclk", "video_ext0"; + + spi1_pmux: spi1-pmux { + groups = "G0"; + function = "spi1"; + }; +}; + +sysctrl: system-controller@d000 { + compatible = "marvell,berlin2-system-ctrl"; + reg = <0xd000 0x100>; + + uart0_pmux: uart0-pmux { + groups = "GSM4"; + function = "uart0"; + }; + + uart1_pmux: uart1-pmux { + groups = "GSM5"; + function = "uart1"; + }; + + uart2_pmux: uart2-pmux { + groups = "GSM3"; + function = "uart2"; + }; +}; diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt new file mode 100644 index 0000000..925ecbf --- /dev/null +++ b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt @@ -0,0 +1,97 @@ +Marvell Kirkwood SoC Family Device Tree Bindings +------------------------------------------------ + +Boards with a SoC of the Marvell Kirkwook family, eg 88f6281 + +* Required root node properties: +compatible: must contain "marvell,kirkwood" + +In addition, the above compatible shall be extended with the specific +SoC. Currently known SoC compatibles are: + +"marvell,kirkwood-88f6192" +"marvell,kirkwood-88f6281" +"marvell,kirkwood-88f6282" +"marvell,kirkwood-88f6283" +"marvell,kirkwood-88f6702" +"marvell,kirkwood-98DX4122" + +And in addition, the compatible shall be extended with the specific +board. Currently known boards are: + +"buffalo,lschlv2" +"buffalo,lsxhl" +"buffalo,lsxl" +"dlink,dns-320" +"dlink,dns-320-a1" +"dlink,dns-325" +"dlink,dns-325-a1" +"dlink,dns-kirkwood" +"excito,b3" +"globalscale,dreamplug-003-ds2001" +"globalscale,guruplug" +"globalscale,guruplug-server-plus" +"globalscale,sheevaplug" +"globalscale,sheevaplug" +"globalscale,sheevaplug-esata" +"globalscale,sheevaplug-esata-rev13" +"iom,iconnect" +"iom,iconnect-1.1" +"iom,ix2-200" +"keymile,km_kirkwood" +"lacie,cloudbox" +"lacie,inetspace_v2" +"lacie,laplug" +"lacie,netspace_lite_v2" +"lacie,netspace_max_v2" +"lacie,netspace_mini_v2" +"lacie,netspace_v2" +"marvell,db-88f6281-bp" +"marvell,db-88f6282-bp" +"marvell,mv88f6281gtw-ge" +"marvell,rd88f6281" +"marvell,rd88f6281" +"marvell,rd88f6281-a0" +"marvell,rd88f6281-a1" +"mpl,cec4" +"mpl,cec4-10" +"netgear,readynas" +"netgear,readynas" +"netgear,readynas-duo-v2" +"netgear,readynas-nv+-v2" +"plathome,openblocks-a6" +"plathome,openblocks-a7" +"raidsonic,ib-nas6210" +"raidsonic,ib-nas6210-b" +"raidsonic,ib-nas6220" +"raidsonic,ib-nas6220-b" +"raidsonic,ib-nas62x0" +"seagate,dockstar" +"seagate,goflexnet" +"synology,ds109" +"synology,ds110jv10" +"synology,ds110jv20" +"synology,ds110jv30" +"synology,ds111" +"synology,ds209" +"synology,ds210jv10" +"synology,ds210jv20" +"synology,ds212" +"synology,ds212jv10" +"synology,ds212jv20" +"synology,ds212pv10" +"synology,ds409" +"synology,ds409slim" +"synology,ds410j" +"synology,ds411" +"synology,ds411j" +"synology,ds411slim" +"synology,ds413jv10" +"synology,rs212" +"synology,rs409" +"synology,rs411" +"synology,rs812" +"usi,topkick" +"usi,topkick-1281P2" +"zyxel,nsa310" +"zyxel,nsa310a" diff --git a/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt b/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt new file mode 100644 index 0000000..0d244b9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt @@ -0,0 +1,16 @@ +* Marvell Feroceon Cache + +Required properties: +- compatible : Should be either "marvell,feroceon-cache" or + "marvell,kirkwood-cache". + +Optional properties: +- reg : Address of the L2 cache control register. Mandatory for + "marvell,kirkwood-cache", not used by "marvell,feroceon-cache" + + +Example: + l2: l2-cache@20128 { + compatible = "marvell,kirkwood-cache"; + reg = <0x20128 0x4>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt new file mode 100644 index 0000000..1333db9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt @@ -0,0 +1,30 @@ +Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) + +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU. +There is one ACC register region per CPU within the KPSS remapped region as +well as an alias register region that remaps accesses to the ACC associated +with the CPU accessing the region. + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: should be one of: + "qcom,kpss-acc-v1" + "qcom,kpss-acc-v2" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the first element specifies the base address and size of + the register region. An optional second element specifies + the base address and size of the alias register region. + +Example: + + clock-controller@2088000 { + compatible = "qcom,kpss-acc-v2"; + reg = <0x02088000 0x1000>, + <0x02008000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt new file mode 100644 index 0000000..1505fb8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt @@ -0,0 +1,35 @@ +SPM AVS Wrapper 2 (SAW2) + +The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the +Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable +micro-controller that transitions a piece of hardware (like a processor or +subsystem) into and out of low power modes via a direct connection to +the PMIC. It can also be wired up to interact with other processors in the +system, notifying them when a low power state is entered or exited. + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: shall contain "qcom,saw2". A more specific value should be + one of: + "qcom,saw2-v1" + "qcom,saw2-v1.1" + "qcom,saw2-v2" + "qcom,saw2-v2.1" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the first element specifies the base address and size of + the register region. An optional second element specifies + the base address and size of the alias register region. + + +Example: + + regulator@2099000 { + compatible = "qcom,saw2"; + reg = <0x02099000 0x1000>, <0x02009000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt index 081c6a7..d24ab2e 100644 --- a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt @@ -1,12 +1,13 @@ MVEBU System Controller ----------------------- -MVEBU (Marvell SOCs: Armada 370/XP, Dove, mv78xx0, Kirkwood, Orion5x) +MVEBU (Marvell SOCs: Armada 370/375/XP, Dove, mv78xx0, Kirkwood, Orion5x) Required properties: - compatible: one of: - "marvell,orion-system-controller" - "marvell,armada-370-xp-system-controller" + - "marvell,armada-375-system-controller" - reg: Should contain system controller registers location and length. Example: diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt new file mode 100644 index 0000000..4139db3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt @@ -0,0 +1,63 @@ +Some socs have a large number of interrupts requests to service +the needs of its many peripherals and subsystems. All of the +interrupt lines from the subsystems are not needed at the same +time, so they have to be muxed to the irq-controller appropriately. +In such places a interrupt controllers are preceded by an CROSSBAR +that provides flexibility in muxing the device requests to the controller +inputs. + +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 + crossbar. These interrupt lines are reserved in the soc, + 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/omap/dmm.txt b/Documentation/devicetree/bindings/arm/omap/dmm.txt new file mode 100644 index 0000000..8bd6d0a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt @@ -0,0 +1,22 @@ +OMAP Dynamic Memory Manager (DMM) bindings + +The dynamic memory manager (DMM) is a module located immediately in front of the +SDRAM controllers (called EMIFs on OMAP). DMM manages various aspects of memory +accesses such as priority generation amongst initiators, configuration of SDRAM +interleaving, optimizing transfer of 2D block objects, and provide MMU-like page +translation for initiators which need contiguous dma bus addresses. + +Required properties: +- compatible: Should contain "ti,omap4-dmm" for OMAP4 family + Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family +- reg: Contains DMM register address range (base address and length) +- interrupts: Should contain an interrupt-specifier for DMM_IRQ. +- ti,hwmods: Name of the hwmod associated to DMM, which is typically "dmm" + +Example: + +dmm@4e000000 { + compatible = "ti,omap4-dmm"; + reg = <0x4e000000 0x800>; + ti,hwmods = "dmm"; +}; diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt index c0105de..974624e 100644 --- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt +++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt @@ -6,6 +6,8 @@ provided by Arteris. Required properties: - compatible : Should be "ti,omap3-l3-smx" for OMAP3 family Should be "ti,omap4-l3-noc" for OMAP4 family + Should be "ti,dra7-l3-noc" for DRA7 family + Should be "ti,am4372-l3-noc" for AM43 family - reg: Contains L3 register address range for each noc domain. - ti,hwmods: "l3_main_1", ... One hwmod for each noc domain. diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index aa719623..d22b216 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -80,7 +80,10 @@ SoCs: compatible = "ti,omap5432", "ti,omap5" - DRA742 - compatible = "ti,dra7xx", "ti,dra7" + compatible = "ti,dra742", "ti,dra74", "ti,dra7" + +- DRA722 + compatible = "ti,dra722", "ti,dra72", "ti,dra7" - AM4372 compatible = "ti,am4372", "ti,am43" @@ -99,6 +102,15 @@ Boards: - OMAP4 PandaBoard : Low cost community board compatible = "ti,omap4-panda", "ti,omap4430" +- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board + compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4"; + +- OMAP4 VAR-STK-OM44 : Commercial dev kit with VAR-OM44CustomBoard and VAR-SOM-OM44 w/WLAN + compatible = "variscite,var-stk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4"; + +- OMAP4 VAR-DVK-OM44 : Commercial dev kit with VAR-OM44CustomBoard, VAR-SOM-OM44 w/WLAN and LCD touchscreen + compatible = "variscite,var-dvk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4"; + - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x compatible = "ti,omap3-evm", "ti,omap3" @@ -114,5 +126,11 @@ Boards: - AM43x EPOS EVM compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43" -- DRA7 EVM: Software Development Board for DRA7XX - compatible = "ti,dra7-evm", "ti,dra7" +- AM437x GP EVM + compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43" + +- DRA742 EVM: Software Development Board for DRA742 + compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7" + +- DRA722 EVM: Software Development Board for DRA722 + compatible = "ti,dra72-evm", "ti,dra722", "ti,dra72", "ti,dra7" diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt index 3e1e498..75ef91d 100644 --- a/Documentation/devicetree/bindings/arm/pmu.txt +++ b/Documentation/devicetree/bindings/arm/pmu.txt @@ -8,7 +8,9 @@ Required properties: - compatible : should be one of "arm,armv8-pmuv3" + "arm,cortex-a17-pmu" "arm,cortex-a15-pmu" + "arm,cortex-a12-pmu" "arm,cortex-a9-pmu" "arm,cortex-a8-pmu" "arm,cortex-a7-pmu" @@ -16,7 +18,14 @@ Required properties: "arm,arm11mpcore-pmu" "arm,arm1176-pmu" "arm,arm1136-pmu" -- interrupts : 1 combined interrupt or 1 per core. + "qcom,krait-pmu" +- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu + interrupt (PPI) then 1 interrupt should be specified. + +Optional properties: + +- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd + events. Example: diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt index 433afe9..b4a58f3 100644 --- a/Documentation/devicetree/bindings/arm/psci.txt +++ b/Documentation/devicetree/bindings/arm/psci.txt @@ -21,7 +21,15 @@ to #0. Main node required properties: - - compatible : Must be "arm,psci" + - compatible : should contain at least one of: + + * "arm,psci" : for implementations complying to PSCI versions prior to + 0.2. For these cases function IDs must be provided. + + * "arm,psci-0.2" : for implementations complying to PSCI 0.2. Function + IDs are not required and should be ignored by an OS with PSCI 0.2 + support, but are permitted to be present for compatibility with + existing software when "arm,psci" is later in the compatible list. - method : The method of calling the PSCI firmware. Permitted values are: @@ -45,6 +53,8 @@ Main node optional properties: Example: +Case 1: PSCI v0.1 only. + psci { compatible = "arm,psci"; method = "smc"; @@ -53,3 +63,28 @@ Example: cpu_on = <0x95c10002>; migrate = <0x95c10003>; }; + + +Case 2: PSCI v0.2 only + + psci { + compatible = "arm,psci-0.2"; + method = "smc"; + }; + +Case 3: PSCI v0.2 and PSCI v0.1. + + A DTB may provide IDs for use by kernels without PSCI 0.2 support, + enabling firmware and hypervisors to support existing and new kernels. + These IDs will be ignored by kernels with PSCI 0.2 support, which will + use the standard PSCI 0.2 IDs exclusively. + + psci { + compatible = "arm,psci-0.2", "arm,psci"; + method = "hvc"; + + cpu_on = < arbitrary value >; + cpu_off = < arbitrary value >; + + ... + }; diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt new file mode 100644 index 0000000..857f126 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -0,0 +1,10 @@ +Rockchip platforms device tree bindings +--------------------------------------- + +- bq Curie 2 tablet: + Required root node properties: + - compatible = "mundoreader,bq-curie2", "rockchip,rk3066a"; + +- Radxa Rock board: + Required root node properties: + - compatible = "radxa,rock", "rockchip,rk3188"; diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.txt b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt new file mode 100644 index 0000000..3ee9b42 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt @@ -0,0 +1,16 @@ +Rockchip power-management-unit: +------------------------------- + +The pmu is used to turn off and on different power domains of the SoCs +This includes the power to the CPU cores. + +Required node properties: +- compatible value : = "rockchip,rk3066-pmu"; +- reg : physical base address and the size of the registers window + +Example: + + pmu@20004000 { + compatible = "rockchip,rk3066-pmu"; + reg = <0x20004000 0x100>; + }; diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt new file mode 100644 index 0000000..d9416fb --- /dev/null +++ b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt @@ -0,0 +1,30 @@ +Rockchip SRAM for smp bringup: +------------------------------ + +Rockchip's smp-capable SoCs use the first part of the sram for the bringup +of the cores. Once the core gets powered up it executes the code that is +residing at the very beginning of the sram. + +Therefore a reserved section sub-node has to be added to the mmio-sram +declaration. + +Required sub-node properties: +- compatible : should be "rockchip,rk3066-smp-sram" + +The rest of the properties should follow the generic mmio-sram discription +found in ../../misc/sram.txt + +Example: + + sram: sram@10080000 { + compatible = "mmio-sram"; + reg = <0x10080000 0x10000>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + smp-sram@10080000 { + compatible = "rockchip,rk3066-smp-sram"; + reg = <0x10080000 0x50>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt index 5d49f2b..adc61b0 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 @@ -48,7 +69,7 @@ adc@12D10000 { /* NTC thermistor is a hwmon device */ ncp15wb473@0 { - compatible = "ntc,ncp15wb473"; + compatible = "murata,ncp15wb473"; pullup-uv = <1800000>; pullup-ohm = <47000>; pulldown-ohm = <0>; diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt new file mode 100644 index 0000000..f9865e7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt @@ -0,0 +1,49 @@ +SAMSUNG Exynos SoC series PMU Registers + +Properties: + - compatible : should contain two values. First value must be one from following list: + - "samsung,exynos3250-pmu" - for Exynos3250 SoC, + - "samsung,exynos4210-pmu" - for Exynos4210 SoC, + - "samsung,exynos4212-pmu" - for Exynos4212 SoC, + - "samsung,exynos4412-pmu" - for Exynos4412 SoC, + - "samsung,exynos5250-pmu" - for Exynos5250 SoC, + - "samsung,exynos5420-pmu" - for Exynos5420 SoC. + second value must be always "syscon". + + - 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/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt index 0ab3251..4fced6e 100644 --- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt +++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt @@ -1,8 +1,10 @@ SAMSUNG S5P/Exynos SoC series System Registers (SYSREG) Properties: - - compatible : should contain "samsung,<chip name>-sysreg", "syscon"; - For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon"; + - compatible : should contain two values. First value must be one from following list: + - "samsung,exynos4-sysreg" - for Exynos4 based SoCs, + - "samsung,exynos5-sysreg" - for Exynos5 based SoCs. + second value must be always "syscon". - reg : offset and length of the register set. Example: @@ -10,3 +12,8 @@ Example: compatible = "samsung,exynos4-sysreg", "syscon"; reg = <0x10010000 0x400>; }; + + syscon@10050000 { + compatible = "samsung,exynos5-sysreg", "syscon"; + reg = <0x10050000 0x5000>; + }; diff --git a/Documentation/devicetree/bindings/arm/sti.txt b/Documentation/devicetree/bindings/arm/sti.txt new file mode 100644 index 0000000..92f16c7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/sti.txt @@ -0,0 +1,15 @@ +ST STi Platforms Device Tree Bindings +--------------------------------------- + +Boards with the ST STiH415 SoC shall have the following properties: +Required root node property: +compatible = "st,stih415"; + +Boards with the ST STiH416 SoC shall have the following properties: +Required root node property: +compatible = "st,stih416"; + +Boards with the ST STiH407 SoC shall have the following properties: +Required root node property: +compatible = "st,stih407"; + diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt index 4aa20e7..1061faf 100644 --- a/Documentation/devicetree/bindings/arm/topology.txt +++ b/Documentation/devicetree/bindings/arm/topology.txt @@ -75,9 +75,10 @@ The cpu-map node can only contain three types of child nodes: whose bindings are described in paragraph 3. -The nodes describing the CPU topology (cluster/core/thread) can only be -defined within the cpu-map node. -Any other configuration is consider invalid and therefore must be ignored. +The nodes describing the CPU topology (cluster/core/thread) can only +be defined within the cpu-map node and every core/thread in the system +must be defined within the topology. Any other configuration is +invalid and therefore must be ignored. =========================================== 2.1 - cpu-map child nodes naming convention diff --git a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt index 5580e9c..00318d0 100644 --- a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt +++ b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt @@ -8,6 +8,8 @@ interrupt generation, MMC and NOR Flash control etc. Required node properties: - compatible value : = "arm,vexpress,sysreg"; - reg : physical base address and the size of the registers window + +Deprecated properties, replaced by GPIO subnodes (see below): - gpio-controller : specifies that the node is a GPIO controller - #gpio-cells : size of the GPIO specifier, should be 2: - first cell is the pseudo-GPIO line number: @@ -16,35 +18,86 @@ Required node properties: 2 - NOR FLASH WPn - second cell can take standard GPIO flags (currently ignored). +Control registers providing pseudo-GPIO lines must be represented +by subnodes, each of them requiring the following properties: +- compatible value : one of + "arm,vexpress-sysreg,sys_led" + "arm,vexpress-sysreg,sys_mci" + "arm,vexpress-sysreg,sys_flash" +- gpio-controller : makes the node a GPIO controller +- #gpio-cells : size of the GPIO specifier, must be 2: + - first cell is the function number: + - for sys_led : 0..7 = LED 0..7 + - for sys_mci : 0 = MMC CARDIN, 1 = MMC WPROT + - for sys_flash : 0 = NOR FLASH WPn + - second cell can take standard GPIO flags (currently ignored). + Example: v2m_sysreg: sysreg@10000000 { compatible = "arm,vexpress-sysreg"; reg = <0x10000000 0x1000>; - gpio-controller; - #gpio-cells = <2>; + + v2m_led_gpios: sys_led@08 { + compatible = "arm,vexpress-sysreg,sys_led"; + gpio-controller; + #gpio-cells = <2>; + }; + + v2m_mmc_gpios: sys_mci@48 { + compatible = "arm,vexpress-sysreg,sys_mci"; + gpio-controller; + #gpio-cells = <2>; + }; + + v2m_flash_gpios: sys_flash@4c { + compatible = "arm,vexpress-sysreg,sys_flash"; + gpio-controller; + #gpio-cells = <2>; + }; }; This block also can also act a bridge to the platform's configuration bus via "system control" interface, addressing devices with site number, position in the board stack, config controller, function and device -numbers - see motherboard's TRM for more details. - -The node describing a config device must refer to the sysreg node via -"arm,vexpress,config-bridge" phandle (can be also defined in the node's -parent) and relies on the board topology properties - see main vexpress -node documentation for more details. It must also define the following -property: -- arm,vexpress-sysreg,func : must contain two cells: - - first cell defines function number (eg. 1 for clock generator, - 2 for voltage regulators etc.) - - device number (eg. osc 0, osc 1 etc.) +numbers - see motherboard's TRM for more details. All configuration +controller accessible via this interface must reference the sysreg +node via "arm,vexpress,config-bridge" phandle and define appropriate +topology properties - see main vexpress node documentation for more +details. Each child of such node describes one function and must +define the following properties: +- compatible value : must be one of (corresponding to the TRM): + "arm,vexpress-amp" + "arm,vexpress-dvimode" + "arm,vexpress-energy" + "arm,vexpress-muxfpga" + "arm,vexpress-osc" + "arm,vexpress-power" + "arm,vexpress-reboot" + "arm,vexpress-reset" + "arm,vexpress-scc" + "arm,vexpress-shutdown" + "arm,vexpress-temp" + "arm,vexpress-volt" +- arm,vexpress-sysreg,func : must contain a set of two cells long groups: + - first cell of each group defines the function number + (eg. 1 for clock generator, 2 for voltage regulators etc.) + - second cell of each group defines device number (eg. osc 0, + osc 1 etc.) + - some functions (eg. energy meter, with its 64 bit long counter) + are using more than one function/device number pair Example: mcc { + compatible = "arm,vexpress,config-bus"; arm,vexpress,config-bridge = <&v2m_sysreg>; osc@0 { compatible = "arm,vexpress-osc"; arm,vexpress-sysreg,func = <1 0>; }; + + energy@0 { + compatible = "arm,vexpress-energy"; + arm,vexpress-sysreg,func = <13 0>, <13 1>; + }; }; diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt b/Documentation/devicetree/bindings/arm/vexpress.txt index ae49161..39844cd 100644 --- a/Documentation/devicetree/bindings/arm/vexpress.txt +++ b/Documentation/devicetree/bindings/arm/vexpress.txt @@ -80,12 +80,17 @@ but also control clock generators, voltage regulators, gather environmental data like temperature, power consumption etc. Even the video output switch (FPGA) is controlled that way. -Nodes describing devices controlled by this infrastructure should -point at the bridge device node: +The controllers are not mapped into normal memory address space +and must be accessed through bridges - other devices capable +of generating transactions on the configuration bus. + +The nodes describing configuration controllers must define +the following properties: +- compatible value: + compatible = "arm,vexpress,config-bus"; - bridge phandle: arm,vexpress,config-bridge = <phandle>; -This property can be also defined in a parent node (eg. for a DCC) -and is effective for all children. +and children describing available functions. Platform topology @@ -197,7 +202,7 @@ Example of a VE tile description (simplified) }; dcc { - compatible = "simple-bus"; + compatible = "arm,vexpress,config-bus"; arm,vexpress,config-bridge = <&v2m_sysreg>; osc@0 { diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index 48b285f..4ab09f2 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -3,22 +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 list, one of "snps,spear-ahci", - "snps,exynos5440-ahci", "ibm,476gtr-ahci", - "allwinner,sun4i-a10-ahci", "fsl,imx53-ahci" - "fsl,imx6q-ahci" or "snps,dwc-ahci" +- compatible : compatible string, one of: + - "allwinner,sun4i-a10-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 { @@ -34,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 0000000..0574a77 --- /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/apm-xgene.txt b/Documentation/devicetree/bindings/ata/apm-xgene.txt index 7bcfbf5..a668f0e 100644 --- a/Documentation/devicetree/bindings/ata/apm-xgene.txt +++ b/Documentation/devicetree/bindings/ata/apm-xgene.txt @@ -24,6 +24,7 @@ Required properties: * "sata-phy" for the SATA 6.0Gbps PHY Optional properties: +- dma-coherent : Present if dma operations are coherent - status : Shall be "ok" if enabled or "disabled" if disabled. Default is "ok". @@ -55,6 +56,7 @@ Example: <0x0 0x1f22e000 0x0 0x1000>, <0x0 0x1f227000 0x0 0x1000>; interrupts = <0x0 0x87 0x4>; + dma-coherent; status = "ok"; clocks = <&sataclk 0>; phys = <&phy2 0>; @@ -69,6 +71,7 @@ Example: <0x0 0x1f23e000 0x0 0x1000>, <0x0 0x1f237000 0x0 0x1000>; interrupts = <0x0 0x88 0x4>; + dma-coherent; status = "ok"; clocks = <&sataclk 0>; phys = <&phy3 0>; diff --git a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt b/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt deleted file mode 100644 index 37824fa..0000000 --- a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt +++ /dev/null @@ -1,14 +0,0 @@ -* Samsung 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 "samsung,exynos5-sata-phy" -- reg : <registers mapping> - -Example: - sata@ffe07000 { - compatible = "samsung,exynos5-sata-phy"; - reg = <0xffe07000 0x1000>; - }; diff --git a/Documentation/devicetree/bindings/ata/exynos-sata.txt b/Documentation/devicetree/bindings/ata/exynos-sata.txt index 0849f10..cb48448 100644 --- a/Documentation/devicetree/bindings/ata/exynos-sata.txt +++ b/Documentation/devicetree/bindings/ata/exynos-sata.txt @@ -4,14 +4,27 @@ SATA nodes are defined to describe on-chip Serial ATA controllers. Each SATA controller should have its own node. Required properties: -- compatible : compatible list, contains "samsung,exynos5-sata" -- interrupts : <interrupt mapping for SATA IRQ> -- reg : <registers mapping> -- samsung,sata-freq : <frequency in MHz> +- compatible : compatible list, contains "samsung,exynos5-sata" +- interrupts : <interrupt mapping for SATA IRQ> +- reg : <registers mapping> +- samsung,sata-freq : <frequency in MHz> +- phys : Must contain exactly one entry as specified + in phy-bindings.txt +- phy-names : Must be "sata-phy" + +Optional properties: +- clocks : Must contain an entry for each entry in clock-names. +- clock-names : Shall be "sata" for the external SATA bus clock, + and "sclk_sata" for the internal controller clock. Example: - sata@ffe08000 { - compatible = "samsung,exynos5-sata"; - reg = <0xffe08000 0x1000>; - interrupts = <115>; - }; + sata@122f0000 { + compatible = "snps,dwc-ahci"; + samsung,sata-freq = <66>; + reg = <0x122f0000 0x1ff>; + interrupts = <0 115 0>; + clocks = <&clock 277>, <&clock 143>; + clock-names = "sata", "sclk_sata"; + phys = <&sata_phy>; + phy-names = "sata-phy"; + }; diff --git a/Documentation/devicetree/bindings/ata/imx-sata.txt b/Documentation/devicetree/bindings/ata/imx-sata.txt new file mode 100644 index 0000000..fa511db --- /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 0000000..946f207 --- /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/bus/brcm,gisb-arb.txt b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt new file mode 100644 index 0000000..e2d501d --- /dev/null +++ b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt @@ -0,0 +1,30 @@ +Broadcom GISB bus Arbiter controller + +Required properties: + +- compatible: should be "brcm,gisb-arb" +- reg: specifies the base physical address and size of the registers +- interrupt-parent: specifies the phandle to the parent interrupt controller + this arbiter gets interrupt line from +- interrupts: specifies the two interrupts (timeout and TEA) to be used from + the parent interrupt controller + +Optional properties: + +- brcm,gisb-arb-master-mask: 32-bits wide bitmask used to specify which GISB + masters are valid at the system level +- brcm,gisb-arb-master-names: string list of the litteral name of the GISB + masters. Should match the number of bits set in brcm,gisb-master-mask and + the order in which they appear + +Example: + +gisb-arb@f0400000 { + compatible = "brcm,gisb-arb"; + reg = <0xf0400000 0x800>; + interrupts = <0>, <2>; + interrupt-parent = <&sun_l2_intc>; + + brcm,gisb-arb-master-mask = <0x7>; + brcm,gisb-arb-master-names = "bsp_0", "scpu_0", "cpu_0"; +}; diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt index 0fd76c4..6630d84 100644 --- a/Documentation/devicetree/bindings/bus/imx-weim.txt +++ b/Documentation/devicetree/bindings/bus/imx-weim.txt @@ -8,7 +8,12 @@ The actual devices are instantiated from the child nodes of a WEIM node. Required properties: - - compatible: Should be set to "fsl,<soc>-weim" + - compatible: Should contain one of the following: + "fsl,imx1-weim" + "fsl,imx27-weim" + "fsl,imx51-weim" + "fsl,imx50-weim" + "fsl,imx6q-weim" - reg: A resource specifier for the register space (see the example below) - clocks: the clock, see the example below. @@ -19,6 +24,26 @@ Required properties: <cs-number> 0 <physical address of mapping> <size> +Optional properties: + + - fsl,weim-cs-gpr: For "fsl,imx50-weim" and "fsl,imx6q-weim" type of + devices, it should be the phandle to the system General + Purpose Register controller that contains WEIM CS GPR + register, e.g. IOMUXC_GPR1 on i.MX6Q. IOMUXC_GPR1[11:0] + should be set up as one of the following 4 possible + values depending on the CS space configuration. + + IOMUXC_GPR1[11:0] CS0 CS1 CS2 CS3 + --------------------------------------------- + 05 128M 0M 0M 0M + 033 64M 64M 0M 0M + 0113 64M 32M 32M 0M + 01111 32M 32M 32M 32M + + In case that the property is absent, the reset value or + what bootloader sets up in IOMUXC_GPR1[11:0] will be + used. + Timing property for child nodes. It is mandatory, not optional. - fsl,weim-cs-timing: The timing array, contains timing values for the @@ -43,6 +68,7 @@ Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM: #address-cells = <2>; #size-cells = <1>; ranges = <0 0 0x08000000 0x08000000>; + fsl,weim-cs-gpr = <&gpr>; nor@0,0 { compatible = "cfi-flash"; diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt index 0045433..f72e80e 100644 --- a/Documentation/devicetree/bindings/clock/altr_socfpga.txt +++ b/Documentation/devicetree/bindings/clock/altr_socfpga.txt @@ -21,5 +21,10 @@ Optional properties: - fixed-divider : If clocks have a fixed divider value, use this property. - clk-gate : For "socfpga-gate-clk", clk-gate contains the gating register and the bit index. -- div-reg : For "socfpga-gate-clk", div-reg contains the divider register, bit shift, - and width. +- div-reg : For "socfpga-gate-clk" and "socfpga-periph-clock", div-reg contains + the divider register, bit shift, and width. +- clk-phase : For the sdmmc_clk, contains the value of the clock phase that controls + the SDMMC CIU clock. The first value is the clk_sample(smpsel), and the second + value is the cclk_in_drv(drvsel). The clk-phase is used to enable the correct + hold/delay times that is needed for the SD/MMC CIU clock. The values of both + can be 0-315 degrees, in 45 degree increments. diff --git a/Documentation/devicetree/bindings/clock/arm-integrator.txt b/Documentation/devicetree/bindings/clock/arm-integrator.txt new file mode 100644 index 0000000..652914b --- /dev/null +++ b/Documentation/devicetree/bindings/clock/arm-integrator.txt @@ -0,0 +1,34 @@ +Clock bindings for ARM Integrator Core Module clocks + +Auxilary Oscillator Clock + +This is a configurable clock fed from a 24 MHz chrystal, +used for generating e.g. video clocks. It is located on the +core module and there is only one of these. + +This clock node *must* be a subnode of the core module, since +it obtains the base address for it's address range from its +parent node. + + +Required properties: +- compatible: must be "arm,integrator-cm-auxosc" +- #clock-cells: must be <0> + +Optional properties: +- clocks: parent clock(s) + +Example: + +core-module@10000000 { + xtal24mhz: xtal24mhz@24M { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <24000000>; + }; + auxosc: cm_aux_osc@25M { + #clock-cells = <0>; + compatible = "arm,integrator-cm-auxosc"; + clocks = <&xtal24mhz>; + }; +}; diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt index cd5e239..b3d544c 100644 --- a/Documentation/devicetree/bindings/clock/at91-clock.txt +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt @@ -6,6 +6,16 @@ This binding uses the common clock binding[1]. Required properties: - compatible : shall be one of the following: + "atmel,at91sam9x5-sckc": + at91 SCKC (Slow Clock Controller) + This node contains the slow clock definitions. + + "atmel,at91sam9x5-clk-slow-osc": + at91 slow oscillator + + "atmel,at91sam9x5-clk-slow-rc-osc": + at91 internal slow RC oscillator + "atmel,at91rm9200-pmc" or "atmel,at91sam9g45-pmc" or "atmel,at91sam9n12-pmc" or @@ -15,8 +25,18 @@ Required properties: All at91 specific clocks (clocks defined below) must be child node of the PMC node. + "atmel,at91sam9x5-clk-slow" (under sckc node) + or + "atmel,at91sam9260-clk-slow" (under pmc node): + at91 slow clk + + "atmel,at91rm9200-clk-main-osc" + "atmel,at91sam9x5-clk-main-rc-osc" + at91 main clk sources + + "atmel,at91sam9x5-clk-main" "atmel,at91rm9200-clk-main": - at91 main oscillator + at91 main clock "atmel,at91rm9200-clk-master" or "atmel,at91sam9x5-clk-master": @@ -54,6 +74,63 @@ Required properties: "atmel,at91sam9x5-clk-utmi": at91 utmi clock +Required properties for SCKC node: +- reg : defines the IO memory reserved for the SCKC. +- #size-cells : shall be 0 (reg is used to encode clk id). +- #address-cells : shall be 1 (reg is used to encode clk id). + + +For example: + sckc: sckc@fffffe50 { + compatible = "atmel,sama5d3-pmc"; + reg = <0xfffffe50 0x4> + #size-cells = <0>; + #address-cells = <1>; + + /* put at91 slow clocks here */ + }; + + +Required properties for internal slow RC oscillator: +- #clock-cells : from common clock binding; shall be set to 0. +- clock-frequency : define the internal RC oscillator frequency. + +Optional properties: +- clock-accuracy : define the internal RC oscillator accuracy. + +For example: + slow_rc_osc: slow_rc_osc { + compatible = "atmel,at91sam9x5-clk-slow-rc-osc"; + clock-frequency = <32768>; + clock-accuracy = <50000000>; + }; + +Required properties for slow oscillator: +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : shall encode the main osc source clk sources (see atmel datasheet). + +Optional properties: +- atmel,osc-bypass : boolean property. Set this when a clock signal is directly + provided on XIN. + +For example: + slow_osc: slow_osc { + compatible = "atmel,at91rm9200-clk-slow-osc"; + #clock-cells = <0>; + clocks = <&slow_xtal>; + }; + +Required properties for slow clock: +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : shall encode the slow clk sources (see atmel datasheet). + +For example: + clk32k: slck { + compatible = "atmel,at91sam9x5-clk-slow"; + #clock-cells = <0>; + clocks = <&slow_rc_osc &slow_osc>; + }; + Required properties for PMC node: - reg : defines the IO memory reserved for the PMC. - #size-cells : shall be 0 (reg is used to encode clk id). @@ -62,7 +139,7 @@ Required properties for PMC node: - interrupt-controller : tell that the PMC is an interrupt controller. - #interrupt-cells : must be set to 1. The first cell encodes the interrupt id, and reflect the bit position in the PMC_ER/DR/SR registers. - You can use the dt macros defined in dt-bindings/clk/at91.h. + You can use the dt macros defined in dt-bindings/clock/at91.h. 0 (AT91_PMC_MOSCS) -> main oscillator ready 1 (AT91_PMC_LOCKA) -> PLL A ready 2 (AT91_PMC_LOCKB) -> PLL B ready @@ -85,24 +162,57 @@ For example: /* put at91 clocks here */ }; +Required properties for main clock internal RC oscillator: +- interrupt-parent : must reference the PMC node. +- interrupts : shall be set to "<0>". +- clock-frequency : define the internal RC oscillator frequency. + +Optional properties: +- clock-accuracy : define the internal RC oscillator accuracy. + +For example: + main_rc_osc: main_rc_osc { + compatible = "atmel,at91sam9x5-clk-main-rc-osc"; + interrupt-parent = <&pmc>; + interrupts = <0>; + clock-frequency = <12000000>; + clock-accuracy = <50000000>; + }; + +Required properties for main clock oscillator: +- interrupt-parent : must reference the PMC node. +- interrupts : shall be set to "<0>". +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : shall encode the main osc source clk sources (see atmel datasheet). + +Optional properties: +- atmel,osc-bypass : boolean property. Specified if a clock signal is provided + on XIN. + + clock signal is directly provided on XIN pin. + +For example: + main_osc: main_osc { + compatible = "atmel,at91rm9200-clk-main-osc"; + interrupt-parent = <&pmc>; + interrupts = <0>; + #clock-cells = <0>; + clocks = <&main_xtal>; + }; + Required properties for main clock: - interrupt-parent : must reference the PMC node. - interrupts : shall be set to "<0>". - #clock-cells : from common clock binding; shall be set to 0. -- clocks (optional if clock-frequency is provided) : shall be the slow clock - phandle. This clock is used to calculate the main clock rate if - "clock-frequency" is not provided. -- clock-frequency : the main oscillator frequency.Prefer the use of - "clock-frequency" over automatic clock rate calculation. +- clocks : shall encode the main clk sources (see atmel datasheet). For example: main: mainck { - compatible = "atmel,at91rm9200-clk-main"; + compatible = "atmel,at91sam9x5-clk-main"; interrupt-parent = <&pmc>; interrupts = <0>; #clock-cells = <0>; - clocks = <&ck32k>; - clock-frequency = <18432000>; + clocks = <&main_rc_osc &main_osc>; }; Required properties for master clock: diff --git a/Documentation/devicetree/bindings/clock/axi-clkgen.txt b/Documentation/devicetree/bindings/clock/axi-clkgen.txt index 028b493..20e1704 100644 --- a/Documentation/devicetree/bindings/clock/axi-clkgen.txt +++ b/Documentation/devicetree/bindings/clock/axi-clkgen.txt @@ -5,7 +5,7 @@ This binding uses the common clock binding[1]. [1] Documentation/devicetree/bindings/clock/clock-bindings.txt Required properties: -- compatible : shall be "adi,axi-clkgen". +- compatible : shall be "adi,axi-clkgen-1.00.a" or "adi,axi-clkgen-2.00.a". - #clock-cells : from common clock binding; Should always be set to 0. - reg : Address and length of the axi-clkgen register set. - clocks : Phandle and clock specifier for the parent clock. diff --git a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt index 56d1f49..5286e26 100644 --- a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt +++ b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt @@ -10,12 +10,12 @@ This binding uses the common clock binding: Required properties: - compatible - Shall have one of the following values: - - "brcm,bcm11351-root-ccu" - - "brcm,bcm11351-aon-ccu" - - "brcm,bcm11351-hub-ccu" - - "brcm,bcm11351-master-ccu" - - "brcm,bcm11351-slave-ccu" + Shall have a value of the form "brcm,<model>-<which>-ccu", + where <model> is a Broadcom SoC model number and <which> is + the name of a defined CCU. For example: + "brcm,bcm11351-root-ccu" + The compatible strings used for each supported SoC family + are defined below. - reg Shall define the base and range of the address space containing clock control registers @@ -26,12 +26,48 @@ Required properties: Shall be an ordered list of strings defining the names of the clocks provided by the CCU. +Device tree example: + + slave_ccu: slave_ccu { + compatible = "brcm,bcm11351-slave-ccu"; + reg = <0x3e011000 0x0f00>; + #clock-cells = <1>; + clock-output-names = "uartb", + "uartb2", + "uartb3", + "uartb4"; + }; + + ref_crystal_clk: ref_crystal { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <26000000>; + }; + + uart@3e002000 { + compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; + status = "disabled"; + reg = <0x3e002000 0x1000>; + clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>; + interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>; + reg-shift = <2>; + reg-io-width = <4>; + }; + +BCM281XX family +--------------- +CCU compatible string values for SoCs in the BCM281XX family are: + "brcm,bcm11351-root-ccu" + "brcm,bcm11351-aon-ccu" + "brcm,bcm11351-hub-ccu" + "brcm,bcm11351-master-ccu" + "brcm,bcm11351-slave-ccu" -BCM281XX family SoCs use Kona CCUs. The following table defines -the set of CCUs and clock specifiers for BCM281XX clocks. When -a clock consumer references a clocks, its symbolic specifier -(rather than its numeric index value) should be used. These -specifiers are defined in "include/dt-bindings/clock/bcm281xx.h". +The following table defines the set of CCUs and clock specifiers for +BCM281XX family clocks. When a clock consumer references a clocks, +its symbolic specifier (rather than its numeric index value) should +be used. These specifiers are defined in: + "include/dt-bindings/clock/bcm281xx.h" CCU Clock Type Index Specifier --- ----- ---- ----- --------- @@ -64,30 +100,40 @@ specifiers are defined in "include/dt-bindings/clock/bcm281xx.h". slave pwm peri 9 BCM281XX_SLAVE_CCU_PWM -Device tree example: +BCM21664 family +--------------- +CCU compatible string values for SoCs in the BCM21664 family are: + "brcm,bcm21664-root-ccu" + "brcm,bcm21664-aon-ccu" + "brcm,bcm21664-master-ccu" + "brcm,bcm21664-slave-ccu" - slave_ccu: slave_ccu { - compatible = "brcm,bcm11351-slave-ccu"; - reg = <0x3e011000 0x0f00>; - #clock-cells = <1>; - clock-output-names = "uartb", - "uartb2", - "uartb3", - "uartb4"; - }; +The following table defines the set of CCUs and clock specifiers for +BCM21664 family clocks. When a clock consumer references a clocks, +its symbolic specifier (rather than its numeric index value) should +be used. These specifiers are defined in: + "include/dt-bindings/clock/bcm21664.h" - ref_crystal_clk: ref_crystal { - #clock-cells = <0>; - compatible = "fixed-clock"; - clock-frequency = <26000000>; - }; + CCU Clock Type Index Specifier + --- ----- ---- ----- --------- + root frac_1m peri 0 BCM21664_ROOT_CCU_FRAC_1M - uart@3e002000 { - compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart"; - status = "disabled"; - reg = <0x3e002000 0x1000>; - clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>; - interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - reg-io-width = <4>; - }; + aon hub_timer peri 0 BCM21664_AON_CCU_HUB_TIMER + + master sdio1 peri 0 BCM21664_MASTER_CCU_SDIO1 + master sdio2 peri 1 BCM21664_MASTER_CCU_SDIO2 + master sdio3 peri 2 BCM21664_MASTER_CCU_SDIO3 + master sdio4 peri 3 BCM21664_MASTER_CCU_SDIO4 + master sdio1_sleep peri 4 BCM21664_MASTER_CCU_SDIO1_SLEEP + master sdio2_sleep peri 5 BCM21664_MASTER_CCU_SDIO2_SLEEP + master sdio3_sleep peri 6 BCM21664_MASTER_CCU_SDIO3_SLEEP + master sdio4_sleep peri 7 BCM21664_MASTER_CCU_SDIO4_SLEEP + + slave uartb peri 0 BCM21664_SLAVE_CCU_UARTB + slave uartb2 peri 1 BCM21664_SLAVE_CCU_UARTB2 + slave uartb3 peri 2 BCM21664_SLAVE_CCU_UARTB3 + slave uartb4 peri 3 BCM21664_SLAVE_CCU_UARTB4 + slave bsc1 peri 4 BCM21664_SLAVE_CCU_BSC1 + slave bsc2 peri 5 BCM21664_SLAVE_CCU_BSC2 + slave bsc3 peri 6 BCM21664_SLAVE_CCU_BSC3 + slave bsc4 peri 7 BCM21664_SLAVE_CCU_BSC4 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 0000000..4208886 --- /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 7c52c29..06fc6d5 100644 --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt @@ -44,6 +44,22 @@ For example: clocks by index. The names should reflect the clock output signal names for the device. +clock-indices: If the identifying number for the clocks in the node + is not linear from zero, then this allows the mapping of + identifiers into the clock-output-names array. + +For example, if we have two clocks <&oscillator 1> and <&oscillator 3>: + + oscillator { + compatible = "myclocktype"; + #clock-cells = <1>; + clock-indices = <1>, <3>; + clock-output-names = "clka", "clkb"; + } + + This ensures we do not have any empty strings in clock-output-names + + ==Clock consumers== Required properties: @@ -115,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 0000000..ce5a747 --- /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/exynos3250-clock.txt b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt new file mode 100644 index 0000000..aadc9c5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt @@ -0,0 +1,41 @@ +* Samsung Exynos3250 Clock Controller + +The Exynos3250 clock controller generates and supplies clock to various +controllers within the Exynos3250 SoC. + +Required Properties: + +- compatible: should be one of the following. + - "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC. + +- reg: physical base address of the controller and length of memory mapped + region. + +- #clock-cells: should be 1. + +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 +dt-bindings/clock/exynos3250.h header and can be used in device +tree sources. + +Example 1: An example of a clock controller node is listed below. + + cmu: clock-controller@10030000 { + compatible = "samsung,exynos3250-cmu"; + reg = <0x10030000 0x20000>; + #clock-cells = <1>; + }; + +Example 2: UART controller node that consumes the clock generated by the clock + controller. Refer to the standard clock bindings for information + about 'clocks' and 'clock-names' property. + + serial@13800000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x13800000 0x100>; + interrupts = <0 109 0>; + clocks = <&cmu CLK_UART0>, <&cmu CLK_SCLK_UART0>; + clock-names = "uart", "clk_uart_baud0"; + }; diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt index a2ac2d9..f5a5b19 100644 --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt @@ -15,259 +15,12 @@ Required Properties: - #clock-cells: should be 1. -The following is the list of clocks generated by the controller. Each clock is -assigned an identifier and client nodes use this identifier to specify the -clock which they consume. Some of the clocks are available only on a particular -Exynos4 SoC and this is specified where applicable. - - - [Core Clocks] - - Clock ID SoC (if specific) - ----------------------------------------------- - - xxti 1 - xusbxti 2 - fin_pll 3 - fout_apll 4 - fout_mpll 5 - fout_epll 6 - fout_vpll 7 - sclk_apll 8 - sclk_mpll 9 - sclk_epll 10 - sclk_vpll 11 - arm_clk 12 - aclk200 13 - aclk100 14 - aclk160 15 - aclk133 16 - mout_mpll_user_t 17 Exynos4x12 - mout_mpll_user_c 18 Exynos4x12 - mout_core 19 - mout_apll 20 - - - [Clock Gate for Special Clocks] - - Clock ID SoC (if specific) - ----------------------------------------------- - - sclk_fimc0 128 - sclk_fimc1 129 - sclk_fimc2 130 - sclk_fimc3 131 - sclk_cam0 132 - sclk_cam1 133 - sclk_csis0 134 - sclk_csis1 135 - sclk_hdmi 136 - sclk_mixer 137 - sclk_dac 138 - sclk_pixel 139 - sclk_fimd0 140 - sclk_mdnie0 141 Exynos4412 - sclk_mdnie_pwm0 12 142 Exynos4412 - sclk_mipi0 143 - sclk_audio0 144 - sclk_mmc0 145 - sclk_mmc1 146 - sclk_mmc2 147 - sclk_mmc3 148 - sclk_mmc4 149 - sclk_sata 150 Exynos4210 - sclk_uart0 151 - sclk_uart1 152 - sclk_uart2 153 - sclk_uart3 154 - sclk_uart4 155 - sclk_audio1 156 - sclk_audio2 157 - sclk_spdif 158 - sclk_spi0 159 - sclk_spi1 160 - sclk_spi2 161 - sclk_slimbus 162 - sclk_fimd1 163 Exynos4210 - sclk_mipi1 164 Exynos4210 - sclk_pcm1 165 - sclk_pcm2 166 - sclk_i2s1 167 - sclk_i2s2 168 - sclk_mipihsi 169 Exynos4412 - sclk_mfc 170 - sclk_pcm0 171 - sclk_g3d 172 - sclk_pwm_isp 173 Exynos4x12 - sclk_spi0_isp 174 Exynos4x12 - sclk_spi1_isp 175 Exynos4x12 - sclk_uart_isp 176 Exynos4x12 - sclk_fimg2d 177 - - [Peripheral Clock Gates] - - Clock ID SoC (if specific) - ----------------------------------------------- - - fimc0 256 - fimc1 257 - fimc2 258 - fimc3 259 - csis0 260 - csis1 261 - jpeg 262 - smmu_fimc0 263 - smmu_fimc1 264 - smmu_fimc2 265 - smmu_fimc3 266 - smmu_jpeg 267 - vp 268 - mixer 269 - tvenc 270 Exynos4210 - hdmi 271 - smmu_tv 272 - mfc 273 - smmu_mfcl 274 - smmu_mfcr 275 - g3d 276 - g2d 277 - rotator 278 Exynos4210 - mdma 279 Exynos4210 - smmu_g2d 280 Exynos4210 - smmu_rotator 281 Exynos4210 - smmu_mdma 282 Exynos4210 - fimd0 283 - mie0 284 - mdnie0 285 Exynos4412 - dsim0 286 - smmu_fimd0 287 - fimd1 288 Exynos4210 - mie1 289 Exynos4210 - dsim1 290 Exynos4210 - smmu_fimd1 291 Exynos4210 - pdma0 292 - pdma1 293 - pcie_phy 294 - sata_phy 295 Exynos4210 - tsi 296 - sdmmc0 297 - sdmmc1 298 - sdmmc2 299 - sdmmc3 300 - sdmmc4 301 - sata 302 Exynos4210 - sromc 303 - usb_host 304 - usb_device 305 - pcie 306 - onenand 307 - nfcon 308 - smmu_pcie 309 - gps 310 - smmu_gps 311 - uart0 312 - uart1 313 - uart2 314 - uart3 315 - uart4 316 - i2c0 317 - i2c1 318 - i2c2 319 - i2c3 320 - i2c4 321 - i2c5 322 - i2c6 323 - i2c7 324 - i2c_hdmi 325 - tsadc 326 - spi0 327 - spi1 328 - spi2 329 - i2s1 330 - i2s2 331 - pcm0 332 - i2s0 333 - pcm1 334 - pcm2 335 - pwm 336 - slimbus 337 - spdif 338 - ac97 339 - modemif 340 - chipid 341 - sysreg 342 - hdmi_cec 343 - mct 344 - wdt 345 - rtc 346 - keyif 347 - audss 348 - mipi_hsi 349 Exynos4210 - mdma2 350 Exynos4210 - pixelasyncm0 351 - pixelasyncm1 352 - fimc_lite0 353 Exynos4x12 - fimc_lite1 354 Exynos4x12 - ppmuispx 355 Exynos4x12 - ppmuispmx 356 Exynos4x12 - fimc_isp 357 Exynos4x12 - fimc_drc 358 Exynos4x12 - fimc_fd 359 Exynos4x12 - mcuisp 360 Exynos4x12 - gicisp 361 Exynos4x12 - smmu_isp 362 Exynos4x12 - smmu_drc 363 Exynos4x12 - smmu_fd 364 Exynos4x12 - smmu_lite0 365 Exynos4x12 - smmu_lite1 366 Exynos4x12 - mcuctl_isp 367 Exynos4x12 - mpwm_isp 368 Exynos4x12 - i2c0_isp 369 Exynos4x12 - i2c1_isp 370 Exynos4x12 - mtcadc_isp 371 Exynos4x12 - pwm_isp 372 Exynos4x12 - wdt_isp 373 Exynos4x12 - uart_isp 374 Exynos4x12 - asyncaxim 375 Exynos4x12 - smmu_ispcx 376 Exynos4x12 - spi0_isp 377 Exynos4x12 - spi1_isp 378 Exynos4x12 - pwm_isp_sclk 379 Exynos4x12 - spi0_isp_sclk 380 Exynos4x12 - spi1_isp_sclk 381 Exynos4x12 - uart_isp_sclk 382 Exynos4x12 - tmu_apbif 383 - - [Mux Clocks] - - Clock ID SoC (if specific) - ----------------------------------------------- - - mout_fimc0 384 - mout_fimc1 385 - mout_fimc2 386 - mout_fimc3 387 - mout_cam0 388 - mout_cam1 389 - mout_csis0 390 - mout_csis1 391 - mout_g3d0 392 - mout_g3d1 393 - mout_g3d 394 - aclk400_mcuisp 395 Exynos4x12 - - [Div Clocks] - - Clock ID SoC (if specific) - ----------------------------------------------- - - div_isp0 450 Exynos4x12 - div_isp1 451 Exynos4x12 - div_mcuisp0 452 Exynos4x12 - div_mcuisp1 453 Exynos4x12 - div_aclk200 454 Exynos4x12 - div_aclk400_mcuisp 455 Exynos4x12 +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 +dt-bindings/clock/exynos4.h header and can be used in device +tree sources. Example 1: An example of a clock controller node is listed below. @@ -285,6 +38,6 @@ Example 2: UART controller node that consumes the clock generated by the clock compatible = "samsung,exynos4210-uart"; reg = <0x13820000 0x100>; interrupts = <0 54 0>; - clocks = <&clock 314>, <&clock 153>; + clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>; clock-names = "uart", "clk_uart_baud0"; }; diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt index 72ce617..536eacd 100644 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@ -13,163 +13,12 @@ Required Properties: - #clock-cells: should be 1. -The following is the list of clocks generated by the controller. Each clock is -assigned an identifier and client nodes use this identifier to specify the -clock which they consume. - - - [Core Clocks] - - Clock ID - ---------------------------- - - fin_pll 1 - - [Clock Gate for Special Clocks] - - Clock ID - ---------------------------- - - sclk_cam_bayer 128 - sclk_cam0 129 - sclk_cam1 130 - sclk_gscl_wa 131 - sclk_gscl_wb 132 - sclk_fimd1 133 - sclk_mipi1 134 - sclk_dp 135 - sclk_hdmi 136 - sclk_pixel 137 - sclk_audio0 138 - sclk_mmc0 139 - sclk_mmc1 140 - sclk_mmc2 141 - sclk_mmc3 142 - sclk_sata 143 - sclk_usb3 144 - sclk_jpeg 145 - sclk_uart0 146 - sclk_uart1 147 - sclk_uart2 148 - sclk_uart3 149 - sclk_pwm 150 - sclk_audio1 151 - sclk_audio2 152 - sclk_spdif 153 - sclk_spi0 154 - sclk_spi1 155 - sclk_spi2 156 - div_i2s1 157 - div_i2s2 158 - sclk_hdmiphy 159 - div_pcm0 160 - - - [Peripheral Clock Gates] - - Clock ID - ---------------------------- - - gscl0 256 - gscl1 257 - gscl2 258 - gscl3 259 - gscl_wa 260 - gscl_wb 261 - smmu_gscl0 262 - smmu_gscl1 263 - smmu_gscl2 264 - smmu_gscl3 265 - mfc 266 - smmu_mfcl 267 - smmu_mfcr 268 - rotator 269 - jpeg 270 - mdma1 271 - smmu_rotator 272 - smmu_jpeg 273 - smmu_mdma1 274 - pdma0 275 - pdma1 276 - sata 277 - usbotg 278 - mipi_hsi 279 - sdmmc0 280 - sdmmc1 281 - sdmmc2 282 - sdmmc3 283 - sromc 284 - usb2 285 - usb3 286 - sata_phyctrl 287 - sata_phyi2c 288 - uart0 289 - uart1 290 - uart2 291 - uart3 292 - uart4 293 - i2c0 294 - i2c1 295 - i2c2 296 - i2c3 297 - i2c4 298 - i2c5 299 - i2c6 300 - i2c7 301 - i2c_hdmi 302 - adc 303 - spi0 304 - spi1 305 - spi2 306 - i2s1 307 - i2s2 308 - pcm1 309 - pcm2 310 - pwm 311 - spdif 312 - ac97 313 - hsi2c0 314 - hsi2c1 315 - hs12c2 316 - hs12c3 317 - chipid 318 - sysreg 319 - pmu 320 - cmu_top 321 - cmu_core 322 - cmu_mem 323 - tzpc0 324 - tzpc1 325 - tzpc2 326 - tzpc3 327 - tzpc4 328 - tzpc5 329 - tzpc6 330 - tzpc7 331 - tzpc8 332 - tzpc9 333 - hdmi_cec 334 - mct 335 - wdt 336 - rtc 337 - tmu 338 - fimd1 339 - mie1 340 - dsim0 341 - dp 342 - mixer 343 - hdmi 344 - g2d 345 - mdma0 346 - smmu_mdma0 347 - - - [Clock Muxes] - - Clock ID - ---------------------------- - mout_hdmi 1024 +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 +dt-bindings/clock/exynos5250.h header and can be used in device +tree sources. Example 1: An example of a clock controller node is listed below. @@ -187,6 +36,6 @@ Example 2: UART controller node that consumes the clock generated by the clock compatible = "samsung,exynos4210-uart"; reg = <0x13820000 0x100>; interrupts = <0 54 0>; - clocks = <&clock 314>, <&clock 153>; + clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>; clock-names = "uart", "clk_uart_baud0"; }; diff --git a/Documentation/devicetree/bindings/clock/exynos5260-clock.txt b/Documentation/devicetree/bindings/clock/exynos5260-clock.txt new file mode 100644 index 0000000..5496b2f --- /dev/null +++ b/Documentation/devicetree/bindings/clock/exynos5260-clock.txt @@ -0,0 +1,190 @@ +* Samsung Exynos5260 Clock Controller + +Exynos5260 has 13 clock controllers which are instantiated +independently from the device-tree. These clock controllers +generate and supply clocks to various hardware blocks within +the SoC. + +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 +dt-bindings/clock/exynos5260-clk.h header and can be used in +device tree sources. + +External clocks: + +There are several clocks that are generated outside the SoC. It +is expected that they are defined using standard clock bindings +with following clock-output-names: + + - "fin_pll" - PLL input clock from XXTI + - "xrtcxti" - input clock from XRTCXTI + - "ioclk_pcm_extclk" - pcm external operation clock + - "ioclk_spdif_extclk" - spdif external operation clock + - "ioclk_i2s_cdclk" - i2s0 codec clock + +Phy clocks: + +There are several clocks which are generated by specific PHYs. +These clocks are fed into the clock controller and then routed to +the hardware blocks. These clocks are defined as fixed clocks in the +driver with following names: + + - "phyclk_dptx_phy_ch3_txd_clk" - dp phy clock for channel 3 + - "phyclk_dptx_phy_ch2_txd_clk" - dp phy clock for channel 2 + - "phyclk_dptx_phy_ch1_txd_clk" - dp phy clock for channel 1 + - "phyclk_dptx_phy_ch0_txd_clk" - dp phy clock for channel 0 + - "phyclk_hdmi_phy_tmds_clko" - hdmi phy tmds clock + - "phyclk_hdmi_phy_pixel_clko" - hdmi phy pixel clock + - "phyclk_hdmi_link_o_tmds_clkhi" - hdmi phy for hdmi link + - "phyclk_dptx_phy_o_ref_clk_24m" - dp phy reference clock + - "phyclk_dptx_phy_clk_div2" + - "phyclk_mipi_dphy_4l_m_rxclkesc0" + - "phyclk_usbhost20_phy_phyclock" - usb 2.0 phy clock + - "phyclk_usbhost20_phy_freeclk" + - "phyclk_usbhost20_phy_clk48mohci" + - "phyclk_usbdrd30_udrd30_pipe_pclk" + - "phyclk_usbdrd30_udrd30_phyclock" - usb 3.0 phy clock + +Required Properties for Clock Controller: + + - compatible: should be one of the following. + 1) "samsung,exynos5260-clock-top" + 2) "samsung,exynos5260-clock-peri" + 3) "samsung,exynos5260-clock-egl" + 4) "samsung,exynos5260-clock-kfc" + 5) "samsung,exynos5260-clock-g2d" + 6) "samsung,exynos5260-clock-mif" + 7) "samsung,exynos5260-clock-mfc" + 8) "samsung,exynos5260-clock-g3d" + 9) "samsung,exynos5260-clock-fsys" + 10) "samsung,exynos5260-clock-aud" + 11) "samsung,exynos5260-clock-isp" + 12) "samsung,exynos5260-clock-gscl" + 13) "samsung,exynos5260-clock-disp" + + - reg: physical base address of the controller and the length of + memory mapped region. + + - #clock-cells: should be 1. + + - clocks: list of clock identifiers which are fed as the input to + the given clock controller. Please refer the next section to find + the input clocks for a given controller. + + - clock-names: list of names of clocks which are fed as the input + to the given clock controller. + +Input clocks for top clock controller: + - fin_pll + - dout_mem_pll + - dout_bus_pll + - dout_media_pll + +Input clocks for peri clock controller: + - fin_pll + - ioclk_pcm_extclk + - ioclk_i2s_cdclk + - ioclk_spdif_extclk + - phyclk_hdmi_phy_ref_cko + - dout_aclk_peri_66 + - dout_sclk_peri_uart0 + - dout_sclk_peri_uart1 + - dout_sclk_peri_uart2 + - dout_sclk_peri_spi0_b + - dout_sclk_peri_spi1_b + - dout_sclk_peri_spi2_b + - dout_aclk_peri_aud + - dout_sclk_peri_spi0_b + +Input clocks for egl clock controller: + - fin_pll + - dout_bus_pll + +Input clocks for kfc clock controller: + - fin_pll + - dout_media_pll + +Input clocks for g2d clock controller: + - fin_pll + - dout_aclk_g2d_333 + +Input clocks for mif clock controller: + - fin_pll + +Input clocks for mfc clock controller: + - fin_pll + - dout_aclk_mfc_333 + +Input clocks for g3d clock controller: + - fin_pll + +Input clocks for fsys clock controller: + - fin_pll + - phyclk_usbhost20_phy_phyclock + - phyclk_usbhost20_phy_freeclk + - phyclk_usbhost20_phy_clk48mohci + - phyclk_usbdrd30_udrd30_pipe_pclk + - phyclk_usbdrd30_udrd30_phyclock + - dout_aclk_fsys_200 + +Input clocks for aud clock controller: + - fin_pll + - fout_aud_pll + - ioclk_i2s_cdclk + - ioclk_pcm_extclk + +Input clocks for isp clock controller: + - fin_pll + - dout_aclk_isp1_266 + - dout_aclk_isp1_400 + - mout_aclk_isp1_266 + +Input clocks for gscl clock controller: + - fin_pll + - dout_aclk_gscl_400 + - dout_aclk_gscl_333 + +Input clocks for disp clock controller: + - fin_pll + - phyclk_dptx_phy_ch3_txd_clk + - phyclk_dptx_phy_ch2_txd_clk + - phyclk_dptx_phy_ch1_txd_clk + - phyclk_dptx_phy_ch0_txd_clk + - phyclk_hdmi_phy_tmds_clko + - phyclk_hdmi_phy_ref_clko + - phyclk_hdmi_phy_pixel_clko + - phyclk_hdmi_link_o_tmds_clkhi + - phyclk_mipi_dphy_4l_m_txbyte_clkhs + - phyclk_dptx_phy_o_ref_clk_24m + - phyclk_dptx_phy_clk_div2 + - phyclk_mipi_dphy_4l_m_rxclkesc0 + - phyclk_hdmi_phy_ref_cko + - ioclk_spdif_extclk + - dout_aclk_peri_aud + - dout_aclk_disp_222 + - dout_sclk_disp_pixel + - dout_aclk_disp_333 + +Example 1: An example of a clock controller node is listed below. + + clock_mfc: clock-controller@11090000 { + compatible = "samsung,exynos5260-clock-mfc"; + clock = <&fin_pll>, <&clock_top TOP_DOUT_ACLK_MFC_333>; + clock-names = "fin_pll", "dout_aclk_mfc_333"; + reg = <0x11090000 0x10000>; + #clock-cells = <1>; + }; + +Example 2: UART controller node that consumes the clock generated by the + peri clock controller. Refer to the standard clock bindings for + information about 'clocks' and 'clock-names' property. + + serial@12C00000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x12C00000 0x100>; + interrupts = <0 146 0>; + clocks = <&clock_peri PERI_PCLK_UART0>, <&clock_peri PERI_SCLK_UART0>; + clock-names = "uart", "clk_uart_baud0"; + }; + diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt new file mode 100644 index 0000000..aeab635 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt @@ -0,0 +1,45 @@ +* Samsung Exynos5410 Clock Controller + +The Exynos5410 clock controller generates and supplies clock to various +controllers within the Exynos5410 SoC. + +Required Properties: + +- compatible: should be "samsung,exynos5410-clock" + +- reg: physical base address of the controller and length of memory mapped + region. + +- #clock-cells: should be 1. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/exynos5410.h header and can be used in device +tree sources. + +External clock: + +There is clock that is generated outside the SoC. It +is expected that it is defined using standard clock bindings +with following clock-output-name: + + - "fin_pll" - PLL input clock from XXTI + +Example 1: An example of a clock controller node is listed below. + + clock: clock-controller@0x10010000 { + compatible = "samsung,exynos5410-clock"; + reg = <0x10010000 0x30000>; + #clock-cells = <1>; + }; + +Example 2: UART controller node that consumes the clock generated by the clock + controller. Refer to the standard clock bindings for information + about 'clocks' and 'clock-names' property. + + serial@12C20000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x12C00000 0x100>; + interrupts = <0 51 0>; + clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>; + clock-names = "uart", "clk_uart_baud0"; + }; diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt index 458f347..d54f42c 100644 --- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt @@ -1,196 +1,25 @@ * Samsung Exynos5420 Clock Controller The Exynos5420 clock controller generates and supplies clock to various -controllers within the Exynos5420 SoC. +controllers within the Exynos5420 SoC and for the Exynos5800 SoC. Required Properties: - compatible: should be one of the following. - "samsung,exynos5420-clock" - controller compatible with Exynos5420 SoC. + - "samsung,exynos5800-clock" - controller compatible with Exynos5800 SoC. - reg: physical base address of the controller and length of memory mapped region. - #clock-cells: should be 1. -The following is the list of clocks generated by the controller. Each clock is -assigned an identifier and client nodes use this identifier to specify the -clock which they consume. +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. - - [Core Clocks] - - Clock ID - ---------------------------- - - fin_pll 1 - - [Clock Gate for Special Clocks] - - Clock ID - ---------------------------- - sclk_uart0 128 - sclk_uart1 129 - sclk_uart2 130 - sclk_uart3 131 - sclk_mmc0 132 - sclk_mmc1 133 - sclk_mmc2 134 - sclk_spi0 135 - sclk_spi1 136 - sclk_spi2 137 - sclk_i2s1 138 - sclk_i2s2 139 - sclk_pcm1 140 - sclk_pcm2 141 - sclk_spdif 142 - sclk_hdmi 143 - sclk_pixel 144 - sclk_dp1 145 - sclk_mipi1 146 - sclk_fimd1 147 - sclk_maudio0 148 - sclk_maupcm0 149 - sclk_usbd300 150 - sclk_usbd301 151 - sclk_usbphy300 152 - sclk_usbphy301 153 - sclk_unipro 154 - sclk_pwm 155 - sclk_gscl_wa 156 - sclk_gscl_wb 157 - sclk_hdmiphy 158 - - [Peripheral Clock Gates] - - Clock ID - ---------------------------- - - aclk66_peric 256 - uart0 257 - uart1 258 - uart2 259 - uart3 260 - i2c0 261 - i2c1 262 - i2c2 263 - i2c3 264 - i2c4 265 - i2c5 266 - i2c6 267 - i2c7 268 - i2c_hdmi 269 - tsadc 270 - spi0 271 - spi1 272 - spi2 273 - keyif 274 - i2s1 275 - i2s2 276 - pcm1 277 - pcm2 278 - pwm 279 - spdif 280 - i2c8 281 - i2c9 282 - i2c10 283 - aclk66_psgen 300 - chipid 301 - sysreg 302 - tzpc0 303 - tzpc1 304 - tzpc2 305 - tzpc3 306 - tzpc4 307 - tzpc5 308 - tzpc6 309 - tzpc7 310 - tzpc8 311 - tzpc9 312 - hdmi_cec 313 - seckey 314 - mct 315 - wdt 316 - rtc 317 - tmu 318 - tmu_gpu 319 - pclk66_gpio 330 - aclk200_fsys2 350 - mmc0 351 - mmc1 352 - mmc2 353 - sromc 354 - ufs 355 - aclk200_fsys 360 - tsi 361 - pdma0 362 - pdma1 363 - rtic 364 - usbh20 365 - usbd300 366 - usbd301 377 - aclk400_mscl 380 - mscl0 381 - mscl1 382 - mscl2 383 - smmu_mscl0 384 - smmu_mscl1 385 - smmu_mscl2 386 - aclk333 400 - mfc 401 - smmu_mfcl 402 - smmu_mfcr 403 - aclk200_disp1 410 - dsim1 411 - dp1 412 - hdmi 413 - aclk300_disp1 420 - fimd1 421 - smmu_fimd1 422 - aclk166 430 - mixer 431 - aclk266 440 - rotator 441 - mdma1 442 - smmu_rotator 443 - smmu_mdma1 444 - aclk300_jpeg 450 - jpeg 451 - jpeg2 452 - smmu_jpeg 453 - aclk300_gscl 460 - smmu_gscl0 461 - smmu_gscl1 462 - gscl_wa 463 - gscl_wb 464 - gscl0 465 - gscl1 466 - clk_3aa 467 - aclk266_g2d 470 - sss 471 - slim_sss 472 - mdma0 473 - aclk333_g2d 480 - g2d 481 - aclk333_432_gscl 490 - smmu_3aa 491 - smmu_fimcl0 492 - smmu_fimcl1 493 - smmu_fimcl3 494 - fimc_lite3 495 - aclk_g3d 500 - g3d 501 - smmu_mixer 502 - - Mux ID - ---------------------------- - - mout_hdmi 640 - - Divider ID - ---------------------------- - - dout_pixel 768 +All available clocks are defined as preprocessor macros in +dt-bindings/clock/exynos5420.h header and can be used in device +tree sources. Example 1: An example of a clock controller node is listed below. @@ -208,6 +37,6 @@ Example 2: UART controller node that consumes the clock generated by the clock compatible = "samsung,exynos4210-uart"; reg = <0x13820000 0x100>; interrupts = <0 54 0>; - clocks = <&clock 259>, <&clock 130>; + clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>; clock-names = "uart", "clk_uart_baud0"; }; diff --git a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt index 9955dc9..5f7005f 100644 --- a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt @@ -12,45 +12,12 @@ Required Properties: - #clock-cells: should be 1. -The following is the list of clocks generated by the controller. Each clock is -assigned an identifier and client nodes use this identifier to specify the -clock which they consume. - - - [Core Clocks] - - Clock ID - ---------------------------- - - xtal 1 - arm_clk 2 - - [Peripheral Clock Gates] - - Clock ID - ---------------------------- - - spi_baud 16 - pb0_250 17 - pr0_250 18 - pr1_250 19 - b_250 20 - b_125 21 - b_200 22 - sata 23 - usb 24 - gmac0 25 - cs250 26 - pb0_250_o 27 - pr0_250_o 28 - pr1_250_o 29 - b_250_o 30 - b_125_o 31 - b_200_o 32 - sata_o 33 - usb_o 34 - gmac0_o 35 - cs250_o 36 +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 +dt-bindings/clock/exynos5440.h header and can be used in device +tree sources. Example: An example of a clock controller node is listed below. diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.txt b/Documentation/devicetree/bindings/clock/fixed-clock.txt index 48ea0ad..0641a663 100644 --- a/Documentation/devicetree/bindings/clock/fixed-clock.txt +++ b/Documentation/devicetree/bindings/clock/fixed-clock.txt @@ -12,7 +12,6 @@ Required properties: Optional properties: - clock-accuracy : accuracy of clock in ppb (parts per billion). Should be a single cell. -- gpios : From common gpio binding; gpio connection to clock enable pin. - clock-output-names : From common clock binding. Example: diff --git a/Documentation/devicetree/bindings/clock/hi3620-clock.txt b/Documentation/devicetree/bindings/clock/hi3620-clock.txt index 4b71ab4..dad6269 100644 --- a/Documentation/devicetree/bindings/clock/hi3620-clock.txt +++ b/Documentation/devicetree/bindings/clock/hi3620-clock.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: should be one of the following. - "hisilicon,hi3620-clock" - controller compatible with Hi3620 SoC. + - "hisilicon,hi3620-mmc-clock" - controller specific for Hi3620 mmc. - reg: physical base address of the controller and length of memory mapped region. diff --git a/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt b/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt new file mode 100644 index 0000000..7894a64 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt @@ -0,0 +1,31 @@ +* Hisilicon Hix5hd2 Clock Controller + +The hix5hd2 clock controller generates and supplies clock to various +controllers within the hix5hd2 SoC. + +Required Properties: + +- compatible: should be "hisilicon,hix5hd2-clock" +- reg: Address and length of the register set +- #clock-cells: Should be <1> + +Each clock is assigned an identifier and client nodes use this identifier +to specify the clock which they consume. + +All these identifier could be found in <dt-bindings/clock/hix5hd2-clock.h>. + +Examples: + clock: clock@f8a22000 { + compatible = "hisilicon,hix5hd2-clock"; + reg = <0xf8a22000 0x1000>; + #clock-cells = <1>; + }; + + uart0: uart@f8b00000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0xf8b00000 0x1000>; + interrupts = <0 49 4>; + clocks = <&clock HIX5HD2_FIXED_83M>; + clock-names = "apb_pclk"; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.txt b/Documentation/devicetree/bindings/clock/imx25-clock.txt index db4f2f0..ba6b312 100644 --- a/Documentation/devicetree/bindings/clock/imx25-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx25-clock.txt @@ -139,6 +139,9 @@ clocks and IDs. uart5_ipg 124 reserved 125 wdt_ipg 126 + cko_div 127 + cko_sel 128 + cko 129 Examples: diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.txt b/Documentation/devicetree/bindings/clock/imx27-clock.txt index 7a20703..6bc9fd2 100644 --- a/Documentation/devicetree/bindings/clock/imx27-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx27-clock.txt @@ -98,7 +98,12 @@ clocks and IDs. fpm 83 mpll_osc_sel 84 mpll_sel 85 - spll_gate 86 + spll_gate 86 + mshc_div 87 + rtic_ipg_gate 88 + mshc_ipg_gate 89 + rtic_ahb_gate 90 + mshc_baud_gate 91 Examples: diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index 6aab72b..90ec91f 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt @@ -220,6 +220,7 @@ clocks and IDs. lvds2_sel 205 lvds1_gate 206 lvds2_gate 207 + esai_ahb 208 Examples: diff --git a/Documentation/devicetree/bindings/clock/imx6sx-clock.txt b/Documentation/devicetree/bindings/clock/imx6sx-clock.txt new file mode 100644 index 0000000..22362b9 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx6sx-clock.txt @@ -0,0 +1,13 @@ +* Clock bindings for Freescale i.MX6 SoloX + +Required properties: +- compatible: Should be "fsl,imx6sx-ccm" +- reg: Address and length of the register set +- #clock-cells: Should be <1> +- clocks: list of clock specifiers, must contain an entry for each required + entry in clock-names +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1" + +The clock consumer should specify the desired clock by having the clock +ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sx-clock.h +for the full list of i.MX6 SoloX clock IDs. diff --git a/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt b/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt new file mode 100644 index 0000000..3ce97cf --- /dev/null +++ b/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt @@ -0,0 +1,29 @@ +AXM5516 clock driver bindings +----------------------------- + +Required properties : +- compatible : shall contain "lsi,axm5516-clks" +- reg : shall contain base register location and length +- #clock-cells : shall contain 1 + +The consumer specifies the desired clock by having the clock ID in its "clocks" +phandle cell. See <dt-bindings/clock/lsi,axxia-clock.h> for the list of +supported clock IDs. + +Example: + + clks: clock-controller@2010020000 { + compatible = "lsi,axm5516-clks"; + #clock-cells = <1>; + reg = <0x20 0x10020000 0 0x20000>; + }; + + serial0: uart@2010080000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x20 0x10080000 0 0x1000>; + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks AXXIA_CLK_PER>; + clock-names = "apb_pclk"; + }; + }; + diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt new file mode 100644 index 0000000..fedea84 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt @@ -0,0 +1,48 @@ +Device Tree Clock bindings for arch-moxart + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +MOXA ART SoCs allow to determine PLL output and APB frequencies +by reading registers holding multiplier and divisor information. + + +PLL: + +Required properties: +- compatible : Must be "moxa,moxart-pll-clock" +- #clock-cells : Should be 0 +- reg : Should contain registers location and length +- clocks : Should contain phandle + clock-specifier for the parent clock + +Optional properties: +- clock-output-names : Should contain clock name + + +APB: + +Required properties: +- compatible : Must be "moxa,moxart-apb-clock" +- #clock-cells : Should be 0 +- reg : Should contain registers location and length +- clocks : Should contain phandle + clock-specifier for the parent clock + +Optional properties: +- clock-output-names : Should contain clock name + + +For example: + + clk_pll: clk_pll@98100000 { + compatible = "moxa,moxart-pll-clock"; + #clock-cells = <0>; + reg = <0x98100000 0x34>; + }; + + clk_apb: clk_apb@98100000 { + compatible = "moxa,moxart-apb-clock"; + #clock-cells = <0>; + reg = <0x98100000 0x34>; + clocks = <&clk_pll>; + }; diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt index 1e66294..dc5ea5b 100644 --- a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt +++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt @@ -11,19 +11,41 @@ The following is a list of provided IDs and clock names on Armada 370/XP: 3 = hclk (DRAM control clock) 4 = dramclk (DDR clock) +The following is a list of provided IDs and clock names on Armada 375: + 0 = tclk (Internal Bus clock) + 1 = cpuclk (CPU clock) + 2 = l2clk (L2 Cache clock) + 3 = ddrclk (DDR clock) + +The following is a list of provided IDs and clock names on Armada 380/385: + 0 = tclk (Internal Bus clock) + 1 = cpuclk (CPU clock) + 2 = l2clk (L2 Cache clock) + 3 = ddrclk (DDR clock) + The following is a list of provided IDs and clock names on Kirkwood and Dove: 0 = tclk (Internal Bus clock) 1 = cpuclk (CPU0 clock) 2 = l2clk (L2 Cache clock derived from CPU0 clock) 3 = ddrclk (DDR controller clock derived from CPU0 clock) +The following is a list of provided IDs and clock names on Orion5x: + 0 = tclk (Internal Bus clock) + 1 = cpuclk (CPU0 clock) + 2 = ddrclk (DDR controller clock derived from CPU0 clock) + Required properties: - compatible : shall be one of the following: "marvell,armada-370-core-clock" - For Armada 370 SoC core clocks + "marvell,armada-375-core-clock" - For Armada 375 SoC core clocks + "marvell,armada-380-core-clock" - For Armada 380/385 SoC core clocks "marvell,armada-xp-core-clock" - For Armada XP SoC core clocks "marvell,dove-core-clock" - for Dove SoC core clocks "marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180) "marvell,mv88f6180-core-clock" - for Kirkwood MV88f6180 SoC + "marvell,mv88f5182-core-clock" - for Orion MV88F5182 SoC + "marvell,mv88f5281-core-clock" - for Orion MV88F5281 SoC + "marvell,mv88f6183-core-clock" - for Orion MV88F6183 SoC - reg : shall be the register address of the Sample-At-Reset (SAR) register - #clock-cells : from common clock binding; shall be set to 1 diff --git a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt index c62391f..520562a 100644 --- a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt +++ b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt @@ -4,7 +4,10 @@ The following is a list of provided IDs and clock names on Armada 370/XP: 0 = nand (NAND clock) Required properties: -- compatible : must be "marvell,armada-370-corediv-clock" +- compatible : must be "marvell,armada-370-corediv-clock", + "marvell,armada-375-corediv-clock", + "marvell,armada-380-corediv-clock", + - reg : must be the register address of Core Divider control register - #clock-cells : from common clock binding; shall be set to 1 - clocks : must be set to the parent's phandle diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt index fc2910f..76477be 100644 --- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt +++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt @@ -1,9 +1,10 @@ * Gated Clock bindings for Marvell EBU SoCs -Marvell Armada 370/XP, Dove and Kirkwood allow some peripheral clocks to be -gated to save some power. The clock consumer should specify the desired clock -by having the clock ID in its "clocks" phandle cell. The clock ID is directly -mapped to the corresponding clock gating control bit in HW to ease manual clock +Marvell Armada 370/375/380/385/XP, Dove and Kirkwood allow some +peripheral clocks to be gated to save some power. The clock consumer +should specify the desired clock by having the clock ID in its +"clocks" phandle cell. The clock ID is directly mapped to the +corresponding clock gating control bit in HW to ease manual clock lookup in datasheet. The following is a list of provided IDs for Armada 370: @@ -22,6 +23,60 @@ ID Clock Peripheral 28 ddr DDR Cntrl 30 sata1 SATA Host 0 +The following is a list of provided IDs for Armada 375: +ID Clock Peripheral +----------------------------------- +2 mu Management Unit +3 pp Packet Processor +4 ptp PTP +5 pex0 PCIe 0 Clock out +6 pex1 PCIe 1 Clock out +8 audio Audio Cntrl +11 nd_clk Nand Flash Cntrl +14 sata0_link SATA 0 Link +15 sata0_core SATA 0 Core +16 usb3 USB3 Host +17 sdio SDHCI Host +18 usb USB Host +19 gop Gigabit Ethernet MAC +20 sata1_link SATA 1 Link +21 sata1_core SATA 1 Core +22 xor0 XOR DMA 0 +23 xor1 XOR DMA 0 +24 copro Coprocessor +25 tdm Time Division Mplx +28 crypto0_enc Cryptographic Unit Port 0 Encryption +29 crypto0_core Cryptographic Unit Port 0 Core +30 crypto1_enc Cryptographic Unit Port 1 Encryption +31 crypto1_core Cryptographic Unit Port 1 Core + +The following is a list of provided IDs for Armada 380/385: +ID Clock Peripheral +----------------------------------- +0 audio Audio +2 ge2 Gigabit Ethernet 2 +3 ge1 Gigabit Ethernet 1 +4 ge0 Gigabit Ethernet 0 +5 pex1 PCIe 1 +6 pex2 PCIe 2 +7 pex3 PCIe 3 +8 pex0 PCIe 0 +9 usb3h0 USB3 Host 0 +10 usb3h1 USB3 Host 1 +11 usb3d USB3 Device +13 bm Buffer Management +14 crypto0z Cryptographic 0 Z +15 sata0 SATA 0 +16 crypto1z Cryptographic 1 Z +17 sdio SDIO +18 usb2 USB 2 +21 crypto1 Cryptographic 1 +22 xor0 XOR 0 +23 crypto0 Cryptographic 0 +25 tdm Time Division Multiplexing +28 xor1 XOR 1 +30 sata1 SATA 1 + The following is a list of provided IDs for Armada XP: ID Clock Peripheral ----------------------------------- @@ -95,6 +150,8 @@ ID Clock Peripheral Required properties: - compatible : shall be one of the following: "marvell,armada-370-gating-clock" - for Armada 370 SoC clock gating + "marvell,armada-375-gating-clock" - for Armada 375 SoC clock gating + "marvell,armada-380-gating-clock" - for Armada 380/385 SoC clock gating "marvell,armada-xp-gating-clock" - for Armada XP SoC clock gating "marvell,dove-gating-clock" - for Dove SoC clock gating "marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 767401f..aba3d25 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -4,9 +4,14 @@ Qualcomm Global Clock & Reset Controller Binding 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" + "qcom,gcc-msm8974pro" + "qcom,gcc-msm8974pro-ac" - reg : shall contain base register location and length - #clock-cells : shall contain 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt index d572e99..29ebf84 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/corenet-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt index 24711af..5666812 100644 --- a/Documentation/devicetree/bindings/clock/corenet-clock.txt +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt @@ -7,6 +7,14 @@ which can then be passed to a variety of internal logic, including cores and peripheral IP blocks. Please refer to the Reference Manual for details. +All references to "1.0" and "2.0" refer to the QorIQ chassis version to +which the chip complies. + +Chassis Version Example Chips +--------------- ------------- +1.0 p4080, p5020, p5040 +2.0 t4240, b4860, t1040 + 1. Clock Block Binding Required properties: @@ -85,7 +93,7 @@ Example for clock block and clock provider: #clock-cells = <0>; compatible = "fsl,qoriq-sysclk-1.0"; clock-output-names = "sysclk"; - } + }; pll0: pll0@800 { #clock-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt index 5992dce..8a92b5f 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt @@ -10,6 +10,8 @@ index in the group, from 0 to 31. Required Properties: - compatible: Must be one of the following + - "renesas,r7s72100-mstp-clocks" for R7S72100 (RZ) MSTP gate clocks + - "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) MSTP gate clocks - "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks - "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2) MSTP gate clocks - "renesas,cpg-mstp-clock" for generic MSTP gate clocks @@ -43,7 +45,7 @@ Example clock-output-names = "tpu0", "mmcif1", "sdhi3", "sdhi2", "sdhi1", "sdhi0", "mmcif0"; - renesas,clock-indices = < + clock-indices = < R8A7790_CLK_TPU0 R8A7790_CLK_MMCIF1 R8A7790_CLK_SDHI3 R8A7790_CLK_SDHI2 R8A7790_CLK_SDHI1 R8A7790_CLK_SDHI0 R8A7790_CLK_MMCIF0 diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt new file mode 100644 index 0000000..2c03302 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt @@ -0,0 +1,41 @@ +These bindings should be considered EXPERIMENTAL for now. + +* Renesas R8A7740 Clock Pulse Generator (CPG) + +The CPG generates core clocks for the R8A7740 SoC. It includes three PLLs +and several fixed ratio and variable ratio dividers. + +Required Properties: + + - compatible: Must be "renesas,r8a7740-cpg-clocks" + + - reg: Base address and length of the memory resource used by the CPG + + - clocks: Reference to the three parent clocks + - #clock-cells: Must be 1 + - clock-output-names: The names of the clocks. Supported clocks are + "system", "pllc0", "pllc1", "pllc2", "r", "usb24s", "i", "zg", "b", + "m1", "hp", "hpp", "usbp", "s", "zb", "m3", and "cp". + + - renesas,mode: board-specific settings of the MD_CK* bits + + +Example +------- + +cpg_clocks: cpg_clocks@e6150000 { + compatible = "renesas,r8a7740-cpg-clocks"; + reg = <0xe6150000 0x10000>; + clocks = <&extal1_clk>, <&extal2_clk>, <&extalr_clk>; + #clock-cells = <1>; + clock-output-names = "system", "pllc0", "pllc1", + "pllc2", "r", + "usb24s", + "i", "zg", "b", "m1", "hp", + "hpp", "usbp", "s", "zb", "m3", + "cp"; +}; + +&cpg_clocks { + renesas,mode = <0x05>; +}; diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt new file mode 100644 index 0000000..ed3c8cb --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt @@ -0,0 +1,27 @@ +* Renesas R8A7779 Clock Pulse Generator (CPG) + +The CPG generates core clocks for the R8A7779. It includes one PLL and +several fixed ratio dividers + +Required Properties: + + - compatible: Must be "renesas,r8a7779-cpg-clocks" + - reg: Base address and length of the memory resource used by the CPG + + - clocks: Reference to the parent clock + - #clock-cells: Must be 1 + - clock-output-names: The names of the clocks. Supported clocks are "plla", + "z", "zs", "s", "s1", "p", "b", "out". + + +Example +------- + + cpg_clocks: cpg_clocks@ffc80000 { + compatible = "renesas,r8a7779-cpg-clocks"; + reg = <0 0xffc80000 0 0x30>; + clocks = <&extal_clk>; + #clock-cells = <1>; + clock-output-names = "plla", "z", "zs", "s", "s1", "p", + "b", "out"; + }; diff --git a/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt new file mode 100644 index 0000000..98a2574 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt @@ -0,0 +1,29 @@ +* Renesas RZ Clock Pulse Generator (CPG) + +The CPG generates core clocks for the RZ SoCs. It includes the PLL, variable +CPU and GPU clocks, and several fixed ratio dividers. + +Required Properties: + + - compatible: Must be one of + - "renesas,r7s72100-cpg-clocks" for the r7s72100 CPG + - "renesas,rz-cpg-clocks" for the generic RZ CPG + - reg: Base address and length of the memory resource used by the CPG + - clocks: References to possible parent clocks. Order must match clock modes + in the datasheet. For the r7s72100, this is extal, usb_x1. + - #clock-cells: Must be 1 + - clock-output-names: The names of the clocks. Supported clocks are "pll", + "i", and "g" + + +Example +------- + + cpg_clocks: cpg_clocks@fcfe0000 { + #clock-cells = <1>; + compatible = "renesas,r7s72100-cpg-clocks", + "renesas,rz-cpg-clocks"; + reg = <0xfcfe0000 0x18>; + clocks = <&extal_clk>, <&usb_x1_clk>; + clock-output-names = "pll", "i", "g"; + }; 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 0000000..0c2bf5e --- /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 0000000..c9fbb76 --- /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 a891c82..22f6769 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/samsung,s3c2410-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt new file mode 100644 index 0000000..822505e --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt @@ -0,0 +1,50 @@ +* Samsung S3C2410 Clock Controller + +The S3C2410 clock controller generates and supplies clock to various controllers +within the SoC. The clock binding described here is applicable to the s3c2410, +s3c2440 and s3c2442 SoCs in the s3c24x family. + +Required Properties: + +- compatible: should be one of the following. + - "samsung,s3c2410-clock" - controller compatible with S3C2410 SoC. + - "samsung,s3c2440-clock" - controller compatible with S3C2440 SoC. + - "samsung,s3c2442-clock" - controller compatible with S3C2442 SoC. +- reg: physical base address of the controller and length of memory mapped + region. +- #clock-cells: should be 1. + +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. Some of the clocks are available only +on a particular SoC. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/s3c2410.h header and can be used in device +tree sources. + +External clocks: + +The xti clock used as input for the plls is generated outside the SoC. It is +expected that is are defined using standard clock bindings with a +clock-output-names value of "xti". + +Example: Clock controller node: + + clocks: clock-controller@4c000000 { + compatible = "samsung,s3c2410-clock"; + reg = <0x4c000000 0x20>; + #clock-cells = <1>; + }; + +Example: UART controller node that consumes the clock generated by the clock + controller (refer to the standard clock bindings for information about + "clocks" and "clock-names" properties): + + serial@50004000 { + compatible = "samsung,s3c2440-uart"; + reg = <0x50004000 0x4000>; + interrupts = <1 23 3 4>, <1 23 4 4>; + clock-names = "uart", "clk_uart_baud2"; + clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt new file mode 100644 index 0000000..2b43096 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt @@ -0,0 +1,50 @@ +* Samsung S3C2412 Clock Controller + +The S3C2412 clock controller generates and supplies clock to various controllers +within the SoC. The clock binding described here is applicable to the s3c2412 +and s3c2413 SoCs in the s3c24x family. + +Required Properties: + +- compatible: should be "samsung,s3c2412-clock" +- reg: physical base address of the controller and length of memory mapped + region. +- #clock-cells: should be 1. + +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. Some of the clocks are available only +on a particular SoC. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/s3c2412.h header and can be used in device +tree sources. + +External clocks: + +There are several clocks that are generated outside the SoC. It is expected +that they are defined using standard clock bindings with following +clock-output-names: + - "xti" - crystal input - required, + - "ext" - external clock source - optional, + +Example: Clock controller node: + + clocks: clock-controller@4c000000 { + compatible = "samsung,s3c2412-clock"; + reg = <0x4c000000 0x20>; + #clock-cells = <1>; + }; + +Example: UART controller node that consumes the clock generated by the clock + controller (refer to the standard clock bindings for information about + "clocks" and "clock-names" properties): + + serial@50004000 { + compatible = "samsung,s3c2412-uart"; + reg = <0x50004000 0x4000>; + interrupts = <1 23 3 4>, <1 23 4 4>; + clock-names = "uart", "clk_uart_baud2", "clk_uart_baud3"; + clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>, + <&clocks SCLK_UART>; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt new file mode 100644 index 0000000..e67bb05 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt @@ -0,0 +1,56 @@ +* Samsung S3C2443 Clock Controller + +The S3C2443 clock controller generates and supplies clock to various controllers +within the SoC. The clock binding described here is applicable to all SoCs in +the s3c24x family starting with the s3c2443. + +Required Properties: + +- compatible: should be one of the following. + - "samsung,s3c2416-clock" - controller compatible with S3C2416 SoC. + - "samsung,s3c2443-clock" - controller compatible with S3C2443 SoC. + - "samsung,s3c2450-clock" - controller compatible with S3C2450 SoC. +- reg: physical base address of the controller and length of memory mapped + region. +- #clock-cells: should be 1. + +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. Some of the clocks are available only +on a particular SoC. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/s3c2443.h header and can be used in device +tree sources. + +External clocks: + +There are several clocks that are generated outside the SoC. It is expected +that they are defined using standard clock bindings with following +clock-output-names: + - "xti" - crystal input - required, + - "ext" - external clock source - optional, + - "ext_i2s" - external I2S clock - optional, + - "ext_uart" - external uart clock - optional, + +Example: Clock controller node: + + clocks: clock-controller@4c000000 { + compatible = "samsung,s3c2416-clock"; + reg = <0x4c000000 0x40>; + #clock-cells = <1>; + }; + +Example: UART controller node that consumes the clock generated by the clock + controller (refer to the standard clock bindings for information about + "clocks" and "clock-names" properties): + + serial@50004000 { + compatible = "samsung,s3c2440-uart"; + reg = <0x50004000 0x4000>; + interrupts = <1 23 3 4>, <1 23 4 4>; + clock-names = "uart", "clk_uart_baud2", + "clk_uart_baud3"; + clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>, + <&clocks SCLK_UART>; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt new file mode 100644 index 0000000..6247652 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt @@ -0,0 +1,49 @@ +Binding for a ST divider and multiplexer clock driver. + +This binding uses the common clock binding[1]. +Base address is located to the parent node. See clock binding[2] + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/st/st,clkgen.txt + +Required properties: + +- compatible : shall be: + "st,clkgena-divmux-c65-hs", "st,clkgena-divmux" + "st,clkgena-divmux-c65-ls", "st,clkgena-divmux" + "st,clkgena-divmux-c32-odf0", "st,clkgena-divmux" + "st,clkgena-divmux-c32-odf1", "st,clkgena-divmux" + "st,clkgena-divmux-c32-odf2", "st,clkgena-divmux" + "st,clkgena-divmux-c32-odf3", "st,clkgena-divmux" + +- #clock-cells : From common clock binding; shall be set to 1. + +- clocks : From common clock binding + +- clock-output-names : From common clock binding. + +Example: + + clockgen-a@fd345000 { + reg = <0xfd345000 0xb50>; + + 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"; + }; + }; + diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt new file mode 100644 index 0000000..f1fa91c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt @@ -0,0 +1,36 @@ +Binding for a ST multiplexed clock driver. + +This binding supports only simple indexed multiplexers, it does not +support table based parent index to hardware value translations. + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: + +- compatible : shall be: + "st,stih416-clkgenc-vcc-hd", "st,clkgen-mux" + "st,stih416-clkgenf-vcc-fvdp", "st,clkgen-mux" + "st,stih416-clkgenf-vcc-hva", "st,clkgen-mux" + "st,stih416-clkgenf-vcc-hd", "st,clkgen-mux" + "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. + +- reg : A Base address and length of the register set. + +- clocks : from common clock binding + +Example: + + 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>; + }; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt new file mode 100644 index 0000000..efb51cf --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt @@ -0,0 +1,51 @@ +Binding for a ST pll clock driver. + +This binding uses the common clock binding[1]. +Base address is located to the parent node. See clock binding[2] + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/st/st,clkgen.txt + +Required properties: + +- compatible : shall be: + "st,clkgena-prediv-c65", "st,clkgena-prediv" + "st,clkgena-prediv-c32", "st,clkgena-prediv" + + "st,clkgena-plls-c65" + "st,plls-c32-a1x-0", "st,clkgen-plls-c32" + "st,plls-c32-a1x-1", "st,clkgen-plls-c32" + "st,stih415-plls-c32-a9", "st,clkgen-plls-c32" + "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 + +- clock-output-names : From common clock binding. + +Example: + + clockgen-a@fee62000 { + reg = <0xfee62000 0xb48>; + + clk_s_a0_pll: clk-s-a0-pll { + #clock-cells = <1>; + compatible = "st,clkgena-plls-c65"; + + clocks = <&clk_sysin>; + + 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 new file mode 100644 index 0000000..604766c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt @@ -0,0 +1,36 @@ +Binding for a ST pre-divider clock driver. + +This binding uses the common clock binding[1]. +Base address is located to the parent node. See clock binding[2] + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/st/st,clkgen.txt + +Required properties: + +- compatible : shall be: + "st,clkgena-prediv-c65", "st,clkgena-prediv" + "st,clkgena-prediv-c32", "st,clkgena-prediv" + +- #clock-cells : From common clock binding; shall be set to 0. + +- clocks : From common clock binding + +- clock-output-names : From common clock binding. + +Example: + + clockgen-a@fd345000 { + reg = <0xfd345000 0xb50>; + + clk_m_a2_osc_prediv: clk-m-a2-osc-prediv { + #clock-cells = <0>; + compatible = "st,clkgena-prediv-c32", + "st,clkgena-prediv"; + + clocks = <&clk_sysin>; + + 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 new file mode 100644 index 0000000..109b3ed --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt @@ -0,0 +1,61 @@ +Binding for a type of STMicroelectronics clock crossbar (VCC). + +The crossbar can take up to 4 input clocks and control up to 16 +output clocks. Not all inputs or outputs have to be in use in a +particular instantiation. Each output can be individually enabled, +select any of the input clocks and apply a divide (by 1,2,4 or 8) to +that selected clock. + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: + +- compatible : shall be: + "st,stih416-clkgenc", "st,vcc" + "st,stih416-clkgenf", "st,vcc" + +- #clock-cells : from common clock binding; shall be set to 1. + +- reg : A Base address and length of the register set. + +- clocks : from common clock binding + +- clock-output-names : From common clock binding. The block has 16 + clock outputs but not all of them in a specific instance + have to be used in the SoC. If a clock name is left as + an empty string then no clock will be created for the + output associated with that string index. If fewer than + 16 strings are provided then no clocks will be created + for the remaining outputs. + +Example: + + 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"; + }; + diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt new file mode 100644 index 0000000..78978f1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt @@ -0,0 +1,100 @@ +Binding for a Clockgen hardware block found on +certain STMicroelectronics consumer electronics SoC devices. + +A Clockgen node can contain pll, diviser or multiplexer nodes. + +We will find only the base address of the Clockgen, this base +address is common of all subnode. + + clockgen_node { + reg = <>; + + pll_node { + ... + }; + + prediv_node { + ... + }; + + divmux_node { + ... + }; + + 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]..[7] + +[1] Documentation/devicetree/bindings/clock/clock-bindings.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: + + clockgen-a@fee62000 { + + reg = <0xfee62000 0xb48>; + + clk_s_a0_pll: clk-s-a0-pll { + #clock-cells = <1>; + compatible = "st,clkgena-plls-c65"; + + clocks = <&clk-sysin>; + + 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 { + #clock-cells = <0>; + compatible = "st,clkgena-prediv-c65", + "st,clkgena-prediv"; + + clocks = <&clk_sysin>; + + clock-output-names = "clk-s-a0-osc-prediv"; + }; + + 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 */ + + 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 0000000..1d3ace0 --- /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 new file mode 100644 index 0000000..cedeb9c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt @@ -0,0 +1,48 @@ +Binding for a type of quad channel digital frequency synthesizer found on +certain STMicroelectronics consumer electronics SoC devices. + +This version contains a programmable PLL which can generate up to 216, 432 +or 660MHz (from a 30MHz oscillator input) as the input to the digital +synthesizers. + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be: + "st,stih416-quadfs216", "st,quadfs" + "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. + +- reg : A Base address and length of the register set. + +- clocks : from common clock binding + +- clock-output-names : From common clock binding. The block has 4 + clock outputs but not all of them in a specific instance + have to be used in the SoC. If a clock name is left as + an empty string then no clock will be created for the + output associated with that string index. If fewer than + 4 strings are provided then no clocks will be created + for the remaining outputs. + +Example: + + 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"; + }; diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index c2cb762..d3a5c3c 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -6,37 +6,52 @@ This binding uses the common clock binding[1]. Required properties: - compatible : shall be one of the following: - "allwinner,sun4i-osc-clk" - for a gatable oscillator - "allwinner,sun4i-pll1-clk" - for the main PLL clock and PLL4 + "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,sun4i-pll5-clk" - for the PLL5 clock - "allwinner,sun4i-pll6-clk" - for the PLL6 clock - "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock - "allwinner,sun4i-axi-clk" - for the AXI clock - "allwinner,sun4i-axi-gates-clk" - for the AXI gates - "allwinner,sun4i-ahb-clk" - for the AHB clock - "allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10 + "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 "allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13 "allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s "allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20 + "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,sun4i-apb0-clk" - for the APB0 clock - "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10 + "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,sun4i-apb1-clk" - for the APB1 clock - "allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing - "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10 + "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 "allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13 "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,sun4i-mod0-clk" - for the module 0 family of clocks + "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 + "allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20 + "allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13 + "allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31 Required properties for all clocks: - reg : shall be the control register address for the clock. @@ -44,10 +59,17 @@ Required properties for all clocks: multiplexed clocks, the list order must match the hardware programming order. - #clock-cells : from common clock binding; shall be set to 0 except for - "allwinner,*-gates-clk" where it shall be set to 1 + "allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk" and + "allwinner,sun4i-pll6-clk" where it shall be set to 1 +- clock-output-names : shall be the corresponding names of the outputs. + If the clock module only has one output, the name shall be the + module name. -Additionally, "allwinner,*-gates-clk" clocks require: -- clock-output-names : the corresponding gate names that the clock controls +And "allwinner,*-usb-clk" clocks also require: +- reset-cells : shall be set to 1 + +For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate +dummy clocks at 25 MHz and 125 MHz, respectively. See example. Clock consumers should specify the desired clocks they use with a "clocks" phandle cell. Consumers that are using a gated clock should @@ -56,23 +78,68 @@ offset of the bit controlling this particular gate in the register. For example: -osc24M: osc24M@01c20050 { +osc24M: clk@01c20050 { #clock-cells = <0>; - compatible = "allwinner,sun4i-osc-clk"; + compatible = "allwinner,sun4i-a10-osc-clk"; reg = <0x01c20050 0x4>; clocks = <&osc24M_fixed>; + clock-output-names = "osc24M"; }; -pll1: pll1@01c20000 { +pll1: clk@01c20000 { #clock-cells = <0>; - compatible = "allwinner,sun4i-pll1-clk"; + compatible = "allwinner,sun4i-a10-pll1-clk"; reg = <0x01c20000 0x4>; clocks = <&osc24M>; + clock-output-names = "pll1"; +}; + +pll5: clk@01c20020 { + #clock-cells = <1>; + compatible = "allwinner,sun4i-pll5-clk"; + reg = <0x01c20020 0x4>; + clocks = <&osc24M>; + clock-output-names = "pll5_ddr", "pll5_other"; }; cpu: cpu@01c20054 { #clock-cells = <0>; - compatible = "allwinner,sun4i-cpu-clk"; + compatible = "allwinner,sun4i-a10-cpu-clk"; reg = <0x01c20054 0x4>; clocks = <&osc32k>, <&osc24M>, <&pll1>; + clock-output-names = "cpu"; +}; + +mmc0_clk: clk@01c20088 { + #clock-cells = <0>; + compatible = "allwinner,sun4i-mod0-clk"; + reg = <0x01c20088 0x4>; + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>; + clock-output-names = "mmc0"; +}; + +mii_phy_tx_clk: clk@2 { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <25000000>; + clock-output-names = "mii_phy_tx"; +}; + +gmac_int_tx_clk: clk@3 { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <125000000>; + clock-output-names = "gmac_int_tx"; +}; + +gmac_clk: clk@01c20164 { + #clock-cells = <0>; + compatible = "allwinner,sun7i-a20-gmac-clk"; + reg = <0x01c20164 0x4>; + /* + * The first clock must be fixed at 25MHz; + * the second clock must be fixed at 125MHz + */ + clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>; + clock-output-names = "gmac"; }; diff --git a/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt b/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt new file mode 100644 index 0000000..3e6a81e --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt @@ -0,0 +1,20 @@ +* Device tree bindings for Texas Instruments keystone pll controller + +The main pll controller used to drive theC66x CorePacs, the switch fabric, +and a majority of the peripheral clocks (all but the ARM CorePacs, DDR3 and +the NETCP modules) requires a PLL Controller to manage the various clock +divisions, gating, and synchronization. + +Required properties: + +- compatible: "ti,keystone-pllctrl", "syscon" + +- reg: contains offset/length value for pll controller + registers space. + +Example: + +pllctrl: pll-controller@0x02310000 { + compatible = "ti,keystone-pllctrl", "syscon"; + reg = <0x02310000 0x200>; +}; diff --git a/Documentation/devicetree/bindings/clock/ti/apll.txt b/Documentation/devicetree/bindings/clock/ti/apll.txt index 7faf5a6..ade4dd4 100644 --- a/Documentation/devicetree/bindings/clock/ti/apll.txt +++ b/Documentation/devicetree/bindings/clock/ti/apll.txt @@ -14,18 +14,32 @@ a subtype of a DPLL [2], although a simplified one at that. [2] Documentation/devicetree/bindings/clock/ti/dpll.txt Required properties: -- compatible : shall be "ti,dra7-apll-clock" +- compatible : shall be "ti,dra7-apll-clock" or "ti,omap2-apll-clock" - #clock-cells : from common clock binding; shall be set to 0. - clocks : link phandles of parent clocks (clk-ref and clk-bypass) - reg : address and length of the register set for controlling the APLL. It contains the information of registers in the following order: - "control" - contains the control register base address - "idlest" - contains the idlest register base address + "control" - contains the control register offset + "idlest" - contains the idlest register offset + "autoidle" - contains the autoidle register offset (OMAP2 only) +- ti,clock-frequency : static clock frequency for the clock (OMAP2 only) +- ti,idlest-shift : bit-shift for the idlest field (OMAP2 only) +- ti,bit-shift : bit-shift for enable and autoidle fields (OMAP2 only) Examples: - apll_pcie_ck: apll_pcie_ck@4a008200 { + apll_pcie_ck: apll_pcie_ck { #clock-cells = <0>; clocks = <&apll_pcie_in_clk_mux>, <&dpll_pcie_ref_ck>; - reg = <0x4a00821c 0x4>, <0x4a008220 0x4>; + reg = <0x021c>, <0x0220>; compatible = "ti,dra7-apll-clock"; }; + + apll96_ck: apll96_ck { + #clock-cells = <0>; + compatible = "ti,omap2-apll-clock"; + clocks = <&sys_ck>; + ti,bit-shift = <2>; + ti,idlest-shift = <8>; + ti,clock-frequency = <96000000>; + reg = <0x0500>, <0x0530>, <0x0520>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt index 30bfdb7..df57009 100644 --- a/Documentation/devicetree/bindings/clock/ti/dpll.txt +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -24,12 +24,14 @@ Required properties: "ti,omap4-dpll-core-clock", "ti,omap4-dpll-m4xen-clock", "ti,omap4-dpll-j-type-clock", + "ti,omap5-mpu-dpll-clock", "ti,am3-dpll-no-gate-clock", "ti,am3-dpll-j-type-clock", "ti,am3-dpll-no-gate-j-type-clock", "ti,am3-dpll-clock", "ti,am3-dpll-core-clock", "ti,am3-dpll-x2-clock", + "ti,omap2-dpll-core-clock", - #clock-cells : from common clock binding; shall be set to 0. - clocks : link phandles of parent clocks, first entry lists reference clock @@ -41,6 +43,7 @@ Required properties: "mult-div1" - contains the multiplier / divider register base address "autoidle" - contains the autoidle register base address (optional) ti,am3-* dpll types do not have autoidle register + ti,omap2-* dpll type does not support idlest / autoidle registers Optional properties: - DPLL mode setting - defining any one or more of the following overrides @@ -73,3 +76,10 @@ Examples: clocks = <&sys_clkin_ck>, <&sys_clkin_ck>; reg = <0x90>, <0x5c>, <0x68>; }; + + dpll_ck: dpll_ck { + #clock-cells = <0>; + compatible = "ti,omap2-dpll-core-clock"; + clocks = <&sys_ck>, <&sys_ck>; + reg = <0x0500>, <0x0540>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt b/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt new file mode 100644 index 0000000..585e8c1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/dra7-atl.txt @@ -0,0 +1,96 @@ +Device Tree Clock bindings for ATL (Audio Tracking Logic) of DRA7 SoC. + +The ATL IP is used to generate clock to be used to synchronize baseband and +audio codec. A single ATL IP provides four ATL clock instances sharing the same +functional clock but can be configured to provide different clocks. +ATL can maintain a clock averages to some desired frequency based on the bws/aws +signals - can compensate the drift between the two ws signal. + +In order to provide the support for ATL and it's output clocks (which can be used +internally within the SoC or external components) two sets of bindings is needed: + +Clock tree binding: +This binding uses the common clock binding[1]. +To be able to integrate the ATL clocks with DT clock tree. +Provides ccf level representation of the ATL clocks to be used by drivers. +Since the clock instances are part of a single IP this binding is used as a node +for the DT clock tree, the IP driver is needed to handle the actual configuration +of the IP. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be "ti,dra7-atl-clock" +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles to functional clock of ATL + +Binding for the IP driver: +This binding is used to configure the IP driver which is going to handle the +configuration of the IP for the ATL clock instances. + +Required properties: +- compatible : shall be "ti,dra7-atl" +- reg : base address for the ATL IP +- ti,provided-clocks : List of phandles to the clocks associated with the ATL +- clocks : link phandles to functional clock of ATL +- clock-names : Shall be set to "fck" +- ti,hwmods : Shall be set to "atl" + +Optional properties: +Configuration of ATL instances: +- atl{0/1/2/3} { + - bws : Baseband word select signal selection + - aws : Audio word select signal selection +}; + +For valid word select signals, see the dt-bindings/clk/ti-dra7-atl.h include +file. + +Examples: +/* clock bindings for atl provided clocks */ +atl_clkin0_ck: atl_clkin0_ck { + #clock-cells = <0>; + compatible = "ti,dra7-atl-clock"; + clocks = <&atl_gfclk_mux>; +}; + +atl_clkin1_ck: atl_clkin1_ck { + #clock-cells = <0>; + compatible = "ti,dra7-atl-clock"; + clocks = <&atl_gfclk_mux>; +}; + +atl_clkin2_ck: atl_clkin2_ck { + #clock-cells = <0>; + compatible = "ti,dra7-atl-clock"; + clocks = <&atl_gfclk_mux>; +}; + +atl_clkin3_ck: atl_clkin3_ck { + #clock-cells = <0>; + compatible = "ti,dra7-atl-clock"; + clocks = <&atl_gfclk_mux>; +}; + +/* binding for the IP */ +atl: atl@4843c000 { + compatible = "ti,dra7-atl"; + reg = <0x4843c000 0x3ff>; + ti,hwmods = "atl"; + ti,provided-clocks = <&atl_clkin0_ck>, <&atl_clkin1_ck>, + <&atl_clkin2_ck>, <&atl_clkin3_ck>; + clocks = <&atl_gfclk_mux>; + clock-names = "fck"; + status = "disabled"; +}; + +#include <dt-bindings/clk/ti-dra7-atl.h> + +&atl { + status = "okay"; + + atl2 { + bws = <DRA7_ATL_WS_MCASP2_FSX>; + aws = <DRA7_ATL_WS_MCASP3_FSX>; + }; +}; diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt index 125281a..03f8fde 100644 --- a/Documentation/devicetree/bindings/clock/ti/gate.txt +++ b/Documentation/devicetree/bindings/clock/ti/gate.txt @@ -25,6 +25,11 @@ Required properties: to map clockdomains properly "ti,hsdiv-gate-clock" - gate clock with OMAP36xx specific hardware handling, required for a hardware errata + "ti,composite-gate-clock" - composite gate clock, to be part of composite + clock + "ti,composite-no-wait-gate-clock" - composite gate clock that does not wait + for clock to be active before returning + from clk_enable() - #clock-cells : from common clock binding; shall be set to 0 - clocks : link to phandle of parent clock - reg : offset for register controlling adjustable gate, not needed for @@ -41,7 +46,7 @@ Examples: #clock-cells = <0>; compatible = "ti,gate-clock"; clocks = <&core_96m_fck>; - reg = <0x48004a00 0x4>; + reg = <0x0a00>; ti,bit-shift = <25>; }; @@ -57,7 +62,7 @@ Examples: #clock-cells = <0>; compatible = "ti,dss-gate-clock"; clocks = <&dpll4_m4x2_ck>; - reg = <0x48004e00 0x4>; + reg = <0x0e00>; ti,bit-shift = <0>; }; @@ -65,7 +70,7 @@ Examples: #clock-cells = <0>; compatible = "ti,am35xx-gate-clock"; clocks = <&ipss_ick>; - reg = <0x4800259c 0x4>; + reg = <0x059c>; ti,bit-shift = <1>; }; @@ -80,6 +85,22 @@ Examples: compatible = "ti,hsdiv-gate-clock"; clocks = <&dpll4_m2x2_mul_ck>; ti,bit-shift = <0x1b>; - reg = <0x48004d00 0x4>; + reg = <0x0d00>; ti,set-bit-to-disable; }; + + vlynq_gate_fck: vlynq_gate_fck { + #clock-cells = <0>; + compatible = "ti,composite-gate-clock"; + clocks = <&core_ck>; + ti,bit-shift = <3>; + reg = <0x0200>; + }; + + sys_clkout2_src_gate: sys_clkout2_src_gate { + #clock-cells = <0>; + compatible = "ti,composite-no-wait-gate-clock"; + clocks = <&core_ck>; + ti,bit-shift = <15>; + reg = <0x0070>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt b/Documentation/devicetree/bindings/clock/ti/interface.txt index 064e8ca..3111a40 100644 --- a/Documentation/devicetree/bindings/clock/ti/interface.txt +++ b/Documentation/devicetree/bindings/clock/ti/interface.txt @@ -21,6 +21,8 @@ Required properties: "ti,omap3-dss-interface-clock" - interface clock with DSS specific HW handling "ti,omap3-ssi-interface-clock" - interface clock with SSI specific HW handling "ti,am35xx-interface-clock" - interface clock with AM35xx specific HW handling + "ti,omap2430-interface-clock" - interface clock with OMAP2430 specific HW + handling - #clock-cells : from common clock binding; shall be set to 0 - clocks : link to phandle of parent clock - reg : base address for the control register diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt index 17b4a94..d93746c 100644 --- a/Documentation/devicetree/bindings/clock/zynq-7000.txt +++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt @@ -14,6 +14,7 @@ for all clock consumers of PS clocks. Required properties: - #clock-cells : Must be 1 - compatible : "xlnx,ps7-clkc" + - reg : SLCR offset and size taken via syscon < 0x100 0x100 > - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ (usually 33 MHz oscillators are used for Zynq platforms) - clock-output-names : List of strings used to name the clock outputs. Shall be @@ -87,10 +88,11 @@ Clock outputs: 47: dbg_apb Example: - clkc: clkc { + clkc: clkc@100 { #clock-cells = <1>; compatible = "xlnx,ps7-clkc"; ps-clk-frequency = <33333333>; + reg = <0x100 0x100>; clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x", "dci", "lqspi", "smc", "pcap", "gem0", "gem1", diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt index f055515..366690c 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 0000000..8c61183 --- /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 0000000..fdd53b1 --- /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/crypto/samsung-sss.txt b/Documentation/devicetree/bindings/crypto/samsung-sss.txt new file mode 100644 index 0000000..a6dafa8 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt @@ -0,0 +1,34 @@ +Samsung SoC SSS (Security SubSystem) module + +The SSS module in S5PV210 SoC supports the following: +-- Feeder (FeedCtrl) +-- Advanced Encryption Standard (AES) +-- Data Encryption Standard (DES)/3DES +-- Public Key Accelerator (PKA) +-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG +-- PRNG: Pseudo Random Number Generator + +The SSS module in Exynos4 (Exynos4210) and +Exynos5 (Exynos5420 and Exynos5250) SoCs +supports the following also: +-- ARCFOUR (ARC4) +-- True Random Number Generator (TRNG) +-- Secure Key Manager + +Required properties: + +- compatible : Should contain entries for this and backward compatible + SSS versions: + - "samsung,s5pv210-secss" for S5PV210 SoC. + - "samsung,exynos4210-secss" for Exynos4210, Exynos4212, Exynos4412, Exynos5250, + Exynos5260 and Exynos5420 SoCs. +- reg : Offset and length of the register set for the module +- interrupts : interrupt specifiers of SSS module interrupts, should contain + following entries: + - first : feed control interrupt (required for all variants), + - second : hash interrupt (required only for samsung,s5pv210-secss). + +- clocks : list of clock phandle and specifier pairs for all clocks listed in + clock-names property. +- clock-names : list of device clock input names; should contain one entry + "secss". diff --git a/Documentation/devicetree/bindings/dma/fsl-edma.txt b/Documentation/devicetree/bindings/dma/fsl-edma.txt new file mode 100644 index 0000000..191d7bd --- /dev/null +++ b/Documentation/devicetree/bindings/dma/fsl-edma.txt @@ -0,0 +1,76 @@ +* Freescale enhanced Direct Memory Access(eDMA) Controller + + The eDMA channels have multiplex capability by programmble memory-mapped +registers. channels are split into two groups, called DMAMUX0 and DMAMUX1, +specific DMA request source can only be multiplexed by any channel of certain +group, DMAMUX0 or DMAMUX1, but not both. + +* eDMA Controller +Required properties: +- compatible : + - "fsl,vf610-edma" for eDMA used similar to that on Vybrid vf610 SoC +- reg : Specifies base physical address(s) and size of the eDMA registers. + The 1st region is eDMA control register's address and size. + The 2nd and the 3rd regions are programmable channel multiplexing + control register's address and size. +- interrupts : A list of interrupt-specifiers, one for each entry in + interrupt-names. +- interrupt-names : Should contain: + "edma-tx" - the transmission interrupt + "edma-err" - the error interrupt +- #dma-cells : Must be <2>. + The 1st cell specifies the DMAMUX(0 for DMAMUX0 and 1 for DMAMUX1). + Specific request source can only be multiplexed by specific channels + group called DMAMUX. + The 2nd cell specifies the request source(slot) ID. + See the SoC's reference manual for all the supported request sources. +- dma-channels : Number of channels supported by the controller +- clock-names : A list of channel group clock names. Should contain: + "dmamux0" - clock name of mux0 group + "dmamux1" - clock name of mux1 group +- clocks : A list of phandle and clock-specifier pairs, one for each entry in + clock-names. + +Optional properties: +- big-endian: If present registers and hardware scatter/gather descriptors + of the eDMA are implemented in big endian mode, otherwise in little + mode. + + +Examples: + +edma0: dma-controller@40018000 { + #dma-cells = <2>; + compatible = "fsl,vf610-edma"; + reg = <0x40018000 0x2000>, + <0x40024000 0x1000>, + <0x40025000 0x1000>; + interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>, + <0 9 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "edma-tx", "edma-err"; + dma-channels = <32>; + clock-names = "dmamux0", "dmamux1"; + clocks = <&clks VF610_CLK_DMAMUX0>, + <&clks VF610_CLK_DMAMUX1>; +}; + + +* DMA clients +DMA client drivers that uses the DMA function must use the format described +in the dma.txt file, using a two-cell specifier for each channel: the 1st +specifies the channel group(DMAMUX) in which this request can be multiplexed, +and the 2nd specifies the request source. + +Examples: + +sai2: sai@40031000 { + compatible = "fsl,vf610-sai"; + reg = <0x40031000 0x1000>; + interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "sai"; + clocks = <&clks VF610_CLK_SAI2>; + dma-names = "tx", "rx"; + dmas = <&edma0 0 21>, + <&edma0 0 20>; + status = "disabled"; +}; diff --git a/Documentation/devicetree/bindings/dma/mmp-dma.txt b/Documentation/devicetree/bindings/dma/mmp-dma.txt index a4fa4ef..7a802f6 100644 --- a/Documentation/devicetree/bindings/dma/mmp-dma.txt +++ b/Documentation/devicetree/bindings/dma/mmp-dma.txt @@ -1,17 +1,20 @@ * MARVELL MMP DMA controller Marvell Peripheral DMA Controller -Used platfroms: pxa688, pxa910, pxa3xx, etc +Used platforms: pxa688, pxa910, pxa3xx, etc Required properties: - compatible: Should be "marvell,pdma-1.0" - reg: Should contain DMA registers location and length. - interrupts: Either contain all of the per-channel DMA interrupts or one irq for pdma device -- #dma-channels: Number of DMA channels supported by the controller. + +Optional properties: +- #dma-channels: Number of DMA channels supported by the controller (defaults + to 32 when not specified) "marvell,pdma-1.0" -Used platfroms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688. +Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688. Examples: @@ -45,7 +48,7 @@ pdma: dma-controller@d4000000 { Marvell Two Channel DMA Controller used specifically for audio -Used platfroms: pxa688, pxa910 +Used platforms: pxa688, pxa910 Required properties: - compatible: Should be "marvell,adma-1.0" or "marvell,pxa910-squ" diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt new file mode 100644 index 0000000..d75a9d7 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt @@ -0,0 +1,41 @@ +QCOM BAM DMA controller + +Required properties: +- compatible: must contain "qcom,bam-v1.4.0" for MSM8974 +- reg: Address range for DMA registers +- interrupts: Should contain the one interrupt shared by all channels +- #dma-cells: must be <1>, the cell in the dmas property of the client device + represents the channel number +- clocks: required clock +- clock-names: must contain "bam_clk" entry +- qcom,ee : indicates the active Execution Environment identifier (0-7) used in + the secure world. + +Example: + + uart-bam: dma@f9984000 = { + compatible = "qcom,bam-v1.4.0"; + reg = <0xf9984000 0x15000>; + interrupts = <0 94 0>; + clocks = <&gcc GCC_BAM_DMA_AHB_CLK>; + clock-names = "bam_clk"; + #dma-cells = <1>; + qcom,ee = <0>; + }; + +DMA clients must use the format described in the dma.txt file, using a two cell +specifier for each channel. + +Example: + serial@f991e000 { + compatible = "qcom,msm-uart"; + reg = <0xf991e000 0x1000> + <0xf9944000 0x19000>; + interrupts = <0 108 0>; + clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>, + <&gcc GCC_BLSP1_AHB_CLK>; + clock-names = "core", "iface"; + + dmas = <&uart-bam 0>, <&uart-bam 1>; + dma-names = "rx", "tx"; + }; diff --git a/Documentation/devicetree/bindings/dma/sirfsoc-dma.txt b/Documentation/devicetree/bindings/dma/sirfsoc-dma.txt new file mode 100644 index 0000000..ecbc96a --- /dev/null +++ b/Documentation/devicetree/bindings/dma/sirfsoc-dma.txt @@ -0,0 +1,43 @@ +* CSR SiRFSoC DMA controller + +See dma.txt first + +Required properties: +- compatible: Should be "sirf,prima2-dmac" or "sirf,marco-dmac" +- reg: Should contain DMA registers location and length. +- interrupts: Should contain one interrupt shared by all channel +- #dma-cells: must be <1>. used to represent the number of integer + cells in the dmas property of client device. +- clocks: clock required + +Example: + +Controller: +dmac0: dma-controller@b00b0000 { + compatible = "sirf,prima2-dmac"; + reg = <0xb00b0000 0x10000>; + interrupts = <12>; + clocks = <&clks 24>; + #dma-cells = <1>; +}; + + +Client: +Fill the specific dma request line in dmas. In the below example, spi0 read +channel request line is 9 of the 2nd dma controller, while write channel uses +4 of the 2nd dma controller; spi1 read channel request line is 12 of the 1st +dma controller, while write channel uses 13 of the 1st dma controller: + +spi0: spi@b00d0000 { + compatible = "sirf,prima2-spi"; + dmas = <&dmac1 9>, + <&dmac1 4>; + dma-names = "rx", "tx"; +}; + +spi1: spi@b0170000 { + compatible = "sirf,prima2-spi"; + dmas = <&dmac0 12>, + <&dmac0 13>; + dma-names = "rx", "tx"; +}; diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt index 9fbbdb7..5ba525a 100644 --- a/Documentation/devicetree/bindings/dma/ti-edma.txt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -2,11 +2,8 @@ TI EDMA Required properties: - compatible : "ti,edma3" -- ti,edma-regions: Number of regions -- ti,edma-slots: Number of slots - #dma-cells: Should be set to <1> Clients should use a single channel number per DMA request. -- dma-channels: Specify total DMA channels per CC - reg: Memory map for accessing module - interrupt-parent: Interrupt controller the interrupt is routed through - interrupts: Exactly 3 interrupts need to be specified in the order: @@ -17,6 +14,13 @@ Optional properties: - ti,hwmods: Name of the hwmods associated to the EDMA - ti,edma-xbar-event-map: Crossbar event to channel map +Deprecated properties: +Listed here in case one wants to boot an old kernel with new DTB. These +properties might need to be added to the new DTS files. +- ti,edma-regions: Number of regions +- ti,edma-slots: Number of slots +- dma-channels: Specify total DMA channels per CC + Example: edma: edma@49000000 { @@ -26,9 +30,6 @@ edma: edma@49000000 { compatible = "ti,edma3"; ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; #dma-cells = <1>; - dma-channels = <64>; - ti,edma-regions = <4>; - ti,edma-slots = <256>; - ti,edma-xbar-event-map = <1 12 - 2 13>; + ti,edma-xbar-event-map = /bits/ 16 <1 12 + 2 13>; }; diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt new file mode 100644 index 0000000..1405ed0 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt @@ -0,0 +1,75 @@ +Xilinx AXI VDMA engine, it does transfers between memory and video devices. +It can be configured to have one channel or two channels. If configured +as two channels, one is to transmit to the video device and another is +to receive from the video device. + +Required properties: +- compatible: Should be "xlnx,axi-vdma-1.00.a" +- #dma-cells: Should be <1>, see "dmas" property below +- reg: Should contain VDMA registers location and length. +- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w. +- dma-channel child node: Should have at least one channel and can have up to + two channels per device. This node specifies the properties of each + DMA channel (see child node properties below). + +Optional properties: +- xlnx,include-sg: Tells configured for Scatter-mode in + the hardware. +- xlnx,flush-fsync: Tells which channel to Flush on Frame sync. + It takes following values: + {1}, flush both channels + {2}, flush mm2s channel + {3}, flush s2mm channel + +Required child node properties: +- compatible: It should be either "xlnx,axi-vdma-mm2s-channel" or + "xlnx,axi-vdma-s2mm-channel". +- interrupts: Should contain per channel VDMA interrupts. +- xlnx,data-width: Should contain the stream data width, take values + {32,64...1024}. + +Optional child node properties: +- xlnx,include-dre: Tells hardware is configured for Data + Realignment Engine. +- xlnx,genlock-mode: Tells Genlock synchronization is + enabled/disabled in hardware. + +Example: +++++++++ + +axi_vdma_0: axivdma@40030000 { + compatible = "xlnx,axi-vdma-1.00.a"; + #dma_cells = <1>; + reg = < 0x40030000 0x10000 >; + xlnx,num-fstores = <0x8>; + xlnx,flush-fsync = <0x1>; + dma-channel@40030000 { + compatible = "xlnx,axi-vdma-mm2s-channel"; + interrupts = < 0 54 4 >; + xlnx,datawidth = <0x40>; + } ; + dma-channel@40030030 { + compatible = "xlnx,axi-vdma-s2mm-channel"; + interrupts = < 0 53 4 >; + xlnx,datawidth = <0x40>; + } ; +} ; + + +* DMA client + +Required properties: +- dmas: a list of <[Video DMA device phandle] [Channel ID]> pairs, + where Channel ID is '0' for write/tx and '1' for read/rx + channel. +- dma-names: a list of DMA channel names, one per "dmas" entry + +Example: +++++++++ + +vdmatest_0: vdmatest@0 { + compatible ="xlnx,axi-vdma-test-1.00.a"; + dmas = <&axi_vdma_0 0 + &axi_vdma_0 1>; + dma-names = "vdma0", "vdma1"; +} ; diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt new file mode 100644 index 0000000..52b93b2 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt @@ -0,0 +1,27 @@ +ptn3460 bridge bindings + +Required properties: + - compatible: "nxp,ptn3460" + - reg: i2c address of the bridge + - powerdown-gpio: OF device-tree gpio specification + - reset-gpio: OF device-tree gpio specification + - edid-emulation: The EDID emulation entry to use + +-------+------------+------------------+ + | Value | Resolution | Description | + | 0 | 1024x768 | NXP Generic | + | 1 | 1920x1080 | NXP Generic | + | 2 | 1920x1080 | NXP Generic | + | 3 | 1600x900 | Samsung LTM200KT | + | 4 | 1920x1080 | Samsung LTM230HT | + | 5 | 1366x768 | NXP Generic | + | 6 | 1600x900 | ChiMei M215HGE | + +-------+------------+------------------+ + +Example: + lvds-bridge@20 { + compatible = "nxp,ptn3460"; + reg = <0x20>; + powerdown-gpio = <&gpy2 5 1 0 0>; + reset-gpio = <&gpx1 5 1 0 0>; + edid-emulation = <5>; + }; diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt new file mode 100644 index 0000000..d7df01c --- /dev/null +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt @@ -0,0 +1,27 @@ +Device-Tree bindings for the NXP TDA998x HDMI transmitter + +Required properties; + - compatible: must be "nxp,tda998x" + +Optional properties: + - interrupts: interrupt number and trigger type + default: polling + + - pinctrl-0: pin control group to be used for + screen plug/unplug interrupt. + + - pinctrl-names: must contain a "default" entry. + + - video-ports: 24 bits value which defines how the video controller + output is wired to the TDA998x input - default: <0x230145> + +Example: + + tda998x: hdmi-encoder { + compatible = "nxp,tda998x"; + reg = <0x70>; + interrupt-parent = <&gpio0>; + interrupts = <27 2>; /* falling edge */ + pinctrl-0 = <&pmx_camera>; + pinctrl-names = "default"; + }; diff --git a/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt b/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt new file mode 100644 index 0000000..4ecda22 --- /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/gpio/cirrus,clps711x-mctrl-gpio.txt b/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt new file mode 100644 index 0000000..94ae9f8 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt @@ -0,0 +1,17 @@ +* ARM Cirrus Logic CLPS711X SYSFLG1 MCTRL GPIOs + +Required properties: +- compatible: Should contain "cirrus,clps711x-mctrl-gpio". +- gpio-controller: Marks the device node as a gpio controller. +- #gpio-cells: Should be two. The first cell is the pin number and + the second cell is used to specify the gpio polarity: + 0 = Active high, + 1 = Active low. + +Example: + sysgpio: sysgpio { + compatible = "cirrus,ep7312-mctrl-gpio", + "cirrus,clps711x-mctrl-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt index a2e839d..5079ba7 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt @@ -1,13 +1,17 @@ -Davinci GPIO controller bindings +Davinci/Keystone GPIO controller bindings Required Properties: -- compatible: should be "ti,dm6441-gpio" +- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio" - reg: Physical base address of the controller and the size of memory mapped registers. - gpio-controller : Marks the device node as a gpio controller. +- #gpio-cells : Should be two. + - first cell is the pin number + - second cell is used to specify optional parameters (unused) + - interrupt-parent: phandle of the parent interrupt controller. - interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are @@ -27,6 +31,7 @@ Example: gpio: gpio@1e26000 { compatible = "ti,dm6441-gpio"; gpio-controller; + #gpio-cells = <2>; reg = <0x226000 0x1000>; interrupt-parent = <&intc>; interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH @@ -39,3 +44,19 @@ gpio: gpio@1e26000 { interrupt-controller; #interrupt-cells = <2>; }; + +leds { + compatible = "gpio-leds"; + + led1 { + label = "davinci:green:usr1"; + gpios = <&gpio 10 GPIO_ACTIVE_HIGH>; + ... + }; + + led2 { + label = "davinci:red:debug1"; + gpios = <&gpio 11 GPIO_ACTIVE_HIGH>; + ... + }; +}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-zevio.txt b/Documentation/devicetree/bindings/gpio/gpio-zevio.txt new file mode 100644 index 0000000..a37bd9a --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-zevio.txt @@ -0,0 +1,16 @@ +Zevio GPIO controller + +Required properties: +- compatible: Should be "lsi,zevio-gpio" +- reg: Address and length of the register set for the device +- #gpio-cells: Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters (currently unused). +- gpio-controller: Marks the device node as a GPIO controller. + +Example: + gpio: gpio@90000000 { + compatible = "lsi,zevio-gpio"; + reg = <0x90000000 0x1000>; + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index 0c85bb6..3fb8f53 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -13,11 +13,11 @@ properties, each containing a 'gpio-list': gpio-specifier : Array of #gpio-cells specifying specific gpio (controller specific) -GPIO properties should be named "[<name>-]gpios". Exact +GPIO properties should be named "[<name>-]gpios". The exact meaning of each gpios property must be documented in the device tree binding for each device. -For example, the following could be used to describe gpios pins to use +For example, the following could be used to describe GPIO pins used as chip select lines; with chip selects 0, 1 and 3 populated, and chip select 2 left empty: @@ -44,35 +44,79 @@ whether pin is open-drain and whether pin is logically inverted. Exact meaning of each specifier cell is controller specific, and must be documented in the device tree binding for the device. -Example of the node using GPIOs: +Example of a node using GPIOs: node { gpios = <&qe_pio_e 18 0>; }; In this example gpio-specifier is "18 0" and encodes GPIO pin number, -and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller. +and GPIO flags as accepted by the "qe_pio_e" gpio-controller. + +1.1) GPIO specifier best practices +---------------------------------- + +A gpio-specifier should contain a flag indicating the GPIO polarity; active- +high or active-low. If it does, the follow best practices should be followed: + +The gpio-specifier's polarity flag should represent the physical level at the +GPIO controller that achieves (or represents, for inputs) a logically asserted +value at the device. The exact definition of logically asserted should be +defined by the binding for the device. If the board inverts the signal between +the GPIO controller and the device, then the gpio-specifier will represent the +opposite physical level than the signal at the device's pin. + +When the device's signal polarity is configurable, the binding for the +device must either: + +a) Define a single static polarity for the signal, with the expectation that +any software using that binding would statically program the device to use +that signal polarity. + +The static choice of polarity may be either: + +a1) (Preferred) Dictated by a binding-specific DT property. + +or: + +a2) Defined statically by the DT binding itself. + +In particular, the polarity cannot be derived from the gpio-specifier, since +that would prevent the DT from separately representing the two orthogonal +concepts of configurable signal polarity in the device, and possible board- +level signal inversion. + +or: + +b) Pick a single option for device signal polarity, and document this choice +in the binding. The gpio-specifier should represent the polarity of the signal +(at the GPIO controller) assuming that the device is configured for this +particular signal polarity choice. If software chooses to program the device +to generate or receive a signal of the opposite polarity, software will be +responsible for correctly interpreting (inverting) the GPIO signal at the GPIO +controller. 2) gpio-controller nodes ------------------------ -Every GPIO controller node must both an empty "gpio-controller" -property, and have #gpio-cells contain the size of the gpio-specifier. +Every GPIO controller node must contain both an empty "gpio-controller" +property, and a #gpio-cells integer property, which indicates the number of +cells in a gpio-specifier. Example of two SOC GPIO banks defined as gpio-controller nodes: qe_pio_a: gpio-controller@1400 { - #gpio-cells = <2>; compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank"; reg = <0x1400 0x18>; gpio-controller; + #gpio-cells = <2>; }; qe_pio_e: gpio-controller@1460 { - #gpio-cells = <2>; compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank"; reg = <0x1460 0x18>; gpio-controller; + #gpio-cells = <2>; }; 2.1) gpio- and pin-controller interaction diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt index f61cef7..941a26a 100644 --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt @@ -21,6 +21,12 @@ Required Properties: GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. - gpio-ranges: Range of pins managed by the GPIO controller. +Optional properties: + + - clocks: Must contain a reference to the functional clock. The property is + mandatory if the hardware implements a controllable functional clock for + the GPIO instance. + Please refer to gpio.txt in this directory for details of gpio-ranges property and the common GPIO bindings used by client devices. diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt new file mode 100644 index 0000000..dd5d2c0 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt @@ -0,0 +1,60 @@ +* Synopsys DesignWare APB GPIO controller + +Required properties: +- compatible : Should contain "snps,dw-apb-gpio" +- reg : Address and length of the register set for the device. +- #address-cells : should be 1 (for addressing port subnodes). +- #size-cells : should be 0 (port subnodes). + +The GPIO controller has a configurable number of ports, each of which are +represented as child nodes with the following properties: + +Required properties: +- compatible : "snps,dw-apb-gpio-port" +- gpio-controller : Marks the device node as a gpio controller. +- #gpio-cells : Should be two. The first cell is the pin number and + the second cell is used to specify the gpio polarity: + 0 = active high + 1 = active low +- reg : The integer port index of the port, a single cell. + +Optional properties: +- interrupt-controller : The first port may be configured to be an interrupt +controller. +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt. Shall be set to 2. The first cell defines the interrupt number, + the second encodes the triger flags encoded as described in + Documentation/devicetree/bindings/interrupts.txt +- interrupt-parent : The parent interrupt controller. +- interrupts : The interrupt to the parent controller raised when GPIOs + generate the interrupts. +- snps,nr-gpios : The number of pins in the port, a single cell. + +Example: + +gpio: gpio@20000 { + compatible = "snps,dw-apb-gpio"; + reg = <0x20000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + + porta: gpio-controller@0 { + compatible = "snps,dw-apb-gpio-port"; + gpio-controller; + #gpio-cells = <2>; + snps,nr-gpios = <8>; + reg = <0>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&vic1>; + interrupts = <0>; + }; + + portb: gpio-controller@1 { + compatible = "snps,dw-apb-gpio-port"; + gpio-controller; + #gpio-cells = <2>; + snps,nr-gpios = <8>; + reg = <1>; + }; +}; diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt index efaeec8..b48f4ef 100644 --- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt @@ -136,6 +136,7 @@ of the following host1x client modules: - compatible: "nvidia,tegra<chip>-hdmi" - reg: Physical base address and length of the controller's registers. - interrupts: The interrupt outputs from the controller. + - hdmi-supply: supply for the +5V HDMI connector pin - vdd-supply: regulator for supply voltage - pll-supply: regulator for PLL - clocks: Must contain an entry for each entry in clock-names. @@ -180,6 +181,7 @@ of the following host1x client modules: See ../reset/reset.txt for details. - reset-names: Must include the following entries: - dsi + - avdd-dsi-supply: phandle of a supply that powers the DSI controller - nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying which pads are used by this DSI output and need to be calibrated. See also ../mipi/nvidia,tegra114-mipi.txt. @@ -190,6 +192,48 @@ of the following host1x client modules: - nvidia,edid: supplies a binary EDID blob - nvidia,panel: phandle of a display panel +- sor: serial output resource + + Required properties: + - compatible: "nvidia,tegra124-sor" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - 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: + - sor: clock input for the SOR hardware + - parent: input for the pixel clock + - dp: reference clock for the SOR clock + - safe: safe reference for the SOR clock during power up + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - sor + + Optional properties: + - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing + - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection + - nvidia,edid: supplies a binary EDID blob + - nvidia,panel: phandle of a display panel + + Optional properties when driving an eDP output: + - nvidia,dpaux: phandle to a DispayPort AUX interface + +- dpaux: DisplayPort AUX interface + - compatible: "nvidia,tegra124-dpaux" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - 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: + - dpaux: clock input for the DPAUX hardware + - parent: reference clock + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - dpaux + - vdd-supply: phandle of a supply that powers the DisplayPort link + Example: / { diff --git a/Documentation/devicetree/bindings/hsi/client-devices.txt b/Documentation/devicetree/bindings/hsi/client-devices.txt new file mode 100644 index 0000000..104c9a3 --- /dev/null +++ b/Documentation/devicetree/bindings/hsi/client-devices.txt @@ -0,0 +1,44 @@ +Each HSI port is supposed to have one child node, which +symbols the remote device connected to the HSI port. The +following properties are standardized for HSI clients: + +Required HSI configuration properties: + +- hsi-channel-ids: A list of channel ids + +- hsi-rx-mode: Receiver Bit transmission mode ("stream" or "frame") +- hsi-tx-mode: Transmitter Bit transmission mode ("stream" or "frame") +- hsi-mode: May be used instead hsi-rx-mode and hsi-tx-mode if + the transmission mode is the same for receiver and + transmitter +- hsi-speed-kbps: Max bit transmission speed in kbit/s +- hsi-flow: RX flow type ("synchronized" or "pipeline") +- hsi-arb-mode: Arbitration mode for TX frame ("round-robin", "priority") + +Optional HSI configuration properties: + +- hsi-channel-names: A list with one name per channel specified in the + hsi-channel-ids property + + +Device Tree node example for an HSI client: + +hsi-controller { + hsi-port { + modem: hsi-client { + compatible = "nokia,n900-modem"; + + hsi-channel-ids = <0>, <1>, <2>, <3>; + hsi-channel-names = "mcsaab-control", + "speech-control", + "speech-data", + "mcsaab-data"; + hsi-speed-kbps = <55000>; + hsi-mode = "frame"; + hsi-flow = "synchronized"; + hsi-arb-mode = "round-robin"; + + /* more client specific properties */ + }; + }; +}; diff --git a/Documentation/devicetree/bindings/hsi/nokia-modem.txt b/Documentation/devicetree/bindings/hsi/nokia-modem.txt new file mode 100644 index 0000000..8a97978 --- /dev/null +++ b/Documentation/devicetree/bindings/hsi/nokia-modem.txt @@ -0,0 +1,57 @@ +Nokia modem client bindings + +The Nokia modem HSI client follows the common HSI client binding +and inherits all required properties. The following additional +properties are needed by the Nokia modem HSI client: + +Required properties: +- compatible: Should be one of + "nokia,n900-modem" +- hsi-channel-names: Should contain the following strings + "mcsaab-control" + "speech-control" + "speech-data" + "mcsaab-data" +- gpios: Should provide a GPIO handler for each GPIO listed in + gpio-names +- gpio-names: Should contain the following strings + "cmt_apeslpx" + "cmt_rst_rq" + "cmt_en" + "cmt_rst" + "cmt_bsi" +- interrupts: Should be IRQ handle for modem's reset indication + +Example: + +&ssi_port { + modem: hsi-client { + compatible = "nokia,n900-modem"; + + pinctrl-names = "default"; + pinctrl-0 = <&modem_pins>; + + hsi-channel-ids = <0>, <1>, <2>, <3>; + hsi-channel-names = "mcsaab-control", + "speech-control", + "speech-data", + "mcsaab-data"; + hsi-speed-kbps = <55000>; + hsi-mode = "frame"; + hsi-flow = "synchronized"; + hsi-arb-mode = "round-robin"; + + interrupts-extended = <&gpio3 8 IRQ_TYPE_EDGE_FALLING>; /* 72 */ + + gpios = <&gpio3 6 GPIO_ACTIVE_HIGH>, /* 70 */ + <&gpio3 9 GPIO_ACTIVE_HIGH>, /* 73 */ + <&gpio3 10 GPIO_ACTIVE_HIGH>, /* 74 */ + <&gpio3 11 GPIO_ACTIVE_HIGH>, /* 75 */ + <&gpio5 29 GPIO_ACTIVE_HIGH>; /* 157 */ + gpio-names = "cmt_apeslpx", + "cmt_rst_rq", + "cmt_en", + "cmt_rst", + "cmt_bsi"; + }; +}; diff --git a/Documentation/devicetree/bindings/hsi/omap-ssi.txt b/Documentation/devicetree/bindings/hsi/omap-ssi.txt new file mode 100644 index 0000000..f26625e --- /dev/null +++ b/Documentation/devicetree/bindings/hsi/omap-ssi.txt @@ -0,0 +1,97 @@ +OMAP SSI controller bindings + +OMAP Synchronous Serial Interface (SSI) controller implements a legacy +variant of MIPI's High Speed Synchronous Serial Interface (HSI). + +Required properties: +- compatible: Should include "ti,omap3-ssi". +- reg-names: Contains the values "sys" and "gdd" (in this order). +- reg: Contains a matching register specifier for each entry + in reg-names. +- interrupt-names: Contains the value "gdd_mpu". +- interrupts: Contains matching interrupt information for each entry + in interrupt-names. +- ranges: Represents the bus address mapping between the main + controller node and the child nodes below. +- clock-names: Must include the following entries: + "ssi_ssr_fck": The OMAP clock of that name + "ssi_sst_fck": The OMAP clock of that name + "ssi_ick": The OMAP clock of that name +- clocks: Contains a matching clock specifier for each entry in + clock-names. +- #address-cells: Should be set to <1> +- #size-cells: Should be set to <1> + +Each port is represented as a sub-node of the ti,omap3-ssi device. + +Required Port sub-node properties: +- compatible: Should be set to the following value + ti,omap3-ssi-port (applicable to OMAP34xx devices) +- reg-names: Contains the values "tx" and "rx" (in this order). +- reg: Contains a matching register specifier for each entry + in reg-names. +- interrupt-parent Should be a phandle for the interrupt controller +- interrupts: Should contain interrupt specifiers for mpu interrupts + 0 and 1 (in this order). +- ti,ssi-cawake-gpio: Defines which GPIO pin is used to signify CAWAKE + events for the port. This is an optional board-specific + property. If it's missing the port will not be + enabled. + +Example for Nokia N900: + +ssi-controller@48058000 { + compatible = "ti,omap3-ssi"; + + /* needed until hwmod is updated to use the compatible string */ + ti,hwmods = "ssi"; + + reg = <0x48058000 0x1000>, + <0x48059000 0x1000>; + reg-names = "sys", + "gdd"; + + interrupts = <55>; + interrupt-names = "gdd_mpu"; + + clocks = <&ssi_ssr_fck>, + <&ssi_sst_fck>, + <&ssi_ick>; + clock-names = "ssi_ssr_fck", + "ssi_sst_fck", + "ssi_ick"; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + ssi-port@4805a000 { + compatible = "ti,omap3-ssi-port"; + + reg = <0x4805a000 0x800>, + <0x4805a800 0x800>; + reg-names = "tx", + "rx"; + + interrupt-parent = <&intc>; + interrupts = <67>, + <68>; + + ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */ + } + + ssi-port@4805a000 { + compatible = "ti,omap3-ssi-port"; + + reg = <0x4805b000 0x800>, + <0x4805b800 0x800>; + reg-names = "tx", + "rx"; + + interrupt-parent = <&intc>; + interrupts = <69>, + <70>; + + status = "disabled"; /* second port is not used on N900 */ + } +} diff --git a/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt b/Documentation/devicetree/bindings/hwmon/ibmpowernv.txt new file mode 100644 index 0000000..f93242b --- /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 c6f6667..2391e5c 100644 --- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt +++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt @@ -3,11 +3,20 @@ NTC Thermistor hwmon sensors Requires node properties: - "compatible" value : one of - "ntc,ncp15wb473" - "ntc,ncp18wb473" - "ntc,ncp21wb473" - "ntc,ncp03wb473" - "ntc,ncp15wl333" + "epcos,b57330v2103" + "murata,ncp15wb473" + "murata,ncp18wb473" + "murata,ncp21wb473" + "murata,ncp03wb473" + "murata,ncp15wl333" + +/* Usage of vendor name "ntc" is deprecated */ +<DEPRECATED> "ntc,ncp15wb473" +<DEPRECATED> "ntc,ncp18wb473" +<DEPRECATED> "ntc,ncp21wb473" +<DEPRECATED> "ntc,ncp03wb473" +<DEPRECATED> "ntc,ncp15wl333" + - "pullup-uv" Pull up voltage in micro volts - "pullup-ohm" Pull up resistor value in ohms - "pulldown-ohm" Pull down resistor value in ohms @@ -21,7 +30,7 @@ Read more about iio bindings at Example: ncp15wb473@0 { - compatible = "ntc,ncp15wb473"; + compatible = "murata,ncp15wb473"; pullup-uv = <1800000>; pullup-ohm = <47000>; pulldown-ohm = <0>; diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt new file mode 100644 index 0000000..610757c --- /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/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt index 1ac8ea8..bfeabb8 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt @@ -8,6 +8,12 @@ the standard I2C multi-master rules. Using GPIOs is generally useful in the case where there is a device on the bus that has errata and/or bugs that makes standard multimaster mode not feasible. +Note that this scheme works well enough but has some downsides: +* It is nonstandard (not using standard I2C multimaster) +* Having two masters on a bus in general makes it relatively hard to debug + problems (hard to tell if i2c issues were caused by one master, another, or + some device on the bus). + Algorithm: diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt index 4fade84..388f0a2 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt @@ -12,6 +12,7 @@ Required properties : - clocks: phandles to input clocks. Optional properties: +- clock-frequency: Desired I2C bus frequency in Hz, otherwise defaults to 100000 - Child nodes conforming to i2c bus binding Examples : @@ -23,6 +24,7 @@ i2c0: i2c@fff84000 { #address-cells = <1>; #size-cells = <0>; clocks = <&twi0_clk>; + clock-frequency = <400000>; 24c512@50 { compatible = "24c512"; diff --git a/Documentation/devicetree/bindings/i2c/i2c-cadence.txt b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt new file mode 100644 index 0000000..7cb0b56 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt @@ -0,0 +1,24 @@ +Binding for the Cadence I2C controller + +Required properties: + - reg: Physical base address and size of the controller's register area. + - compatible: Compatibility string. Must be 'cdns,i2c-r1p10'. + - clocks: Input clock specifier. Refer to common clock bindings. + - interrupts: Interrupt specifier. Refer to interrupt bindings. + - #address-cells: Should be 1. + - #size-cells: Should be 0. + +Optional properties: + - clock-frequency: Desired operating frequency, in Hz, of the bus. + - clock-names: Input clock name, should be 'pclk'. + +Example: + i2c@e0004000 { + compatible = "cdns,i2c-r1p10"; + clocks = <&clkc 38>; + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; + reg = <0xe0004000 0x1000>; + clock-frequency = <400000>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt new file mode 100644 index 0000000..898f030 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt @@ -0,0 +1,39 @@ +I2C bus that tunnels through the ChromeOS EC (cros-ec) +====================================================== +On some ChromeOS board designs we've got a connection to the EC (embedded +controller) but no direct connection to some devices on the other side of +the EC (like a battery and PMIC). To get access to those devices we need +to tunnel our i2c commands through the EC. + +The node for this device should be under a cros-ec node like google,cros-ec-spi +or google,cros-ec-i2c. + + +Required properties: +- compatible: google,cros-ec-i2c-tunnel +- google,remote-bus: The EC bus we'd like to talk to. + +Optional child nodes: +- One node per I2C device connected to the tunnelled I2C bus. + + +Example: + cros-ec@0 { + compatible = "google,cros-ec-spi"; + + ... + + i2c-tunnel { + compatible = "google,cros-ec-i2c-tunnel"; + #address-cells = <1>; + #size-cells = <0>; + + google,remote-bus = <0>; + + battery: sbs-battery@b { + compatible = "sbs,sbs-battery"; + reg = <0xb>; + sbs,poll-retry-count = <1>; + }; + }; + } diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt b/Documentation/devicetree/bindings/i2c/i2c-designware.txt index 7fd7fa2..5199b0c 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt @@ -14,6 +14,12 @@ Optional properties : - i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds. This option is only supported in hardware blocks version 1.11a or newer. + - i2c-scl-falling-time : should contain the SCL falling time in nanoseconds. + This value which is by default 300ns is used to compute the tLOW period. + + - i2c-sda-falling-time : should contain the SDA falling time in nanoseconds. + This value which is by default 300ns is used to compute the tHIGH period. + Example : i2c@f0000 { @@ -34,4 +40,6 @@ Example : interrupts = <12 1>; clock-frequency = <400000>; i2c-sda-hold-time-ns = <300>; + i2c-sda-falling-time-ns = <300>; + i2c-scl-falling-time-ns = <300>; }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-efm32.txt b/Documentation/devicetree/bindings/i2c/i2c-efm32.txt new file mode 100644 index 0000000..fc15ac5 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-efm32.txt @@ -0,0 +1,34 @@ +* Energymicro efm32 i2c controller + +Required properties : + + - reg : Offset and length of the register set for the device + - compatible : should be "energymicro,efm32-i2c" + - interrupts : the interrupt number + - clocks : reference to the module clock + +Recommended properties : + + - clock-frequency : maximal I2C bus clock frequency in Hz. + - efm32,location : Decides the location of the USART I/O pins. + Allowed range : [0 .. 6] + +Example: + i2c0: i2c@4000a000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "energymicro,efm32-i2c"; + reg = <0x4000a000 0x400>; + interrupts = <9>; + clocks = <&cmu clk_HFPERCLKI2C0>; + clock-frequency = <100000>; + status = "ok"; + efm32,location = <3>; + + eeprom@50 { + compatible = "microchip,24c02"; + reg = <0x50>; + pagesize = <16>; + }; + }; + diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt index 056732c..d4745e3 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt @@ -5,7 +5,14 @@ at various speeds ranging from 100khz to 3.4Mhz. Required properties: - compatible: value should be. - -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c. + -> "samsung,exynos5-hsi2c", (DEPRECATED) + for i2c compatible with HSI2C available + on Exynos5250 and Exynos5420 SoCs. + -> "samsung,exynos5250-hsi2c", for i2c compatible with HSI2C available + on Exynos5250 and Exynos5420 SoCs. + -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C available + on Exynos5260 SoCs. + - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt number to the cpu. @@ -26,7 +33,7 @@ Optional properties: Example: hsi2c@12ca0000 { - compatible = "samsung,exynos5-hsi2c"; + compatible = "samsung,exynos5250-hsi2c"; reg = <0x12ca0000 0x100>; interrupts = <56>; clock-frequency = <100000>; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt index 582b465..5c30026 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt @@ -4,12 +4,16 @@ Required properties : - reg : Offset and length of the register set for the device - - compatible : Should be "marvell,mv64xxx-i2c" or "allwinner,sun4i-i2c" - or "marvell,mv78230-i2c" or "marvell,mv78230-a0-i2c" - Note: Only use "marvell,mv78230-a0-i2c" for a very rare, - initial version of the SoC which had broken offload - support. Linux auto-detects this and sets it - appropriately. + - compatible : Should be either: + - "allwinner,sun4i-a10-i2c" + - "allwinner,sun6i-a31-i2c" + - "marvell,mv64xxx-i2c" + - "marvell,mv78230-i2c" + - "marvell,mv78230-a0-i2c" + * Note: Only use "marvell,mv78230-a0-i2c" for a + very rare, initial version of the SoC which + had broken offload support. Linux + auto-detects this and sets it appropriately. - interrupts : The interrupt number Optional properties : @@ -17,6 +21,10 @@ Optional properties : - clock-frequency : Desired I2C bus clock frequency in Hz. If not set the default frequency is 100kHz + - resets : phandle to the parent reset controller. Mandatory + whenever you're using the "allwinner,sun6i-a31-i2c" + compatible. + Examples: i2c@11000 { diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt index 897cfcd5..16b3e07 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt @@ -6,6 +6,10 @@ Required properties: "renesas,i2c-r8a7778" "renesas,i2c-r8a7779" "renesas,i2c-r8a7790" + "renesas,i2c-r8a7791" + "renesas,i2c-r8a7792" + "renesas,i2c-r8a7793" + "renesas,i2c-r8a7794" - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt specifier. @@ -13,11 +17,16 @@ Required properties: Optional properties: - clock-frequency: desired I2C bus clock frequency in Hz. The absence of this propoerty indicates the default frequency 100 kHz. +- clocks: clock specifier. Examples : -i2c0: i2c@e6500000 { - compatible = "renesas,i2c-rcar-h2"; - reg = <0 0xe6500000 0 0x428>; - interrupts = <0 174 0x4>; +i2c0: i2c@e6508000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "renesas,i2c-r8a7791"; + reg = <0 0xe6508000 0 0x40>; + interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp9_clks R8A7791_CLK_I2C0>; + clock-frequency = <400000>; }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt new file mode 100644 index 0000000..dde6c22 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.txt @@ -0,0 +1,42 @@ +* Rockchip RK3xxx I2C controller + +This driver interfaces with the native I2C controller present in Rockchip +RK3xxx SoCs. + +Required properties : + + - reg : Offset and length of the register set for the device + - compatible : should be "rockchip,rk3066-i2c", "rockchip,rk3188-i2c" or + "rockchip,rk3288-i2c". + - interrupts : interrupt number + - clocks : parent clock + +Required on RK3066, RK3188 : + + - rockchip,grf : the phandle of the syscon node for the general register + file (GRF) + - on those SoCs an alias with the correct I2C bus ID (bit offset in the GRF) + is also required. + +Optional properties : + + - clock-frequency : SCL frequency to use (in Hz). If omitted, 100kHz is used. + +Example: + +aliases { + i2c0 = &i2c0; +} + +i2c0: i2c@2002d000 { + compatible = "rockchip,rk3188-i2c"; + reg = <0x2002d000 0x1000>; + interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + + rockchip,grf = <&grf>; + + clock-names = "i2c"; + clocks = <&cru PCLK_I2C0>; +}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt new file mode 100644 index 0000000..d2153ce --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt @@ -0,0 +1,26 @@ +Device tree configuration for Renesas IIC (sh_mobile) driver + +Required properties: +- compatible : "renesas,iic-<soctype>". "renesas,rmobile-iic" as fallback +- reg : address start and address range size of device +- interrupts : interrupt of device +- clocks : clock for device +- #address-cells : should be <1> +- #size-cells : should be <0> + +Optional properties: +- clock-frequency : frequency of bus clock in Hz. Default 100kHz if unset. + +Pinctrl properties might be needed, too. See there. + +Example: + + iic0: i2c@e6500000 { + compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic"; + reg = <0 0xe6500000 0 0x425>; + interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp3_clks R8A7790_CLK_IIC0>; + clock-frequency = <400000>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt b/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt new file mode 100644 index 0000000..6b76548 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt @@ -0,0 +1,41 @@ + +* Allwinner P2WI (Push/Pull 2 Wire Interface) controller + +Required properties : + + - reg : Offset and length of the register set for the device. + - compatible : Should one of the following: + - "allwinner,sun6i-a31-p2wi" + - interrupts : The interrupt line connected to the P2WI peripheral. + - clocks : The gate clk connected to the P2WI peripheral. + - resets : The reset line connected to the P2WI peripheral. + +Optional properties : + + - clock-frequency : Desired P2WI bus clock frequency in Hz. If not set the +default frequency is 100kHz + +A P2WI may contain one child node encoding a P2WI slave device. + +Slave device properties: + Required properties: + - reg : the I2C slave address used during the initialization + process to switch from I2C to P2WI mode + +Example: + + p2wi@01f03400 { + compatible = "allwinner,sun6i-a31-p2wi"; + reg = <0x01f03400 0x400>; + interrupts = <0 39 4>; + clocks = <&apb0_gates 3>; + clock-frequency = <6000000>; + resets = <&apb0_rst 3>; + + axp221: pmic@68 { + compatible = "x-powers,axp221"; + reg = <0x68>; + + /* ... */ + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt new file mode 100644 index 0000000..dc71754 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt @@ -0,0 +1,40 @@ +Qualcomm Universal Peripheral (QUP) I2C controller + +Required properties: + - compatible: Should be: + * "qcom,i2c-qup-v1.1.1" for 8660, 8960 and 8064. + * "qcom,i2c-qup-v2.1.1" for 8974 v1. + * "qcom,i2c-qup-v2.2.1" for 8974 v2 and later. + - reg: Should contain QUP register address and length. + - interrupts: Should contain I2C interrupt. + + - clocks: A list of phandles + clock-specifiers, one for each entry in + clock-names. + - clock-names: Should contain: + * "core" for the core clock + * "iface" for the AHB clock + + - #address-cells: Should be <1> Address cells for i2c device address + - #size-cells: Should be <0> as i2c addresses have no size component + +Optional properties: + - clock-frequency: Should specify the desired i2c bus clock frequency in Hz, + defaults to 100kHz if omitted. + +Child nodes should conform to i2c bus binding. + +Example: + + i2c@f9924000 { + compatible = "qcom,i2c-qup-v2.2.1"; + reg = <0xf9924000 0x1000>; + interrupts = <0 96 0>; + + clocks = <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>; + clock-names = "core", "iface"; + + clock-frequency = <355000>; + + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index f47e56b..37803eb 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -13,8 +13,22 @@ ad,ad7414 SMBus/I2C Digital Temperature Sensor in 6-Pin SOT with SMBus Alert an ad,adm9240 ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems adi,adt7461 +/-1C TDM Extended Temp Range I.C adt7461 +/-1C TDM Extended Temp Range I.C +adi,adt7473 +/-1C TDM Extended Temp Range I.C +adi,adt7475 +/-1C TDM Extended Temp Range I.C +adi,adt7476 +/-1C TDM Extended Temp Range I.C +adi,adt7490 +/-1C TDM Extended Temp Range I.C at,24c08 i2c serial eeprom (24cxx) +atmel,24c00 i2c serial eeprom (24cxx) +atmel,24c01 i2c serial eeprom (24cxx) atmel,24c02 i2c serial eeprom (24cxx) +atmel,24c04 i2c serial eeprom (24cxx) +atmel,24c16 i2c serial eeprom (24cxx) +atmel,24c32 i2c serial eeprom (24cxx) +atmel,24c64 i2c serial eeprom (24cxx) +atmel,24c128 i2c serial eeprom (24cxx) +atmel,24c256 i2c serial eeprom (24cxx) +atmel,24c512 i2c serial eeprom (24cxx) +atmel,24c1024 i2c serial eeprom (24cxx) atmel,at97sc3204t i2c trusted platform module (TPM) capella,cm32181 CM32181: Ambient Light Sensor catalyst,24c32 i2c serial eeprom @@ -36,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 @@ -46,8 +61,10 @@ maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface mc,rv3029c2 Real Time Clock Module with I2C-Bus +national,lm63 Temperature sensor with integrated fan control national,lm75 I2C TEMP SENSOR national,lm80 Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor +national,lm85 Temperature sensor with integrated fan control national,lm92 ±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator with Two-Wire Interface nuvoton,npct501 i2c trusted platform module (TPM) nxp,pca9556 Octal SMBus and I2C registered interface @@ -59,6 +76,7 @@ plx,pex8648 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch ramtron,24c64 i2c serial eeprom (24cxx) ricoh,rs5c372a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power) +sii,s35390a 2-wire CMOS real-time clock st-micro,24c256 i2c serial eeprom (24cxx) stm,m41t00 Serial Access TIMEKEEPER stm,m41t62 Serial real-time clock (RTC) with alarm @@ -66,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/arm/atmel-adc.txt b/Documentation/devicetree/bindings/iio/adc/at91_adc.txt index 9a1175b..0f813de 100644 --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt +++ b/Documentation/devicetree/bindings/iio/adc/at91_adc.txt @@ -8,32 +8,32 @@ Required properties: - clock-names: tuple listing input clock names. Required elements: "adc_clk", "adc_op_clk". - clocks: phandles to input clocks. - - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this + - atmel,adc-channels-used: Bitmask of the channels muxed and enabled for this device - atmel,adc-startup-time: Startup Time of the ADC in microseconds as defined in the datasheet - atmel,adc-vref: Reference voltage in millivolts for the conversions - - atmel,adc-res: List of resolution in bits supported by the ADC. List size + - atmel,adc-res: List of resolutions in bits supported by the ADC. List size must be two at least. - atmel,adc-res-names: Contains one identifier string for each resolution in atmel,adc-res property. "lowres" and "highres" identifiers are required. Optional properties: - - atmel,adc-use-external: Boolean to enable of external triggers + - atmel,adc-use-external-triggers: Boolean to enable the external triggers - atmel,adc-use-res: String corresponding to an identifier from atmel,adc-res-names property. If not specified, the highest resolution will be used. - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds - - atmel,adc-ts-wires: Number of touch screen wires. Should be 4 or 5. If this - value is set, then adc driver will enable touch screen + - atmel,adc-ts-wires: Number of touchscreen wires. Should be 4 or 5. If this + value is set, then the adc driver will enable touchscreen support. - NOTE: when adc touch screen enabled, the adc hardware trigger will be - disabled. Since touch screen will occupied the trigger register. + NOTE: when adc touchscreen is enabled, the adc hardware trigger will be + disabled. Since touchscreen will occupy the trigger register. - atmel,adc-ts-pressure-threshold: a pressure threshold for touchscreen. It - make touch detect more precision. - + makes touch detection more precise. + Optional trigger Nodes: - Required properties: * trigger-name: Name of the trigger exposed to the user @@ -44,42 +44,43 @@ Optional trigger Nodes: Examples: adc0: adc@fffb0000 { + #address-cells = <1>; + #size-cells = <0>; compatible = "atmel,at91sam9260-adc"; reg = <0xfffb0000 0x100>; - interrupts = <20 4>; + interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>; clocks = <&adc_clk>, <&adc_op_clk>; clock-names = "adc_clk", "adc_op_clk"; - atmel,adc-channel-base = <0x30>; atmel,adc-channels-used = <0xff>; - atmel,adc-drdy-mask = <0x10000>; - atmel,adc-num-channels = <8>; atmel,adc-startup-time = <40>; - atmel,adc-status-register = <0x1c>; - atmel,adc-trigger-register = <0x08>; - atmel,adc-use-external; + atmel,adc-use-external-triggers; atmel,adc-vref = <3300>; atmel,adc-res = <8 10>; atmel,adc-res-names = "lowres", "highres"; atmel,adc-use-res = "lowres"; trigger@0 { + reg = <0>; trigger-name = "external-rising"; trigger-value = <0x1>; trigger-external; }; trigger@1 { + reg = <1>; trigger-name = "external-falling"; trigger-value = <0x2>; trigger-external; }; trigger@2 { + reg = <2>; trigger-name = "external-any"; trigger-value = <0x3>; trigger-external; }; trigger@3 { + reg = <3>; trigger-name = "continuous"; trigger-value = <0x6>; }; 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 0000000..a8770cc --- /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/adc/twl4030-madc.txt b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt new file mode 100644 index 0000000..6bdd214 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt @@ -0,0 +1,24 @@ +* TWL4030 Monitoring Analog to Digital Converter (MADC) + +The MADC subsystem in the TWL4030 consists of a 10-bit ADC +combined with a 16-input analog multiplexer. + +Required properties: + - compatible: Should contain "ti,twl4030-madc". + - interrupts: IRQ line for the MADC submodule. + - #io-channel-cells: Should be set to <1>. + +Optional properties: + - ti,system-uses-second-madc-irq: boolean, set if the second madc irq register + should be used, which is intended to be used + by Co-Processors (e.g. a modem). + +Example: + +&twl { + madc { + compatible = "ti,twl4030-madc"; + interrupts = <3>; + #io-channel-cells = <1>; + }; +}; diff --git a/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt b/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt index 90d5f34..8e191ee 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/proximity/as3935.txt b/Documentation/devicetree/bindings/iio/proximity/as3935.txt new file mode 100644 index 0000000..ae23dd8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt @@ -0,0 +1,28 @@ +Austrian Microsystems AS3935 Franklin lightning sensor device driver + +Required properties: + - compatible: must be "ams,as3935" + - reg: SPI chip select number for the device + - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI + slave node bindings. + - interrupt-parent : should be the phandle for the interrupt controller + - interrupts : the sole interrupt generated by the device + + Refer to interrupt-controller/interrupts.txt for generic + interrupt client node bindings. + +Optional properties: + - ams,tuning-capacitor-pf: Calibration tuning capacitor stepping + value 0 - 120pF. This will require using the calibration data from + the manufacturer. + +Example: + +as3935@0 { + compatible = "ams,as3935"; + reg = <0>; + spi-cpha; + interrupt-parent = <&gpio1>; + interrupts = <16 1>; + ams,tuning-capacitor-pf = <80>; +}; diff --git a/Documentation/devicetree/bindings/iio/st-sensors.txt b/Documentation/devicetree/bindings/iio/st-sensors.txt new file mode 100644 index 0000000..a7a0a15 --- /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/input/clps711x-keypad.txt b/Documentation/devicetree/bindings/input/clps711x-keypad.txt new file mode 100644 index 0000000..e68d2bb --- /dev/null +++ b/Documentation/devicetree/bindings/input/clps711x-keypad.txt @@ -0,0 +1,27 @@ +* Cirrus Logic CLPS711X matrix keypad device tree bindings + +Required Properties: +- compatible: Shall contain "cirrus,clps711x-keypad". +- row-gpios: List of GPIOs used as row lines. +- poll-interval: Poll interval time in milliseconds. +- linux,keymap: The definition can be found at + bindings/input/matrix-keymap.txt. + +Optional Properties: +- autorepeat: Enable autorepeat feature. + +Example: + keypad { + compatible = "cirrus,ep7312-keypad", "cirrus,clps711x-keypad"; + autorepeat; + poll-interval = <120>; + row-gpios = <&porta 0 0>, + <&porta 1 0>; + + linux,keymap = < + MATRIX_KEY(0, 0, KEY_UP) + MATRIX_KEY(0, 1, KEY_DOWN) + MATRIX_KEY(1, 0, KEY_LEFT) + MATRIX_KEY(1, 1, KEY_RIGHT) + >; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio_keys.txt b/Documentation/devicetree/bindings/input/gpio-keys.txt index 5c2c021..5c2c021 100644 --- a/Documentation/devicetree/bindings/gpio/gpio_keys.txt +++ b/Documentation/devicetree/bindings/input/gpio-keys.txt diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt new file mode 100644 index 0000000..7d8cb92 --- /dev/null +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt @@ -0,0 +1,89 @@ +Qualcomm PM8xxx PMIC Keypad + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8058-keypad" + "qcom,pm8921-keypad" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: address of keypad control register + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: the first interrupt specifies the key sense interrupt + and the second interrupt specifies the key stuck interrupt. + The format of the specifier is defined by the binding + document describing the node's interrupt parent. + +- linux,keymap: + Usage: required + Value type: <prop-encoded-array> + Definition: the linux keymap. More information can be found in + input/matrix-keymap.txt. + +- linux,keypad-no-autorepeat: + Usage: optional + Value type: <bool> + Definition: don't enable autorepeat feature. + +- linux,keypad-wakeup: + Usage: optional + Value type: <bool> + Definition: use any event on keypad as wakeup event. + +- keypad,num-rows: + Usage: required + Value type: <u32> + Definition: number of rows in the keymap. More information can be found + in input/matrix-keymap.txt. + +- keypad,num-columns: + Usage: required + Value type: <u32> + Definition: number of columns in the keymap. More information can be + found in input/matrix-keymap.txt. + +- debounce: + Usage: optional + Value type: <u32> + Definition: time in microseconds that key must be pressed or release + for key sense interrupt to trigger. + +- scan-delay: + Usage: optional + Value type: <u32> + Definition: time in microseconds to pause between successive scans + of the matrix array. + +- row-hold: + Usage: optional + Value type: <u32> + Definition: time in nanoseconds to pause between scans of each row in + the matrix array. + +EXAMPLE + + keypad@148 { + compatible = "qcom,pm8921-keypad"; + reg = <0x148>; + interrupt-parent = <&pmicintc>; + interrupts = <74 1>, <75 1>; + linux,keymap = < + MATRIX_KEY(0, 0, KEY_VOLUMEUP) + MATRIX_KEY(0, 1, KEY_VOLUMEDOWN) + MATRIX_KEY(0, 2, KEY_CAMERA_FOCUS) + MATRIX_KEY(0, 3, KEY_CAMERA) + >; + keypad,num-rows = <1>; + keypad,num-columns = <5>; + debounce = <15>; + scan-delay = <32>; + row-hold = <91500>; + }; diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt new file mode 100644 index 0000000..588536c --- /dev/null +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt @@ -0,0 +1,46 @@ +Qualcomm PM8xxx PMIC Power Key + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8058-pwrkey" + "qcom,pm8921-pwrkey" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: address of power key control register + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: the first interrupt specifies the key release interrupt + and the second interrupt specifies the key press interrupt. + The format of the specifier is defined by the binding + document describing the node's interrupt parent. + +- debounce: + Usage: optional + Value type: <u32> + Definition: time in microseconds that key must be pressed or release + for state change interrupt to trigger. + +- pull-up: + Usage: optional + Value type: <empty> + Definition: presence of this property indicates that the KPDPWR_N pin + should be configured for pull up. + +EXAMPLE + + pwrkey@1c { + compatible = "qcom,pm8921-pwrkey"; + reg = <0x1c>; + interrupt-parent = <&pmicintc>; + interrupts = <50 1>, <51 1>; + debounce = <15625>; + pull-up; + }; diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt new file mode 100644 index 0000000..4ed467b --- /dev/null +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt @@ -0,0 +1,22 @@ +Qualcomm PM8xxx PMIC Vibrator + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8058-vib" + "qcom,pm8921-vib" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: address of vibration control register + +EXAMPLE + + vibrator@4a { + compatible = "qcom,pm8058-vib"; + reg = <0x4a>; + }; diff --git a/Documentation/devicetree/bindings/input/st-keyscan.txt b/Documentation/devicetree/bindings/input/st-keyscan.txt new file mode 100644 index 0000000..51eb428 --- /dev/null +++ b/Documentation/devicetree/bindings/input/st-keyscan.txt @@ -0,0 +1,60 @@ +* ST Keyscan controller Device Tree bindings + +The ST keyscan controller Device Tree binding is based on the +matrix-keymap. + +Required properties: +- compatible: "st,sti-keyscan" + +- reg: Register base address and size of st-keyscan controller. + +- interrupts: Interrupt number for the st-keyscan controller. + +- clocks: Must contain one entry, for the module clock. + See ../clocks/clock-bindings.txt for details. + +- pinctrl: Should specify pin control groups used for this controller. + See ../pinctrl/pinctrl-bindings.txt for details. + +- linux,keymap: The keymap for keys as described in the binding document + devicetree/bindings/input/matrix-keymap.txt. + +- keypad,num-rows: Number of row lines connected to the keypad controller. + +- keypad,num-columns: Number of column lines connected to the keypad + controller. + +Optional property: +- st,debounce_us: Debouncing interval time in microseconds + +Example: + +keyscan: keyscan@fe4b0000 { + compatible = "st,sti-keyscan"; + reg = <0xfe4b0000 0x2000>; + interrupts = <GIC_SPI 212 IRQ_TYPE_NONE>; + clocks = <&CLK_SYSIN>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_keyscan>; + + keypad,num-rows = <4>; + keypad,num-columns = <4>; + st,debounce_us = <5000>; + + linux,keymap = < MATRIX_KEY(0x00, 0x00, KEY_F13) + MATRIX_KEY(0x00, 0x01, KEY_F9) + MATRIX_KEY(0x00, 0x02, KEY_F5) + MATRIX_KEY(0x00, 0x03, KEY_F1) + MATRIX_KEY(0x01, 0x00, KEY_F14) + MATRIX_KEY(0x01, 0x01, KEY_F10) + MATRIX_KEY(0x01, 0x02, KEY_F6) + MATRIX_KEY(0x01, 0x03, KEY_F2) + MATRIX_KEY(0x02, 0x00, KEY_F15) + MATRIX_KEY(0x02, 0x01, KEY_F11) + MATRIX_KEY(0x02, 0x02, KEY_F7) + MATRIX_KEY(0x02, 0x03, KEY_F3) + MATRIX_KEY(0x03, 0x00, KEY_F16) + MATRIX_KEY(0x03, 0x01, KEY_F12) + MATRIX_KEY(0x03, 0x02, KEY_F8) + MATRIX_KEY(0x03, 0x03, KEY_F4) >; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt new file mode 100644 index 0000000..76db967 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt @@ -0,0 +1,55 @@ +FocalTech EDT-FT5x06 Polytouch driver +===================================== + +There are 3 variants of the chip for various touch panel sizes +FT5206GE1 2.8" .. 3.8" +FT5306DE4 4.3" .. 7" +FT5406EE8 7" .. 8.9" + +The software interface is identical for all those chips, so that +currently there is no need for the driver to distinguish between the +different chips. Nevertheless distinct compatible strings are used so +that a distinction can be added if necessary without changing the DT +bindings. + + +Required properties: + - compatible: "edt,edt-ft5206" + or: "edt,edt-ft5306" + or: "edt,edt-ft5406" + + - reg: I2C slave address of the chip (0x38) + - interrupt-parent: a phandle pointing to the interrupt controller + serving the interrupt for this chip + - interrupts: interrupt specification for the touchdetect + interrupt + +Optional properties: + - reset-gpios: GPIO specification for the RESET input + - wake-gpios: GPIO specification for the WAKE input + + - pinctrl-names: should be "default" + - pinctrl-0: a phandle pointing to the pin settings for the + control gpios + + - threshold: allows setting the "click"-threshold in the range + from 20 to 80. + + - gain: allows setting the sensitivity in the range from 0 to + 31. Note that lower values indicate higher + sensitivity. + + - offset: allows setting the edge compensation in the range from + 0 to 31. + +Example: + polytouch: edt-ft5x06@38 { + compatible = "edt,edt-ft5406", "edt,edt-ft5x06"; + reg = <0x38>; + pinctrl-names = "default"; + pinctrl-0 = <&edt_ft5x06_pins>; + interrupt-parent = <&gpio2>; + interrupts = <5 0>; + reset-gpios = <&gpio2 6 1>; + wake-gpios = <&gpio4 9 0>; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt new file mode 100644 index 0000000..aef5779 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt @@ -0,0 +1,20 @@ +sun4i resistive touchscreen controller +-------------------------------------- + +Required properties: + - compatible: "allwinner,sun4i-a10-ts" + - reg: mmio address range of the chip + - interrupts: interrupt to which the chip is connected + +Optional properties: + - allwinner,ts-attached: boolean indicating that an actual touchscreen is + attached to the controller + +Example: + + rtp: rtp@01c25000 { + compatible = "allwinner,sun4i-a10-ts"; + reg = <0x01c25000 0x100>; + interrupts = <29>; + allwinner,ts-attached; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt new file mode 100644 index 0000000..d8e06163 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt @@ -0,0 +1,27 @@ +General Touchscreen Properties: + +Optional properties for Touchscreens: + - touchscreen-size-x : horizontal resolution of touchscreen + (in pixels) + - touchscreen-size-y : vertical resolution of touchscreen + (in pixels) + - touchscreen-max-pressure : maximum reported pressure (arbitrary range + dependent on the controller) + - touchscreen-fuzz-x : horizontal noise value of the absolute input + device (in pixels) + - touchscreen-fuzz-y : vertical noise value of the absolute input + device (in pixels) + - touchscreen-fuzz-pressure : pressure noise value of the absolute input + device (arbitrary range dependent on the + controller) + - touchscreen-inverted-x : X axis is inverted (boolean) + - touchscreen-inverted-y : Y axis is inverted (boolean) + +Deprecated properties for Touchscreens: + - x-size : deprecated name for touchscreen-size-x + - y-size : deprecated name for touchscreen-size-y + - moving-threshold : deprecated name for a combination of + touchscreen-fuzz-x and touchscreen-fuzz-y + - contact-threshold : deprecated name for touchscreen-fuzz-pressure + - x-invert : deprecated name for touchscreen-inverted-x + - y-invert : deprecated name for touchscreen-inverted-y diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt new file mode 100644 index 0000000..4b641c7 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt @@ -0,0 +1,42 @@ +* Texas Instruments tsc2005 touchscreen controller + +Required properties: + - compatible : "ti,tsc2005" + - reg : SPI device address + - spi-max-frequency : Maximal SPI speed + - interrupts : IRQ specifier + - reset-gpios : GPIO specifier + - vio-supply : Regulator specifier + +Optional properties: + - ti,x-plate-ohms : integer, resistance of the touchscreen's X plates + in ohm (defaults to 280) + - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after + the configured time (in milli seconds), the driver + will reset it. This is disabled by default. + - properties defined in touchscreen.txt + +Example: + +&mcspi1 { + tsc2005@0 { + compatible = "ti,tsc2005"; + spi-max-frequency = <6000000>; + reg = <0>; + + vio-supply = <&vio>; + + reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */ + interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */ + + touchscreen-fuzz-x = <4>; + touchscreen-fuzz-y = <7>; + touchscreen-fuzz-pressure = <2>; + touchscreen-max-x = <4096>; + touchscreen-max-y = <4096>; + touchscreen-max-pressure = <2048>; + + ti,x-plate-ohms = <280>; + ti,esd-recovery-timeout-ms = <8000>; + }; +} diff --git a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt new file mode 100644 index 0000000..2faf1f1 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt @@ -0,0 +1,30 @@ +* Neonode infrared touchscreen controller + +Required properties: +- compatible: must be "neonode,zforce" +- reg: I2C address of the chip +- interrupts: interrupt to which the chip is connected +- gpios: gpios the chip is connected to + first one is the interrupt gpio and second one the reset gpio +- x-size: horizontal resolution of touchscreen +- y-size: vertical resolution of touchscreen + +Example: + + i2c@00000000 { + /* ... */ + + zforce_ts@50 { + compatible = "neonode,zforce"; + reg = <0x50>; + interrupts = <2 0>; + + gpios = <&gpio5 6 0>, /* INT */ + <&gpio5 9 0>; /* RST */ + + x-size = <800>; + y-size = <600>; + }; + + /* ... */ + }; diff --git a/Documentation/devicetree/bindings/arm/atmel-aic.txt b/Documentation/devicetree/bindings/interrupt-controller/atmel,aic.txt index 2742e9c..2742e9c 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/brcm,l2-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt new file mode 100644 index 0000000..448273a --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt @@ -0,0 +1,29 @@ +Broadcom Generic Level 2 Interrupt Controller + +Required properties: + +- compatible: should be "brcm,l2-intc" +- reg: specifies the base physical address and size of the registers +- interrupt-controller: identifies the node as an interrupt controller +- #interrupt-cells: specifies the number of cells needed to encode an + interrupt source. Should be 1. +- interrupt-parent: specifies the phandle to the parent interrupt controller + this controller is cacaded from +- interrupts: specifies the interrupt line in the interrupt-parent irq space + to be used for cascading + +Optional properties: + +- brcm,irq-can-wake: If present, this means the L2 controller can be used as a + wakeup source for system suspend/resume. + +Example: + +hif_intr2_intc: interrupt-controller@f0441000 { + compatible = "brcm,l2-intc"; + reg = <0xf0441000 0x30>; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&intc>; + interrupts = <0x0 0x20 0x0>; +}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt new file mode 100644 index 0000000..759339c --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt @@ -0,0 +1,41 @@ +Cirrus Logic CLPS711X Interrupt Controller + +Required properties: + +- compatible: Should be "cirrus,clps711x-intc". +- reg: Specifies base physical address of the registers set. +- 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. + +The interrupt sources are as follows: +ID Name Description +--------------------------- +1: BLINT Battery low (FIQ) +3: MCINT Media changed (FIQ) +4: CSINT CODEC sound +5: EINT1 External 1 +6: EINT2 External 2 +7: EINT3 External 3 +8: TC1OI TC1 under flow +9: TC2OI TC2 under flow +10: RTCMI RTC compare match +11: TINT 64Hz tick +12: UTXINT1 UART1 transmit FIFO half empty +13: URXINT1 UART1 receive FIFO half full +14: UMSINT UART1 modem status changed +15: SSEOTI SSI1 end of transfer +16: KBDINT Keyboard +17: SS2RX SSI2 receive FIFO half or greater full +18: SS2TX SSI2 transmit FIFO less than half empty +28: UTXINT2 UART2 transmit FIFO half empty +29: URXINT2 UART2 receive FIFO half full +32: DAIINT DAI interface (FIQ) + +Example: + intc: interrupt-controller { + compatible = "cirrus,clps711x-intc"; + reg = <0x80000000 0x4000>; + interrupt-controller; + #interrupt-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.txt index 5fc0313..5fc0313 100644 --- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.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 0000000..55c04fa --- /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 e34c6cd..2d0f7cd 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt @@ -42,11 +42,11 @@ 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 + aliases of secure registers have to be used during + SMMU configuration. Example: diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt b/Documentation/devicetree/bindings/iommu/iommu.txt new file mode 100644 index 0000000..5a8b462 --- /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/iommu/samsung,sysmmu.txt b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt new file mode 100644 index 0000000..6fa4c73 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt @@ -0,0 +1,70 @@ +Samsung Exynos IOMMU H/W, System MMU (System Memory Management Unit) + +Samsung's Exynos architecture contains System MMUs that enables scattered +physical memory chunks visible as a contiguous region to DMA-capable peripheral +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth. + +System MMU is an IOMMU and supports identical translation table format to +ARMv7 translation tables with minimum set of page properties including access +permissions, shareability and security protection. In addition, System MMU has +another capabilities like L2 TLB or block-fetch buffers to minimize translation +latency. + +System MMUs are in many to one relation with peripheral devices, i.e. single +peripheral device might have multiple System MMUs (usually one for each bus +master), but one System MMU can handle transactions from only one peripheral +device. The relation between a System MMU and the peripheral device needs to be +defined in device node of the peripheral device. + +MFC in all Exynos SoCs and FIMD, M2M Scalers and G2D in Exynos5420 has 2 System +MMUs. +* MFC has one System MMU on its left and right bus. +* FIMD in Exynos5420 has one System MMU for window 0 and 4, the other system MMU + for window 1, 2 and 3. +* M2M Scalers and G2D in Exynos5420 has one System MMU on the read channel and + the other System MMU on the write channel. +The drivers must consider how to handle those System MMUs. One of the idea is +to implement child devices or sub-devices which are the client devices of the +System MMU. + +Note: +The current DT binding for the Exynos System MMU is incomplete. +The following properties can be removed or changed, if found incompatible with +the "Generic IOMMU Binding" support for attaching devices to the IOMMU. + +Required properties: +- compatible: Should be "samsung,exynos-sysmmu" +- reg: A tuple of base address and size of System MMU registers. +- interrupt-parent: The phandle of the interrupt controller of System MMU +- interrupts: An interrupt specifier for interrupt signal of System MMU, + according to the format defined by a particular interrupt + controller. +- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock. + Optional "master" if the clock to the System MMU is gated by + another gate clock other than "sysmmu". + Exynos4 SoCs, there needs no "master" clock. + Exynos5 SoCs, some System MMUs must have "master" clocks. +- clocks: Required if the System MMU is needed to gate its clock. +- samsung,power-domain: Required if the System MMU is needed to gate its power. + Please refer to the following document: + Documentation/devicetree/bindings/arm/exynos/power_domain.txt + +Examples: + gsc_0: gsc@13e00000 { + compatible = "samsung,exynos5-gsc"; + reg = <0x13e00000 0x1000>; + interrupts = <0 85 0>; + samsung,power-domain = <&pd_gsc>; + clocks = <&clock CLK_GSCL0>; + clock-names = "gscl"; + }; + + sysmmu_gsc0: sysmmu@13E80000 { + compatible = "samsung,exynos-sysmmu"; + reg = <0x13E80000 0x1000>; + interrupt-parent = <&combiner>; + interrupts = <2 0>; + clock-names = "sysmmu", "master"; + clocks = <&clock CLK_SMMU_GSCL0>, <&clock CLK_GSCL0>; + samsung,power-domain = <&pd_gsc>; + }; diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode 100644 index 0000000..42531dc --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -0,0 +1,26 @@ +OMAP2+ IOMMU + +Required properties: +- compatible : Should be one of, + "ti,omap2-iommu" for OMAP2/OMAP3 IOMMU instances + "ti,omap4-iommu" for OMAP4/OMAP5 IOMMU instances + "ti,dra7-iommu" for DRA7xx IOMMU instances +- ti,hwmods : Name of the hwmod associated with the IOMMU instance +- reg : Address space for the configuration registers +- interrupts : Interrupt specifier for the IOMMU instance + +Optional properties: +- ti,#tlb-entries : Number of entries in the translation look-aside buffer. + Should be either 8 or 32 (default: 32) +- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing + back a bus error response on MMU faults. + +Example: + /* OMAP3 ISP MMU */ + mmu_isp: mmu@480bd400 { + compatible = "ti,omap2-iommu"; + reg = <0x480bd400 0x80>; + interrupts = <24>; + ti,hwmods = "mmu_isp"; + ti,#tlb-entries = <8>; + }; diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt index df1b308..f77148f 100644 --- a/Documentation/devicetree/bindings/leds/leds-gpio.txt +++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt @@ -21,6 +21,8 @@ LED sub-node properties: on). The "keep" setting will keep the LED at whatever its current state is, without producing a glitch. The default is off if this property is not present. +- retain-state-suspended: (optional) The suspend state can be retained.Such + as charge-led gpio. Examples: @@ -50,3 +52,13 @@ run-control { default-state = "on"; }; }; + +leds { + compatible = "gpio-leds"; + + charger-led { + gpios = <&gpio1 2 0>; + linux,default-trigger = "max8903-charger-charging"; + retain-state-suspended; + }; +}; diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt index c55b8c0..1b66a41 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt @@ -1,7 +1,13 @@ Binding for TI/National Semiconductor LP55xx Led Drivers Required properties: -- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562" or "ti,lp8501" +- compatible: one of + national,lp5521 + national,lp5523 + ti,lp55231 + ti,lp5562 + ti,lp8501 + - reg: I2C slave address - clock-mode: Input clock mode, (0: automode, 1: internal, 2: external) diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt b/Documentation/devicetree/bindings/leds/leds-pwm.txt index 7297107..6c6583c 100644 --- a/Documentation/devicetree/bindings/leds/leds-pwm.txt +++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt @@ -13,6 +13,8 @@ LED sub-node properties: For the pwms and pwm-names property please refer to: Documentation/devicetree/bindings/pwm/pwm.txt - max-brightness : Maximum brightness possible for the LED +- active-low : (optional) For PWMs where the LED is wired to supply + rather than ground. - label : (optional) see Documentation/devicetree/bindings/leds/common.txt - linux,default-trigger : (optional) diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt b/Documentation/devicetree/bindings/media/atmel-isi.txt new file mode 100644 index 0000000..17e71b7 --- /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 937b755..bf52ed4 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/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt new file mode 100644 index 0000000..c27cede --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -0,0 +1,70 @@ +* Analog Devices ADV7604/11 video decoder with HDMI receiver + +The ADV7604 and ADV7611 are multiformat video decoders with an integrated HDMI +receiver. The ADV7604 has four multiplexed HDMI inputs and one analog input, +and the ADV7611 has one HDMI input and no analog input. + +These device tree bindings support the ADV7611 only at the moment. + +Required Properties: + + - compatible: Must contain one of the following + - "adi,adv7611" for the ADV7611 + + - reg: I2C slave address + + - hpd-gpios: References to the GPIOs that control the HDMI hot-plug + detection pins, one per HDMI input. The active flag indicates the GPIO + level that enables hot-plug detection. + +The device node must contain one 'port' child node per device input and output +port, in accordance with the video interface bindings defined in +Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes +are numbered as follows. + + Port ADV7611 +------------------------------------------------------------ + HDMI 0 + Digital output 1 + +The digital output port node must contain at least one endpoint. + +Optional Properties: + + - reset-gpios: Reference to the GPIO connected to the device's reset pin. + +Optional Endpoint Properties: + + The following three properties are defined in video-interfaces.txt and are + valid for source endpoints only. + + - hsync-active: Horizontal synchronization polarity. Defaults to active low. + - vsync-active: Vertical synchronization polarity. Defaults to active low. + - pclk-sample: Pixel clock polarity. Defaults to output on the falling edge. + + If none of hsync-active, vsync-active and pclk-sample is specified the + endpoint will use embedded BT.656 synchronization. + + +Example: + + hdmi_receiver@4c { + compatible = "adi,adv7611"; + reg = <0x4c>; + + reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>; + hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>; + + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + }; + port@1 { + reg = <1>; + hdmi_in: endpoint { + remote-endpoint = <&ccdc_in>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/mt9m111.txt b/Documentation/devicetree/bindings/media/i2c/mt9m111.txt new file mode 100644 index 0000000..ed5a334 --- /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/img-ir-rev1.txt b/Documentation/devicetree/bindings/media/img-ir-rev1.txt new file mode 100644 index 0000000..5434ce6 --- /dev/null +++ b/Documentation/devicetree/bindings/media/img-ir-rev1.txt @@ -0,0 +1,34 @@ +* ImgTec Infrared (IR) decoder version 1 + +This binding is for Imagination Technologies' Infrared decoder block, +specifically major revision 1. + +Required properties: +- compatible: Should be "img,ir-rev1" +- reg: Physical base address of the controller and length of + memory mapped region. +- interrupts: The interrupt specifier to the cpu. + +Optional properties: +- clocks: List of clock specifiers as described in standard + clock bindings. + Up to 3 clocks may be specified in the following order: + 1st: Core clock (defaults to 32.768KHz if omitted). + 2nd: System side (fast) clock. + 3rd: Power modulation clock. +- clock-names: List of clock names corresponding to the clocks + specified in the clocks property. + Accepted clock names are: + "core": Core clock. + "sys": System clock. + "mod": Power modulation clock. + +Example: + + ir@02006200 { + compatible = "img,ir-rev1"; + reg = <0x02006200 0x100>; + interrupts = <29 4>; + clocks = <&clk_32khz>; + clock-names = "core"; + }; diff --git a/Documentation/devicetree/bindings/media/pxa-camera.txt b/Documentation/devicetree/bindings/media/pxa-camera.txt new file mode 100644 index 0000000..11f5b5d --- /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 0000000..ba61782 --- /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/renesas,vsp1.txt b/Documentation/devicetree/bindings/media/renesas,vsp1.txt new file mode 100644 index 0000000..87fe08a --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt @@ -0,0 +1,43 @@ +* Renesas VSP1 Video Processing Engine + +The VSP1 is a video processing engine that supports up-/down-scaling, alpha +blending, color space conversion and various other image processing features. +It can be found in the Renesas R-Car second generation SoCs. + +Required properties: + + - compatible: Must contain "renesas,vsp1" + + - reg: Base address and length of the registers block for the VSP1. + - interrupts: VSP1 interrupt specifier. + - clocks: A phandle + clock-specifier pair for the VSP1 functional clock. + + - renesas,#rpf: Number of Read Pixel Formatter (RPF) modules in the VSP1. + - renesas,#uds: Number of Up Down Scaler (UDS) modules in the VSP1. + - renesas,#wpf: Number of Write Pixel Formatter (WPF) modules in the VSP1. + + +Optional properties: + + - renesas,has-lif: Boolean, indicates that the LCD Interface (LIF) module is + available. + - renesas,has-lut: Boolean, indicates that the Look Up Table (LUT) module is + available. + - renesas,has-sru: Boolean, indicates that the Super Resolution Unit (SRU) + module is available. + + +Example: R8A7790 (R-Car H2) VSP1-S node + + vsp1@fe928000 { + compatible = "renesas,vsp1"; + reg = <0 0xfe928000 0 0x8000>; + interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp1_clks R8A7790_CLK_VSP1_S>; + + renesas,has-lut; + renesas,has-sru; + renesas,#rpf = <5>; + renesas,#uds = <3>; + renesas,#wpf = <4>; + }; diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index f418168..3e3c5f3 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -10,7 +10,8 @@ Required properties: - compatible : value should be either one among the following (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs - (b) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC + (c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC + (d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC - reg : Physical base address of the IP registers and length of memory mapped region. diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt index 96312f6..922d6f8 100644 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt @@ -15,11 +15,21 @@ Common 'camera' node Required properties: -- compatible : must be "samsung,fimc", "simple-bus" -- clocks : list of clock specifiers, corresponding to entries in - the clock-names property; -- clock-names : must contain "sclk_cam0", "sclk_cam1", "pxl_async0", - "pxl_async1" entries, matching entries in the clocks property. +- compatible: must be "samsung,fimc", "simple-bus" +- clocks: list of clock specifiers, corresponding to entries in + the clock-names property; +- clock-names : must contain "sclk_cam0", "sclk_cam1", "pxl_async0", + "pxl_async1" entries, matching entries in the clocks property. + +- #clock-cells: from the common clock bindings (../clock/clock-bindings.txt), + must be 1. A clock provider is associated with the 'camera' node and it should + be referenced by external sensors that use clocks provided by the SoC on + CAM_*_CLKOUT pins. The clock specifier cell stores an index of a clock. + The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively. + +- clock-output-names: from the common clock bindings, should contain names of + clocks registered by the camera subsystem corresponding to CAM_A_CLKOUT, + CAM_B_CLKOUT output clocks respectively. The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used to define a required pinctrl state named "default" and optional pinctrl states: @@ -32,6 +42,7 @@ way around. The 'camera' node must include at least one 'fimc' child node. + 'fimc' device nodes ------------------- @@ -88,8 +99,8 @@ port nodes specifies data input - 0, 1 indicates input A, B respectively. Optional properties -- samsung,camclk-out : specifies clock output for remote sensor, - 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT; +- samsung,camclk-out (deprecated) : specifies clock output for remote sensor, + 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT; Image sensor nodes ------------------ @@ -97,8 +108,6 @@ Image sensor nodes The sensor device nodes should be added to their control bus controller (e.g. I2C0) nodes and linked to a port node in the csis or the parallel-ports node, using the common video interfaces bindings, defined in video-interfaces.txt. -The implementation of this bindings requires clock-frequency property to be -present in the sensor device nodes. Example: @@ -114,7 +123,7 @@ Example: vddio-supply = <...>; clock-frequency = <24000000>; - clocks = <...>; + clocks = <&camera 1>; clock-names = "mclk"; port { @@ -135,7 +144,7 @@ Example: vddio-supply = <...>; clock-frequency = <24000000>; - clocks = <...>; + clocks = <&camera 0>; clock-names = "mclk"; port { @@ -149,12 +158,17 @@ Example: camera { compatible = "samsung,fimc", "simple-bus"; - #address-cells = <1>; - #size-cells = <1>; - status = "okay"; - + clocks = <&clock 132>, <&clock 133>, <&clock 351>, + <&clock 352>; + clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", + "pxl_async1"; + #clock-cells = <1>; + clock-output-names = "cam_a_clkout", "cam_b_clkout"; pinctrl-names = "default"; pinctrl-0 = <&cam_port_a_clk_active>; + status = "okay"; + #address-cells = <1>; + #size-cells = <1>; /* parallel camera ports */ parallel-ports { diff --git a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt new file mode 100644 index 0000000..2c85c45 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt @@ -0,0 +1,97 @@ +Samsung S5C73M3 8Mp camera ISP +------------------------------ + +The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656) video +data busses. The I2C bus is the main control bus and additionally the SPI bus +is used, mostly for transferring the firmware to and from the device. Two +slave device nodes corresponding to these control bus interfaces are required +and should be placed under respective bus controller nodes. + +I2C slave device node +--------------------- + +Required properties: + +- compatible : "samsung,s5c73m3"; +- reg : I2C slave address of the sensor; +- vdd-int-supply : digital power supply (1.2V); +- vdda-supply : analog power supply (1.2V); +- vdd-reg-supply : regulator input power supply (2.8V); +- vddio-host-supply : host I/O power supply (1.8V to 2.8V); +- vddio-cis-supply : CIS I/O power supply (1.2V to 1.8V); +- vdd-af-supply : lens power supply (2.8V); +- xshutdown-gpios : specifier of GPIO connected to the XSHUTDOWN pin; +- standby-gpios : specifier of GPIO connected to the STANDBY pin; +- clocks : should contain list of phandle and clock specifier pairs + according to common clock bindings for the clocks described + in the clock-names property; +- clock-names : should contain "cis_extclk" entry for the CIS_EXTCLK clock; + +Optional properties: + +- clock-frequency : the frequency at which the "cis_extclk" clock should be + configured to operate, in Hz; if this property is not + specified default 24 MHz value will be used. + +The common video interfaces bindings (see video-interfaces.txt) should be used +to specify link from the S5C73M3 to an external image data receiver. The S5C73M3 +device node should contain one 'port' child node with an 'endpoint' subnode for +this purpose. The data link from a raw image sensor to the S5C73M3 can be +similarly specified, but it is optional since the S5C73M3 ISP and a raw image +sensor are usually inseparable and form a hybrid module. + +Following properties are valid for the endpoint node(s): + +endpoint subnode +---------------- + +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in + video-interfaces.txt. This sensor doesn't support data lane remapping + and physical lane indexes in subsequent elements of the array should + be only consecutive ascending values. + +SPI device node +--------------- + +Required properties: + +- compatible : "samsung,s5c73m3"; + +For more details see description of the SPI busses bindings +(../spi/spi-bus.txt) and bindings of a specific bus controller. + +Example: + +i2c@138A000000 { + ... + s5c73m3@3c { + compatible = "samsung,s5c73m3"; + reg = <0x3c>; + vdd-int-supply = <&buck9_reg>; + vdda-supply = <&ldo17_reg>; + vdd-reg-supply = <&cam_io_reg>; + vddio-host-supply = <&ldo18_reg>; + vddio-cis-supply = <&ldo9_reg>; + vdd-af-supply = <&cam_af_reg>; + clock-frequency = <24000000>; + clocks = <&clk 0>; + clock-names = "cis_extclk"; + reset-gpios = <&gpf1 3 1>; + standby-gpios = <&gpm0 1 1>; + port { + s5c73m3_ep: endpoint { + remote-endpoint = <&csis0_ep>; + data-lanes = <1 2 3 4>; + }; + }; + }; +}; + +spi@1392000 { + ... + s5c73m3_spi: s5c73m3@0 { + compatible = "samsung,s5c73m3"; + reg = <0>; + ... + }; +}; diff --git a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt new file mode 100644 index 0000000..cce01e8 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt @@ -0,0 +1,33 @@ +Samsung S5K6A3(YX) raw image sensor +--------------------------------- + +S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces +and CCI (I2C compatible) control bus. + +Required properties: + +- compatible : "samsung,s5k6a3"; +- reg : I2C slave address of the sensor; +- svdda-supply : core voltage supply; +- svddio-supply : I/O voltage supply; +- afvdd-supply : AF (actuator) voltage supply; +- gpios : specifier of a GPIO connected to the RESET pin; +- clocks : should contain list of phandle and clock specifier pairs + according to common clock bindings for the clocks described + in the clock-names property; +- clock-names : should contain "extclk" entry for the sensor's EXTCLK clock; + +Optional properties: + +- clock-frequency : the frequency at which the "extclk" clock should be + configured to operate, in Hz; if this property is not + specified default 24 MHz value will be used. + +The common video interfaces bindings (see video-interfaces.txt) should be +used to specify link to the image data receiver. The S5K6A3(YX) device +node should contain one 'port' child node with an 'endpoint' subnode. + +Following properties are valid for the endpoint node: + +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in + video-interfaces.txt. The sensor supports only one data lane. diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt new file mode 100644 index 0000000..23dd5ad --- /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/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt index 653c90c..1ee3bc0 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt +++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt @@ -6,10 +6,11 @@ The actual devices are instantiated from the child nodes of a Device Bus node. Required properties: - - compatible: Currently only Armada 370/XP SoC are supported, - with this compatible string: + - compatible: Armada 370/XP SoC are supported using the + "marvell,mvebu-devbus" compatible string. - marvell,mvebu-devbus + Orion5x SoC are supported using the + "marvell,orion-devbus" compatible string. - reg: A resource specifier for the register space. This is the base address of a chip select within @@ -22,7 +23,14 @@ Required properties: integer values for each chip-select line in use: 0 <physical address of mapping> <size> -Mandatory timing properties for child nodes: +Optional properties: + + - devbus,keep-config This property can optionally be used to keep + using the timing parameters set by the + bootloader. It makes all the timing properties + described below unused. + +Timing properties for child nodes: Read parameters: @@ -30,21 +38,26 @@ Read parameters: drive the AD bus after the completion of a device read. This prevents contentions on the Device Bus after a read cycle from a slow device. + Mandatory, except if devbus,keep-config is used. - - devbus,bus-width: Defines the bus width (e.g. <16>) + - devbus,bus-width: Defines the bus width, in bits (e.g. <16>). + Mandatory, except if devbus,keep-config is used. - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle, to read data sample. This parameter is useful for synchronous pipelined devices, where the address precedes the read data by one or two cycles. + Mandatory, except if devbus,keep-config is used. - devbus,acc-first-ps: Defines the time delay from the negation of ALE[0] to the cycle that the first read data is sampled by the controller. + Mandatory, except if devbus,keep-config is used. - devbus,acc-next-ps: Defines the time delay between the cycle that samples data N and the cycle that samples data N+1 (in burst accesses). + Mandatory, except if devbus,keep-config is used. - devbus,rd-setup-ps: Defines the time delay between DEV_CSn assertion to DEV_OEn assertion. If set to 0 (default), @@ -52,6 +65,8 @@ Read parameters: This parameter has no affect on <acc-first-ps> parameter (no affect on first data sample). Set <rd-setup-ps> to a value smaller than <acc-first-ps>. + Mandatory for "marvell,mvebu-devbus" compatible string, + except if devbus,keep-config is used. - devbus,rd-hold-ps: Defines the time between the last data sample to the de-assertion of DEV_CSn. If set to 0 (default), @@ -62,16 +77,20 @@ Read parameters: last data sampled. Also this parameter has no affect on <turn-off-ps> parameter. Set <rd-hold-ps> to a value smaller than <turn-off-ps>. + Mandatory for "marvell,mvebu-devbus" compatible string, + except if devbus,keep-config is used. Write parameters: - devbus,ale-wr-ps: Defines the time delay from the ALE[0] negation cycle to the DEV_WEn assertion. + Mandatory. - devbus,wr-low-ps: Defines the time during which DEV_WEn is active. A[2:0] and Data are kept valid as long as DEV_WEn is active. This parameter defines the setup time of address and data to DEV_WEn rise. + Mandatory. - devbus,wr-high-ps: Defines the time during which DEV_WEn is kept inactive (high) between data beats of a burst write. @@ -79,10 +98,13 @@ Write parameters: <wr-high-ps> - <tick> ps. This parameter defines the hold time of address and data after DEV_WEn rise. + Mandatory. - devbus,sync-enable: Synchronous device enable. 1: True 0: False + Mandatory for "marvell,mvebu-devbus" compatible string, + except if devbus,keep-config is used. An example for an Armada XP GP board, with a 16 MiB NOR device as child is showed below. Note that the Device Bus driver is in charge of allocating diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index 0e295c9..36a0c3d 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -5,9 +5,10 @@ of analogue I/O. Required properties: - - compatible : one of the following chip-specific strings: - "wlf,wm5102" - "wlf,wm5110" + - compatible : One of the following chip-specific strings: + "wlf,wm5102" + "wlf,wm5110" + "wlf,wm8997" - reg : I2C slave address when connected using I2C, chip select number when using SPI. @@ -25,8 +26,9 @@ Required properties: - #gpio-cells : Must be 2. The first cell is the pin number and the second cell is used to specify optional parameters (currently unused). - - AVDD1-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply, - SPKVDDL-supply, SPKVDDR-supply : power supplies for the device, as covered + - AVDD-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply (wm5102, wm5110), + CPVDD-supply, SPKVDDL-supply (wm5102, wm5110), SPKVDDR-supply (wm5102, + wm5110), SPKVDD-supply (wm8997) : Power supplies for the device, as covered in Documentation/devicetree/bindings/regulator/regulator.txt Optional properties: @@ -46,6 +48,7 @@ codec: wm5102@1a { compatible = "wlf,wm5102"; reg = <0x1a>; interrupts = <347>; + interrupt-controller; #interrupt-cells = <2>; interrupt-parent = <&gic>; @@ -53,10 +56,10 @@ codec: wm5102@1a { #gpio-cells = <2>; wlf,gpio-defaults = < - 0x00000000, /* AIF1TXLRCLK */ - 0xffffffff, - 0xffffffff, - 0xffffffff, - 0xffffffff, + 0x00000000 /* AIF1TXLRCLK */ + 0xffffffff + 0xffffffff + 0xffffffff + 0xffffffff >; }; diff --git a/Documentation/devicetree/bindings/mfd/bcm590xx.txt b/Documentation/devicetree/bindings/mfd/bcm590xx.txt new file mode 100644 index 0000000..be51a15 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/bcm590xx.txt @@ -0,0 +1,39 @@ +------------------------------- +BCM590xx Power Management Units +------------------------------- + +Required properties: +- compatible: "brcm,bcm59056" +- reg: I2C slave address +- interrupts: interrupt for the PMU. Generic interrupt client node bindings + are described in interrupt-controller/interrupts.txt + +------------------ +Voltage Regulators +------------------ + +Optional child nodes: +- regulators: container node for regulators following the generic + regulator binding in regulator/regulator.txt + + The valid regulator node names for BCM59056 are: + rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo, + mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo, + csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr, + gpldo1, gpldo2, gpldo3, gpldo4, gpldo5, gpldo6, + vbus + +Example: + pmu: bcm59056@8 { + compatible = "brcm,bcm59056"; + reg = <0x08>; + interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>; + regulators { + rfldo_reg: rfldo { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + }; + + ... + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/bfticu.txt b/Documentation/devicetree/bindings/mfd/bfticu.txt new file mode 100644 index 0000000..65c9077 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/bfticu.txt @@ -0,0 +1,25 @@ +KEYMILE bfticu Chassis Management FPGA + +The bfticu is a multifunction device that manages the whole chassis. +Its main functionality is to collect IRQs from the whole chassis and signals +them to a single controller. + +Required properties: +- compatible: "keymile,bfticu" +- interrupt-controller: the bfticu FPGA is an interrupt controller +- interrupts: the main IRQ line to signal the collected IRQs +- #interrupt-cells : is 2 and their usage is compliant to the 2 cells variant + of Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +- interrupt-parent: the parent IRQ ctrl the main IRQ is connected to +- reg: access on the parent local bus (chip select, offset in chip select, size) + +Example: + + chassis-mgmt@3,0 { + compatible = "keymile,bfticu"; + interrupt-controller; + #interrupt-cells = <2>; + reg = <3 0 0x100>; + interrupt-parent = <&mpic>; + interrupts = <6 1 0 0>; + }; diff --git a/Documentation/devicetree/bindings/mfd/da9055.txt b/Documentation/devicetree/bindings/mfd/da9055.txt new file mode 100644 index 0000000..6dab34d --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/da9055.txt @@ -0,0 +1,72 @@ +* Dialog DA9055 Power Management Integrated Circuit (PMIC) + +DA9055 consists of a large and varied group of sub-devices (I2C Only): + +Device Supply Names Description +------ ------------ ----------- +da9055-gpio : : GPIOs +da9055-regulator : : Regulators +da9055-onkey : : On key +da9055-rtc : : RTC +da9055-hwmon : : ADC +da9055-watchdog : : Watchdog + +The CODEC device in DA9055 has a separate, configurable I2C address and so +is instantiated separately from the PMIC. + +For details on accompanying CODEC I2C device, see the following: +Documentation/devicetree/bindings/sound/da9055.txt + +====== + +Required properties: +- compatible : Should be "dlg,da9055-pmic" +- reg: Specifies the I2C slave address (defaults to 0x5a but can be modified) +- interrupt-parent: Specifies the phandle of the interrupt controller to which + the IRQs from da9055 are delivered to. +- interrupts: IRQ line info for da9055 chip. +- interrupt-controller: da9055 has internal IRQs (has own IRQ domain). +- #interrupt-cells: Should be 1, is the local IRQ number for da9055. + +Sub-nodes: +- regulators : Contain the regulator nodes. The DA9055 regulators are + bound using their names as listed below: + + buck1 : regulator BUCK1 + buck2 : regulator BUCK2 + ldo1 : regulator LDO1 + ldo2 : regulator LDO2 + ldo3 : regulator LDO3 + ldo4 : regulator LDO4 + ldo5 : regulator LDO5 + ldo6 : regulator LDO6 + + The bindings details of individual regulator device can be found in: + Documentation/devicetree/bindings/regulator/regulator.txt + + +Example: + + pmic: da9055-pmic@5a { + compatible = "dlg,da9055-pmic"; + reg = <0x5a>; + interrupt-parent = <&intc>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <1>; + + regulators { + buck1: BUCK1 { + regulator-min-microvolt = <725000>; + regulator-max-microvolt = <2075000>; + }; + buck2: BUCK2 { + regulator-min-microvolt = <925000>; + regulator-max-microvolt = <2500000>; + }; + ldo1: LDO1 { + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt index abd9e3c..8aba488 100644 --- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt +++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt @@ -10,9 +10,47 @@ Optional properties: - fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used Sub-nodes: +- codec: Contain the Audio Codec node. + - adc-port: Contain PMIC SSI port number used for ADC. + - dac-port: Contain PMIC SSI port number used for DAC. +- leds : Contain the led nodes and initial register values in property + "led-control". Number of register depends of used IC, for MC13783 is 6, + for MC13892 is 4, for MC34708 is 1. See datasheet for bits definitions of + these registers. + - #address-cells: Must be 1. + - #size-cells: Must be 0. + Each led node should contain "reg", which used as LED ID (described below). + Optional properties "label" and "linux,default-trigger" is described in + Documentation/devicetree/bindings/leds/common.txt. - regulators : Contain the regulator nodes. The regulators are bound using their names as listed below with their registers and bits for enabling. +MC13783 LED IDs: + 0 : Main display + 1 : AUX display + 2 : Keypad + 3 : Red 1 + 4 : Green 1 + 5 : Blue 1 + 6 : Red 2 + 7 : Green 2 + 8 : Blue 2 + 9 : Red 3 + 10 : Green 3 + 11 : Blue 3 + +MC13892 LED IDs: + 0 : Main display + 1 : AUX display + 2 : Keypad + 3 : Red + 4 : Green + 5 : Blue + +MC34708 LED IDs: + 0 : Charger Red + 1 : Charger Green + MC13783 regulators: sw1a : regulator SW1A (register 24, bit 0) sw1b : regulator SW1B (register 25, bit 0) @@ -89,6 +127,18 @@ ecspi@70010000 { /* ECSPI1 */ interrupt-parent = <&gpio0>; interrupts = <8>; + leds { + #address-cells = <1>; + #size-cells = <0>; + led-control = <0x000 0x000 0x0e0 0x000>; + + sysled { + reg = <3>; + label = "system:red:live"; + linux,default-trigger = "heartbeat"; + }; + }; + regulators { sw1_reg: mc13892__sw1 { regulator-min-microvolt = <600000>; diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt index b381fa6..4721b2d 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt @@ -32,6 +32,29 @@ Optional properties: - single-ulpi-bypass: Must be present if the controller contains a single ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1 +- clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. + +- clock-names: should include: + For OMAP3 + * "usbhost_120m_fck" - 120MHz Functional clock. + + For OMAP4+ + * "refclk_60m_int" - 60MHz internal reference clock for UTMI clock mux + * "refclk_60m_ext_p1" - 60MHz external ref. clock for Port 1's UTMI clock mux. + * "refclk_60m_ext_p2" - 60MHz external ref. clock for Port 2's UTMI clock mux + * "utmi_p1_gfclk" - Port 1 UTMI clock mux. + * "utmi_p2_gfclk" - Port 2 UTMI clock mux. + * "usb_host_hs_utmi_p1_clk" - Port 1 UTMI clock gate. + * "usb_host_hs_utmi_p2_clk" - Port 2 UTMI clock gate. + * "usb_host_hs_utmi_p3_clk" - Port 3 UTMI clock gate. + * "usb_host_hs_hsic480m_p1_clk" - Port 1 480MHz HSIC clock gate. + * "usb_host_hs_hsic480m_p2_clk" - Port 2 480MHz HSIC clock gate. + * "usb_host_hs_hsic480m_p3_clk" - Port 3 480MHz HSIC clock gate. + * "usb_host_hs_hsic60m_p1_clk" - Port 1 60MHz HSIC clock gate. + * "usb_host_hs_hsic60m_p2_clk" - Port 2 60MHz HSIC clock gate. + * "usb_host_hs_hsic60m_p3_clk" - Port 3 60MHz HSIC clock gate. + Required properties if child node exists: - #address-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt index 62fe697..c58d704 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt @@ -7,6 +7,16 @@ Required properties: - interrupts : should contain the TLL module's interrupt - ti,hwmod : must contain "usb_tll_hs" +Optional properties: + +- clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. + +- clock-names: should include: + * "usb_tll_hs_usb_ch0_clk" - USB TLL channel 0 clock + * "usb_tll_hs_usb_ch1_clk" - USB TLL channel 1 clock + * "usb_tll_hs_usb_ch2_clk" - USB TLL channel 2 clock + Example: usbhstll: usbhstll@4a062000 { diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index e5f0f83..eda8989 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/mfd/qcom,pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom,pm8xxx.txt new file mode 100644 index 0000000..03518dc --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qcom,pm8xxx.txt @@ -0,0 +1,96 @@ +Qualcomm PM8xxx PMIC multi-function devices + +The PM8xxx family of Power Management ICs are used to provide regulated +voltages and other various functionality to Qualcomm SoCs. + += PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8058" + "qcom,pm8921" + +- #address-cells: + Usage: required + Value type: <u32> + Definition: must be 1 + +- #size-cells: + Usage: required + Value type: <u32> + Definition: must be 0 + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: specifies the interrupt that indicates a subdevice + has generated an interrupt (summary interrupt). The + format of the specifier is defined by the binding document + describing the node's interrupt parent. + +- #interrupt-cells: + Usage: required + Value type : <u32> + Definition: must be 2. Specifies the number of cells needed to encode + an interrupt source. The 1st cell contains the interrupt + number. The 2nd cell is the trigger type and level flags + encoded as follows: + + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered + 4 = active high level-sensitive + 8 = active low level-sensitive + +- interrupt-controller: + Usage: required + Value type: <empty> + Definition: identifies this node as an interrupt controller + += SUBCOMPONENTS + +The PMIC contains multiple independent functions, each described in a subnode. +The below bindings specify the set of valid subnodes. + +== Real-Time Clock + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8058-rtc" + "qcom,pm8921-rtc" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: single entry specifying the base address of the RTC registers + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: single entry specifying the RTC's alarm interrupt + +- allow-set-time: + Usage: optional + Value type: <empty> + Definition: indicates that the setting of RTC time is allowed by + the host CPU + += EXAMPLE + + pmicintc: pmic@0 { + compatible = "qcom,pm8921"; + interrupts = <104 8>; + #interrupt-cells = <2>; + interrupt-controller; + #address-cells = <1>; + #size-cells = <0>; + + rtc@11d { + compatible = "qcom,pm8921-rtc"; + reg = <0x11d>; + interrupts = <0x27 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/qriox.txt b/Documentation/devicetree/bindings/mfd/qriox.txt new file mode 100644 index 0000000..f301e2d --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qriox.txt @@ -0,0 +1,17 @@ +KEYMILE qrio Board Control CPLD + +The qrio is a multifunction device that controls the KEYMILE boards based on +the kmp204x design. +It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ capable +GPIO blocks. + +Required properties: +- compatible: "keymile,qriox" +- reg: access on the parent local bus (chip select, offset in chip select, size) + +Example: + + board-control@1,0 { + compatible = "keymile,qriox"; + reg = <1 0 0x80>; + }; diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index f69bec2..d81ba30 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -16,20 +16,25 @@ Optional properties: - interrupts: Interrupt specifiers for interrupt sources. Optional nodes: -- clocks: s2mps11 provides three(AP/CP/BT) buffered 32.768 KHz outputs, so to - register these as clocks with common clock framework instantiate a sub-node - named "clocks". It uses the common clock binding documented in : +- clocks: s2mps11 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz + outputs, so to register these as clocks with common clock framework + instantiate a sub-node named "clocks". It uses the common clock binding + documented in : [Documentation/devicetree/bindings/clock/clock-bindings.txt] + The s2mps14 provides two (AP/BT) buffered 32.768 KHz outputs. - #clock-cells: should be 1. - The following is the list of clocks generated by the controller. Each clock is assigned an identifier and client nodes use this identifier to specify the clock which they consume. - Clock ID - ---------------------- - 32KhzAP 0 - 32KhzCP 1 - 32KhzBT 2 + Clock ID Devices + ---------------------------------------------------------- + 32KhzAP 0 S2MPS11, S2MPS14, S5M8767 + 32KhzCP 1 S2MPS11, S5M8767 + 32KhzBT 2 S2MPS11, S2MPS14, S5M8767 + + - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps14-clk", + "samsung,s5m8767-clk" - regulators: The regulators of s2mps11 that have to be instantiated should be included in a sub-node named 'regulators'. Regulator nodes included in this @@ -51,6 +56,20 @@ for a particular group of BUCKs. So provide same regulator-ramp-delay<value>. Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6], BUCK[3, 4], and BUCK[7, 8, 10] +On S2MPS14 the LDO10, LDO11 and LDO12 can be configured to external control +over GPIO. To turn this feature on this property must be added to the regulator +sub-node: + - samsung,ext-control-gpios: GPIO specifier for one GPIO + controlling this regulator (enable/disable); +Example: + LDO12 { + regulator-name = "V_EMMC_2.8V"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + samsung,ext-control-gpios = <&gpk0 2 0>; + }; + + The regulator constraints inside the regulator nodes use the standard regulator bindings which are documented elsewhere. @@ -75,7 +94,8 @@ Example: compatible = "samsung,s2mps11-pmic"; reg = <0x66>; - s2m_osc: clocks{ + s2m_osc: clocks { + compatible = "samsung,s2mps11-clk"; #clock-cells = 1; clock-output-names = "xx", "yy", "zz"; }; diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt new file mode 100644 index 0000000..1f5a31fe --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt @@ -0,0 +1,59 @@ +* Allwinner PRCM (Power/Reset/Clock Management) Multi-Functional Device + +PRCM is an MFD device exposing several Power Management related devices +(like clks and reset controllers). + +Required properties: + - compatible: "allwinner,sun6i-a31-prcm" + - reg: The PRCM registers range + +The prcm node may contain several subdevices definitions: + - see Documentation/devicetree/clk/sunxi.txt for clock devices + - see Documentation/devicetree/reset/allwinner,sunxi-clock-reset.txt for reset + controller devices + + +Example: + + prcm: prcm@01f01400 { + compatible = "allwinner,sun6i-a31-prcm"; + reg = <0x01f01400 0x200>; + + /* Put subdevices here */ + ar100: ar100_clk { + compatible = "allwinner,sun6i-a31-ar100-clk"; + #clock-cells = <0>; + clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>; + }; + + ahb0: ahb0_clk { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clock-div = <1>; + clock-mult = <1>; + clocks = <&ar100_div>; + clock-output-names = "ahb0"; + }; + + apb0: apb0_clk { + compatible = "allwinner,sun6i-a31-apb0-clk"; + #clock-cells = <0>; + clocks = <&ahb0>; + clock-output-names = "apb0"; + }; + + apb0_gates: apb0_gates_clk { + compatible = "allwinner,sun6i-a31-apb0-gates-clk"; + #clock-cells = <1>; + clocks = <&apb0>; + clock-output-names = "apb0_pio", "apb0_ir", + "apb0_timer01", "apb0_p2wi", + "apb0_uart", "apb0_1wire", + "apb0_i2c"; + }; + + apb0_rst: apb0_rst { + compatible = "allwinner,sun6i-a31-clock-reset"; + #reset-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt b/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt new file mode 100644 index 0000000..20963c7 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt @@ -0,0 +1,19 @@ +* Device tree bindings for Texas Instruments keystone device state control + +The Keystone II devices have a set of registers that are used to control +the status of its peripherals. This node is intended to allow access to +this functionality. + +Required properties: + +- compatible: "ti,keystone-devctrl", "syscon" + +- reg: contains offset/length value for device state control + registers space. + +Example: + +devctrl: device-state-control@0x02620000 { + compatible = "ti,keystone-devctrl", "syscon"; + reg = <0x02620000 0x1000>; +}; diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt b/Documentation/devicetree/bindings/mfd/twl4030-power.txt index 8e15ec3..b9ee7b9 100644 --- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt +++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt @@ -5,7 +5,22 @@ to control the power resources, including power scripts. For now, the binding only supports the complete shutdown of the system after poweroff. Required properties: -- compatible : must be "ti,twl4030-power" +- compatible : must be one of the following + "ti,twl4030-power" + "ti,twl4030-power-reset" + "ti,twl4030-power-idle" + "ti,twl4030-power-idle-osc-off" + +The use of ti,twl4030-power-reset is recommended at least on +3530 that needs a special configuration for warm reset to work. + +When using ti,twl4030-power-idle, the TI recommended configuration +for idle modes is loaded to the tlw4030 PMIC. + +When using ti,twl4030-power-idle-osc-off, the TI recommended +configuration is used with the external oscillator being shut +down during off-idle. Note that this does not work on all boards +depending on how the external oscillator is wired. Optional properties: - ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt b/Documentation/devicetree/bindings/mfd/twl6040.txt index 0f5dd70..a41157b 100644 --- a/Documentation/devicetree/bindings/mfd/twl6040.txt +++ b/Documentation/devicetree/bindings/mfd/twl6040.txt @@ -19,6 +19,8 @@ Required properties: Optional properties, nodes: - enable-active-high: To power on the twl6040 during boot. +- clocks: phandle to the clk32k clock provider +- clock-names: Must be "clk32k" Vibra functionality Required properties: diff --git a/Documentation/devicetree/bindings/misc/arm-charlcd.txt b/Documentation/devicetree/bindings/misc/arm-charlcd.txt new file mode 100644 index 0000000..e28e2aa --- /dev/null +++ b/Documentation/devicetree/bindings/misc/arm-charlcd.txt @@ -0,0 +1,18 @@ +ARM Versatile Character LCD +----------------------------------------------------- +This binding defines the character LCD interface found on ARM Versatile AB +and PB reference platforms. + +Required properties: +- compatible : "arm,versatile-clcd" +- reg : Location and size of character LCD registers + +Optional properties: +- interrupts - single interrupt for character LCD. The character LCD can + operate in polled mode without an interrupt. + +Example: + lcd@10008000 { + compatible = "arm,versatile-lcd"; + reg = <0x10008000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 458b57f..3c18001 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -26,9 +26,20 @@ Optional properties: this system, even if the controller claims it is. - cap-sd-highspeed: SD high-speed timing is supported - cap-mmc-highspeed: MMC high-speed timing is supported +- sd-uhs-sdr12: SD UHS SDR12 speed is supported +- sd-uhs-sdr25: SD UHS SDR25 speed is supported +- sd-uhs-sdr50: SD UHS SDR50 speed is supported +- sd-uhs-sdr104: SD UHS SDR104 speed is supported +- sd-uhs-ddr50: SD UHS DDR50 speed is supported - cap-power-off-card: powering off the card is safe - cap-sdio-irq: enable SDIO IRQ signalling on this interface - full-pwr-cycle: full power cycle of the card is supported +- mmc-highspeed-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported +- mmc-highspeed-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported +- mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported +- mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported +- mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported +- mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line polarity properties, we have to fix the meaning of the "normal" and "inverted" diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt index 2b584ca..03796cf 100644 --- a/Documentation/devicetree/bindings/mmc/mmci.txt +++ b/Documentation/devicetree/bindings/mmc/mmci.txt @@ -4,12 +4,58 @@ The ARM PrimeCell MMCI PL180 and PL181 provides an interface for reading and writing to MultiMedia and SD cards alike. This file documents differences between the core properties described -by mmc.txt and the properties used by the mmci driver. +by mmc.txt and the properties used by the mmci driver. Using "st" as +the prefix for a property, indicates support by the ST Micro variant. Required properties: - compatible : contains "arm,pl18x", "arm,primecell". -- arm,primecell-periphid : contains the PrimeCell Peripheral ID. +- vmmc-supply : phandle to the regulator device tree node, mentioned + as the VCC/VDD supply in the eMMC/SD specs. Optional properties: -- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable -- mmc-cap-sd-highspeed : indicates whether SD is high speed capable +- arm,primecell-periphid : contains the PrimeCell Peripheral ID, it overrides + the ID provided by the HW +- vqmmc-supply : phandle to the regulator device tree node, mentioned + as the VCCQ/VDD_IO supply in the eMMC/SD specs. +- st,sig-dir-dat0 : bus signal direction pin used for DAT[0]. +- st,sig-dir-dat2 : bus signal direction pin used for DAT[2]. +- st,sig-dir-dat31 : bus signal direction pin used for DAT[3] and DAT[1]. +- st,sig-dir-dat74 : bus signal direction pin used for DAT[4] to DAT[7]. +- st,sig-dir-cmd : cmd signal direction pin used for CMD. +- st,sig-pin-fbclk : feedback clock signal pin used. + +Deprecated properties: +- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable. +- mmc-cap-sd-highspeed : indicates whether SD is high speed capable. + +Example: + +sdi0_per1@80126000 { + compatible = "arm,pl18x", "arm,primecell"; + reg = <0x80126000 0x1000>; + interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>; + + dmas = <&dma 29 0 0x2>, /* Logical - DevToMem */ + <&dma 29 0 0x0>; /* Logical - MemToDev */ + dma-names = "rx", "tx"; + + clocks = <&prcc_kclk 1 5>, <&prcc_pclk 1 5>; + clock-names = "sdi", "apb_pclk"; + + max-frequency = <100000000>; + bus-width = <4>; + cap-sd-highspeed; + cap-mmc-highspeed; + cd-gpios = <&gpio2 31 0x4>; // 95 + st,sig-dir-dat0; + st,sig-dir-dat2; + st,sig-dir-cmd; + st,sig-pin-fbclk; + + vmmc-supply = <&ab8500_ldo_aux3_reg>; + vqmmc-supply = <&vmmci>; + + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&sdi0_default_mode>; + pinctrl-1 = <&sdi0_sleep_mode>; +}; diff --git a/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt new file mode 100644 index 0000000..b638191 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt @@ -0,0 +1,30 @@ +MOXA ART MMC Host Controller Interface + + Inherits from mmc binding[1]. + + [1] Documentation/devicetree/bindings/mmc/mmc.txt + +Required properties: + +- compatible : Must be "moxa,moxart-mmc" or "faraday,ftsdc010" +- reg : Should contain registers location and length +- interrupts : Should contain the interrupt number +- clocks : Should contain phandle for the clock feeding the MMC controller + +Optional properties: + +- dmas : Should contain two DMA channels, line request number must be 5 for + both channels +- dma-names : Must be "tx", "rx" + +Example: + + mmc: mmc@98e00000 { + compatible = "moxa,moxart-mmc"; + reg = <0x98e00000 0x5C>; + interrupts = <5 0>; + clocks = <&clk_apb>; + dmas = <&dma 5>, + <&dma 5>; + dma-names = "tx", "rx"; + }; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt new file mode 100644 index 0000000..81b33b5 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -0,0 +1,55 @@ +* Qualcomm SDHCI controller (sdhci-msm) + +This file documents differences between the core properties in mmc.txt +and the properties used by the sdhci-msm driver. + +Required properties: +- compatible: Should contain "qcom,sdhci-msm-v4". +- reg: Base address and length of the register in the following order: + - Host controller register map (required) + - SD Core register map (required) +- interrupts: Should contain an interrupt-specifiers for the interrupts: + - Host controller interrupt (required) +- pinctrl-names: Should contain only one value - "default". +- pinctrl-0: Should specify pin control groups used for this controller. +- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock-names. +- clock-names: Should contain the following: + "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required) + "core" - SDC MMC clock (MCLK) (required) + "bus" - SDCC bus voter clock (optional) + +Example: + + sdhc_1: sdhci@f9824900 { + compatible = "qcom,sdhci-msm-v4"; + reg = <0xf9824900 0x11c>, <0xf9824000 0x800>; + interrupts = <0 123 0>; + bus-width = <8>; + non-removable; + + vmmc = <&pm8941_l20>; + vqmmc = <&pm8941_s3>; + + pinctrl-names = "default"; + pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data>; + + clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>; + clock-names = "core", "iface"; + }; + + sdhc_2: sdhci@f98a4900 { + compatible = "qcom,sdhci-msm-v4"; + reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>; + interrupts = <0 125 0>; + bus-width = <4>; + cd-gpios = <&msmgpio 62 0x1>; + + vmmc = <&pm8941_l21>; + vqmmc = <&pm8941_l13>; + + pinctrl-names = "default"; + pinctrl-0 = <&sdc2_clk &sdc2_cmd &sdc2_data>; + + clocks = <&gcc GCC_SDCC2_APPS_CLK>, <&gcc GCC_SDCC2_AHB_CLK>; + clock-names = "core", "iface"; + }; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt index dbe98a3..86223c3 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt @@ -4,7 +4,14 @@ This file documents differences between the core properties in mmc.txt and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers. Required properties: -- compatible: Should be "mrvl,pxav2-mmc" or "mrvl,pxav3-mmc". +- compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or + "marvell,armada-380-sdhci". +- reg: + * for "mrvl,pxav2-mmc" and "mrvl,pxav3-mmc", one register area for + the SDHCI registers. + * for "marvell,armada-380-sdhci", two register areas. The first one + for the SDHCI registers themselves, and the second one for the + AXI/Mbus bridge registers of the SDHCI unit. Optional properties: - mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning. @@ -19,3 +26,11 @@ sdhci@d4280800 { non-removable; mrvl,clk-delay-cycles = <31>; }; + +sdhci@d8000 { + compatible = "marvell,armada-380-sdhci"; + reg = <0xd8000 0x1000>, <0xdc000 0x100>; + interrupts = <0 25 0x4>; + clocks = <&gateclk 17>; + mrvl,clk-delay-cycles = <0x1F>; +}; diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt new file mode 100644 index 0000000..4897bea --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt @@ -0,0 +1,23 @@ +* Altera SOCFPGA specific extensions to the Synopsys Designware Mobile + Storage Host Controller + +The Synopsys designware mobile storage host controller is used to interface +a SoC with storage medium such as eMMC or SD/MMC cards. This file documents +differences between the core Synopsys dw mshc controller properties described +by synopsys-dw-mshc.txt and the properties used by the Altera SOCFPGA specific +extensions to the Synopsys Designware Mobile Storage Host Controller. + +Required Properties: + +* compatible: should be + - "altr,socfpga-dw-mshc": for Altera's SOCFPGA platform + +Example: + + mmc: dwmmc0@ff704000 { + compatible = "altr,socfpga-dw-mshc"; + reg = <0xff704000 0x1000>; + interrupts = <0 129 4>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt new file mode 100644 index 0000000..91b3a34 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt @@ -0,0 +1,43 @@ +* Allwinner sunxi MMC controller + +The highspeed MMC host controller on Allwinner SoCs provides an interface +for MMC, SD and SDIO types of memory cards. + +Supported maximum speeds are the ones of the eMMC standard 4.5 as well +as the speed of SD standard 3.0. +Absolute maximum transfer rate is 200MB/s + +Required properties: + - compatible : "allwinner,sun4i-a10-mmc" or "allwinner,sun5i-a13-mmc" + - reg : mmc controller base registers + - clocks : a list with 2 phandle + clock specifier pairs + - clock-names : must contain "ahb" and "mmc" + - interrupts : mmc controller interrupt + +Optional properties: + - resets : phandle + reset specifier pair + - reset-names : must contain "ahb" + - for cd, bus-width and additional generic mmc parameters + please refer to mmc.txt within this directory + +Examples: + - Within .dtsi: + mmc0: mmc@01c0f000 { + compatible = "allwinner,sun5i-a13-mmc"; + reg = <0x01c0f000 0x1000>; + clocks = <&ahb_gates 8>, <&mmc0_clk>; + clock-names = "ahb", "mod"; + interrupts = <0 32 4>; + status = "disabled"; + }; + + - Within dts: + mmc0: mmc@01c0f000 { + pinctrl-names = "default", "default"; + pinctrl-0 = <&mmc0_pins_a>; + pinctrl-1 = <&mmc0_cd_pin_reference_design>; + bus-width = <4>; + cd-gpios = <&pio 7 1 0>; /* PH1 */ + cd-inverted; + status = "okay"; + }; diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt index 8f3f133..2d4a725 100644 --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt @@ -69,10 +69,6 @@ Optional properties: * supports-highspeed: Enables support for high speed cards (up to 50MHz) -* caps2-mmc-hs200-1_8v: Supports mmc HS200 SDR 1.8V mode - -* caps2-mmc-hs200-1_2v: Supports mmc HS200 SDR 1.2V mode - * broken-cd: as documented in mmc core bindings. * vmmc-supply: The phandle to the regulator to use for vmmc. If this is @@ -103,7 +99,6 @@ board specific portions as listed below. clock-freq-min-max = <400000 200000000>; num-slots = <1>; supports-highspeed; - caps2-mmc-hs200-1_8v; broken-cd; fifo-depth = <0x80>; card-detect-delay = <200>; diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908a..ce80561 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -10,6 +10,7 @@ Required properties: - compatible: Should be "ti,omap2-hsmmc", for OMAP2 controllers Should be "ti,omap3-hsmmc", for OMAP3 controllers + Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0 Should be "ti,omap4-hsmmc", for OMAP4 controllers - ti,hwmods: Must be "mmc<n>", n is controller instance starting 1 diff --git a/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt new file mode 100644 index 0000000..8babdaa --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt @@ -0,0 +1,33 @@ +* Renesas usdhi6rol0 SD/SDIO host controller + +Required properties: + +- compatible: must be + "renesas,usdhi6rol0" +- interrupts: 3 interrupts, named "card detect", "data" and "SDIO" must be + specified +- clocks: a clock binding for the IMCLK input + +Optional properties: + +- vmmc-supply: a phandle of a regulator, supplying Vcc to the card +- vqmmc-supply: a phandle of a regulator, supplying VccQ to the card + +Additionally any standard mmc bindings from mmc.txt can be used. + +Example: + +sd0: sd@ab000000 { + compatible = "renesas,usdhi6rol0"; + reg = <0xab000000 0x200>; + interrupts = <0 23 0x4 + 0 24 0x4 + 0 25 0x4>; + interrupt-names = "card detect", "data", "SDIO"; + bus-width = <4>; + max-frequency = <50000000>; + cap-power-off-card; + clocks = <&imclk>; + vmmc-supply = <&vcc_sd0>; + vqmmc-supply = <&vccq_sd0>; +}; diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt new file mode 100644 index 0000000..823d134 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt @@ -0,0 +1,35 @@ +* Freescale Quad Serial Peripheral Interface(QuadSPI) + +Required properties: + - compatible : Should be "fsl,vf610-qspi" + - reg : the first contains the register location and length, + the second contains the memory mapping address and length + - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory" + - interrupts : Should contain the interrupt for the device + - clocks : The clocks needed by the QuadSPI controller + - clock-names : the name of the clocks + +Optional properties: + - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B. + Each bus can be connected with two NOR flashes. + Most of the time, each bus only has one NOR flash + connected, this is the default case. + But if there are two NOR flashes connected to the + bus, you should enable this property. + (Please check the board's schematic.) + +Example: + +qspi0: quadspi@40044000 { + compatible = "fsl,vf610-qspi"; + reg = <0x40044000 0x1000>, <0x20000000 0x10000000>; + reg-names = "QuadSPI", "QuadSPI-memory"; + interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks VF610_CLK_QSPI0_EN>, + <&clks VF610_CLK_QSPI0>; + clock-names = "qspi_en", "qspi"; + + flash0: s25fl128s@0 { + .... + }; +}; diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index eb05255..65f4f7c 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -28,6 +28,8 @@ Optional properties: "ham1" 1-bit Hamming ecc code "bch4" 4-bit BCH ecc code "bch8" 8-bit BCH ecc code + "bch16" 16-bit BCH ECC code + Refer below "How to select correct ECC scheme for your device ?" - ti,nand-xfer-type: A string setting the data transfer type. One of: @@ -90,3 +92,46 @@ Example for an AM33xx board: }; }; +How to select correct ECC scheme for your device ? +-------------------------------------------------- +Higher ECC scheme usually means better protection against bit-flips and +increased system lifetime. However, selection of ECC scheme is dependent +on various other factors also like; + +(1) support of built in hardware engines. + Some legacy OMAP SoC do not have ELM harware engine, so those SoC cannot + support ecc-schemes with hardware error-correction (BCHx_HW). However + such SoC can use ecc-schemes with software library for error-correction + (BCHx_HW_DETECTION_SW). The error correction capability with software + library remains equivalent to their hardware counter-part, but there is + slight CPU penalty when too many bit-flips are detected during reads. + +(2) Device parameters like OOBSIZE. + Other factor which governs the selection of ecc-scheme is oob-size. + Higher ECC schemes require more OOB/Spare area to store ECC syndrome, + so the device should have enough free bytes available its OOB/Spare + area to accomodate ECC for entire page. In general following expression + helps in determining if given device can accomodate ECC syndrome: + "2 + (PAGESIZE / 512) * ECC_BYTES" >= OOBSIZE" + where + OOBSIZE number of bytes in OOB/spare area + PAGESIZE number of bytes in main-area of device page + ECC_BYTES number of ECC bytes generated to protect + 512 bytes of data, which is: + '3' for HAM1_xx ecc schemes + '7' for BCH4_xx ecc schemes + '14' for BCH8_xx ecc schemes + '26' for BCH16_xx ecc schemes + + Example(a): For a device with PAGESIZE = 2048 and OOBSIZE = 64 and + trying to use BCH16 (ECC_BYTES=26) ecc-scheme. + Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B + which is greater than capacity of NAND device (OOBSIZE=64) + Hence, BCH16 cannot be supported on given device. But it can + probably use lower ecc-schemes like BCH8. + + Example(b): For a device with PAGESIZE = 2048 and OOBSIZE = 128 and + trying to use BCH16 (ECC_BYTES=26) ecc-scheme. + Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B + which can be accomodate in the OOB/Spare area of this device + (OOBSIZE=128). So this device can use BCH16 ecc-scheme. diff --git a/Documentation/devicetree/bindings/mtd/m25p80.txt b/Documentation/devicetree/bindings/mtd/m25p80.txt index 6d3d576..4611aa8 100644 --- a/Documentation/devicetree/bindings/mtd/m25p80.txt +++ b/Documentation/devicetree/bindings/mtd/m25p80.txt @@ -5,8 +5,8 @@ Required properties: representing partitions. - compatible : Should be the manufacturer and the name of the chip. Bear in mind the DT binding is not Linux-only, but in case of Linux, see the - "m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of - supported chips. + "spi_nor_ids" table in drivers/mtd/spi-nor/spi-nor.c for the list + of supported chips. - reg : Chip-Select number - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt index 03855c8..b53f92e 100644 --- a/Documentation/devicetree/bindings/mtd/nand.txt +++ b/Documentation/devicetree/bindings/mtd/nand.txt @@ -5,3 +5,17 @@ "soft_bch". - nand-bus-width : 8 or 16 bus width if not present 8 - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false + +- nand-ecc-strength: integer representing the number of bits to correct + per ECC step. + +- nand-ecc-step-size: integer representing the number of data bytes + that are covered by a single ECC step. + +The ECC strength and ECC step size properties define the correction capability +of a controller. Together, they say a controller can correct "{strength} bit +errors per {size} bytes". + +The interpretation of these parameters is implementation-defined, so not all +implementations must support all possible combinations. However, implementations +are encouraged to further specify the value(s) they support. diff --git a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt index 86e0a56..de8b517 100644 --- a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt +++ b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt @@ -17,6 +17,14 @@ Optional properties: - num-cs: Number of chipselect lines to usw - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false + - nand-ecc-strength: number of bits to correct per ECC step + - nand-ecc-step-size: number of data bytes covered by a single ECC step + +The following ECC strength and step size are currently supported: + + - nand-ecc-strength = <1>, nand-ecc-step-size = <512> + - nand-ecc-strength = <4>, nand-ecc-step-size = <512> + - nand-ecc-strength = <8>, nand-ecc-step-size = <512> Example: diff --git a/Documentation/devicetree/bindings/mtd/st-fsm.txt b/Documentation/devicetree/bindings/mtd/st-fsm.txt new file mode 100644 index 0000000..c248939 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/st-fsm.txt @@ -0,0 +1,26 @@ +* ST-Microelectronics SPI FSM Serial (NOR) Flash Controller + +Required properties: + - compatible : Should be "st,spi-fsm" + - reg : Contains register's location and length. + - reg-names : Should contain the reg names "spi-fsm" + - interrupts : The interrupt number + - pinctrl-0 : Standard Pinctrl phandle (see: pinctrl/pinctrl-bindings.txt) + +Optional properties: + - st,syscfg : Phandle to boot-device system configuration registers + - st,boot-device-reg : Address of the aforementioned boot-device register(s) + - st,boot-device-spi : Expected boot-device value if booted via this device + +Example: + spifsm: spifsm@fe902000{ + compatible = "st,spi-fsm"; + reg = <0xfe902000 0x1000>; + reg-names = "spi-fsm"; + pinctrl-0 = <&pinctrl_fsm>; + st,syscfg = <&syscfg_rear>; + st,boot-device-reg = <0x958>; + st,boot-device-spi = <0x1a>; + status = "okay"; + }; + diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt index 863d5b81..10640b1 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt @@ -5,13 +5,9 @@ Required properties: "allwinner,sun4i-emac") - reg: address and length of the register set for the device. - interrupts: interrupt for the device -- phy: A phandle to a phy node defining the PHY address (as the reg - property, a single integer). +- phy: see ethernet.txt file in the same directory. - clocks: A phandle to the reference clock for this device -Optional properties: -- (local-)mac-address: mac address to be used by this driver - Example: emac: ethernet@01c0b000 { diff --git a/Documentation/devicetree/bindings/net/altera_tse.txt b/Documentation/devicetree/bindings/net/altera_tse.txt new file mode 100644 index 0000000..a706297 --- /dev/null +++ b/Documentation/devicetree/bindings/net/altera_tse.txt @@ -0,0 +1,114 @@ +* Altera Triple-Speed Ethernet MAC driver (TSE) + +Required properties: +- compatible: Should be "altr,tse-1.0" for legacy SGDMA based TSE, and should + be "altr,tse-msgdma-1.0" for the preferred MSGDMA based TSE. + ALTR is supported for legacy device trees, but is deprecated. + altr should be used for all new designs. +- reg: Address and length of the register set for the device. It contains + the information of registers in the same order as described by reg-names +- reg-names: Should contain the reg names + "control_port": MAC configuration space region + "tx_csr": xDMA Tx dispatcher control and status space region + "tx_desc": MSGDMA Tx dispatcher descriptor space region + "rx_csr" : xDMA Rx dispatcher control and status space region + "rx_desc": MSGDMA Rx dispatcher descriptor space region + "rx_resp": MSGDMA Rx dispatcher response space region + "s1": SGDMA descriptor memory +- interrupts: Should contain the TSE interrupts and it's mode. +- interrupt-names: Should contain the interrupt names + "rx_irq": xDMA Rx dispatcher interrupt + "tx_irq": xDMA Tx dispatcher interrupt +- rx-fifo-depth: MAC receive FIFO buffer depth in bytes +- tx-fifo-depth: MAC transmit FIFO buffer depth in bytes +- phy-mode: See ethernet.txt in the same directory. +- phy-handle: See ethernet.txt in the same directory. +- phy-addr: See ethernet.txt in the same directory. A configuration should + include phy-handle or phy-addr. +- altr,has-supplementary-unicast: + If present, TSE supports additional unicast addresses. + Otherwise additional unicast addresses are not supported. +- altr,has-hash-multicast-filter: + If present, TSE supports a hash based multicast filter. + Otherwise, hash-based multicast filtering is not supported. + +- mdio device tree subnode: When the TSE has a phy connected to its local + mdio, there must be device tree subnode with the following + required properties: + + - compatible: Must be "altr,tse-mdio". + - #address-cells: Must be <1>. + - #size-cells: Must be <0>. + + For each phy on the mdio bus, there must be a node with the following + fields: + + - reg: phy id used to communicate to phy. + - device_type: Must be "ethernet-phy". + +Optional properties: +- local-mac-address: See ethernet.txt in the same directory. +- max-frame-size: See ethernet.txt in the same directory. + +Example: + + tse_sub_0_eth_tse_0: ethernet@0x1,00000000 { + compatible = "altr,tse-msgdma-1.0"; + reg = <0x00000001 0x00000000 0x00000400>, + <0x00000001 0x00000460 0x00000020>, + <0x00000001 0x00000480 0x00000020>, + <0x00000001 0x000004A0 0x00000008>, + <0x00000001 0x00000400 0x00000020>, + <0x00000001 0x00000420 0x00000020>; + reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp", "tx_csr", "tx_desc"; + interrupt-parent = <&hps_0_arm_gic_0>; + interrupts = <0 41 4>, <0 40 4>; + interrupt-names = "rx_irq", "tx_irq"; + rx-fifo-depth = <2048>; + tx-fifo-depth = <2048>; + address-bits = <48>; + max-frame-size = <1500>; + local-mac-address = [ 00 00 00 00 00 00 ]; + phy-mode = "gmii"; + altr,has-supplementary-unicast; + altr,has-hash-multicast-filter; + phy-handle = <&phy0>; + mdio { + compatible = "altr,tse-mdio"; + #address-cells = <1>; + #size-cells = <0>; + phy0: ethernet-phy@0 { + reg = <0x0>; + device_type = "ethernet-phy"; + }; + + phy1: ethernet-phy@1 { + reg = <0x1>; + device_type = "ethernet-phy"; + }; + + }; + }; + + tse_sub_1_eth_tse_0: ethernet@0x1,00001000 { + compatible = "altr,tse-msgdma-1.0"; + reg = <0x00000001 0x00001000 0x00000400>, + <0x00000001 0x00001460 0x00000020>, + <0x00000001 0x00001480 0x00000020>, + <0x00000001 0x000014A0 0x00000008>, + <0x00000001 0x00001400 0x00000020>, + <0x00000001 0x00001420 0x00000020>; + reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp", "tx_csr", "tx_desc"; + interrupt-parent = <&hps_0_arm_gic_0>; + interrupts = <0 43 4>, <0 42 4>; + interrupt-names = "rx_irq", "tx_irq"; + rx-fifo-depth = <2048>; + tx-fifo-depth = <2048>; + address-bits = <48>; + max-frame-size = <1500>; + local-mac-address = [ 00 00 00 00 00 00 ]; + phy-mode = "gmii"; + altr,has-supplementary-unicast; + altr,has-hash-multicast-filter; + phy-handle = <&phy1>; + }; diff --git a/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt b/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt new file mode 100644 index 0000000..42409bf --- /dev/null +++ b/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt @@ -0,0 +1,23 @@ +* AMD 10GbE PHY driver (amd-xgbe-phy) + +Required properties: +- compatible: Should be "amd,xgbe-phy-seattle-v1a" and + "ethernet-phy-ieee802.3-c45" +- reg: Address and length of the register sets for the device + - SerDes Rx/Tx registers + - SerDes integration registers (1/2) + - SerDes integration registers (2/2) + +Optional properties: +- amd,speed-set: Speed capabilities of the device + 0 - 1GbE and 10GbE (default) + 1 - 2.5GbE and 10GbE + +Example: + xgbe_phy@e1240800 { + compatible = "amd,xgbe-phy-seattle-v1a", "ethernet-phy-ieee802.3-c45"; + reg = <0 0xe1240800 0 0x00400>, + <0 0xe1250000 0 0x00060>, + <0 0xe1250080 0 0x00004>; + amd,speed-set = <0>; + }; diff --git a/Documentation/devicetree/bindings/net/amd-xgbe.txt b/Documentation/devicetree/bindings/net/amd-xgbe.txt new file mode 100644 index 0000000..41354f7 --- /dev/null +++ b/Documentation/devicetree/bindings/net/amd-xgbe.txt @@ -0,0 +1,39 @@ +* AMD 10GbE driver (amd-xgbe) + +Required properties: +- compatible: Should be "amd,xgbe-seattle-v1a" +- reg: Address and length of the register sets for the device + - MAC registers + - PCS registers +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the amd-xgbe interrupt +- clocks: + - DMA clock for the amd-xgbe device (used for calculating the + correct Rx interrupt watchdog timer value on a DMA channel + for coalescing) + - PTP clock for the amd-xgbe device +- clock-names: Should be the names of the clocks + - "dma_clk" for the DMA clock + - "ptp_clk" for the PTP clock +- phy-handle: See ethernet.txt file in the same directory +- phy-mode: See ethernet.txt file in the same directory + +Optional properties: +- mac-address: mac address to be assigned to the device. Can be overridden + by UEFI. +- dma-coherent: Present if dma operations are coherent + +Example: + xgbe@e0700000 { + compatible = "amd,xgbe-seattle-v1a"; + reg = <0 0xe0700000 0 0x80000>, + <0 0xe0780000 0 0x80000>; + interrupt-parent = <&gic>; + interrupts = <0 325 4>; + clocks = <&xgbe_dma_clk>, <&xgbe_ptp_clk>; + clock-names = "dma_clk", "ptp_clk"; + phy-handle = <&phy>; + phy-mode = "xgmii"; + mac-address = [ 02 a1 a2 a3 a4 a5 ]; + }; diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt b/Documentation/devicetree/bindings/net/arc_emac.txt index bcbc3f0..a1d71eb 100644 --- a/Documentation/devicetree/bindings/net/arc_emac.txt +++ b/Documentation/devicetree/bindings/net/arc_emac.txt @@ -4,21 +4,18 @@ Required properties: - compatible: Should be "snps,arc-emac" - reg: Address and length of the register set for the device - interrupts: Should contain the EMAC interrupts -- clock-frequency: CPU frequency. It is needed to calculate and set polling -period of EMAC. -- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations -bandwidth of external memory controller might be a limiting factor. That's why -it's required to specify which data-rate is supported on current SoC or FPGA. -For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s is -supported (100BASE-TX) set "100". -- phy: PHY device attached to the EMAC via MDIO bus +- max-speed: see ethernet.txt file in the same directory. +- phy: see ethernet.txt file in the same directory. + +Clock handling: +The clock frequency is needed to calculate and set polling period of EMAC. +It must be provided by one of: +- clock-frequency: CPU frequency. +- clocks: reference to the clock supplying the EMAC. Child nodes of the driver are the individual PHY devices connected to the MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus. -Optional properties: -- mac-address: 6 bytes, mac address - Examples: ethernet@c0fc2000 { @@ -26,7 +23,11 @@ Examples: reg = <0xc0fc2000 0x3c>; interrupts = <6>; mac-address = [ 00 11 22 33 44 55 ]; + clock-frequency = <80000000>; + /* or */ + clocks = <&emac_clock>; + max-speed = <100>; phy = <&phy0>; diff --git a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt new file mode 100644 index 0000000..451fef2 --- /dev/null +++ b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt @@ -0,0 +1,121 @@ +* Broadcom BCM7xxx Ethernet Controller (GENET) + +Required properties: +- compatible: should contain one of "brcm,genet-v1", "brcm,genet-v2", + "brcm,genet-v3", "brcm,genet-v4". +- reg: address and length of the register set for the device +- interrupts: must be two cells, the first cell is the general purpose + interrupt line, while the second cell is the interrupt for the ring + RX and TX queues operating in ring mode +- phy-mode: see ethernet.txt file in the same directory +- #address-cells: should be 1 +- #size-cells: should be 1 + +Optional properties: +- clocks: When provided, must be two phandles to the functional clocks nodes + of the GENET block. The first phandle is the main GENET clock used during + normal operation, while the second phandle is the Wake-on-LAN clock. +- clock-names: When provided, names of the functional clock phandles, first + name should be "enet" and second should be "enet-wol". + +- phy-handle: See ethernet.txt file in the same directory; used to describe + configurations where a PHY (internal or external) is used. + +- fixed-link: When the GENET interface is connected to a MoCA hardware block or + when operating in a RGMII to RGMII type of connection, or when the MDIO bus is + voluntarily disabled, this property should be used to describe the "fixed link". + See Documentation/devicetree/bindings/net/fixed-link.txt for information on + the property specifics + +Required child nodes: + +- mdio bus node: this node should always be present regarless of the PHY + configuration of the GENET instance + +MDIO bus node required properties: + +- compatible: should contain one of "brcm,genet-mdio-v1", "brcm,genet-mdio-v2" + "brcm,genet-mdio-v3", "brcm,genet-mdio-v4", the version has to match the + parent node compatible property (e.g: brcm,genet-v4 pairs with + brcm,genet-mdio-v4) +- reg: address and length relative to the parent node base register address +- #address-cells: address cell for MDIO bus addressing, should be 1 +- #size-cells: size of the cells for MDIO bus addressing, should be 0 + +Ethernet PHY node properties: + +See Documentation/devicetree/bindings/net/phy.txt for the list of required and +optional properties. + +Internal Gigabit PHY example: + +ethernet@f0b60000 { + phy-mode = "internal"; + phy-handle = <&phy1>; + mac-address = [ 00 10 18 36 23 1a ]; + compatible = "brcm,genet-v4"; + #address-cells = <0x1>; + #size-cells = <0x1>; + reg = <0xf0b60000 0xfc4c>; + interrupts = <0x0 0x14 0x0>, <0x0 0x15 0x0>; + + mdio@e14 { + compatible = "brcm,genet-mdio-v4"; + #address-cells = <0x1>; + #size-cells = <0x0>; + reg = <0xe14 0x8>; + + phy1: ethernet-phy@1 { + max-speed = <1000>; + reg = <0x1>; + compatible = "brcm,28nm-gphy", "ethernet-phy-ieee802.3-c22"; + }; + }; +}; + +MoCA interface / MAC to MAC example: + +ethernet@f0b80000 { + phy-mode = "moca"; + fixed-link = <1 0 1000 0 0>; + mac-address = [ 00 10 18 36 24 1a ]; + compatible = "brcm,genet-v4"; + #address-cells = <0x1>; + #size-cells = <0x1>; + reg = <0xf0b80000 0xfc4c>; + interrupts = <0x0 0x16 0x0>, <0x0 0x17 0x0>; + + mdio@e14 { + compatible = "brcm,genet-mdio-v4"; + #address-cells = <0x1>; + #size-cells = <0x0>; + reg = <0xe14 0x8>; + }; +}; + + +External MDIO-connected Gigabit PHY/switch: + +ethernet@f0ba0000 { + phy-mode = "rgmii"; + phy-handle = <&phy0>; + mac-address = [ 00 10 18 36 26 1a ]; + compatible = "brcm,genet-v4"; + #address-cells = <0x1>; + #size-cells = <0x1>; + reg = <0xf0ba0000 0xfc4c>; + interrupts = <0x0 0x18 0x0>, <0x0 0x19 0x0>; + + mdio@0e14 { + compatible = "brcm,genet-mdio-v4"; + #address-cells = <0x1>; + #size-cells = <0x0>; + reg = <0xe14 0x8>; + + phy0: ethernet-phy@0 { + max-speed = <1000>; + reg = <0x0>; + compatible = "brcm,bcm53125", "ethernet-phy-ieee802.3-c22"; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/net/broadcom-systemport.txt b/Documentation/devicetree/bindings/net/broadcom-systemport.txt new file mode 100644 index 0000000..aa7ad62 --- /dev/null +++ b/Documentation/devicetree/bindings/net/broadcom-systemport.txt @@ -0,0 +1,30 @@ +* Broadcom BCM7xxx Ethernet Systemport Controller (SYSTEMPORT) + +Required properties: +- compatible: should be one of "brcm,systemport-v1.00" or "brcm,systemport" +- reg: address and length of the register set for the device. +- interrupts: interrupts for the device, first cell must be for the the rx + interrupts, and the second cell should be for the transmit queues. An + optional third interrupt cell for Wake-on-LAN can be specified +- local-mac-address: Ethernet MAC address (48 bits) of this adapter +- phy-mode: Should be a string describing the PHY interface to the + Ethernet switch/PHY, see Documentation/devicetree/bindings/net/ethernet.txt +- fixed-link: see Documentation/devicetree/bindings/net/fixed-link.txt for + the property specific details + +Optional properties: +- systemport,num-tier2-arb: number of tier 2 arbiters, an integer +- systemport,num-tier1-arb: number of tier 1 arbiters, an integer +- systemport,num-txq: number of HW transmit queues, an integer +- systemport,num-rxq: number of HW receive queues, an integer + +Example: +ethernet@f04a0000 { + compatible = "brcm,systemport-v1.00"; + reg = <0xf04a0000 0x4650>; + local-mac-address = [ 00 11 22 33 44 55 ]; + fixed-link = <0 1 1000 0 0>; + phy-mode = "gmii"; + interrupts = <0x0 0x16 0x0>, + <0x0 0x17 0x0>; +}; diff --git a/Documentation/devicetree/bindings/net/can/sja1000.txt b/Documentation/devicetree/bindings/net/can/sja1000.txt index f2105a4..b4a6d53 100644 --- a/Documentation/devicetree/bindings/net/can/sja1000.txt +++ b/Documentation/devicetree/bindings/net/can/sja1000.txt @@ -12,6 +12,10 @@ Required properties: Optional properties: +- reg-io-width : Specify the size (in bytes) of the IO accesses that + should be performed on the device. Valid value is 1, 2 or 4. + Default to 1 (8 bits). + - nxp,external-clock-frequency : Frequency of the external oscillator clock in Hz. Note that the internal clock frequency used by the SJA1000 is half of that value. If not specified, a default value diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt b/Documentation/devicetree/bindings/net/can/xilinx_can.txt new file mode 100644 index 0000000..fe38847 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/xilinx_can.txt @@ -0,0 +1,44 @@ +Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings +--------------------------------------------------------- + +Required properties: +- compatible : Should be "xlnx,zynq-can-1.0" for Zynq CAN + controllers and "xlnx,axi-can-1.00.a" for Axi CAN + controllers. +- reg : Physical base address and size of the Axi CAN/Zynq + CANPS registers map. +- interrupts : Property with a value describing the interrupt + number. +- interrupt-parent : Must be core interrupt controller +- clock-names : List of input clock names - "can_clk", "pclk" + (For CANPS), "can_clk" , "s_axi_aclk"(For AXI CAN) + (See clock bindings for details). +- clocks : Clock phandles (see clock bindings for details). +- tx-fifo-depth : Can Tx fifo depth. +- rx-fifo-depth : Can Rx fifo depth. + + +Example: + +For Zynq CANPS Dts file: + zynq_can_0: can@e0008000 { + compatible = "xlnx,zynq-can-1.0"; + clocks = <&clkc 19>, <&clkc 36>; + clock-names = "can_clk", "pclk"; + reg = <0xe0008000 0x1000>; + interrupts = <0 28 4>; + interrupt-parent = <&intc>; + tx-fifo-depth = <0x40>; + rx-fifo-depth = <0x40>; + }; +For Axi CAN Dts file: + axi_can_0: axi-can@40000000 { + compatible = "xlnx,axi-can-1.00.a"; + clocks = <&clkc 0>, <&clkc 1>; + clock-names = "can_clk","s_axi_aclk" ; + reg = <0x40000000 0x10000>; + interrupt-parent = <&intc>; + interrupts = <0 59 1>; + tx-fifo-depth = <0x40>; + rx-fifo-depth = <0x40>; + }; diff --git a/Documentation/devicetree/bindings/net/cavium-mix.txt b/Documentation/devicetree/bindings/net/cavium-mix.txt index 5da628d..8d7c309 100644 --- a/Documentation/devicetree/bindings/net/cavium-mix.txt +++ b/Documentation/devicetree/bindings/net/cavium-mix.txt @@ -18,12 +18,7 @@ Properties: - interrupts: Two interrupt specifiers. The first is the MIX interrupt routing and the second the routing for the AGL interrupts. -- mac-address: Optional, the MAC address to assign to the device. - -- local-mac-address: Optional, the MAC address to assign to the device - if mac-address is not specified. - -- phy-handle: Optional, a phandle for the PHY device connected to this device. +- phy-handle: Optional, see ethernet.txt file in the same directory. Example: ethernet@1070000100800 { diff --git a/Documentation/devicetree/bindings/net/cavium-pip.txt b/Documentation/devicetree/bindings/net/cavium-pip.txt index d4c53ba..7dbd158 100644 --- a/Documentation/devicetree/bindings/net/cavium-pip.txt +++ b/Documentation/devicetree/bindings/net/cavium-pip.txt @@ -35,12 +35,7 @@ Properties for PIP port which is a child the PIP interface: - reg: The port number within the interface group. -- mac-address: Optional, the MAC address to assign to the device. - -- local-mac-address: Optional, the MAC address to assign to the device - if mac-address is not specified. - -- phy-handle: Optional, a phandle for the PHY device connected to this device. +- phy-handle: Optional, see ethernet.txt file in the same directory. Example: diff --git a/Documentation/devicetree/bindings/net/cdns-emac.txt b/Documentation/devicetree/bindings/net/cdns-emac.txt index 09055c2..abd67c1 100644 --- a/Documentation/devicetree/bindings/net/cdns-emac.txt +++ b/Documentation/devicetree/bindings/net/cdns-emac.txt @@ -6,11 +6,7 @@ Required properties: or the generic form: "cdns,emac". - reg: Address and length of the register set for the device - interrupts: Should contain macb interrupt -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii". - -Optional properties: -- local-mac-address: 6 bytes, mac address +- phy-mode: see ethernet.txt file in the same directory. Examples: diff --git a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt index 7ff57a1..764c0c7 100644 --- a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt +++ b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt @@ -2,7 +2,9 @@ TI CPSW Phy mode Selection Device Tree Bindings ----------------------------------------------- Required properties: -- compatible : Should be "ti,am3352-cpsw-phy-sel" +- compatible : Should be "ti,am3352-cpsw-phy-sel" for am335x platform and + "ti,dra7xx-cpsw-phy-sel" for dra7xx platform + "ti,am43xx-cpsw-phy-sel" for am43xx platform - reg : physical base address and size of the cpsw registers map - reg-names : names of the register map given in "reg" node diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index 05d660e..ae2b8b7 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -28,9 +28,8 @@ Optional properties: Slave Properties: Required properties: - phy_id : Specifies slave phy id -- phy-mode : The interface between the SoC and the PHY (a string - that of_get_phy_mode() can understand) -- mac-address : Specifies slave MAC address +- phy-mode : See ethernet.txt file in the same directory +- mac-address : See ethernet.txt file in the same directory Optional properties: - dual_emac_res_vlan : Specifies VID to be used to segregate the ports diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt b/Documentation/devicetree/bindings/net/davicom-dm9000.txt index 2d39c99..28767ed 100644 --- a/Documentation/devicetree/bindings/net/davicom-dm9000.txt +++ b/Documentation/devicetree/bindings/net/davicom-dm9000.txt @@ -9,8 +9,6 @@ Required properties: - interrupts : interrupt specifier specific to interrupt controller Optional properties: -- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address - to use (from firmware or bootloader) - davicom,no-eeprom : Configuration EEPROM is not available - davicom,ext-phy : Use external PHY diff --git a/Documentation/devicetree/bindings/net/davinci-mdio.txt b/Documentation/devicetree/bindings/net/davinci-mdio.txt index 72efaaf..0369e25 100644 --- a/Documentation/devicetree/bindings/net/davinci-mdio.txt +++ b/Documentation/devicetree/bindings/net/davinci-mdio.txt @@ -1,8 +1,8 @@ -TI SoC Davinci MDIO Controller Device Tree Bindings +TI SoC Davinci/Keystone2 MDIO Controller Device Tree Bindings --------------------------------------------------- Required properties: -- compatible : Should be "ti,davinci_mdio" +- compatible : Should be "ti,davinci_mdio" or "ti,keystone_mdio" - reg : physical base address and size of the davinci mdio registers map - bus_freq : Mdio Bus frequency @@ -19,7 +19,7 @@ file. Examples: mdio: davinci_mdio@4A101000 { - compatible = "ti,cpsw"; + compatible = "ti,davinci_mdio"; reg = <0x4A101000 0x1000>; bus_freq = <1000000>; }; @@ -27,7 +27,7 @@ Examples: (or) mdio: davinci_mdio@4A101000 { - compatible = "ti,cpsw"; + compatible = "ti,davinci_mdio"; ti,hwmods = "davinci_mdio"; bus_freq = <1000000>; }; diff --git a/Documentation/devicetree/bindings/net/davinci_emac.txt b/Documentation/devicetree/bindings/net/davinci_emac.txt index 6e356d1..0328088 100644 --- a/Documentation/devicetree/bindings/net/davinci_emac.txt +++ b/Documentation/devicetree/bindings/net/davinci_emac.txt @@ -17,9 +17,8 @@ Required properties: Miscellaneous Interrupt> Optional properties: -- phy-handle: Contains a phandle to an Ethernet PHY. +- phy-handle: See ethernet.txt file in the same directory. If absent, davinci_emac driver defaults to 100/FULL. -- local-mac-address : 6 bytes, mac address - ti,davinci-rmii-en: 1 byte, 1 means use RMII - ti,davinci-no-bd-ram: boolean, does EMAC have BD RAM? diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt new file mode 100644 index 0000000..3fc3605 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ethernet.txt @@ -0,0 +1,25 @@ +The following properties are common to the Ethernet controllers: + +- local-mac-address: array of 6 bytes, specifies the MAC address that was + assigned to the network device; +- mac-address: array of 6 bytes, specifies the MAC address that was last used by + the boot program; should be used in cases where the MAC address assigned to + the device by the boot program is different from the "local-mac-address" + property; +- max-speed: number, specifies maximum speed in Mbit/s supported by the device; +- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than + the maximum frame size (there's contradiction in ePAPR). +- phy-mode: string, operation mode of the PHY interface; supported values are + "mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id", + "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a de-facto + standard property; +- phy-connection-type: the same as "phy-mode" property but described in ePAPR; +- phy-handle: phandle, specifies a reference to a node representing a PHY + device; this property is described in ePAPR and so preferred; +- phy: the same as "phy-handle" property, not recommended for new bindings. +- phy-device: the same as "phy-handle" property, not recommended for new + bindings. + +Child nodes of the Ethernet controller are typically the individual PHY devices +connected via the MDIO bus (sometimes the MDIO bus controller is separate). +They are described in the phy.txt file in this same directory. diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt new file mode 100644 index 0000000..82bf7e0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/fixed-link.txt @@ -0,0 +1,42 @@ +Fixed link Device Tree binding +------------------------------ + +Some Ethernet MACs have a "fixed link", and are not connected to a +normal MDIO-managed PHY device. For those situations, a Device Tree +binding allows to describe a "fixed link". + +Such a fixed link situation is described by creating a 'fixed-link' +sub-node of the Ethernet MAC device node, with the following +properties: + +* 'speed' (integer, mandatory), to indicate the link speed. Accepted + values are 10, 100 and 1000 +* 'full-duplex' (boolean, optional), to indicate that full duplex is + used. When absent, half duplex is assumed. +* 'pause' (boolean, optional), to indicate that pause should be + enabled. +* 'asym-pause' (boolean, optional), to indicate that asym_pause should + be enabled. + +Old, deprecated 'fixed-link' binding: + +* A 'fixed-link' property in the Ethernet MAC node, with 5 cells, of the + form <a b c d e> with the following accepted values: + - a: emulated PHY ID, choose any but but unique to the all specified + fixed-links, from 0 to 31 + - b: duplex configuration: 0 for half duplex, 1 for full duplex + - c: link speed in Mbits/sec, accepted values are: 10, 100 and 1000 + - d: pause configuration: 0 for no pause, 1 for pause + - e: asymmetric pause configuration: 0 for no asymmetric pause, 1 for + asymmetric pause + +Example: + +ethernet@0 { + ... + fixed-link { + speed = <1000>; + full-duplex; + }; + ... +}; diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt index 845ff84..6bc84ad 100644 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt @@ -4,12 +4,9 @@ Required properties: - compatible : Should be "fsl,<soc>-fec" - reg : Address and length of the register set for the device - interrupts : Should contain fec interrupt -- phy-mode : String, operation mode of the PHY interface. - Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii", - "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii". +- phy-mode : See ethernet.txt file in the same directory Optional properties: -- local-mac-address : 6 bytes, mac address - phy-reset-gpios : Should specify the gpio for phy reset - phy-reset-duration : Reset duration in milliseconds. Should present only if property "phy-reset-gpios" is available. Missing the property diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt index d2ea460..be6ea89 100644 --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt @@ -38,22 +38,14 @@ Properties: - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC" - compatible : Should be "gianfar" - reg : Offset and length of the register set for the device - - local-mac-address : List of bytes representing the ethernet address of - this controller - interrupts : For FEC devices, the first interrupt is the device's interrupt. For TSEC and eTSEC devices, the first interrupt is transmit, the second is receive, and the third is error. - - phy-handle : The phandle for the PHY connected to this ethernet - controller. - - fixed-link : <a b c d e> where a is emulated phy id - choose any, - but unique to the all specified fixed-links, b is duplex - 0 half, - 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no - pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause. - - phy-connection-type : a string naming the controller/PHY interface type, - i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii", - "tbi", or "rtbi". This property is only really needed if the connection - is of type "rgmii-id", as all other connection types are detected by - hardware. + - phy-handle : See ethernet.txt file in the same directory. + - fixed-link : See fixed-link.txt in the same directory. + - phy-connection-type : See ethernet.txt file in the same directory. + This property is only really needed if the connection is of type + "rgmii-id", as all other connection types are detected by hardware. - fsl,magic-packet : If present, indicates that the hardware supports waking up via magic packet. - bd-stash : If present, indicates that the hardware supports stashing diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt new file mode 100644 index 0000000..75d398b --- /dev/null +++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt @@ -0,0 +1,36 @@ +Hisilicon hix5hd2 gmac controller + +Required properties: +- compatible: should be "hisilicon,hix5hd2-gmac". +- reg: specifies base physical address(s) and size of the device registers. + The first region is the MAC register base and size. + The second region is external interface control register. +- interrupts: should contain the MAC interrupt. +- #address-cells: must be <1>. +- #size-cells: must be <0>. +- phy-mode: see ethernet.txt [1]. +- phy-handle: see ethernet.txt [1]. +- mac-address: see ethernet.txt [1]. +- clocks: clock phandle and specifier pair. + +- PHY subnode: inherits from phy binding [2] + +[1] Documentation/devicetree/bindings/net/ethernet.txt +[2] Documentation/devicetree/bindings/net/phy.txt + +Example: + gmac0: ethernet@f9840000 { + compatible = "hisilicon,hix5hd2-gmac"; + reg = <0xf9840000 0x1000>,<0xf984300c 0x4>; + interrupts = <0 71 4>; + #address-cells = <1>; + #size-cells = <0>; + phy-mode = "mii"; + phy-handle = <&phy2>; + mac-address = [00 00 00 00 00 00]; + clocks = <&clock HIX5HD2_MAC0_CLK>; + + phy2: ethernet-phy@2 { + reg = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt b/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt new file mode 100644 index 0000000..d3bbdded --- /dev/null +++ b/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt @@ -0,0 +1,23 @@ +* AT86RF230 IEEE 802.15.4 * + +Required properties: + - compatible: should be "atmel,at86rf230", "atmel,at86rf231", + "atmel,at86rf233" or "atmel,at86rf212" + - spi-max-frequency: maximal bus speed, should be set to 7500000 depends + sync or async operation mode + - reg: the chipselect index + - interrupts: the interrupt generated by the device + +Optional properties: + - reset-gpio: GPIO spec for the rstn pin + - sleep-gpio: GPIO spec for the slp_tr pin + +Example: + + at86rf231@0 { + compatible = "atmel,at86rf231"; + spi-max-frequency = <7500000>; + reg = <0>; + interrupts = <19 1>; + interrupt-parent = <&gpio3>; + }; diff --git a/Documentation/devicetree/bindings/net/ieee802154/cc2520.txt b/Documentation/devicetree/bindings/net/ieee802154/cc2520.txt new file mode 100644 index 0000000..0071883 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ieee802154/cc2520.txt @@ -0,0 +1,29 @@ +*CC2520 IEEE 802.15.4 Compatible Radio* + +Required properties: + - compatible: should be "ti,cc2520" + - spi-max-frequency: maximal bus speed (8000000), should be set to 4000000 depends + sync or async operation mode + - reg: the chipselect index + - pinctrl-0: pin control group to be used for this controller. + - pinctrl-names: must contain a "default" entry. + - fifo-gpio: GPIO spec for the FIFO pin + - fifop-gpio: GPIO spec for the FIFOP pin + - sfd-gpio: GPIO spec for the SFD pin + - cca-gpio: GPIO spec for the CCA pin + - vreg-gpio: GPIO spec for the VREG pin + - reset-gpio: GPIO spec for the RESET pin +Example: + cc2520@0 { + compatible = "ti,cc2520"; + reg = <0>; + spi-max-frequency = <4000000>; + pinctrl-names = "default"; + pinctrl-0 = <&cc2520_cape_pins>; + fifo-gpio = <&gpio1 18 0>; + fifop-gpio = <&gpio1 19 0>; + sfd-gpio = <&gpio1 13 0>; + cca-gpio = <&gpio1 16 0>; + vreg-gpio = <&gpio0 31 0>; + reset-gpio = <&gpio1 12 0>; + }; diff --git a/Documentation/devicetree/bindings/net/lpc-eth.txt b/Documentation/devicetree/bindings/net/lpc-eth.txt index 585021a..b92e927 100644 --- a/Documentation/devicetree/bindings/net/lpc-eth.txt +++ b/Documentation/devicetree/bindings/net/lpc-eth.txt @@ -6,10 +6,9 @@ Required properties: - interrupts: Should contain ethernet controller interrupt Optional properties: -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii" (default) +- phy-mode: See ethernet.txt file in the same directory. If the property is + absent, "rmii" is assumed. - use-iram: Use LPC32xx internal SRAM (IRAM) for DMA buffering -- local-mac-address : 6 bytes, mac address Example: diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index 70af2ec..aaa6964 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -8,16 +8,12 @@ Required properties: the Cadence GEM, or the generic form: "cdns,gem". - reg: Address and length of the register set for the device - interrupts: Should contain macb interrupt -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii", "gmii", "rgmii". +- phy-mode: See ethernet.txt file in the same directory. - clock-names: Tuple listing input clock names. Required elements: 'pclk', 'hclk' Optional elements: 'tx_clk' - clocks: Phandles to input clocks. -Optional properties: -- local-mac-address: 6 bytes, mac address - Examples: macb0: ethernet@fffc4000 { diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt index 859a6fa..750d577 100644 --- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt @@ -4,10 +4,8 @@ Required properties: - compatible: should be "marvell,armada-370-neta". - reg: address and length of the register set for the device. - interrupts: interrupt for the device -- phy: A phandle to a phy node defining the PHY address (as the reg - property, a single integer). -- phy-mode: The interface between the SoC and the PHY (a string that - of_get_phy_mode() can understand) +- phy: See ethernet.txt file in the same directory. +- phy-mode: See ethernet.txt file in the same directory - clocks: a pointer to the reference clock for this device. Example: diff --git a/Documentation/devicetree/bindings/net/marvell-orion-net.txt b/Documentation/devicetree/bindings/net/marvell-orion-net.txt index c233b61..bce52b2 100644 --- a/Documentation/devicetree/bindings/net/marvell-orion-net.txt +++ b/Documentation/devicetree/bindings/net/marvell-orion-net.txt @@ -36,7 +36,7 @@ Required port properties: "marvell,kirkwood-eth-port". - reg: port number relative to ethernet controller, shall be 0, 1, or 2. - interrupts: port interrupt. - - local-mac-address: 6 bytes MAC address. + - local-mac-address: See ethernet.txt file in the same directory. Optional port properties: - marvell,tx-queue-size: size of the transmit ring buffer. @@ -48,7 +48,7 @@ Optional port properties: and - - phy-handle: phandle reference to ethernet PHY. + - phy-handle: See ethernet.txt file in the same directory. or diff --git a/Documentation/devicetree/bindings/net/marvell-pp2.txt b/Documentation/devicetree/bindings/net/marvell-pp2.txt new file mode 100644 index 0000000..aa4f423 --- /dev/null +++ b/Documentation/devicetree/bindings/net/marvell-pp2.txt @@ -0,0 +1,61 @@ +* Marvell Armada 375 Ethernet Controller (PPv2) + +Required properties: + +- compatible: should be "marvell,armada-375-pp2" +- reg: addresses and length of the register sets for the device. + Must contain the following register sets: + - common controller registers + - LMS registers + In addition, at least one port register set is required. +- clocks: a pointer to the reference clocks for this device, consequently: + - main controller clock + - GOP clock +- clock-names: names of used clocks, must be "pp_clk" and "gop_clk". + +The ethernet ports are represented by subnodes. At least one port is +required. + +Required properties (port): + +- interrupts: interrupt for the port +- port-id: should be '0' or '1' for ethernet ports, and '2' for the + loopback port +- phy-mode: See ethernet.txt file in the same directory + +Optional properties (port): + +- marvell,loopback: port is loopback mode +- phy: a phandle to a phy node defining the PHY address (as the reg + property, a single integer). Note: if this property isn't present, + then fixed link is assumed, and the 'fixed-link' property is + mandatory. + +Example: + +ethernet@f0000 { + compatible = "marvell,armada-375-pp2"; + reg = <0xf0000 0xa000>, + <0xc0000 0x3060>, + <0xc4000 0x100>, + <0xc5000 0x100>; + clocks = <&gateclk 3>, <&gateclk 19>; + clock-names = "pp_clk", "gop_clk"; + status = "okay"; + + eth0: eth0@c4000 { + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; + port-id = <0>; + status = "okay"; + phy = <&phy0>; + phy-mode = "gmii"; + }; + + eth1: eth1@c5000 { + interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>; + port-id = <1>; + status = "okay"; + phy = <&phy3>; + phy-mode = "gmii"; + }; +}; diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.txt b/Documentation/devicetree/bindings/net/mdio-gpio.txt index c79bab0..8dbcf82 100644 --- a/Documentation/devicetree/bindings/net/mdio-gpio.txt +++ b/Documentation/devicetree/bindings/net/mdio-gpio.txt @@ -14,7 +14,7 @@ node. Example: aliases { - mdio-gpio0 = <&mdio0>; + mdio-gpio0 = &mdio0; }; mdio0: mdio { diff --git a/Documentation/devicetree/bindings/net/micrel-ks8851.txt b/Documentation/devicetree/bindings/net/micrel-ks8851.txt index 4fc3927..bbdf9a7 100644 --- a/Documentation/devicetree/bindings/net/micrel-ks8851.txt +++ b/Documentation/devicetree/bindings/net/micrel-ks8851.txt @@ -1,10 +1,18 @@ -Micrel KS8851 Ethernet mac +Micrel KS8851 Ethernet mac (MLL) Required properties: -- compatible = "micrel,ks8851-ml" of parallel interface +- compatible = "micrel,ks8851-mll" of parallel interface - reg : 2 physical address and size of registers for data and command - interrupts : interrupt connection +Micrel KS8851 Ethernet mac (SPI) + +Required properties: +- compatible = "micrel,ks8851" or the deprecated "ks8851" +- reg : chip select number +- interrupts : interrupt connection + Optional properties: -- local-mac-address : Ethernet mac address to use -- vdd-supply: supply for Ethernet mac +- vdd-supply: analog 3.3V supply for Ethernet mac +- vdd-io-supply: digital 1.8V IO supply for Ethernet mac +- reset-gpios: reset_n input pin diff --git a/Documentation/devicetree/bindings/net/micrel-ksz9021.txt b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt deleted file mode 100644 index 997a63f..0000000 --- a/Documentation/devicetree/bindings/net/micrel-ksz9021.txt +++ /dev/null @@ -1,49 +0,0 @@ -Micrel KSZ9021 Gigabit Ethernet PHY - -Some boards require special tuning values, particularly when it comes to -clock delays. You can specify clock delay values by adding -micrel-specific properties to an Ethernet OF device node. - -All skew control options are specified in picoseconds. The minimum -value is 0, and the maximum value is 3000. - -Optional properties: - - rxc-skew-ps : Skew control of RXC pad - - rxdv-skew-ps : Skew control of RX CTL pad - - txc-skew-ps : Skew control of TXC pad - - txen-skew-ps : Skew control of TX_CTL pad - - rxd0-skew-ps : Skew control of RX data 0 pad - - rxd1-skew-ps : Skew control of RX data 1 pad - - rxd2-skew-ps : Skew control of RX data 2 pad - - rxd3-skew-ps : Skew control of RX data 3 pad - - txd0-skew-ps : Skew control of TX data 0 pad - - txd1-skew-ps : Skew control of TX data 1 pad - - txd2-skew-ps : Skew control of TX data 2 pad - - txd3-skew-ps : Skew control of TX data 3 pad - -Examples: - - /* Attach to an Ethernet device with autodetected PHY */ - &enet { - rxc-skew-ps = <3000>; - rxdv-skew-ps = <0>; - txc-skew-ps = <3000>; - txen-skew-ps = <0>; - status = "okay"; - }; - - /* Attach to an explicitly-specified PHY */ - mdio { - phy0: ethernet-phy@0 { - rxc-skew-ps = <3000>; - rxdv-skew-ps = <0>; - txc-skew-ps = <3000>; - txen-skew-ps = <0>; - reg = <0>; - }; - }; - ethernet@70000 { - status = "okay"; - phy = <&phy0>; - phy-mode = "rgmii-id"; - }; diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt new file mode 100644 index 0000000..692076f --- /dev/null +++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt @@ -0,0 +1,83 @@ +Micrel KSZ9021/KSZ9031 Gigabit Ethernet PHY + +Some boards require special tuning values, particularly when it comes to +clock delays. You can specify clock delay values by adding +micrel-specific properties to an Ethernet OF device node. + +Note that these settings are applied after any phy-specific fixup from +phy_fixup_list (see phy_init_hw() from drivers/net/phy/phy_device.c), +and therefore may overwrite them. + +KSZ9021: + + All skew control options are specified in picoseconds. The minimum + value is 0, the maximum value is 3000, and it is incremented by 200ps + steps. + + Optional properties: + + - rxc-skew-ps : Skew control of RXC pad + - rxdv-skew-ps : Skew control of RX CTL pad + - txc-skew-ps : Skew control of TXC pad + - txen-skew-ps : Skew control of TX CTL pad + - rxd0-skew-ps : Skew control of RX data 0 pad + - rxd1-skew-ps : Skew control of RX data 1 pad + - rxd2-skew-ps : Skew control of RX data 2 pad + - rxd3-skew-ps : Skew control of RX data 3 pad + - txd0-skew-ps : Skew control of TX data 0 pad + - txd1-skew-ps : Skew control of TX data 1 pad + - txd2-skew-ps : Skew control of TX data 2 pad + - txd3-skew-ps : Skew control of TX data 3 pad + +KSZ9031: + + All skew control options are specified in picoseconds. The minimum + value is 0, and the maximum is property-dependent. The increment + step is 60ps. + + Optional properties: + + Maximum value of 1860: + + - rxc-skew-ps : Skew control of RX clock pad + - txc-skew-ps : Skew control of TX clock pad + + Maximum value of 900: + + - rxdv-skew-ps : Skew control of RX CTL pad + - txen-skew-ps : Skew control of TX CTL pad + - rxd0-skew-ps : Skew control of RX data 0 pad + - rxd1-skew-ps : Skew control of RX data 1 pad + - rxd2-skew-ps : Skew control of RX data 2 pad + - rxd3-skew-ps : Skew control of RX data 3 pad + - txd0-skew-ps : Skew control of TX data 0 pad + - txd1-skew-ps : Skew control of TX data 1 pad + - txd2-skew-ps : Skew control of TX data 2 pad + - txd3-skew-ps : Skew control of TX data 3 pad + +Examples: + + /* Attach to an Ethernet device with autodetected PHY */ + &enet { + rxc-skew-ps = <3000>; + rxdv-skew-ps = <0>; + txc-skew-ps = <3000>; + txen-skew-ps = <0>; + status = "okay"; + }; + + /* Attach to an explicitly-specified PHY */ + mdio { + phy0: ethernet-phy@0 { + rxc-skew-ps = <3000>; + rxdv-skew-ps = <0>; + txc-skew-ps = <3000>; + txen-skew-ps = <0>; + reg = <0>; + }; + }; + ethernet@70000 { + status = "okay"; + phy = <&phy0>; + phy-mode = "rgmii-id"; + }; diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt new file mode 100644 index 0000000..98a3e61 --- /dev/null +++ b/Documentation/devicetree/bindings/net/micrel.txt @@ -0,0 +1,18 @@ +Micrel PHY properties. + +These properties cover the base properties Micrel PHYs. + +Optional properties: + + - micrel,led-mode : LED mode value to set for PHYs with configurable LEDs. + + Configure the LED mode with single value. The list of PHYs and + the bits that are currently supported: + + KSZ8001: register 0x1e, bits 15..14 + KSZ8041: register 0x1e, bits 15..14 + KSZ8021: register 0x1f, bits 5..4 + KSZ8031: register 0x1f, bits 5..4 + KSZ8051: register 0x1f, bits 5..4 + + See the respective PHY datasheet for the mode values. diff --git a/Documentation/devicetree/bindings/net/nfc/pn544.txt b/Documentation/devicetree/bindings/net/nfc/pn544.txt new file mode 100644 index 0000000..dab69f3 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/pn544.txt @@ -0,0 +1,35 @@ +* NXP Semiconductors PN544 NFC Controller + +Required properties: +- compatible: Should be "nxp,pn544-i2c". +- clock-frequency: IC work frequency. +- reg: address on the bus +- interrupt-parent: phandle for the interrupt gpio controller +- interrupts: GPIO interrupt to which the chip is connected +- enable-gpios: Output GPIO pin used for enabling/disabling the PN544 +- firmware-gpios: Output GPIO pin used to enter firmware download mode + +Optional SoC Specific Properties: +- pinctrl-names: Contains only one value - "default". +- pintctrl-0: Specifies the pin control groups used for this controller. + +Example (for ARM-based BeagleBone with PN544 on I2C2): + +&i2c2 { + + status = "okay"; + + pn544: pn544@28 { + + compatible = "nxp,pn544-i2c"; + + reg = <0x28>; + clock-frequency = <400000>; + + interrupt-parent = <&gpio1>; + interrupts = <17 GPIO_ACTIVE_HIGH>; + + enable-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>; + firmware-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>; + }; +}; diff --git a/Documentation/devicetree/bindings/net/nfc/st21nfca.txt b/Documentation/devicetree/bindings/net/nfc/st21nfca.txt new file mode 100644 index 0000000..e4faa2e --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/st21nfca.txt @@ -0,0 +1,33 @@ +* STMicroelectronics SAS. ST21NFCA NFC Controller + +Required properties: +- compatible: Should be "st,st21nfca_i2c". +- clock-frequency: I²C work frequency. +- reg: address on the bus +- interrupt-parent: phandle for the interrupt gpio controller +- interrupts: GPIO interrupt to which the chip is connected +- enable-gpios: Output GPIO pin used for enabling/disabling the ST21NFCA + +Optional SoC Specific Properties: +- pinctrl-names: Contains only one value - "default". +- pintctrl-0: Specifies the pin control groups used for this controller. + +Example (for ARM-based BeagleBoard xM with ST21NFCA on I2C2): + +&i2c2 { + + status = "okay"; + + st21nfca: st21nfca@1 { + + compatible = "st,st21nfca_i2c"; + + reg = <0x01>; + clock-frequency = <400000>; + + interrupt-parent = <&gpio5>; + interrupts = <2 IRQ_TYPE_LEVEL_LOW>; + + enable-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>; + }; +}; diff --git a/Documentation/devicetree/bindings/net/nfc/st21nfcb.txt b/Documentation/devicetree/bindings/net/nfc/st21nfcb.txt new file mode 100644 index 0000000..3b58ae4 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/st21nfcb.txt @@ -0,0 +1,33 @@ +* STMicroelectronics SAS. ST21NFCB NFC Controller + +Required properties: +- compatible: Should be "st,st21nfcb_i2c". +- clock-frequency: I²C work frequency. +- reg: address on the bus +- interrupt-parent: phandle for the interrupt gpio controller +- interrupts: GPIO interrupt to which the chip is connected +- reset-gpios: Output GPIO pin used to reset the ST21NFCB + +Optional SoC Specific Properties: +- pinctrl-names: Contains only one value - "default". +- pintctrl-0: Specifies the pin control groups used for this controller. + +Example (for ARM-based BeagleBoard xM with ST21NFCB on I2C2): + +&i2c2 { + + status = "okay"; + + st21nfcb: st21nfcb@8 { + + compatible = "st,st21nfcb_i2c"; + + reg = <0x08>; + clock-frequency = <400000>; + + interrupt-parent = <&gpio5>; + interrupts = <2 IRQ_TYPE_LEVEL_LOW>; + + reset-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>; + }; +}; diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt new file mode 100644 index 0000000..1e43613 --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt @@ -0,0 +1,36 @@ +* Texas Instruments TRF7970A RFID/NFC/15693 Transceiver + +Required properties: +- compatible: Should be "ti,trf7970a". +- spi-max-frequency: Maximum SPI frequency (<= 2000000). +- interrupt-parent: phandle of parent interrupt handler. +- interrupts: A single interrupt specifier. +- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the + TRF7970A. +- vin-supply: Regulator for supply voltage to VIN pin + +Optional SoC Specific Properties: +- pinctrl-names: Contains only one value - "default". +- pintctrl-0: Specifies the pin control groups used for this controller. +- autosuspend-delay: Specify autosuspend delay in milliseconds. + +Example (for ARM-based BeagleBone with TRF7970A on SPI1): + +&spi1 { + status = "okay"; + + nfc@0 { + compatible = "ti,trf7970a"; + reg = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&trf7970a_default>; + spi-max-frequency = <2000000>; + interrupt-parent = <&gpio2>; + interrupts = <14 0>; + ti,enable-gpios = <&gpio2 2 GPIO_ACTIVE_LOW>, + <&gpio2 5 GPIO_ACTIVE_LOW>; + vin-supply = <&ldo3_reg>; + autosuspend-delay = <30000>; + status = "okay"; + }; +}; diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt index 58307d0..5b8c589 100644 --- a/Documentation/devicetree/bindings/net/phy.txt +++ b/Documentation/devicetree/bindings/net/phy.txt @@ -21,10 +21,18 @@ Optional Properties: elements. - max-speed: Maximum PHY supported speed (10, 100, 1000...) + If the phy's identifier is known then the list may contain an entry + of the form: "ethernet-phy-idAAAA.BBBB" where + AAAA - The value of the 16 bit Phy Identifier 1 register as + 4 hex digits. This is the chip vendor OUI bits 3:18 + BBBB - The value of the 16 bit Phy Identifier 2 register as + 4 hex digits. This is the chip vendor OUI bits 19:24, + followed by 10 bits of a vendor specific ID. + Example: ethernet-phy@0 { - compatible = "ethernet-phy-ieee802.3-c22"; + compatible = "ethernet-phy-id0141.0e90", "ethernet-phy-ieee802.3-c22"; interrupt-parent = <40000>; interrupts = <35 1>; reg = <0>; diff --git a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt new file mode 100644 index 0000000..989f6c9 --- /dev/null +++ b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt @@ -0,0 +1,52 @@ +* Samsung 10G Ethernet driver (SXGBE) + +Required properties: +- compatible: Should be "samsung,sxgbe-v2.0a" +- 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 SXGBE interrupts + These interrupts are ordered by fixed and follows variable + trasmit DMA interrupts, receive DMA interrupts and lpi interrupt. + index 0 - this is fixed common interrupt of SXGBE and it is always + available. + index 1 to 25 - 8 variable trasmit interrupts, variable 16 receive interrupts + and 1 optional lpi interrupt. +- phy-mode: String, operation mode of the PHY interface. + Supported values are: "sgmii", "xgmii". +- samsung,pbl: Integer, Programmable Burst Length. + Supported values are 1, 2, 4, 8, 16, or 32. +- samsung,burst-map: Integer, Program the possible bursts supported by sxgbe + This is an interger and represents allowable DMA bursts when fixed burst. + Allowable range is 0x01-0x3F. When this field is set fixed burst is enabled. + When fixed length is needed for burst mode, it can be set within allowable + range. + +Optional properties: +- mac-address: 6 bytes, mac address +- max-frame-size: Maximum Transfer Unit (IEEE defined MTU), rather + than the maximum frame size. + +Example: + + aliases { + ethernet0 = <&sxgbe0>; + }; + + sxgbe0: ethernet@1a040000 { + compatible = "samsung,sxgbe-v2.0a"; + reg = <0 0x1a040000 0 0x10000>; + interrupt-parent = <&gic>; + interrupts = <0 209 4>, <0 185 4>, <0 186 4>, <0 187 4>, + <0 188 4>, <0 189 4>, <0 190 4>, <0 191 4>, + <0 192 4>, <0 193 4>, <0 194 4>, <0 195 4>, + <0 196 4>, <0 197 4>, <0 198 4>, <0 199 4>, + <0 200 4>, <0 201 4>, <0 202 4>, <0 203 4>, + <0 204 4>, <0 205 4>, <0 206 4>, <0 207 4>, + <0 208 4>, <0 210 4>; + samsung,pbl = <0x08> + samsung,burst-map = <0x20> + mac-address = [ 00 11 22 33 44 55 ]; /* Filled in by U-Boot */ + max-frame-size = <9000>; + phy-mode = "xgmii"; + }; diff --git a/Documentation/devicetree/bindings/net/sh_eth.txt b/Documentation/devicetree/bindings/net/sh_eth.txt new file mode 100644 index 0000000..34d4db1 --- /dev/null +++ b/Documentation/devicetree/bindings/net/sh_eth.txt @@ -0,0 +1,56 @@ +* Renesas Electronics SH EtherMAC + +This file provides information on what the device node for the SH EtherMAC +interface contains. + +Required properties: +- compatible: "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC. + "renesas,ether-r8a7778" if the device is a part of R8A7778 SoC. + "renesas,ether-r8a7779" if the device is a part of R8A7779 SoC. + "renesas,ether-r8a7790" if the device is a part of R8A7790 SoC. + "renesas,ether-r8a7791" if the device is a part of R8A7791 SoC. + "renesas,ether-r8a7794" if the device is a part of R8A7794 SoC. + "renesas,ether-r7s72100" if the device is a part of R7S72100 SoC. +- reg: offset and length of (1) the E-DMAC/feLic register block (required), + (2) the TSU register block (optional). +- interrupts: interrupt specifier for the sole interrupt. +- phy-mode: see ethernet.txt file in the same directory. +- phy-handle: see ethernet.txt file in the same directory. +- #address-cells: number of address cells for the MDIO bus, must be equal to 1. +- #size-cells: number of size cells on the MDIO bus, must be equal to 0. +- clocks: clock phandle and specifier pair. +- pinctrl-0: phandle, referring to a default pin configuration node. + +Optional properties: +- interrupt-parent: the phandle for the interrupt controller that services + interrupts for this device. +- pinctrl-names: pin configuration state name ("default"). +- renesas,no-ether-link: boolean, specify when a board does not provide a proper + Ether LINK signal. +- renesas,ether-link-active-low: boolean, specify when the Ether LINK signal is + active-low instead of normal active-high. + +Example (Lager board): + + ethernet@ee700000 { + compatible = "renesas,ether-r8a7790"; + reg = <0 0xee700000 0 0x400>; + interrupt-parent = <&gic>; + interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp8_clks R8A7790_CLK_ETHER>; + phy-mode = "rmii"; + phy-handle = <&phy1>; + pinctrl-0 = <ðer_pins>; + pinctrl-names = "default"; + renesas,ether-link-active-low; + #address-cells = <1>; + #size-cells = <0>; + + phy1: ethernet-phy@1 { + reg = <1>; + interrupt-parent = <&irqc0>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&phy1_pins>; + pinctrl-names = "default"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt index 5a41a865..0f8487b8 100644 --- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt +++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt @@ -6,8 +6,7 @@ Required properties: - interrupts : interrupt connection Optional properties: -- phy-device : phandle to Ethernet phy -- local-mac-address : Ethernet mac address to use +- phy-device : see ethernet.txt file in the same directory - reg-io-width : Mask of sizes (in bytes) of the IO accesses that are supported on the device. Valid value for SMSC LAN91c111 are 1, 2 or 4. If it's omitted or invalid, the size would be 2 meaning diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt b/Documentation/devicetree/bindings/net/smsc911x.txt index adb5b57..3fed3c1 100644 --- a/Documentation/devicetree/bindings/net/smsc911x.txt +++ b/Documentation/devicetree/bindings/net/smsc911x.txt @@ -6,9 +6,7 @@ Required properties: - interrupts : Should contain SMSC LAN interrupt line - interrupt-parent : Should be the phandle for the interrupt controller that services interrupts for this device -- phy-mode : String, operation mode of the PHY interface. - Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii", - "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii". +- phy-mode : See ethernet.txt file in the same directory Optional properties: - reg-shift : Specify the quantity to shift the register offsets by @@ -23,7 +21,6 @@ Optional properties: external PHY - smsc,save-mac-address : Indicates that mac address needs to be saved before resetting the controller -- local-mac-address : 6 bytes, mac address Examples: diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt new file mode 100644 index 0000000..2a60cd3 --- /dev/null +++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt @@ -0,0 +1,27 @@ +Altera SOCFPGA SoC DWMAC controller + +This is a variant of the dwmac/stmmac driver an inherits all descriptions +present in Documentation/devicetree/bindings/net/stmmac.txt. + +The device node has additional properties: + +Required properties: + - compatible : Should contain "altr,socfpga-stmmac" along with + "snps,dwmac" and any applicable more detailed + designware version numbers documented in stmmac.txt + - altr,sysmgr-syscon : Should be the phandle to the system manager node that + encompasses the glue register, the register offset, and the register shift. + +Example: + +gmac0: ethernet@ff700000 { + compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac"; + altr,sysmgr-syscon = <&sysmgr 0x60 0>; + status = "disabled"; + reg = <0xff700000 0x2000>; + interrupts = <0 115 4>; + interrupt-names = "macirq"; + mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */ + clocks = <&emac_0_clk>; + clock-names = "stmmaceth"; +}; diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index 9d92d42..9b03c57 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -10,8 +10,7 @@ Required properties: - interrupt-names: Should contain the interrupt names "macirq" "eth_wake_irq" if this interrupt is supported in the "interrupts" property -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii", "gmii", "rgmii". +- phy-mode: See ethernet.txt file in the same directory. - snps,reset-gpio gpio number for phy reset. - snps,reset-active-low boolean flag to indicate if phy reset is active low. - snps,reset-delays-us is triplet of delays @@ -26,14 +25,20 @@ Required properties: - snps,force_sf_dma_mode Force DMA to use the Store and Forward mode for both tx and rx. This flag is ignored if force_thresh_dma_mode is set. +- snps,multicast-filter-bins: Number of multicast filter hash bins + supported by this device instance +- snps,perfect-filter-entries: Number of perfect filter entries supported + by this device instance Optional properties: -- mac-address: 6 bytes, mac address - resets: Should contain a phandle to the STMMAC reset signal, if any - reset-names: Should contain the reset signal name "stmmaceth", if a reset phandle is given -- max-frame-size: Maximum Transfer Unit (IEEE defined MTU), rather - than the maximum frame size. +- max-frame-size: See ethernet.txt file in the same directory +- clocks: If present, the first clock should be the GMAC main clock, + further clocks may be specified in derived bindings. +- clock-names: One name for each entry in the clocks property, the + first one should be "stmmaceth". Examples: @@ -46,4 +51,8 @@ Examples: mac-address = [000000000000]; /* Filled in by U-Boot */ max-frame-size = <3800>; phy-mode = "gmii"; + snps,multicast-filter-bins = <256>; + snps,perfect-filter-entries = <128>; + clocks = <&clock>; + clock-names = "stmmaceth">; }; diff --git a/Documentation/devicetree/bindings/net/via-rhine.txt b/Documentation/devicetree/bindings/net/via-rhine.txt new file mode 100644 index 0000000..334eca2 --- /dev/null +++ b/Documentation/devicetree/bindings/net/via-rhine.txt @@ -0,0 +1,17 @@ +* VIA Rhine 10/100 Network Controller + +Required properties: +- compatible : Should be "via,vt8500-rhine" for integrated + Rhine controllers found in VIA VT8500, WonderMedia WM8950 + and similar. These are listed as 1106:3106 rev. 0x84 on the + virtual PCI bus under vendor-provided kernels +- reg : Address and length of the io space +- interrupts : Should contain the controller interrupt line + +Examples: + +ethernet@d8004000 { + compatible = "via,vt8500-rhine"; + reg = <0xd8004000 0x100>; + interrupts = <10>; +}; diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt new file mode 100644 index 0000000..5dbf169 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt @@ -0,0 +1,41 @@ +Broadcom BCM43xx Fullmac wireless SDIO devices + +This node provides properties for controlling the Broadcom wireless device. The +node is expected to be specified as a child node to the SDIO controller that +connects the device to the system. + +Required properties: + + - compatible : Should be "brcm,bcm4329-fmac". + +Optional properties: + - brcm,drive-strength : drive strength used for SDIO pins on device in mA + (default = 6). + - interrupt-parent : the phandle for the interrupt controller to which the + device interrupts are connected. + - interrupts : specifies attributes for the out-of-band interrupt (host-wake). + When not specified the device will use in-band SDIO interrupts. + - interrupt-names : name of the out-of-band interrupt, which must be set + to "host-wake". + +Example: + +mmc3: mmc@01c12000 { + #address-cells = <1>; + #size-cells = <0>; + + pinctrl-names = "default"; + pinctrl-0 = <&mmc3_pins_a>; + vmmc-supply = <®_vmmc3>; + bus-width = <4>; + non-removable; + status = "okay"; + + brcmf: bcrmf@1 { + reg = <1>; + compatible = "brcm,bcm4329-fmac"; + interrupt-parent = <&pio>; + interrupts = <10 8>; /* PH10 / EINT10 */ + interrupt-names = "host-wake"; + }; +}; diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt new file mode 100644 index 0000000..189ae5c --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt @@ -0,0 +1,39 @@ +* Texas Instruments wl1251 wireless lan controller + +The wl1251 chip can be connected via SPI or via SDIO. This +document describes the binding for the SPI connected chip. + +Required properties: +- compatible : Should be "ti,wl1251" +- reg : Chip select address of device +- spi-max-frequency : Maximum SPI clocking speed of device in Hz +- interrupts : Should contain interrupt line +- interrupt-parent : Should be the phandle for the interrupt controller + that services interrupts for this device +- vio-supply : phandle to regulator providing VIO +- ti,power-gpio : GPIO connected to chip's PMEN pin + +Optional properties: +- ti,wl1251-has-eeprom : boolean, the wl1251 has an eeprom connected, which + provides configuration data (calibration, MAC, ...) +- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt + for optional SPI connection related properties, + +Examples: + +&spi1 { + wl1251@0 { + compatible = "ti,wl1251"; + + reg = <0>; + spi-max-frequency = <48000000>; + spi-cpol; + spi-cpha; + + interrupt-parent = <&gpio2>; + interrupts = <10 IRQ_TYPE_NONE>; /* gpio line 42 */ + + vio-supply = <&vio>; + ti,power-gpio = <&gpio3 23 GPIO_ACTIVE_HIGH>; /* 87 */ + }; +}; diff --git a/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt b/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt new file mode 100644 index 0000000..7443b7c --- /dev/null +++ b/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt @@ -0,0 +1,7 @@ +AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel + +Required properties: +- compatible: should be "auo,b133xtn01" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt b/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt new file mode 100644 index 0000000..4903d7b --- /dev/null +++ b/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt @@ -0,0 +1,7 @@ +Emerging Display Technology Corp. 5.7" VGA TFT LCD panel + +Required properties: +- compatible: should be "edt,et057090dhu" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt b/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt new file mode 100644 index 0000000..20cb38e --- /dev/null +++ b/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt @@ -0,0 +1,10 @@ +Emerging Display Technology Corp. ET070080DH6 7.0" WVGA TFT LCD panel + +Required properties: +- compatible: should be "edt,et070080dh6" + +This panel is the same as ETM0700G0DH6 except for the touchscreen. +ET070080DH6 is the model with resistive touch. + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt b/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt new file mode 100644 index 0000000..ee4b180 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt @@ -0,0 +1,10 @@ +Emerging Display Technology Corp. ETM0700G0DH6 7.0" WVGA TFT LCD panel + +Required properties: +- compatible: should be "edt,etm0700g0dh6" + +This panel is the same as ET070080DH6 except for the touchscreen. +ETM0700G0DH6 is the model with capacitive multitouch. + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt b/Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt new file mode 100644 index 0000000..5e649cb --- /dev/null +++ b/Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt @@ -0,0 +1,7 @@ +LG Corporation 7" WXGA TFT LCD panel + +Required properties: +- compatible: should be "lg,ld070wx3-sl01" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt b/Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt new file mode 100644 index 0000000..a04fd2b --- /dev/null +++ b/Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt @@ -0,0 +1,7 @@ +LG Corporation 5" HD TFT LCD panel + +Required properties: +- compatible: should be "lg,lh500wx1-sd03" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/lg,lp129qe.txt b/Documentation/devicetree/bindings/panel/lg,lp129qe.txt new file mode 100644 index 0000000..9f262e0 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/lg,lp129qe.txt @@ -0,0 +1,7 @@ +LG 12.9" (2560x1700 pixels) TFT LCD panel + +Required properties: +- compatible: should be "lg,lp129qe" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/samsung,ld9040.txt b/Documentation/devicetree/bindings/panel/samsung,ld9040.txt new file mode 100644 index 0000000..07c36c3 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/samsung,ld9040.txt @@ -0,0 +1,66 @@ +Samsung LD9040 AMOLED LCD parallel RGB panel with SPI control bus + +Required properties: + - compatible: "samsung,ld9040" + - reg: address of the panel on SPI bus + - vdd3-supply: core voltage supply + - vci-supply: voltage supply for analog circuits + - reset-gpios: a GPIO spec for the reset pin + - display-timings: timings for the connected panel according to [1] + +The panel must obey rules for SPI slave device specified in document [2]. + +Optional properties: + - power-on-delay: delay after turning regulators on [ms] + - reset-delay: delay after reset sequence [ms] + - panel-width-mm: physical panel width [mm] + - panel-height-mm: physical panel height [mm] + +The device node can contain one 'port' child node with one child +'endpoint' node, according to the bindings defined in [3]. This +node should describe panel's video bus. + +[1]: Documentation/devicetree/bindings/video/display-timing.txt +[2]: Documentation/devicetree/bindings/spi/spi-bus.txt +[3]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + lcd@0 { + compatible = "samsung,ld9040"; + reg = <0>; + vdd3-supply = <&ldo7_reg>; + vci-supply = <&ldo17_reg>; + reset-gpios = <&gpy4 5 0>; + spi-max-frequency = <1200000>; + spi-cpol; + spi-cpha; + power-on-delay = <10>; + reset-delay = <10>; + panel-width-mm = <90>; + panel-height-mm = <154>; + + display-timings { + timing { + clock-frequency = <23492370>; + hactive = <480>; + vactive = <800>; + hback-porch = <16>; + hfront-porch = <16>; + vback-porch = <2>; + vfront-porch = <28>; + hsync-len = <2>; + vsync-len = <1>; + hsync-active = <0>; + vsync-active = <0>; + de-active = <0>; + pixelclk-active = <0>; + }; + }; + + port { + lcd_ep: endpoint { + remote-endpoint = <&fimd_dpi_ep>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt b/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt new file mode 100644 index 0000000..e7ee988 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt @@ -0,0 +1,56 @@ +Samsung S6E8AA0 AMOLED LCD 5.3 inch panel + +Required properties: + - compatible: "samsung,s6e8aa0" + - reg: the virtual channel number of a DSI peripheral + - vdd3-supply: core voltage supply + - vci-supply: voltage supply for analog circuits + - reset-gpios: a GPIO spec for the reset pin + - display-timings: timings for the connected panel as described by [1] + +Optional properties: + - power-on-delay: delay after turning regulators on [ms] + - reset-delay: delay after reset sequence [ms] + - init-delay: delay after initialization sequence [ms] + - panel-width-mm: physical panel width [mm] + - panel-height-mm: physical panel height [mm] + - flip-horizontal: boolean to flip image horizontally + - flip-vertical: boolean to flip image vertically + +The device node can contain one 'port' child node with one child +'endpoint' node, according to the bindings defined in [2]. This +node should describe panel's video bus. + +[1]: Documentation/devicetree/bindings/video/display-timing.txt +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + panel { + compatible = "samsung,s6e8aa0"; + reg = <0>; + vdd3-supply = <&vcclcd_reg>; + vci-supply = <&vlcd_reg>; + reset-gpios = <&gpy4 5 0>; + power-on-delay= <50>; + reset-delay = <100>; + init-delay = <100>; + panel-width-mm = <58>; + panel-height-mm = <103>; + flip-horizontal; + flip-vertical; + + display-timings { + timing0: timing-0 { + clock-frequency = <57153600>; + hactive = <720>; + vactive = <1280>; + hfront-porch = <5>; + hback-porch = <5>; + hsync-len = <5>; + vfront-porch = <13>; + vback-porch = <1>; + vsync-len = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index d6fae13f..d0d15ee 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -1,15 +1,7 @@ * Synopsys Designware PCIe interface Required properties: -- compatible: should contain "snps,dw-pcie" to identify the - core, plus an identifier for the specific instance, such - as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie". -- reg: base addresses and lengths of the pcie controller, - the phy controller, additional register for the phy controller. -- interrupts: interrupt values for level interrupt, - pulse interrupt, special interrupt. -- clocks: from common clock binding: handle to pci clock. -- clock-names: from common clock binding: should be "pcie" and "pcie_bus". +- compatible: should contain "snps,dw-pcie" to identify the core. - #address-cells: set to <3> - #size-cells: set to <2> - device_type: set to "pci" @@ -19,65 +11,11 @@ Required properties: to define the mapping of the PCIe interface to interrupt numbers. - num-lanes: number of lanes to use +- 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: + - "pcie" + - "pcie_bus" Optional properties: - reset-gpio: gpio pin number of power good signal - -Optional properties for fsl,imx6q-pcie -- power-on-gpio: gpio pin number of power-enable signal -- wake-up-gpio: gpio pin number of incoming wakeup signal -- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal - -Example: - -SoC specific DT Entry: - - pcie@290000 { - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie"; - reg = <0x290000 0x1000 - 0x270000 0x1000 - 0x271000 0x40>; - interrupts = <0 20 0>, <0 21 0>, <0 22 0>; - clocks = <&clock 28>, <&clock 27>; - clock-names = "pcie", "pcie_bus"; - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */ - 0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */ - 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */ - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0x0 0 &gic 53>; - num-lanes = <4>; - }; - - pcie@2a0000 { - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie"; - reg = <0x2a0000 0x1000 - 0x272000 0x1000 - 0x271040 0x40>; - interrupts = <0 23 0>, <0 24 0>, <0 25 0>; - clocks = <&clock 29>, <&clock 27>; - clock-names = "pcie", "pcie_bus"; - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */ - 0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */ - 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */ - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0x0 0 &gic 56>; - num-lanes = <4>; - }; - -Board specific DT Entry: - - pcie@290000 { - reset-gpio = <&pin_ctrl 5 0>; - }; - - pcie@2a0000 { - reset-gpio = <&pin_ctrl 22 0>; - }; diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt new file mode 100644 index 0000000..9455fd0 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt @@ -0,0 +1,38 @@ +* Freescale i.MX6 PCIe interface + +This PCIe host controller is based on the Synopsis Designware PCIe IP +and thus inherits all the common properties defined in designware-pcie.txt. + +Required properties: +- compatible: "fsl,imx6q-pcie" +- reg: base addresse and length of the pcie controller +- interrupts: A list of interrupt outputs of the controller. Must contain an + entry for each entry in the interrupt-names property. +- interrupt-names: Must include the following entries: + - "msi": The interrupt that is asserted when an MSI is received +- clock-names: Must include the following additional entries: + - "pcie_phy" + +Example: + + pcie@0x01000000 { + compatible = "fsl,imx6q-pcie", "snps,dw-pcie"; + reg = <0x01ffc000 0x4000>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000 + 0x81000000 0 0 0x01f80000 0 0x00010000 + 0x82000000 0 0x01000000 0x01000000 0 0x00f00000>; + num-lanes = <1>; + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0x7>; + interrupt-map = <0 0 0 1 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 2 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 3 &intc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 4 &intc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks 144>, <&clks 206>, <&clks 189>; + clock-names = "pcie", "pcie_bus", "pcie_phy"; + }; diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt b/Documentation/devicetree/bindings/pci/host-generic-pci.txt new file mode 100644 index 0000000..f0b0436 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt @@ -0,0 +1,100 @@ +* Generic PCI host controller + +Firmware-initialised PCI host controllers and PCI emulations, such as the +virtio-pci implementations found in kvmtool and other para-virtualised +systems, do not require driver support for complexities such as regulator +and clock management. In fact, the controller may not even require the +configuration of a control interface by the operating system, instead +presenting a set of fixed windows describing a subset of IO, Memory and +Configuration Spaces. + +Such a controller can be described purely in terms of the standardized device +tree bindings communicated in pci.txt: + + +Properties of the host controller node: + +- compatible : Must be "pci-host-cam-generic" or "pci-host-ecam-generic" + depending on the layout of configuration space (CAM vs + ECAM respectively). + +- device_type : Must be "pci". + +- ranges : As described in IEEE Std 1275-1994, but must provide + at least a definition of non-prefetchable memory. One + or both of prefetchable Memory and IO Space may also + be provided. + +- bus-range : Optional property (also described in IEEE Std 1275-1994) + to indicate the range of bus numbers for this controller. + If absent, defaults to <0 255> (i.e. all buses). + +- #address-cells : Must be 3. + +- #size-cells : Must be 2. + +- reg : The Configuration Space base address and size, as accessed + from the parent bus. + + +Properties of the /chosen node: + +- linux,pci-probe-only + : Optional property which takes a single-cell argument. + If '0', then Linux will assign devices in its usual manner, + otherwise it will not try to assign devices and instead use + them as they are configured already. + +Configuration Space is assumed to be memory-mapped (as opposed to being +accessed via an ioport) and laid out with a direct correspondence to the +geography of a PCI bus address by concatenating the various components to +form an offset. + +For CAM, this 24-bit offset is: + + cfg_offset(bus, device, function, register) = + bus << 16 | device << 11 | function << 8 | register + +Whilst ECAM extends this by 4 bits to accomodate 4k of function space: + + cfg_offset(bus, device, function, register) = + bus << 20 | device << 15 | function << 12 | register + +Interrupt mapping is exactly as described in `Open Firmware Recommended +Practice: Interrupt Mapping' and requires the following properties: + +- #interrupt-cells : Must be 1 + +- interrupt-map : <see aforementioned specification> + +- interrupt-map-mask : <see aforementioned specification> + + +Example: + +pci { + compatible = "pci-host-cam-generic" + device_type = "pci"; + #address-cells = <3>; + #size-cells = <2>; + bus-range = <0x0 0x1>; + + // CPU_PHYSICAL(2) SIZE(2) + reg = <0x0 0x40000000 0x0 0x1000000>; + + // BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2) + ranges = <0x01000000 0x0 0x01000000 0x0 0x01000000 0x0 0x00010000>, + <0x02000000 0x0 0x41000000 0x0 0x41000000 0x0 0x3f000000>; + + + #interrupt-cells = <0x1>; + + // PCI_DEVICE(3) INT#(1) CONTROLLER(PHANDLE) CONTROLLER_DATA(3) + interrupt-map = < 0x0 0x0 0x0 0x1 &gic 0x0 0x4 0x1 + 0x800 0x0 0x0 0x1 &gic 0x0 0x5 0x1 + 0x1000 0x0 0x0 0x1 &gic 0x0 0x6 0x1 + 0x1800 0x0 0x0 0x1 &gic 0x0 0x7 0x1>; + + // PCI_DEVICE(3) INT#(1) + interrupt-map-mask = <0xf800 0x0 0x0 0x7>; +} diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt index 24cee06..c300391 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt @@ -42,6 +42,10 @@ Required properties: - 0xc2000000: prefetchable memory region Please refer to the standard PCI bus binding document for a more detailed explanation. +- #interrupt-cells: Size representation for interrupts (must be 1) +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties + Please refer to the standard PCI bus binding document for a more detailed + explanation. - 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: @@ -86,6 +90,10 @@ SoC DTSI: 0 99 0x04>; /* MSI interrupt */ interrupt-names = "intr", "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &intc GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; + bus-range = <0x00 0xff>; #address-cells = <3>; #size-cells = <2>; diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt new file mode 100644 index 0000000..d8ef5bf --- /dev/null +++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt @@ -0,0 +1,66 @@ +Renesas AHB to PCI bridge +------------------------- + +This is the bridge used internally to connect the USB controllers to the +AHB. There is one bridge instance per USB port connected to the internal +OHCI and EHCI controllers. + +Required properties: +- compatible: "renesas,pci-r8a7790" for the R8A7790 SoC; + "renesas,pci-r8a7791" for the R8A7791 SoC. +- reg: A list of physical regions to access the device: the first is + the operational registers for the OHCI/EHCI controllers and the + second is for the bridge configuration and control registers. +- interrupts: interrupt for the device. +- clocks: The reference to the device clock. +- bus-range: The PCI bus number range; as this is a single bus, the range + should be specified as the same value twice. +- #address-cells: must be 3. +- #size-cells: must be 2. +- #interrupt-cells: must be 1. +- interrupt-map: standard property used to define the mapping of the PCI + interrupts to the GIC interrupts. +- interrupt-map-mask: standard property that helps to define the interrupt + mapping. + +Example SoC configuration: + + pci0: pci@ee090000 { + compatible = "renesas,pci-r8a7790"; + clocks = <&mstp7_clks R8A7790_CLK_EHCI>; + reg = <0x0 0xee090000 0x0 0xc00>, + <0x0 0xee080000 0x0 0x1100>; + interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + + bus-range = <0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + interrupt-map-mask = <0xff00 0 0 0x7>; + interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH + 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH + 0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>; + + pci@0,1 { + reg = <0x800 0 0 0 0>; + device_type = "pci"; + phys = <&usbphy 0 0>; + phy-names = "usb"; + }; + + pci@0,2 { + reg = <0x1000 0 0 0 0>; + device_type = "pci"; + phys = <&usbphy 0 0>; + phy-names = "usb"; + }; + }; + +Example board setup: + +&pci0 { + status = "okay"; + pinctrl-0 = <&usb0_pins>; + pinctrl-names = "default"; +}; diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt new file mode 100644 index 0000000..29d3b98 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt @@ -0,0 +1,47 @@ +* Renesas RCar PCIe interface + +Required properties: +- compatible: should contain one of the following + "renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791" +- reg: base address and length of the pcie controller registers. +- #address-cells: set to <3> +- #size-cells: set to <2> +- bus-range: PCI bus numbers covered +- device_type: set to "pci" +- ranges: ranges for the PCI memory and I/O regions. +- dma-ranges: ranges for the inbound memory regions. +- interrupts: two interrupt sources for MSI interrupts, followed by interrupt + source for hardware related interrupts (e.g. link speed change). +- #interrupt-cells: set to <1> +- interrupt-map-mask and interrupt-map: standard PCI properties + to define the mapping of the PCIe interface to interrupt + numbers. +- clocks: from common clock binding: clock specifiers for the PCIe controller + and PCIe bus clocks. +- clock-names: from common clock binding: should be "pcie" and "pcie_bus". + +Example: + +SoC specific DT Entry: + + pcie: pcie@fe000000 { + compatible = "renesas,pcie-r8a7791"; + reg = <0 0xfe000000 0 0x80000>; + #address-cells = <3>; + #size-cells = <2>; + bus-range = <0x00 0xff>; + device_type = "pci"; + ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000 + 0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000 + 0x02000000 0 0x30000000 0 0x30000000 0 0x08000000 + 0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>; + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000 + 0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>; + interrupts = <0 116 4>, <0 117 4>, <0 118 4>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic 0 116 4>; + clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>; + clock-names = "pcie", "pcie_bus"; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt new file mode 100644 index 0000000..4f9d23d --- /dev/null +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt @@ -0,0 +1,65 @@ +* Samsung Exynos 5440 PCIe interface + +This PCIe host controller is based on the Synopsis Designware PCIe IP +and thus inherits all the common properties defined in designware-pcie.txt. + +Required properties: +- compatible: "samsung,exynos5440-pcie" +- reg: base addresses and lengths of the pcie controller, + the phy controller, additional register for the phy controller. +- interrupts: A list of interrupt outputs for level interrupt, + pulse interrupt, special interrupt. + +Example: + +SoC specific DT Entry: + + pcie@290000 { + compatible = "samsung,exynos5440-pcie", "snps,dw-pcie"; + reg = <0x290000 0x1000 + 0x270000 0x1000 + 0x271000 0x40>; + interrupts = <0 20 0>, <0 21 0>, <0 22 0>; + clocks = <&clock 28>, <&clock 27>; + clock-names = "pcie", "pcie_bus"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */ + 0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */ + 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */ + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>; + num-lanes = <4>; + }; + + pcie@2a0000 { + compatible = "samsung,exynos5440-pcie", "snps,dw-pcie"; + reg = <0x2a0000 0x1000 + 0x272000 0x1000 + 0x271040 0x40>; + interrupts = <0 23 0>, <0 24 0>, <0 25 0>; + clocks = <&clock 29>, <&clock 27>; + clock-names = "pcie", "pcie_bus"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */ + 0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */ + 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */ + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>; + num-lanes = <4>; + }; + +Board specific DT Entry: + + pcie@290000 { + reset-gpio = <&pin_ctrl 5 0>; + }; + + pcie@2a0000 { + reset-gpio = <&pin_ctrl 22 0>; + }; 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 0000000..88f8c23 --- /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 0000000..296168b --- /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 8ae844f..2aa1840 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 0000000..42c8808 --- /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 0000000..952f6c9 --- /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 0000000..76bfbd0 --- /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 28f9edb..6099a5c 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. @@ -74,3 +76,90 @@ phy-consumer@12340000 { Refer to DT bindings documentation of particular PHY consumer devices for more information about required PHYs and the way of specification. + +Samsung 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 "samsung,exynos5250-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 "sata_phyctrl" +- samsung,exynos-sataphy-i2c-phandle : a phandle to the I2C device, no arguments +- samsung,syscon-phandle : a phandle to the PMU system controller, no arguments + +Example: + sata_phy: sata-phy@12170000 { + compatible = "samsung,exynos5250-sata-phy"; + reg = <0x12170000 0x1ff>; + clocks = <&clock 287>; + clock-names = "sata_phyctrl"; + #phy-cells = <0>; + samsung,exynos-sataphy-i2c-phandle = <&sata_phy_i2c>; + samsung,syscon-phandle = <&pmu_syscon>; + }; + +Device-Tree bindings for sataphy i2c client driver +-------------------------------------------------- + +Required properties: +compatible: Should be "samsung,exynos-sataphy-i2c" +- reg: I2C address of the sataphy i2c device. + +Example: + + sata_phy_i2c:sata-phy@38 { + compatible = "samsung,exynos-sataphy-i2c"; + reg = <0x38>; + }; + +Samsung Exynos5 SoC series USB DRD PHY controller +-------------------------------------------------- + +Required properties: +- compatible : Should be set to one of the following supported values: + - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC, + - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC. +- reg : Register offset and length of USB DRD PHY register set; +- clocks: Clock IDs array as required by the controller +- clock-names: names of clocks correseponding to IDs in the clock property; + Required clocks: + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock), + used for register access. + - ref: PHY's reference clock (usually crystal clock), used for + PHY operations, associated by phy name. It is used to + determine bit values for clock settings register. + For Exynos5420 this is given as 'sclk_usbphy30' in CMU. +- samsung,pmu-syscon: phandle for PMU system controller interface, used to + control pmu registers for power isolation. +- #phy-cells : from the generic PHY bindings, must be 1; + +For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy" +compatible PHYs, the second cell in the PHY specifier identifies the +PHY id, which is interpreted as follows: + 0 - UTMI+ type phy, + 1 - PIPE3 type phy, + +Example: + usbdrd_phy: usbphy@12100000 { + compatible = "samsung,exynos5250-usbdrd-phy"; + reg = <0x12100000 0x100>; + clocks = <&clock 286>, <&clock 1>; + clock-names = "phy", "ref"; + samsung,pmu-syscon = <&pmu_system_controller>; + #phy-cells = <1>; + }; + +- aliases: For SoCs like Exynos5420 having multiple USB 3.0 DRD PHY controllers, + 'usbdrd_phy' nodes should have numbered alias in the aliases node, + in the form of usbdrdphyN, N = 0, 1... (depending on number of + controllers). +Example: + aliases { + usbdrdphy0 = &usb3_phy0; + usbdrdphy1 = &usb3_phy1; + }; diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt index a82361b..16528b9 100644 --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt @@ -2,15 +2,26 @@ Allwinner sun4i USB PHY ----------------------- Required properties: -- compatible : should be one of "allwinner,sun4i-a10-usb-phy", - "allwinner,sun5i-a13-usb-phy" or "allwinner,sun7i-a20-usb-phy" +- compatible : should be one of + * allwinner,sun4i-a10-usb-phy + * allwinner,sun5i-a13-usb-phy + * allwinner,sun6i-a31-usb-phy + * allwinner,sun7i-a20-usb-phy - reg : a list of offset + length pairs -- reg-names : "phy_ctrl", "pmu1" and for sun4i or sun7i "pmu2" +- reg-names : + * "phy_ctrl" + * "pmu1" + * "pmu2" for sun4i, sun6i or sun7i - #phy-cells : from the generic phy bindings, must be 1 -- clocks : phandle + clock specifier for the phy clock -- clock-names : "usb_phy" +- clocks : phandle + clock specifier for the phy clocks +- clock-names : + * "usb_phy" for sun4i, sun5i or sun7i + * "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i - resets : a list of phandle + reset specifier pairs -- reset-names : "usb0_reset", "usb1_reset" and for sun4i or sun7i "usb2_reset" +- reset-names : + * "usb0_reset" + * "usb1_reset" + * "usb2_reset" for sun4i, sun6i or sun7i Example: usbphy: phy@0x01c13400 { diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index 788fb0f..305e3df 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"; @@ -32,6 +34,11 @@ Required properties: - reg : Address and length of the register set for the device. - #phy-cells: determine the number of cells that should be given in the phandle while referencing this phy. + - clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. + - clock-names: should include: + * "wkupclk" - wakeup clock. + * "refclk" - reference clock (optional). Optional properties: - ctrl-module : phandle of the control module used by PHY driver to power on @@ -44,13 +51,15 @@ usb2phy@4a0ad080 { reg = <0x4a0ad080 0x58>; ctrl-module = <&omap_control_usb>; #phy-cells = <0>; + clocks = <&usb_phy_cm_clk32k>, <&usb_otg_ss_refclk960m>; + clock-names = "wkupclk", "refclk"; }; 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". @@ -62,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/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt index dff0e5f..d8d0656 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt @@ -6,8 +6,13 @@ the first two functions being GPIO in and out. The configuration on the pins includes drive strength and pull-up. Required properties: -- compatible: "allwinner,<soc>-pinctrl". Supported SoCs for now are: - sun5i-a13. +- compatible: Should be one of the followings (depending on you SoC): + "allwinner,sun4i-a10-pinctrl" + "allwinner,sun5i-a10s-pinctrl" + "allwinner,sun5i-a13-pinctrl" + "allwinner,sun6i-a31-pinctrl" + "allwinner,sun6i-a31-r-pinctrl" + "allwinner,sun7i-a20-pinctrl" - reg: Should contain the register physical address and length for the pin controller. diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt index 54a6e82..4eaae32 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt @@ -119,7 +119,7 @@ Optional Properties (for HDMI pins): Example: // pin controller node pinctrl@35004800 { - compatible = "brcmbcm11351-pinctrl"; + compatible = "brcm,bcm11351-pinctrl"; reg = <0x35004800 0x430>; // pin configuration node diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt new file mode 100644 index 0000000..b1b5952 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt @@ -0,0 +1,36 @@ +* Freescale i.MX6 SoloX IOMUX Controller + +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part +and usage. + +Required properties: +- compatible: "fsl,imx6sx-iomuxc" +- fsl,pins: each entry consists of 6 integers and represents the mux and config + setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val + input_val> are specified using a PIN_FUNC_ID macro, which can be found in + imx6sx-pinfunc.h under device tree source folder. The last integer CONFIG is + the pad setting value like pull-up on this pin. Please refer to i.MX6 SoloX + Reference Manual for detailed CONFIG settings. + +CONFIG bits definition: +PAD_CTL_HYS (1 << 16) +PAD_CTL_PUS_100K_DOWN (0 << 14) +PAD_CTL_PUS_47K_UP (1 << 14) +PAD_CTL_PUS_100K_UP (2 << 14) +PAD_CTL_PUS_22K_UP (3 << 14) +PAD_CTL_PUE (1 << 13) +PAD_CTL_PKE (1 << 12) +PAD_CTL_ODE (1 << 11) +PAD_CTL_SPEED_LOW (0 << 6) +PAD_CTL_SPEED_MED (1 << 6) +PAD_CTL_SPEED_HIGH (3 << 6) +PAD_CTL_DSE_DISABLE (0 << 3) +PAD_CTL_DSE_260ohm (1 << 3) +PAD_CTL_DSE_130ohm (2 << 3) +PAD_CTL_DSE_87ohm (3 << 3) +PAD_CTL_DSE_65ohm (4 << 3) +PAD_CTL_DSE_52ohm (5 << 3) +PAD_CTL_DSE_43ohm (6 << 3) +PAD_CTL_DSE_37ohm (7 << 3) +PAD_CTL_SRE_FAST (1 << 0) +PAD_CTL_SRE_SLOW (0 << 0) diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt new file mode 100644 index 0000000..27570a3 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt @@ -0,0 +1,91 @@ +* Marvell Orion SoC pinctrl driver for mpp + +Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding +part and usage. + +Required properties: +- compatible: "marvell,88f5181l-pinctrl", "marvell,88f5182-pinctrl", + "marvell,88f5281-pinctrl" + +- reg: two register areas, the first one describing the first two + contiguous MPP registers, and the second one describing the single + final MPP register, separated from the previous one. + +Available mpp pins/groups and functions: +Note: brackets (x) are not part of the mpp name for marvell,function and given +only for more detailed description in this document. + +* Marvell Orion 88f5181l + +name pins functions +================================================================================ +mpp0 0 pcie(rstout), pci(req2), gpio +mpp1 1 gpio, pci(gnt2) +mpp2 2 gpio, pci(req3), pci-1(pme) +mpp3 3 gpio, pci(gnt3) +mpp4 4 gpio, pci(req4) +mpp5 5 gpio, pci(gnt4) +mpp6 6 gpio, pci(req5), pci-1(clk) +mpp7 7 gpio, pci(gnt5), pci-1(clk) +mpp8 8 gpio, ge(col) +mpp9 9 gpio, ge(rxerr) +mpp10 10 gpio, ge(crs) +mpp11 11 gpio, ge(txerr) +mpp12 12 gpio, ge(txd4) +mpp13 13 gpio, ge(txd5) +mpp14 14 gpio, ge(txd6) +mpp15 15 gpio, ge(txd7) +mpp16 16 ge(rxd4) +mpp17 17 ge(rxd5) +mpp18 18 ge(rxd6) +mpp19 19 ge(rxd7) + +* Marvell Orion 88f5182 + +name pins functions +================================================================================ +mpp0 0 pcie(rstout), pci(req2), gpio +mpp1 1 gpio, pci(gnt2) +mpp2 2 gpio, pci(req3), pci-1(pme) +mpp3 3 gpio, pci(gnt3) +mpp4 4 gpio, pci(req4), bootnand(re), sata0(prsnt) +mpp5 5 gpio, pci(gnt4), bootnand(we), sata1(prsnt) +mpp6 6 gpio, pci(req5), nand(re0), sata0(act) +mpp7 7 gpio, pci(gnt5), nand(we0), sata1(act) +mpp8 8 gpio, ge(col) +mpp9 9 gpio, ge(rxerr) +mpp10 10 gpio, ge(crs) +mpp11 11 gpio, ge(txerr) +mpp12 12 gpio, ge(txd4), nand(re1), sata0(ledprsnt) +mpp13 13 gpio, ge(txd5), nand(we1), sata1(ledprsnt) +mpp14 14 gpio, ge(txd6), nand(re2), sata0(ledact) +mpp15 15 gpio, ge(txd7), nand(we2), sata1(ledact) +mpp16 16 uart1(rxd), ge(rxd4), gpio +mpp17 17 uart1(txd), ge(rxd5), gpio +mpp18 18 uart1(cts), ge(rxd6), gpio +mpp19 19 uart1(rts), ge(rxd7), gpio + +* Marvell Orion 88f5281 + +name pins functions +================================================================================ +mpp0 0 pcie(rstout), pci(req2), gpio +mpp1 1 gpio, pci(gnt2) +mpp2 2 gpio, pci(req3), pci(pme) +mpp3 3 gpio, pci(gnt3) +mpp4 4 gpio, pci(req4), bootnand(re) +mpp5 5 gpio, pci(gnt4), bootnand(we) +mpp6 6 gpio, pci(req5), nand(re0) +mpp7 7 gpio, pci(gnt5), nand(we0) +mpp8 8 gpio, ge(col) +mpp9 9 gpio, ge(rxerr) +mpp10 10 gpio, ge(crs) +mpp11 11 gpio, ge(txerr) +mpp12 12 gpio, ge(txd4), nand(re1) +mpp13 13 gpio, ge(txd5), nand(we1) +mpp14 14 gpio, ge(txd6), nand(re2) +mpp15 15 gpio, ge(txd7), nand(we2) +mpp16 16 uart1(rxd), ge(rxd4) +mpp17 17 uart1(txd), ge(rxd5) +mpp18 18 uart1(cts), ge(rxd6) +mpp19 19 uart1(rts), ge(rxd7) diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index 4414163..fa40a17 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -156,6 +156,7 @@ input-disable - disable input on pin (no effect on output) input-schmitt-enable - enable schmitt-trigger mode input-schmitt-disable - disable schmitt-trigger mode input-debounce - debounce mode with debound time X +power-source - select between different power supplies low-power-enable - enable low power mode low-power-disable - disable low power mode output-low - set the pin to output mode with low level diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt index 4bd5be0..26bcb18 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt @@ -83,7 +83,7 @@ Example: reg = <0xfe61f080 0x4>; reg-names = "irqmux"; interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>; - interrupts-names = "irqmux"; + interrupt-names = "irqmux"; ranges = <0 0xfe610000 0x5000>; PIO0: gpio@fe610000 { @@ -165,7 +165,7 @@ sdhci0:sdhci@fe810000{ interrupt-parent = <&PIO3>; #interrupt-cells = <2>; interrupts = <3 IRQ_TYPE_LEVEL_HIGH>; /* Interrupt line via PIO3-3 */ - interrupts-names = "card-detect"; + interrupt-names = "card-detect"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_mmc>; }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt new file mode 100644 index 0000000..7181f92 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt @@ -0,0 +1,88 @@ +Qualcomm APQ8064 TLMM block + +Required properties: +- compatible: "qcom,apq8064-pinctrl" +- reg: Should be the base address and length of the TLMM block. +- interrupts: Should be the parent IRQ of the TLMM block. +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be two. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells : Should be two. + The first cell is the gpio pin number and the + second cell is used for optional parameters. + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +Qualcomm's pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + + pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength, + output-low, output-high. + +Non-empty subnodes must specify the 'pins' property. + +Valid values for pins are: + gpio0-gpio89 + +Valid values for function are: + cam_mclk, codec_mic_i2s, codec_spkr_i2s, gsbi1, gsbi2, gsbi3, gsbi4, + gsbi4_cam_i2c, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, + gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3, gsbi7, gsbi7_spi_cs1, + gsbi7_spi_cs2, gsbi7_spi_cs3, gsbi_cam_i2c, hdmi, mi2s, riva_bt, riva_fm, + riva_wlan, sdc2, sdc4, slimbus, spkr_i2s, tsif1, tsif2, usb2_hsic, + +Example: + + msmgpio: pinctrl@800000 { + compatible = "qcom,apq8064-pinctrl"; + reg = <0x800000 0x4000>; + + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <0 32 0x4>; + + pinctrl-names = "default"; + pinctrl-0 = <&gsbi5_uart_default>; + + gsbi5_uart_default: gsbi5_uart_default { + mux { + pins = "gpio51", "gpio52"; + function = "gsbi5"; + }; + + tx { + pins = "gpio51"; + drive-strength = <4>; + bias-disable; + }; + + rx { + pins = "gpio52"; + drive-strength = <2>; + bias-pull-up; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt new file mode 100644 index 0000000..e0d35a4 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt @@ -0,0 +1,95 @@ +Qualcomm IPQ8064 TLMM block + +Required properties: +- compatible: "qcom,ipq8064-pinctrl" +- reg: Should be the base address and length of the TLMM block. +- interrupts: Should be the parent IRQ of the TLMM block. +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be two. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells : Should be two. + The first cell is the gpio pin number and the + second cell is used for optional parameters. + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +Qualcomm's pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + + pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength, + output-low, output-high. + +Non-empty subnodes must specify the 'pins' property. + +Valid values for qcom,pins are: + gpio0-gpio68 + Supports mux, bias, and drive-strength + + sdc3_clk, sdc3_cmd, sdc3_data + Supports bias and drive-strength + + +Valid values for function are: + mdio, mi2s, pdm, ssbi, spmi, audio_pcm, gsbi1, gsbi2, gsbi4, gsbi5, + gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, gsbi7, nss_spi, sdc1, + spdif, nand, tsif1, tsif2, usb_fs_n, usb_fs, usb2_hsic, rgmii2, sata, + pcie1_rst, pcie1_prsnt, pcie1_pwren_n, pcie1_pwren, pcie1_pwrflt, + pcie1_clk_req, pcie2_rst, pcie2_prsnt, pcie2_pwren_n, pcie2_pwren, + pcie2_pwrflt, pcie2_clk_req, pcie3_rst, pcie3_prsnt, pcie3_pwren_n, + pcie3_pwren, pcie3_pwrflt, pcie3_clk_req, ps_hold + +Example: + + pinmux: pinctrl@800000 { + compatible = "qcom,ipq8064-pinctrl"; + reg = <0x800000 0x4000>; + + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <0 32 0x4>; + + pinctrl-names = "default"; + pinctrl-0 = <&gsbi5_uart_default>; + + gsbi5_uart_default: gsbi5_uart_default { + mux { + pins = "gpio18", "gpio19"; + function = "gsbi5"; + }; + + tx { + pins = "gpio18"; + drive-strength = <4>; + bias-disable; + }; + + rx { + pins = "gpio19"; + drive-strength = <2>; + bias-pull-up; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt index 9fb89e3..73262b5 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt @@ -50,7 +50,27 @@ Valid values for pins are: Supports bias and drive-strength Valid values for function are: - blsp_i2c2, blsp_i2c6, blsp_i2c11, blsp_spi1, blsp_uart2, blsp_uart8, slimbus + cci_i2c0, cci_i2c1, uim1, uim2, uim_batt_alarm, + blsp_uim1, blsp_uart1, blsp_i2c1, blsp_spi1, + blsp_uim2, blsp_uart2, blsp_i2c2, blsp_spi2, + blsp_uim3, blsp_uart3, blsp_i2c3, blsp_spi3, + blsp_uim4, blsp_uart4, blsp_i2c4, blsp_spi4, + blsp_uim5, blsp_uart5, blsp_i2c5, blsp_spi5, + blsp_uim6, blsp_uart6, blsp_i2c6, blsp_spi6, + blsp_uim7, blsp_uart7, blsp_i2c7, blsp_spi7, + blsp_uim8, blsp_uart8, blsp_i2c8, blsp_spi8, + blsp_uim9, blsp_uart9, blsp_i2c9, blsp_spi9, + blsp_uim10, blsp_uart10, blsp_i2c10, blsp_spi10, + blsp_uim11, blsp_uart11, blsp_i2c11, blsp_spi11, + blsp_uim12, blsp_uart12, blsp_i2c12, blsp_spi12, + blsp_spi1_cs1, blsp_spi2_cs2, blsp_spi_cs3, blsp_spi2_cs1, blsp_spi2_cs2 + blsp_spi2_cs3, blsp_spi10_cs1, blsp_spi10_cs2, blsp_spi10_cs3, + sdc3, sdc4, gcc_gp_clk1, gcc_gp_clk2, gcc_gp_clk3, cci_timer0, cci_timer1, + cci_timer2, cci_timer3, cci_async_in0, cci_async_in1, cci_async_in2, + cam_mckl0, cam_mclk1, cam_mclk2, cam_mclk3, mdp_vsync, hdmi_cec, hdmi_ddc, + hdmi_hpd, edp_hpd, gp_pdm0, gp_pdm1, gp_pdm2, gp_pdm3, gp0_clk, gp1_clk, + gp_mn, tsif1, tsif2, hsic, grfc, audio_ref_clk, qua_mi2s, pri_mi2s, spkr_mi2s, + ter_mi2s, sec_mi2s, bt, fm, wlan, slimbus (Note that this is not yet the complete list of functions) diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index f378d34..cefef74 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt @@ -21,13 +21,23 @@ defined as gpio sub-nodes of the pinmux controller. Required properties for iomux controller: - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl" + - rockchip,grf: phandle referencing a syscon providing the + "general register files" + +Optional properties for iomux controller: + - rockchip,pmu: phandle referencing a syscon providing the pmu registers + as some SoCs carry parts of the iomux controller registers there. + Required for at least rk3188 and rk3288. + +Deprecated properties for iomux controller: - reg: first element is the general register space of the iomux controller - second element is the separate pull register space of the rk3188 + It should be large enough to contain also separate pull registers. + second element is the separate pull register space of the rk3188. + Use rockchip,grf and rockchip,pmu described above instead. Required properties for gpio sub nodes: - compatible: "rockchip,gpio-bank", "rockchip,rk3188-gpio-bank0" - reg: register of the gpio bank (different than the iomux registerset) - second element: separate pull register for rk3188 bank0 - interrupts: base interrupt of the gpio bank in the interrupt controller - clocks: clock that drives this bank - gpio-controller: identifies the node as a gpio controller and pin bank. @@ -39,6 +49,10 @@ Required properties for gpio sub nodes: cells should use the standard two-cell scheme described in bindings/interrupt-controller/interrupts.txt +Deprecated properties for gpio sub nodes: + - reg: second element: separate pull register for rk3188 bank0, use + rockchip,pmu described above instead + Required properties for pin configuration node: - rockchip,pins: 3 integers array, represents a group of pins mux and config setting. The format is rockchip,pins = <PIN_BANK PIN_BANK_IDX MUX &phandle>. @@ -54,7 +68,8 @@ Examples: pinctrl@20008000 { compatible = "rockchip,rk3066a-pinctrl"; - reg = <0x20008000 0x150>; + rockchip,grf = <&grf>; + #address-cells = <1>; #size-cells = <1>; ranges; @@ -103,16 +118,15 @@ Example for rk3188: pinctrl@20008000 { compatible = "rockchip,rk3188-pinctrl"; - reg = <0x20008000 0xa0>, - <0x20008164 0x1a0>; + rockchip,grf = <&grf>; + rockchip,pmu = <&pmu>; #address-cells = <1>; #size-cells = <1>; ranges; gpio0: gpio0@0x2000a000 { compatible = "rockchip,rk3188-gpio-bank0"; - reg = <0x2000a000 0x100>, - <0x20004064 0x8>; + reg = <0x2000a000 0x100>; interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clk_gates8 9>; diff --git a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt new file mode 100644 index 0000000..c82f12e --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt @@ -0,0 +1,67 @@ +* Device tree bindings for Texas Instruments keystone reset + +This node is intended to allow SoC reset in case of software reset +of selected watchdogs. + +The Keystone SoCs can contain up to 4 watchdog timers to reset +SoC. Each watchdog timer event input is connected to the Reset Mux +block. The Reset Mux block can be configured to cause reset or not. + +Additionally soft or hard reset can be configured. + +Required properties: + +- compatible: ti,keystone-reset + +- ti,syscon-pll: phandle/offset pair. The phandle to syscon used to + access pll controller registers and the offset to use + reset control registers. + +- ti,syscon-dev: phandle/offset pair. The phandle to syscon used to + access device state control registers and the offset + in order to use mux block registers for all watchdogs. + +Optional properties: + +- ti,soft-reset: Boolean option indicating soft reset. + By default hard reset is used. + +- ti,wdt-list: WDT list that can cause SoC reset. It's not related + to WDT driver, it's just needed to enable a SoC related + reset that's triggered by one of WDTs. The list is + in format: <0>, <2>; It can be in random order and + begins from 0 to 3, as keystone can contain up to 4 SoC + reset watchdogs and can be in random order. + +Example 1: +Setup keystone reset so that in case software reset or +WDT0 is triggered it issues hard reset for SoC. + +pllctrl: pll-controller@02310000 { + compatible = "ti,keystone-pllctrl", "syscon"; + reg = <0x02310000 0x200>; +}; + +devctrl: device-state-control@02620000 { + compatible = "ti,keystone-devctrl", "syscon"; + reg = <0x02620000 0x1000>; +}; + +rstctrl: reset-controller { + compatible = "ti,keystone-reset"; + ti,syscon-pll = <&pllctrl 0xe4>; + ti,syscon-dev = <&devctrl 0x328>; + ti,wdt-list = <0>; +}; + +Example 2: +Setup keystone reset so that in case of software reset or +WDT0 or WDT2 is triggered it issues soft reset for SoC. + +rstctrl: reset-controller { + compatible = "ti,keystone-reset"; + ti,syscon-pll = <&pllctrl 0xe4>; + ti,syscon-dev = <&devctrl 0x328>; + ti,wdt-list = <0>, <2>; + ti,soft-reset; +}; diff --git a/Documentation/devicetree/bindings/power/rx51-battery.txt b/Documentation/devicetree/bindings/power/rx51-battery.txt new file mode 100644 index 0000000..9043845 --- /dev/null +++ b/Documentation/devicetree/bindings/power/rx51-battery.txt @@ -0,0 +1,25 @@ +Binding for Nokia N900 battery + +The Nokia N900 battery status can be read via the TWL4030's A/D converter. + +Required properties: +- compatible: Should contain one of the following: + * "nokia,n900-battery" +- io-channels: Should contain IIO channel specifiers + for each element in io-channel-names. +- io-channel-names: Should contain the following values: + * "temp" - The ADC channel for temperature reading + * "bsi" - The ADC channel for battery size identification + * "vbat" - The ADC channel to measure the battery voltage + +Example from Nokia N900: + +battery: n900-battery { + compatible = "nokia,n900-battery"; + io-channels = <&twl4030_madc 0>, + <&twl4030_madc 4>, + <&twl4030_madc 12>; + io-channel-names = "temp", + "bsi", + "vbat"; +}; diff --git a/Documentation/devicetree/bindings/power_supply/axxia-reset.txt b/Documentation/devicetree/bindings/power_supply/axxia-reset.txt new file mode 100644 index 0000000..47e720d --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/axxia-reset.txt @@ -0,0 +1,20 @@ +Axxia Restart Driver + +This driver can do reset of the Axxia SoC. It uses the registers in the syscon +block to initiate a chip reset. + +Required Properties: + -compatible: "lsi,axm55xx-reset" + -syscon: phandle to the syscon node. + +Example: + + syscon: syscon@2010030000 { + compatible = "lsi,axxia-syscon", "syscon"; + reg = <0x20 0x10030000 0 0x2000>; + }; + + reset: reset@2010031000 { + compatible = "lsi,axm55xx-reset"; + syscon = <&syscon>; + }; diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt index 0347d83..af25e77 100644 --- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt +++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt @@ -6,8 +6,11 @@ Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the microcontroller to turn the power off. This driver adds a handler to pm_power_off which is called to turn the power off. +Synology NAS devices use a similar scheme, but a different baud rate, +9600, and a different character, '1'. + Required Properties: -- compatible: Should be "qnap,power-off" +- compatible: Should be "qnap,power-off" or "synology,power-off" - reg: Address and length of the register set for UART1 - clocks: tclk clock diff --git a/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt b/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt new file mode 100644 index 0000000..db93921 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt @@ -0,0 +1,54 @@ + +IBM Akebono board device tree +============================= + +The IBM Akebono board is a development board for the PPC476GTR SoC. + +0) The root node + + Required properties: + + - model : "ibm,akebono". + - compatible : "ibm,akebono" , "ibm,476gtr". + +1.a) The Secure Digital Host Controller Interface (SDHCI) node + + Represent the Secure Digital Host Controller Interfaces. + + Required properties: + + - compatible : should be "ibm,476gtr-sdhci","generic-sdhci". + - reg : should contain the SDHCI registers location and length. + - interrupt-parent : a phandle for the interrupt controller. + - interrupts : should contain the SDHCI interrupt. + +1.b) The Advanced Host Controller Interface (AHCI) SATA node + + Represents the advanced host controller SATA interface. + + Required properties: + + - compatible : should be "ibm,476gtr-ahci". + - reg : should contain the AHCI registers location and length. + - interrupt-parent : a phandle for the interrupt controller. + - interrupts : should contain the AHCI interrupt. + +1.c) The FPGA node + + The Akebono board stores some board information such as the revision + number in an FPGA which is represented by this node. + + Required properties: + + - compatible : should be "ibm,akebono-fpga". + - reg : should contain the FPGA registers location and length. + +1.d) The AVR node + + The Akebono board has an Atmel AVR microprocessor attached to the I2C + bus as a power controller for the board. + + Required properties: + + - compatible : should be "ibm,akebono-avr". + - reg : should contain the I2C bus address for the AVR. diff --git a/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt b/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt new file mode 100644 index 0000000..c737c83 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt @@ -0,0 +1,19 @@ + +ppc476gtr High Speed Serial Assist (HSTA) node +============================================== + +The 476gtr SoC contains a high speed serial assist module attached +between the plb4 and plb6 system buses to provide high speed data +transfer between memory and system peripherals as well as support for +PCI message signalled interrupts. + +Currently only the MSI support is used by Linux using the following +device tree entries: + +Require properties: +- compatible : "ibm,476gtr-hsta-msi", "ibm,hsta-msi" +- reg : register mapping for the HSTA MSI space +- interrupt-parent : parent controller for mapping interrupts +- interrupts : ordered interrupt mapping for each MSI in the register + space. The first interrupt should be associated with a + register offset of 0x00, the second to 0x10, etc. diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt index 380914e..700dec4 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt @@ -67,3 +67,20 @@ Example: gpio-controller; }; }; + +* Freescale on-board FPGA connected on I2C bus + +Some Freescale boards like BSC9132QDS have on board FPGA connected on +the i2c bus. + +Required properties: +- compatible: Should be a board-specific string followed by a string + indicating the type of FPGA. Example: + "fsl,<board>-fpga", "fsl,fpga-qixis-i2c" +- reg: Should contain the address of the FPGA + +Example: + fpga: fpga@66 { + compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c"; + reg = <0x66>; + }; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt new file mode 100644 index 0000000..454da7e --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt @@ -0,0 +1,46 @@ +Freescale CoreNet Coherency Fabric(CCF) Device Tree Binding + +DESCRIPTION + +The CoreNet coherency fabric is a fabric-oriented, connectivity infrastructure +that enables the implementation of coherent, multicore systems. + +Required properties: + +- compatible: <string list> + fsl,corenet1-cf - CoreNet coherency fabric version 1. + Example chips: T4240, B4860 + + fsl,corenet2-cf - CoreNet coherency fabric version 2. + Example chips: P5040, P5020, P4080, P3041, P2041 + + fsl,corenet-cf - Used to represent the common registers + between CCF version 1 and CCF version 2. This compatible + is retained for compatibility reasons, as it was already + used for both CCF version 1 chips and CCF version 2 + chips. It should be specified after either + "fsl,corenet1-cf" or "fsl,corenet2-cf". + +- reg: <prop-encoded-array> + A standard property. Represents the CCF registers. + +- interrupts: <prop-encoded-array> + Interrupt mapping for CCF error interrupt. + +- fsl,ccf-num-csdids: <u32> + Specifies the number of Coherency Subdomain ID Port Mapping + Registers that are supported by the CCF. + +- fsl,ccf-num-snoopids: <u32> + Specifies the number of Snoop ID Port Mapping Registers that + are supported by CCF. + +Example: + + corenet-cf@18000 { + compatible = "fsl,corenet2-cf", "fsl,corenet-cf"; + reg = <0x18000 0x1000>; + interrupts = <16 2 1 31>; + fsl,ccf-num-csdids = <32>; + fsl,ccf-num-snoopids = <32>; + }; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt index 922c30a..f8cd239 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt @@ -20,3 +20,14 @@ PROPERTIES a property named fsl,eref-[CAT], where [CAT] is the abbreviated category name with all uppercase letters converted to lowercase, indicates that the category is supported by the implementation. + + - fsl,portid-mapping + Usage: optional + Value type: <u32> + Definition: The Coherency Subdomain ID Port Mapping Registers and + Snoop ID Port Mapping registers, which are part of the CoreNet + Coherency fabric (CCF), provide a CoreNet Coherency Subdomain + ID/CoreNet Snoop ID to cpu mapping functions. Certain bits from + these registers should be set if the coresponding CPU should be + snooped. This property defines a bitmask which selects the bit + that should be set if this cpu should be snooped. diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt index 1f5e329..c2b2899 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt @@ -34,6 +34,15 @@ Optional properties: for legacy drivers. - interrupt-parent : <phandle> Phandle to interrupt controller +- fsl,portid-mapping : <u32> + The Coherency Subdomain ID Port Mapping Registers and + Snoop ID Port Mapping registers, which are part of the + CoreNet Coherency fabric (CCF), provide a CoreNet + Coherency Subdomain ID/CoreNet Snoop ID to pamu mapping + functions. Certain bits from these registers should be + set if PAMUs should be snooped. This property defines + a bitmask which selects the bits that should be set if + PAMUs should be snooped. Child nodes: @@ -88,6 +97,7 @@ Example: compatible = "fsl,pamu-v1.0", "fsl,pamu"; reg = <0x20000 0x5000>; ranges = <0 0x20000 0x5000>; + fsl,portid-mapping = <0xf80000>; #address-cells = <1>; #size-cells = <1>; interrupts = < diff --git a/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt new file mode 100644 index 0000000..8eae9fe --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt @@ -0,0 +1,21 @@ +Broadcom Kona PWM controller device tree bindings + +This controller has 6 channels. + +Required Properties : +- compatible: should contain "brcm,kona-pwm" +- reg: physical base address and length of the controller's registers +- clocks: phandle + clock specifier pair for the external clock +- #pwm-cells: Should be 3. See pwm.txt in this directory for a + description of the cells format. + +Refer to clocks/clock-bindings.txt for generic clock consumer properties. + +Example: + +pwm: pwm@3e01a000 { + compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm"; + reg = <0x3e01a000 0xc4>; + clocks = <&pwm_clk>; + #pwm-cells = <3>; +}; diff --git a/Documentation/devicetree/bindings/pwm/cirrus,clps711x-pwm.txt b/Documentation/devicetree/bindings/pwm/cirrus,clps711x-pwm.txt new file mode 100644 index 0000000..a183db4 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/cirrus,clps711x-pwm.txt @@ -0,0 +1,16 @@ +* Cirris Logic CLPS711X PWM controller + +Required properties: +- compatible: Shall contain "cirrus,clps711x-pwm". +- reg: Physical base address and length of the controller's registers. +- clocks: phandle + clock specifier pair of the PWM reference clock. +- #pwm-cells: Should be 1. The cell specifies the index of the channel. + +Example: + pwm: pwm@80000400 { + compatible = "cirrus,ep7312-pwm", + "cirrus,clps711x-pwm"; + reg = <0x80000400 0x4>; + clocks = <&clks 8>; + #pwm-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt new file mode 100644 index 0000000..0bda229 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt @@ -0,0 +1,35 @@ +Freescale FlexTimer Module (FTM) PWM controller + +Required properties: +- compatible: Should be "fsl,vf610-ftm-pwm". +- reg: Physical base address and length of the controller's registers +- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of + the cells format. +- clock-names: Should include the following module clock source entries: + "ftm_sys" (module clock, also can be used as counter clock), + "ftm_ext" (external counter clock), + "ftm_fix" (fixed counter clock), + "ftm_cnt_clk_en" (external and fixed counter clock enable/disable). +- clocks: Must contain a phandle and clock specifier for each entry in + clock-names, please see clock/clock-bindings.txt for details of the property + values. +- pinctrl-names: Must contain a "default" entry. +- pinctrl-NNN: One property must exist for each entry in pinctrl-names. + See pinctrl/pinctrl-bindings.txt for details of the property values. + + +Example: + +pwm0: pwm@40038000 { + compatible = "fsl,vf610-ftm-pwm"; + reg = <0x40038000 0x1000>; + #pwm-cells = <3>; + clock-names = "ftm_sys", "ftm_ext", + "ftm_fix", "ftm_cnt_clk_en"; + clocks = <&clks VF610_CLK_FTM0>, + <&clks VF610_CLK_FTM0_EXT_SEL>, + <&clks VF610_CLK_FTM0_FIX_SEL>, + <&clks VF610_CLK_FTM0_EXT_FIX_EN>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pwm0_1>; +}; diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt index bef1fbb..865614b 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/ltc3589.txt b/Documentation/devicetree/bindings/regulator/ltc3589.txt new file mode 100644 index 0000000..8010530 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/ltc3589.txt @@ -0,0 +1,99 @@ +Linear Technology LTC3589, LTC3589-1, and LTC3589-2 8-output regulators + +Required properties: +- compatible: "lltc,ltc3589", "lltc,ltc3589-1" or "lltc,ltc3589-2" +- reg: I2C slave address + +Required child node: +- regulators: Contains eight regulator child nodes sw1, sw2, sw3, bb-out, + ldo1, ldo2, ldo3, and ldo4, specifying the initialization data as + documented in Documentation/devicetree/bindings/regulator/regulator.txt. + +Each regulator is defined using the standard binding for regulators. The +nodes for sw1, sw2, sw3, bb-out, ldo1, and ldo2 additionally need to specify +the resistor values of their external feedback voltage dividers: + +Required properties (not on ldo3, ldo4): +- lltc,fb-voltage-divider: An array of two integers containing the resistor + values R1 and R2 of the feedback voltage divider in ohms. + +Regulators sw1, sw2, sw3, and ldo2 can regulate the feedback reference from +0.3625 V to 0.75 V in 12.5 mV steps. The output voltage thus ranges between +0.3625 * (1 + R1/R2) V and 0.75 * (1 + R1/R2) V. Regulators bb-out and ldo1 +have a fixed 0.8 V reference and thus output 0.8 * (1 + R1/R2) V. The ldo3 +regulator is fixed to 1.8 V on LTC3589 and to 2.8 V on LTC3589-1,2. The ldo4 +regulator can output between 1.8 V and 3.3 V on LTC3589 and between 1.2 V +and 3.2 V on LTC3589-1,2 in four steps. The ldo1 standby regulator can not +be disabled and thus should have the regulator-always-on property set. + +Example: + + ltc3589: pmic@34 { + compatible = "lltc,ltc3589-1"; + reg = <0x34>; + + regulators { + sw1_reg: sw1 { + regulator-min-microvolt = <591930>; + regulator-max-microvolt = <1224671>; + lltc,fb-voltage-divider = <100000 158000>; + regulator-ramp-delay = <7000>; + regulator-boot-on; + regulator-always-on; + }; + + sw2_reg: sw2 { + regulator-min-microvolt = <704123>; + regulator-max-microvolt = <1456803>; + lltc,fb-voltage-divider = <180000 191000>; + regulator-ramp-delay = <7000>; + regulator-boot-on; + regulator-always-on; + }; + + sw3_reg: sw3 { + regulator-min-microvolt = <1341250>; + regulator-max-microvolt = <2775000>; + lltc,fb-voltage-divider = <270000 100000>; + regulator-ramp-delay = <7000>; + regulator-boot-on; + regulator-always-on; + }; + + bb_out_reg: bb-out { + regulator-min-microvolt = <3387341>; + regulator-max-microvolt = <3387341>; + lltc,fb-voltage-divider = <511000 158000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo1_reg: ldo1 { + regulator-min-microvolt = <1306329>; + regulator-max-microvolt = <1306329>; + lltc,fb-voltage-divider = <100000 158000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo2_reg: ldo2 { + regulator-min-microvolt = <704123>; + regulator-max-microvolt = <1456806>; + lltc,fb-voltage-divider = <180000 191000>; + regulator-ramp-delay = <7000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo3_reg: ldo3 { + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + regulator-boot-on; + }; + + ldo4_reg: ldo4 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3200000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index 42e6b6b..725393c 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/pbias-regulator.txt b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt new file mode 100644 index 0000000..32aa26f --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt @@ -0,0 +1,27 @@ +PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs. + +Required properties: +- compatible: + - "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7. +- reg: pbias register offset from syscon base and size of pbias register. +- syscon : phandle of the system control module +- regulator-name : should be + pbias_mmc_omap2430 for OMAP2430, OMAP3 SoCs + pbias_sim_omap3 for OMAP3 SoCs + pbias_mmc_omap4 for OMAP4 SoCs + pbias_mmc_omap5 for OMAP5 and DRA7 SoC + +Optional properties: +- Any optional property defined in bindings/regulator/regulator.txt + +Example: + + pbias_regulator: pbias_regulator { + compatible = "ti,pbias-omap"; + reg = <0 0x4>; + syscon = <&omap5_padconf_global>; + pbias_mmc_reg: pbias_mmc_omap5 { + regulator-name = "pbias_mmc_omap5"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3000000>; + }; diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt b/Documentation/devicetree/bindings/regulator/tps65090.txt index 313a60b..34098023 100644 --- a/Documentation/devicetree/bindings/regulator/tps65090.txt +++ b/Documentation/devicetree/bindings/regulator/tps65090.txt @@ -21,6 +21,10 @@ Optional properties: number should be provided. If it is externally controlled and no GPIO entry then driver will just configure this rails as external control and will not provide any enable/disable APIs. +- ti,overcurrent-wait: This is applicable to FET registers, which have a + poorly defined "overcurrent wait" field. If this property is present it + should be between 0 - 3. If this property isn't present we won't touch the + "overcurrent wait" field and we'll leave it to the BIOS/EC to deal with. Each regulator is defined using the standard binding for regulators. diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt b/Documentation/devicetree/bindings/regulator/tps65218.txt new file mode 100644 index 0000000..fccc1d2 --- /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/reset/allwinner,sunxi-clock-reset.txt b/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt new file mode 100644 index 0000000..c8f7757 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt @@ -0,0 +1,21 @@ +Allwinner sunxi Peripheral Reset Controller +=========================================== + +Please also refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: +- compatible: Should be one of the following: + "allwinner,sun6i-a31-ahb1-reset" + "allwinner,sun6i-a31-clock-reset" +- reg: should be register base and length as documented in the + datasheet +- #reset-cells: 1, see below + +example: + +ahb1_rst: reset@01c202c0 { + #reset-cells = <1>; + compatible = "allwinner,sun6i-a31-ahb1-reset"; + reg = <0x01c202c0 0xc>; +}; diff --git a/Documentation/devicetree/bindings/reset/sirf,rstc.txt b/Documentation/devicetree/bindings/reset/sirf,rstc.txt new file mode 100644 index 0000000..0505de7 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/sirf,rstc.txt @@ -0,0 +1,42 @@ +CSR SiRFSoC Reset Controller +====================================== + +Please also refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: +- compatible: Should be "sirf,prima2-rstc" or "sirf,marco-rstc" +- reg: should be register base and length as documented in the + datasheet +- #reset-cells: 1, see below + +example: + +rstc: reset-controller@88010000 { + compatible = "sirf,prima2-rstc"; + reg = <0x88010000 0x1000>; + #reset-cells = <1>; +}; + +Specifying reset lines connected to IP modules +============================================== + +The reset controller(rstc) manages various reset sources. This module provides +reset signals for most blocks in system. Those device nodes should specify the +reset line on the rstc in their resets property, containing a phandle to the +rstc device node and a RESET_INDEX specifying which module to reset, as described +in reset.txt. + +For SiRFSoC, RESET_INDEX is just reset_bit defined in SW_RST0 and SW_RST1 registers. +For modules whose rest_bit is in SW_RST0, its RESET_INDEX is 0~31. For modules whose +rest_bit is in SW_RST1, its RESET_INDEX is 32~63. + +example: + +vpp@90020000 { + compatible = "sirf,prima2-vpp"; + reg = <0x90020000 0x10000>; + interrupts = <31>; + clocks = <&clks 35>; + resets = <&rstc 6>; +}; diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt b/Documentation/devicetree/bindings/reset/socfpga-reset.txt index ecdb57d..32c1c8b 100644 --- a/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt +++ b/Documentation/devicetree/bindings/reset/socfpga-reset.txt @@ -3,9 +3,11 @@ Altera SOCFPGA Reset Manager Required properties: - compatible : "altr,rst-mgr" - reg : Should contain 1 register ranges(address and length) +- #reset-cells: 1 Example: rstmgr@ffd05000 { + #reset-cells = <1>; compatible = "altr,rst-mgr"; reg = <0xffd05000 0x1000>; }; diff --git a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt new file mode 100644 index 0000000..5ab26b7 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt @@ -0,0 +1,47 @@ +STMicroelectronics STi family Sysconfig Peripheral Powerdown Reset Controller +============================================================================= + +This binding describes a reset controller device that is used to enable and +disable on-chip peripheral controllers such as USB and SATA, using +"powerdown" control bits found in the STi family SoC system configuration +registers. These have been grouped together into a single reset controller +device for convenience. + +The actual action taken when powerdown is asserted is hardware dependent. +However, when asserted it may not be possible to access the hardware's +registers and after an assert/deassert sequence the hardware's previous state +may no longer be valid. + +Please refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: +- compatible: Should be "st,<chip>-powerdown" + ex: "st,stih415-powerdown", "st,stih416-powerdown" +- #reset-cells: 1, see below + +example: + + powerdown: powerdown-controller { + #reset-cells = <1>; + compatible = "st,stih415-powerdown"; + }; + + +Specifying powerdown control of devices +======================================= + +Device nodes should specify the reset channel required in their "resets" +property, containing a phandle to the powerdown device node and an +index specifying which channel to use, as described in reset.txt + +example: + + usb1: usb@fe200000 { + resets = <&powerdown STIH41X_USB1_POWERDOWN>; + }; + +Macro definitions for the supported reset channels can be found in: + +include/dt-bindings/reset-controller/stih415-resets.h +include/dt-bindings/reset-controller/stih416-resets.h diff --git a/Documentation/devicetree/bindings/reset/st,sti-softreset.txt b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt new file mode 100644 index 0000000..a8d3d3c --- /dev/null +++ b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt @@ -0,0 +1,46 @@ +STMicroelectronics STi family Sysconfig Peripheral SoftReset Controller +============================================================================= + +This binding describes a reset controller device that is used to enable and +disable on-chip peripheral controllers such as USB and SATA, using +"softreset" control bits found in the STi family SoC system configuration +registers. + +The actual action taken when softreset is asserted is hardware dependent. +However, when asserted it may not be possible to access the hardware's +registers and after an assert/deassert sequence the hardware's previous state +may no longer be valid. + +Please refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: +- compatible: Should be "st,<chip>-softreset" example: + "st,stih415-softreset" or "st,stih416-softreset"; +- #reset-cells: 1, see below + +example: + + softreset: softreset-controller { + #reset-cells = <1>; + compatible = "st,stih415-softreset"; + }; + + +Specifying softreset control of devices +======================================= + +Device nodes should specify the reset channel required in their "resets" +property, containing a phandle to the softreset device node and an +index specifying which channel to use, as described in reset.txt + +example: + + ethernet0{ + resets = <&softreset STIH415_ETH0_SOFTRESET>; + }; + +Macro definitions for the supported reset channels can be found in: + +include/dt-bindings/reset-controller/stih415-resets.h +include/dt-bindings/reset-controller/stih416-resets.h diff --git a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt index 31406fd..5c199ee 100644 --- a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt +++ b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt @@ -9,6 +9,9 @@ Required properties: - interrupts: rtc alarm/event interrupt - #clock-cells: the value should be 0 +Optional properties: +- clock-output-names: From common clock binding + Example: hym8563: hym8563@51 { diff --git a/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt b/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt index 7cb9dbf..6983aad 100644 --- a/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt +++ b/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt @@ -3,7 +3,7 @@ RTC controller for the Allwinner A10/A20 Required properties: -- compatible : Should be "allwinner,sun4i-rtc" or "allwinner,sun7i-a20-rtc" +- compatible : Should be "allwinner,sun4i-a10-rtc" or "allwinner,sun7i-a20-rtc" - reg: physical base address of the controller and length of memory mapped region. - interrupts: IRQ line for the RTC. @@ -11,7 +11,7 @@ Required properties: Example: rtc: rtc@01c20d00 { - compatible = "allwinner,sun4i-rtc"; + compatible = "allwinner,sun4i-a10-rtc"; reg = <0x01c20d00 0x20>; interrupts = <24>; }; diff --git a/Documentation/devicetree/bindings/rtc/xgene-rtc.txt b/Documentation/devicetree/bindings/rtc/xgene-rtc.txt new file mode 100644 index 0000000..fd195c3 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/xgene-rtc.txt @@ -0,0 +1,28 @@ +* APM X-Gene Real Time Clock + +RTC controller for the APM X-Gene Real Time Clock + +Required properties: +- compatible : Should be "apm,xgene-rtc" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: IRQ line for the RTC. +- #clock-cells: Should be 1. +- clocks: Reference to the clock entry. + +Example: + +rtcclk: rtcclk { + compatible = "fixed-clock"; + #clock-cells = <1>; + clock-frequency = <100000000>; + clock-output-names = "rtcclk"; +}; + +rtc: rtc@10510000 { + compatible = "apm,xgene-rtc"; + reg = <0x0 0x10510000 0x0 0x400>; + interrupts = <0x0 0x46 0x4>; + #clock-cells = <1>; + clocks = <&rtcclk 0>; +}; diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/serial/atmel-usart.txt index 9c5d19a..a6391e7 100644 --- a/Documentation/devicetree/bindings/serial/atmel-usart.txt +++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt @@ -13,6 +13,9 @@ Required properties: Optional properties: - atmel,use-dma-rx: use of PDC or DMA for receiving data - atmel,use-dma-tx: use of PDC or DMA for transmitting data +- {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD line respectively. + It will use specified PIO instead of the peripheral function pin for the USART feature. + If unsure, don't specify this property. - add dma bindings for dma transfer: - dmas: DMA specifier, consisting of a phandle to DMA controller node, memory peripheral interface and USART DMA channel ID, FIFO configuration. @@ -33,6 +36,12 @@ Example: clock-names = "usart"; atmel,use-dma-rx; atmel,use-dma-tx; + rts-gpios = <&pioD 15 GPIO_ACTIVE_LOW>; + cts-gpios = <&pioD 16 GPIO_ACTIVE_LOW>; + dtr-gpios = <&pioD 17 GPIO_ACTIVE_LOW>; + dsr-gpios = <&pioD 18 GPIO_ACTIVE_LOW>; + dcd-gpios = <&pioD 20 GPIO_ACTIVE_LOW>; + rng-gpios = <&pioD 19 GPIO_ACTIVE_LOW>; }; - use DMA: diff --git a/Documentation/devicetree/bindings/serial/efm32-uart.txt b/Documentation/devicetree/bindings/serial/efm32-uart.txt index 1984bdf..8adbab2 100644 --- a/Documentation/devicetree/bindings/serial/efm32-uart.txt +++ b/Documentation/devicetree/bindings/serial/efm32-uart.txt @@ -1,20 +1,20 @@ * Energymicro efm32 UART Required properties: -- compatible : Should be "efm32,uart" +- compatible : Should be "energymicro,efm32-uart" - reg : Address and length of the register set - 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 Example: uart@0x4000c400 { - compatible = "efm32,uart"; + 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 a1d1205..c95005e 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/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt new file mode 100644 index 0000000..246c795 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt @@ -0,0 +1,33 @@ +* NXP SC16IS7xx advanced Universal Asynchronous Receiver-Transmitter (UART) + +Required properties: +- compatible: Should be one of the following: + - "nxp,sc16is740" for NXP SC16IS740, + - "nxp,sc16is741" for NXP SC16IS741, + - "nxp,sc16is750" for NXP SC16IS750, + - "nxp,sc16is752" for NXP SC16IS752, + - "nxp,sc16is760" for NXP SC16IS760, + - "nxp,sc16is762" for NXP SC16IS762. +- reg: I2C address of the SC16IS7xx device. +- interrupt-parent: The phandle for the interrupt controller that + services interrupts for this IC. +- interrupts: Should contain the UART interrupt +- clocks: Reference to the IC source clock. + +Optional properties: +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells: Should be two. The first cell is the GPIO number and + the second cell is used to specify the GPIO polarity: + 0 = active high, + 1 = active low. + +Example: + sc16is750: sc16is750@51 { + compatible = "nxp,sc16is750"; + reg = <0x51>; + clocks = <&clk20m>; + interrupt-parent = <&gpio3>; + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt b/Documentation/devicetree/bindings/serial/of-serial.txt index 1928a3e..7705477 100644 --- a/Documentation/devicetree/bindings/serial/of-serial.txt +++ b/Documentation/devicetree/bindings/serial/of-serial.txt @@ -37,6 +37,7 @@ Optional properties: - auto-flow-control: one way to enable automatic flow control support. The driver is allowed to detect support for the capability even without this property. +- has-hw-flow-control: the hardware has flow control capability. Example: diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index 53e6c17..b355660 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -4,6 +4,14 @@ Required properties: - compatible: Must contain one of the following: + - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. + - "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible UART. + - "renesas,scifa-r8a73a4" for R8A73A4 (R-Mobile APE6) SCIFA compatible UART. + - "renesas,scifb-r8a73a4" for R8A73A4 (R-Mobile APE6) SCIFB compatible UART. + - "renesas,scifa-r8a7740" for R8A7740 (R-Mobile A1) SCIFA compatible UART. + - "renesas,scifb-r8a7740" for R8A7740 (R-Mobile A1) SCIFB compatible UART. + - "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART. + - "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART. - "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART. - "renesas,scifa-r8a7790" for R8A7790 (R-Car H2) SCIFA compatible UART. - "renesas,scifb-r8a7790" for R8A7790 (R-Car H2) SCIFB compatible UART. diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.txt b/Documentation/devicetree/bindings/serial/samsung_uart.txt index 2c8a17c..e85f37e 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 f13f1c5..7f76214 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/soc/qcom/qcom,gsbi.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt new file mode 100644 index 0000000..4ce24d4 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt @@ -0,0 +1,78 @@ +QCOM GSBI (General Serial Bus Interface) Driver + +The GSBI controller is modeled as a node with zero or more child nodes, each +representing a serial sub-node device that is mux'd as part of the GSBI +configuration settings. The mode setting will govern the input/output mode of +the 4 GSBI IOs. + +Required properties: +- compatible: must contain "qcom,gsbi-v1.0.0" for APQ8064/IPQ8064 +- reg: Address range for GSBI registers +- clocks: required clock +- clock-names: must contain "iface" entry +- qcom,mode : indicates MUX value for configuration of the serial interface. + Please reference dt-bindings/soc/qcom,gsbi.h for valid mux values. + +Optional properties: +- qcom,crci : indicates CRCI MUX value for QUP CRCI ports. Please reference + dt-bindings/soc/qcom,gsbi.h for valid CRCI mux values. + +Required properties if child node exists: +- #address-cells: Must be 1 +- #size-cells: Must be 1 +- ranges: Must be present + +Properties for children: + +A GSBI controller node can contain 0 or more child nodes representing serial +devices. These serial devices can be a QCOM UART, I2C controller, spi +controller, or some combination of aforementioned devices. + +See the following for child node definitions: +Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt +Documentation/devicetree/bindings/spi/qcom,spi-qup.txt +Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt + +Example for APQ8064: + +#include <dt-bindings/soc/qcom,gsbi.h> + + gsbi4@16300000 { + compatible = "qcom,gsbi-v1.0.0"; + reg = <0x16300000 0x100>; + clocks = <&gcc GSBI4_H_CLK>; + clock-names = "iface"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + qcom,mode = <GSBI_PROT_I2C_UART>; + qcom,crci = <GSBI_CRCI_QUP>; + + /* child nodes go under here */ + + i2c_qup4: i2c@16380000 { + compatible = "qcom,i2c-qup-v1.1.1"; + reg = <0x16380000 0x1000>; + interrupts = <0 153 0>; + + clocks = <&gcc GSBI4_QUP_CLK>, <&gcc GSBI4_H_CLK>; + clock-names = "core", "iface"; + + clock-frequency = <200000>; + + #address-cells = <1>; + #size-cells = <0>; + + }; + + uart4: serial@16340000 { + compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm"; + reg = <0x16340000 0x1000>, + <0x16300000 0x1000>; + interrupts = <0 152 0x0>; + clocks = <&gcc GSBI4_UART_CLK>, <&gcc GSBI4_H_CLK>; + clock-names = "core", "iface"; + status = "ok"; + }; + }; + diff --git a/Documentation/devicetree/bindings/sound/ak4104.txt b/Documentation/devicetree/bindings/sound/ak4104.txt index b902ee3..deca5e1 100644 --- a/Documentation/devicetree/bindings/sound/ak4104.txt +++ b/Documentation/devicetree/bindings/sound/ak4104.txt @@ -8,6 +8,8 @@ Required properties: - reg : The chip select number on the SPI bus + - vdd-supply : A regulator node, providing 2.7V - 3.6V + Optional properties: - reset-gpio : a GPIO spec for the reset pin. If specified, it will be @@ -19,4 +21,5 @@ spdif: ak4104@0 { compatible = "asahi-kasei,ak4104"; reg = <0>; spi-max-frequency = <5000000>; + vdd-supply = <&vdd_3v3_reg>; }; diff --git a/Documentation/devicetree/bindings/sound/ak5386.txt b/Documentation/devicetree/bindings/sound/ak5386.txt index dc3914f..ec3df3a 100644 --- a/Documentation/devicetree/bindings/sound/ak5386.txt +++ b/Documentation/devicetree/bindings/sound/ak5386.txt @@ -10,10 +10,14 @@ Optional properties: - reset-gpio : a GPIO spec for the reset/power down pin. If specified, it will be deasserted at probe time. + - va-supply : a regulator spec, providing 5.0V + - vd-supply : a regulator spec, providing 3.3V Example: spdif: ak5386@0 { compatible = "asahi-kasei,ak5386"; reset-gpio = <&gpio0 23>; + va-supply = <&vdd_5v0_reg>; + vd-supply = <&vdd_3v3_reg>; }; diff --git a/Documentation/devicetree/bindings/sound/alc5623.txt b/Documentation/devicetree/bindings/sound/alc5623.txt new file mode 100644 index 0000000..26c86c9 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/alc5623.txt @@ -0,0 +1,25 @@ +ALC5621/ALC5622/ALC5623 audio Codec + +Required properties: + + - compatible: "realtek,alc5623" + - reg: the I2C address of the device. + +Optional properties: + + - add-ctrl: Default register value for Reg-40h, Additional Control + Register. If absent or has the value of 0, the + register is untouched. + + - jack-det-ctrl: Default register value for Reg-5Ah, Jack Detect + Control Register. If absent or has value 0, the + register is untouched. + +Example: + + alc5621: alc5621@1a { + compatible = "alc5621"; + reg = <0x1a>; + add-ctrl = <0x3700>; + jack-det-ctrl = <0x4810>; + }; diff --git a/Documentation/devicetree/bindings/sound/cs4265.txt b/Documentation/devicetree/bindings/sound/cs4265.txt new file mode 100644 index 0000000..380fff8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cs4265.txt @@ -0,0 +1,29 @@ +CS4265 audio CODEC + +This device supports I2C only. + +Required properties: + + - compatible : "cirrus,cs4265" + + - reg : the I2C address of the device for I2C. The I2C address depends on + the state of the AD0 pin. If AD0 is high, the i2c address is 0x4f. + If it is low, the i2c address is 0x4e. + +Optional properties: + + - reset-gpios : a GPIO spec for the reset pin. If specified, it will be + deasserted before communication to the codec starts. + +Examples: + +codec_ad0_high: cs4265@4f { /* AD0 Pin is high */ + compatible = "cirrus,cs4265"; + reg = <0x4f>; +}; + + +codec_ad0_low: cs4265@4e { /* AD0 Pin is low */ + compatible = "cirrus,cs4265"; + reg = <0x4e>; +}; diff --git a/Documentation/devicetree/bindings/sound/cs42l56.txt b/Documentation/devicetree/bindings/sound/cs42l56.txt new file mode 100644 index 0000000..4feb0eb --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cs42l56.txt @@ -0,0 +1,63 @@ +CS42L52 audio CODEC + +Required properties: + + - compatible : "cirrus,cs42l56" + + - reg : the I2C address of the device for I2C + + - VA-supply, VCP-supply, VLDO-supply : power supplies for the device, + as covered in Documentation/devicetree/bindings/regulator/regulator.txt. + +Optional properties: + + - cirrus,gpio-nreset : GPIO controller's phandle and the number + of the GPIO used to reset the codec. + + - cirrus,chgfreq-divisor : Values used to set the Charge Pump Frequency. + Allowable values of 0x00 through 0x0F. These are raw values written to the + register, not the actual frequency. The frequency is determined by the following. + Frequency = MCLK / 4 * (N+2) + N = chgfreq_val + MCLK = Where MCLK is the frequency of the mclk signal after the MCLKDIV2 circuit. + + - cirrus,ain1a-ref-cfg, ain1b-ref-cfg : boolean, If present, AIN1A or AIN1B are configured + as a pseudo-differential input referenced to AIN1REF/AIN3A. + + - cirrus,ain2a-ref-cfg, ain2b-ref-cfg : boolean, If present, AIN2A or AIN2B are configured + as a pseudo-differential input referenced to AIN2REF/AIN3B. + + - cirrus,micbias-lvl: Set the output voltage level on the MICBIAS Pin. + 0 = 0.5 x VA + 1 = 0.6 x VA + 2 = 0.7 x VA + 3 = 0.8 x VA + 4 = 0.83 x VA + 5 = 0.91 x VA + + - cirrus,adaptive-pwr-cfg : Configures how the power to the Headphone and Lineout + Amplifiers adapt to the output signal levels. + 0 = Adapt to Volume Mode. Voltage level determined by the sum of the relevant volume settings. + 1 = Fixed - Headphone and Line Amp supply = + or - VCP/2. + 2 = Fixed - Headphone and Line Amp supply = + or - VCP. + 3 = Adapted to Signal; Voltage level is dynamically determined by the output signal. + + - cirrus,hpf-left-freq, hpf-right-freq : Sets the corner frequency (-3dB point) for the internal High-Pass + Filter. + 0 = 1.8Hz + 1 = 119Hz + 2 = 236Hz + 3 = 464Hz + + +Example: + +codec: codec@4b { + compatible = "cirrus,cs42l56"; + reg = <0x4b>; + gpio-reset = <&gpio 10 0>; + cirrus,chgfreq-divisor = <0x05>; + cirrus.ain1_ref_cfg; + cirrus,micbias-lvl = <5>; + VA-supply = <®_audio>; +}; diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt index 569b26c4..60ca079 100644 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt @@ -47,7 +47,7 @@ mcasp0: mcasp0@1d00000 { reg = <0x100000 0x3000>; reg-names "mpu"; interrupts = <82>, <83>; - interrupts-names = "tx", "rx"; + interrupt-names = "tx", "rx"; op-mode = <0>; /* MCASP_IIS_MODE */ tdm-slots = <2>; serial-dir = < diff --git a/Documentation/devicetree/bindings/sound/fsl,asrc.txt b/Documentation/devicetree/bindings/sound/fsl,asrc.txt new file mode 100644 index 0000000..b93362a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,asrc.txt @@ -0,0 +1,60 @@ +Freescale Asynchronous Sample Rate Converter (ASRC) Controller + +The Asynchronous Sample Rate Converter (ASRC) converts the sampling rate of a +signal associated with an input clock into a signal associated with a different +output clock. The driver currently works as a Front End of DPCM with other Back +Ends Audio controller such as ESAI, SSI and SAI. It has three pairs to support +three substreams within totally 10 channels. + +Required properties: + + - compatible : Contains "fsl,imx35-asrc" or "fsl,imx53-asrc". + + - reg : Offset and length of the register set for the device. + + - interrupts : Contains the spdif interrupt. + + - dmas : Generic dma devicetree binding as described in + Documentation/devicetree/bindings/dma/dma.txt. + + - dma-names : Contains "rxa", "rxb", "rxc", "txa", "txb" and "txc". + + - clocks : Contains an entry for each entry in clock-names. + + - clock-names : Contains the following entries + "mem" Peripheral access clock to access registers. + "ipg" Peripheral clock to driver module. + "asrck_<0-f>" Clock sources for input and output clock. + + - big-endian : If this property is absent, the little endian mode + will be in use as default. Otherwise, the big endian + mode will be in use for all the device registers. + + - fsl,asrc-rate : Defines a mutual sample rate used by DPCM Back Ends. + + - fsl,asrc-width : Defines a mutual sample width used by DPCM Back Ends. + +Example: + +asrc: asrc@02034000 { + compatible = "fsl,imx53-asrc"; + reg = <0x02034000 0x4000>; + interrupts = <0 50 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks 107>, <&clks 107>, <&clks 0>, + <&clks 0>, <&clks 0>, <&clks 0>, <&clks 0>, + <&clks 0>, <&clks 0>, <&clks 0>, <&clks 0>, + <&clks 0>, <&clks 0>, <&clks 0>, <&clks 0>, + <&clks 107>, <&clks 0>, <&clks 0>; + clock-names = "mem", "ipg", "asrck0", + "asrck_1", "asrck_2", "asrck_3", "asrck_4", + "asrck_5", "asrck_6", "asrck_7", "asrck_8", + "asrck_9", "asrck_a", "asrck_b", "asrck_c", + "asrck_d", "asrck_e", "asrck_f"; + dmas = <&sdma 17 23 1>, <&sdma 18 23 1>, <&sdma 19 23 1>, + <&sdma 20 23 1>, <&sdma 21 23 1>, <&sdma 22 23 1>; + dma-names = "rxa", "rxb", "rxc", + "txa", "txb", "txc"; + fsl,asrc-rate = <48000>; + fsl,asrc-width = <16>; + status = "okay"; +}; diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt index b93e9a9..3aa4a8f 100644 --- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt +++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt @@ -20,15 +20,6 @@ Required properties: have. - interrupt-parent: The phandle for the interrupt controller that services interrupts for this device. -- fsl,mode: The operating mode for the SSI interface. - "i2s-slave" - I2S mode, SSI is clock slave - "i2s-master" - I2S mode, SSI is clock master - "lj-slave" - left-justified mode, SSI is clock slave - "lj-master" - l.j. mode, SSI is clock master - "rj-slave" - right-justified mode, SSI is clock slave - "rj-master" - r.j., SSI is clock master - "ac97-slave" - AC97 mode, SSI is clock slave - "ac97-master" - AC97 mode, SSI is clock master - fsl,playback-dma: Phandle to a node for the DMA channel to use for playback of audio. This is typically dictated by SOC design. See the notes below. @@ -47,6 +38,9 @@ Required properties: be connected together, and SRFS and STFS be connected together. This would still allow different sample sizes, but not different sample rates. + - clocks: "ipg" - Required clock for the SSI unit + "baud" - Required clock for SSI master mode. Otherwise this + clock is not used Required are also ac97 link bindings if ac97 is used. See Documentation/devicetree/bindings/sound/soc-ac97link.txt for the necessary @@ -64,6 +58,15 @@ Optional properties: Documentation/devicetree/bindings/dma/dma.txt. - dma-names: Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq is not defined. +- fsl,mode: The operating mode for the SSI interface. + "i2s-slave" - I2S mode, SSI is clock slave + "i2s-master" - I2S mode, SSI is clock master + "lj-slave" - left-justified mode, SSI is clock slave + "lj-master" - l.j. mode, SSI is clock master + "rj-slave" - right-justified mode, SSI is clock slave + "rj-master" - r.j., SSI is clock master + "ac97-slave" - AC97 mode, SSI is clock slave + "ac97-master" - AC97 mode, SSI is clock master Child 'codec' node required properties: - compatible: Compatible list, contains the name of the codec diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt b/Documentation/devicetree/bindings/sound/fsl-sai.txt index 98611a6..0f4e238 100644 --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt @@ -7,10 +7,11 @@ codec/DSP interfaces. Required properties: -- compatible: Compatible list, contains "fsl,vf610-sai". +- compatible: Compatible list, contains "fsl,vf610-sai" or "fsl,imx6sx-sai". - reg: Offset and length of the register set for the device. - clocks: Must contain an entry for each entry in clock-names. -- clock-names : Must include the "sai" entry. +- clock-names : Must include the "bus" for register access and "mclk1" "mclk2" + "mclk3" for bit clock and frame clock providing. - dmas : Generic dma devicetree binding as described in Documentation/devicetree/bindings/dma/dma.txt. - dma-names : Two dmas have to be defined, "tx" and "rx". @@ -30,8 +31,10 @@ sai2: sai@40031000 { reg = <0x40031000 0x1000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_sai2_1>; - clocks = <&clks VF610_CLK_SAI2>; - clock-names = "sai"; + clocks = <&clks VF610_CLK_PLATFORM_BUS>, + <&clks VF610_CLK_SAI2>, + <&clks 0>, <&clks 0>; + clock-names = "bus", "mclk1", "mclk2", "mclk3"; dma-names = "tx", "rx"; dmas = <&edma0 0 VF610_EDMA_MUXID0_SAI2_TX>, <&edma0 0 VF610_EDMA_MUXID0_SAI2_RX>; diff --git a/Documentation/devicetree/bindings/sound/max98090.txt b/Documentation/devicetree/bindings/sound/max98090.txt index e4c8b36..c454e67 100644 --- a/Documentation/devicetree/bindings/sound/max98090.txt +++ b/Documentation/devicetree/bindings/sound/max98090.txt @@ -4,12 +4,18 @@ This device supports I2C only. Required properties: -- compatible : "maxim,max98090". +- compatible : "maxim,max98090" or "maxim,max98091". - reg : The I2C address of the device. - interrupts : The CODEC's interrupt output. +Optional properties: + +- clocks: The phandle of the master clock to the CODEC + +- clock-names: Should be "mclk" + Pins on the device (for linking into audio routes): * MIC1 diff --git a/Documentation/devicetree/bindings/sound/max98095.txt b/Documentation/devicetree/bindings/sound/max98095.txt new file mode 100644 index 0000000..318a4c8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/max98095.txt @@ -0,0 +1,22 @@ +MAX98095 audio CODEC + +This device supports I2C only. + +Required properties: + +- compatible : "maxim,max98095". + +- reg : The I2C address of the device. + +Optional properties: + +- clocks: The phandle of the master clock to the CODEC + +- clock-names: Should be "mclk" + +Example: + +max98095: codec@11 { + compatible = "maxim,max98095"; + reg = <0x11>; +}; diff --git a/Documentation/devicetree/bindings/sound/nokia,rx51.txt b/Documentation/devicetree/bindings/sound/nokia,rx51.txt new file mode 100644 index 0000000..72f93d9 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nokia,rx51.txt @@ -0,0 +1,27 @@ +* Nokia N900 audio setup + +Required properties: +- compatible: Should contain "nokia,n900-audio" +- nokia,cpu-dai: phandle for the McBSP node +- nokia,audio-codec: phandles for the main TLV320AIC3X node and the + auxiliary TLV320AIC3X node (in this order) +- nokia,headphone-amplifier: phandle for the TPA6130A2 node +- tvout-selection-gpios: GPIO for tvout selection +- jack-detection-gpios: GPIO for jack detection +- eci-switch-gpios: GPIO for ECI (Enhancement Control Interface) switch +- speaker-amplifier-gpios: GPIO for speaker amplifier + +Example: + +sound { + compatible = "nokia,n900-audio"; + + nokia,cpu-dai = <&mcbsp2>; + nokia,audio-codec = <&tlv320aic3x>, <&tlv320aic3x_aux>; + nokia,headphone-amplifier = <&tpa6130a2>; + + tvout-selection-gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>; /* 40 */ + jack-detection-gpios = <&gpio6 17 GPIO_ACTIVE_HIGH>; /* 177 */ + eci-switch-gpios = <&gpio6 22 GPIO_ACTIVE_HIGH>; /* 182 */ + speaker-amplifier-gpios = <&twl_gpio 7 GPIO_ACTIVE_HIGH>; +}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt new file mode 100644 index 0000000..b4730c2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt @@ -0,0 +1,28 @@ +NVIDIA Tegra30 HDA controller + +Required properties: +- compatible : "nvidia,tegra30-hda" +- reg : Should contain the HDA registers location and length. +- interrupts : The interrupt from the HDA controller. +- clocks : Must contain an entry for each required entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names : Must include the following entries: hda, hdacodec_2x, hda2hdmi +- resets : Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names : Must include the following entries: hda, hdacodec_2x, hda2hdmi + +Example: + +hda@0,70030000 { + compatible = "nvidia,tegra124-hda", "nvidia,tegra30-hda"; + reg = <0x0 0x70030000 0x0 0x10000>; + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA124_CLK_HDA>, + <&tegra_car TEGRA124_CLK_HDA2HDMI>, + <&tegra_car TEGRA124_CLK_HDA2CODEC_2X>; + clock-names = "hda", "hda2hdmi", "hda2codec_2x"; + resets = <&tegra_car 125>, /* hda */ + <&tegra_car 128>; /* hda2hdmi */ + <&tegra_car 111>, /* hda2codec_2x */ + reset-names = "hda", "hda2hdmi", "hda2codec_2x"; +}; diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index a44e917..aa697ab 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -13,6 +13,9 @@ Required properties: - rcar_sound,src : Should contain SRC feature. The number of SRC subnode should be same as HW. see below for detail. +- rcar_sound,dvc : Should contain DVC feature. + The number of DVC subnode should be same as HW. + see below for detail. - rcar_sound,dai : DAI contents. The number of DAI subnode should be same as HW. see below for detail. @@ -20,6 +23,8 @@ Required properties: SSI subnode properties: - interrupts : Should contain SSI interrupt for PIO transfer - shared-pin : if shared clock pin +- pio-transfer : use PIO transfer mode +- no-busif : BUSIF is not ussed when [mem -> SSI] via DMA case SRC subnode properties: no properties at this point @@ -38,6 +43,11 @@ rcar_sound: rcar_sound@0xffd90000 { <0 0xec540000 0 0x1000>, /* SSIU */ <0 0xec541000 0 0x1280>; /* SSI */ + rcar_sound,dvc { + dvc0: dvc@0 { }; + dvc1: dvc@1 { }; + }; + rcar_sound,src { src0: src@0 { }; src1: src@1 { }; diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt new file mode 100644 index 0000000..6c55fcf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt @@ -0,0 +1,37 @@ +* Rockchip I2S controller + +The I2S bus (Inter-IC sound bus) is a serial link for digital +audio data transfer between devices in the system. + +Required properties: + +- compatible: should be one of the followings + - "rockchip,rk3066-i2s": for rk3066 + - "rockchip,rk3188-i2s", "rockchip,rk3066-i2s": for rk3188 + - "rockchip,rk3288-i2s", "rockchip,rk3066-i2s": for rk3288 +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: should contain the I2S interrupt. +- #address-cells: should be 1. +- #size-cells: should be 0. +- dmas: DMA specifiers for tx and rx dma. See the DMA client binding, + Documentation/devicetree/bindings/dma/dma.txt +- dma-names: should include "tx" and "rx". +- clocks: a list of phandle + clock-specifer pairs, one for each entry in clock-names. +- clock-names: should contain followings: + - "i2s_hclk": clock for I2S BUS + - "i2s_clk" : clock for I2S controller + +Example for rk3288 I2S controller: + +i2s@ff890000 { + compatible = "rockchip,rk3288-i2s", "rockchip,rk3066-i2s"; + reg = <0xff890000 0x10000>; + interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + dmas = <&pdma1 0>, <&pdma1 1>; + dma-names = "rx", "tx"; + clock-names = "i2s_hclk", "i2s_clk"; + clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>; +}; diff --git a/Documentation/devicetree/bindings/sound/rt5640.txt b/Documentation/devicetree/bindings/sound/rt5640.txt index 068a114..bac4d9a 100644 --- a/Documentation/devicetree/bindings/sound/rt5640.txt +++ b/Documentation/devicetree/bindings/sound/rt5640.txt @@ -1,10 +1,10 @@ -RT5640 audio CODEC +RT5640/RT5639 audio CODEC This device supports I2C only. Required properties: -- compatible : "realtek,rt5640". +- compatible : One of "realtek,rt5640" or "realtek,rt5639". - reg : The I2C address of the device. @@ -18,7 +18,7 @@ Optional properties: - realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin. -Pins on the device (for linking into audio routes): +Pins on the device (for linking into audio routes) for RT5639/RT5640: * DMIC1 * DMIC2 @@ -31,13 +31,16 @@ Pins on the device (for linking into audio routes): * HPOR * LOUTL * LOUTR - * MONOP - * MONON * SPOLP * SPOLN * SPORP * SPORN +Additional pins on the device for RT5640: + + * MONOP + * MONON + Example: rt5640 { diff --git a/Documentation/devicetree/bindings/sound/samsung,odroidx2-max98090.txt b/Documentation/devicetree/bindings/sound/samsung,odroidx2-max98090.txt new file mode 100644 index 0000000..9148f72 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,odroidx2-max98090.txt @@ -0,0 +1,35 @@ +Samsung Exynos Odroid X2/U3 audio complex with MAX98090 codec + +Required properties: + - compatible : "samsung,odroidx2-audio" - for Odroid X2 board, + "samsung,odroidu3-audio" - for Odroid U3 board + - samsung,model : the user-visible name of this sound complex + - samsung,i2s-controller : the phandle of the I2S controller + - samsung,audio-codec : the phandle of the MAX98090 audio codec + - samsung,audio-routing : a list of the connections between audio + components; each entry is a pair of strings, the first being the + connection's sink, the second being the connection's source; + valid names for sources and sinks are the MAX98090's pins (as + documented in its binding), and the jacks on the board + For Odroid X2: + * Headphone Jack + * Mic Jack + * DMIC + + For Odroid U3: + * Headphone Jack + * Speakers + +Example: + +sound { + compatible = "samsung,odroidu3-audio"; + samsung,i2s-controller = <&i2s0>; + samsung,audio-codec = <&max98090>; + samsung,model = "Odroid-X2"; + samsung,audio-routing = + "Headphone Jack", "HPL", + "Headphone Jack", "HPR", + "IN1", "Mic Jack", + "Mic Jack", "MICBIAS"; +}; diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index 131aa2a..c2e9841 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -1,6 +1,6 @@ Simple-Card: -Simple-Card specifies audio DAI connection of SoC <-> codec. +Simple-Card specifies audio DAI connections of SoC <-> codec. Required properties: @@ -10,26 +10,54 @@ Optional properties: - simple-audio-card,name : User specified audio sound card name, one string property. -- simple-audio-card,format : CPU/CODEC common audio format. - "i2s", "right_j", "left_j" , "dsp_a" - "dsp_b", "ac97", "pdm", "msb", "lsb" - simple-audio-card,widgets : Please refer to widgets.txt. - simple-audio-card,routing : A list of the connections between audio components. Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. -- dai-tdm-slot-num : Please refer to tdm-slot.txt. -- dai-tdm-slot-width : Please refer to tdm-slot.txt. +- simple-audio-card,mclk-fs : Multiplication factor between stream rate and codec + mclk. + +Optional subnodes: + +- simple-audio-card,dai-link : Container for dai-link level + properties and the CPU and CODEC + sub-nodes. This container may be + omitted when the card has only one + DAI link. See the examples and the + section bellow. + +Dai-link subnode properties and subnodes: + +If dai-link subnode is omitted and the subnode properties are directly +under "sound"-node the subnode property and subnode names have to be +prefixed with "simple-audio-card,"-prefix. -Required subnodes: +Required dai-link subnodes: -- simple-audio-card,dai-link : container for the CPU and CODEC sub-nodes - This container may be omitted when the - card has only one DAI link. - See the examples. +- cpu : CPU sub-node +- codec : CODEC sub-node -- simple-audio-card,cpu : CPU sub-node -- simple-audio-card,codec : CODEC sub-node +Optional dai-link subnode properties: + +- format : CPU/CODEC common audio format. + "i2s", "right_j", "left_j" , "dsp_a" + "dsp_b", "ac97", "pdm", "msb", "lsb" +- frame-master : Indicates dai-link frame master. + phandle to a cpu or codec subnode. +- bitclock-master : Indicates dai-link bit clock master. + phandle to a cpu or codec subnode. +- bitclock-inversion : bool property. Add this if the + dai-link uses bit clock inversion. +- frame-inversion : bool property. Add this if the + dai-link uses frame clock inversion. + +For backward compatibility the frame-master and bitclock-master +properties can be used as booleans in codec subnode to indicate if the +codec is the dai-link frame or bit clock master. In this case there +should be no dai-link node, the same properties should not be present +at sound-node level, and the bitclock-inversion and frame-inversion +properties should also be placed in the codec node if needed. Required CPU/CODEC subnodes properties: @@ -37,29 +65,21 @@ Required CPU/CODEC subnodes properties: Optional CPU/CODEC subnodes properties: -- format : CPU/CODEC specific audio format if needed. - see simple-audio-card,format -- frame-master : bool property. add this if subnode is frame master -- bitclock-master : bool property. add this if subnode is bitclock master -- bitclock-inversion : bool property. add this if subnode has clock inversion -- frame-inversion : bool property. add this if subnode has frame inversion +- dai-tdm-slot-num : Please refer to tdm-slot.txt. +- dai-tdm-slot-width : Please refer to tdm-slot.txt. - clocks / system-clock-frequency : specify subnode's clock if needed. it can be specified via "clocks" if system has clock node (= common clock), or "system-clock-frequency" (if system doens't support common clock) -Note: - * For 'format', 'frame-master', 'bitclock-master', 'bitclock-inversion' and - 'frame-inversion', the simple card will use the settings of CODEC for both - CPU and CODEC sides as we need to keep the settings identical for both ends - of the link. - Example 1 - single DAI link: sound { compatible = "simple-audio-card"; simple-audio-card,name = "VF610-Tower-Sound-Card"; simple-audio-card,format = "left_j"; + simple-audio-card,bitclock-master = <&dailink0_master>; + simple-audio-card,frame-master = <&dailink0_master>; simple-audio-card,widgets = "Microphone", "Microphone Jack", "Headphone", "Headphone Jack", @@ -69,17 +89,12 @@ sound { "Headphone Jack", "HP_OUT", "External Speaker", "LINE_OUT"; - dai-tdm-slot-num = <2>; - dai-tdm-slot-width = <8>; - simple-audio-card,cpu { sound-dai = <&sh_fsi2 0>; }; - simple-audio-card,codec { + dailink0_master: simple-audio-card,codec { sound-dai = <&ak4648>; - bitclock-master; - frame-master; clocks = <&osc>; }; }; @@ -105,31 +120,31 @@ Example 2 - many DAI links: sound { compatible = "simple-audio-card"; simple-audio-card,name = "Cubox Audio"; - simple-audio-card,format = "i2s"; simple-audio-card,dai-link@0 { /* I2S - HDMI */ - simple-audio-card,cpu { + format = "i2s"; + cpu { sound-dai = <&audio1 0>; }; - simple-audio-card,codec { + codec { sound-dai = <&tda998x 0>; }; }; simple-audio-card,dai-link@1 { /* S/PDIF - HDMI */ - simple-audio-card,cpu { + cpu { sound-dai = <&audio1 1>; }; - simple-audio-card,codec { + codec { sound-dai = <&tda998x 1>; }; }; simple-audio-card,dai-link@2 { /* S/PDIF - S/PDIF */ - simple-audio-card,cpu { + cpu { sound-dai = <&audio1 1>; }; - simple-audio-card,codec { + codec { sound-dai = <&spdif_codec>; }; }; diff --git a/Documentation/devicetree/bindings/sound/sirf-usp.txt b/Documentation/devicetree/bindings/sound/sirf-usp.txt new file mode 100644 index 0000000..02f85b3 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/sirf-usp.txt @@ -0,0 +1,27 @@ +* SiRF SoC USP module + +Required properties: +- compatible: "sirf,prima2-usp-pcm" +- reg: Base address and size entries: +- dmas: List of DMA controller phandle and DMA request line ordered pairs. +- dma-names: Identifier string for each DMA request line in the dmas property. + These strings correspond 1:1 with the ordered pairs in dmas. + + One of the DMA channels will be responsible for transmission (should be + named "tx") and one for reception (should be named "rx"). + +- clocks: USP controller clock source +- pinctrl-names: Must contain a "default" entry. +- pinctrl-NNN: One property must exist for each entry in pinctrl-names. + +Example: +usp0: usp@b0080000 { + compatible = "sirf,prima2-usp-pcm"; + reg = <0xb0080000 0x10000>; + clocks = <&clks 28>; + dmas = <&dmac1 1>, <&dmac1 2>; + dma-names = "rx", "tx"; + pinctrl-names = "default"; + pinctrl-0 = <&usp0_only_utfs_pins_a>; +}; + diff --git a/Documentation/devicetree/bindings/sound/snow.txt b/Documentation/devicetree/bindings/sound/snow.txt new file mode 100644 index 0000000..6df74f1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/snow.txt @@ -0,0 +1,22 @@ +Audio Binding for Snow boards + +Required properties: +- compatible : Can be one of the following, + "google,snow-audio-max98090" or + "google,snow-audio-max98091" or + "google,snow-audio-max98095" +- samsung,i2s-controller: The phandle of the Samsung I2S controller +- samsung,audio-codec: The phandle of the audio codec + +Optional: +- samsung,model: The name of the sound-card + +Example: + +sound { + compatible = "google,snow-audio-max98095"; + + samsung,model = "Snow-I2S-MAX98095"; + samsung,i2s-controller = <&i2s0>; + samsung,audio-codec = <&max98095>; +}; diff --git a/Documentation/devicetree/bindings/sound/st,sta350.txt b/Documentation/devicetree/bindings/sound/st,sta350.txt new file mode 100644 index 0000000..b7e71bf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/st,sta350.txt @@ -0,0 +1,131 @@ +STA350 audio CODEC + +The driver for this device only supports I2C. + +Required properties: + + - compatible: "st,sta350" + - reg: the I2C address of the device for I2C + - reset-gpios: a GPIO spec for the reset pin. If specified, it will be + deasserted before communication to the codec starts. + + - power-down-gpios: a GPIO spec for the power down pin. If specified, + it will be deasserted before communication to the codec + starts. + + - vdd-dig-supply: regulator spec, providing 3.3V + - vdd-pll-supply: regulator spec, providing 3.3V + - vcc-supply: regulator spec, providing 5V - 26V + +Optional properties: + + - st,output-conf: number, Selects the output configuration: + 0: 2-channel (full-bridge) power, 2-channel data-out + 1: 2 (half-bridge). 1 (full-bridge) on-board power + 2: 2 Channel (Full-Bridge) Power, 1 Channel FFX + 3: 1 Channel Mono-Parallel + If parameter is missing, mode 0 will be enabled. + This property has to be specified as '/bits/ 8' value. + + - st,ch1-output-mapping: Channel 1 output mapping + - st,ch2-output-mapping: Channel 2 output mapping + - st,ch3-output-mapping: Channel 3 output mapping + 0: Channel 1 + 1: Channel 2 + 2: Channel 3 + If parameter is missing, channel 1 is choosen. + This properties have to be specified as '/bits/ 8' values. + + - st,thermal-warning-recover: + If present, thermal warning recovery is enabled. + + - st,thermal-warning-adjustment: + If present, thermal warning adjustment is enabled. + + - st,fault-detect-recovery: + If present, then fault recovery will be enabled. + + - st,ffx-power-output-mode: string + The FFX power output mode selects how the FFX output timing is + configured. Must be one of these values: + - "drop-compensation" + - "tapered-compensation" + - "full-power-mode" + - "variable-drop-compensation" (default) + + - st,drop-compensation-ns: number + Only required for "st,ffx-power-output-mode" == + "variable-drop-compensation". + Specifies the drop compensation in nanoseconds. + The value must be in the range of 0..300, and only + multiples of 20 are allowed. Default is 140ns. + + - st,overcurrent-warning-adjustment: + If present, overcurrent warning adjustment is enabled. + + - st,max-power-use-mpcc: + If present, then MPCC bits are used for MPC coefficients, + otherwise standard MPC coefficients are used. + + - st,max-power-corr: + If present, power bridge correction for THD reduction near maximum + power output is enabled. + + - st,am-reduction-mode: + If present, FFX mode runs in AM reduction mode, otherwise normal + FFX mode is used. + + - st,odd-pwm-speed-mode: + If present, PWM speed mode run on odd speed mode (341.3 kHz) on all + channels. If not present, normal PWM spped mode (384 kHz) will be used. + + - st,distortion-compensation: + If present, distortion compensation variable uses DCC coefficient. + If not present, preset DC coefficient is used. + + - st,invalid-input-detect-mute: + If present, automatic invalid input detect mute is enabled. + + - st,activate-mute-output: + If present, a mute output will be activated in ase the volume will + reach a value lower than -76 dBFS. + + - st,bridge-immediate-off: + If present, the bridge will be switched off immediately after the + power-down-gpio goes low. Otherwise, the bridge will wait for 13 + million clock cycles to pass before shutting down. + + - st,noise-shape-dc-cut: + If present, the noise-shaping technique on the DC cutoff filter are + enabled. + + - st,powerdown-master-volume: + If present, the power-down pin and I2C power-down functions will + act on the master volume. Otherwise, the functions will act on the + mute commands. + + - st,powerdown-delay-divider: + If present, the bridge power-down time will be divided by the provided + value. If not specified, a divider of 1 will be used. Allowed values + are 1, 2, 4, 8, 16, 32, 64 and 128. + This property has to be specified as '/bits/ 8' value. + +Example: + +codec: sta350@38 { + compatible = "st,sta350"; + reg = <0x1c>; + reset-gpios = <&gpio1 19 0>; + power-down-gpios = <&gpio1 16 0>; + st,output-conf = /bits/ 8 <0x3>; // set output to 2-channel + // (full-bridge) power, + // 2-channel data-out + st,ch1-output-mapping = /bits/ 8 <0>; // set channel 1 output ch 1 + st,ch2-output-mapping = /bits/ 8 <0>; // set channel 2 output ch 1 + st,ch3-output-mapping = /bits/ 8 <0>; // set channel 3 output ch 1 + st,max-power-correction; // enables power bridge + // correction for THD reduction + // near maximum power output + st,invalid-input-detect-mute; // mute if no valid digital + // audio signal is provided. +}; diff --git a/Documentation/devicetree/bindings/sound/tas2552.txt b/Documentation/devicetree/bindings/sound/tas2552.txt new file mode 100644 index 0000000..55e2a0a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tas2552.txt @@ -0,0 +1,26 @@ +Texas Instruments - tas2552 Codec module + +The tas2552 serial control bus communicates through I2C protocols + +Required properties: + - compatible - One of: + "ti,tas2552" - TAS2552 + - reg - I2C slave address + - supply-*: Required supply regulators are: + "vbat" battery voltage + "iovdd" I/O Voltage + "avdd" Analog DAC Voltage + +Optional properties: + - enable-gpio - gpio pin to enable/disable the device + +Example: + +tas2552: tas2552@41 { + compatible = "ti,tas2552"; + reg = <0x41>; + enable-gpio = <&gpio4 2 GPIO_ACTIVE_HIGH>; +}; + +For more product information please see the link below: +http://www.ti.com/product/TAS2552 diff --git a/Documentation/devicetree/bindings/sound/ti,tas5086.txt b/Documentation/devicetree/bindings/sound/ti,tas5086.txt index d2866a0..234dad2 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas5086.txt +++ b/Documentation/devicetree/bindings/sound/ti,tas5086.txt @@ -31,6 +31,9 @@ Optional properties: Most systems should not set any of these properties. + - avdd-supply: Power supply for AVDD, providing 3.3V + - dvdd-supply: Power supply for DVDD, providing 3.3V + Examples: i2c_bus { @@ -39,5 +42,7 @@ Examples: reg = <0x1b>; reset-gpio = <&gpio 23 0>; ti,charge-period = <156000>; + avdd-supply = <&vdd_3v3_reg>; + dvdd-supply = <&vdd_3v3_reg>; }; }; diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt index 74c66de..eff12be 100644 --- a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt +++ b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt @@ -13,6 +13,9 @@ Required properties: "ti,tlv320aic3111" - TLV320AIC3111 (stereo speaker amp, MiniDSP) - reg - <int> - I2C slave address +- HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply, + DVDD-supply : power supplies for the device as covered in + Documentation/devicetree/bindings/regulator/regulator.txt Optional properties: @@ -24,9 +27,6 @@ Optional properties: 3 or MICBIAS_AVDD - MICBIAS output is connected to AVDD If this node is not mentioned or if the value is unknown, then micbias is set to 2.0V. -- HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply, - DVDD-supply : power supplies for the device as covered in - Documentation/devicetree/bindings/regulator/regulator.txt CODEC output pins: * HPL diff --git a/Documentation/devicetree/bindings/sound/wm8904.txt b/Documentation/devicetree/bindings/sound/wm8904.txt new file mode 100644 index 0000000..e99f409 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wm8904.txt @@ -0,0 +1,33 @@ +WM8904 audio CODEC + +This device supports I2C only. + +Required properties: + - compatible: "wlf,wm8904" + - reg: the I2C address of the device. + - clock-names: "mclk" + - clocks: reference to + <Documentation/devicetree/bindings/clock/clock-bindings.txt> + +Pins on the device (for linking into audio routes): + + * IN1L + * IN1R + * IN2L + * IN2R + * IN3L + * IN3R + * HPOUTL + * HPOUTR + * LINEOUTL + * LINEOUTR + * MICBIAS + +Examples: + +codec: wm8904@1a { + compatible = "wlf,wm8904"; + reg = <0x1a>; + clocks = <&pck0>; + clock-names = "mclk"; +}; diff --git a/Documentation/devicetree/bindings/spi/efm32-spi.txt b/Documentation/devicetree/bindings/spi/efm32-spi.txt index 8f081c9..750e29a 100644 --- a/Documentation/devicetree/bindings/spi/efm32-spi.txt +++ b/Documentation/devicetree/bindings/spi/efm32-spi.txt @@ -8,7 +8,14 @@ Required properties: - interrupts: pair specifying rx and tx irq - clocks: phandle to the spi clock - cs-gpios: see spi-bus.txt -- efm32,location: Value to write to the ROUTE register's LOCATION bitfield to configure the pinmux for the device, see datasheet for values. + +Recommended properties : +- 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: @@ -20,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/fsl-spi.txt b/Documentation/devicetree/bindings/spi/fsl-spi.txt index b032dd7..a233137 100644 --- a/Documentation/devicetree/bindings/spi/fsl-spi.txt +++ b/Documentation/devicetree/bindings/spi/fsl-spi.txt @@ -42,6 +42,10 @@ Required properties: - interrupts : should contain eSPI interrupt, the device has one interrupt. - fsl,espi-num-chipselects : the number of the chipselect signals. +Optional properties: +- fsl,csbef: chip select assertion time in bits before frame starts +- fsl,csaft: chip select negation time in bits after frame ends + Example: spi@110000 { #address-cells = <1>; @@ -51,4 +55,6 @@ Example: interrupts = <53 0x2>; interrupt-parent = <&mpic>; fsl,espi-num-chipselects = <4>; + fsl,csbef = <1>; + fsl,csaft = <1>; }; diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt index b82a268..e2c88df 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 @@ -23,6 +27,12 @@ Optional properties: - spi-max-frequency: Specifies maximum SPI clock frequency, Units - Hz. Definition as per Documentation/devicetree/bindings/spi/spi-bus.txt +- num-cs: total number of chipselects +- cs-gpios: should specify GPIOs used for chipselects. + The gpios will be referred to as reg = <index> in the SPI child + nodes. If unspecified, a single SPI device without a chip + select can be used. + SPI slave nodes must be children of the SPI master node and can contain properties described in Documentation/devicetree/bindings/spi/spi-bus.txt 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 0000000..bd99193 --- /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-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index cc128ae..bbaa857 100644 --- a/Documentation/devicetree/bindings/spi/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt @@ -55,6 +55,8 @@ contain the following properties. chip select active high - spi-3wire - (optional) Empty property indicating device requires 3-wire mode. +- spi-lsb-first - (optional) Empty property indicating device requires + LSB first mode. - spi-tx-bus-width - (optional) The bus width(number of data wires) that used for MOSI. Defaults to 1 if not present. - spi-rx-bus-width - (optional) The bus width(number of data wires) that diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.txt b/Documentation/devicetree/bindings/spi/spi-cadence.txt new file mode 100644 index 0000000..94f0914 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-cadence.txt @@ -0,0 +1,31 @@ +Cadence SPI controller Device Tree Bindings +------------------------------------------- + +Required properties: +- compatible : Should be "cdns,spi-r1p6" or "xlnx,zynq-spi-r1p6". +- reg : Physical base address and size of SPI registers map. +- interrupts : Property with a value describing the interrupt + number. +- interrupt-parent : Must be core interrupt controller +- clock-names : List of input clock names - "ref_clk", "pclk" + (See clock bindings for details). +- clocks : Clock phandles (see clock bindings for details). + +Optional properties: +- num-cs : Number of chip selects used. + If a decoder is used, this will be the number of + chip selects after the decoder. +- is-decoded-cs : Flag to indicate whether decoder is used or not. + +Example: + + spi@e0007000 { + compatible = "xlnx,zynq-spi-r1p6"; + clock-names = "ref_clk", "pclk"; + clocks = <&clkc 26>, <&clkc 35>; + interrupt-parent = <&intc>; + interrupts = <0 49 4>; + num-cs = <4>; + is-decoded-cs = <0>; + reg = <0xe0007000 0x1000>; + } ; diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt b/Documentation/devicetree/bindings/spi/spi-davinci.txt index 6d0ac8d..f80887b 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-dw.txt b/Documentation/devicetree/bindings/spi/spi-dw.txt new file mode 100644 index 0000000..7b63ed6 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-dw.txt @@ -0,0 +1,24 @@ +Synopsys DesignWare SPI master + +Required properties: +- compatible: should be "snps,designware-spi" +- #address-cells: see spi-bus.txt +- #size-cells: see spi-bus.txt +- reg: address and length of the spi master registers +- interrupts: should contain one interrupt +- clocks: spi clock phandle +- num-cs: see spi-bus.txt + +Optional properties: +- cs-gpios: see spi-bus.txt + +Example: + +spi: spi@4020a000 { + compatible = "snps,designware-spi"; + interrupts = <11 1>; + reg = <0x4020a000 0x1000>; + clocks = <&pclk>; + num-cs = <2>; + cs-gpios = <&banka 0 0>; +}; diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt b/Documentation/devicetree/bindings/spi/spi-rockchip.txt new file mode 100644 index 0000000..7bab355 --- /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 86aa061..792efba 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/spmi/spmi.txt b/Documentation/devicetree/bindings/spmi/spmi.txt index 462a42f..4bb10d1 100644 --- a/Documentation/devicetree/bindings/spmi/spmi.txt +++ b/Documentation/devicetree/bindings/spmi/spmi.txt @@ -26,7 +26,7 @@ Each child node must have one and only one 'reg' entry of type SPMI_USID. reg = <...>; #address-cells = <2>; - #size-cells <0>; + #size-cells = <0>; child@0 { compatible = "..."; diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt index 3be5ce7..e75f0e5 100644 --- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt +++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt @@ -61,6 +61,7 @@ Required properties: Optional properties: - interface_pix_fmt: How this display is connected to the display interface. Currently supported types: "rgb24", "rgb565", "bgr666" + and "lvds666". - edid: verbatim EDID data block describing attached display. - ddc: phandle describing the i2c bus handling the display data channel diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt index fff93d5..4cf0249 100644 --- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt @@ -1,11 +1,21 @@ -* Marvell Armada 370/XP thermal management +* Marvell Armada 370/375/380/XP thermal management Required properties: - compatible: Should be set to one of the following: marvell,armada370-thermal + marvell,armada375-thermal + marvell,armada375-z1-thermal + marvell,armada380-thermal marvell,armadaxp-thermal + Note: As the name suggests, "marvell,armada375-z1-thermal" + applies for the SoC Z1 stepping only. On such stepping + some quirks need to be done and the register offset differs + from the one in the A0 stepping. + The operating system may auto-detect the SoC stepping and + update the compatible and register offsets at runtime. + - reg: Device's register space. Two entries are expected, see the examples below. The first one is required for the sensor register; diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt index 284f530..c949092 100644 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt @@ -6,16 +6,35 @@ "samsung,exynos4412-tmu" "samsung,exynos4210-tmu" "samsung,exynos5250-tmu" + "samsung,exynos5260-tmu" + "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420 + "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4 + Exynos5420 (Must pass triminfo base and triminfo clock) "samsung,exynos5440-tmu" - interrupt-parent : The phandle for the interrupt controller - reg : Address range of the thermal registers. For soc's which has multiple instances of TMU and some registers are shared across all TMU's like interrupt related then 2 set of register has to supplied. First set - belongs to each instance of TMU and second set belongs to common TMU - registers. + belongs to register set of TMU instance and second set belongs to + registers shared with the TMU instance. + + NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU + channels 2, 3 and 4 + Use "samsung,exynos5420-tmu-ext-triminfo" in cases, there is a misplaced + register, also provide clock to access that base. + + TRIMINFO at 0x1006c000 contains data for TMU channel 3 + TRIMINFO at 0x100a0000 contains data for TMU channel 4 + TRIMINFO at 0x10068000 contains data for TMU channel 2 + - interrupts : Should contain interrupt for thermal system -- clocks : The main clock for TMU device +- clocks : The main clocks for TMU device + -- 1. operational clock for TMU channel + -- 2. optional clock to access the shared registers of TMU channel - clock-names : Thermal system clock name + -- "tmu_apbif" operational clock for current TMU channel + -- "tmu_triminfo_apbif" clock to access the shared triminfo register + for current TMU channel - vtmu-supply: This entry is optional and provides the regulator node supplying voltage to TMU. If needed this entry can be placed inside board/platform specific dts file. @@ -43,6 +62,31 @@ Example 2): clock-names = "tmu_apbif"; }; +Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register") + tmu_cpu2: tmu@10068000 { + compatible = "samsung,exynos5420-tmu-ext-triminfo"; + reg = <0x10068000 0x100>, <0x1006c000 0x4>; + interrupts = <0 184 0>; + clocks = <&clock 318>, <&clock 318>; + clock-names = "tmu_apbif", "tmu_triminfo_apbif"; + }; + + tmu_cpu3: tmu@1006c000 { + compatible = "samsung,exynos5420-tmu-ext-triminfo"; + reg = <0x1006c000 0x100>, <0x100a0000 0x4>; + interrupts = <0 185 0>; + clocks = <&clock 318>, <&clock 319>; + clock-names = "tmu_apbif", "tmu_triminfo_apbif"; + }; + + tmu_gpu: tmu@100a0000 { + compatible = "samsung,exynos5420-tmu-ext-triminfo"; + reg = <0x100a0000 0x100>, <0x10068000 0x4>; + interrupts = <0 215 0>; + clocks = <&clock 319>, <&clock 318>; + clock-names = "tmu_apbif", "tmu_triminfo_apbif"; + }; + Note: For multi-instance tmu each instance should have an alias correctly numbered in "aliases" node. diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt index 7c26154..27cfc7d 100644 --- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt +++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt @@ -9,6 +9,9 @@ Required properties: one) - clocks: phandle to the source clock (usually the AHB clock) +Optionnal properties: +- resets: phandle to a reset controller asserting the timer + Example: timer@01c60000 { @@ -19,4 +22,5 @@ timer@01c60000 { <0 53 1>, <0 54 1>; clocks = <&ahb1_gates 19>; + resets = <&ahb1rst 19>; }; 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 0000000..cd55b52 --- /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/efm32,timer.txt b/Documentation/devicetree/bindings/timer/energymicro,efm32-timer.txt index 97a568f..e502c11 100644 --- a/Documentation/devicetree/bindings/timer/efm32,timer.txt +++ b/Documentation/devicetree/bindings/timer/energymicro,efm32-timer.txt @@ -6,7 +6,7 @@ channels and can be used as PWM or Quadrature Decoder. Available clock sources are the cpu's HFPERCLK (with a 10-bit prescaler) or an external pin. Required properties: -- compatible : Should be efm32,timer +- compatible : Should be "energymicro,efm32-timer" - reg : Address and length of the register set - clocks : Should contain a reference to the HFPERCLK @@ -16,7 +16,7 @@ Optional properties: Example: timer@40010c00 { - compatible = "efm32,timer"; + compatible = "energymicro,efm32-timer"; reg = <0x40010c00 0x400>; interrupts = <14>; clocks = <&cmu clk_HFPERCLKTIMER3>; diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt new file mode 100644 index 0000000..aa8c402 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt @@ -0,0 +1,31 @@ +Freescale FlexTimer Module (FTM) Timer + +Required properties: + +- compatible : should be "fsl,ftm-timer" +- reg : Specifies base physical address and size of the register sets for the + clock event device and clock source device. +- interrupts : Should be the clock event device interrupt. +- clocks : The clocks provided by the SoC to drive the timer, must contain an + entry for each entry in clock-names. +- clock-names : Must include the following entries: + o "ftm-evt" + o "ftm-src" + o "ftm-evt-counter-en" + o "ftm-src-counter-en" +- big-endian: One boolean property, the big endian mode will be in use if it is + present, or the little endian mode will be in use for all the device registers. + +Example: +ftm: ftm@400b8000 { + compatible = "fsl,ftm-timer"; + reg = <0x400b8000 0x1000 0x400b9000 0x1000>; + interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "ftm-evt", "ftm-src", + "ftm-evt-counter-en", "ftm-src-counter-en"; + clocks = <&clks VF610_CLK_FTM2>, + <&clks VF610_CLK_FTM3>, + <&clks VF610_CLK_FTM2_EXT_FIX_EN>, + <&clks VF610_CLK_FTM3_EXT_FIX_EN>; + big-endian; +}; 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 0000000..7c4408f --- /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 0000000..a17418b --- /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 0000000..917453f --- /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 0000000..425d0c5 --- /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/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt index 55f51af..bc2222c 100644 --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt @@ -57,8 +57,8 @@ Required properties: - ep childnode: To specify the number of endpoints and their properties. Optional properties: - - atmel,vbus-gpio: If present, specifies a gpio that needs to be - activated for the bus to be powered. + - atmel,vbus-gpio: If present, specifies a gpio that allows to detect whether + vbus is present (USB is connected). Required child node properties: - name: Name of the endpoint. diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt index a6a32cb..1bae71e 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/ci-hdrc-qcom.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt new file mode 100644 index 0000000..f2899b5 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt @@ -0,0 +1,17 @@ +Qualcomm CI13xxx (Chipidea) USB controllers + +Required properties: +- compatible: should contain "qcom,ci-hdrc" +- reg: offset and length of the register set in the memory map +- interrupts: interrupt-specifier for the controller interrupt. +- usb-phy: phandle for the PHY device +- dr_mode: Should be "peripheral" + +Examples: + gadget@f9a55000 { + compatible = "qcom,ci-hdrc"; + reg = <0xf9a55000 0x400>; + dr_mode = "peripheral"; + interrupts = <0 134 0>; + usb-phy = <&usbphy0>; + }; diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index b8b6871..467ddd1 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -13,7 +13,7 @@ Refer to clk/clock-bindings.txt for generic clock consumer properties Optional properties: - phys: phy provider specifier -- phy-names: shall be "device" +- phy-names: shall be "usb2-phy" Refer to phy/phy-bindings.txt for generic phy consumer properties Example: diff --git a/Documentation/devicetree/bindings/usb/ehci-omap.txt b/Documentation/devicetree/bindings/usb/ehci-omap.txt index 485a9a1..3dc231c 100644 --- a/Documentation/devicetree/bindings/usb/ehci-omap.txt +++ b/Documentation/devicetree/bindings/usb/ehci-omap.txt @@ -21,7 +21,7 @@ Documentation/devicetree/bindings/mfd/omap-usb-host.txt Example for OMAP4: usbhsehci: ehci@4a064c00 { - compatible = "ti,ehci-omap", "usb-ehci"; + compatible = "ti,ehci-omap"; reg = <0x4a064c00 0x400>; interrupts = <0 77 0x4>; }; diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt b/Documentation/devicetree/bindings/usb/ehci-orion.txt index 6bc09ec..17c3bc8 100644 --- a/Documentation/devicetree/bindings/usb/ehci-orion.txt +++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt @@ -6,6 +6,11 @@ Required properties: region. - interrupts: The EHCI interrupt +Optional properties: +- clocks: reference to the clock +- phys: reference to the USB PHY +- phy-names: name of the USB PHY, should be "usb" + Example: ehci@50000 { diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt index d967ba1..a3b5990 100644 --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt @@ -12,6 +12,13 @@ Required properties: - interrupts: interrupt number to the cpu. - clocks: from common clock binding: handle to usb clock. - clock-names: from common clock binding: Shall be "usbhost". + - port: if in the SoC there are EHCI phys, they should be listed here. + One phy per port. Each port should have following entries: + - reg: port number on EHCI controller, e.g + On Exynos5250, port 0 is USB2.0 otg phy + port 1 is HSIC phy0 + port 2 is HSIC phy1 + - phys: from the *Generic PHY* bindings; specifying phy used by port. Optional properties: - samsung,vbus-gpio: if present, specifies the GPIO that @@ -27,6 +34,14 @@ Example: clocks = <&clock 285>; clock-names = "usbhost"; + + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + phys = <&usb2phy 1>; + status = "disabled"; + }; }; OHCI @@ -38,6 +53,13 @@ Required properties: - interrupts: interrupt number to the cpu. - clocks: from common clock binding: handle to usb clock. - clock-names: from common clock binding: Shall be "usbhost". + - port: if in the SoC there are OHCI phys, they should be listed here. + One phy per port. Each port should have following entries: + - reg: port number on OHCI controller, e.g + On Exynos5250, port 0 is USB2.0 otg phy + port 1 is HSIC phy0 + port 2 is HSIC phy1 + - phys: from the *Generic PHY* bindings, specifying phy used by port. Example: usb@12120000 { @@ -47,6 +69,15 @@ Example: clocks = <&clock 285>; clock-names = "usbhost"; + + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + phys = <&usb2phy 1>; + status = "disabled"; + }; + }; DWC3 diff --git a/Documentation/devicetree/bindings/usb/gr-udc.txt b/Documentation/devicetree/bindings/usb/gr-udc.txt index 0c5118f..e944522 100644 --- a/Documentation/devicetree/bindings/usb/gr-udc.txt +++ b/Documentation/devicetree/bindings/usb/gr-udc.txt @@ -12,17 +12,23 @@ Required properties: - reg : Address and length of the register set for the device -- interrupts : Interrupt numbers for this device +- interrupts : Interrupt numbers for this device. Either one interrupt number + for all interrupts, or one for status related interrupts, one for IN + endpoint related interrupts and one for OUT endpoint related interrupts. Optional properties: -- epobufsizes : An array of buffer sizes for OUT endpoints. If the property is - not present, or for endpoints outside of the array, 1024 is assumed by - the driver. - -- epibufsizes : An array of buffer sizes for IN endpoints. If the property is - not present, or for endpoints outside of the array, 1024 is assumed by - the driver. +- epobufsizes : Array of buffer sizes for OUT endpoints when they differ + from the default size of 1024. The array is indexed by the OUT endpoint + number. If the property is present it typically contains one entry for + each OUT endpoint of the core. Fewer entries overrides the default sizes + only for as many endpoints as the array contains. + +- epibufsizes : Array of buffer sizes for IN endpoints when they differ + from the default size of 1024. The array is indexed by the IN endpoint + number. If the property is present it typically contains one entry for + each IN endpoint of the core. Fewer entries overrides the default sizes + only for as many endpoints as the array contains. For further information look in the documentation for the GLIB IP core library: http://www.gaisler.com/products/grlib/grip.pdf diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt index 5ea26c6..2826f2a 100644 --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt @@ -15,3 +15,81 @@ Example EHCI controller device node: usb-phy = <&usb_otg>; }; +USB PHY with optional OTG: + +Required properties: +- compatible: Should contain: + "qcom,usb-otg-ci" for chipsets with ChipIdea 45nm PHY + "qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY + +- regs: Offset and length of the register set in the memory map +- interrupts: interrupt-specifier for the OTG interrupt. + +- clocks: A list of phandle + clock-specifier pairs for the + clocks listed in clock-names +- clock-names: Should contain the following: + "phy" USB PHY reference clock + "core" Protocol engine clock + "iface" Interface bus clock + "alt_core" Protocol engine clock for targets with asynchronous + reset methodology. (optional) + +- vdccx-supply: phandle to the regulator for the vdd supply for + digital circuit operation. +- v1p8-supply: phandle to the regulator for the 1.8V supply +- v3p3-supply: phandle to the regulator for the 3.3V supply + +- resets: A list of phandle + reset-specifier pairs for the + resets listed in reset-names +- reset-names: Should contain the following: + "phy" USB PHY controller reset + "link" USB LINK controller reset + +- qcom,otg-control: OTG control (VBUS and ID notifications) can be one of + 1 - PHY control + 2 - PMIC control + +Optional properties: +- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg" + +- qcom,phy-init-sequence: PHY configuration sequence values. This is related to Device + Mode Eye Diagram test. Start address at which these values will be + written is ULPI_EXT_VENDOR_SPECIFIC. Value of -1 is reserved as + "do not overwrite default value at this address". + For example: qcom,phy-init-sequence = < -1 0x63 >; + Will update only value at address ULPI_EXT_VENDOR_SPECIFIC + 1. + +- qcom,phy-num: Select number of pyco-phy to use, can be one of + 0 - PHY one, default + 1 - Second PHY + Some platforms may have configuration to allow USB + controller work with any of the two HSPHYs present. + +- qcom,vdd-levels: This property must be a list of three integer values + (no, min, max) where each value represents either a voltage + in microvolts or a value corresponding to voltage corner. + +Example HSUSB OTG controller device node: + + usb@f9a55000 { + compatible = "qcom,usb-otg-snps"; + reg = <0xf9a55000 0x400>; + interrupts = <0 134 0>; + dr_mode = "peripheral"; + + clocks = <&gcc GCC_XO_CLK>, <&gcc GCC_USB_HS_SYSTEM_CLK>, + <&gcc GCC_USB_HS_AHB_CLK>; + + clock-names = "phy", "core", "iface"; + + vddcx-supply = <&pm8841_s2_corner>; + v1p8-supply = <&pm8941_l6>; + v3p3-supply = <&pm8941_l24>; + + resets = <&gcc GCC_USB2A_PHY_BCR>, <&gcc GCC_USB_HS_BCR>; + reset-names = "phy", "link"; + + qcom,otg-control = <1>; + qcom,phy-init-sequence = < -1 0x63 >; + qcom,vdd-levels = <1 5 7>; + }; diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt index ba797d3..c9205fb 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/ohci-omap3.txt b/Documentation/devicetree/bindings/usb/ohci-omap3.txt index 14ab428..ce8c47cff 100644 --- a/Documentation/devicetree/bindings/usb/ohci-omap3.txt +++ b/Documentation/devicetree/bindings/usb/ohci-omap3.txt @@ -9,7 +9,7 @@ Required properties: Example for OMAP4: usbhsohci: ohci@4a064800 { - compatible = "ti,ohci-omap3", "usb-ohci"; + compatible = "ti,ohci-omap3"; reg = <0x4a064800 0x400>; interrupts = <0 76 0x4>; }; diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 38b2fae..38d9bb8 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -44,7 +44,9 @@ Board specific device node entry }; OMAP DWC3 GLUE - - compatible : Should be "ti,dwc3" + - compatible : Should be + * "ti,dwc3" for OMAP5 and DRA7 + * "ti,am437x-dwc3" for AM437x - ti,hwmods : Should be "usb_otg_ss" - reg : Address and length of the register set for the device. - interrupts : The irq number of this device that is used to interrupt the diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt index ff151ec0..43c1a4e 100644 --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt @@ -15,6 +15,7 @@ Optional properties: - clocks : a list of phandle + clock specifier pairs - phys : phandle + phy specifier pair - phy-names : "usb" + - resets : phandle + reset specifier pair Example (Sequoia 440EPx): ehci@e0000300 { diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt index 45f67d9..b968a1a 100644 --- a/Documentation/devicetree/bindings/usb/usb-ohci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt @@ -12,6 +12,7 @@ Optional properties: - clocks : a list of phandle + clock specifier pairs - phys : phandle + phy specifier pair - phy-names : "usb" +- resets : phandle + reset specifier pair Example: diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index 90f8f60..86f67f0 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -1,11 +1,18 @@ USB xHCI controllers Required properties: - - compatible: should be "generic-xhci" (deprecated: "xhci-platform"). + - compatible: should be one of "generic-xhci", + "marvell,armada-375-xhci", "marvell,armada-380-xhci", + "renesas,xhci-r8a7790", "renesas,xhci-r8a7791" (deprecated: + "xhci-platform"). - reg: should contain address and length of the standard XHCI register set for the device. - interrupts: one XHCI interrupt should be described here. +Optional properties: + - clocks: reference to a clock + - usb3-lpm-capable: determines if platform is USB3 LPM capable + Example: usb@f0931000 { compatible = "generic-xhci"; diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt index a018da4..221ac0d 100644 --- a/Documentation/devicetree/bindings/usb/usb3503.txt +++ b/Documentation/devicetree/bindings/usb/usb3503.txt @@ -15,6 +15,14 @@ Optional properties: - reset-gpios: Should specify GPIO for reset. - initial-mode: Should specify initial mode. (1 for HUB mode, 2 for STANDBY mode) +- refclk: Clock used for driving REFCLK signal (optional, if not provided + the driver assumes that clock signal is always available, its + rate is specified by REF_SEL pins and a value from the primary + reference clock frequencies table is used) +- refclk-frequency: Frequency of the REFCLK signal as defined by REF_SEL + pins (optional, if not provided, driver will not set rate of the + REFCLK signal and assume that a value from the primary reference + clock frequencies table is used) Examples: usb3503@08 { diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 95465d5..d415b38 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -13,6 +13,7 @@ allwinner Allwinner Technology Co., Ltd. altr Altera Corp. amcc Applied Micro Circuits Corporation (APM, formally AMCC) amd Advanced Micro Devices (AMD), Inc. +ams AMS AG amstaos AMS-Taos Inc. apm Applied Micro Circuits Corporation (APM) arm ARM Ltd. @@ -22,6 +23,7 @@ auo AU Optronics Corporation avago Avago Technologies bosch Bosch Sensortec GmbH brcm Broadcom Corporation +buffalo Buffalo, Inc. calxeda Calxeda capella Capella Microsystems, Inc cavium Cavium, Inc. @@ -33,13 +35,19 @@ cortina Cortina Systems, Inc. crystalfontz Crystalfontz America, Inc. dallas Maxim Integrated Products (formerly Dallas Semiconductor) davicom DAVICOM Semiconductor, Inc. -dlink D-Link Systems, Inc. denx Denx Software Engineering +digi Digi International Inc. +dlink D-Link Corporation +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 +eukrea Eukréa Electromatique +excito Excito fsl Freescale Semiconductor GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. @@ -51,26 +59,38 @@ haoyu Haoyu Microelectronic Co. Ltd. hisilicon Hisilicon Limited. honeywell Honeywell hp Hewlett Packard +i2se I2SE GmbH ibm International Business Machines (IBM) idt Integrated Device Technologies, Inc. +iom Iomega Corporation img Imagination Technologies Ltd. intel Intel Corporation intercontrol Inter Control Group +isee ISEE 2007 S.L. isl Intersil karo Ka-Ro electronics GmbH +keymile Keymile GmbH lacie LaCie lantiq Lantiq Semiconductor lg LG Corporation linux Linux-specific binding 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. moxa Moxa +mpl MPL AG +mundoreader Mundo Reader S.L. +murata Murata Manufacturing Co., Ltd. +mxicy Macronix International Co., Ltd. national National Semiconductor neonode Neonode Inc. netgear NETGEAR +newhaven Newhaven Display International nintendo Nintendo nokia Nokia nvidia NVIDIA @@ -80,20 +100,27 @@ opencores OpenCores.org panasonic Panasonic Corporation phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd +plathome Plat'Home Co., Ltd. powervr PowerVR (deprecated, use img) qca Qualcomm Atheros, Inc. qcom Qualcomm Technologies, Inc +qnap QNAP Systems, Inc. +radxa Radxa +raidsonic RaidSonic Technology GmbH ralink Mediatek/Ralink Technology Corp. ramtron Ramtron International realtek Realtek Semiconductor Corp. renesas Renesas Electronics Corporation +ricoh Ricoh Co. Ltd. rockchip Fuzhou Rockchip Electronics Co., Ltd samsung Samsung Semiconductor sbs Smart Battery System schindler Schindler +seagate Seagate Technology PLC sil Silicon Image silabs Silicon Laboratories simtek +sii Seiko Instruments, Inc. sirf SiRF Technology, Inc. smsc Standard Microsystems Corporation snps Synopsys, Inc. @@ -101,14 +128,21 @@ spansion Spansion Inc. st STMicroelectronics ste ST-Ericsson stericsson ST-Ericsson +synology Synology, Inc. ti Texas Instruments tlm Trusted Logic Mobility +toradex Toradex AG toshiba Toshiba Corporation toumaz Toumaz +usi Universal Scientifc Industrial Co., Ltd. v3 V3 Semiconductor +variscite Variscite Ltd. via VIA Technologies, Inc. +voipac Voipac Technologies s.r.o. winbond Winbond Electronics corp. wlf Wolfson Microelectronics wm Wondermedia Technologies, Inc. xes Extreme Engineering Solutions (X-ES) xlnx Xilinx +zyxel ZyXEL Communications Corp. +zarlink Zarlink Semiconductor diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt b/Documentation/devicetree/bindings/video/analog-tv-connector.txt new file mode 100644 index 0000000..0218fcd --- /dev/null +++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt @@ -0,0 +1,25 @@ +Analog TV Connector +=================== + +Required properties: +- compatible: "composite-connector" or "svideo-connector" + +Optional properties: +- label: a symbolic name for the connector + +Required nodes: +- Video port for TV input + +Example +------- + +tv: connector { + compatible = "composite-connector"; + label = "tv"; + + port { + tv_connector_in: endpoint { + remote-endpoint = <&venc_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt b/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt new file mode 100644 index 0000000..321be66 --- /dev/null +++ b/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt @@ -0,0 +1,16 @@ +gpio-backlight bindings + +Required properties: + - compatible: "gpio-backlight" + - gpios: describes the gpio that is used for enabling/disabling the backlight. + refer to bindings/gpio/gpio.txt for more details. + +Optional properties: + - default-on: enable the backlight at boot. + +Example: + backlight { + compatible = "gpio-backlight"; + gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>; + default-on; + }; diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt new file mode 100644 index 0000000..fc53f7c --- /dev/null +++ b/Documentation/devicetree/bindings/video/dvi-connector.txt @@ -0,0 +1,35 @@ +DVI Connector +============== + +Required properties: +- compatible: "dvi-connector" + +Optional properties: +- label: a symbolic name for the connector +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC +- analog: the connector has DVI analog pins +- digital: the connector has DVI digital pins +- dual-link: the connector has pins for DVI dual-link + +Required nodes: +- Video port for DVI input + +Note: One (or both) of 'analog' or 'digital' must be set. + +Example +------- + +dvi0: connector@0 { + compatible = "dvi-connector"; + label = "dvi"; + + digital; + + ddc-i2c-bus = <&i2c3>; + + port { + dvi_connector_in: endpoint { + remote-endpoint = <&tfp410_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt index 3289d76..53dbccf 100644 --- a/Documentation/devicetree/bindings/video/exynos_dp.txt +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt @@ -49,6 +49,8 @@ Required properties for dp-controller: -samsung,lane-count: number of lanes supported by the panel. LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4 + - display-timings: timings for the connected panel as described by + Documentation/devicetree/bindings/video/display-timing.txt Optional properties for dp-controller: -interlaced: @@ -60,6 +62,10 @@ Optional properties for dp-controller: -hsync-active-high: HSYNC polarity configuration. High if defined, Low if not defined + -samsung,hpd-gpio: + Hotplug detect GPIO. + Indicates which GPIO should be used for hotplug + detection Example: @@ -84,4 +90,19 @@ Board Specific portion: samsung,color-depth = <1>; samsung,link-rate = <0x0a>; samsung,lane-count = <4>; + + display-timings { + native-mode = <&lcd_timing>; + lcd_timing: 1366x768 { + clock-frequency = <70589280>; + hactive = <1366>; + vactive = <768>; + hfront-porch = <40>; + hback-porch = <40>; + hsync-len = <32>; + vback-porch = <10>; + vfront-porch = <12>; + vsync-len = <6>; + }; + }; }; diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt b/Documentation/devicetree/bindings/video/exynos_dsim.txt new file mode 100644 index 0000000..33b5730 --- /dev/null +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt @@ -0,0 +1,80 @@ +Exynos MIPI DSI Master + +Required properties: + - compatible: "samsung,exynos4210-mipi-dsi" + - reg: physical base address and length of the registers set for the device + - interrupts: should contain DSI interrupt + - clocks: list of clock specifiers, must contain an entry for each required + entry in clock-names + - clock-names: should include "bus_clk"and "pll_clk" entries + - phys: list of phy specifiers, must contain an entry for each required + entry in phy-names + - phy-names: should include "dsim" entry + - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V) + - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) + - samsung,pll-clock-frequency: specifies frequency of the "pll_clk" clock + - #address-cells, #size-cells: should be set respectively to <1> and <0> + according to DSI host bindings (see MIPI DSI bindings [1]) + +Optional properties: + - samsung,power-domain: a phandle to DSIM power domain node + +Child nodes: + Should contain DSI peripheral nodes (see MIPI DSI bindings [1]). + +Video interfaces: + Device node can contain video interface port nodes according to [2]. + The following are properties specific to those nodes: + + port node: + - reg: (required) can be 0 for input RGB/I80 port or 1 for DSI port; + + endpoint node of DSI port (reg = 1): + - samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst + mode + - samsung,esc-clock-frequency: specifies DSI frequency in escape mode + +[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + dsi@11C80000 { + compatible = "samsung,exynos4210-mipi-dsi"; + reg = <0x11C80000 0x10000>; + interrupts = <0 79 0>; + clocks = <&clock 286>, <&clock 143>; + clock-names = "bus_clk", "pll_clk"; + phys = <&mipi_phy 1>; + phy-names = "dsim"; + vddcore-supply = <&vusb_reg>; + vddio-supply = <&vmipi_reg>; + samsung,power-domain = <&pd_lcd0>; + #address-cells = <1>; + #size-cells = <0>; + samsung,pll-clock-frequency = <24000000>; + + panel@1 { + reg = <0>; + ... + port { + panel_ep: endpoint { + remote-endpoint = <&dsi_ep>; + }; + }; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + dsi_ep: endpoint { + reg = <0>; + samsung,burst-clock-frequency = <500000000>; + samsung,esc-clock-frequency = <20000000>; + remote-endpoint = <&panel_ep>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index 50decf8..1fd8cf9 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -5,6 +5,7 @@ Required properties: 1) "samsung,exynos5-hdmi" <DEPRECATED> 2) "samsung,exynos4210-hdmi" 3) "samsung,exynos4212-hdmi" + 4) "samsung,exynos5420-hdmi" - reg: physical base address of the hdmi and length of memory mapped region. - interrupts: interrupt number to the cpu. @@ -25,6 +26,10 @@ Required properties: sclk_pixel. - clock-names: aliases as per driver requirements for above clock IDs: "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi". +- ddc: phandle to the hdmi ddc node +- phy: phandle to the hdmi phy node +- samsung,syscon-phandle: phandle for system controller node for PMU. + Example: hdmi { @@ -32,4 +37,7 @@ Example: reg = <0x14530000 0x100000>; interrupts = <0 95 0>; hpd-gpio = <&gpx3 7 1>; + ddc = <&hdmi_ddc_node>; + phy = <&hdmi_phy_node>; + samsung,syscon-phandle = <&pmu_system_controller>; }; diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt index 46da08d..0329f60 100644 --- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt @@ -15,8 +15,12 @@ Required nodes: - fsl,pcr: LCDC PCR value Optional properties: +- lcd-supply: Regulator for LCD supply voltage. - fsl,dmacr: DMA Control Register value. This is optional. By default, the register is not modified as recommended by the datasheet. +- fsl,lpccr: Contrast Control Register value. This property provides the + default value for the contrast control register. + If that property is ommited, the register is zeroed. - fsl,lscr1: LCDC Sharp Configuration Register value. Example: diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt new file mode 100644 index 0000000..acd5668 --- /dev/null +++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt @@ -0,0 +1,29 @@ +HDMI Connector +============== + +Required properties: +- compatible: "hdmi-connector" +- type: the HDMI connector type: "a", "b", "c", "d" or "e" + +Optional properties: +- label: a symbolic name for the connector +- hpd-gpios: HPD GPIO number + +Required nodes: +- Video port for HDMI input + +Example +------- + +hdmi0: connector@1 { + compatible = "hdmi-connector"; + label = "hdmi"; + + type = "a"; + + port { + hdmi_connector_in: endpoint { + remote-endpoint = <&tpd12s015_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt b/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt new file mode 100644 index 0000000..1a1e653 --- /dev/null +++ b/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt @@ -0,0 +1,33 @@ +LG.Philips LB035Q02 Panel +========================= + +Required properties: +- compatible: "lgphilips,lb035q02" +- enable-gpios: panel enable gpio + +Optional properties: +- label: a symbolic name for the panel + +Required nodes: +- Video port for DPI input + +Example +------- + +lcd-panel: panel@0 { + compatible = "lgphilips,lb035q02"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + + enable-gpios = <&gpio7 7 0>; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt new file mode 100644 index 0000000..a40180b --- /dev/null +++ b/Documentation/devicetree/bindings/video/panel-dpi.txt @@ -0,0 +1,45 @@ +Generic MIPI DPI Panel +====================== + +Required properties: +- compatible: "panel-dpi" + +Optional properties: +- label: a symbolic name for the panel +- enable-gpios: panel enable gpio + +Required nodes: +- "panel-timing" containing video timings + (Documentation/devicetree/bindings/video/display-timing.txt) +- Video port for DPI input + +Example +------- + +lcd0: display@0 { + compatible = "samsung,lte430wq-f0c", "panel-dpi"; + label = "lcd"; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + + panel-timing { + clock-frequency = <9200000>; + hactive = <480>; + vactive = <272>; + hfront-porch = <8>; + hback-porch = <4>; + hsync-len = <41>; + vback-porch = <2>; + vfront-porch = <4>; + vsync-len = <10>; + + hsync-active = <0>; + vsync-active = <0>; + de-active = <1>; + pixelclk-active = <1>; + }; +}; diff --git a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt new file mode 100644 index 0000000..dce48eb --- /dev/null +++ b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt @@ -0,0 +1,29 @@ +Generic MIPI DSI Command Mode Panel +=================================== + +Required properties: +- compatible: "panel-dsi-cm" + +Optional properties: +- label: a symbolic name for the panel +- reset-gpios: panel reset gpio +- te-gpios: panel TE gpio + +Required nodes: +- Video port for DSI input + +Example +------- + +lcd0: display { + compatible = "tpo,taal", "panel-dsi-cm"; + label = "lcd0"; + + reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; + + port { + lcd0_in: endpoint { + remote-endpoint = <&dsi1_out_ep>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt index 778838a..2dad41b 100644 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt @@ -39,6 +39,23 @@ Required properties: Optional Properties: - samsung,power-domain: a phandle to FIMD power domain node. +- samsung,invert-vden: video enable signal is inverted +- samsung,invert-vclk: video clock signal is inverted +- display-timings: timing settings for FIMD, as described in document [1]. + Can be used in case timings cannot be provided otherwise + or to override timings provided by the panel. + +The device node can contain 'port' child nodes according to the bindings defined +in [2]. The following are properties specific to those nodes: +- reg: (required) port index, can be: + 0 - for CAMIF0 input, + 1 - for CAMIF1 input, + 2 - for CAMIF2 input, + 3 - for parallel output, + 4 - for write-back interface + +[1]: Documentation/devicetree/bindings/video/display-timing.txt +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt Example: diff --git a/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt new file mode 100644 index 0000000..0cc8981 --- /dev/null +++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt @@ -0,0 +1,43 @@ +SHARP LS037V7DW01 TFT-LCD panel +=================================== + +Required properties: +- compatible: "sharp,ls037v7dw01" + +Optional properties: +- label: a symbolic name for the panel +- enable-gpios: a GPIO spec for the optional enable pin. + This pin is the INI pin as specified in the LS037V7DW01.pdf file. +- reset-gpios: a GPIO spec for the optional reset pin. + This pin is the RESB pin as specified in the LS037V7DW01.pdf file. +- mode-gpios: a GPIO + ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file. + +Required nodes: +- Video port for DPI input + +This panel can have zero to five GPIOs to configure to change configuration +between QVGA and VGA mode and the scan direction. As these pins can be also +configured with external pulls, all the GPIOs are considered optional with holes +in the array. + +Example +------- + +Example when connected to a omap2+ based device: + +lcd0: display { + compatible = "sharp,ls037v7dw01"; + power-supply = <&lcd_3v3>; + enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */ + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */ + mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */ + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ + &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */ + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt new file mode 100644 index 0000000..e123332 --- /dev/null +++ b/Documentation/devicetree/bindings/video/sony,acx565akm.txt @@ -0,0 +1,30 @@ +Sony ACX565AKM SDI Panel +======================== + +Required properties: +- compatible: "sony,acx565akm" + +Optional properties: +- label: a symbolic name for the panel +- reset-gpios: panel reset gpio + +Required nodes: +- Video port for SDI input + +Example +------- + +acx565akm@2 { + compatible = "sony,acx565akm"; + spi-max-frequency = <6000000>; + reg = <2>; + + label = "lcd"; + reset-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */ + + port { + lcd_in: endpoint { + remote-endpoint = <&sdi_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt new file mode 100644 index 0000000..d5f1a3f --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt @@ -0,0 +1,211 @@ +Texas Instruments OMAP Display Subsystem +======================================== + +Generic Description +------------------- + +This document is a generic description of the OMAP Display Subsystem bindings. +Binding details for each OMAP SoC version are described in respective binding +documentation. + +The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and +a number of encoder modules. All DSS versions contain DSS Core and DISPC, but +the encoder modules vary. + +The DSS Core is the parent of the other DSS modules, and manages clock routing, +integration to the SoC, etc. + +DISPC is the display controller, which reads pixels from the memory and outputs +a RGB pixel stream to encoders. + +The encoder modules encode the received RGB pixel stream to a video output like +HDMI, MIPI DPI, etc. + +Video Ports +----------- + +The DSS Core and the encoders have video port outputs. The structure of the +video ports is described in Documentation/devicetree/bindings/video/video- +ports.txt, and the properties for the ports and endpoints for each encoder are +described in the SoC's DSS binding documentation. + +The video ports are used to describe the connections to external hardware, like +panels or external encoders. + +Aliases +------- + +The board dts file may define aliases for displays to assign "displayX" style +name for each display. If no aliases are defined, a semi-random number is used +for the display. + +Example +------- + +A shortened example of the DSS description for OMAP4, with non-relevant parts +removed, defined in omap4.dtsi: + +dss: dss@58000000 { + compatible = "ti,omap4-dss"; + reg = <0x58000000 0x80>; + status = "disabled"; + ti,hwmods = "dss_core"; + clocks = <&dss_dss_clk>; + clock-names = "fck"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + dispc@58001000 { + compatible = "ti,omap4-dispc"; + reg = <0x58001000 0x1000>; + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; + ti,hwmods = "dss_dispc"; + clocks = <&dss_dss_clk>; + clock-names = "fck"; + }; + + hdmi: encoder@58006000 { + compatible = "ti,omap4-hdmi"; + reg = <0x58006000 0x200>, + <0x58006200 0x100>, + <0x58006300 0x100>, + <0x58006400 0x1000>; + reg-names = "wp", "pll", "phy", "core"; + interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + ti,hwmods = "dss_hdmi"; + clocks = <&dss_48mhz_clk>, <&dss_sys_clk>; + clock-names = "fck", "sys_clk"; + }; +}; + +A shortened example of the board description for OMAP4 Panda board, defined in +omap4-panda.dts. + +The Panda board has a DVI and a HDMI connector, and the board contains a TFP410 +chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level +shifter). The video pipelines for the connectors are formed as follows: + +DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector +OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector + +/ { + aliases { + display0 = &dvi0; + display1 = &hdmi0; + }; + + tfp410: encoder@0 { + compatible = "ti,tfp410"; + gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */ + + pinctrl-names = "default"; + pinctrl-0 = <&tfp410_pins>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tfp410_in: endpoint@0 { + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + + tfp410_out: endpoint@0 { + remote-endpoint = <&dvi_connector_in>; + }; + }; + }; + }; + + dvi0: connector@0 { + compatible = "dvi-connector"; + label = "dvi"; + + i2c-bus = <&i2c3>; + + port { + dvi_connector_in: endpoint { + remote-endpoint = <&tfp410_out>; + }; + }; + }; + + tpd12s015: encoder@1 { + compatible = "ti,tpd12s015"; + + pinctrl-names = "default"; + pinctrl-0 = <&tpd12s015_pins>; + + gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */ + <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */ + <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */ + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tpd12s015_in: endpoint@0 { + remote-endpoint = <&hdmi_out>; + }; + }; + + port@1 { + reg = <1>; + + tpd12s015_out: endpoint@0 { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; + }; + + hdmi0: connector@1 { + compatible = "hdmi-connector"; + label = "hdmi"; + + port { + hdmi_connector_in: endpoint { + remote-endpoint = <&tpd12s015_out>; + }; + }; + }; +}; + +&dss { + status = "ok"; + + pinctrl-names = "default"; + pinctrl-0 = <&dss_dpi_pins>; + + port { + dpi_out: endpoint { + remote-endpoint = <&tfp410_in>; + data-lines = <24>; + }; + }; +}; + +&hdmi { + status = "ok"; + vdda-supply = <&vdac>; + + pinctrl-names = "default"; + pinctrl-0 = <&dss_hdmi_pins>; + + port { + hdmi_out: endpoint { + remote-endpoint = <&tpd12s015_in>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt new file mode 100644 index 0000000..fa8bb2e --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt @@ -0,0 +1,54 @@ +Texas Instruments OMAP2 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap2-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" + +Optional nodes: +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap2-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt + + +RFBI +---- + +Required properties: +- compatible: "ti,omap2-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" + + +VENC +---- + +Required properties: +- compatible: "ti,omap2-venc" +- reg: address and length of the register space +- ti,hwmods: "dss_venc" +- vdda-supply: power supply for DAC + +VENC Endpoint required properties: + +Required properties: +- ti,invert-polarity: invert the polarity of the video signal +- ti,channels: 1 for composite, 2 for s-video diff --git a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt new file mode 100644 index 0000000..0023fa4 --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt @@ -0,0 +1,83 @@ +Texas Instruments OMAP3 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap3-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" +- clocks: handle to fclk +- clock-names: "fck" + +Optional nodes: +- Video ports: + - Port 0: DPI output + - Port 1: SDI output + +DPI Endpoint required properties: +- data-lines: number of lines used + +SDI Endpoint required properties: +- datapairs: number of datapairs used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap3-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: "fck" + + +RFBI +---- + +Required properties: +- compatible: "ti,omap3-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" +- clocks: handles to fclk and iclk +- clock-names: "fck", "ick" + + +VENC +---- + +Required properties: +- compatible: "ti,omap3-venc" +- reg: address and length of the register space +- ti,hwmods: "dss_venc" +- vdda-supply: power supply for DAC +- clocks: handle to fclk +- clock-names: "fck" + +VENC Endpoint required properties: +- ti,invert-polarity: invert the polarity of the video signal +- ti,channels: 1 for composite, 2 for s-video + + +DSI +--- + +Required properties: +- compatible: "ti,omap3-dsi" +- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' +- reg-names: "proto", "phy", "pll" +- interrupts: the DSI interrupt line +- ti,hwmods: "dss_dsi1" +- vdd-supply: power supply for DSI +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +DSI Endpoint required properties: +- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, + DATA1+, DATA1-, ... diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt new file mode 100644 index 0000000..b8c29fb --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt @@ -0,0 +1,115 @@ +Texas Instruments OMAP4 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap4-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" +- clocks: handle to fclk +- clock-names: "fck" + +Required nodes: +- DISPC + +Optional nodes: +- DSS Submodules: RFBI, VENC, DSI, HDMI +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap4-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: "fck" + + +RFBI +---- + +Required properties: +- compatible: "ti,omap4-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" +- clocks: handles to fclk and iclk +- clock-names: "fck", "ick" + +Optional nodes: +- Video port for RFBI output +- RFBI controlled peripherals + + +VENC +---- + +Required properties: +- compatible: "ti,omap4-venc" +- reg: address and length of the register space +- ti,hwmods: "dss_venc" +- vdda-supply: power supply for DAC +- clocks: handle to fclk +- clock-names: "fck" + +Optional nodes: +- Video port for VENC output + +VENC Endpoint required properties: +- ti,invert-polarity: invert the polarity of the video signal +- ti,channels: 1 for composite, 2 for s-video + + +DSI +--- + +Required properties: +- compatible: "ti,omap4-dsi" +- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' +- reg-names: "proto", "phy", "pll" +- interrupts: the DSI interrupt line +- ti,hwmods: "dss_dsi1" or "dss_dsi2" +- vdd-supply: power supply for DSI +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for DSI output +- DSI controlled peripherals + +DSI Endpoint required properties: +- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, + DATA1+, DATA1-, ... + + +HDMI +---- + +Required properties: +- compatible: "ti,omap4-hdmi" +- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', + 'core' +- reg-names: "wp", "pll", "phy", "core" +- interrupts: the HDMI interrupt line +- ti,hwmods: "dss_hdmi" +- vdda-supply: vdda power supply +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for HDMI output + +HDMI Endpoint optional properties: +- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, + D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) diff --git a/Documentation/devicetree/bindings/video/ti,omap5-dss.txt b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt new file mode 100644 index 0000000..38ffc8f --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt @@ -0,0 +1,96 @@ +Texas Instruments OMAP5 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap5-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" +- clocks: handle to fclk +- clock-names: "fck" + +Required nodes: +- DISPC + +Optional nodes: +- DSS Submodules: RFBI, DSI, HDMI +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap5-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: "fck" + + +RFBI +---- + +Required properties: +- compatible: "ti,omap5-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" +- clocks: handles to fclk and iclk +- clock-names: "fck", "ick" + +Optional nodes: +- Video port for RFBI output +- RFBI controlled peripherals + + +DSI +--- + +Required properties: +- compatible: "ti,omap5-dsi" +- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' +- reg-names: "proto", "phy", "pll" +- interrupts: the DSI interrupt line +- ti,hwmods: "dss_dsi1" or "dss_dsi2" +- vdd-supply: power supply for DSI +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for DSI output +- DSI controlled peripherals + +DSI Endpoint required properties: +- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, + DATA1+, DATA1-, ... + + +HDMI +---- + +Required properties: +- compatible: "ti,omap5-hdmi" +- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', + 'core' +- reg-names: "wp", "pll", "phy", "core" +- interrupts: the HDMI interrupt line +- ti,hwmods: "dss_hdmi" +- vdda-supply: vdda power supply +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for HDMI output + +HDMI Endpoint optional properties: +- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, + D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) diff --git a/Documentation/devicetree/bindings/video/ti,tfp410.txt b/Documentation/devicetree/bindings/video/ti,tfp410.txt new file mode 100644 index 0000000..2cbe32a --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,tfp410.txt @@ -0,0 +1,41 @@ +TFP410 DPI to DVI encoder +========================= + +Required properties: +- compatible: "ti,tfp410" + +Optional properties: +- powerdown-gpios: power-down gpio + +Required nodes: +- Video port 0 for DPI input +- Video port 1 for DVI output + +Example +------- + +tfp410: encoder@0 { + compatible = "ti,tfp410"; + powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tfp410_in: endpoint@0 { + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + + tfp410_out: endpoint@0 { + remote-endpoint = <&dvi_connector_in>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt new file mode 100644 index 0000000..26e6d32 --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt @@ -0,0 +1,44 @@ +TPD12S015 HDMI level shifter and ESD protection chip +==================================================== + +Required properties: +- compatible: "ti,tpd12s015" + +Optional properties: +- gpios: CT CP HPD, LS OE and HPD gpios + +Required nodes: +- Video port 0 for HDMI input +- Video port 1 for HDMI output + +Example +------- + +tpd12s015: encoder@1 { + compatible = "ti,tpd12s015"; + + gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */ + <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */ + <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */ + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tpd12s015_in: endpoint@0 { + remote-endpoint = <&hdmi_out>; + }; + }; + + port@1 { + reg = <1>; + + tpd12s015_out: endpoint@0 { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt b/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt new file mode 100644 index 0000000..7175dc3 --- /dev/null +++ b/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt @@ -0,0 +1,30 @@ +Toppoly TD028TTEC1 Panel +======================== + +Required properties: +- compatible: "toppoly,td028ttec1" + +Optional properties: +- label: a symbolic name for the panel + +Required nodes: +- Video port for DPI input + +Example +------- + +lcd-panel: td028ttec1@0 { + compatible = "toppoly,td028ttec1"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; + diff --git a/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt b/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt new file mode 100644 index 0000000..ec6d629 --- /dev/null +++ b/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt @@ -0,0 +1,33 @@ +TPO TD043MTEA1 Panel +==================== + +Required properties: +- compatible: "tpo,td043mtea1" +- reset-gpios: panel reset gpio + +Optional properties: +- label: a symbolic name for the panel + +Required nodes: +- Video port for DPI input + +Example +------- + +lcd-panel: panel@0 { + compatible = "tpo,td043mtea1"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + + reset-gpios = <&gpio7 7 0>; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt index 2144af1..e52ba2d 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt @@ -5,10 +5,15 @@ Required properties: - reg : Should contain WDT registers location and length - interrupts : Should contain WDT interrupt +Optional property: +- big-endian: If present the watchdog device's registers are implemented + in big endian mode, otherwise in little mode. + Examples: wdt@73f98000 { compatible = "fsl,imx51-wdt", "fsl,imx21-wdt"; reg = <0x73f98000 0x4000>; interrupts = <58>; + big-endian; }; diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt index 5dc8d30..97223fd 100644 --- a/Documentation/devicetree/bindings/watchdog/marvel.txt +++ b/Documentation/devicetree/bindings/watchdog/marvel.txt @@ -3,17 +3,31 @@ Required Properties: - Compatibility : "marvell,orion-wdt" -- reg : Address of the timer registers + "marvell,armada-370-wdt" + "marvell,armada-xp-wdt" + "marvell,armada-375-wdt" + "marvell,armada-380-wdt" + +- reg : Should contain two entries: first one with the + timer control address, second one with the + rstout enable address. + +For "marvell,armada-375-wdt" and "marvell,armada-380-wdt": + +- reg : A third entry is mandatory and should contain the + shared mask/unmask RSTOUT address. Optional properties: +- interrupts : Contains the IRQ for watchdog expiration - timeout-sec : Contains the watchdog timeout in seconds Example: wdt@20300 { compatible = "marvell,orion-wdt"; - reg = <0x20300 0x28>; + reg = <0x20300 0x28>, <0x20108 0x4>; + interrupts = <3>; timeout-sec = <10>; status = "okay"; }; diff --git a/Documentation/dontdiff b/Documentation/dontdiff index b89a739..9de9813 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -1,5 +1,6 @@ *.a *.aux +*.bc *.bin *.bz2 *.cis @@ -21,6 +22,7 @@ *.i *.jpeg *.ko +*.ll *.log *.lst *.lzma @@ -35,6 +37,7 @@ *.out *.patch *.pdf +*.plist *.png *.pot *.ps diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 4f7897e..d14710b 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -233,63 +233,78 @@ certainly invest a bit more effort into libata core layer). 6. List of managed interfaces ----------------------------- -MEM - devm_kzalloc() - devm_kfree() +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() @@ -299,9 +314,11 @@ 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() diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 5d5ee4c..26c623d 100755 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -28,8 +28,8 @@ use IO::Handle; "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718", "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395", "lme2510c_s7395_old", "drxk", "drxk_terratec_h5", - "drxk_hauppauge_hvr930c", "tda10071", "it9135", "it9137", - "drxk_pctv", "drxk_terratec_htc_stick", "sms1xxx_hcw"); + "drxk_hauppauge_hvr930c", "tda10071", "it9135", "drxk_pctv", + "drxk_terratec_htc_stick", "sms1xxx_hcw", "si2165"); # Check args syntax() if (scalar(@ARGV) != 1); @@ -727,24 +727,6 @@ sub it9135 { "$fwfile1 $fwfile2" } -sub it9137 { - my $url = "http://kworld.server261.com/kworld/CD/ITE_TiVme/V1.00/"; - my $zipfile = "Driver_V10.323.1.0412.100412.zip"; - my $hash = "79b597dc648698ed6820845c0c9d0d37"; - my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0); - my $drvfile = "Driver_V10.323.1.0412.100412/Data/x86/IT9135BDA.sys"; - my $fwfile = "dvb-usb-it9137-01.fw"; - - checkstandard(); - - wgetfile($zipfile, $url . $zipfile); - verify($zipfile, $hash); - unzip($zipfile, $tmpdir); - extract("$tmpdir/$drvfile", 69632, 5731, "$fwfile"); - - "$fwfile" -} - sub tda10071 { my $sourcefile = "PCTV_460e_reference.zip"; my $url = "ftp://ftp.pctvsystems.com/TV/driver/PCTV%2070e%2080e%20100e%20320e%20330e%20800e/"; @@ -801,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/dvb/it9137.txt b/Documentation/dvb/it9137.txt deleted file mode 100644 index 9e6726e..0000000 --- a/Documentation/dvb/it9137.txt +++ /dev/null @@ -1,9 +0,0 @@ -To extract firmware for Kworld UB499-2T (id 1b80:e409) you need to copy the -following file(s) to this directory. - -IT9135BDA.sys Dated Mon 22 Mar 2010 02:20:08 GMT - -extract using dd -dd if=IT9135BDA.sys ibs=1 skip=69632 count=5731 of=dvb-usb-it9137-01.fw - -copy to default firmware location. diff --git a/Documentation/edac.txt b/Documentation/edac.txt index 8bdc07c..73fff13 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt @@ -6,7 +6,7 @@ Written by Doug Thompson <dougthompson@xmission.com> 7 Dec 2005 17 Jul 2007 Updated -(c) Mauro Carvalho Chehab <mchehab@redhat.com> +(c) Mauro Carvalho Chehab 05 Aug 2009 Nehalem interface EDAC is maintained and written by: diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt index c628788..7747024 100644 --- a/Documentation/efi-stub.txt +++ b/Documentation/efi-stub.txt @@ -1,13 +1,21 @@ The EFI Boot Stub --------------------------- -On the x86 platform, a bzImage can masquerade as a PE/COFF image, -thereby convincing EFI firmware loaders to load it as an EFI -executable. The code that modifies the bzImage header, along with the -EFI-specific entry point that the firmware loader jumps to are -collectively known as the "EFI boot stub", and live in +On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade +as a PE/COFF image, thereby convincing EFI firmware loaders to load +it as an EFI executable. The code that modifies the bzImage header, +along with the EFI-specific entry point that the firmware loader +jumps to are collectively known as the "EFI boot stub", and live in arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c, -respectively. +respectively. For ARM the EFI stub is implemented in +arch/arm/boot/compressed/efi-header.S and +arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared +between architectures is in drivers/firmware/efi/efi-stub-helper.c. + +For arm64, there is no compressed kernel support, so the Image itself +masquerades as a PE/COFF image and the EFI stub is linked into the +kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S +and arch/arm64/kernel/efi-stub.c. By using the EFI boot stub it's possible to boot a Linux kernel without the use of a conventional EFI boot loader, such as grub or @@ -23,7 +31,10 @@ The bzImage located in arch/x86/boot/bzImage must be copied to the EFI System Partition (ESP) and renamed with the extension ".efi". Without the extension the EFI firmware loader will refuse to execute it. It's not possible to execute bzImage.efi from the usual Linux file systems -because EFI firmware doesn't have support for them. +because EFI firmware doesn't have support for them. For ARM the +arch/arm/boot/zImage should be copied to the system partition, and it +may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image +should be copied but not necessarily renamed. **** Passing kernel parameters from the EFI shell @@ -63,3 +74,11 @@ Notice how bzImage.efi can be specified with a relative path. That's because the image we're executing is interpreted by the EFI shell, which understands relative paths, whereas the rest of the command line is passed to bzImage.efi. + + +**** The "dtb=" option + +For the ARM and arm64 architectures, we also need to be able to provide a +device tree to the kernel. This is done with the "dtb=" command line option, +and is processed in the same manner as the "initrd=" option that is +described above. diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt index e9f5dac..9af538be 100644 --- a/Documentation/email-clients.txt +++ b/Documentation/email-clients.txt @@ -1,6 +1,17 @@ Email clients info for Linux ====================================================================== +Git +---------------------------------------------------------------------- +These days most developers use `git send-email` instead of regular +email clients. The man page for this is quite good. On the receiving +end, maintainers use `git am` to apply the patches. + +If you are new to git then send your first patch to yourself. Save it +as raw text including all the headers. Run `git am raw_email.txt` and +then review the changelog with `git log`. When that works then send +the patch to the appropriate mailing list(s). + General Preferences ---------------------------------------------------------------------- Patches for the Linux kernel are submitted via email, preferably as @@ -201,20 +212,15 @@ To beat some sense out of the internal editor, do this: - Edit your Thunderbird config settings so that it won't use format=flowed. Go to "edit->preferences->advanced->config editor" to bring up the - thunderbird's registry editor, and set "mailnews.send_plaintext_flowed" to - "false". + thunderbird's registry editor. -- Disable HTML Format: Set "mail.identity.id1.compose_html" to "false". +- Set "mailnews.send_plaintext_flowed" to "false" -- Enable "preformat" mode: Set "editor.quotesPreformatted" to "true". +- Set "mailnews.wraplength" from "72" to "0" -- Enable UTF8: Set "prefs.converted-to-utf8" to "true". +- "View" > "Message Body As" > "Plain Text" -- Install the "toggle wordwrap" extension. Download the file from: - https://addons.mozilla.org/thunderbird/addon/2351/ - Then go to "tools->add ons", select "install" at the bottom of the screen, - and browse to where you saved the .xul file. This adds an "Enable - Wordwrap" entry under the Options menu of the message composer. +- "View" > "Character Encoding" > "Unicode (UTF-8)" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TkRat (GUI) diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 5b0c083..b18dd17 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -47,6 +47,8 @@ prototypes: int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t); int (*rename) (struct inode *, struct dentry *, struct inode *, struct dentry *); + int (*rename2) (struct inode *, struct dentry *, + struct inode *, struct dentry *, unsigned int); int (*readlink) (struct dentry *, char __user *,int); void * (*follow_link) (struct dentry *, struct nameidata *); void (*put_link) (struct dentry *, struct nameidata *, void *); @@ -78,6 +80,7 @@ mkdir: yes unlink: yes (both) rmdir: yes (both) (see below) rename: yes (all) (see below) +rename2: yes (all) (see below) readlink: no follow_link: no put_link: no @@ -96,7 +99,8 @@ tmpfile: no Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on victim. - cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem. + cross-directory ->rename() and rename2() has (per-superblock) +->s_vfs_rename_sem. See Documentation/filesystems/directory-locking for more detailed discussion of the locking scheme for directory operations. @@ -192,13 +196,12 @@ prototypes: void (*invalidatepage) (struct page *, unsigned int, unsigned int); int (*releasepage) (struct page *, int); void (*freepage)(struct page *); - int (*direct_IO)(int, struct kiocb *, const struct iovec *iov, - loff_t offset, unsigned long nr_segs); + int (*direct_IO)(int, struct kiocb *, struct iov_iter *iter, loff_t offset); int (*get_xip_mem)(struct address_space *, pgoff_t, int, void **, unsigned long *); int (*migratepage)(struct address_space *, struct page *, struct page *); int (*launder_page)(struct page *); - int (*is_partially_uptodate)(struct page *, read_descriptor_t *, unsigned long); + int (*is_partially_uptodate)(struct page *, unsigned long, unsigned long); int (*error_remove_page)(struct address_space *, struct page *); int (*swap_activate)(struct file *); int (*swap_deactivate)(struct file *); @@ -427,6 +430,8 @@ prototypes: ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t); ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t); + ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); + ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); int (*iterate) (struct file *, struct dir_context *); unsigned int (*poll) (struct file *, struct poll_table_struct *); long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); @@ -525,6 +530,7 @@ locking rules: open: yes close: yes fault: yes can return with page locked +map_pages: yes page_mkwrite: yes can return with page locked access: yes @@ -536,6 +542,15 @@ the page, then ensure it is not already truncated (the page lock will block subsequent truncate), and then return with VM_FAULT_LOCKED, and the page locked. The VM will unlock the page. + ->map_pages() is called when VM asks to map easy accessible pages. +Filesystem should find and map pages associated with offsets from "pgoff" +till "max_pgoff". ->map_pages() is called with page table locked and must +not block. If it's not possible to reach a page without blocking, +filesystem should skip it. Filesystem should use do_set_pte() to setup +page table entry. Pointer to entry associated with offset "pgoff" is +passed in "pte" field in vm_fault structure. Pointers to entries for other +offsets should be calculated relative to "pte". + ->page_mkwrite() is called when a previously read-only pte is about to become writeable. The filesystem again must ensure that there are no truncate/invalidate races, and then return with the page locked. If diff --git a/Documentation/filesystems/affs.txt b/Documentation/filesystems/affs.txt index 81ac488..71b63c2 100644 --- a/Documentation/filesystems/affs.txt +++ b/Documentation/filesystems/affs.txt @@ -49,6 +49,10 @@ mode=mode Sets the mode flags to the given (octal) value, regardless This is useful since most of the plain AmigaOS files will map to 600. +nofilenametruncate + The file system will return an error when filename exceeds + standard maximum filename length (30 characters). + reserved=num Sets the number of reserved blocks at the start of the partition to num. You should never need this option. Default is 2. @@ -181,9 +185,8 @@ tested, though several hundred MB have been read and written using this fs. For a most up-to-date list of bugs please consult fs/affs/Changes. -Filenames are truncated to 30 characters without warning (this -can be changed by setting the compile-time option AFFS_NO_TRUNCATE -in include/linux/amigaffs.h). +By default, filenames are truncated to 30 characters without warning. +'nofilenametruncate' mount option can change that behavior. Case is ignored by the affs in filename matching, but Linux shells do care about the case. Example (with /wb being an affs mounted fs): diff --git a/Documentation/filesystems/caching/operations.txt b/Documentation/filesystems/caching/operations.txt index bee2a5f..a1c052c 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 b8d2849..a2046a7 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -122,6 +122,15 @@ disable_ext_identify Disable the extension list configured by mkfs, so f2fs inline_xattr Enable the inline xattrs feature. inline_data Enable the inline data feature: New created small(<~3.4k) files can be written into inode block. +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 @@ -169,9 +178,11 @@ Files in /sys/fs/f2fs/<devname> reclaim_segments This parameter controls the number of prefree segments to be reclaimed. If the number of prefree - segments is larger than this number, f2fs tries to - conduct checkpoint to reclaim the prefree segments - to free segments. By default, 100 segments, 200MB. + segments is larger than the number of segments + in the proportion to the percentage over total + volume size, f2fs tries to conduct checkpoint to + reclaim the prefree segments to free segments. + By default, 5% over total # of segments. max_small_discards This parameter controls the number of discard commands that consist small blocks less than 2MB. @@ -195,6 +206,17 @@ Files in /sys/fs/f2fs/<devname> cleaning operations. The default value is 4096 which covers 8GB block address range. + dir_level This parameter controls the directory level to + support large directory. If a directory has a + number of files, it can reduce the file lookup + latency by increasing this dir_level value. + Otherwise, it needs to decrease this value to + reduce the space overhead. The default value is 0. + + ram_thresh This parameter controls the memory footprint used + by free nids and cached nat entries. By default, + 10 is set, which indicates 10 MB / 1 GB RAM. + ================================================================================ USAGE ================================================================================ @@ -444,9 +466,11 @@ The number of blocks and buckets are determined by, # of blocks in level #n = | `- 4, Otherwise - ,- 2^n, if n < MAX_DIR_HASH_DEPTH / 2, + ,- 2^(n + dir_level), + | if n + dir_level < MAX_DIR_HASH_DEPTH / 2, # of buckets in level #n = | - `- 2^((MAX_DIR_HASH_DEPTH / 2) - 1), Otherwise + `- 2^((MAX_DIR_HASH_DEPTH / 2) - 1), + Otherwise When F2FS finds a file name in a directory, at first a hash value of the file name is calculated. Then, F2FS scans the hash table in level #0 to find the diff --git a/Documentation/filesystems/nfs/nfs41-server.txt b/Documentation/filesystems/nfs/nfs41-server.txt index b930ad0..c49cd7e 100644 --- a/Documentation/filesystems/nfs/nfs41-server.txt +++ b/Documentation/filesystems/nfs/nfs41-server.txt @@ -176,7 +176,5 @@ Nonstandard compound limitations: ca_maxrequestsize request and a ca_maxresponsesize reply, so we may fail to live up to the promise we made in CREATE_SESSION fore channel negotiation. -* No more than one read-like operation allowed per compound; encoding - replies that cross page boundaries (except for read data) not handled. See also http://wiki.linux-nfs.org/wiki/index.php/Server_4.0_and_4.1_issues. diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt index 06887d4..41c3d33 100644 --- a/Documentation/filesystems/nilfs2.txt +++ b/Documentation/filesystems/nilfs2.txt @@ -25,9 +25,8 @@ available from the following download page. At least "mkfs.nilfs2", cleaner or garbage collector) are required. Details on the tools are described in the man pages included in the package. -Project web page: http://www.nilfs.org/en/ -Download page: http://www.nilfs.org/en/download.html -Git tree web page: http://www.nilfs.org/git/ +Project web page: http://nilfs.sourceforge.net/ +Download page: http://nilfs.sourceforge.net/en/download.html List info: http://vger.kernel.org/vger-lists.html#linux-nilfs Caveats @@ -111,6 +110,13 @@ Table of NILFS2 specific ioctls nilfs_resize utilities and by nilfs_cleanerd daemon. + NILFS_IOCTL_SET_SUINFO Modify segment usage info of requested + segments. This ioctl is used by + nilfs_cleanerd daemon to skip unnecessary + cleaning operation of segments and reduce + performance penalty or wear of flash device + due to redundant move of in-use blocks. + NILFS_IOCTL_GET_SUSTAT Return segment usage statistics. This ioctl is used in lssu, nilfs_resize utilities and by nilfs_cleanerd daemon. diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt index 791af8d..61947fa 100644 --- a/Documentation/filesystems/ntfs.txt +++ b/Documentation/filesystems/ntfs.txt @@ -455,8 +455,6 @@ not have this problem with odd numbers of sectors. ChangeLog ========= -Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog. - 2.1.30: - Fix writev() (it kept writing the first segment over and over again instead of moving onto subsequent segments). diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index fe2b7ae..0f3a139 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -295,9 +295,9 @@ in the beginning of ->setattr unconditionally. ->clear_inode() and ->delete_inode() are gone; ->evict_inode() should be used instead. It gets called whenever the inode is evicted, whether it has remaining links or not. Caller does *not* evict the pagecache or inode-associated -metadata buffers; getting rid of those is responsibility of method, as it had -been for ->delete_inode(). Caller makes sure async writeback cannot be running -for the inode while (or after) ->evict_inode() is called. +metadata buffers; the method has to use truncate_inode_pages_final() to get rid +of those. Caller makes sure async writeback cannot be running for the inode while +(or after) ->evict_inode() is called. ->drop_inode() returns int now; it's called on final iput() with inode->i_lock held and it returns true if filesystems wants the inode to be diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 324328d..eb8a10e 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1246,8 +1246,9 @@ second). The meanings of the columns are as follows, from left to right: The "intr" line gives counts of interrupts serviced since boot time, for each of the possible system interrupts. The first column is the total of all -interrupts serviced; each subsequent column is the total for that particular -interrupt. +interrupts serviced including unnumbered architecture specific interrupts; +each subsequent column is the total for that particular numbered interrupt. +Unnumbered interrupts are not shown, only summed into the total. The "ctxt" line gives the total number of context switches across all CPUs. @@ -1649,18 +1650,21 @@ pids, so one need to either stop or freeze processes being inspected if precise results are needed. -3.7 /proc/<pid>/fdinfo/<fd> - Information about opened file +3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file --------------------------------------------------------------- This file provides information associated with an opened file. The regular -files have at least two fields -- 'pos' and 'flags'. The 'pos' represents -the current offset of the opened file in decimal form [see lseek(2) for -details] and 'flags' denotes the octal O_xxx mask the file has been -created with [see open(2) for details]. +files have at least three fields -- 'pos', 'flags' and mnt_id. The 'pos' +represents the current offset of the opened file in decimal form [see lseek(2) +for details], 'flags' denotes the octal O_xxx mask the file has been +created with [see open(2) for details] and 'mnt_id' represents mount ID of +the file system containing the opened file [see 3.5 /proc/<pid>/mountinfo +for details]. A typical output is pos: 0 flags: 0100002 + mnt_id: 19 The files such as eventfd, fsnotify, signalfd, epoll among the regular pos/flags pair provide additional information particular to the objects they represent. @@ -1669,6 +1673,7 @@ pair provide additional information particular to the objects they represent. ~~~~~~~~~~~~~ pos: 0 flags: 04002 + mnt_id: 9 eventfd-count: 5a where 'eventfd-count' is hex value of a counter. @@ -1677,6 +1682,7 @@ pair provide additional information particular to the objects they represent. ~~~~~~~~~~~~~~ pos: 0 flags: 04002 + mnt_id: 9 sigmask: 0000000000000200 where 'sigmask' is hex value of the signal mask associated @@ -1686,6 +1692,7 @@ pair provide additional information particular to the objects they represent. ~~~~~~~~~~~ pos: 0 flags: 02 + mnt_id: 9 tfd: 5 events: 1d data: ffffffffffffffff where 'tfd' is a target file descriptor number in decimal form, @@ -1719,6 +1726,7 @@ pair provide additional information particular to the objects they represent. pos: 0 flags: 02 + mnt_id: 9 fanotify flags:10 event-flags:0 fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003 fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4 @@ -1735,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/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt index a1e2e0d..1fe0ccb 100644 --- a/Documentation/filesystems/seq_file.txt +++ b/Documentation/filesystems/seq_file.txt @@ -54,6 +54,15 @@ how the mechanism works without getting lost in other details. (Those wanting to see the full source for this module can find it at http://lwn.net/Articles/22359/). +Deprecated create_proc_entry + +Note that the above article uses create_proc_entry which was removed in +kernel 3.10. Current versions require the following update + +- entry = create_proc_entry("sequence", 0, NULL); +- if (entry) +- entry->proc_fops = &ct_file_ops; ++ entry = proc_create("sequence", 0, NULL, &ct_file_ops); The iterator interface diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt index 4a93e98..ce1126a 100644 --- a/Documentation/filesystems/vfat.txt +++ b/Documentation/filesystems/vfat.txt @@ -172,6 +172,11 @@ nfs=stale_rw|nostale_ro To maintain backward compatibility, '-o nfs' is also accepted, defaulting to stale_rw +dos1xfloppy -- If set, use a fallback default BIOS Parameter Block + configuration, determined by backing device size. These static + parameters match defaults assumed by DOS 1.x for 160 kiB, + 180 kiB, 320 kiB, and 360 kiB floppies and floppy images. + <bool>: 0,1,yes,no,true,false diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index c53784c..a1d0d7a 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -347,6 +347,8 @@ struct inode_operations { int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t); int (*rename) (struct inode *, struct dentry *, struct inode *, struct dentry *); + int (*rename2) (struct inode *, struct dentry *, + struct inode *, struct dentry *, unsigned int); int (*readlink) (struct dentry *, char __user *,int); void * (*follow_link) (struct dentry *, struct nameidata *); void (*put_link) (struct dentry *, struct nameidata *, void *); @@ -414,6 +416,20 @@ otherwise noted. rename: called by the rename(2) system call to rename the object to have the parent and name given by the second inode and dentry. + rename2: this has an additional flags argument compared to rename. + If no flags are supported by the filesystem then this method + need not be implemented. If some flags are supported then the + filesystem must return -EINVAL for any unsupported or unknown + flags. Currently the following flags are implemented: + (1) RENAME_NOREPLACE: this flag indicates that if the target + of the rename exists the rename should fail with -EEXIST + instead of replacing the target. The VFS already checks for + existence, so for local filesystems the RENAME_NOREPLACE + implementation is equivalent to plain rename. + (2) RENAME_EXCHANGE: exchange source and target. Both must + exist; this is checked by the VFS. Unlike plain rename, + source and target may be of different type. + readlink: called by the readlink(2) system call. Only required if you want to support reading symbolic links @@ -573,14 +589,13 @@ struct address_space_operations { void (*invalidatepage) (struct page *, unsigned int, unsigned int); int (*releasepage) (struct page *, int); void (*freepage)(struct page *); - ssize_t (*direct_IO)(int, struct kiocb *, const struct iovec *iov, - loff_t offset, unsigned long nr_segs); + ssize_t (*direct_IO)(int, struct kiocb *, struct iov_iter *iter, loff_t offset); struct page* (*get_xip_page)(struct address_space *, sector_t, int); /* migrate the contents of a page to the specified target */ int (*migratepage) (struct page *, struct page *); int (*launder_page) (struct page *); - int (*is_partially_uptodate) (struct page *, read_descriptor_t *, + int (*is_partially_uptodate) (struct page *, unsigned long, unsigned long); void (*is_dirty_writeback) (struct page *, bool *, bool *); int (*error_remove_page) (struct mapping *mapping, struct page *page); @@ -791,6 +806,8 @@ struct file_operations { ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t); ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t); + ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); + ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); int (*iterate) (struct file *, struct dir_context *); unsigned int (*poll) (struct file *, struct poll_table_struct *); long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); @@ -821,11 +838,15 @@ otherwise noted. read: called by read(2) and related system calls - aio_read: called by io_submit(2) and other asynchronous I/O operations + aio_read: vectored, possibly asynchronous read + + read_iter: possibly asynchronous read with iov_iter as destination write: called by write(2) and related system calls - aio_write: called by io_submit(2) and other asynchronous I/O operations + aio_write: vectored, possibly asynchronous write + + write_iter: possibly asynchronous write with iov_iter as source iterate: called when the VFS needs to read the directory contents diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README index 43fada9..71f8685 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/gpio/consumer.txt b/Documentation/gpio/consumer.txt index 0ff8eb0..d8abfc3 100644 --- a/Documentation/gpio/consumer.txt +++ b/Documentation/gpio/consumer.txt @@ -154,6 +154,7 @@ raw line value: void gpiod_set_raw_value(struct gpio_desc *desc, int value) int gpiod_get_raw_value_cansleep(const struct gpio_desc *desc) void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value) + int gpiod_direction_output_raw(struct gpio_desc *desc, int value) The active-low state of a GPIO can also be queried using the following call: diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index 9da0bfa..fa9a0a8 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -62,6 +62,96 @@ Any debugfs dump method should normally ignore signals which haven't been requested as GPIOs. They can use gpiochip_is_requested(), which returns either NULL or the label associated with that GPIO when it was requested. + +GPIO drivers providing IRQs +--------------------------- +It is custom that GPIO drivers (GPIO chips) are also providing interrupts, +most often cascaded off a parent interrupt controller, and in some special +cases the GPIO logic is melded with a SoC's primary interrupt controller. + +The IRQ portions of the GPIO block are implemented using an irqchip, using +the header <linux/irq.h>. So basically such a driver is utilizing two sub- +systems simultaneously: gpio and irq. + +GPIO irqchips usually fall in one of two categories: + +* CHAINED GPIO irqchips: these are usually the type that is embedded on + an SoC. This means that there is a fast IRQ handler for the GPIOs that + gets called in a chain from the parent IRQ handler, most typically the + system interrupt controller. This means the GPIO irqchip is registered + using irq_set_chained_handler() or the corresponding + gpiochip_set_chained_irqchip() helper function, and the GPIO irqchip + handler will be called immediately from the parent irqchip, while + holding the IRQs disabled. The GPIO irqchip will then end up calling + something like this sequence in its interrupt handler: + + static irqreturn_t tc3589x_gpio_irq(int irq, void *data) + chained_irq_enter(...); + generic_handle_irq(...); + chained_irq_exit(...); + + Chained GPIO irqchips typically can NOT set the .can_sleep flag on + struct gpio_chip, as everything happens directly in the callbacks. + +* NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any + other GPIO irqchip residing on the other side of a sleeping bus. Of course + such drivers that need slow bus traffic to read out IRQ status and similar, + traffic which may in turn incur other IRQs to happen, cannot be handled + in a quick IRQ handler with IRQs disabled. Instead they need to spawn a + thread and then mask the parent IRQ line until the interrupt is handled + by the driver. The hallmark of this driver is to call something like + this in its interrupt handler: + + static irqreturn_t tc3589x_gpio_irq(int irq, void *data) + ... + handle_nested_irq(irq); + + The hallmark of threaded GPIO irqchips is that they set the .can_sleep + flag on struct gpio_chip to true, indicating that this chip may sleep + when accessing the GPIOs. + +To help out in handling the set-up and management of GPIO irqchips and the +associated irqdomain and resource allocation callbacks, the gpiolib has +some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig +symbol: + +* gpiochip_irqchip_add(): adds an irqchip to a gpiochip. It will pass + the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks + need to embed the gpio_chip in its state container and obtain a pointer + to the container using container_of(). + (See Documentation/driver-model/design-patterns.txt) + +* gpiochip_set_chained_irqchip(): sets up a chained irq handler for a + gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler + data. (Notice handler data, since the irqchip data is likely used by the + parent irqchip!) This is for the chained type of chip. + +To use the helpers please keep the following in mind: + +- Make sure to assign all relevant members of the struct gpio_chip so that + the irqchip can initialize. E.g. .dev and .can_sleep shall be set up + properly. + +It is legal for any IRQ consumer to request an IRQ from any irqchip no matter +if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and +irq_chip are orthogonal, and offering their services independent of each +other. + +gpiod_to_irq() is just a convenience function to figure out the IRQ for a +certain GPIO line and should not be relied upon to have been called before +the IRQ is used. + +So always prepare the hardware and make it ready for action in respective +callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having +been called first. + +This orthogonality leads to ambiguities that we need to solve: if there is +competition inside the subsystem which side is using the resource (a certain +GPIO line and register for example) it needs to deny certain operations and +keep track of usage inside of the gpiolib subsystem. This is why the API +below exists. + + Locking IRQ usage ----------------- Input GPIOs can be used as IRQ signals. When this happens, a driver is requested @@ -73,3 +163,7 @@ This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock is released: void gpiod_unlock_as_irq(struct gpio_desc *desc) + +When implementing an irqchip inside a GPIO driver, these two functions should +typically be called in the .startup() and .shutdown() callbacks from the +irqchip. diff --git a/Documentation/hid/hid-transport.txt b/Documentation/hid/hid-transport.txt new file mode 100644 index 0000000..3dcba9f --- /dev/null +++ b/Documentation/hid/hid-transport.txt @@ -0,0 +1,317 @@ + HID I/O Transport Drivers + =========================== + +The HID subsystem is independent of the underlying transport driver. Initially, +only USB was supported, but other specifications adopted the HID design and +provided new transport drivers. The kernel includes at least support for USB, +Bluetooth, I2C and user-space I/O drivers. + +1) HID Bus +========== + +The HID subsystem is designed as a bus. Any I/O subsystem may provide HID +devices and register them with the HID bus. HID core then loads generic device +drivers on top of it. The transport drivers are responsible of raw data +transport and device setup/management. HID core is responsible of +report-parsing, report interpretation and the user-space API. Device specifics +and quirks are handled by all layers depending on the quirk. + + +-----------+ +-----------+ +-----------+ +-----------+ + | Device #1 | | Device #i | | Device #j | | Device #k | + +-----------+ +-----------+ +-----------+ +-----------+ + \\ // \\ // + +------------+ +------------+ + | I/O Driver | | I/O Driver | + +------------+ +------------+ + || || + +------------------+ +------------------+ + | Transport Driver | | Transport Driver | + +------------------+ +------------------+ + \___ ___/ + \ / + +----------------+ + | HID Core | + +----------------+ + / | | \ + / | | \ + ____________/ | | \_________________ + / | | \ + / | | \ + +----------------+ +-----------+ +------------------+ +------------------+ + | Generic Driver | | MT Driver | | Custom Driver #1 | | Custom Driver #2 | + +----------------+ +-----------+ +------------------+ +------------------+ + +Example Drivers: + I/O: USB, I2C, Bluetooth-l2cap + Transport: USB-HID, I2C-HID, BT-HIDP + +Everything below "HID Core" is simplified in this graph as it is only of +interest to HID device drivers. Transport drivers do not need to know the +specifics. + +1.1) Device Setup +----------------- + +I/O drivers normally provide hotplug detection or device enumeration APIs to the +transport drivers. Transport drivers use this to find any suitable HID device. +They allocate HID device objects and register them with HID core. Transport +drivers are not required to register themselves with HID core. HID core is never +aware of which transport drivers are available and is not interested in it. It +is only interested in devices. + +Transport drivers attach a constant "struct hid_ll_driver" object with each +device. Once a device is registered with HID core, the callbacks provided via +this struct are used by HID core to communicate with the device. + +Transport drivers are responsible of detecting device failures and unplugging. +HID core will operate a device as long as it is registered regardless of any +device failures. Once transport drivers detect unplug or failure events, they +must unregister the device from HID core and HID core will stop using the +provided callbacks. + +1.2) Transport Driver Requirements +---------------------------------- + +The terms "asynchronous" and "synchronous" in this document describe the +transmission behavior regarding acknowledgements. An asynchronous channel must +not perform any synchronous operations like waiting for acknowledgements or +verifications. Generally, HID calls operating on asynchronous channels must be +running in atomic-context just fine. +On the other hand, synchronous channels can be implemented by the transport +driver in whatever way they like. They might just be the same as asynchronous +channels, but they can also provide acknowledgement reports, automatic +retransmission on failure, etc. in a blocking manner. If such functionality is +required on asynchronous channels, a transport-driver must implement that via +its own worker threads. + +HID core requires transport drivers to follow a given design. A Transport +driver must provide two bi-directional I/O channels to each HID device. These +channels must not necessarily be bi-directional in the hardware itself. A +transport driver might just provide 4 uni-directional channels. Or it might +multiplex all four on a single physical channel. However, in this document we +will describe them as two bi-directional channels as they have several +properties in common. + + - Interrupt Channel (intr): The intr channel is used for asynchronous data + reports. No management commands or data acknowledgements are sent on this + channel. Any unrequested incoming or outgoing data report must be sent on + this channel and is never acknowledged by the remote side. Devices usually + send their input events on this channel. Outgoing events are normally + not send via intr, except if high throughput is required. + - Control Channel (ctrl): The ctrl channel is used for synchronous requests and + device management. Unrequested data input events must not be sent on this + channel and are normally ignored. Instead, devices only send management + events or answers to host requests on this channel. + The control-channel is used for direct blocking queries to the device + independent of any events on the intr-channel. + Outgoing reports are usually sent on the ctrl channel via synchronous + SET_REPORT requests. + +Communication between devices and HID core is mostly done via HID reports. A +report can be of one of three types: + + - INPUT Report: Input reports provide data from device to host. This + data may include button events, axis events, battery status or more. This + data is generated by the device and sent to the host with or without + requiring explicit requests. Devices can choose to send data continuously or + only on change. + - OUTPUT Report: Output reports change device states. They are sent from host + to device and may include LED requests, rumble requests or more. Output + reports are never sent from device to host, but a host can retrieve their + current state. + Hosts may choose to send output reports either continuously or only on + change. + - FEATURE Report: Feature reports are used for specific static device features + and never reported spontaneously. A host can read and/or write them to access + data like battery-state or device-settings. + Feature reports are never sent without requests. A host must explicitly set + or retrieve a feature report. This also means, feature reports are never sent + on the intr channel as this channel is asynchronous. + +INPUT and OUTPUT reports can be sent as pure data reports on the intr channel. +For INPUT reports this is the usual operational mode. But for OUTPUT reports, +this is rarely done as OUTPUT reports are normally quite scarce. But devices are +free to make excessive use of asynchronous OUTPUT reports (for instance, custom +HID audio speakers make great use of it). + +Plain reports must not be sent on the ctrl channel, though. Instead, the ctrl +channel provides synchronous GET/SET_REPORT requests. Plain reports are only +allowed on the intr channel and are the only means of data there. + + - GET_REPORT: A GET_REPORT request has a report ID as payload and is sent + from host to device. The device must answer with a data report for the + requested report ID on the ctrl channel as a synchronous acknowledgement. + Only one GET_REPORT request can be pending for each device. This restriction + is enforced by HID core as several transport drivers don't allow multiple + simultaneous GET_REPORT requests. + Note that data reports which are sent as answer to a GET_REPORT request are + not handled as generic device events. That is, if a device does not operate + in continuous data reporting mode, an answer to GET_REPORT does not replace + the raw data report on the intr channel on state change. + GET_REPORT is only used by custom HID device drivers to query device state. + Normally, HID core caches any device state so this request is not necessary + on devices that follow the HID specs except during device initialization to + retrieve the current state. + GET_REPORT requests can be sent for any of the 3 report types and shall + return the current report state of the device. However, OUTPUT reports as + payload may be blocked by the underlying transport driver if the + specification does not allow them. + - SET_REPORT: A SET_REPORT request has a report ID plus data as payload. It is + sent from host to device and a device must update it's current report state + according to the given data. Any of the 3 report types can be used. However, + INPUT reports as payload might be blocked by the underlying transport driver + if the specification does not allow them. + A device must answer with a synchronous acknowledgement. However, HID core + does not require transport drivers to forward this acknowledgement to HID + core. + Same as for GET_REPORT, only one SET_REPORT can be pending at a time. This + restriction is enforced by HID core as some transport drivers do not support + multiple synchronous SET_REPORT requests. + +Other ctrl-channel requests are supported by USB-HID but are not available +(or deprecated) in most other transport level specifications: + + - GET/SET_IDLE: Only used by USB-HID and I2C-HID. + - GET/SET_PROTOCOL: Not used by HID core. + - RESET: Used by I2C-HID, not hooked up in HID core. + - SET_POWER: Used by I2C-HID, not hooked up in HID core. + +2) HID API +========== + +2.1) Initialization +------------------- + +Transport drivers normally use the following procedure to register a new device +with HID core: + + struct hid_device *hid; + int ret; + + hid = hid_allocate_device(); + if (IS_ERR(hid)) { + ret = PTR_ERR(hid); + goto err_<...>; + } + + strlcpy(hid->name, <device-name-src>, 127); + strlcpy(hid->phys, <device-phys-src>, 63); + strlcpy(hid->uniq, <device-uniq-src>, 63); + + hid->ll_driver = &custom_ll_driver; + hid->bus = <device-bus>; + hid->vendor = <device-vendor>; + hid->product = <device-product>; + hid->version = <device-version>; + hid->country = <device-country>; + hid->dev.parent = <pointer-to-parent-device>; + hid->driver_data = <transport-driver-data-field>; + + ret = hid_add_device(hid); + if (ret) + goto err_<...>; + +Once hid_add_device() is entered, HID core might use the callbacks provided in +"custom_ll_driver". Note that fields like "country" can be ignored by underlying +transport-drivers if not supported. + +To unregister a device, use: + + hid_destroy_device(hid); + +Once hid_destroy_device() returns, HID core will no longer make use of any +driver callbacks. + +2.2) hid_ll_driver operations +----------------------------- + +The available HID callbacks are: + - int (*start) (struct hid_device *hdev) + Called from HID device drivers once they want to use the device. Transport + drivers can choose to setup their device in this callback. However, normally + devices are already set up before transport drivers register them to HID core + so this is mostly only used by USB-HID. + + - void (*stop) (struct hid_device *hdev) + Called from HID device drivers once they are done with a device. Transport + drivers can free any buffers and deinitialize the device. But note that + ->start() might be called again if another HID device driver is loaded on the + device. + Transport drivers are free to ignore it and deinitialize devices after they + destroyed them via hid_destroy_device(). + + - int (*open) (struct hid_device *hdev) + Called from HID device drivers once they are interested in data reports. + Usually, while user-space didn't open any input API/etc., device drivers are + not interested in device data and transport drivers can put devices asleep. + However, once ->open() is called, transport drivers must be ready for I/O. + ->open() calls are nested for each client that opens the HID device. + + - void (*close) (struct hid_device *hdev) + Called from HID device drivers after ->open() was called but they are no + longer interested in device reports. (Usually if user-space closed any input + devices of the driver). + Transport drivers can put devices asleep and terminate any I/O of all + ->open() calls have been followed by a ->close() call. However, ->start() may + be called again if the device driver is interested in input reports again. + + - int (*parse) (struct hid_device *hdev) + Called once during device setup after ->start() has been called. Transport + drivers must read the HID report-descriptor from the device and tell HID core + about it via hid_parse_report(). + + - int (*power) (struct hid_device *hdev, int level) + Called by HID core to give PM hints to transport drivers. Usually this is + analogical to the ->open() and ->close() hints and redundant. + + - void (*request) (struct hid_device *hdev, struct hid_report *report, + int reqtype) + Send an HID request on the ctrl channel. "report" contains the report that + should be sent and "reqtype" the request type. Request-type can be + HID_REQ_SET_REPORT or HID_REQ_GET_REPORT. + This callback is optional. If not provided, HID core will assemble a raw + report following the HID specs and send it via the ->raw_request() callback. + The transport driver is free to implement this asynchronously. + + - int (*wait) (struct hid_device *hdev) + Used by HID core before calling ->request() again. A transport driver can use + it to wait for any pending requests to complete if only one request is + allowed at a time. + + - int (*raw_request) (struct hid_device *hdev, unsigned char reportnum, + __u8 *buf, size_t count, unsigned char rtype, + int reqtype) + Same as ->request() but provides the report as raw buffer. This request shall + be synchronous. A transport driver must not use ->wait() to complete such + requests. This request is mandatory and hid core will reject the device if + it is missing. + + - int (*output_report) (struct hid_device *hdev, __u8 *buf, size_t len) + Send raw output report via intr channel. Used by some HID device drivers + which require high throughput for outgoing requests on the intr channel. This + must not cause SET_REPORT calls! This must be implemented as asynchronous + output report on the intr channel! + + - int (*idle) (struct hid_device *hdev, int report, int idle, int reqtype) + Perform SET/GET_IDLE request. Only used by USB-HID, do not implement! + +2.3) Data Path +-------------- + +Transport drivers are responsible of reading data from I/O devices. They must +handle any I/O-related state-tracking themselves. HID core does not implement +protocol handshakes or other management commands which can be required by the +given HID transport specification. + +Every raw data packet read from a device must be fed into HID core via +hid_input_report(). You must specify the channel-type (intr or ctrl) and report +type (input/output/feature). Under normal conditions, only input reports are +provided via this API. + +Responses to GET_REPORT requests via ->request() must also be provided via this +API. Responses to ->raw_request() are synchronous and must be intercepted by the +transport driver and not passed to hid_input_report(). +Acknowledgements to SET_REPORT requests are not of interest to HID core. + +---------------------------------------------------- +Written 2013, David Herrmann <dh.herrmann@gmail.com> diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt index 31cabfd..54c8f97 100644 --- a/Documentation/hid/uhid.txt +++ b/Documentation/hid/uhid.txt @@ -93,6 +93,11 @@ the request was handled successfully. event to the kernel. The payload is of type struct uhid_create_req and contains information about your device. You can start I/O now. + UHID_CREATE2: + Same as UHID_CREATE, but the HID report descriptor data (rd_data) is an array + inside struct uhid_create2_req, instead of a pointer to a separate array. + Enables use from languages that don't support pointers, e.g. Python. + UHID_DESTROY: This destroys the internal HID device. No further I/O will be accepted. There may still be pending messages that you can receive with read() but no further @@ -105,6 +110,12 @@ the request was handled successfully. contains a data-payload. This is the raw data that you read from your device. The kernel will parse the HID reports and react on it. + UHID_INPUT2: + Same as UHID_INPUT, but the data array is the last field of uhid_input2_req. + Enables userspace to write only the required bytes to kernel (ev.type + + ev.u.input2.size + the part of the data array that matters), instead of + the entire struct uhid_input2_req. + UHID_FEATURE_ANSWER: If you receive a UHID_FEATURE request you must answer with this request. You must copy the "id" field from the request into the answer. Set the "err" field diff --git a/Documentation/hsi.txt b/Documentation/hsi.txt new file mode 100644 index 0000000..6ac6cd5 --- /dev/null +++ b/Documentation/hsi.txt @@ -0,0 +1,75 @@ +HSI - High-speed Synchronous Serial Interface + +1. Introduction +~~~~~~~~~~~~~~~ + +High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol, +that is optimized for die-level interconnect between an Application Processor +and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and +implemented by multiple vendors since then. + +The HSI interface supports full duplex communication over multiple channels +(typically 8) and is capable of reaching speeds up to 200 Mbit/s. + +The serial protocol uses two signals, DATA and FLAG as combined data and clock +signals and an additional READY signal for flow control. An additional WAKE +signal can be used to wakeup the chips from standby modes. The signals are +commonly prefixed by AC for signals going from the application die to the +cellular die and CA for signals going the other way around. + ++------------+ +---------------+ +| Cellular | | Application | +| Die | | Die | +| | - - - - - - CAWAKE - - - - - - >| | +| T|------------ CADATA ------------>|R | +| X|------------ CAFLAG ------------>|X | +| |<----------- ACREADY ------------| | +| | | | +| | | | +| |< - - - - - ACWAKE - - - - - - -| | +| R|<----------- ACDATA -------------|T | +| X|<----------- ACFLAG -------------|X | +| |------------ CAREADY ----------->| | +| | | | +| | | | ++------------+ +---------------+ + +2. HSI Subsystem in Linux +~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the Linux kernel the hsi subsystem is supposed to be used for HSI devices. +The hsi subsystem contains drivers for hsi controllers including support for +multi-port controllers and provides a generic API for using the HSI ports. + +It also contains HSI client drivers, which make use of the generic API to +implement a protocol used on the HSI interface. These client drivers can +use an arbitrary number of channels. + +3. hsi-char Device +~~~~~~~~~~~~~~~~~~ + +Each port automatically registers a generic client driver called hsi_char, +which provides a charecter device for userspace representing the HSI port. +It can be used to communicate via HSI from userspace. Userspace may +configure the hsi_char device using the following ioctl commands: + +* HSC_RESET: + - flush the HSI port + +* HSC_SET_PM + - enable or disable the client. + +* HSC_SEND_BREAK + - send break + +* HSC_SET_RX + - set RX configuration + +* HSC_GET_RX + - get RX configuration + +* HSC_SET_TX + - set TX configuration + +* HSC_GET_TX + - get TX configuration diff --git a/Documentation/hwmon/emc1403 b/Documentation/hwmon/emc1403 new file mode 100644 index 0000000..a869b0e --- /dev/null +++ b/Documentation/hwmon/emc1403 @@ -0,0 +1,59 @@ +Kernel driver emc1403 +===================== + +Supported chips: + * SMSC / Microchip EMC1402, EMC1412 + Addresses scanned: I2C 0x18, 0x1c, 0x29, 0x4c, 0x4d, 0x5c + Prefix: 'emc1402' + Datasheets: + http://ww1.microchip.com/downloads/en/DeviceDoc/1412.pdf + http://ww1.microchip.com/downloads/en/DeviceDoc/1402.pdf + * SMSC / Microchip EMC1403, EMC1404, EMC1413, EMC1414 + Addresses scanned: I2C 0x18, 0x29, 0x4c, 0x4d + Prefix: 'emc1403', 'emc1404' + Datasheets: + http://ww1.microchip.com/downloads/en/DeviceDoc/1403_1404.pdf + http://ww1.microchip.com/downloads/en/DeviceDoc/1413_1414.pdf + * SMSC / Microchip EMC1422 + Addresses scanned: I2C 0x4c + Prefix: 'emc1422' + Datasheet: + http://ww1.microchip.com/downloads/en/DeviceDoc/1422.pdf + * SMSC / Microchip EMC1423, EMC1424 + Addresses scanned: I2C 0x4c + Prefix: 'emc1423', 'emc1424' + Datasheet: + http://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf + +Author: + Kalhan Trisal <kalhan.trisal@intel.com + + +Description +----------- + +The Standard Microsystems Corporation (SMSC) / Microchip EMC14xx chips +contain up to four temperature sensors. EMC14x2 support two sensors +(one internal, one external). EMC14x3 support three sensors (one internal, +two external), and EMC14x4 support four sensors (one internal, three +external). + +The chips implement three limits for each sensor: low (tempX_min), high +(tempX_max) and critical (tempX_crit.) The chips also implement an +hysteresis mechanism which applies to all limits. The relative difference +is stored in a single register on the chip, which means that the relative +difference between the limit and its hysteresis is always the same for +all three limits. + +This implementation detail implies the following: +* When setting a limit, its hysteresis will automatically follow, the + difference staying unchanged. For example, if the old critical limit + was 80 degrees C, and the hysteresis was 75 degrees C, and you change + the critical limit to 90 degrees C, then the hysteresis will + automatically change to 85 degrees C. +* The hysteresis values can't be set independently. We decided to make + only temp1_crit_hyst writable, while all other hysteresis attributes + are read-only. Setting temp1_crit_hyst writes the difference between + temp1_crit_hyst and temp1_crit into the chip, and the same relative + hysteresis applies automatically to all other limits. +* The limits should be set before the hysteresis. diff --git a/Documentation/hwmon/hwmon-kernel-api.txt b/Documentation/hwmon/hwmon-kernel-api.txt new file mode 100644 index 0000000..2ecdbfc --- /dev/null +++ b/Documentation/hwmon/hwmon-kernel-api.txt @@ -0,0 +1,107 @@ +The Linux Hardware Monitoring kernel API. +========================================= + +Guenter Roeck + +Introduction +------------ + +This document describes the API that can be used by hardware monitoring +drivers that want to use the hardware monitoring framework. + +This document does not describe what a hardware monitoring (hwmon) Driver or +Device is. It also does not describe the API which can be used by user space +to communicate with a hardware monitoring device. If you want to know this +then please read the following file: Documentation/hwmon/sysfs-interface. + +For additional guidelines on how to write and improve hwmon drivers, please +also read Documentation/hwmon/submitting-patches. + +The API +------- +Each hardware monitoring driver must #include <linux/hwmon.h> and, in most +cases, <linux/hwmon-sysfs.h>. linux/hwmon.h declares the following +register/unregister functions: + +struct device *hwmon_device_register(struct device *dev); +struct device * +hwmon_device_register_with_groups(struct device *dev, const char *name, + void *drvdata, + const struct attribute_group **groups); + +struct device * +devm_hwmon_device_register_with_groups(struct device *dev, + const char *name, void *drvdata, + const struct attribute_group **groups); + +void hwmon_device_unregister(struct device *dev); +void devm_hwmon_device_unregister(struct device *dev); + +hwmon_device_register registers a hardware monitoring device. The parameter +of this function is a pointer to the parent device. +This function returns a pointer to the newly created hardware monitoring device +or PTR_ERR for failure. If this registration function is used, hardware +monitoring sysfs attributes are expected to have been created and attached to +the parent device prior to calling hwmon_device_register. A name attribute must +have been created by the caller. + +hwmon_device_register_with_groups is similar to hwmon_device_register. However, +it has additional parameters. The name parameter is a pointer to the hwmon +device name. The registration function wil create a name sysfs attribute +pointing to this name. The drvdata parameter is the pointer to the local +driver data. hwmon_device_register_with_groups will attach this pointer +to the newly allocated hwmon device. The pointer can be retrieved by the driver +using dev_get_drvdata() on the hwmon device pointer. The groups parameter is +a pointer to a list of sysfs attribute groups. The list must be NULL terminated. +hwmon_device_register_with_groups creates the hwmon device with name attribute +as well as all sysfs attributes attached to the hwmon device. + +devm_hwmon_device_register_with_groups is similar to +hwmon_device_register_with_groups. However, it is device managed, meaning the +hwmon device does not have to be removed explicitly by the removal function. + +hwmon_device_unregister deregisters a registered hardware monitoring device. +The parameter of this function is the pointer to the registered hardware +monitoring device structure. This function must be called from the driver +remove function if the hardware monitoring device was registered with +hwmon_device_register or with hwmon_device_register_with_groups. + +devm_hwmon_device_unregister does not normally have to be called. It is only +needed for error handling, and only needed if the driver probe fails after +the call to devm_hwmon_device_register_with_groups. + +The header file linux/hwmon-sysfs.h provides a number of useful macros to +declare and use hardware monitoring sysfs attributes. + +In many cases, you can use the exsting define DEVICE_ATTR to declare such +attributes. This is feasible if an attribute has no additional context. However, +in many cases there will be additional information such as a sensor index which +will need to be passed to the sysfs attribute handling function. + +SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 can be used to define attributes +which need such additional context information. SENSOR_DEVICE_ATTR requires +one additional argument, SENSOR_DEVICE_ATTR_2 requires two. + +SENSOR_DEVICE_ATTR defines a struct sensor_device_attribute variable. +This structure has the following fields. + +struct sensor_device_attribute { + struct device_attribute dev_attr; + int index; +}; + +You can use to_sensor_dev_attr to get the pointer to this structure from the +attribute read or write function. Its parameter is the device to which the +attribute is attached. + +SENSOR_DEVICE_ATTR_2 defines a struct sensor_device_attribute_2 variable, +which is defined as follows. + +struct sensor_device_attribute_2 { + struct device_attribute dev_attr; + u8 index; + u8 nr; +}; + +Use to_sensor_dev_attr_2 to get the pointer to this structure. Its parameter +is the device to which the attribute is attached. diff --git a/Documentation/hwmon/ibmpowernv b/Documentation/hwmon/ibmpowernv new file mode 100644 index 0000000..8826ba2 --- /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/it87 b/Documentation/hwmon/it87 index 0c16350..fe80e9a 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -2,7 +2,7 @@ Kernel driver it87 ================== Supported chips: - * IT8603E + * IT8603E/IT8623E Prefix: 'it8603' Addresses scanned: from Super I/O config space (8 I/O ports) Datasheet: Not publicly available @@ -94,9 +94,9 @@ motherboard models. Description ----------- -This driver implements support for the IT8603E, IT8705F, IT8712F, IT8716F, -IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E, IT8772E, -IT8782F, IT8783E/F, and SiS950 chips. +This driver implements support for the IT8603E, IT8623E, IT8705F, IT8712F, +IT8716F, IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E, +IT8772E, IT8782F, IT8783E/F, and SiS950 chips. These chips are 'Super I/O chips', supporting floppy disks, infrared ports, joysticks and other miscellaneous stuff. For hardware monitoring, they @@ -133,7 +133,7 @@ to userspace applications. The IT8728F, IT8771E, and IT8772E are considered compatible with the IT8721F, until a datasheet becomes available (hopefully.) -The IT8603E is a custom design, hardware monitoring part is similar to +The IT8603E/IT8623E is a custom design, hardware monitoring part is similar to IT8728F. It only supports 16-bit fan mode, the full speed mode of the fan is not supported (value 0 of pwmX_enable). diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42 index 868d74d..f3893f7 100644 --- a/Documentation/hwmon/jc42 +++ b/Documentation/hwmon/jc42 @@ -5,9 +5,12 @@ Supported chips: * Analog Devices ADT7408 Datasheets: http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf - * Atmel AT30TS00 + * Atmel AT30TS00, AT30TS002A/B, AT30TSE004A Datasheets: http://www.atmel.com/Images/doc8585.pdf + http://www.atmel.com/Images/doc8711.pdf + http://www.atmel.com/Images/Atmel-8852-SEEPROM-AT30TSE002A-Datasheet.pdf + http://www.atmel.com/Images/Atmel-8868-DTS-AT30TSE004A-Datasheet.pdf * IDT TSE2002B3, TSE2002GB2, TS3000B3, TS3000GB2 Datasheets: http://www.idt.com/sites/default/files/documents/IDT_TSE2002B3C_DST_20100512_120303152056.pdf @@ -34,12 +37,13 @@ Supported chips: Datasheet: http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF - * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS3000 + * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS2004, STTS3000 Datasheets: - http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157556.pdf - http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157558.pdf - http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00225278.pdf - http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/CD00270920.pdf + http://www.st.com/web/en/resource/technical/document/datasheet/CD00157556.pdf + http://www.st.com/web/en/resource/technical/document/datasheet/CD00157558.pdf + http://www.st.com/web/en/resource/technical/document/datasheet/CD00266638.pdf + http://www.st.com/web/en/resource/technical/document/datasheet/CD00225278.pdf + http://www.st.com/web/en/resource/technical/document/datasheet/DM00076709.pdf * JEDEC JC 42.4 compliant temperature sensor chips Datasheet: http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp index 4dfdc8f..ee6d30e 100644 --- a/Documentation/hwmon/k10temp +++ b/Documentation/hwmon/k10temp @@ -11,8 +11,8 @@ Supported chips: Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series) * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series) -* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity" -* AMD Family 16h processors: "Kabini" +* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri" +* AMD Family 16h processors: "Kabini", "Mullins" Prefix: 'k10temp' Addresses scanned: PCI space @@ -46,7 +46,7 @@ Description ----------- This driver permits reading of the internal temperature sensor of AMD -Family 10h/11h/12h/14h/15h processors. +Family 10h/11h/12h/14h/15h/16h processors. All these processors have a sensor, but on those for Socket F or AM2+, the sensor may return inconsistent values (erratum 319). The driver diff --git a/Documentation/hwmon/lm75 b/Documentation/hwmon/lm75 index 2560a9c..c6a5ff1 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/lm77 b/Documentation/hwmon/lm77 index 57c3a46..bfc915f 100644 --- a/Documentation/hwmon/lm77 +++ b/Documentation/hwmon/lm77 @@ -18,5 +18,21 @@ sensor incorporates a band-gap type temperature sensor, 10-bit ADC, and a digital comparator with user-programmable upper and lower limit values. -Limits can be set through the Overtemperature Shutdown register and -Hysteresis register. +The LM77 implements 3 limits: low (temp1_min), high (temp1_max) and +critical (temp1_crit.) It also implements an hysteresis mechanism which +applies to all 3 limits. The relative difference is stored in a single +register on the chip, which means that the relative difference between +the limit and its hysteresis is always the same for all 3 limits. + +This implementation detail implies the following: +* When setting a limit, its hysteresis will automatically follow, the + difference staying unchanged. For example, if the old critical limit + was 80 degrees C, and the hysteresis was 75 degrees C, and you change + the critical limit to 90 degrees C, then the hysteresis will + automatically change to 85 degrees C. +* All 3 hysteresis can't be set independently. We decided to make + temp1_crit_hyst writable, while temp1_min_hyst and temp1_max_hyst are + read-only. Setting temp1_crit_hyst writes the difference between + temp1_crit_hyst and temp1_crit into the chip, and the same relative + hysteresis applies automatically to the low and high limits. +* The limits should be set before the hysteresis. diff --git a/Documentation/hwmon/nct6683 b/Documentation/hwmon/nct6683 new file mode 100644 index 0000000..c1301d4 --- /dev/null +++ b/Documentation/hwmon/nct6683 @@ -0,0 +1,57 @@ +Kernel driver nct6683 +===================== + +Supported chips: + * Nuvoton NCT6683D + Prefix: 'nct6683' + Addresses scanned: ISA address retrieved from Super I/O registers + Datasheet: Available from Nuvoton upon request + +Authors: + Guenter Roeck <linux@roeck-us.net> + +Description +----------- + +This driver implements support for the Nuvoton NCT6683D eSIO chip. + +The chips implement up to shared 32 temperature and voltage sensors. +It supports up to 16 fan rotation sensors and up to 8 fan control engines. + +Temperatures are measured in degrees Celsius. Measurement resolution is +0.5 degrees C. + +Voltage sensors (also known as IN sensors) report their values in millivolts. + +Fan rotation speeds are reported in RPM (rotations per minute). + +Usage Note +---------- + +Limit register locations on Intel boards with EC firmware version 1.0 +build date 04/03/13 do not match the register locations in the Nuvoton +datasheet. Nuvoton confirms that Intel uses a special firmware version +with different register addresses. The specification describing the Intel +firmware is held under NDA by Nuvoton and Intel and not available +to the public. + +Some of the register locations can be reverse engineered; others are too +well hidden. Given this, writing any values from the operating system is +considered too risky with this firmware and has been disabled. All limits +must all be written from the BIOS. + +The driver has only been tested with the Intel firmware, and by default +only instantiates on Intel boards. To enable it on non-Intel boards, +set the 'force' module parameter to 1. + +Tested Boards and Firmware Versions +----------------------------------- + +The driver has been reported to work with the following boards and +firmware versions. + +Board Firmware version +--------------------------------------------------------------- +Intel DH87RL NCT6683D EC firmware version 1.0 build 04/03/13 +Intel DH87MC NCT6683D EC firmware version 1.0 build 04/03/13 +Intel DB85FL NCT6683D EC firmware version 1.0 build 04/03/13 diff --git a/Documentation/hwmon/ntc_thermistor b/Documentation/hwmon/ntc_thermistor index 3bfda94..c5e05e2 100644 --- a/Documentation/hwmon/ntc_thermistor +++ b/Documentation/hwmon/ntc_thermistor @@ -1,11 +1,16 @@ Kernel driver ntc_thermistor ================= -Supported thermistors: +Supported thermistors from Murata: * Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, NCP15WL333 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. @@ -15,9 +20,9 @@ Authors: Description ----------- -The NTC thermistor is a simple thermistor that requires users to provide the -resistance and lookup the corresponding compensation table to get the -temperature input. +The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor +that requires users to provide the resistance and lookup the corresponding +compensation table to get the temperature input. The NTC driver provides lookup tables with a linear approximation function and four circuit models with an option not to use any of the four models. diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus index cf756ed..a3557da 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 0000000..21e44f7 --- /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 0000000..18529d2 --- /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/shtc1 b/Documentation/hwmon/shtc1 new file mode 100644 index 0000000..6b1e054 --- /dev/null +++ b/Documentation/hwmon/shtc1 @@ -0,0 +1,43 @@ +Kernel driver shtc1 +=================== + +Supported chips: + * Sensirion SHTC1 + Prefix: 'shtc1' + Addresses scanned: none + Datasheet: http://www.sensirion.com/file/datasheet_shtc1 + + * Sensirion SHTW1 + Prefix: 'shtw1' + Addresses scanned: none + Datasheet: Not publicly available + +Author: + Johannes Winkelmann <johannes.winkelmann@sensirion.com> + +Description +----------- + +This driver implements support for the Sensirion SHTC1 chip, a humidity and +temperature sensor. Temperature is measured in degrees celsius, relative +humidity is expressed as a percentage. Driver can be used as well for SHTW1 +chip, which has the same electrical interface. + +The device communicates with the I2C protocol. All sensors are set to I2C +address 0x70. See Documentation/i2c/instantiating-devices for methods to +instantiate the device. + +There are two options configurable by means of shtc1_platform_data: +1. blocking (pull the I2C clock line down while performing the measurement) or + non-blocking mode. Blocking mode will guarantee the fastest result but + the I2C bus will be busy during that time. By default, non-blocking mode + is used. Make sure clock-stretching works properly on your device if you + want to use blocking mode. +2. high or low accuracy. High accuracy is used by default and using it is + strongly recommended. + +sysfs-Interface +--------------- + +temp1_input - temperature input +humidity1_input - humidity input diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index 79f8257..2cc95ad 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -327,6 +327,13 @@ temp[1-*]_max_hyst from the max value. RW +temp[1-*]_min_hyst + Temperature hysteresis value for min limit. + Unit: millidegree Celsius + Must be reported as an absolute temperature, NOT a delta + from the min value. + RW + temp[1-*]_input Temperature input value. Unit: millidegree Celsius RO @@ -362,6 +369,13 @@ temp[1-*]_lcrit Temperature critical min value, typically lower than Unit: millidegree Celsius RW +temp[1-*]_lcrit_hyst + Temperature hysteresis value for critical min limit. + Unit: millidegree Celsius + Must be reported as an absolute temperature, NOT a delta + from the critical min value. + RW + temp[1-*]_offset Temperature offset which is added to the temperature reading by the chip. diff --git a/Documentation/hwmon/tmp103 b/Documentation/hwmon/tmp103 new file mode 100644 index 0000000..ec00a15 --- /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 0cf07f82..9e6fe55 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 0000000..24bb068 --- /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/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index aaaf0693..adf5e33 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -26,6 +26,7 @@ Supported adapters: * Intel Wellsburg (PCH) * Intel Coleto Creek (PCH) * Intel Wildcat Point-LP (PCH) + * Intel BayTrail (SOC) Datasheets: Publicly available at the Intel website On Intel Patsburg and later chipsets, both the normal host SMBus controller diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality index b0ff2ab..4556a3e 100644 --- a/Documentation/i2c/functionality +++ b/Documentation/i2c/functionality @@ -46,7 +46,7 @@ A few combinations of the above flags are also defined for your convenience: and write_block_data commands I2C_FUNC_SMBUS_I2C_BLOCK Handles the SMBus read_i2c_block_data and write_i2c_block_data commands - I2C_FUNC_SMBUS_EMUL Handles all SMBus commands than can be + I2C_FUNC_SMBUS_EMUL Handles all SMBus commands that can be emulated by a real I2C adapter (using the transparent emulation layer) diff --git a/Documentation/i2c/i2c-protocol b/Documentation/i2c/i2c-protocol index 0b3e62d..ff6d6ce 100644 --- a/Documentation/i2c/i2c-protocol +++ b/Documentation/i2c/i2c-protocol @@ -6,8 +6,8 @@ Key to symbols S (1 bit) : Start bit P (1 bit) : Stop bit Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0. -A, NA (1 bit) : Accept and reverse accept bit. -Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to +A, NA (1 bit) : Accept and reverse accept bit. +Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to get a 10 bit I2C address. Comm (8 bits): Command byte, a data byte which often selects a register on the device. @@ -49,11 +49,20 @@ a byte read, followed by a byte write: Modified transactions ===================== -The following modifications to the I2C protocol can also be generated, -with the exception of I2C_M_NOSTART these are usually only needed to -work around device issues: +The following modifications to the I2C protocol can also be generated by +setting these flags for i2c messages. With the exception of I2C_M_NOSTART, they +are usually only needed to work around device issues: - Flag I2C_M_NOSTART: +I2C_M_IGNORE_NAK: + Normally message is interrupted immediately if there is [NA] from the + client. Setting this flag treats any [NA] as [A], and all of + message is sent. + These messages may still fail to SCL lo->hi timeout. + +I2C_M_NO_RD_ACK: + In a read message, master A/NA bit is skipped. + +I2C_M_NOSTART: In a combined transaction, no 'S Addr Wr/Rd [A]' is generated at some point. For example, setting I2C_M_NOSTART on the second partial message generates something like: @@ -67,17 +76,13 @@ work around device issues: I2C device but may also be used between direction changes by some rare devices. - Flags I2C_M_REV_DIR_ADDR +I2C_M_REV_DIR_ADDR: This toggles the Rd/Wr flag. That is, if you want to do a write, but need to emit an Rd instead of a Wr, or vice versa, you set this flag. For example: S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P - Flags I2C_M_IGNORE_NAK - Normally message is interrupted immediately if there is [NA] from the - client. Setting this flag treats any [NA] as [A], and all of - message is sent. - These messages may still fail to SCL lo->hi timeout. - - Flags I2C_M_NO_RD_ACK - In a read message, master A/NA bit is skipped. +I2C_M_STOP: + Force a stop condition (P) after the message. Some I2C related protocols + like SCCB require that. Normally, you really don't want to get interrupted + between the messages of one transfer. diff --git a/Documentation/input/elantech.txt b/Documentation/input/elantech.txt index 5602eb7..e1ae127 100644 --- a/Documentation/input/elantech.txt +++ b/Documentation/input/elantech.txt @@ -504,9 +504,12 @@ byte 5: * reg_10 bit 7 6 5 4 3 2 1 0 - 0 0 0 0 0 0 0 A + 0 0 0 0 R F T A A: 1 = enable absolute tracking + T: 1 = enable two finger mode auto correct + F: 1 = disable ABS Position Filter + R: 1 = enable real hardware resolution 6.2 Native absolute mode 6 byte packet format ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/input/event-codes.txt b/Documentation/input/event-codes.txt index f1ea2c6..c587a96 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 d7e43fa..7e240a7 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/irqflags-tracing.txt b/Documentation/irqflags-tracing.txt index 67aa71e..f6da056 100644 --- a/Documentation/irqflags-tracing.txt +++ b/Documentation/irqflags-tracing.txt @@ -22,13 +22,6 @@ rather straightforward and risk-free manner. Architectures that want to support this need to do a couple of code-organizational changes first: -- move their irq-flags manipulation code from their asm/system.h header - to asm/irqflags.h - -- rename local_irq_disable()/etc to raw_local_irq_disable()/etc. so that - the linux/irqflags.h code can inject callbacks and can construct the - real local_irq_disable()/etc APIs. - - add and enable TRACE_IRQFLAGS_SUPPORT in their arch level Kconfig file and then a couple of functional changes are needed as well to implement diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO index 0091a82..b61885c 100644 --- a/Documentation/ja_JP/HOWTO +++ b/Documentation/ja_JP/HOWTO @@ -315,7 +315,7 @@ Andrew Morton が Linux-kernel メーリングリストにカーネルリリー もし、3.x.y カーネルが存在しない場合には、番号が一番大きい 3.x が 最新の安定版カーネルです。 -3.x.y は "stable" チーム <stable@kernel.org> でメンテされており、必 +3.x.y は "stable" チーム <stable@vger.kernel.org> でメンテされており、必 要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差し迫っ た問題がなければもう少し長くなることもあります。セキュリティ関連の問題 の場合はこれに対してだいたいの場合、すぐにリリースがされます。 diff --git a/Documentation/ja_JP/SubmittingPatches b/Documentation/ja_JP/SubmittingPatches index 97f78dd..5d6ae63 100644 --- a/Documentation/ja_JP/SubmittingPatches +++ b/Documentation/ja_JP/SubmittingPatches @@ -98,11 +98,6 @@ dontdiff ファイルには Linux カーネルのビルドプロセスの過程 Quilt: http://savannah.nongnu.org/projects/quilt -Andrew Morton's patch scripts: -http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz -このリンクの先のスクリプトの代わりとして、quilt がパッチマネジメント -ツールとして推奨されています(上のリンクを見てください)。 - 2) パッチに対する説明 パッチの中の変更点に対する技術的な詳細について説明してください。 @@ -695,7 +690,7 @@ gcc においては、マクロと同じくらい軽いです。 ---------------------- Andrew Morton, "The perfect patch" (tpp). - <http://userweb.kernel.org/~akpm/stuff/tpp.txt> + <http://www.ozlabs.org/~akpm/stuff/tpp.txt> Jeff Garzik, "Linux kernel patch submission format". <http://linux.yyz.us/patch-format.html> @@ -707,7 +702,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". <http://www.kroah.com/log/2006/01/11/> NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! - <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> + <https://lkml.org/lkml/2005/7/11/336> Kernel Documentation/CodingStyle: <http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle> diff --git a/Documentation/ja_JP/stable_kernel_rules.txt b/Documentation/ja_JP/stable_kernel_rules.txt index 1426583..9dbda9b 100644 --- a/Documentation/ja_JP/stable_kernel_rules.txt +++ b/Documentation/ja_JP/stable_kernel_rules.txt @@ -50,16 +50,16 @@ linux-2.6.29/Documentation/stable_kernel_rules.txt -stable ツリーにパッチを送付する手続き- - - 上記の規則に従っているかを確認した後に、stable@kernel.org にパッチ + - 上記の規則に従っているかを確認した後に、stable@vger.kernel.org にパッチ を送る。 - 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合 には NAK を受け取る。この反応は開発者たちのスケジュールによって、数 日かかる場合がある。 - もし受け取られたら、パッチは他の開発者たちと関連するサブシステムの メンテナーによるレビューのために -stable キューに追加される。 - - パッチに stable@kernel.org のアドレスが付加されているときには、それ + - パッチに stable@vger.kernel.org のアドレスが付加されているときには、それ が Linus のツリーに入る時に自動的に stable チームに email される。 - - セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ + - セキュリティパッチはこのエイリアス (stable@vger.kernel.org) に送られるべ きではなく、代わりに security@kernel.org のアドレスに送られる。 レビューサイクル- diff --git a/Documentation/java.txt b/Documentation/java.txt index e6a7232..4180205 100644 --- a/Documentation/java.txt +++ b/Documentation/java.txt @@ -188,6 +188,9 @@ shift #define CP_METHODREF 10 #define CP_INTERFACEMETHODREF 11 #define CP_NAMEANDTYPE 12 +#define CP_METHODHANDLE 15 +#define CP_METHODTYPE 16 +#define CP_INVOKEDYNAMIC 18 /* Define some commonly used error messages */ @@ -242,14 +245,19 @@ void skip_constant(FILE *classfile, u_int16_t *cur) break; case CP_CLASS: case CP_STRING: + case CP_METHODTYPE: seekerr = fseek(classfile, 2, SEEK_CUR); break; + case CP_METHODHANDLE: + seekerr = fseek(classfile, 3, SEEK_CUR); + break; case CP_INTEGER: case CP_FLOAT: case CP_FIELDREF: case CP_METHODREF: case CP_INTERFACEMETHODREF: case CP_NAMEANDTYPE: + case CP_INVOKEDYNAMIC: seekerr = fseek(classfile, 4, SEEK_CUR); break; case CP_LONG: diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index c420676..350f733 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -157,6 +157,10 @@ applicable everywhere (see syntax). to the build environment (if this is desired, it can be done via another symbol). + - "allnoconfig_y" + This declares the symbol as one that should have the value y when + using "allnoconfig". Used for symbols that hide other symbols. + Menu dependencies ----------------- diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index d567a7c..c600e2f 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -1171,7 +1171,7 @@ When kbuild executes, the following steps are followed (roughly): obvious reason. dtc - Create flattend device tree blob object suitable for linking + Create flattened device tree blob object suitable for linking into vmlinux. Device tree blobs linked into vmlinux are placed in an init section in the image. Platform code *must* copy the blob to non-init memory prior to calling unflatten_device_tree(). diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index 69372fb..3fb39e0 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -470,7 +470,7 @@ build. Sometimes, an external module uses exported symbols from another external module. kbuild needs to have full knowledge of - all symbols to avoid spliitting out warnings about undefined + all symbols to avoid spitting out warnings about undefined symbols. Three solutions exist for this situation. NOTE: The method with a top-level kbuild file is recommended diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index bc34785..883901b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1,27 +1,37 @@ Kernel Parameters ~~~~~~~~~~~~~~~~~ -The following is a consolidated list of the kernel parameters as implemented -(mostly) by the __setup() macro and sorted into English Dictionary order -(defined as ignoring all punctuation and sorting digits before letters in a -case insensitive manner), and with descriptions where known. - -Module parameters for loadable modules are specified only as the -parameter name with optional '=' and value as appropriate, such as: - - modprobe usbcore blinkenlights=1 - -Module parameters for modules that are built into the kernel image -are specified on the kernel command line with the module name plus -'.' plus parameter name, with '=' and value if appropriate, such as: - - usbcore.blinkenlights=1 +The following is a consolidated list of the kernel parameters as +implemented by the __setup(), core_param() and module_param() macros +and sorted into English Dictionary order (defined as ignoring all +punctuation and sorting digits before letters in a case insensitive +manner), and with descriptions where known. + +The kernel parses parameters from the kernel command line up to "--"; +if it doesn't recognize a parameter and it doesn't contain a '.', the +parameter gets passed to init: parameters with '=' go into init's +environment, others are passed as command line arguments to init. +Everything after "--" is passed as an argument to init. + +Module parameters can be specified in two ways: via the kernel command +line with a module name prefix, or via modprobe, e.g.: + + (kernel command line) usbcore.blinkenlights=1 + (modprobe command line) modprobe usbcore blinkenlights=1 + +Parameters for modules which are built into the kernel need to be +specified on the kernel command line. modprobe looks through the +kernel command line (/proc/cmdline) and collects module parameters +when it loads a module, so the kernel command line can be used for +loadable modules too. Hyphens (dashes) and underscores are equivalent in parameter names, so log_buf_len=1M print-fatal-signals=1 can also be entered as log-buf-len=1M print_fatal_signals=1 +Double-quotes can be used to protect spaces in values, e.g.: + param="spaces in here" This document may not be entirely up to date and comprehensive. The command "modinfo -p ${modulename}" shows a current list of all parameters of a loadable @@ -214,6 +224,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. unusable. The "log_buf_len" parameter may be useful if you need to capture more output. + acpi_force_table_verification [HW,ACPI] + Enable table checksum verification during early stage. + By default, this is disabled due to x86 early mapping + size limitation. + acpi_irq_balance [HW,ACPI] ACPI will balance active IRQs default in APIC mode @@ -237,7 +252,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted. This feature is enabled by default. This option allows to turn off the feature. - acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT + acpi_no_static_ssdt [HW,ACPI] + Disable installation of static SSDTs at early boot time + By default, SSDTs contained in the RSDT/XSDT will be + installed automatically and they will appear under + /sys/firmware/acpi/tables. + This option turns off this feature. + Note that specifying this option does not affect + dynamic table installation which will install SSDT + tables to /sys/firmware/acpi/tables/dynamic. acpica_no_return_repair [HW, ACPI] Disable AML predefined validation mechanism @@ -543,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. @@ -617,8 +645,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Also note the kernel might malfunction if you disable some critical bits. - cma=nn[MG] [ARM,KNL] - Sets the size of kernel global memory area for contiguous + cma=nn[MG]@[start[MG][-end[MG]]] + [ARM,X86,KNL] + Sets the size of kernel global memory area for + contiguous memory allocations and optionally the + placement constraint by the physical address range of memory allocations. For more information, see include/linux/dma-contiguous.h @@ -804,13 +835,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. dhash_entries= [KNL] Set number of hash buckets for dentry cache. - digi= [HW,SERIAL] - IO parameters + enable/disable command. - - digiepca= [HW,SERIAL] - See drivers/char/README.epca and - Documentation/serial/digiepca.txt. - disable= [IPV6] See Documentation/networking/ipv6.txt. @@ -884,7 +908,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Enable debug messages at boot time. See Documentation/dynamic-debug-howto.txt for details. + early_ioremap_debug [KNL] + Enable debug messages in early_ioremap support. This + is useful for tracking down temporary early mappings + which are not unmapped. + earlycon= [KNL] Output early console device and options. + uart[8250],io,<addr>[,options] uart[8250],mmio,<addr>[,options] uart[8250],mmio32,<addr>[,options] @@ -894,7 +924,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted. (mmio) or 32-bit (mmio32). The options are the same as for ttyS, above. - earlyprintk= [X86,SH,BLACKFIN,ARM] + pl011,<addr> + Start an early, polled-mode console on a pl011 serial + port at the specified address. The pl011 serial port + must already be setup and configured. Options are not + yet supported. + + smh Use ARM semihosting calls for early console. + + earlyprintk= [X86,SH,BLACKFIN,ARM,M68k] earlyprintk=vga earlyprintk=efi earlyprintk=xen @@ -1064,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) @@ -1280,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 @@ -1289,6 +1350,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. for working out where the kernel is dying during startup. + initcall_blacklist= [KNL] Do not execute a comma-separated list of + initcall functions. Useful for debugging built-in + modules and initcalls. + initrd= [BOOT] Specify the location of the initial ramdisk inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver @@ -1379,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 @@ -1437,6 +1498,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. js= [HW,JOY] Analog joystick See Documentation/input/joystick.txt. + kaslr/nokaslr [X86] + Enable/disable kernel and module base offset ASLR + (Address Space Layout Randomization) if built into + the kernel. When CONFIG_HIBERNATION is selected, + kASLR is disabled by default. When kASLR is enabled, + hibernation will be disabled. + keepinitrd [HW,ARM] kernelcore=nn[KMG] [KNL,X86,IA-64,PPC] This parameter @@ -2073,10 +2141,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. noapic [SMP,APIC] Tells the kernel to not make use of any IOAPICs that may be present in the system. - nokaslr [X86] - Disable kernel and module base offset ASLR (Address - Space Layout Randomization) if built into the kernel. - noautogroup Disable scheduler automatic task group creation. nobats [PPC] Do not use BATs for mapping kernel lowmem @@ -2147,6 +2211,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. in certain environments such as networked servers or real-time systems. + nohibernate [HIBERNATION] Disable hibernation and resume. + nohz= [KNL] Boottime enable/disable dynamic ticks Valid arguments: on, off Default: on @@ -2220,10 +2286,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. noreplace-smp [X86-32,SMP] Don't replace SMP instructions with UP alternatives - nordrand [X86] Disable the direct use of the RDRAND - instruction even if it is supported by the - processor. RDRAND is still available to user - space applications. + nordrand [X86] Disable kernel use of the RDRAND and + RDSEED instructions even if they are supported + by the processor. RDRAND and RDSEED are still + available to user space applications. noresume [SWSUSP] Disables resume and restores original swap space. @@ -2334,6 +2400,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted. timeout < 0: reboot immediately Format: <timeout> + crash_kexec_post_notifiers + Run kdump after running panic-notifiers and dumping + kmsg. This only for the users who doubt kdump always + succeeds in any situation. + Note that this also increases risks of kdump failure, + because some panic notifiers can make the crashed + kernel more unstable. + parkbd.port= [HW] Parallel port number the keyboard adapter is connected to, default is 0. Format: <parport#> @@ -2558,6 +2632,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. pcmv= [HW,PCMCIA] BadgePAD 4 + pd_ignore_unused + [PM] + Keep all power-domains already enabled by bootloader on, + even if no driver has claimed them. This is useful + for debug and development, but should not be + needed on a platform with proper driver support. + pd. [PARIDE] See Documentation/blockdev/paride.txt. @@ -2733,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. @@ -2744,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. @@ -2884,6 +2978,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. [KNL, SMP] Set scheduler's default relax_domain_level. See Documentation/cgroups/cpusets.txt. + relative_sleep_states= + [SUSPEND] Use sleep state labeling where the deepest + state available other than hibernation is always "mem". + Format: { "0" | "1" } + 0 -- Traditional sleep state labels. + 1 -- Relative sleep state labels. + reserve= [KNL,BUGS] Force the kernel to ignore some iomem area reservetop= [X86-32] @@ -2921,15 +3022,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. noresume Don't check if there's a hibernation image present during boot. nocompress Don't compress/decompress hibernation images. + no Disable hibernation and resume. retain_initrd [RAM] Keep initrd memory after extraction rhash_entries= [KNL,NET] Set number of hash buckets for route cache - riscom8= [HW,SERIAL] - Format: <io_board1>[,<io_board2>[,...<io_boardN>]] - ro [KNL] Mount root device read-only on boot root= [KNL] Root filesystem @@ -3068,12 +3167,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted. [KNL] Should the soft-lockup detector generate panics. Format: <integer> + softlockup_all_cpu_backtrace= + [KNL] Should the soft-lockup detector generate + backtraces on all cpus. + Format: <integer> + sonypi.*= [HW] Sony Programmable I/O Control Device driver See Documentation/laptops/sonypi.txt - specialix= [HW,SERIAL] Specialix multi-serial port adapter - See Documentation/serial/specialix.txt. - spia_io_base= [HW,MTD] spia_fio_base= spia_pedr= diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index b6e3973..b772418 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt @@ -11,9 +11,7 @@ with the difference that the orphan objects are not freed but only reported via /sys/kernel/debug/kmemleak. A similar method is used by the Valgrind tool (memcheck --leak-check) to detect the memory leaks in user-space applications. - -Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported -architectures. +Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390, metag and tile. Usage ----- @@ -53,7 +51,8 @@ Memory scanning parameters can be modified at run-time by writing to the (default 600, 0 to stop the automatic scanning) scan - trigger a memory scan clear - clear list of current memory leak suspects, done by - marking all current reported unreferenced objects grey + marking all current reported unreferenced objects grey, + or free all kmemleak objects if kmemleak has been disabled. dump=<addr> - dump information about the object found at <addr> Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on @@ -68,7 +67,7 @@ Basic Algorithm The memory allocations via kmalloc, vmalloc, kmem_cache_alloc and friends are traced and the pointers, together with additional -information like size and stack trace, are stored in a prio search tree. +information like size and stack trace, are stored in a rbtree. The corresponding freeing function calls are tracked and the pointers removed from the kmemleak data structures. @@ -84,7 +83,7 @@ The scanning algorithm steps: 1. mark all objects as white (remaining white objects will later be considered orphan) 2. scan the memory starting with the data section and stacks, checking - the values against the addresses stored in the prio search tree. If + the values against the addresses stored in the rbtree. If a pointer to a white object is found, the object is added to the gray list 3. scan the gray objects for matching addresses (some white objects @@ -120,6 +119,18 @@ Then as usual to get your report with: # cat /sys/kernel/debug/kmemleak +Freeing kmemleak internal objects +--------------------------------- + +To allow access to previosuly found memory leaks after kmemleak has been +disabled by the user or due to an fatal error, internal kmemleak objects +won't be freed when kmemleak is disabled, and those objects may occupy +a large part of physical memory. + +In this situation, you may reclaim memory with: + + # echo clear > /sys/kernel/debug/kmemleak + Kmemleak API ------------ @@ -131,6 +142,7 @@ kmemleak_alloc_percpu - notify of a percpu memory block allocation kmemleak_free - notify of a memory block freeing kmemleak_free_part - notify of a partial memory block freeing kmemleak_free_percpu - notify of a percpu memory block freeing +kmemleak_update_trace - update object allocation stack trace kmemleak_not_leak - mark an object as not a leak kmemleak_ignore - do not scan or report an object as leak kmemleak_scan_area - add scan areas inside a memory block diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 0cfb00f..4bbeca8 100644 --- a/Documentation/kprobes.txt +++ b/Documentation/kprobes.txt @@ -22,8 +22,9 @@ Appendix B: The kprobes sysctl interface Kprobes enables you to dynamically break into any kernel routine and collect debugging and performance information non-disruptively. You -can trap at almost any kernel code address, specifying a handler +can trap at almost any kernel code address(*), specifying a handler routine to be invoked when the breakpoint is hit. +(*: some parts of the kernel code can not be trapped, see 1.5 Blacklist) There are currently three types of probes: kprobes, jprobes, and kretprobes (also called return probes). A kprobe can be inserted @@ -273,6 +274,19 @@ using one of the following techniques: or - Execute 'sysctl -w debug.kprobes_optimization=n' +1.5 Blacklist + +Kprobes can probe most of the kernel except itself. This means +that there are some functions where kprobes cannot probe. Probing +(trapping) such functions can cause a recursive trap (e.g. double +fault) or the nested probe handler may never be called. +Kprobes manages such functions as a blacklist. +If you want to add a function into the blacklist, you just need +to (1) include linux/kprobes.h and (2) use NOKPROBE_SYMBOL() macro +to specify a blacklisted function. +Kprobes checks the given probe address against the blacklist and +rejects registering it, if the given address is in the blacklist. + 2. Architectures Supported Kprobes, jprobes, and return probes are implemented on the following diff --git a/Documentation/laptops/00-INDEX b/Documentation/laptops/00-INDEX index d13b9a9..d399ae1 100644 --- a/Documentation/laptops/00-INDEX +++ b/Documentation/laptops/00-INDEX @@ -8,8 +8,8 @@ disk-shock-protection.txt - information on hard disk shock protection. dslm.c - Simple Disk Sleep Monitor program -hpfall.c - - (HP) laptop accelerometer program for disk protection. +freefall.c + - (HP/DELL) laptop accelerometer program for disk protection. laptop-mode.txt - how to conserve battery power using laptop-mode. sony-laptop.txt diff --git a/Documentation/laptops/hpfall.c b/Documentation/laptops/freefall.c index 6708432..d417318 100644 --- a/Documentation/laptops/hpfall.c +++ b/Documentation/laptops/freefall.c @@ -1,7 +1,9 @@ -/* Disk protection for HP machines. +/* Disk protection for HP/DELL machines. * * Copyright 2008 Eric Piel * Copyright 2009 Pavel Machek <pavel@ucw.cz> + * Copyright 2012 Sonal Santan + * Copyright 2014 Pali Rohár <pali.rohar@gmail.com> * * GPLv2. */ @@ -18,25 +20,32 @@ #include <signal.h> #include <sys/mman.h> #include <sched.h> +#include <syslog.h> -char unload_heads_path[64]; +static int noled; +static char unload_heads_path[64]; +static char device_path[32]; +static const char app_name[] = "FREE FALL"; -int set_unload_heads_path(char *device) +static int set_unload_heads_path(char *device) { char devname[64]; if (strlen(device) <= 5 || strncmp(device, "/dev/", 5) != 0) return -EINVAL; - strncpy(devname, device + 5, sizeof(devname)); + strncpy(devname, device + 5, sizeof(devname) - 1); devname[sizeof(devname) - 1] = '\0'; + strncpy(device_path, device, sizeof(device_path) - 1); snprintf(unload_heads_path, sizeof(unload_heads_path) - 1, "/sys/block/%s/device/unload_heads", devname); return 0; } -int valid_disk(void) + +static int valid_disk(void) { int fd = open(unload_heads_path, O_RDONLY); + if (fd < 0) { perror(unload_heads_path); return 0; @@ -46,43 +55,54 @@ int valid_disk(void) return 1; } -void write_int(char *path, int i) +static void write_int(char *path, int i) { char buf[1024]; int fd = open(path, O_RDWR); + if (fd < 0) { perror("open"); exit(1); } + sprintf(buf, "%d", i); + if (write(fd, buf, strlen(buf)) != strlen(buf)) { perror("write"); exit(1); } + close(fd); } -void set_led(int on) +static void set_led(int on) { + if (noled) + return; write_int("/sys/class/leds/hp::hddprotect/brightness", on); } -void protect(int seconds) +static void protect(int seconds) { + const char *str = (seconds == 0) ? "Unparked" : "Parked"; + write_int(unload_heads_path, seconds*1000); + syslog(LOG_INFO, "%s %s disk head\n", str, device_path); } -int on_ac(void) +static int on_ac(void) { -// /sys/class/power_supply/AC0/online + /* /sys/class/power_supply/AC0/online */ + return 1; } -int lid_open(void) +static int lid_open(void) { -// /proc/acpi/button/lid/LID/state + /* /proc/acpi/button/lid/LID/state */ + return 1; } -void ignore_me(void) +static void ignore_me(int signum) { protect(0); set_led(0); @@ -91,6 +111,7 @@ void ignore_me(void) int main(int argc, char **argv) { int fd, ret; + struct stat st; struct sched_param param; if (argc == 1) @@ -112,7 +133,16 @@ int main(int argc, char **argv) return EXIT_FAILURE; } - daemon(0, 0); + if (stat("/sys/class/leds/hp::hddprotect/brightness", &st)) + noled = 1; + + if (daemon(0, 0) != 0) { + perror("daemon"); + return EXIT_FAILURE; + } + + openlog(app_name, LOG_CONS | LOG_PID | LOG_NDELAY, LOG_LOCAL1); + param.sched_priority = sched_get_priority_max(SCHED_FIFO); sched_setscheduler(0, SCHED_FIFO, ¶m); mlockall(MCL_CURRENT|MCL_FUTURE); @@ -142,6 +172,7 @@ int main(int argc, char **argv) alarm(20); } + closelog(); close(fd); return EXIT_SUCCESS; } diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt index 76d80a6..4c8e142 100644 --- a/Documentation/magic-number.txt +++ b/Documentation/magic-number.txt @@ -63,8 +63,6 @@ Magic Name Number Structure File PG_MAGIC 'P' pg_{read,write}_hdr include/linux/pg.h CMAGIC 0x0111 user include/linux/a.out.h MKISS_DRIVER_MAGIC 0x04bf mkiss_channel drivers/net/mkiss.h -RISCOM8_MAGIC 0x0907 riscom_port drivers/char/riscom8.h -SPECIALIX_MAGIC 0x0907 specialix_port drivers/char/specialix_io8.h HDLC_MAGIC 0x239e n_hdlc drivers/char/n_hdlc.c APM_BIOS_MAGIC 0x4101 apm_user arch/x86/kernel/apm_32.c CYCLADES_MAGIC 0x4359 cyclades_port include/linux/cyclades.h @@ -82,7 +80,6 @@ STRIP_MAGIC 0x5303 strip drivers/net/strip.c X25_ASY_MAGIC 0x5303 x25_asy drivers/net/x25_asy.h SIXPACK_MAGIC 0x5304 sixpack drivers/net/hamradio/6pack.h AX25_MAGIC 0x5316 ax_disp drivers/net/mkiss.h -ESP_MAGIC 0x53ee esp_struct drivers/char/esp.h TTY_MAGIC 0x5401 tty_struct include/linux/tty.h MGSL_MAGIC 0x5401 mgsl_info drivers/char/synclink.c TTY_DRIVER_MAGIC 0x5402 tty_driver include/linux/tty_driver.h @@ -94,13 +91,10 @@ USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth drivers/usb/class/bluetty.c RFCOMM_TTY_MAGIC 0x6d02 net/bluetooth/rfcomm/tty.c USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port drivers/usb/serial/usb-serial.h CG_MAGIC 0x00090255 ufs_cylinder_group include/linux/ufs_fs.h -A2232_MAGIC 0x000a2232 gs_port drivers/char/ser_a2232.h RPORT_MAGIC 0x00525001 r_port drivers/char/rocket_int.h LSEMAGIC 0x05091998 lse drivers/fc4/fc.c GDTIOCTL_MAGIC 0x06030f07 gdth_iowr_str drivers/scsi/gdth_ioctl.h RIEBL_MAGIC 0x09051990 drivers/net/atarilance.c -RIO_MAGIC 0x12345678 gs_port drivers/char/rio/rio_linux.c -SX_MAGIC 0x12345678 gs_port drivers/char/sx.h NBD_REQUEST_MAGIC 0x12560953 nbd_request include/linux/nbd.h RED_MAGIC2 0x170fc2a5 (any) mm/slab.c BAYCOM_MAGIC 0x19730510 baycom_state drivers/net/baycom_epp.c @@ -116,7 +110,6 @@ ISDN_ASYNC_MAGIC 0x49344C01 modem_info include/linux/isdn.h CTC_ASYNC_MAGIC 0x49344C01 ctc_tty_info drivers/s390/net/ctctty.c ISDN_NET_MAGIC 0x49344C02 isdn_net_local_s drivers/isdn/i4l/isdn_net_lib.h SAVEKMSG_MAGIC2 0x4B4D5347 savekmsg arch/*/amiga/config.c -STLI_BOARDMAGIC 0x4bc6c825 stlibrd include/linux/istallion.h CS_STATE_MAGIC 0x4c4f4749 cs_state sound/oss/cs46xx.c SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c @@ -127,10 +120,8 @@ SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h RED_MAGIC1 0x5a2cf071 (any) mm/slab.c -STL_PORTMAGIC 0x5a7182c9 stlport include/linux/stallion.h EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev drivers/atm/lanai.c HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h -EPCA_MAGIC 0x5c6df104 channel include/linux/epca.h PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h KV_MAGIC 0x5f4b565f kernel_vars_s arch/mips/include/asm/sn/klkernvars.h I810_STATE_MAGIC 0x63657373 i810_state sound/oss/i810_audio.c @@ -142,17 +133,14 @@ SLOT_MAGIC 0x67267322 slot drivers/hotplug/acpiphp.h LO_MAGIC 0x68797548 nbd_device include/linux/nbd.h OPROFILE_MAGIC 0x6f70726f super_block drivers/oprofile/oprofilefs.h M3_STATE_MAGIC 0x734d724d m3_state sound/oss/maestro3.c -STL_PANELMAGIC 0x7ef621a1 stlpanel include/linux/stallion.h VMALLOC_MAGIC 0x87654320 snd_alloc_track sound/core/memory.c KMALLOC_MAGIC 0x87654321 snd_alloc_track sound/core/memory.c PWC_MAGIC 0x89DC10AB pwc_device drivers/usb/media/pwc.h NBD_REPLY_MAGIC 0x96744668 nbd_reply include/linux/nbd.h -STL_BOARDMAGIC 0xa2267f52 stlbrd include/linux/stallion.h ENI155_MAGIC 0xa54b872d midway_eprom drivers/atm/eni.h SCI_MAGIC 0xbabeface gs_port drivers/char/sh-sci.h CODA_MAGIC 0xC0DAC0DA coda_file_info fs/coda/coda_fs_i.h DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram drivers/scsi/gdth.h -STLI_PORTMAGIC 0xe671c7a1 stliport include/linux/istallion.h YAM_MAGIC 0xF10A7654 yam_port drivers/net/hamradio/yam.c CCB_MAGIC 0xf2691ad2 ccb drivers/scsi/ncr53c8xx.c QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry drivers/scsi/arm/queue.c diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 556f951..a4de88f 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -115,8 +115,8 @@ For example, consider the following sequence of events: CPU 1 CPU 2 =============== =============== { A == 1; B == 2 } - A = 3; x = A; - B = 4; y = B; + A = 3; x = B; + B = 4; y = A; The set of accesses as seen by the memory system in the middle can be arranged in 24 different combinations: @@ -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 =============== =============== @@ -1583,20 +1587,21 @@ There are some more advanced barrier functions: insert anything more than a compiler barrier in a UP compilation. - (*) smp_mb__before_atomic_dec(); - (*) smp_mb__after_atomic_dec(); - (*) smp_mb__before_atomic_inc(); - (*) smp_mb__after_atomic_inc(); + (*) smp_mb__before_atomic(); + (*) smp_mb__after_atomic(); - These are for use with atomic add, subtract, increment and decrement - functions that don't return a value, especially when used for reference - counting. These functions do not imply memory barriers. + These are for use with atomic (such as add, subtract, increment and + decrement) functions that don't return a value, especially when used for + reference counting. These functions do not imply memory barriers. + + These are also used for atomic bitop functions that do not return a + value (such as set_bit and clear_bit). As an example, consider a piece of code that marks an object as being dead and then decrements the object's reference count: obj->dead = 1; - smp_mb__before_atomic_dec(); + smp_mb__before_atomic(); atomic_dec(&obj->ref_count); This makes sure that the death mark on the object is perceived to be set @@ -1606,27 +1611,6 @@ There are some more advanced barrier functions: operations" subsection for information on where to use these. - (*) smp_mb__before_clear_bit(void); - (*) smp_mb__after_clear_bit(void); - - These are for use similar to the atomic inc/dec barriers. These are - typically used for bitwise unlocking operations, so care must be taken as - there are no implicit memory barriers here either. - - Consider implementing an unlock operation of some nature by clearing a - locking bit. The clear_bit() would then need to be barriered like this: - - smp_mb__before_clear_bit(); - clear_bit( ... ); - - This prevents memory operations before the clear leaking to after it. See - the subsection on "Locking Functions" with reference to RELEASE operation - implications. - - See Documentation/atomic_ops.txt for more information. See the "Atomic - operations" subsection for information on where to use these. - - MMIO WRITE BARRIER ------------------ @@ -1913,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(); @@ -2283,11 +2282,11 @@ operations: change_bit(); With these the appropriate explicit memory barrier should be used if necessary -(smp_mb__before_clear_bit() for instance). +(smp_mb__before_atomic() for instance). The following also do _not_ imply memory barriers, and so may require explicit -memory barriers under some circumstances (smp_mb__before_atomic_dec() for +memory barriers under some circumstances (smp_mb__before_atomic() for instance): atomic_add(); diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index 58340d5..45134dc 100644 --- a/Documentation/memory-hotplug.txt +++ b/Documentation/memory-hotplug.txt @@ -88,16 +88,21 @@ phase by hand. 1.3. Unit of Memory online/offline operation ------------ -Memory hotplug uses SPARSEMEM memory model. SPARSEMEM divides the whole memory -into chunks of the same size. The chunk is called a "section". The size of -a section is architecture dependent. For example, power uses 16MiB, ia64 uses -1GiB. The unit of online/offline operation is "one section". (see Section 3.) +Memory hotplug uses SPARSEMEM memory model which allows memory to be divided +into chunks of the same size. These chunks are called "sections". The size of +a memory section is architecture dependent. For example, power uses 16MiB, ia64 +uses 1GiB. -To determine the size of sections, please read this file: +Memory sections are combined into chunks referred to as "memory blocks". The +size of a memory block is architecture dependent and represents the logical +unit upon which memory online/offline operations are to be performed. The +default size of a memory block is the same as memory section size unless an +architecture specifies otherwise. (see Section 3.) + +To determine the size (in bytes) of a memory block please read this file: /sys/devices/system/memory/block_size_bytes -This file shows the size of sections in byte. ----------------------- 2. Kernel Configuration @@ -123,42 +128,35 @@ config options. (CONFIG_ACPI_CONTAINER). This option can be kernel module too. + -------------------------------- -4 sysfs files for memory hotplug +3 sysfs files for memory hotplug -------------------------------- -All sections have their device information in sysfs. Each section is part of -a memory block under /sys/devices/system/memory as +All memory blocks have their device information in sysfs. Each memory block +is described under /sys/devices/system/memory as /sys/devices/system/memory/memoryXXX -(XXX is the section id.) +(XXX is the memory block id.) -Now, XXX is defined as (start_address_of_section / section_size) of the first -section contained in the memory block. The files 'phys_index' and -'end_phys_index' under each directory report the beginning and end section id's -for the memory block covered by the sysfs directory. It is expected that all +For the memory block covered by the sysfs directory. It is expected that all memory sections in this range are present and no memory holes exist in the range. Currently there is no way to determine if there is a memory hole, but the existence of one should not affect the hotplug capabilities of the memory block. -For example, assume 1GiB section size. A device for a memory starting at +For example, assume 1GiB memory block size. A device for a memory starting at 0x100000000 is /sys/device/system/memory/memory4 (0x100000000 / 1Gib = 4) This device covers address range [0x100000000 ... 0x140000000) -Under each section, you can see 4 or 5 files, the end_phys_index file being -a recent addition and not present on older kernels. +Under each memory block, you can see 4 files: -/sys/devices/system/memory/memoryXXX/start_phys_index -/sys/devices/system/memory/memoryXXX/end_phys_index +/sys/devices/system/memory/memoryXXX/phys_index /sys/devices/system/memory/memoryXXX/phys_device /sys/devices/system/memory/memoryXXX/state /sys/devices/system/memory/memoryXXX/removable -'phys_index' : read-only and contains section id of the first section - in the memory block, same as XXX. -'end_phys_index' : read-only and contains section id of the last section - in the memory block. +'phys_index' : read-only and contains memory block id, same as XXX. 'state' : read-write at read: contains online/offline state of memory. at write: user can specify "online_kernel", @@ -185,6 +183,7 @@ For example: A backlink will also be created: /sys/devices/system/memory/memory9/node0 -> ../../node/node0 + -------------------------------- 4. Physical memory hot-add phase -------------------------------- @@ -210,15 +209,12 @@ If memory device is found, memory hotplug code will be called. 4.2 Notify memory hot-add event by hand ------------ -On powerpc, the firmware does not notify a memory hotplug event to the kernel. -Therefore, "probe" interface is supported to notify the event to the kernel. -This interface depends on CONFIG_ARCH_MEMORY_PROBE. - -CONFIG_ARCH_MEMORY_PROBE is supported on powerpc only. On x86, this config -option is disabled by default since ACPI notifies a memory hotplug event to -the kernel, which performs its hotplug operation as the result. Please -enable this option if you need the "probe" interface for testing purposes -on x86. +On some architectures, the firmware may not notify the kernel of a memory +hotplug event. Therefore, the memory "probe" interface is supported to +explicitly notify the kernel. This interface depends on +CONFIG_ARCH_MEMORY_PROBE and can be configured on powerpc, sh, and x86 +if hotplug is supported, although for x86 this should be handled by ACPI +notification. Probe interface is located at /sys/devices/system/memory/probe @@ -227,11 +223,10 @@ You can tell the physical address of new memory to the kernel by % echo start_address_of_new_memory > /sys/devices/system/memory/probe -Then, [start_address_of_new_memory, start_address_of_new_memory + section_size) -memory range is hot-added. In this case, hotplug script is not called (in -current implementation). You'll have to online memory by yourself. -Please see "How to online memory" in this text. - +Then, [start_address_of_new_memory, start_address_of_new_memory + +memory_block_size] memory range is hot-added. In this case, hotplug script is +not called (in current implementation). You'll have to online memory by +yourself. Please see "How to online memory" in this text. ------------------------------ @@ -240,36 +235,36 @@ Please see "How to online memory" in this text. 5.1. State of memory ------------ -To see (online/offline) state of memory section, read 'state' file. +To see (online/offline) state of a memory block, read 'state' file. % cat /sys/device/system/memory/memoryXXX/state -If the memory section is online, you'll read "online". -If the memory section is offline, you'll read "offline". +If the memory block is online, you'll read "online". +If the memory block is offline, you'll read "offline". 5.2. How to online memory ------------ Even if the memory is hot-added, it is not at ready-to-use state. -For using newly added memory, you have to "online" the memory section. +For using newly added memory, you have to "online" the memory block. -For onlining, you have to write "online" to the section's state file as: +For onlining, you have to write "online" to the memory block's state file as: % echo online > /sys/devices/system/memory/memoryXXX/state -This onlining will not change the ZONE type of the target memory section, -If the memory section is in ZONE_NORMAL, you can change it to ZONE_MOVABLE: +This onlining will not change the ZONE type of the target memory block, +If the memory block is in ZONE_NORMAL, you can change it to ZONE_MOVABLE: % echo online_movable > /sys/devices/system/memory/memoryXXX/state -(NOTE: current limit: this memory section must be adjacent to ZONE_MOVABLE) +(NOTE: current limit: this memory block must be adjacent to ZONE_MOVABLE) -And if the memory section is in ZONE_MOVABLE, you can change it to ZONE_NORMAL: +And if the memory block is in ZONE_MOVABLE, you can change it to ZONE_NORMAL: % echo online_kernel > /sys/devices/system/memory/memoryXXX/state -(NOTE: current limit: this memory section must be adjacent to ZONE_NORMAL) +(NOTE: current limit: this memory block must be adjacent to ZONE_NORMAL) -After this, section memoryXXX's state will be 'online' and the amount of +After this, memory block XXX's state will be 'online' and the amount of available memory will be increased. Currently, newly added memory is added as ZONE_NORMAL (for powerpc, ZONE_DMA). @@ -284,22 +279,22 @@ This may be changed in future. 6.1 Memory offline and ZONE_MOVABLE ------------ Memory offlining is more complicated than memory online. Because memory offline -has to make the whole memory section be unused, memory offline can fail if -the section includes memory which cannot be freed. +has to make the whole memory block be unused, memory offline can fail if +the memory block includes memory which cannot be freed. In general, memory offline can use 2 techniques. -(1) reclaim and free all memory in the section. -(2) migrate all pages in the section. +(1) reclaim and free all memory in the memory block. +(2) migrate all pages in the memory block. In the current implementation, Linux's memory offline uses method (2), freeing -all pages in the section by page migration. But not all pages are +all pages in the memory block by page migration. But not all pages are migratable. Under current Linux, migratable pages are anonymous pages and -page caches. For offlining a section by migration, the kernel has to guarantee -that the section contains only migratable pages. +page caches. For offlining a memory block by migration, the kernel has to +guarantee that the memory block contains only migratable pages. -Now, a boot option for making a section which consists of migratable pages is -supported. By specifying "kernelcore=" or "movablecore=" boot option, you can +Now, a boot option for making a memory block which consists of migratable pages +is supported. By specifying "kernelcore=" or "movablecore=" boot option, you can create ZONE_MOVABLE...a zone which is just used for movable pages. (See also Documentation/kernel-parameters.txt) @@ -315,28 +310,27 @@ creates ZONE_MOVABLE as following. Size of memory for movable pages (for offline) is ZZZZ. -Note) Unfortunately, there is no information to show which section belongs +Note: Unfortunately, there is no information to show which memory block belongs to ZONE_MOVABLE. This is TBD. 6.2. How to offline memory ------------ -You can offline a section by using the same sysfs interface that was used in -memory onlining. +You can offline a memory block by using the same sysfs interface that was used +in memory onlining. % echo offline > /sys/devices/system/memory/memoryXXX/state -If offline succeeds, the state of the memory section is changed to be "offline". +If offline succeeds, the state of the memory block is changed to be "offline". If it fails, some error core (like -EBUSY) will be returned by the kernel. -Even if a section does not belong to ZONE_MOVABLE, you can try to offline it. -If it doesn't contain 'unmovable' memory, you'll get success. +Even if a memory block does not belong to ZONE_MOVABLE, you can try to offline +it. If it doesn't contain 'unmovable' memory, you'll get success. -A section under ZONE_MOVABLE is considered to be able to be offlined easily. -But under some busy state, it may return -EBUSY. Even if a memory section -cannot be offlined due to -EBUSY, you can retry offlining it and may be able to -offline it (or not). -(For example, a page is referred to by some kernel internal call and released - soon.) +A memory block under ZONE_MOVABLE is considered to be able to be offlined +easily. But under some busy state, it may return -EBUSY. Even if a memory +block cannot be offlined due to -EBUSY, you can retry offlining it and may be +able to offline it (or not). (For example, a page is referred to by some kernel +internal call and released soon.) Consideration: Memory hotplug's design direction is to make the possibility of memory offlining @@ -373,11 +367,11 @@ MEMORY_GOING_OFFLINE Generated to begin the process of offlining memory. Allocations are no longer possible from the memory but some of the memory to be offlined is still in use. The callback can be used to free memory known to a - subsystem from the indicated memory section. + subsystem from the indicated memory block. MEMORY_CANCEL_OFFLINE Generated if MEMORY_GOING_OFFLINE fails. Memory is available again from - the section that we attempted to offline. + the memory block that we attempted to offline. MEMORY_OFFLINE Generated after offlining memory is complete. @@ -413,8 +407,8 @@ node if necessary. -------------- - allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like sysctl or new control file. - - showing memory section and physical device relationship. - - showing memory section is under ZONE_MOVABLE or not + - showing memory block and physical device relationship. + - showing memory block is under ZONE_MOVABLE or not - test and make it better memory offlining. - support HugeTLB page migration and offlining. - memmap removing at memory offline. diff --git a/Documentation/mic/mic_overview.txt b/Documentation/mic/mic_overview.txt index b419292..77c5418 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 3136c68..cacbdb0 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/module-signing.txt b/Documentation/module-signing.txt index 09b583e..09c2382 100644 --- a/Documentation/module-signing.txt +++ b/Documentation/module-signing.txt @@ -53,7 +53,8 @@ This has a number of options available: If this is off (ie. "permissive"), then modules for which the key is not available and modules that are unsigned are permitted, but the kernel will - be marked as being tainted. + be marked as being tainted, and the concerned modules will be marked as + tainted, shown with the character 'E'. If this is on (ie. "restrictive"), only modules that have a valid signature that can be verified by a public key in the kernel's possession diff --git a/Documentation/mtd/spi-nor.txt b/Documentation/mtd/spi-nor.txt new file mode 100644 index 0000000..548d630 --- /dev/null +++ b/Documentation/mtd/spi-nor.txt @@ -0,0 +1,62 @@ + SPI NOR framework + ============================================ + +Part I - Why do we need this framework? +--------------------------------------- + +SPI bus controllers (drivers/spi/) only deal with streams of bytes; the bus +controller operates agnostic of the specific device attached. However, some +controllers (such as Freescale's QuadSPI controller) cannot easily handle +arbitrary streams of bytes, but rather are designed specifically for SPI NOR. + +In particular, Freescale's QuadSPI controller must know the NOR commands to +find the right LUT sequence. Unfortunately, the SPI subsystem has no notion of +opcodes, addresses, or data payloads; a SPI controller simply knows to send or +receive bytes (Tx and Rx). Therefore, we must define a new layering scheme under +which the controller driver is aware of the opcodes, addressing, and other +details of the SPI NOR protocol. + +Part II - How does the framework work? +-------------------------------------- + +This framework just adds a new layer between the MTD and the SPI bus driver. +With this new layer, the SPI NOR controller driver does not depend on the +m25p80 code anymore. + + Before this framework, the layer is like: + + MTD + ------------------------ + m25p80 + ------------------------ + SPI bus driver + ------------------------ + SPI NOR chip + + After this framework, the layer is like: + MTD + ------------------------ + SPI NOR framework + ------------------------ + m25p80 + ------------------------ + SPI bus driver + ------------------------ + SPI NOR chip + + With the SPI NOR controller driver (Freescale QuadSPI), it looks like: + MTD + ------------------------ + SPI NOR framework + ------------------------ + fsl-quadSPI + ------------------------ + SPI NOR chip + +Part III - How can drivers use the framework? +--------------------------------------------- + +The main API is spi_nor_scan(). Before you call the hook, a driver should +initialize the necessary fields for spi_nor{}. Please see +drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to fsl-quadspi.c +when you want to write a new driver for a SPI NOR controller. diff --git a/Documentation/mutex-design.txt b/Documentation/mutex-design.txt index 1dfe62c..ee231ed 100644 --- a/Documentation/mutex-design.txt +++ b/Documentation/mutex-design.txt @@ -1,139 +1,157 @@ Generic Mutex Subsystem started by Ingo Molnar <mingo@redhat.com> +updated by Davidlohr Bueso <davidlohr@hp.com> - "Why on earth do we need a new mutex subsystem, and what's wrong - with semaphores?" +What are mutexes? +----------------- -firstly, there's nothing wrong with semaphores. But if the simpler -mutex semantics are sufficient for your code, then there are a couple -of advantages of mutexes: +In the Linux kernel, mutexes refer to a particular locking primitive +that enforces serialization on shared memory systems, and not only to +the generic term referring to 'mutual exclusion' found in academia +or similar theoretical text books. Mutexes are sleeping locks which +behave similarly to binary semaphores, and were introduced in 2006[1] +as an alternative to these. This new data structure provided a number +of advantages, including simpler interfaces, and at that time smaller +code (see Disadvantages). - - 'struct mutex' is smaller on most architectures: E.g. on x86, - 'struct semaphore' is 20 bytes, 'struct mutex' is 16 bytes. - A smaller structure size means less RAM footprint, and better - CPU-cache utilization. +[1] http://lwn.net/Articles/164802/ - - tighter code. On x86 i get the following .text sizes when - switching all mutex-alike semaphores in the kernel to the mutex - subsystem: +Implementation +-------------- - text data bss dec hex filename - 3280380 868188 396860 4545428 455b94 vmlinux-semaphore - 3255329 865296 396732 4517357 44eded vmlinux-mutex +Mutexes are represented by 'struct mutex', defined in include/linux/mutex.h +and implemented in kernel/locking/mutex.c. These locks use a three +state atomic counter (->count) to represent the different possible +transitions that can occur during the lifetime of a lock: - that's 25051 bytes of code saved, or a 0.76% win - off the hottest - codepaths of the kernel. (The .data savings are 2892 bytes, or 0.33%) - Smaller code means better icache footprint, which is one of the - major optimization goals in the Linux kernel currently. + 1: unlocked + 0: locked, no waiters + negative: locked, with potential waiters - - the mutex subsystem is slightly faster and has better scalability for - contended workloads. On an 8-way x86 system, running a mutex-based - kernel and testing creat+unlink+close (of separate, per-task files) - in /tmp with 16 parallel tasks, the average number of ops/sec is: +In its most basic form it also includes a wait-queue and a spinlock +that serializes access to it. CONFIG_SMP systems can also include +a pointer to the lock task owner (->owner) as well as a spinner MCS +lock (->osq), both described below in (ii). - Semaphores: Mutexes: +When acquiring a mutex, there are three possible paths that can be +taken, depending on the state of the lock: - $ ./test-mutex V 16 10 $ ./test-mutex V 16 10 - 8 CPUs, running 16 tasks. 8 CPUs, running 16 tasks. - checking VFS performance. checking VFS performance. - avg loops/sec: 34713 avg loops/sec: 84153 - CPU utilization: 63% CPU utilization: 22% +(i) fastpath: tries to atomically acquire the lock by decrementing the + counter. If it was already taken by another task it goes to the next + possible path. This logic is architecture specific. On x86-64, the + locking fastpath is 2 instructions: - i.e. in this workload, the mutex based kernel was 2.4 times faster - than the semaphore based kernel, _and_ it also had 2.8 times less CPU - utilization. (In terms of 'ops per CPU cycle', the semaphore kernel - performed 551 ops/sec per 1% of CPU time used, while the mutex kernel - performed 3825 ops/sec per 1% of CPU time used - it was 6.9 times - more efficient.) - - the scalability difference is visible even on a 2-way P4 HT box: - - Semaphores: Mutexes: - - $ ./test-mutex V 16 10 $ ./test-mutex V 16 10 - 4 CPUs, running 16 tasks. 8 CPUs, running 16 tasks. - checking VFS performance. checking VFS performance. - avg loops/sec: 127659 avg loops/sec: 181082 - CPU utilization: 100% CPU utilization: 34% - - (the straight performance advantage of mutexes is 41%, the per-cycle - efficiency of mutexes is 4.1 times better.) - - - there are no fastpath tradeoffs, the mutex fastpath is just as tight - as the semaphore fastpath. On x86, the locking fastpath is 2 - instructions: - - c0377ccb <mutex_lock>: - c0377ccb: f0 ff 08 lock decl (%eax) - c0377cce: 78 0e js c0377cde <.text..lock.mutex> - c0377cd0: c3 ret + 0000000000000e10 <mutex_lock>: + e21: f0 ff 0b lock decl (%rbx) + e24: 79 08 jns e2e <mutex_lock+0x1e> the unlocking fastpath is equally tight: - c0377cd1 <mutex_unlock>: - c0377cd1: f0 ff 00 lock incl (%eax) - c0377cd4: 7e 0f jle c0377ce5 <.text..lock.mutex+0x7> - c0377cd6: c3 ret - - - 'struct mutex' semantics are well-defined and are enforced if - CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand have - virtually no debugging code or instrumentation. The mutex subsystem - checks and enforces the following rules: - - * - only one task can hold the mutex at a time - * - only the owner can unlock the mutex - * - multiple unlocks are not permitted - * - recursive locking is not permitted - * - a mutex object must be initialized via the API - * - a mutex object must not be initialized via memset or copying - * - task may not exit with mutex held - * - memory areas where held locks reside must not be freed - * - held mutexes must not be reinitialized - * - mutexes may not be used in hardware or software interrupt - * contexts such as tasklets and timers - - furthermore, there are also convenience features in the debugging - code: - - * - uses symbolic names of mutexes, whenever they are printed in debug output - * - point-of-acquire tracking, symbolic lookup of function names - * - list of all locks held in the system, printout of them - * - owner tracking - * - detects self-recursing locks and prints out all relevant info - * - detects multi-task circular deadlocks and prints out all affected - * locks and tasks (and only those tasks) + 0000000000000bc0 <mutex_unlock>: + bc8: f0 ff 07 lock incl (%rdi) + bcb: 7f 0a jg bd7 <mutex_unlock+0x17> + + +(ii) midpath: aka optimistic spinning, tries to spin for acquisition + while the lock owner is running and there are no other tasks ready + to run that have higher priority (need_resched). The rationale is + that if the lock owner is running, it is likely to release the lock + soon. The mutex spinners are queued up using MCS lock so that only + one spinner can compete for the mutex. + + The MCS lock (proposed by Mellor-Crummey and Scott) is a simple spinlock + with the desirable properties of being fair and with each cpu trying + to acquire the lock spinning on a local variable. It avoids expensive + cacheline bouncing that common test-and-set spinlock implementations + incur. An MCS-like lock is specially tailored for optimistic spinning + for sleeping lock implementation. An important feature of the customized + MCS lock is that it has the extra property that spinners are able to exit + the MCS spinlock queue when they need to reschedule. This further helps + avoid situations where MCS spinners that need to reschedule would continue + waiting to spin on mutex owner, only to go directly to slowpath upon + obtaining the MCS lock. + + +(iii) slowpath: last resort, if the lock is still unable to be acquired, + the task is added to the wait-queue and sleeps until woken up by the + unlock path. Under normal circumstances it blocks as TASK_UNINTERRUPTIBLE. + +While formally kernel mutexes are sleepable locks, it is path (ii) that +makes them more practically a hybrid type. By simply not interrupting a +task and busy-waiting for a few cycles instead of immediately sleeping, +the performance of this lock has been seen to significantly improve a +number of workloads. Note that this technique is also used for rw-semaphores. + +Semantics +--------- + +The mutex subsystem checks and enforces the following rules: + + - Only one task can hold the mutex at a time. + - Only the owner can unlock the mutex. + - Multiple unlocks are not permitted. + - Recursive locking/unlocking is not permitted. + - A mutex must only be initialized via the API (see below). + - A task may not exit with a mutex held. + - Memory areas where held locks reside must not be freed. + - Held mutexes must not be reinitialized. + - Mutexes may not be used in hardware or software interrupt + contexts such as tasklets and timers. + +These semantics are fully enforced when CONFIG DEBUG_MUTEXES is enabled. +In addition, the mutex debugging code also implements a number of other +features that make lock debugging easier and faster: + + - Uses symbolic names of mutexes, whenever they are printed + in debug output. + - Point-of-acquire tracking, symbolic lookup of function names, + list of all locks held in the system, printout of them. + - Owner tracking. + - Detects self-recursing locks and prints out all relevant info. + - Detects multi-task circular deadlocks and prints out all affected + locks and tasks (and only those tasks). + + +Interfaces +---------- +Statically define the mutex: + DEFINE_MUTEX(name); + +Dynamically initialize the mutex: + mutex_init(mutex); + +Acquire the mutex, uninterruptible: + void mutex_lock(struct mutex *lock); + void mutex_lock_nested(struct mutex *lock, unsigned int subclass); + int mutex_trylock(struct mutex *lock); + +Acquire the mutex, interruptible: + int mutex_lock_interruptible_nested(struct mutex *lock, + unsigned int subclass); + int mutex_lock_interruptible(struct mutex *lock); + +Acquire the mutex, interruptible, if dec to 0: + int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock); + +Unlock the mutex: + void mutex_unlock(struct mutex *lock); + +Test if the mutex is taken: + int mutex_is_locked(struct mutex *lock); Disadvantages ------------- -The stricter mutex API means you cannot use mutexes the same way you -can use semaphores: e.g. they cannot be used from an interrupt context, -nor can they be unlocked from a different context that which acquired -it. [ I'm not aware of any other (e.g. performance) disadvantages from -using mutexes at the moment, please let me know if you find any. ] - -Implementation of mutexes -------------------------- - -'struct mutex' is the new mutex type, defined in include/linux/mutex.h and -implemented in kernel/locking/mutex.c. It is a counter-based mutex with a -spinlock and a wait-list. The counter has 3 states: 1 for "unlocked", 0 for -"locked" and negative numbers (usually -1) for "locked, potential waiters -queued". - -the APIs of 'struct mutex' have been streamlined: - - DEFINE_MUTEX(name); +Unlike its original design and purpose, 'struct mutex' is larger than +most locks in the kernel. E.g: on x86-64 it is 40 bytes, almost twice +as large as 'struct semaphore' (24 bytes) and 8 bytes shy of the +'struct rw_semaphore' variant. Larger structure sizes mean more CPU +cache and memory footprint. - mutex_init(mutex); +When to use mutexes +------------------- - void mutex_lock(struct mutex *lock); - int mutex_lock_interruptible(struct mutex *lock); - int mutex_trylock(struct mutex *lock); - void mutex_unlock(struct mutex *lock); - int mutex_is_locked(struct mutex *lock); - void mutex_lock_nested(struct mutex *lock, unsigned int subclass); - int mutex_lock_interruptible_nested(struct mutex *lock, - unsigned int subclass); - int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock); +Unless the strict semantics of mutexes are unsuitable and/or the critical +region prevents the lock from being shared, always prefer them to any other +locking primitive. diff --git a/Documentation/networking/altera_tse.txt b/Documentation/networking/altera_tse.txt new file mode 100644 index 0000000..3f24df8 --- /dev/null +++ b/Documentation/networking/altera_tse.txt @@ -0,0 +1,263 @@ + Altera Triple-Speed Ethernet MAC driver + +Copyright (C) 2008-2014 Altera Corporation + +This is the driver for the Altera Triple-Speed Ethernet (TSE) controllers +using the SGDMA and MSGDMA soft DMA IP components. The driver uses the +platform bus to obtain component resources. The designs used to test this +driver were built for a Cyclone(R) V SOC FPGA board, a Cyclone(R) V FPGA board, +and tested with ARM and NIOS processor hosts seperately. The anticipated use +cases are simple communications between an embedded system and an external peer +for status and simple configuration of the embedded system. + +For more information visit www.altera.com and www.rocketboards.org. Support +forums for the driver may be found on www.rocketboards.org, and a design used +to test this driver may be found there as well. Support is also available from +the maintainer of this driver, found in MAINTAINERS. + +The Triple-Speed Ethernet, SGDMA, and MSGDMA components are all soft IP +components that can be assembled and built into an FPGA using the Altera +Quartus toolchain. Quartus 13.1 and 14.0 were used to build the design that +this driver was tested against. The sopc2dts tool is used to create the +device tree for the driver, and may be found at rocketboards.org. + +The driver probe function examines the device tree and determines if the +Triple-Speed Ethernet instance is using an SGDMA or MSGDMA component. The +probe function then installs the appropriate set of DMA routines to +initialize, setup transmits, receives, and interrupt handling primitives for +the respective configurations. + +The SGDMA component is to be deprecated in the near future (over the next 1-2 +years as of this writing in early 2014) in favor of the MSGDMA component. +SGDMA support is included for existing designs and reference in case a +developer wishes to support their own soft DMA logic and driver support. Any +new designs should not use the SGDMA. + +The SGDMA supports only a single transmit or receive operation at a time, and +therefore will not perform as well compared to the MSGDMA soft IP. Please +visit www.altera.com for known, documented SGDMA errata. + +Scatter-gather DMA is not supported by the SGDMA or MSGDMA at this time. +Scatter-gather DMA will be added to a future maintenance update to this +driver. + +Jumbo frames are not supported at this time. + +The driver limits PHY operations to 10/100Mbps, and has not yet been fully +tested for 1Gbps. This support will be added in a future maintenance update. + +1) Kernel Configuration +The kernel configuration option is ALTERA_TSE: + Device Drivers ---> Network device support ---> Ethernet driver support ---> + Altera Triple-Speed Ethernet MAC support (ALTERA_TSE) + +2) Driver parameters list: + debug: message level (0: no output, 16: all); + dma_rx_num: Number of descriptors in the RX list (default is 64); + dma_tx_num: Number of descriptors in the TX list (default is 64). + +3) Command line options +Driver parameters can be also passed in command line by using: + altera_tse=dma_rx_num:128,dma_tx_num:512 + +4) Driver information and notes + +4.1) Transmit process +When the driver's transmit routine is called by the kernel, it sets up a +transmit descriptor by calling the underlying DMA transmit routine (SGDMA or +MSGDMA), and initites a transmit operation. Once the transmit is complete, an +interrupt is driven by the transmit DMA logic. The driver handles the transmit +completion in the context of the interrupt handling chain by recycling +resource required to send and track the requested transmit operation. + +4.2) Receive process +The driver will post receive buffers to the receive DMA logic during driver +intialization. Receive buffers may or may not be queued depending upon the +underlying DMA logic (MSGDMA is able queue receive buffers, SGDMA is not able +to queue receive buffers to the SGDMA receive logic). When a packet is +received, the DMA logic generates an interrupt. The driver handles a receive +interrupt by obtaining the DMA receive logic status, reaping receive +completions until no more receive completions are available. + +4.3) Interrupt Mitigation +The driver is able to mitigate the number of its DMA interrupts +using NAPI for receive operations. Interrupt mitigation is not yet supported +for transmit operations, but will be added in a future maintenance release. + +4.4) Ethtool support +Ethtool is supported. Driver statistics and internal errors can be taken using: +ethtool -S ethX command. It is possible to dump registers etc. + +4.5) PHY Support +The driver is compatible with PAL to work with PHY and GPHY devices. + +4.7) List of source files: + o Kconfig + o Makefile + o altera_tse_main.c: main network device driver + o altera_tse_ethtool.c: ethtool support + o altera_tse.h: private driver structure and common definitions + o altera_msgdma.h: MSGDMA implementation function definitions + o altera_sgdma.h: SGDMA implementation function definitions + o altera_msgdma.c: MSGDMA implementation + o altera_sgdma.c: SGDMA implementation + o altera_sgdmahw.h: SGDMA register and descriptor definitions + o altera_msgdmahw.h: MSGDMA register and descriptor definitions + o altera_utils.c: Driver utility functions + o altera_utils.h: Driver utility function definitions + +5) Debug Information + +The driver exports debug information such as internal statistics, +debug information, MAC and DMA registers etc. + +A user may use the ethtool support to get statistics: +e.g. using: ethtool -S ethX (that shows the statistics counters) +or sees the MAC registers: e.g. using: ethtool -d ethX + +The developer can also use the "debug" module parameter to get +further debug information. + +6) Statistics Support + +The controller and driver support a mix of IEEE standard defined statistics, +RFC defined statistics, and driver or Altera defined statistics. The four +specifications containing the standard definitions for these statistics are +as follows: + + o IEEE 802.3-2012 - IEEE Standard for Ethernet. + o RFC 2863 found at http://www.rfc-editor.org/rfc/rfc2863.txt. + o RFC 2819 found at http://www.rfc-editor.org/rfc/rfc2819.txt. + o Altera Triple Speed Ethernet User Guide, found at http://www.altera.com + +The statistics supported by the TSE and the device driver are as follows: + +"tx_packets" is equivalent to aFramesTransmittedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.2. This statistics is the count of frames that are successfully +transmitted. + +"rx_packets" is equivalent to aFramesReceivedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.5. This statistic is the count of frames that are successfully +received. This count does not include any error packets such as CRC errors, +length errors, or alignment errors. + +"rx_crc_errors" is equivalent to aFrameCheckSequenceErrors defined in IEEE +802.3-2012, Section 5.2.2.1.6. This statistic is the count of frames that are +an integral number of bytes in length and do not pass the CRC test as the frame +is received. + +"rx_align_errors" is equivalent to aAlignmentErrors defined in IEEE 802.3-2012, +Section 5.2.2.1.7. This statistic is the count of frames that are not an +integral number of bytes in length and do not pass the CRC test as the frame is +received. + +"tx_bytes" is equivalent to aOctetsTransmittedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.8. This statistic is the count of data and pad bytes +successfully transmitted from the interface. + +"rx_bytes" is equivalent to aOctetsReceivedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.14. This statistic is the count of data and pad bytes +successfully received by the controller. + +"tx_pause" is equivalent to aPAUSEMACCtrlFramesTransmitted defined in IEEE +802.3-2012, Section 30.3.4.2. This statistic is a count of PAUSE frames +transmitted from the network controller. + +"rx_pause" is equivalent to aPAUSEMACCtrlFramesReceived defined in IEEE +802.3-2012, Section 30.3.4.3. This statistic is a count of PAUSE frames +received by the network controller. + +"rx_errors" is equivalent to ifInErrors defined in RFC 2863. This statistic is +a count of the number of packets received containing errors that prevented the +packet from being delivered to a higher level protocol. + +"tx_errors" is equivalent to ifOutErrors defined in RFC 2863. This statistic +is a count of the number of packets that could not be transmitted due to errors. + +"rx_unicast" is equivalent to ifInUcastPkts defined in RFC 2863. This +statistic is a count of the number of packets received that were not addressed +to the broadcast address or a multicast group. + +"rx_multicast" is equivalent to ifInMulticastPkts defined in RFC 2863. This +statistic is a count of the number of packets received that were addressed to +a multicast address group. + +"rx_broadcast" is equivalent to ifInBroadcastPkts defined in RFC 2863. This +statistic is a count of the number of packets received that were addressed to +the broadcast address. + +"tx_discards" is equivalent to ifOutDiscards defined in RFC 2863. This +statistic is the number of outbound packets not transmitted even though an +error was not detected. An example of a reason this might occur is to free up +internal buffer space. + +"tx_unicast" is equivalent to ifOutUcastPkts defined in RFC 2863. This +statistic counts the number of packets transmitted that were not addressed to +a multicast group or broadcast address. + +"tx_multicast" is equivalent to ifOutMulticastPkts defined in RFC 2863. This +statistic counts the number of packets transmitted that were addressed to a +multicast group. + +"tx_broadcast" is equivalent to ifOutBroadcastPkts defined in RFC 2863. This +statistic counts the number of packets transmitted that were addressed to a +broadcast address. + +"ether_drops" is equivalent to etherStatsDropEvents defined in RFC 2819. +This statistic counts the number of packets dropped due to lack of internal +controller resources. + +"rx_total_bytes" is equivalent to etherStatsOctets defined in RFC 2819. +This statistic counts the total number of bytes received by the controller, +including error and discarded packets. + +"rx_total_packets" is equivalent to etherStatsPkts defined in RFC 2819. +This statistic counts the total number of packets received by the controller, +including error, discarded, unicast, multicast, and broadcast packets. + +"rx_undersize" is equivalent to etherStatsUndersizePkts defined in RFC 2819. +This statistic counts the number of correctly formed packets received less +than 64 bytes long. + +"rx_oversize" is equivalent to etherStatsOversizePkts defined in RFC 2819. +This statistic counts the number of correctly formed packets greater than 1518 +bytes long. + +"rx_64_bytes" is equivalent to etherStatsPkts64Octets defined in RFC 2819. +This statistic counts the total number of packets received that were 64 octets +in length. + +"rx_65_127_bytes" is equivalent to etherStatsPkts65to127Octets defined in RFC +2819. This statistic counts the total number of packets received that were +between 65 and 127 octets in length inclusive. + +"rx_128_255_bytes" is equivalent to etherStatsPkts128to255Octets defined in +RFC 2819. This statistic is the total number of packets received that were +between 128 and 255 octets in length inclusive. + +"rx_256_511_bytes" is equivalent to etherStatsPkts256to511Octets defined in +RFC 2819. This statistic is the total number of packets received that were +between 256 and 511 octets in length inclusive. + +"rx_512_1023_bytes" is equivalent to etherStatsPkts512to1023Octets defined in +RFC 2819. This statistic is the total number of packets received that were +between 512 and 1023 octets in length inclusive. + +"rx_1024_1518_bytes" is equivalent to etherStatsPkts1024to1518Octets define +in RFC 2819. This statistic is the total number of packets received that were +between 1024 and 1518 octets in length inclusive. + +"rx_gte_1519_bytes" is a statistic defined specific to the behavior of the +Altera TSE. This statistics counts the number of received good and errored +frames between the length of 1519 and the maximum frame length configured +in the frm_length register. See the Altera TSE User Guide for More details. + +"rx_jabbers" is equivalent to etherStatsJabbers defined in RFC 2819. This +statistic is the total number of packets received that were longer than 1518 +octets, and had either a bad CRC with an integral number of octets (CRC Error) +or a bad CRC with a non-integral number of octets (Alignment Error). + +"rx_runts" is equivalent to etherStatsFragments defined in RFC 2819. This +statistic is the total number of packets received that were less than 64 octets +in length and had either a bad CRC with an integral number of octets (CRC +error) or a bad CRC with a non-integral number of octets (Alignment Error). diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 5cdb229..eeb5b2e 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -270,16 +270,15 @@ arp_ip_target arp_validate Specifies whether or not ARP probes and replies should be - validated in the active-backup mode. This causes the ARP - monitor to examine the incoming ARP requests and replies, and - only consider a slave to be up if it is receiving the - appropriate ARP traffic. + validated in any mode that supports arp monitoring, or whether + non-ARP traffic should be filtered (disregarded) for link + monitoring purposes. Possible values are: none or 0 - No validation is performed. This is the default. + No validation or filtering is performed. active or 1 @@ -293,31 +292,68 @@ arp_validate Validation is performed for all slaves. - For the active slave, the validation checks ARP replies to - confirm that they were generated by an arp_ip_target. Since - backup slaves do not typically receive these replies, the - validation performed for backup slaves is on the ARP request - sent out via the active slave. It is possible that some - switch or network configurations may result in situations - wherein the backup slaves do not receive the ARP requests; in - such a situation, validation of backup slaves must be - disabled. - - The validation of ARP requests on backup slaves is mainly - helping bonding to decide which slaves are more likely to - work in case of the active slave failure, it doesn't really - guarantee that the backup slave will work if it's selected - as the next active slave. - - This option is useful in network configurations in which - multiple bonding hosts are concurrently issuing ARPs to one or - more targets beyond a common switch. Should the link between - the switch and target fail (but not the switch itself), the - probe traffic generated by the multiple bonding instances will - fool the standard ARP monitor into considering the links as - still up. Use of the arp_validate option can resolve this, as - the ARP monitor will only consider ARP requests and replies - associated with its own instance of bonding. + filter or 4 + + Filtering is applied to all slaves. No validation is + performed. + + filter_active or 5 + + Filtering is applied to all slaves, validation is performed + only for the active slave. + + filter_backup or 6 + + Filtering is applied to all slaves, validation is performed + only for backup slaves. + + Validation: + + Enabling validation causes the ARP monitor to examine the incoming + ARP requests and replies, and only consider a slave to be up if it + is receiving the appropriate ARP traffic. + + For an active slave, the validation checks ARP replies to confirm + that they were generated by an arp_ip_target. Since backup slaves + do not typically receive these replies, the validation performed + for backup slaves is on the broadcast ARP request sent out via the + active slave. It is possible that some switch or network + configurations may result in situations wherein the backup slaves + do not receive the ARP requests; in such a situation, validation + of backup slaves must be disabled. + + The validation of ARP requests on backup slaves is mainly helping + bonding to decide which slaves are more likely to work in case of + the active slave failure, it doesn't really guarantee that the + backup slave will work if it's selected as the next active slave. + + Validation is useful in network configurations in which multiple + bonding hosts are concurrently issuing ARPs to one or more targets + beyond a common switch. Should the link between the switch and + target fail (but not the switch itself), the probe traffic + generated by the multiple bonding instances will fool the standard + ARP monitor into considering the links as still up. Use of + validation can resolve this, as the ARP monitor will only consider + ARP requests and replies associated with its own instance of + bonding. + + Filtering: + + Enabling filtering causes the ARP monitor to only use incoming ARP + packets for link availability purposes. Arriving packets that are + not ARPs are delivered normally, but do not count when determining + if a slave is available. + + Filtering operates by only considering the reception of ARP + packets (any ARP packet, regardless of source or destination) when + determining if a slave has received traffic for link availability + purposes. + + Filtering is useful in network configurations in which significant + levels of third party broadcast traffic would fool the standard + ARP monitor into considering the links as still up. Use of + filtering can resolve this, as only ARP traffic is considered for + link availability purposes. This option was added in bonding version 3.1.0. @@ -506,10 +542,10 @@ mode XOR policy: Transmit based on the selected transmit hash policy. The default policy is a simple [(source - MAC address XOR'd with destination MAC address) modulo - slave count]. Alternate transmit policies may be - selected via the xmit_hash_policy option, described - below. + MAC address XOR'd with destination MAC address XOR + packet type ID) modulo slave count]. Alternate transmit + policies may be selected via the xmit_hash_policy option, + described below. This mode provides load balancing and fault tolerance. @@ -549,13 +585,19 @@ mode balance-tlb or 5 Adaptive transmit load balancing: channel bonding that - does not require any special switch support. The - outgoing traffic is distributed according to the - current load (computed relative to the speed) on each - slave. Incoming traffic is received by the current - slave. If the receiving slave fails, another slave - takes over the MAC address of the failed receiving - slave. + does not require any special switch support. + + In tlb_dynamic_lb=1 mode; the outgoing traffic is + distributed according to the current load (computed + relative to the speed) on each slave. + + In tlb_dynamic_lb=0 mode; the load balancing based on + current load is disabled and the load is distributed + only using the hash distribution. + + Incoming traffic is received by the current slave. + If the receiving slave fails, another slave takes over + the MAC address of the failed receiving slave. Prerequisite: @@ -700,6 +742,28 @@ primary_reselect This option was added for bonding version 3.6.0. +tlb_dynamic_lb + + Specifies if dynamic shuffling of flows is enabled in tlb + mode. The value has no effect on any other modes. + + The default behavior of tlb mode is to shuffle active flows across + slaves based on the load in that interval. This gives nice lb + characteristics but can cause packet reordering. If re-ordering is + a concern use this variable to disable flow shuffling and rely on + load balancing provided solely by the hash distribution. + xmit-hash-policy can be used to select the appropriate hashing for + the setup. + + The sysfs entry can be used to change the setting per bond device + and the initial value is derived from the module parameter. The + sysfs entry is allowed to be changed only if the bond device is + down. + + The default value is "1" that enables flow shuffling while value "0" + disables it. This option was added in bonding driver 3.7.1 + + updelay Specifies the time, in milliseconds, to wait before enabling a @@ -733,14 +797,15 @@ use_carrier xmit_hash_policy Selects the transmit hash policy to use for slave selection in - balance-xor and 802.3ad modes. Possible values are: + balance-xor, 802.3ad, and tlb modes. Possible values are: layer2 - Uses XOR of hardware MAC addresses to generate the - hash. The formula is + Uses XOR of hardware MAC addresses and packet type ID + field to generate the hash. The formula is - (source MAC XOR destination MAC) modulo slave count + hash = source MAC XOR destination MAC XOR packet type ID + slave number = hash modulo slave count This algorithm will place all traffic to a particular network peer on the same slave. @@ -755,7 +820,7 @@ xmit_hash_policy Uses XOR of hardware MAC addresses and IP addresses to generate the hash. The formula is - hash = source MAC XOR destination MAC + hash = source MAC XOR destination MAC XOR packet type ID hash = hash XOR source IP XOR destination IP hash = hash XOR (hash RSHIFT 16) hash = hash XOR (hash RSHIFT 8) @@ -2237,13 +2302,13 @@ broadcast: Like active-backup, there is not much advantage to this bandwidth. Additionally, the linux bonding 802.3ad implementation - distributes traffic by peer (using an XOR of MAC addresses), - so in a "gatewayed" configuration, all outgoing traffic will - generally use the same device. Incoming traffic may also end - up on a single device, but that is dependent upon the - balancing policy of the peer's 8023.ad implementation. In a - "local" configuration, traffic will be distributed across the - devices in the bond. + distributes traffic by peer (using an XOR of MAC addresses + and packet type ID), so in a "gatewayed" configuration, all + outgoing traffic will generally use the same device. Incoming + traffic may also end up on a single device, but that is + dependent upon the balancing policy of the peer's 8023.ad + implementation. In a "local" configuration, traffic will be + distributed across the devices in the bond. Finally, the 802.3ad mode mandates the use of the MII monitor, therefore, the ARP monitor is not available in this mode. diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 988be27..2236d6d 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -469,6 +469,41 @@ solution for a couple of reasons: having this 'send only' use-case we may remove the receive list in the Kernel to save a little (really a very little!) CPU usage. + 4.1.1.1 CAN filter usage optimisation + + The CAN filters are processed in per-device filter lists at CAN frame + reception time. To reduce the number of checks that need to be performed + while walking through the filter lists the CAN core provides an optimized + filter handling when the filter subscription focusses on a single CAN ID. + + For the possible 2048 SFF CAN identifiers the identifier is used as an index + to access the corresponding subscription list without any further checks. + For the 2^29 possible EFF CAN identifiers a 10 bit XOR folding is used as + hash function to retrieve the EFF table index. + + To benefit from the optimized filters for single CAN identifiers the + CAN_SFF_MASK or CAN_EFF_MASK have to be set into can_filter.mask together + with set CAN_EFF_FLAG and CAN_RTR_FLAG bits. A set CAN_EFF_FLAG bit in the + can_filter.mask makes clear that it matters whether a SFF or EFF CAN ID is + subscribed. E.g. in the example from above + + rfilter[0].can_id = 0x123; + rfilter[0].can_mask = CAN_SFF_MASK; + + both SFF frames with CAN ID 0x123 and EFF frames with 0xXXXXX123 can pass. + + To filter for only 0x123 (SFF) and 0x12345678 (EFF) CAN identifiers the + filter has to be defined in this way to benefit from the optimized filters: + + struct can_filter rfilter[2]; + + rfilter[0].can_id = 0x123; + rfilter[0].can_mask = (CAN_EFF_FLAG | CAN_RTR_FLAG | CAN_SFF_MASK); + rfilter[1].can_id = 0x12345678 | CAN_EFF_FLAG; + rfilter[1].can_mask = (CAN_EFF_FLAG | CAN_RTR_FLAG | CAN_EFF_MASK); + + setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, &rfilter, sizeof(rfilter)); + 4.1.2 RAW socket option CAN_RAW_ERR_FILTER As described in chapter 3.4 the CAN interface driver can generate so @@ -1017,7 +1052,7 @@ solution for a couple of reasons: in case of a bus-off condition after the specified delay time in milliseconds. By default it's off. - "bitrate 125000 sample_point 0.875" + "bitrate 125000 sample-point 0.875" Shows the real bit-rate in bits/sec and the sample-point in the range 0.000..0.999. If the calculation of bit-timing parameters is enabled in the kernel (CONFIG_CAN_CALC_BITTIMING=y), the diff --git a/Documentation/networking/cdc_mbim.txt b/Documentation/networking/cdc_mbim.txt new file mode 100644 index 0000000..a15ea60 --- /dev/null +++ b/Documentation/networking/cdc_mbim.txt @@ -0,0 +1,339 @@ + cdc_mbim - Driver for CDC MBIM Mobile Broadband modems + ======================================================== + +The cdc_mbim driver supports USB devices conforming to the "Universal +Serial Bus Communications Class Subclass Specification for Mobile +Broadband Interface Model" [1], which is a further development of +"Universal Serial Bus Communications Class Subclass Specifications for +Network Control Model Devices" [2] optimized for Mobile Broadband +devices, aka "3G/LTE modems". + + +Command Line Parameters +======================= + +The cdc_mbim driver has no parameters of its own. But the probing +behaviour for NCM 1.0 backwards compatible MBIM functions (an +"NCM/MBIM function" as defined in section 3.2 of [1]) is affected +by a cdc_ncm driver parameter: + +prefer_mbim +----------- +Type: Boolean +Valid Range: N/Y (0-1) +Default Value: Y (MBIM is preferred) + +This parameter sets the system policy for NCM/MBIM functions. Such +functions will be handled by either the cdc_ncm driver or the cdc_mbim +driver depending on the prefer_mbim setting. Setting prefer_mbim=N +makes the cdc_mbim driver ignore these functions and lets the cdc_ncm +driver handle them instead. + +The parameter is writable, and can be changed at any time. A manual +unbind/bind is required to make the change effective for NCM/MBIM +functions bound to the "wrong" driver + + +Basic usage +=========== + +MBIM functions are inactive when unmanaged. The cdc_mbim driver only +provides an userspace interface to the MBIM control channel, and will +not participate in the management of the function. This implies that a +userspace MBIM management application always is required to enable a +MBIM function. + +Such userspace applications includes, but are not limited to: + - mbimcli (included with the libmbim [3] library), and + - ModemManager [4] + +Establishing a MBIM IP session reequires at least these actions by the +management application: + - open the control channel + - configure network connection settings + - connect to network + - configure IP interface + +Management application development +---------------------------------- +The driver <-> userspace interfaces are described below. The MBIM +control channel protocol is described in [1]. + + +MBIM control channel userspace ABI +================================== + +/dev/cdc-wdmX character device +------------------------------ +The driver creates a two-way pipe to the MBIM function control channel +using the cdc-wdm driver as a subdriver. The userspace end of the +control channel pipe is a /dev/cdc-wdmX character device. + +The cdc_mbim driver does not process or police messages on the control +channel. The channel is fully delegated to the userspace management +application. It is therefore up to this application to ensure that it +complies with all the control channel requirements in [1]. + +The cdc-wdmX device is created as a child of the MBIM control +interface USB device. The character device associated with a specific +MBIM function can be looked up using sysfs. For example: + + bjorn@nemi:~$ ls /sys/bus/usb/drivers/cdc_mbim/2-4:2.12/usbmisc + cdc-wdm0 + + bjorn@nemi:~$ grep . /sys/bus/usb/drivers/cdc_mbim/2-4:2.12/usbmisc/cdc-wdm0/dev + 180:0 + + +USB configuration descriptors +----------------------------- +The wMaxControlMessage field of the CDC MBIM functional descriptor +limits the maximum control message size. The managament application is +responsible for negotiating a control message size complying with the +requirements in section 9.3.1 of [1], taking this descriptor field +into consideration. + +The userspace application can access the CDC MBIM functional +descriptor of a MBIM function using either of the two USB +configuration descriptor kernel interfaces described in [6] or [7]. + +See also the ioctl documentation below. + + +Fragmentation +------------- +The userspace application is responsible for all control message +fragmentation and defragmentaion, as described in section 9.5 of [1]. + + +/dev/cdc-wdmX write() +--------------------- +The MBIM control messages from the management application *must not* +exceed the negotiated control message size. + + +/dev/cdc-wdmX read() +-------------------- +The management application *must* accept control messages of up the +negotiated control message size. + + +/dev/cdc-wdmX ioctl() +-------------------- +IOCTL_WDM_MAX_COMMAND: Get Maximum Command Size +This ioctl returns the wMaxControlMessage field of the CDC MBIM +functional descriptor for MBIM devices. This is intended as a +convenience, eliminating the need to parse the USB descriptors from +userspace. + + #include <stdio.h> + #include <fcntl.h> + #include <sys/ioctl.h> + #include <linux/types.h> + #include <linux/usb/cdc-wdm.h> + int main() + { + __u16 max; + int fd = open("/dev/cdc-wdm0", O_RDWR); + if (!ioctl(fd, IOCTL_WDM_MAX_COMMAND, &max)) + printf("wMaxControlMessage is %d\n", max); + } + + +Custom device services +---------------------- +The MBIM specification allows vendors to freely define additional +services. This is fully supported by the cdc_mbim driver. + +Support for new MBIM services, including vendor specified services, is +implemented entirely in userspace, like the rest of the MBIM control +protocol + +New services should be registered in the MBIM Registry [5]. + + + +MBIM data channel userspace ABI +=============================== + +wwanY network device +-------------------- +The cdc_mbim driver represents the MBIM data channel as a single +network device of the "wwan" type. This network device is initially +mapped to MBIM IP session 0. + + +Multiplexed IP sessions (IPS) +----------------------------- +MBIM allows multiplexing up to 256 IP sessions over a single USB data +channel. The cdc_mbim driver models such IP sessions as 802.1q VLAN +subdevices of the master wwanY device, mapping MBIM IP session Z to +VLAN ID Z for all values of Z greater than 0. + +The device maximum Z is given in the MBIM_DEVICE_CAPS_INFO structure +described in section 10.5.1 of [1]. + +The userspace management application is responsible for adding new +VLAN links prior to establishing MBIM IP sessions where the SessionId +is greater than 0. These links can be added by using the normal VLAN +kernel interfaces, either ioctl or netlink. + +For example, adding a link for a MBIM IP session with SessionId 3: + + ip link add link wwan0 name wwan0.3 type vlan id 3 + +The driver will automatically map the "wwan0.3" network device to MBIM +IP session 3. + + +Device Service Streams (DSS) +---------------------------- +MBIM also allows up to 256 non-IP data streams to be multiplexed over +the same shared USB data channel. The cdc_mbim driver models these +sessions as another set of 802.1q VLAN subdevices of the master wwanY +device, mapping MBIM DSS session A to VLAN ID (256 + A) for all values +of A. + +The device maximum A is given in the MBIM_DEVICE_SERVICES_INFO +structure described in section 10.5.29 of [1]. + +The DSS VLAN subdevices are used as a practical interface between the +shared MBIM data channel and a MBIM DSS aware userspace application. +It is not intended to be presented as-is to an end user. The +assumption is that an userspace application initiating a DSS session +also takes care of the necessary framing of the DSS data, presenting +the stream to the end user in an appropriate way for the stream type. + +The network device ABI requires a dummy ethernet header for every DSS +data frame being transported. The contents of this header is +arbitrary, with the following exceptions: + - TX frames using an IP protocol (0x0800 or 0x86dd) will be dropped + - RX frames will have the protocol field set to ETH_P_802_3 (but will + not be properly formatted 802.3 frames) + - RX frames will have the destination address set to the hardware + address of the master device + +The DSS supporting userspace management application is responsible for +adding the dummy ethernet header on TX and stripping it on RX. + +This is a simple example using tools commonly available, exporting +DssSessionId 5 as a pty character device pointed to by a /dev/nmea +symlink: + + ip link add link wwan0 name wwan0.dss5 type vlan id 261 + ip link set dev wwan0.dss5 up + socat INTERFACE:wwan0.dss5,type=2 PTY:,echo=0,link=/dev/nmea + +This is only an example, most suitable for testing out a DSS +service. Userspace applications supporting specific MBIM DSS services +are expected to use the tools and programming interfaces required by +that service. + +Note that adding VLAN links for DSS sessions is entirely optional. A +management application may instead choose to bind a packet socket +directly to the master network device, using the received VLAN tags to +map frames to the correct DSS session and adding 18 byte VLAN ethernet +headers with the appropriate tag on TX. In this case using a socket +filter is recommended, matching only the DSS VLAN subset. This avoid +unnecessary copying of unrelated IP session data to userspace. For +example: + + static struct sock_filter dssfilter[] = { + /* use special negative offsets to get VLAN tag */ + BPF_STMT(BPF_LD|BPF_B|BPF_ABS, SKF_AD_OFF + SKF_AD_VLAN_TAG_PRESENT), + BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, 1, 0, 6), /* true */ + + /* verify DSS VLAN range */ + BPF_STMT(BPF_LD|BPF_H|BPF_ABS, SKF_AD_OFF + SKF_AD_VLAN_TAG), + BPF_JUMP(BPF_JMP|BPF_JGE|BPF_K, 256, 0, 4), /* 256 is first DSS VLAN */ + BPF_JUMP(BPF_JMP|BPF_JGE|BPF_K, 512, 3, 0), /* 511 is last DSS VLAN */ + + /* verify ethertype */ + BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 2 * ETH_ALEN), + BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ETH_P_802_3, 0, 1), + + BPF_STMT(BPF_RET|BPF_K, (u_int)-1), /* accept */ + BPF_STMT(BPF_RET|BPF_K, 0), /* ignore */ + }; + + + +Tagged IP session 0 VLAN +------------------------ +As described above, MBIM IP session 0 is treated as special by the +driver. It is initially mapped to untagged frames on the wwanY +network device. + +This mapping implies a few restrictions on multiplexed IPS and DSS +sessions, which may not always be practical: + - no IPS or DSS session can use a frame size greater than the MTU on + IP session 0 + - no IPS or DSS session can be in the up state unless the network + device representing IP session 0 also is up + +These problems can be avoided by optionally making the driver map IP +session 0 to a VLAN subdevice, similar to all other IP sessions. This +behaviour is triggered by adding a VLAN link for the magic VLAN ID +4094. The driver will then immediately start mapping MBIM IP session +0 to this VLAN, and will drop untagged frames on the master wwanY +device. + +Tip: It might be less confusing to the end user to name this VLAN +subdevice after the MBIM SessionID instead of the VLAN ID. For +example: + + ip link add link wwan0 name wwan0.0 type vlan id 4094 + + +VLAN mapping +------------ + +Summarizing the cdc_mbim driver mapping described above, we have this +relationship between VLAN tags on the wwanY network device and MBIM +sessions on the shared USB data channel: + + VLAN ID MBIM type MBIM SessionID Notes + --------------------------------------------------------- + untagged IPS 0 a) + 1 - 255 IPS 1 - 255 <VLANID> + 256 - 511 DSS 0 - 255 <VLANID - 256> + 512 - 4093 b) + 4094 IPS 0 c) + + a) if no VLAN ID 4094 link exists, else dropped + b) unsupported VLAN range, unconditionally dropped + c) if a VLAN ID 4094 link exists, else dropped + + + + +References +========== + +[1] USB Implementers Forum, Inc. - "Universal Serial Bus + Communications Class Subclass Specification for Mobile Broadband + Interface Model", Revision 1.0 (Errata 1), May 1, 2013 + - http://www.usb.org/developers/docs/devclass_docs/ + +[2] USB Implementers Forum, Inc. - "Universal Serial Bus + Communications Class Subclass Specifications for Network Control + Model Devices", Revision 1.0 (Errata 1), November 24, 2010 + - http://www.usb.org/developers/docs/devclass_docs/ + +[3] libmbim - "a glib-based library for talking to WWAN modems and + devices which speak the Mobile Interface Broadband Model (MBIM) + protocol" + - http://www.freedesktop.org/wiki/Software/libmbim/ + +[4] ModemManager - "a DBus-activated daemon which controls mobile + broadband (2G/3G/4G) devices and connections" + - http://www.freedesktop.org/wiki/Software/ModemManager/ + +[5] "MBIM (Mobile Broadband Interface Model) Registry" + - http://compliance.usb.org/mbim/ + +[6] "/proc/bus/usb filesystem output" + - Documentation/usb/proc_usb_info.txt + +[7] "/sys/bus/usb/devices/.../descriptors" + - Documentation/ABI/stable/sysfs-bus-usb diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index a06b48d..c48a970 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -277,10 +277,11 @@ Possible BPF extensions are shown in the following table: mark skb->mark queue skb->queue_mapping hatype skb->dev->type - rxhash skb->rxhash + rxhash skb->hash cpu raw_smp_processor_id() vlan_tci vlan_tx_tag_get(skb) vlan_pr vlan_tx_tag_present(skb) + rand prandom_u32() These extensions can also be prefixed with '#'. Examples for low-level BPF: @@ -308,6 +309,18 @@ Examples for low-level BPF: ret #-1 drop: ret #0 +** icmp random packet sampling, 1 in 4 + ldh [12] + jne #0x800, drop + ldb [23] + jneq #1, drop + # get a random uint32 number + ld rand + mod #4 + jneq #1, drop + ret #-1 + drop: ret #0 + ** SECCOMP filter example: ld [4] /* offsetof(struct seccomp_data, arch) */ @@ -546,6 +559,456 @@ ffffffffa0069c8f + <x>: For BPF JIT developers, bpf_jit_disasm, bpf_asm and bpf_dbg provides a useful toolchain for developing and testing the kernel's JIT compiler. +BPF kernel internals +-------------------- +Internally, for the kernel interpreter, a different instruction set +format with similar underlying principles from BPF described in previous +paragraphs is being used. However, the instruction set format is modelled +closer to the underlying architecture to mimic native instruction sets, so +that a better performance can be achieved (more details later). This new +ISA is called 'eBPF' or 'internal BPF' interchangeably. (Note: eBPF which +originates from [e]xtended BPF is not the same as BPF extensions! While +eBPF is an ISA, BPF extensions date back to classic BPF's 'overloading' +of BPF_LD | BPF_{B,H,W} | BPF_ABS instruction.) + +It is designed to be JITed with one to one mapping, which can also open up +the possibility for GCC/LLVM compilers to generate optimized eBPF code through +an eBPF backend that performs almost as fast as natively compiled code. + +The new instruction set was originally designed with the possible goal in +mind to write programs in "restricted C" and compile into eBPF with a optional +GCC/LLVM backend, so that it can just-in-time map to modern 64-bit CPUs with +minimal performance overhead over two steps, that is, C -> eBPF -> native code. + +Currently, the new format is being used for running user BPF programs, which +includes seccomp BPF, classic socket filters, cls_bpf traffic classifier, +team driver's classifier for its load-balancing mode, netfilter's xt_bpf +extension, PTP dissector/classifier, and much more. They are all internally +converted by the kernel into the new instruction set representation and run +in the eBPF interpreter. For in-kernel handlers, this all works transparently +by using bpf_prog_create() for setting up the filter, resp. +bpf_prog_destroy() for destroying it. The macro +BPF_PROG_RUN(filter, ctx) transparently invokes eBPF interpreter or JITed +code to run the filter. 'filter' is a pointer to struct bpf_prog that we +got from bpf_prog_create(), and 'ctx' the given context (e.g. +skb pointer). All constraints and restrictions from bpf_check_classic() apply +before a conversion to the new layout is being done behind the scenes! + +Currently, the classic BPF format is being used for JITing on most of the +architectures. Only x86-64 performs JIT compilation from eBPF instruction set, +however, future work will migrate other JIT compilers as well, so that they +will profit from the very same benefits. + +Some core changes of the new internal format: + +- Number of registers increase from 2 to 10: + + The old format had two registers A and X, and a hidden frame pointer. The + new layout extends this to be 10 internal registers and a read-only frame + pointer. Since 64-bit CPUs are passing arguments to functions via registers + the number of args from eBPF program to in-kernel function is restricted + to 5 and one register is used to accept return value from an in-kernel + function. Natively, x86_64 passes first 6 arguments in registers, aarch64/ + sparcv9/mips64 have 7 - 8 registers for arguments; x86_64 has 6 callee saved + registers, and aarch64/sparcv9/mips64 have 11 or more callee saved registers. + + Therefore, eBPF calling convention is defined as: + + * R0 - return value from in-kernel function, and exit value for eBPF program + * R1 - R5 - arguments from eBPF program to in-kernel function + * R6 - R9 - callee saved registers that in-kernel function will preserve + * R10 - read-only frame pointer to access stack + + Thus, all eBPF registers map one to one to HW registers on x86_64, aarch64, + etc, and eBPF calling convention maps directly to ABIs used by the kernel on + 64-bit architectures. + + On 32-bit architectures JIT may map programs that use only 32-bit arithmetic + and may let more complex programs to be interpreted. + + R0 - R5 are scratch registers and eBPF program needs spill/fill them if + necessary across calls. Note that there is only one eBPF program (== one + eBPF main routine) and it cannot call other eBPF functions, it can only + call predefined in-kernel functions, though. + +- Register width increases from 32-bit to 64-bit: + + Still, the semantics of the original 32-bit ALU operations are preserved + via 32-bit subregisters. All eBPF registers are 64-bit with 32-bit lower + subregisters that zero-extend into 64-bit if they are being written to. + That behavior maps directly to x86_64 and arm64 subregister definition, but + makes other JITs more difficult. + + 32-bit architectures run 64-bit internal BPF programs via interpreter. + Their JITs may convert BPF programs that only use 32-bit subregisters into + native instruction set and let the rest being interpreted. + + Operation is 64-bit, because on 64-bit architectures, pointers are also + 64-bit wide, and we want to pass 64-bit values in/out of kernel functions, + so 32-bit eBPF registers would otherwise require to define register-pair + ABI, thus, there won't be able to use a direct eBPF register to HW register + mapping and JIT would need to do combine/split/move operations for every + register in and out of the function, which is complex, bug prone and slow. + Another reason is the use of atomic 64-bit counters. + +- Conditional jt/jf targets replaced with jt/fall-through: + + While the original design has constructs such as "if (cond) jump_true; + else jump_false;", they are being replaced into alternative constructs like + "if (cond) jump_true; /* else fall-through */". + +- Introduces bpf_call insn and register passing convention for zero overhead + calls from/to other kernel functions: + + Before an in-kernel function call, the internal BPF program needs to + place function arguments into R1 to R5 registers to satisfy calling + convention, then the interpreter will take them from registers and pass + to in-kernel function. If R1 - R5 registers are mapped to CPU registers + that are used for argument passing on given architecture, the JIT compiler + doesn't need to emit extra moves. Function arguments will be in the correct + registers and BPF_CALL instruction will be JITed as single 'call' HW + instruction. This calling convention was picked to cover common call + situations without performance penalty. + + After an in-kernel function call, R1 - R5 are reset to unreadable and R0 has + a return value of the function. Since R6 - R9 are callee saved, their state + is preserved across the call. + + For example, consider three C functions: + + u64 f1() { return (*_f2)(1); } + u64 f2(u64 a) { return f3(a + 1, a); } + u64 f3(u64 a, u64 b) { return a - b; } + + GCC can compile f1, f3 into x86_64: + + f1: + movl $1, %edi + movq _f2(%rip), %rax + jmp *%rax + f3: + movq %rdi, %rax + subq %rsi, %rax + ret + + Function f2 in eBPF may look like: + + f2: + bpf_mov R2, R1 + bpf_add R1, 1 + bpf_call f3 + bpf_exit + + If f2 is JITed and the pointer stored to '_f2'. The calls f1 -> f2 -> f3 and + returns will be seamless. Without JIT, __sk_run_filter() interpreter needs to + be used to call into f2. + + For practical reasons all eBPF programs have only one argument 'ctx' which is + already placed into R1 (e.g. on __sk_run_filter() startup) and the programs + can call kernel functions with up to 5 arguments. Calls with 6 or more arguments + are currently not supported, but these restrictions can be lifted if necessary + in the future. + + On 64-bit architectures all register map to HW registers one to one. For + example, x86_64 JIT compiler can map them as ... + + R0 - rax + R1 - rdi + R2 - rsi + R3 - rdx + R4 - rcx + R5 - r8 + R6 - rbx + R7 - r13 + R8 - r14 + R9 - r15 + R10 - rbp + + ... since x86_64 ABI mandates rdi, rsi, rdx, rcx, r8, r9 for argument passing + and rbx, r12 - r15 are callee saved. + + Then the following internal BPF pseudo-program: + + bpf_mov R6, R1 /* save ctx */ + bpf_mov R2, 2 + bpf_mov R3, 3 + bpf_mov R4, 4 + bpf_mov R5, 5 + bpf_call foo + bpf_mov R7, R0 /* save foo() return value */ + bpf_mov R1, R6 /* restore ctx for next call */ + bpf_mov R2, 6 + bpf_mov R3, 7 + bpf_mov R4, 8 + bpf_mov R5, 9 + bpf_call bar + bpf_add R0, R7 + bpf_exit + + After JIT to x86_64 may look like: + + push %rbp + mov %rsp,%rbp + sub $0x228,%rsp + mov %rbx,-0x228(%rbp) + mov %r13,-0x220(%rbp) + mov %rdi,%rbx + mov $0x2,%esi + mov $0x3,%edx + mov $0x4,%ecx + mov $0x5,%r8d + callq foo + mov %rax,%r13 + mov %rbx,%rdi + mov $0x2,%esi + mov $0x3,%edx + mov $0x4,%ecx + mov $0x5,%r8d + callq bar + add %r13,%rax + mov -0x228(%rbp),%rbx + mov -0x220(%rbp),%r13 + leaveq + retq + + Which is in this example equivalent in C to: + + u64 bpf_filter(u64 ctx) + { + return foo(ctx, 2, 3, 4, 5) + bar(ctx, 6, 7, 8, 9); + } + + In-kernel functions foo() and bar() with prototype: u64 (*)(u64 arg1, u64 + arg2, u64 arg3, u64 arg4, u64 arg5); will receive arguments in proper + registers and place their return value into '%rax' which is R0 in eBPF. + Prologue and epilogue are emitted by JIT and are implicit in the + interpreter. R0-R5 are scratch registers, so eBPF program needs to preserve + them across the calls as defined by calling convention. + + For example the following program is invalid: + + bpf_mov R1, 1 + bpf_call foo + bpf_mov R0, R1 + bpf_exit + + After the call the registers R1-R5 contain junk values and cannot be read. + In the future an eBPF verifier can be used to validate internal BPF programs. + +Also in the new design, eBPF is limited to 4096 insns, which means that any +program will terminate quickly and will only call a fixed number of kernel +functions. Original BPF and the new format are two operand instructions, +which helps to do one-to-one mapping between eBPF insn and x86 insn during JIT. + +The input context pointer for invoking the interpreter function is generic, +its content is defined by a specific use case. For seccomp register R1 points +to seccomp_data, for converted BPF filters R1 points to a skb. + +A program, that is translated internally consists of the following elements: + + op:16, jt:8, jf:8, k:32 ==> op:8, dst_reg:4, src_reg:4, off:16, imm:32 + +So far 87 internal BPF instructions were implemented. 8-bit 'op' opcode field +has room for new instructions. Some of them may use 16/24/32 byte encoding. New +instructions must be multiple of 8 bytes to preserve backward compatibility. + +Internal BPF is a general purpose RISC instruction set. Not every register and +every instruction are used during translation from original BPF to new format. +For example, socket filters are not using 'exclusive add' instruction, but +tracing filters may do to maintain counters of events, for example. Register R9 +is not used by socket filters either, but more complex filters may be running +out of registers and would have to resort to spill/fill to stack. + +Internal BPF can used as generic assembler for last step performance +optimizations, socket filters and seccomp are using it as assembler. Tracing +filters may use it as assembler to generate code from kernel. In kernel usage +may not be bounded by security considerations, since generated internal BPF code +may be optimizing internal code path and not being exposed to the user space. +Safety of internal BPF can come from a verifier (TBD). In such use cases as +described, it may be used as safe instruction set. + +Just like the original BPF, the new format runs within a controlled environment, +is deterministic and the kernel can easily prove that. The safety of the program +can be determined in two steps: first step does depth-first-search to disallow +loops and other CFG validation; second step starts from the first insn and +descends all possible paths. It simulates execution of every insn and observes +the state change of registers and stack. + +eBPF opcode encoding +-------------------- + +eBPF is reusing most of the opcode encoding from classic to simplify conversion +of classic BPF to eBPF. For arithmetic and jump instructions the 8-bit 'code' +field is divided into three parts: + + +----------------+--------+--------------------+ + | 4 bits | 1 bit | 3 bits | + | operation code | source | instruction class | + +----------------+--------+--------------------+ + (MSB) (LSB) + +Three LSB bits store instruction class which is one of: + + Classic BPF classes: eBPF classes: + + BPF_LD 0x00 BPF_LD 0x00 + BPF_LDX 0x01 BPF_LDX 0x01 + BPF_ST 0x02 BPF_ST 0x02 + BPF_STX 0x03 BPF_STX 0x03 + BPF_ALU 0x04 BPF_ALU 0x04 + BPF_JMP 0x05 BPF_JMP 0x05 + BPF_RET 0x06 [ class 6 unused, for future if needed ] + BPF_MISC 0x07 BPF_ALU64 0x07 + +When BPF_CLASS(code) == BPF_ALU or BPF_JMP, 4th bit encodes source operand ... + + BPF_K 0x00 + BPF_X 0x08 + + * in classic BPF, this means: + + BPF_SRC(code) == BPF_X - use register X as source operand + BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand + + * in eBPF, this means: + + BPF_SRC(code) == BPF_X - use 'src_reg' register as source operand + BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand + +... and four MSB bits store operation code. + +If BPF_CLASS(code) == BPF_ALU or BPF_ALU64 [ in eBPF ], BPF_OP(code) is one of: + + BPF_ADD 0x00 + BPF_SUB 0x10 + BPF_MUL 0x20 + BPF_DIV 0x30 + BPF_OR 0x40 + BPF_AND 0x50 + BPF_LSH 0x60 + BPF_RSH 0x70 + BPF_NEG 0x80 + BPF_MOD 0x90 + BPF_XOR 0xa0 + BPF_MOV 0xb0 /* eBPF only: mov reg to reg */ + BPF_ARSH 0xc0 /* eBPF only: sign extending shift right */ + BPF_END 0xd0 /* eBPF only: endianness conversion */ + +If BPF_CLASS(code) == BPF_JMP, BPF_OP(code) is one of: + + BPF_JA 0x00 + BPF_JEQ 0x10 + BPF_JGT 0x20 + BPF_JGE 0x30 + BPF_JSET 0x40 + BPF_JNE 0x50 /* eBPF only: jump != */ + BPF_JSGT 0x60 /* eBPF only: signed '>' */ + BPF_JSGE 0x70 /* eBPF only: signed '>=' */ + BPF_CALL 0x80 /* eBPF only: function call */ + BPF_EXIT 0x90 /* eBPF only: function return */ + +So BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF +and eBPF. There are only two registers in classic BPF, so it means A += X. +In eBPF it means dst_reg = (u32) dst_reg + (u32) src_reg; similarly, +BPF_XOR | BPF_K | BPF_ALU means A ^= imm32 in classic BPF and analogous +src_reg = (u32) src_reg ^ (u32) imm32 in eBPF. + +Classic BPF is using BPF_MISC class to represent A = X and X = A moves. +eBPF is using BPF_MOV | BPF_X | BPF_ALU code instead. Since there are no +BPF_MISC operations in eBPF, the class 7 is used as BPF_ALU64 to mean +exactly the same operations as BPF_ALU, but with 64-bit wide operands +instead. So BPF_ADD | BPF_X | BPF_ALU64 means 64-bit addition, i.e.: +dst_reg = dst_reg + src_reg + +Classic BPF wastes the whole BPF_RET class to represent a single 'ret' +operation. Classic BPF_RET | BPF_K means copy imm32 into return register +and perform function exit. eBPF is modeled to match CPU, so BPF_JMP | BPF_EXIT +in eBPF means function exit only. The eBPF program needs to store return +value into register R0 before doing a BPF_EXIT. Class 6 in eBPF is currently +unused and reserved for future use. + +For load and store instructions the 8-bit 'code' field is divided as: + + +--------+--------+-------------------+ + | 3 bits | 2 bits | 3 bits | + | mode | size | instruction class | + +--------+--------+-------------------+ + (MSB) (LSB) + +Size modifier is one of ... + + BPF_W 0x00 /* word */ + BPF_H 0x08 /* half word */ + BPF_B 0x10 /* byte */ + BPF_DW 0x18 /* eBPF only, double word */ + +... which encodes size of load/store operation: + + B - 1 byte + H - 2 byte + W - 4 byte + DW - 8 byte (eBPF only) + +Mode modifier is one of: + + BPF_IMM 0x00 /* classic BPF only, reserved in eBPF */ + BPF_ABS 0x20 + BPF_IND 0x40 + BPF_MEM 0x60 + BPF_LEN 0x80 /* classic BPF only, reserved in eBPF */ + BPF_MSH 0xa0 /* classic BPF only, reserved in eBPF */ + BPF_XADD 0xc0 /* eBPF only, exclusive add */ + +eBPF has two non-generic instructions: (BPF_ABS | <size> | BPF_LD) and +(BPF_IND | <size> | BPF_LD) which are used to access packet data. + +They had to be carried over from classic to have strong performance of +socket filters running in eBPF interpreter. These instructions can only +be used when interpreter context is a pointer to 'struct sk_buff' and +have seven implicit operands. Register R6 is an implicit input that must +contain pointer to sk_buff. Register R0 is an implicit output which contains +the data fetched from the packet. Registers R1-R5 are scratch registers +and must not be used to store the data across BPF_ABS | BPF_LD or +BPF_IND | BPF_LD instructions. + +These instructions have implicit program exit condition as well. When +eBPF program is trying to access the data beyond the packet boundary, +the interpreter will abort the execution of the program. JIT compilers +therefore must preserve this property. src_reg and imm32 fields are +explicit inputs to these instructions. + +For example: + + BPF_IND | BPF_W | BPF_LD means: + + R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32)) + and R1 - R5 were scratched. + +Unlike classic BPF instruction set, eBPF has generic load/store operations: + +BPF_MEM | <size> | BPF_STX: *(size *) (dst_reg + off) = src_reg +BPF_MEM | <size> | BPF_ST: *(size *) (dst_reg + off) = imm32 +BPF_MEM | <size> | BPF_LDX: dst_reg = *(size *) (src_reg + off) +BPF_XADD | BPF_W | BPF_STX: lock xadd *(u32 *)(dst_reg + off16) += src_reg +BPF_XADD | BPF_DW | BPF_STX: lock xadd *(u64 *)(dst_reg + off16) += src_reg + +Where size is one of: BPF_B or BPF_H or BPF_W or BPF_DW. Note that 1 and +2 byte atomic increments are not supported. + +Testing +------- + +Next to the BPF toolchain, the kernel also ships a test module that contains +various test cases for classic and internal BPF that can be executed against +the BPF interpreter and JIT compiler. It can be found in lib/test_bpf.c and +enabled via Kconfig: + + CONFIG_TEST_BPF=m + +After the module has been built and installed, the test suite can be executed +via insmod or modprobe against 'test_bpf' module. Results of the test cases +including timings in nsec can be found in the kernel log (dmesg). + Misc ---- @@ -561,3 +1024,4 @@ the underlying architecture. Jay Schulist <jschlst@samba.org> Daniel Borkmann <dborkman@redhat.com> +Alexei Starovoitov <ast@plumgrid.com> diff --git a/Documentation/networking/gianfar.txt b/Documentation/networking/gianfar.txt index ad474ea..ba1daea 100644 --- a/Documentation/networking/gianfar.txt +++ b/Documentation/networking/gianfar.txt @@ -1,38 +1,8 @@ The Gianfar Ethernet Driver -Sysfs File description Author: Andy Fleming <afleming@freescale.com> Updated: 2005-07-28 -SYSFS - -Several of the features of the gianfar driver are controlled -through sysfs files. These are: - -bd_stash: -To stash RX Buffer Descriptors in the L2, echo 'on' or '1' to -bd_stash, echo 'off' or '0' to disable - -rx_stash_len: -To stash the first n bytes of the packet in L2, echo the number -of bytes to buf_stash_len. echo 0 to disable. - -WARNING: You could really screw these up if you set them too low or high! -fifo_threshold: -To change the number of bytes the controller needs in the -fifo before it starts transmission, echo the number of bytes to -fifo_thresh. Range should be 0-511. - -fifo_starve: -When the FIFO has less than this many bytes during a transmit, it -enters starve mode, and increases the priority of TX memory -transactions. To change, echo the number of bytes to -fifo_starve. Range should be 0-511. - -fifo_starve_off: -Once in starve mode, the FIFO remains there until it has this -many bytes. To change, echo the number of bytes to -fifo_starve_off. Range should be 0-511. CHECKSUM OFFLOADING diff --git a/Documentation/networking/i40e.txt b/Documentation/networking/i40e.txt index f737273..a251bf4 100644 --- a/Documentation/networking/i40e.txt +++ b/Documentation/networking/i40e.txt @@ -69,8 +69,11 @@ Additional Configurations FCoE ---- - Fiber Channel over Ethernet (FCoE) hardware offload is not currently - supported. + The driver supports Fiber Channel over Ethernet (FCoE) and Data Center + Bridging (DCB) functionality. Configuring DCB and FCoE is outside the scope + of this driver doc. Refer to http://www.open-fcoe.org/ for FCoE project + information and http://www.open-lldp.org/ or email list + e1000-eedc@lists.sourceforge.net for DCB information. MAC and VLAN anti-spoofing feature ---------------------------------- diff --git a/Documentation/networking/igb.txt b/Documentation/networking/igb.txt index 4ebbd65..43d3549 100644 --- a/Documentation/networking/igb.txt +++ b/Documentation/networking/igb.txt @@ -36,54 +36,6 @@ Default Value: 0 This parameter adds support for SR-IOV. It causes the driver to spawn up to max_vfs worth of virtual function. -QueuePairs ----------- -Valid Range: 0-1 -Default Value: 1 (TX and RX will be paired onto one interrupt vector) - -If set to 0, when MSI-X is enabled, the TX and RX will attempt to occupy -separate vectors. - -This option can be overridden to 1 if there are not sufficient interrupts -available. This can occur if any combination of RSS, VMDQ, and max_vfs -results in more than 4 queues being used. - -Node ----- -Valid Range: 0-n -Default Value: -1 (off) - - 0 - n: where n is the number of the NUMA node that should be used to - allocate memory for this adapter port. - -1: uses the driver default of allocating memory on whichever processor is - running insmod/modprobe. - - The Node parameter will allow you to pick which NUMA node you want to have - the adapter allocate memory from. All driver structures, in-memory queues, - and receive buffers will be allocated on the node specified. This parameter - is only useful when interrupt affinity is specified, otherwise some portion - of the time the interrupt could run on a different core than the memory is - allocated on, causing slower memory access and impacting throughput, CPU, or - both. - -EEE ---- -Valid Range: 0-1 -Default Value: 1 (enabled) - - A link between two EEE-compliant devices will result in periodic bursts of - data followed by long periods where in the link is in an idle state. This Low - Power Idle (LPI) state is supported in both 1Gbps and 100Mbps link speeds. - NOTE: EEE support requires autonegotiation. - -DMAC ----- -Valid Range: 0-1 -Default Value: 1 (enabled) - Enables or disables DMA Coalescing feature. - - - Additional Configurations ========================= diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index ab42c95..29a9351 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -101,19 +101,17 @@ ipfrag_high_thresh - INTEGER Maximum memory used to reassemble IP fragments. When ipfrag_high_thresh bytes of memory is allocated for this purpose, the fragment handler will toss packets until ipfrag_low_thresh - is reached. + is reached. This also serves as a maximum limit to namespaces + different from the initial one. ipfrag_low_thresh - INTEGER - See ipfrag_high_thresh + Maximum memory used to reassemble IP fragments before the kernel + begins to remove incomplete fragment queues to free up resources. + The kernel still accepts new fragments for defragmentation. ipfrag_time - INTEGER Time in seconds to keep an IP fragment in memory. -ipfrag_secret_interval - INTEGER - Regeneration interval (in seconds) of the hash secret (or lifetime - for the hash secret) for IP fragments. - Default: 600 - ipfrag_max_dist - INTEGER ipfrag_max_dist is a non-negative integer value which defines the maximum "disorder" which is allowed among fragments which share a @@ -1132,6 +1130,15 @@ flowlabel_consistency - BOOLEAN FALSE: disabled Default: TRUE +auto_flowlabels - BOOLEAN + Automatically generate flow labels based based on a flow hash + of the packet. This allows intermediate devices, such as routers, + to idenfify packet flows for mechanisms like Equal Cost Multipath + Routing (see RFC 6438). + TRUE: enabled + FALSE: disabled + Default: false + anycast_src_echo_reply - BOOLEAN Controls the use of anycast addresses as source addresses for ICMPv6 echo reply @@ -1153,11 +1160,6 @@ ip6frag_low_thresh - INTEGER ip6frag_time - INTEGER Time in seconds to keep an IPv6 fragment in memory. -ip6frag_secret_interval - INTEGER - Regeneration interval (in seconds) of the hash secret (or lifetime - for the hash secret) for IPv6 fragments. - Default: 600 - conf/default/*: Change the interface-specific default settings. @@ -1210,6 +1212,18 @@ accept_ra_defrtr - BOOLEAN Functional default: enabled if accept_ra is enabled. disabled if accept_ra is disabled. +accept_ra_from_local - BOOLEAN + Accept RA with source-address that is found on local machine + if the RA is otherwise proper and able to be accepted. + Default is to NOT accept these as it may be an un-intended + network loop. + + Functional default: + enabled if accept_ra_from_local is enabled + on a specific interface. + disabled if accept_ra_from_local is disabled + on a specific interface. + accept_ra_pinfo - BOOLEAN Learn Prefix Information in Router Advertisement. diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index 6fea79e..a6d7cb9 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -578,7 +578,7 @@ processes. This also works in combination with mmap(2) on packet sockets. Currently implemented fanout policies are: - - PACKET_FANOUT_HASH: schedule to socket by skb's rxhash + - PACKET_FANOUT_HASH: schedule to socket by skb's packet hash - PACKET_FANOUT_LB: schedule to socket by round-robin - PACKET_FANOUT_CPU: schedule to socket by CPU packet arrives on - PACKET_FANOUT_RND: schedule to socket by random selection @@ -1008,14 +1008,9 @@ hardware timestamps to be used. Note: you may need to enable the generation of hardware timestamps with SIOCSHWTSTAMP (see related information from Documentation/networking/timestamping.txt). -PACKET_TIMESTAMP accepts the same integer bit field as -SO_TIMESTAMPING. However, only the SOF_TIMESTAMPING_SYS_HARDWARE -and SOF_TIMESTAMPING_RAW_HARDWARE values are recognized by -PACKET_TIMESTAMP. SOF_TIMESTAMPING_SYS_HARDWARE takes precedence over -SOF_TIMESTAMPING_RAW_HARDWARE if both bits are set. +PACKET_TIMESTAMP accepts the same integer bit field as SO_TIMESTAMPING: - int req = 0; - req |= SOF_TIMESTAMPING_SYS_HARDWARE; + int req = SOF_TIMESTAMPING_RAW_HARDWARE; setsockopt(fd, SOL_PACKET, PACKET_TIMESTAMP, (void *) &req, sizeof(req)) For the mmap(2)ed ring buffers, such timestamps are stored in the @@ -1023,14 +1018,13 @@ tpacket{,2,3}_hdr structure's tp_sec and tp_{n,u}sec members. To determine what kind of timestamp has been reported, the tp_status field is binary |'ed with the following possible bits ... - TP_STATUS_TS_SYS_HARDWARE TP_STATUS_TS_RAW_HARDWARE TP_STATUS_TS_SOFTWARE ... that are equivalent to its SOF_TIMESTAMPING_* counterparts. For the -RX_RING, if none of those 3 are set (i.e. PACKET_TIMESTAMP is not set), -then this means that a software fallback was invoked *within* PF_PACKET's -processing code (less precise). +RX_RING, if neither is set (i.e. PACKET_TIMESTAMP is not set), then a +software fallback was invoked *within* PF_PACKET's processing code (less +precise). Getting timestamps for the TX_RING works as follows: i) fill the ring frames, ii) call sendto() e.g. in blocking mode, iii) wait for status of relevant diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt index ebf2707..e839e7e 100644 --- a/Documentation/networking/phy.txt +++ b/Documentation/networking/phy.txt @@ -48,7 +48,7 @@ The MDIO bus time, so it is safe for them to block, waiting for an interrupt to signal the operation is complete - 2) A reset function is necessary. This is used to return the bus to an + 2) A reset function is optional. This is used to return the bus to an initialized state. 3) A probe function is needed. This function should set up anything the bus @@ -253,16 +253,27 @@ Writing a PHY driver Each driver consists of a number of function pointers: + soft_reset: perform a PHY software reset config_init: configures PHY into a sane state after a reset. For instance, a Davicom PHY requires descrambling disabled. probe: Allocate phy->priv, optionally refuse to bind. PHY may not have been reset or had fixups run yet. suspend/resume: power management config_aneg: Changes the speed/duplex/negotiation settings + aneg_done: Determines the auto-negotiation result read_status: Reads the current speed/duplex/negotiation settings ack_interrupt: Clear a pending interrupt + did_interrupt: Checks if the PHY generated an interrupt config_intr: Enable or disable interrupts remove: Does any driver take-down + ts_info: Queries about the HW timestamping status + hwtstamp: Set the PHY HW timestamping configuration + rxtstamp: Requests a receive timestamp at the PHY level for a 'skb' + txtsamp: Requests a transmit timestamp at the PHY level for a 'skb' + set_wol: Enable Wake-on-LAN at the PHY level + get_wol: Get the Wake-on-LAN status at the PHY level + read_mmd_indirect: Read PHY MMD indirect register + write_mmd_indirect: Write PHY MMD indirect register Of these, only config_aneg and read_status are required to be assigned by the driver code. The rest are optional. Also, it is @@ -275,7 +286,21 @@ Writing a PHY driver Feel free to look at the Marvell, Cicada, and Davicom drivers in drivers/net/phy/ for examples (the lxt and qsemi drivers have - not been tested as of this writing) + not been tested as of this writing). + + The PHY's MMD register accesses are handled by the PAL framework + by default, but can be overridden by a specific PHY driver if + required. This could be the case if a PHY was released for + manufacturing before the MMD PHY register definitions were + standardized by the IEEE. Most modern PHYs will be able to use + the generic PAL framework for accessing the PHY's MMD registers. + An example of such usage is for Energy Efficient Ethernet support, + implemented in the PAL. This support uses the PAL to access MMD + registers for EEE query and configuration if the PHY supports + the IEEE standard access mechanisms, or can use the PHY's specific + access interfaces if overridden by the specific PHY driver. See + the Micrel driver in drivers/net/phy/ for an example of how this + can be implemented. Board Fixups diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt index 5a61a240..0dffc6e 100644 --- a/Documentation/networking/pktgen.txt +++ b/Documentation/networking/pktgen.txt @@ -24,6 +24,34 @@ For monitoring and control pktgen creates: /proc/net/pktgen/ethX +Tuning NIC for max performance +============================== + +The default NIC setting are (likely) not tuned for pktgen's artificial +overload type of benchmarking, as this could hurt the normal use-case. + +Specifically increasing the TX ring buffer in the NIC: + # ethtool -G ethX tx 1024 + +A larger TX ring can improve pktgen's performance, while it can hurt +in the general case, 1) because the TX ring buffer might get larger +than the CPUs L1/L2 cache, 2) because it allow more queueing in the +NIC HW layer (which is bad for bufferbloat). + +One should be careful to conclude, that packets/descriptors in the HW +TX ring cause delay. Drivers usually delay cleaning up the +ring-buffers (for various performance reasons), thus packets stalling +the TX ring, might just be waiting for cleanup. + +This cleanup issues is specifically the case, for the driver ixgbe +(Intel 82599 chip). This driver (ixgbe) combine TX+RX ring cleanups, +and the cleanup interval is affected by the ethtool --coalesce setting +of parameter "rx-usecs". + +For ixgbe use e.g "30" resulting in approx 33K interrupts/sec (1/30*10^6): + # ethtool -C ethX rx-usecs 30 + + Viewing threads =============== /proc/net/pktgen/kpktgend_0 @@ -102,13 +130,18 @@ Examples: The 'minimum' MAC is what you set with dstmac. pgset "flag [name]" Set a flag to determine behaviour. Current flags - are: IPSRC_RND #IP Source is random (between min/max), - IPDST_RND, UDPSRC_RND, - UDPDST_RND, MACSRC_RND, MACDST_RND + are: IPSRC_RND # IP source is random (between min/max) + IPDST_RND # IP destination is random + UDPSRC_RND, UDPDST_RND, + MACSRC_RND, MACDST_RND + TXSIZE_RND, IPV6, MPLS_RND, VID_RND, SVID_RND + FLOW_SEQ, QUEUE_MAP_RND # queue map random QUEUE_MAP_CPU # queue map mirrors smp_processor_id() - IPSEC # Make IPsec encapsulation for packet + UDPCSUM, + IPSEC # IPsec encapsulation (needs CONFIG_XFRM) + NODE_ALLOC # node specific memory allocation pgset spi SPI_VALUE Set specific SA used to transform packet. @@ -233,13 +266,22 @@ udp_dst_max flag IPSRC_RND - TXSIZE_RND IPDST_RND UDPSRC_RND UDPDST_RND MACSRC_RND MACDST_RND + TXSIZE_RND + IPV6 + MPLS_RND + VID_RND + SVID_RND + FLOW_SEQ + QUEUE_MAP_RND + QUEUE_MAP_CPU + UDPCSUM IPSEC + NODE_ALLOC dst_min dst_max diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt index b89bc82e..16a924c 100644 --- a/Documentation/networking/rxrpc.txt +++ b/Documentation/networking/rxrpc.txt @@ -27,6 +27,8 @@ Contents of this document: (*) AF_RXRPC kernel interface. + (*) Configurable parameters. + ======== OVERVIEW @@ -864,3 +866,82 @@ The kernel interface functions are as follows: This is used to allocate a null RxRPC key that can be used to indicate anonymous security for a particular domain. + + +======================= +CONFIGURABLE PARAMETERS +======================= + +The RxRPC protocol driver has a number of configurable parameters that can be +adjusted through sysctls in /proc/net/rxrpc/: + + (*) req_ack_delay + + The amount of time in milliseconds after receiving a packet with the + request-ack flag set before we honour the flag and actually send the + requested ack. + + Usually the other side won't stop sending packets until the advertised + reception window is full (to a maximum of 255 packets), so delaying the + ACK permits several packets to be ACK'd in one go. + + (*) soft_ack_delay + + The amount of time in milliseconds after receiving a new packet before we + generate a soft-ACK to tell the sender that it doesn't need to resend. + + (*) idle_ack_delay + + The amount of time in milliseconds after all the packets currently in the + received queue have been consumed before we generate a hard-ACK to tell + the sender it can free its buffers, assuming no other reason occurs that + we would send an ACK. + + (*) resend_timeout + + The amount of time in milliseconds after transmitting a packet before we + transmit it again, assuming no ACK is received from the receiver telling + us they got it. + + (*) max_call_lifetime + + The maximum amount of time in seconds that a call may be in progress + before we preemptively kill it. + + (*) dead_call_expiry + + The amount of time in seconds before we remove a dead call from the call + list. Dead calls are kept around for a little while for the purpose of + repeating ACK and ABORT packets. + + (*) connection_expiry + + The amount of time in seconds after a connection was last used before we + remove it from the connection list. Whilst a connection is in existence, + it serves as a placeholder for negotiated security; when it is deleted, + the security must be renegotiated. + + (*) transport_expiry + + The amount of time in seconds after a transport was last used before we + remove it from the transport list. Whilst a transport is in existence, it + serves to anchor the peer data and keeps the connection ID counter. + + (*) rxrpc_rx_window_size + + The size of the receive window in packets. This is the maximum number of + unconsumed received packets we're willing to hold in memory for any + particular call. + + (*) rxrpc_rx_mtu + + The maximum packet MTU size that we're willing to receive in bytes. This + indicates to the peer whether we're willing to accept jumbo packets. + + (*) rxrpc_rx_jumbo_max + + The maximum number of packets that we're willing to accept in a jumbo + packet. Non-terminal packets in a jumbo packet must contain a four byte + header plus exactly 1412 bytes of data. The terminal packet must contain + a four byte header plus any amount of data. In any event, a jumbo packet + may not exceed rxrpc_rx_mtu in size. diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt index ca6977f..99ca40e 100644 --- a/Documentation/networking/scaling.txt +++ b/Documentation/networking/scaling.txt @@ -429,7 +429,7 @@ RPS and RFS were introduced in kernel 2.6.35. XPS was incorporated into (therbert@google.com) Accelerated RFS was introduced in 2.6.35. Original patches were -submitted by Ben Hutchings (bhutchings@solarflare.com) +submitted by Ben Hutchings (bwh@kernel.org) Authors: Tom Herbert (therbert@google.com) diff --git a/Documentation/networking/tcp.txt b/Documentation/networking/tcp.txt index 7d11bb5..bdc4c0d 100644 --- a/Documentation/networking/tcp.txt +++ b/Documentation/networking/tcp.txt @@ -30,7 +30,7 @@ A congestion control mechanism can be registered through functions in tcp_cong.c. The functions used by the congestion control mechanism are registered via passing a tcp_congestion_ops struct to tcp_register_congestion_control. As a minimum name, ssthresh, -cong_avoid, min_cwnd must be valid. +cong_avoid must be valid. Private data for a congestion control mechanism is stored in tp->ca_priv. tcp_ca(tp) returns a pointer to this space. This is preallocated space - it diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt index 048c92b..897f942 100644 --- a/Documentation/networking/timestamping.txt +++ b/Documentation/networking/timestamping.txt @@ -40,7 +40,7 @@ the set bits correspond to data that is available, then the control message will not be generated: SOF_TIMESTAMPING_SOFTWARE: report systime if available -SOF_TIMESTAMPING_SYS_HARDWARE: report hwtimetrans if available +SOF_TIMESTAMPING_SYS_HARDWARE: report hwtimetrans if available (deprecated) SOF_TIMESTAMPING_RAW_HARDWARE: report hwtimeraw if available It is worth noting that timestamps may be collected for reasons other @@ -88,13 +88,12 @@ hwtimeraw is the original hardware time stamp. Filled in if SOF_TIMESTAMPING_RAW_HARDWARE is set. No assumptions about its relation to system time should be made. -hwtimetrans is the hardware time stamp transformed so that it -corresponds as good as possible to system time. This correlation is -not perfect; as a consequence, sorting packets received via different -NICs by their hwtimetrans may differ from the order in which they were -received. hwtimetrans may be non-monotonic even for the same NIC. -Filled in if SOF_TIMESTAMPING_SYS_HARDWARE is set. Requires support -by the network device and will be empty without that support. +hwtimetrans is always zero. This field is deprecated. It used to hold +hw timestamps converted to system time. Instead, expose the hardware +clock device on the NIC directly as a HW PTP clock source, to allow +time conversion in userspace and optionally synchronize system time +with a userspace PTP stack such as linuxptp. For the PTP clock API, +see Documentation/ptp/ptp.txt. SIOCSHWTSTAMP, SIOCGHWTSTAMP: @@ -185,7 +184,6 @@ struct skb_shared_hwtstamps { * since arbitrary point in time */ ktime_t hwtstamp; - ktime_t syststamp; /* hwtstamp transformed to system time base */ }; Time stamps for outgoing packets are to be generated as follows: @@ -202,6 +200,9 @@ Time stamps for outgoing packets are to be generated as follows: and not free the skb. A driver not supporting hardware time stamping doesn't do that. A driver must never touch sk_buff::tstamp! It is used to store software generated time stamps by the network subsystem. +- Driver should call skb_tx_timestamp() as close to passing sk_buff to hardware + as possible. skb_tx_timestamp() provides a software time stamp if requested + and hardware timestamping is not possible (SKBTX_IN_PROGRESS not set). - As soon as the driver has sent the packet and/or obtained a hardware time stamp for it, it passes the time stamp back by calling skb_hwtstamp_tx() with the original skb, the raw @@ -212,6 +213,3 @@ Time stamps for outgoing packets are to be generated as follows: this would occur at a later time in the processing pipeline than other software time stamping and therefore could lead to unexpected deltas between time stamps. -- If the driver did not set the SKBTX_IN_PROGRESS flag (see above), then - dev_hard_start_xmit() checks whether software time stamping - is wanted as fallback and potentially generates the time stamp. diff --git a/Documentation/networking/timestamping/timestamping.c b/Documentation/networking/timestamping/timestamping.c index 8ba82bf..5cdfd74 100644 --- a/Documentation/networking/timestamping/timestamping.c +++ b/Documentation/networking/timestamping/timestamping.c @@ -76,7 +76,6 @@ static void usage(const char *error) " SOF_TIMESTAMPING_RX_HARDWARE - hardware time stamping of incoming packets\n" " SOF_TIMESTAMPING_RX_SOFTWARE - software fallback for incoming packets\n" " SOF_TIMESTAMPING_SOFTWARE - request reporting of software time stamps\n" - " SOF_TIMESTAMPING_SYS_HARDWARE - request reporting of transformed HW time stamps\n" " SOF_TIMESTAMPING_RAW_HARDWARE - request reporting of raw HW time stamps\n" " SIOCGSTAMP - check last socket time stamp\n" " SIOCGSTAMPNS - more accurate socket time stamp\n"); @@ -202,9 +201,7 @@ static void printpacket(struct msghdr *msg, int res, (long)stamp->tv_sec, (long)stamp->tv_nsec); stamp++; - printf("HW transformed %ld.%09ld ", - (long)stamp->tv_sec, - (long)stamp->tv_nsec); + /* skip deprecated HW transformed */ stamp++; printf("HW raw %ld.%09ld", (long)stamp->tv_sec, @@ -361,8 +358,6 @@ int main(int argc, char **argv) so_timestamping_flags |= SOF_TIMESTAMPING_RX_SOFTWARE; else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_SOFTWARE")) so_timestamping_flags |= SOF_TIMESTAMPING_SOFTWARE; - else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_SYS_HARDWARE")) - so_timestamping_flags |= SOF_TIMESTAMPING_SYS_HARDWARE; else if (!strcasecmp(argv[i], "SOF_TIMESTAMPING_RAW_HARDWARE")) so_timestamping_flags |= SOF_TIMESTAMPING_RAW_HARDWARE; else diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt index 13032c0..e315599 100644 --- a/Documentation/oops-tracing.txt +++ b/Documentation/oops-tracing.txt @@ -265,6 +265,9 @@ characters, each representing a particular tainted value. 13: 'O' if an externally-built ("out-of-tree") module has been loaded. + 14: 'E' if an unsigned module has been loaded in a kernel supporting + module signature. + The primary reason for the 'Tainted: ' string is to tell kernel debuggers if this is a clean kernel or if anything unusual has occurred. Tainting is permanent: even if an offending module is diff --git a/Documentation/phy.txt b/Documentation/phy.txt index ebff6ee..c6594af 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/platform/x86-laptop-drivers.txt b/Documentation/platform/x86-laptop-drivers.txt new file mode 100644 index 0000000..01facd2 --- /dev/null +++ b/Documentation/platform/x86-laptop-drivers.txt @@ -0,0 +1,18 @@ +compal-laptop +============= +List of supported hardware: + +by Compal: + Compal FL90/IFL90 + Compal FL91/IFL91 + Compal FL92/JFL92 + Compal FT00/IFT00 + +by Dell: + Dell Vostro 1200 + Dell Mini 9 (Inspiron 910) + Dell Mini 10 (Inspiron 1010) + Dell Mini 10v (Inspiron 1011) + Dell Mini 1012 (Inspiron 1012) + Dell Inspiron 11z (Inspiron 1110) + Dell Mini 12 (Inspiron 1210) diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 47d46df..d172bce 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -2,6 +2,7 @@ Device Power Management Copyright (c) 2010-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc. Copyright (c) 2010 Alan Stern <stern@rowland.harvard.edu> +Copyright (c) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com> Most of the code in Linux is device drivers, so most of the Linux power @@ -326,6 +327,20 @@ the phases are: driver in some way for the upcoming system power transition, but it should not put the device into a low-power state. + For devices supporting runtime power management, the return value of the + prepare callback can be used to indicate to the PM core that it may + safely leave the device in runtime suspend (if runtime-suspended + already), provided that all of the device's descendants are also left in + runtime suspend. Namely, if the prepare callback returns a positive + number and that happens for all of the descendants of the device too, + and all of them (including the device itself) are runtime-suspended, the + PM core will skip the suspend, suspend_late and suspend_noirq suspend + phases as well as the resume_noirq, resume_early and resume phases of + the following system resume for all of these devices. In that case, + the complete callback will be called directly after the prepare callback + and is entirely responsible for bringing the device back to the + functional state as appropriate. + 2. The suspend methods should quiesce the device to stop it from performing I/O. They also may save the device registers and put it into the appropriate low-power state, depending on the bus type the device is on, @@ -400,12 +415,23 @@ When resuming from freeze, standby or memory sleep, the phases are: the resume callbacks occur; it's not necessary to wait until the complete phase. + Moreover, if the preceding prepare callback returned a positive number, + the device may have been left in runtime suspend throughout the whole + system suspend and resume (the suspend, suspend_late, suspend_noirq + phases of system suspend and the resume_noirq, resume_early, resume + phases of system resume may have been skipped for it). In that case, + the complete callback is entirely responsible for bringing the device + back to the functional state after system suspend if necessary. [For + example, it may need to queue up a runtime resume request for the device + for this purpose.] To check if that is the case, the complete callback + can consult the device's power.direct_complete flag. Namely, if that + flag is set when the complete callback is being run, it has been called + directly after the preceding prepare and special action may be required + to make the device work correctly afterward. + At the end of these phases, drivers should be as functional as they were before suspending: I/O can be performed using DMA and IRQs, and the relevant clocks are -gated on. Even if the device was in a low-power state before the system sleep -because of runtime power management, afterwards it should be back in its -full-power state. There are multiple reasons why it's best to do this; they are -discussed in more detail in Documentation/power/runtime_pm.txt. +gated on. However, the details here may again be platform-specific. For example, some systems support multiple "run" states, and the mode in effect at diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt index b8a907d..c6279c2 100644 --- a/Documentation/power/opp.txt +++ b/Documentation/power/opp.txt @@ -10,8 +10,7 @@ Contents 3. OPP Search Functions 4. OPP Availability Control Functions 5. OPP Data Retrieval Functions -6. Cpufreq Table Generation -7. Data Structures +6. Data Structures 1. Introduction =============== @@ -52,9 +51,6 @@ Typical usage of the OPP library is as follows: SoC framework -> modifies on required cases certain OPPs -> OPP layer -> queries to search/retrieve information -> -Architectures that provide a SoC framework for OPP should select ARCH_HAS_OPP -to make the OPP layer available. - OPP layer expects each domain to be represented by a unique device pointer. SoC framework registers a set of initial OPPs per device with the OPP layer. This list is expected to be an optimally small number typically around 5 per device. @@ -72,7 +68,6 @@ operations until that OPP could be re-enabled if possible. OPP library facilitates this concept in it's implementation. The following operational functions operate only on available opps: opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq, dev_pm_opp_get_opp_count -and dev_pm_opp_init_cpufreq_table dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer which can then be used for dev_pm_opp_enable/disable functions to make an opp available as required. @@ -96,10 +91,9 @@ using RCU read locks. The opp_find_freq_{exact,ceil,floor}, opp_get_{voltage, freq, opp_count} fall into this category. opp_{add,enable,disable} are updaters which use mutex and implement it's own -RCU locking mechanisms. dev_pm_opp_init_cpufreq_table acts as an updater and uses -mutex to implment RCU updater strategy. These functions should *NOT* be called -under RCU locks and other contexts that prevent blocking functions in RCU or -mutex operations from working. +RCU locking mechanisms. These functions should *NOT* be called under RCU locks +and other contexts that prevent blocking functions in RCU or mutex operations +from working. 2. Initial OPP List Registration ================================ @@ -311,34 +305,7 @@ dev_pm_opp_get_opp_count - Retrieve the number of available opps for a device /* Do other things */ } -6. Cpufreq Table Generation -=========================== -dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with - cpufreq_frequency_table_cpuinfo which is provided with the list of - frequencies that are available for operation. This function provides - a ready to use conversion routine to translate the OPP layer's internal - information about the available frequencies into a format readily - providable to cpufreq. - - WARNING: Do not use this function in interrupt context. - - Example: - soc_pm_init() - { - /* Do things */ - r = dev_pm_opp_init_cpufreq_table(dev, &freq_table); - if (!r) - cpufreq_frequency_table_cpuinfo(policy, freq_table); - /* Do other things */ - } - - NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in - addition to CONFIG_PM as power management feature is required to - dynamically scale voltage and frequency in a system. - -dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table - -7. Data Structures +6. Data Structures ================== Typically an SoC contains multiple voltage domains which are variable. Each domain is represented by a device pointer. The relationship to OPP can be diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt index 89a8816..48cff88 100644 --- a/Documentation/power/power_supply_class.txt +++ b/Documentation/power/power_supply_class.txt @@ -118,6 +118,10 @@ relative, time-based measurements. CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger. CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the power supply object. +INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates +the current drawn from a charging source. +CHARGE_TERM_CURRENT - Charge termination current used to detect the end of charge +condition. CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger. CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the @@ -140,6 +144,8 @@ TEMP_ALERT_MAX - maximum battery temperature alert. TEMP_AMBIENT - ambient temperature. TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert. TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert. +TEMP_MIN - minimum operatable temperature +TEMP_MAX - maximum operatable temperature TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e. while battery powers a load) diff --git a/Documentation/power/regulator/consumer.txt b/Documentation/power/regulator/consumer.txt index 55c4175..81c0e2b 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/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 5f96daf..f32ce54 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -2,6 +2,7 @@ Runtime Power Management Framework for I/O Devices (C) 2009-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc. (C) 2010 Alan Stern <stern@rowland.harvard.edu> +(C) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com> 1. Introduction @@ -444,6 +445,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: bool pm_runtime_status_suspended(struct device *dev); - return true if the device's runtime PM status is 'suspended' + bool pm_runtime_suspended_if_enabled(struct device *dev); + - return true if the device's runtime PM status is 'suspended' and its + 'power.disable_depth' field is equal to 1 + void pm_runtime_allow(struct device *dev); - set the power.runtime_auto flag for the device and decrease its usage counter (used by the /sys/devices/.../power/control interface to @@ -644,19 +649,33 @@ place (in particular, if the system is not waking up from hibernation), it may be more efficient to leave the devices that had been suspended before the system suspend began in the suspended state. +To this end, the PM core provides a mechanism allowing some coordination between +different levels of device hierarchy. Namely, if a system suspend .prepare() +callback returns a positive number for a device, that indicates to the PM core +that the device appears to be runtime-suspended and its state is fine, so it +may be left in runtime suspend provided that all of its descendants are also +left in runtime suspend. If that happens, the PM core will not execute any +system suspend and resume callbacks for all of those devices, except for the +complete callback, which is then entirely responsible for handling the device +as appropriate. This only applies to system suspend transitions that are not +related to hibernation (see Documentation/power/devices.txt for more +information). + The PM core does its best to reduce the probability of race conditions between the runtime PM and system suspend/resume (and hibernation) callbacks by carrying out the following operations: - * During system suspend it calls pm_runtime_get_noresume() and - pm_runtime_barrier() for every device right before executing the - subsystem-level .suspend() callback for it. In addition to that it calls - __pm_runtime_disable() with 'false' as the second argument for every device - right before executing the subsystem-level .suspend_late() callback for it. - - * During system resume it calls pm_runtime_enable() and pm_runtime_put() - for every device right after executing the subsystem-level .resume_early() - callback and right after executing the subsystem-level .resume() callback + * During system suspend pm_runtime_get_noresume() is called for every device + right before executing the subsystem-level .prepare() callback for it and + pm_runtime_barrier() is called for every device right before executing the + subsystem-level .suspend() callback for it. In addition to that the PM core + calls __pm_runtime_disable() with 'false' as the second argument for every + device right before executing the subsystem-level .suspend_late() callback + for it. + + * During system resume pm_runtime_enable() and pm_runtime_put() are called for + every device right after executing the subsystem-level .resume_early() + callback and right after executing the subsystem-level .complete() callback for it, respectively. 7. Generic subsystem callbacks diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt index 442d43d..50f3ef9 100644 --- a/Documentation/power/states.txt +++ b/Documentation/power/states.txt @@ -1,62 +1,87 @@ +System Power Management Sleep States -System Power Management States +(C) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com> +The kernel supports up to four system sleep states generically, although three +of them depend on the platform support code to implement the low-level details +for each state. -The kernel supports four power management states generically, though -one is generic and the other three are dependent on platform support -code to implement the low-level details for each state. -This file describes each state, what they are -commonly called, what ACPI state they map to, and what string to write -to /sys/power/state to enter that state +The states are represented by strings that can be read or written to the +/sys/power/state file. Those strings may be "mem", "standby", "freeze" and +"disk", where the last one always represents hibernation (Suspend-To-Disk) and +the meaning of the remaining ones depends on the relative_sleep_states command +line argument. -state: Freeze / Low-Power Idle +For relative_sleep_states=1, the strings "mem", "standby" and "freeze" label the +available non-hibernation sleep states from the deepest to the shallowest, +respectively. In that case, "mem" is always present in /sys/power/state, +because there is at least one non-hibernation sleep state in every system. If +the given system supports two non-hibernation sleep states, "standby" is present +in /sys/power/state in addition to "mem". If the system supports three +non-hibernation sleep states, "freeze" will be present in /sys/power/state in +addition to "mem" and "standby". + +For relative_sleep_states=0, which is the default, the following descriptions +apply. + +state: Suspend-To-Idle ACPI state: S0 -String: "freeze" +Label: "freeze" -This state is a generic, pure software, light-weight, low-power state. -It allows more energy to be saved relative to idle by freezing user +This state is a generic, pure software, light-weight, system sleep state. +It allows more energy to be saved relative to runtime idle by freezing user space and putting all I/O devices into low-power states (possibly lower-power than available at run time), such that the processors can spend more time in their idle states. -This state can be used for platforms without Standby/Suspend-to-RAM + +This state can be used for platforms without Power-On Suspend/Suspend-to-RAM support, or it can be used in addition to Suspend-to-RAM (memory sleep) -to provide reduced resume latency. +to provide reduced resume latency. It is always supported. State: Standby / Power-On Suspend ACPI State: S1 -String: "standby" +Label: "standby" -This state offers minimal, though real, power savings, while providing -a very low-latency transition back to a working system. No operating -state is lost (the CPU retains power), so the system easily starts up +This state, if supported, offers moderate, though real, power savings, while +providing a relatively low-latency transition back to a working system. No +operating state is lost (the CPU retains power), so the system easily starts up again where it left off. -We try to put devices in a low-power state equivalent to D1, which -also offers low power savings, but low resume latency. Not all devices -support D1, and those that don't are left on. +In addition to freezing user space and putting all I/O devices into low-power +states, which is done for Suspend-To-Idle too, nonboot CPUs are taken offline +and all low-level system functions are suspended during transitions into this +state. For this reason, it should allow more energy to be saved relative to +Suspend-To-Idle, but the resume latency will generally be greater than for that +state. State: Suspend-to-RAM ACPI State: S3 -String: "mem" +Label: "mem" -This state offers significant power savings as everything in the -system is put into a low-power state, except for memory, which is -placed in self-refresh mode to retain its contents. +This state, if supported, offers significant power savings as everything in the +system is put into a low-power state, except for memory, which should be placed +into the self-refresh mode to retain its contents. All of the steps carried out +when entering Power-On Suspend are also carried out during transitions to STR. +Additional operations may take place depending on the platform capabilities. In +particular, on ACPI systems the kernel passes control to the BIOS (platform +firmware) as the last step during STR transitions and that usually results in +powering down some more low-level components that aren't directly controlled by +the kernel. -System and device state is saved and kept in memory. All devices are -suspended and put into D3. In many cases, all peripheral buses lose -power when entering STR, so devices must be able to handle the -transition back to the On state. +System and device state is saved and kept in memory. All devices are suspended +and put into low-power states. In many cases, all peripheral buses lose power +when entering STR, so devices must be able to handle the transition back to the +"on" state. -For at least ACPI, STR requires some minimal boot-strapping code to -resume the system from STR. This may be true on other platforms. +For at least ACPI, STR requires some minimal boot-strapping code to resume the +system from it. This may be the case on other platforms too. State: Suspend-to-disk ACPI State: S4 -String: "disk" +Label: "disk" This state offers the greatest power savings, and can be used even in the absence of low-level platform support for power management. This diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.txt index e13dafc..2850df3 100644 --- a/Documentation/power/suspend-and-cpuhotplug.txt +++ b/Documentation/power/suspend-and-cpuhotplug.txt @@ -1,6 +1,6 @@ Interaction of Suspend code (S3) with the CPU hotplug infrastructure - (C) 2011 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> + (C) 2011 - 2014 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> I. How does the regular CPU hotplug code differ from how the Suspend-to-RAM diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index 079160e..f732a83 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt @@ -220,7 +220,10 @@ Q: After resuming, system is paging heavily, leading to very bad interactivity. A: Try running -cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null +cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u | while read file +do + test -f "$file" && cat "$file" > /dev/null +done after resume. swapoff -a; swapon -a may also be useful. diff --git a/Documentation/powerpc/cpu_families.txt b/Documentation/powerpc/cpu_families.txt new file mode 100644 index 0000000..fc08e22 --- /dev/null +++ b/Documentation/powerpc/cpu_families.txt @@ -0,0 +1,221 @@ +CPU Families +============ + +This document tries to summarise some of the different cpu families that exist +and are supported by arch/powerpc. + + +Book3S (aka sPAPR) +------------------ + + - Hash MMU + - Mix of 32 & 64 bit + + +--------------+ +----------------+ + | Old POWER | --------------> | RS64 (threads) | + +--------------+ +----------------+ + | + | + v + +--------------+ +----------------+ +------+ + | 601 | --------------> | 603 | ---> | e300 | + +--------------+ +----------------+ +------+ + | | + | | + v v + +--------------+ +----------------+ +-------+ + | 604 | | 750 (G3) | ---> | 750CX | + +--------------+ +----------------+ +-------+ + | | | + | | | + v v v + +--------------+ +----------------+ +-------+ + | 620 (64 bit) | | 7400 | | 750CL | + +--------------+ +----------------+ +-------+ + | | | + | | | + v v v + +--------------+ +----------------+ +-------+ + | POWER3/630 | | 7410 | | 750FX | + +--------------+ +----------------+ +-------+ + | | + | | + v v + +--------------+ +----------------+ + | POWER3+ | | 7450 | + +--------------+ +----------------+ + | | + | | + v v + +--------------+ +----------------+ + | POWER4 | | 7455 | + +--------------+ +----------------+ + | | + | | + v v + +--------------+ +-------+ +----------------+ + | POWER4+ | --> | 970 | | 7447 | + +--------------+ +-------+ +----------------+ + | | | + | | | + v v v + +--------------+ +-------+ +----------------+ + | POWER5 | | 970FX | | 7448 | + +--------------+ +-------+ +----------------+ + | | | + | | | + v v v + +--------------+ +-------+ +----------------+ + | POWER5+ | | 970MP | | e600 | + +--------------+ +-------+ +----------------+ + | + | + v + +--------------+ + | POWER5++ | + +--------------+ + | + | + v + +--------------+ +-------+ + | POWER6 | <-?-> | Cell | + +--------------+ +-------+ + | + | + v + +--------------+ + | POWER7 | + +--------------+ + | + | + v + +--------------+ + | POWER7+ | + +--------------+ + | + | + v + +--------------+ + | POWER8 | + +--------------+ + + + +---------------+ + | PA6T (64 bit) | + +---------------+ + + +IBM BookE +--------- + + - Software loaded TLB. + - All 32 bit + + +--------------+ + | 401 | + +--------------+ + | + | + v + +--------------+ + | 403 | + +--------------+ + | + | + v + +--------------+ + | 405 | + +--------------+ + | + | + v + +--------------+ + | 440 | + +--------------+ + | + | + v + +--------------+ +----------------+ + | 450 | --> | BG/P | + +--------------+ +----------------+ + | + | + v + +--------------+ + | 460 | + +--------------+ + | + | + v + +--------------+ + | 476 | + +--------------+ + + +Motorola/Freescale 8xx +---------------------- + + - Software loaded with hardware assist. + - All 32 bit + + +-------------+ + | MPC8xx Core | + +-------------+ + + +Freescale BookE +--------------- + + - Software loaded TLB. + - e6500 adds HW loaded indirect TLB entries. + - Mix of 32 & 64 bit + + +--------------+ + | e200 | + +--------------+ + + + +--------------------------------+ + | e500 | + +--------------------------------+ + | + | + v + +--------------------------------+ + | e500v2 | + +--------------------------------+ + | + | + v + +--------------------------------+ + | e500mc (Book3e) | + +--------------------------------+ + | + | + v + +--------------------------------+ + | e5500 (64 bit) | + +--------------------------------+ + | + | + v + +--------------------------------+ + | e6500 (HW TLB) (Multithreaded) | + +--------------------------------+ + + +IBM A2 core +----------- + + - Book3E, software loaded TLB + HW loaded indirect TLB entries. + - 64 bit + + +--------------+ +----------------+ + | A2 core | --> | WSP | + +--------------+ +----------------+ + | + | + v + +--------------+ + | BG/Q | + +--------------+ diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c index 4aba043..ba1d502 100644 --- a/Documentation/ptp/testptp.c +++ b/Documentation/ptp/testptp.c @@ -17,8 +17,10 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ +#define _GNU_SOURCE #include <errno.h> #include <fcntl.h> +#include <inttypes.h> #include <math.h> #include <signal.h> #include <stdio.h> @@ -45,12 +47,14 @@ #define CLOCK_INVALID -1 #endif -/* When glibc offers the syscall, this will go away. */ +/* clock_adjtime is not available in GLIBC < 2.14 */ +#if !__GLIBC_PREREQ(2, 14) #include <sys/syscall.h> static int clock_adjtime(clockid_t id, struct timex *tx) { return syscall(__NR_clock_adjtime, id, tx); } +#endif static clockid_t get_clockid(int fd) { @@ -120,11 +124,19 @@ static void usage(char *progname) " -i val index for event/trigger\n" " -k val measure the time offset between system and phc clock\n" " for 'val' times (Maximum 25)\n" + " -l list the current pin configuration\n" + " -L pin,val configure pin index 'pin' with function 'val'\n" + " the channel index is taken from the '-i' option\n" + " 'val' specifies the auxiliary function:\n" + " 0 - none\n" + " 1 - external time stamp\n" + " 2 - periodic output\n" " -p val enable output with a period of 'val' nanoseconds\n" " -P val enable or disable (val=1|0) the system clock PPS\n" " -s set the ptp clock time from the system time\n" " -S set the system time from the ptp clock time\n" - " -t val shift the ptp clock time by 'val' seconds\n", + " -t val shift the ptp clock time by 'val' seconds\n" + " -T val set the ptp clock time to 'val' seconds\n", progname); } @@ -134,6 +146,7 @@ int main(int argc, char *argv[]) struct ptp_extts_event event; struct ptp_extts_request extts_request; struct ptp_perout_request perout_request; + struct ptp_pin_desc desc; struct timespec ts; struct timex tx; @@ -156,12 +169,15 @@ int main(int argc, char *argv[]) int extts = 0; int gettime = 0; int index = 0; + int list_pins = 0; int oneshot = 0; int pct_offset = 0; int n_samples = 0; int periodic = 0; int perout = -1; + int pin_index = -1, pin_func; int pps = -1; + int seconds = 0; int settime = 0; int64_t t1, t2, tp; @@ -169,7 +185,7 @@ int main(int argc, char *argv[]) progname = strrchr(argv[0], '/'); progname = progname ? 1+progname : argv[0]; - while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghi:k:p:P:sSt:v"))) { + while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghi:k:lL:p:P:sSt:T:v"))) { switch (c) { case 'a': oneshot = atoi(optarg); @@ -199,6 +215,16 @@ int main(int argc, char *argv[]) pct_offset = 1; n_samples = atoi(optarg); break; + case 'l': + list_pins = 1; + break; + case 'L': + cnt = sscanf(optarg, "%d,%d", &pin_index, &pin_func); + if (cnt != 2) { + usage(progname); + return -1; + } + break; case 'p': perout = atoi(optarg); break; @@ -214,6 +240,10 @@ int main(int argc, char *argv[]) case 't': adjtime = atoi(optarg); break; + case 'T': + settime = 3; + seconds = atoi(optarg); + break; case 'h': usage(progname); return 0; @@ -245,12 +275,14 @@ int main(int argc, char *argv[]) " %d programmable alarms\n" " %d external time stamp channels\n" " %d programmable periodic signals\n" - " %d pulse per second\n", + " %d pulse per second\n" + " %d programmable pins\n", caps.max_adj, caps.n_alarm, caps.n_ext_ts, caps.n_per_out, - caps.pps); + caps.pps, + caps.n_pins); } } @@ -304,6 +336,16 @@ int main(int argc, char *argv[]) } } + if (settime == 3) { + ts.tv_sec = seconds; + ts.tv_nsec = 0; + if (clock_settime(clkid, &ts)) { + perror("clock_settime"); + } else { + puts("set time okay"); + } + } + if (extts) { memset(&extts_request, 0, sizeof(extts_request)); extts_request.index = index; @@ -331,6 +373,24 @@ int main(int argc, char *argv[]) } } + if (list_pins) { + int n_pins = 0; + if (ioctl(fd, PTP_CLOCK_GETCAPS, &caps)) { + perror("PTP_CLOCK_GETCAPS"); + } else { + n_pins = caps.n_pins; + } + for (i = 0; i < n_pins; i++) { + desc.index = i; + if (ioctl(fd, PTP_PIN_GETFUNC, &desc)) { + perror("PTP_PIN_GETFUNC"); + break; + } + printf("name %s index %u func %u chan %u\n", + desc.name, desc.index, desc.func, desc.chan); + } + } + if (oneshot) { install_handler(SIGALRM, handle_alarm); /* Create a timer. */ @@ -392,6 +452,18 @@ int main(int argc, char *argv[]) } } + if (pin_index >= 0) { + memset(&desc, 0, sizeof(desc)); + desc.index = pin_index; + desc.func = pin_func; + desc.chan = index; + if (ioctl(fd, PTP_PIN_SETFUNC, &desc)) { + perror("PTP_PIN_SETFUNC"); + } else { + puts("set pin function okay"); + } + } + if (pps != -1) { int enable = pps ? 1 : 0; if (ioctl(fd, PTP_ENABLE_PPS, enable)) { @@ -428,14 +500,14 @@ int main(int argc, char *argv[]) interval = t2 - t1; offset = (t2 + t1) / 2 - tp; - printf("system time: %ld.%ld\n", + printf("system time: %" PRId64 ".%u\n", (pct+2*i)->sec, (pct+2*i)->nsec); - printf("phc time: %ld.%ld\n", + printf("phc time: %" PRId64 ".%u\n", (pct+2*i+1)->sec, (pct+2*i+1)->nsec); - printf("system time: %ld.%ld\n", + printf("system time: %" PRId64 ".%u\n", (pct+2*i+2)->sec, (pct+2*i+2)->nsec); - printf("system/phc clock time offset is %ld ns\n" - "system clock time delay is %ld ns\n", + printf("system/phc clock time offset is %" PRId64 " ns\n" + "system clock time delay is %" PRId64 " ns\n", offset, interval); } diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt index 93cb979..ca895fd 100644 --- a/Documentation/pwm.txt +++ b/Documentation/pwm.txt @@ -19,7 +19,8 @@ should instead register a static mapping that can be used to match PWM consumers to providers, as given in the following example: static struct pwm_lookup board_pwm_lookup[] = { - PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL), + PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL, + 50000, PWM_POLARITY_NORMAL), }; static void __init board_init(void) @@ -97,6 +98,13 @@ pwm_chip as argument which provides a description of the PWM chip, the number of PWM devices provided by the chip and the chip-specific implementation of the supported PWM operations to the framework. +When implementing polarity support in a PWM driver, make sure to respect the +signal conventions in the PWM framework. By definition, normal polarity +characterizes a signal starts high for the duration of the duty cycle and +goes low for the remainder of the period. Conversely, a signal with inversed +polarity starts low for the duration of the duty cycle and goes high for the +remainder of the period. + Locking ------- diff --git a/Documentation/rapidio/sysfs.txt b/Documentation/rapidio/sysfs.txt index 271438c..47ce9a5 100644 --- a/Documentation/rapidio/sysfs.txt +++ b/Documentation/rapidio/sysfs.txt @@ -2,8 +2,8 @@ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -1. Device Subdirectories ------------------------- +1. RapidIO Device Subdirectories +-------------------------------- For each RapidIO device, the RapidIO subsystem creates files in an individual subdirectory with the following name, /sys/bus/rapidio/devices/<device_name>. @@ -25,8 +25,8 @@ seen by the enumerating host (destID = 1): NOTE: An enumerating or discovering endpoint does not create a sysfs entry for itself, this is why an endpoint with destID=1 is not shown in the list. -2. Attributes Common for All Devices ------------------------------------- +2. Attributes Common for All RapidIO Devices +-------------------------------------------- Each device subdirectory contains the following informational read-only files: @@ -52,16 +52,16 @@ This attribute is similar in behavior to the "config" attribute of PCI devices and provides an access to the RapidIO device registers using standard file read and write operations. -3. Endpoint Device Attributes ------------------------------ +3. RapidIO Endpoint Device Attributes +------------------------------------- Currently Linux RapidIO subsystem does not create any endpoint specific sysfs attributes. It is possible that RapidIO master port drivers and endpoint device drivers will add their device-specific sysfs attributes but such attributes are outside the scope of this document. -4. Switch Device Attributes ---------------------------- +4. RapidIO Switch Device Attributes +----------------------------------- RapidIO switches have additional attributes in sysfs. RapidIO subsystem supports common and device-specific sysfs attributes for switches. Because switches are @@ -106,3 +106,53 @@ attribute: for that controller always will be 0. To initiate RapidIO enumeration/discovery on all available mports a user must write '-1' (or RIO_MPORT_ANY) into this attribute file. + + +6. RapidIO Bus Controllers/Ports +-------------------------------- + +On-chip RapidIO controllers and PCIe-to-RapidIO bridges (referenced as +"Master Port" or "mport") are presented in sysfs as the special class of +devices: "rapidio_port". + +The /sys/class/rapidio_port subdirectory contains individual subdirectories +named as "rapidioN" where N = mport ID registered with RapidIO subsystem. + +NOTE: An mport ID is not a RapidIO destination ID assigned to a given local +mport device. + +Each mport device subdirectory in addition to standard entries contains the +following device-specific attributes: + + port_destid - reports RapidIO destination ID assigned to the given RapidIO + mport device. If value 0xFFFFFFFF is returned this means that + no valid destination ID have been assigned to the mport (yet). + Normally, before enumeration/discovery have been executed only + fabric enumerating mports have a valid destination ID assigned + to them using "hdid=..." rapidio module parameter. + sys_size - reports RapidIO common transport system size: + 0 = small (8-bit destination ID, max. 256 devices), + 1 = large (16-bit destination ID, max. 65536 devices). + +After enumeration or discovery was performed for a given mport device, +the corresponding subdirectory will also contain subdirectories for each +child RapidIO device connected to the mport. Naming conventions for RapidIO +devices are described in Section 1 above. + +The example below shows mport device subdirectory with several child RapidIO +devices attached to it. + +[rio@rapidio ~]$ ls /sys/class/rapidio_port/rapidio0/ -l +total 0 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0001 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0004 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0007 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0002 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0003 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0005 +lrwxrwxrwx 1 root root 0 Feb 11 15:11 device -> ../../../0000:01:00.0 +-r--r--r-- 1 root root 4096 Feb 11 15:11 port_destid +drwxr-xr-x 2 root root 0 Feb 11 15:11 power +lrwxrwxrwx 1 root root 0 Feb 11 15:04 subsystem -> ../../../../../../class/rapidio_port +-r--r--r-- 1 root root 4096 Feb 11 15:11 sys_size +-rw-r--r-- 1 root root 4096 Feb 11 15:04 uevent diff --git a/Documentation/s390/zfcpdump.txt b/Documentation/s390/zfcpdump.txt index cf45d27..dc929be 100644 --- a/Documentation/s390/zfcpdump.txt +++ b/Documentation/s390/zfcpdump.txt @@ -1,15 +1,15 @@ -s390 SCSI dump tool (zfcpdump) +The s390 SCSI dump tool (zfcpdump) System z machines (z900 or higher) provide hardware support for creating system dumps on SCSI disks. The dump process is initiated by booting a dump tool, which has to create a dump of the current (probably crashed) Linux image. In order to not overwrite memory of the crashed Linux with data of the dump tool, the -hardware saves some memory plus the register sets of the boot cpu before the +hardware saves some memory plus the register sets of the boot CPU before the dump tool is loaded. There exists an SCLP hardware interface to obtain the saved memory afterwards. Currently 32 MB are saved. This zfcpdump implementation consists of a Linux dump kernel together with -a userspace dump tool, which are loaded together into the saved memory region +a user space dump tool, which are loaded together into the saved memory region below 32 MB. zfcpdump is installed on a SCSI disk using zipl (as contained in the s390-tools package) to make the device bootable. The operator of a Linux system can then trigger a SCSI dump by booting the SCSI disk, where zfcpdump @@ -19,68 +19,33 @@ The kernel part of zfcpdump is implemented as a debugfs file under "zcore/mem", which exports memory and registers of the crashed Linux in an s390 standalone dump format. It can be used in the same way as e.g. /dev/mem. The dump format defines a 4K header followed by plain uncompressed memory. The -register sets are stored in the prefix pages of the respective cpus. To build a +register sets are stored in the prefix pages of the respective CPUs. To build a dump enabled kernel with the zcore driver, the kernel config option -CONFIG_ZFCPDUMP has to be set. When reading from "zcore/mem", the part of +CONFIG_CRASH_DUMP has to be set. When reading from "zcore/mem", the part of memory, which has been saved by hardware is read by the driver via the SCLP hardware interface. The second part is just copied from the non overwritten real memory. -The userspace application of zfcpdump can reside e.g. in an intitramfs or an -initrd. It reads from zcore/mem and writes the system dump to a file on a -SCSI disk. +Since kernel version 3.12 also the /proc/vmcore file can also be used to access +the dump. -To build a zfcpdump kernel use the following settings in your kernel -configuration: - * CONFIG_ZFCPDUMP=y - * Enable ZFCP driver - * Enable SCSI driver - * Enable ext2 and ext3 filesystems - * Disable as many features as possible to keep the kernel small. - E.g. network support is not needed at all. +To get a valid zfcpdump kernel configuration use "make zfcpdump_defconfig". -To use the zfcpdump userspace application in an initramfs you have to do the -following: +The s390 zipl tool looks for the zfcpdump kernel and optional initrd/initramfs +under the following locations: - * Copy the zfcpdump executable somewhere into your Linux tree. - E.g. to "arch/s390/boot/zfcpdump. If you do not want to include - shared libraries, compile the tool with the "-static" gcc option. - * If you want to include e2fsck, add it to your source tree, too. The zfcpdump - application attempts to start /sbin/e2fsck from the ramdisk. - * Use an initramfs config file like the following: +* kernel: <zfcpdump directory>/zfcpdump.image +* ramdisk: <zfcpdump directory>/zfcpdump.rd - dir /dev 755 0 0 - nod /dev/console 644 0 0 c 5 1 - nod /dev/null 644 0 0 c 1 3 - nod /dev/sda1 644 0 0 b 8 1 - nod /dev/sda2 644 0 0 b 8 2 - nod /dev/sda3 644 0 0 b 8 3 - nod /dev/sda4 644 0 0 b 8 4 - nod /dev/sda5 644 0 0 b 8 5 - nod /dev/sda6 644 0 0 b 8 6 - nod /dev/sda7 644 0 0 b 8 7 - nod /dev/sda8 644 0 0 b 8 8 - nod /dev/sda9 644 0 0 b 8 9 - nod /dev/sda10 644 0 0 b 8 10 - nod /dev/sda11 644 0 0 b 8 11 - nod /dev/sda12 644 0 0 b 8 12 - nod /dev/sda13 644 0 0 b 8 13 - nod /dev/sda14 644 0 0 b 8 14 - nod /dev/sda15 644 0 0 b 8 15 - file /init arch/s390/boot/zfcpdump 755 0 0 - file /sbin/e2fsck arch/s390/boot/e2fsck 755 0 0 - dir /proc 755 0 0 - dir /sys 755 0 0 - dir /mnt 755 0 0 - dir /sbin 755 0 0 +The zfcpdump directory is defined in the s390-tools package. - * Issue "make image" to build the zfcpdump image with initramfs. +The user space application of zfcpdump can reside in an intitramfs or an +initrd. It can also be included in a built-in kernel initramfs. The application +reads from /proc/vmcore or zcore/mem and writes the system dump to a SCSI disk. -In a Linux distribution the zfcpdump enabled kernel image must be copied to -/usr/share/zfcpdump/zfcpdump.image, where the s390 zipl tool is looking for the -dump kernel when preparing a SCSI dump disk. - -If you use a ramdisk copy it to "/usr/share/zfcpdump/zfcpdump.rd". +The s390-tools package version 1.24.0 and above builds an external zfcpdump +initramfs with a user space application that writes the dump to a SCSI +partition. For more information on how to use zfcpdump refer to the s390 'Using the Dump Tools book', which is available from diff --git a/Documentation/scheduler/sched-arch.txt b/Documentation/scheduler/sched-arch.txt index 9290de7..a2f27bb 100644 --- a/Documentation/scheduler/sched-arch.txt +++ b/Documentation/scheduler/sched-arch.txt @@ -8,7 +8,7 @@ Context switch By default, the switch_to arch function is called with the runqueue locked. This is usually not a problem unless switch_to may need to take the runqueue lock. This is usually due to a wake up operation in -the context switch. See arch/ia64/include/asm/system.h for an example. +the context switch. See arch/ia64/include/asm/switch_to.h for an example. To request the scheduler call switch_to with the runqueue unlocked, you must `#define __ARCH_WANT_UNLOCKED_CTXSW` in a header file diff --git a/Documentation/scsi/LICENSE.qla2xxx b/Documentation/scsi/LICENSE.qla2xxx index 5020b7b..52f0b43 100644 --- a/Documentation/scsi/LICENSE.qla2xxx +++ b/Documentation/scsi/LICENSE.qla2xxx @@ -1,4 +1,4 @@ -Copyright (c) 2003-2013 QLogic Corporation +Copyright (c) 2003-2014 QLogic Corporation QLogic Linux FC-FCoE Driver This program includes a device driver for Linux 3.x. diff --git a/Documentation/scsi/tmscsim.txt b/Documentation/scsi/tmscsim.txt index 3303d21..0810132 100644 --- a/Documentation/scsi/tmscsim.txt +++ b/Documentation/scsi/tmscsim.txt @@ -317,8 +317,6 @@ Each of the parameters is a number, containing the described information: 4 0x10 16 Immediate return on BIOS seek command. (Not used) (*)5 0x20 32 Check for LUNs >= 1. - The default for LUN Check depends on CONFIG_SCSI_MULTI_LUN. - * TaggedCmnds is a number indicating the maximum number of Tagged Commands. It is the binary logarithm - 1 of the actual number. Max is 4 (32). Value Number of Tagged Commands diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt index 5ea996f..b6ef7e9 100644 --- a/Documentation/security/Smack.txt +++ b/Documentation/security/Smack.txt @@ -204,6 +204,16 @@ onlycap these capabilities are effective at for processes with any label. The value is set by writing the desired label to the file or cleared by writing "-" to the file. +ptrace + This is used to define the current ptrace policy + 0 - default: this is the policy that relies on smack access rules. + For the PTRACE_READ a subject needs to have a read access on + object. For the PTRACE_ATTACH a read-write access is required. + 1 - exact: this is the policy that limits PTRACE_ATTACH. Attach is + only allowed when subject's and object's labels are equal. + PTRACE_READ is not affected. Can be overriden with CAP_SYS_PTRACE. + 2 - draconian: this policy behaves like the 'exact' above with an + exception that it can't be overriden with CAP_SYS_PTRACE. revoke-subject Writing a Smack label here sets the access to '-' for all access rules with that subject label. diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt index a4c33f1..8727c19 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/serial/00-INDEX b/Documentation/serial/00-INDEX index f9c6b5e..8021a9f 100644 --- a/Documentation/serial/00-INDEX +++ b/Documentation/serial/00-INDEX @@ -2,23 +2,15 @@ - this file. README.cycladesZ - info on Cyclades-Z firmware loading. -digiepca.txt - - info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards. driver - intro to the low level serial driver. moxa-smartio - file with info on installing/using Moxa multiport serial driver. n_gsm.txt - GSM 0710 tty multiplexer howto. -riscom8.txt - - notes on using the RISCom/8 multi-port serial driver. rocket.txt - info on the Comtrol RocketPort multiport serial driver. serial-rs485.txt - info about RS485 structures and support in the kernel. -specialix.txt - - info on hardware/driver for specialix IO8+ multiport serial card. -sx.txt - - info on the Specialix SX/SI multiport serial driver. tty.txt - guide to the locking policies of the tty layer. diff --git a/Documentation/serial/digiepca.txt b/Documentation/serial/digiepca.txt deleted file mode 100644 index f2560e2..0000000 --- a/Documentation/serial/digiepca.txt +++ /dev/null @@ -1,98 +0,0 @@ -NOTE: This driver is obsolete. Digi provides a 2.6 driver (dgdm) at -http://www.digi.com for PCI cards. They no longer maintain this driver, -and have no 2.6 driver for ISA cards. - -This driver requires a number of user-space tools. They can be acquired from -http://www.digi.com, but only works with 2.4 kernels. - - -The Digi Intl. epca driver. ----------------------------- -The Digi Intl. epca driver for Linux supports the following boards: - -Digi PC/Xem, PC/Xr, PC/Xe, PC/Xi, PC/Xeve -Digi EISA/Xem, PCI/Xem, PCI/Xr - -Limitations: ------------- -Currently the driver only autoprobes for supported PCI boards. - -The Linux MAKEDEV command does not support generating the Digiboard -Devices. Users executing digiConfig to setup EISA and PC series cards -will have their device nodes automatically constructed (cud?? for ~CLOCAL, -and ttyD?? for CLOCAL). Users wishing to boot their board from the LILO -prompt, or those users booting PCI cards may use buildDIGI to construct -the necessary nodes. - -Notes: ------- -This driver may be configured via LILO. For users who have already configured -their driver using digiConfig, configuring from LILO will override previous -settings. Multiple boards may be configured by issuing multiple LILO command -lines. For examples see the bottom of this document. - -Device names start at 0 and continue up. Beware of this as previous Digi -drivers started device names with 1. - -PCI boards are auto-detected and configured by the driver. PCI boards will -be allocated device numbers (internally) beginning with the lowest PCI slot -first. In other words a PCI card in slot 3 will always have higher device -nodes than a PCI card in slot 1. - -LILO config examples: ---------------------- -Using LILO's APPEND command, a string of comma separated identifiers or -integers can be used to configure supported boards. The six values in order -are: - - Enable/Disable this card or Override, - Type of card: PC/Xe (AccelePort) (0), PC/Xeve (1), PC/Xem or PC/Xr (2), - EISA/Xem (3), PC/64Xe (4), PC/Xi (5), - Enable/Disable alternate pin arrangement, - Number of ports on this card, - I/O Port where card is configured (in HEX if using string identifiers), - Base of memory window (in HEX if using string identifiers), - -NOTE : PCI boards are auto-detected and configured. Do not attempt to -configure PCI boards with the LILO append command. If you wish to override -previous configuration data (As set by digiConfig), but you do not wish to -configure any specific card (Example if there are PCI cards in the system) -the following override command will accomplish this: --> append="digi=2" - -Samples: - append="digiepca=E,PC/Xe,D,16,200,D0000" - or - append="digi=1,0,0,16,512,851968" - -Supporting Tools: ------------------ -Supporting tools include digiDload, digiConfig, buildPCI, and ditty. See -drivers/char/README.epca for more details. Note, -this driver REQUIRES that digiDload be executed prior to it being used. -Failure to do this will result in an ENODEV error. - -Documentation: --------------- -Complete documentation for this product may be found in the tool package. - -Sources of information and support: ------------------------------------ -Digi Intl. support site for this product: - --> http://www.digi.com - -Acknowledgments: ----------------- -Much of this work (And even text) was derived from a similar document -supporting the original public domain DigiBoard driver Copyright (C) -1994,1995 Troy De Jongh. Many thanks to Christoph Lameter -(christoph@lameter.com) and Mike McLagan (mike.mclagan@linux.org) who authored -and contributed to the original document. - -Changelog: ----------- -10-29-04: Update status of driver, remove dead links in document - James Nelson <james4765@gmail.com> - -2000 (?) Original Document diff --git a/Documentation/serial/driver b/Documentation/serial/driver index c3a7689..3bba1ae 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver @@ -429,3 +429,28 @@ thus: struct uart_port port; int my_stuff; }; + +Modem control lines via GPIO +---------------------------- + +Some helpers are provided in order to set/get modem control lines via GPIO. + +mctrl_gpio_init(dev, idx): + This will get the {cts,rts,...}-gpios from device tree if they are + present and request them, set direction etc, and return an + allocated structure. devm_* functions are used, so there's no need + to call mctrl_gpio_free(). + +mctrl_gpio_free(dev, gpios): + This will free the requested gpios in mctrl_gpio_init(). + As devm_* function are used, there's generally no need to call + this function. + +mctrl_gpio_to_gpiod(gpios, gidx) + This returns the gpio structure associated to the modem line index. + +mctrl_gpio_set(gpios, mctrl): + This will sets the gpios according to the mctrl state. + +mctrl_gpio_get(gpios, mctrl): + This will update mctrl with the gpios values. diff --git a/Documentation/serial/riscom8.txt b/Documentation/serial/riscom8.txt deleted file mode 100644 index 14f61fd..0000000 --- a/Documentation/serial/riscom8.txt +++ /dev/null @@ -1,36 +0,0 @@ -* NOTE - this is an unmaintained driver. The original author cannot be located. - -SDL Communications is now SBS Technologies, and does not have any -information on these ancient ISA cards on their website. - -James Nelson <james4765@gmail.com> - 12-12-2004 - - This is the README for RISCom/8 multi-port serial driver - (C) 1994-1996 D.Gorodchanin - See file LICENSE for terms and conditions. - -NOTE: English is not my native language. - I'm sorry for any mistakes in this text. - -Misc. notes for RISCom/8 serial driver, in no particular order :) - -1) This driver can support up to 4 boards at time. - Use string "riscom8=0xXXX,0xXXX,0xXXX,0xXXX" at LILO prompt, for - setting I/O base addresses for boards. If you compile driver - as module use modprobe options "iobase=0xXXX iobase1=0xXXX iobase2=..." - -2) The driver partially supports famous 'setserial' program, you can use almost - any of its options, excluding port & irq settings. - -3) There are some misc. defines at the beginning of riscom8.c, please read the - comments and try to change some of them in case of problems. - -4) I consider the current state of the driver as BETA. - -5) SDL Communications WWW page is http://www.sdlcomm.com. - -6) You can use the MAKEDEV program to create RISCom/8 /dev/ttyL* entries. - -7) Minor numbers for first board are 0-7, for second 8-15, etc. - -22 Apr 1996. diff --git a/Documentation/serial/specialix.txt b/Documentation/serial/specialix.txt deleted file mode 100644 index 6eb6f3a..0000000 --- a/Documentation/serial/specialix.txt +++ /dev/null @@ -1,383 +0,0 @@ - - specialix.txt -- specialix IO8+ multiport serial driver readme. - - - - Copyright (C) 1997 Roger Wolff (R.E.Wolff@BitWizard.nl) - - Specialix pays for the development and support of this driver. - Please DO contact io8-linux@specialix.co.uk if you require - support. - - This driver was developed in the BitWizard linux device - driver service. If you require a linux device driver for your - product, please contact devices@BitWizard.nl for a quote. - - This code is firmly based on the riscom/8 serial driver, - written by Dmitry Gorodchanin. The specialix IO8+ card - programming information was obtained from the CL-CD1865 Data - Book, and Specialix document number 6200059: IO8+ Hardware - Functional Specification, augmented by document number 6200088: - Merak Hardware Functional Specification. (IO8+/PCI is also - called Merak) - - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of - the License, or (at your option) any later version. - - This program is distributed in the hope that it will be - useful, but WITHOUT ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR - PURPOSE. See the GNU General Public License for more details. - - You should have received a copy of the GNU General Public - License along with this program; if not, write to the Free - Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, - USA. - - -Intro -===== - - -This file contains some random information, that I like to have online -instead of in a manual that can get lost. Ever misplace your Linux -kernel sources? And the manual of one of the boards in your computer? - - -Addresses and interrupts -======================== - -Address dip switch settings: -The dip switch sets bits 2-9 of the IO address. - - 9 8 7 6 5 4 3 2 - +-----------------+ - 0 | X X X X X X X | - | | = IoBase = 0x100 - 1 | X | - +-----------------+ ------ RS232 connectors ----> - - | | | - edge connector - | | | - V V V - -Base address 0x100 caused a conflict in one of my computers once. I -haven't the foggiest why. My Specialix card is now at 0x180. My -other computer runs just fine with the Specialix card at 0x100.... -The card occupies 4 addresses, but actually only two are really used. - -The PCI version doesn't have any dip switches. The BIOS assigns -an IO address. - -The driver now still autoprobes at 0x100, 0x180, 0x250 and 0x260. If -that causes trouble for you, please report that. I'll remove -autoprobing then. - -The driver will tell the card what IRQ to use, so you don't have to -change any jumpers to change the IRQ. Just use a command line -argument (irq=xx) to the insmod program to set the interrupt. - -The BIOS assigns the IRQ on the PCI version. You have no say in what -IRQ to use in that case. - -If your specialix cards are not at the default locations, you can use -the kernel command line argument "specialix=io0,irq0,io1,irq1...". -Here "io0" is the io address for the first card, and "irq0" is the -irq line that the first card should use. And so on. - -Examples. - -You use the driver as a module and have three cards at 0x100, 0x250 -and 0x180. And some way or another you want them detected in that -order. Moreover irq 12 is taken (e.g. by your PS/2 mouse). - - insmod specialix.o iobase=0x100,0x250,0x180 irq=9,11,15 - -The same three cards, but now in the kernel would require you to -add - - specialix=0x100,9,0x250,11,0x180,15 - -to the command line. This would become - - append="specialix=0x100,9,0x250,11,0x180,15" - -in your /etc/lilo.conf file if you use lilo. - -The Specialix driver is slightly odd: It allows you to have the second -or third card detected without having a first card. This has -advantages and disadvantages. A slot that isn't filled by an ISA card, -might be filled if a PCI card is detected. Thus if you have an ISA -card at 0x250 and a PCI card, you would get: - -sx0: specialix IO8+ Board at 0x100 not found. -sx1: specialix IO8+ Board at 0x180 not found. -sx2: specialix IO8+ board detected at 0x250, IRQ 12, CD1865 Rev. B. -sx3: specialix IO8+ Board at 0x260 not found. -sx0: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B. - -This would happen if you don't give any probe hints to the driver. -If you would specify: - - specialix=0x250,11 - -you'd get the following messages: - -sx0: specialix IO8+ board detected at 0x250, IRQ 11, CD1865 Rev. B. -sx1: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B. - -ISA probing is aborted after the IO address you gave is exhausted, and -the PCI card is now detected as the second card. The ISA card is now -also forced to IRQ11.... - - -Baud rates -========== - -The rev 1.2 and below boards use a CL-CD1864. These chips can only -do 64kbit. The rev 1.3 and newer boards use a CL-CD1865. These chips -are officially capable of 115k2. - -The Specialix card uses a 25MHz crystal (in times two mode, which in -fact is a divided by two mode). This is not enough to reach the rated -115k2 on all ports at the same time. With this clock rate you can only -do 37% of this rate. This means that at 115k2 on all ports you are -going to lose characters (The chip cannot handle that many incoming -bits at this clock rate.) (Yes, you read that correctly: there is a -limit to the number of -=bits=- per second that the chip can handle.) - -If you near the "limit" you will first start to see a graceful -degradation in that the chip cannot keep the transmitter busy at all -times. However with a central clock this slow, you can also get it to -miss incoming characters. The driver will print a warning message when -you are outside the official specs. The messages usually show up in -the file /var/log/messages . - -The specialix card cannot reliably do 115k2. If you use it, you have -to do "extensive testing" (*) to verify if it actually works. - -When "mgetty" communicates with my modem at 115k2 it reports: -got: +++[0d]ATQ0V1H0[0d][0d][8a]O[cb][0d][8a] - ^^^^ ^^^^ ^^^^ - -The three characters that have the "^^^" under them have suffered a -bit error in the highest bit. In conclusion: I've tested it, and found -that it simply DOESN'T work for me. I also suspect that this is also -caused by the baud rate being just a little bit out of tune. - -I upgraded the crystal to 66Mhz on one of my Specialix cards. Works -great! Contact me for details. (Voids warranty, requires a steady hand -and more such restrictions....) - - -(*) Cirrus logic CD1864 databook, page 40. - - -Cables for the Specialix IO8+ -============================= - -The pinout of the connectors on the IO8+ is: - - pin short direction long name - name - Pin 1 DCD input Data Carrier Detect - Pin 2 RXD input Receive - Pin 3 DTR/RTS output Data Terminal Ready/Ready To Send - Pin 4 GND - Ground - Pin 5 TXD output Transmit - Pin 6 CTS input Clear To Send - - - -- 6 5 4 3 2 1 -- - | | - | | - | | - | | - +----- -----+ - |__________| - clip - - Front view of an RJ12 connector. Cable moves "into" the paper. - (the plug is ready to plug into your mouth this way...) - - - NULL cable. I don't know who is going to use these except for - testing purposes, but I tested the cards with this cable. (It - took quite a while to figure out, so I'm not going to delete - it. So there! :-) - - - This end goes This end needs - straight into the some twists in - RJ12 plug. the wiring. - IO8+ RJ12 IO8+ RJ12 - 1 DCD white - - - - 1 DCD - 2 RXD black 5 TXD - 3 DTR/RTS red 6 CTS - 4 GND green 4 GND - 5 TXD yellow 2 RXD - 6 CTS blue 3 DTR/RTS - - - Same NULL cable, but now sorted on the second column. - - 1 DCD white - - - - 1 DCD - 5 TXD yellow 2 RXD - 6 CTS blue 3 DTR/RTS - 4 GND green 4 GND - 2 RXD black 5 TXD - 3 DTR/RTS red 6 CTS - - - - This is a modem cable usable for hardware handshaking: - RJ12 DB25 DB9 - 1 DCD white 8 DCD 1 DCD - 2 RXD black 3 RXD 2 RXD - 3 DTR/RTS red 4 RTS 7 RTS - 4 GND green 7 GND 5 GND - 5 TXD yellow 2 TXD 3 TXD - 6 CTS blue 5 CTS 8 CTS - +---- 6 DSR 6 DSR - +---- 20 DTR 4 DTR - - This is a modem cable usable for software handshaking: - It allows you to reset the modem using the DTR ioctls. - I (REW) have never tested this, "but xxxxxxxxxxxxx - says that it works." If you test this, please - tell me and I'll fill in your name on the xxx's. - - RJ12 DB25 DB9 - 1 DCD white 8 DCD 1 DCD - 2 RXD black 3 RXD 2 RXD - 3 DTR/RTS red 20 DTR 4 DTR - 4 GND green 7 GND 5 GND - 5 TXD yellow 2 TXD 3 TXD - 6 CTS blue 5 CTS 8 CTS - +---- 6 DSR 6 DSR - +---- 4 RTS 7 RTS - - I bought a 6 wire flat cable. It was colored as indicated. - Check that yours is the same before you trust me on this. - - -Hardware handshaking issues. -============================ - -The driver can be told to operate in two different ways. The default -behaviour is specialix.sx_rtscts = 0 where the pin behaves as DTR when -hardware handshaking is off. It behaves as the RTS hardware -handshaking signal when hardware handshaking is selected. - -When you use this, you have to use the appropriate cable. The -cable will either be compatible with hardware handshaking or with -software handshaking. So switching on the fly is not really an -option. - -I actually prefer to use the "specialix.sx_rtscts=1" option. -This makes the DTR/RTS pin always an RTS pin, and ioctls to -change DTR are always ignored. I have a cable that is configured -for this. - - -Ports and devices -================= - -Port 0 is the one furthest from the card-edge connector. - -Devices: - -You should make the devices as follows: - -bash -cd /dev -for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 \ - 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 -do - echo -n "$i " - mknod /dev/ttyW$i c 75 $i - mknod /dev/cuw$i c 76 $i -done -echo "" - -If your system doesn't come with these devices preinstalled, bug your -linux-vendor about this. They have had ample time to get this -implemented by now. - -You cannot have more than 4 boards in one computer. The card only -supports 4 different interrupts. If you really want this, contact me -about this and I'll give you a few tips (requires soldering iron).... - -If you have enough PCI slots, you can probably use more than 4 PCI -versions of the card though.... - -The PCI version of the card cannot adhere to the mechanical part of -the PCI spec because the 8 serial connectors are simply too large. If -it doesn't fit in your computer, bring back the card. - - ------------------------------------------------------------------------- - - - Fixed bugs and restrictions: - - During initialization, interrupts are blindly turned on. - Having a shadow variable would cause an extra memory - access on every IO instruction. - - The interrupt (on the card) should be disabled when we - don't allocate the Linux end of the interrupt. This allows - a different driver/card to use it while all ports are not in - use..... (a la standard serial port) - == An extra _off variant of the sx_in and sx_out macros are - now available. They don't set the interrupt enable bit. - These are used during initialization. Normal operation uses - the old variant which enables the interrupt line. - - RTS/DTR issue needs to be implemented according to - specialix' spec. - I kind of like the "determinism" of the current - implementation. Compile time flag? - == Ok. Compile time flag! Default is how Specialix likes it. - == Now a config time flag! Gets saved in your config file. Neat! - - Can you set the IO address from the lilo command line? - If you need this, bug me about it, I'll make it. - == Hah! No bugging needed. Fixed! :-) - - Cirrus logic hasn't gotten back to me yet why the CD1865 can - and the CD1864 can't do 115k2. I suspect that this is - because the CD1864 is not rated for 33MHz operation. - Therefore the CD1864 versions of the card can't do 115k2 on - all ports just like the CD1865 versions. The driver does - not block 115k2 on CD1864 cards. - == I called the Cirrus Logic representative here in Holland. - The CD1864 databook is identical to the CD1865 databook, - except for an extra warning at the end. Similar Bit errors - have been observed in testing at 115k2 on both an 1865 and - a 1864 chip. I see no reason why I would prohibit 115k2 on - 1864 chips and not do it on 1865 chips. Actually there is - reason to prohibit it on BOTH chips. I print a warning. - If you use 115k2, you're on your own. - - A spiky CD may send spurious HUPs. Also in CLOCAL??? - -- A fix for this turned out to be counter productive. - Different fix? Current behaviour is acceptable? - -- Maybe the current implementation is correct. If anybody - gets bitten by this, please report, and it will get fixed. - - -- Testing revealed that when in CLOCAL, the problem doesn't - occur. As warned for in the CD1865 manual, the chip may - send modem intr's on a spike. We could filter those out, - but that would be a cludge anyway (You'd still risk getting - a spurious HUP when two spikes occur.)..... - - - - Bugs & restrictions: - - This is a difficult card to autoprobe. - You have to WRITE to the address register to even - read-probe a CD186x register. Disable autodetection? - -- Specialix: any suggestions? - - diff --git a/Documentation/serial/sx.txt b/Documentation/serial/sx.txt deleted file mode 100644 index cb4efa0..0000000 --- a/Documentation/serial/sx.txt +++ /dev/null @@ -1,294 +0,0 @@ - - sx.txt -- specialix SX/SI multiport serial driver readme. - - - - Copyright (C) 1997 Roger Wolff (R.E.Wolff@BitWizard.nl) - - Specialix pays for the development and support of this driver. - Please DO contact support@specialix.co.uk if you require - support. - - This driver was developed in the BitWizard linux device - driver service. If you require a linux device driver for your - product, please contact devices@BitWizard.nl for a quote. - - (History) - There used to be an SI driver by Simon Allan. This is a complete - rewrite from scratch. Just a few lines-of-code have been snatched. - - (Sources) - Specialix document number 6210028: SX Host Card and Download Code - Software Functional Specification. - - (Copying) - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of - the License, or (at your option) any later version. - - This program is distributed in the hope that it will be - useful, but WITHOUT ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR - PURPOSE. See the GNU General Public License for more details. - - You should have received a copy of the GNU General Public - License along with this program; if not, write to the Free - Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, - USA. - - (Addendum) - I'd appreciate it that if you have fixes, that you send them - to me first. - - -Introduction -============ - -This file contains some random information, that I like to have online -instead of in a manual that can get lost. Ever misplace your Linux -kernel sources? And the manual of one of the boards in your computer? - - -Theory of operation -=================== - -An important thing to know is that the driver itself doesn't have the -firmware for the card. This means that you need the separate package -"sx_firmware". For now you can get the source at - - ftp://ftp.bitwizard.nl/specialix/sx_firmware_<version>.tgz - -The firmware load needs a "misc" device, so you'll need to enable the -"Support for user misc device modules" in your kernel configuration. -The misc device needs to be called "/dev/specialix_sxctl". It needs -misc major 10, and minor number 167 (assigned by HPA). The section -on creating device files below also creates this device. - -After loading the sx.o module into your kernel, the driver will report -the number of cards detected, but because it doesn't have any -firmware, it will not be able to determine the number of ports. Only -when you then run "sx_firmware" will the firmware be downloaded and -the rest of the driver initialized. At that time the sx_firmware -program will report the number of ports installed. - -In contrast with many other multi port serial cards, some of the data -structures are only allocated when the card knows the number of ports -that are connected. This means we won't waste memory for 120 port -descriptor structures when you only have 8 ports. If you experience -problems due to this, please report them: I haven't seen any. - - -Interrupts -========== - -A multi port serial card, would generate a horrendous amount of -interrupts if it would interrupt the CPU for every received -character. Even more than 10 years ago, the trick not to use -interrupts but to poll the serial cards was invented. - -The SX card allow us to do this two ways. First the card limits its -own interrupt rate to a rate that won't overwhelm the CPU. Secondly, -we could forget about the cards interrupt completely and use the -internal timer for this purpose. - -Polling the card can take up to a few percent of your CPU. Using the -interrupts would be better if you have most of the ports idle. Using -timer-based polling is better if your card almost always has work to -do. You save the separate interrupt in that case. - -In any case, it doesn't really matter all that much. - -The most common problem with interrupts is that for ISA cards in a PCI -system the BIOS has to be told to configure that interrupt as "legacy -ISA". Otherwise the card can pull on the interrupt line all it wants -but the CPU won't see this. - -If you can't get the interrupt to work, remember that polling mode is -more efficient (provided you actually use the card intensively). - - -Allowed Configurations -====================== - -Some configurations are disallowed. Even though at a glance they might -seem to work, they are known to lockup the bus between the host card -and the device concentrators. You should respect the drivers decision -not to support certain configurations. It's there for a reason. - -Warning: Seriously technical stuff ahead. Executive summary: Don't use -SX cards except configured at a 64k boundary. Skip the next paragraph. - -The SX cards can theoretically be placed at a 32k boundary. So for -instance you can put an SX card at 0xc8000-0xd7fff. This is not a -"recommended configuration". ISA cards have to tell the bus controller -how they like their timing. Due to timing issues they have to do this -based on which 64k window the address falls into. This means that the -32k window below and above the SX card have to use exactly the same -timing as the SX card. That reportedly works for other SX cards. But -you're still left with two useless 32k windows that should not be used -by anybody else. - - -Configuring the driver -====================== - -PCI cards are always detected. The driver auto-probes for ISA cards at -some sensible addresses. Please report if the auto-probe causes trouble -in your system, or when a card isn't detected. - -I'm afraid I haven't implemented "kernel command line parameters" yet. -This means that if the default doesn't work for you, you shouldn't use -the compiled-into-the-kernel version of the driver. Use a module -instead. If you convince me that you need this, I'll make it for -you. Deal? - -I'm afraid that the module parameters are a bit clumsy. If you have a -better idea, please tell me. - -You can specify several parameters: - - sx_poll: number of jiffies between timer-based polls. - - Set this to "0" to disable timer based polls. - Initialization of cards without a working interrupt - will fail. - - Set this to "1" if you want a polling driver. - (on Intel: 100 polls per second). If you don't use - fast baud rates, you might consider a value like "5". - (If you don't know how to do the math, use 1). - - sx_slowpoll: Number of jiffies between timer-based polls. - Set this to "100" to poll once a second. - This should get the card out of a stall if the driver - ever misses an interrupt. I've never seen this happen, - and if it does, that's a bug. Tell me. - - sx_maxints: Number of interrupts to request from the card. - The card normally limits interrupts to about 100 per - second to offload the host CPU. You can increase this - number to reduce latency on the card a little. - Note that if you give a very high number you can overload - your CPU as well as the CPU on the host card. This setting - is inaccurate and not recommended for SI cards (But it - works). - - sx_irqmask: The mask of allowable IRQs to use. I suggest you set - this to 0 (disable IRQs all together) and use polling if - the assignment of IRQs becomes problematic. This is defined - as the sum of (1 << irq) 's that you want to allow. So - sx_irqmask of 8 (1 << 3) specifies that only irq 3 may - be used by the SX driver. If you want to specify to the - driver: "Either irq 11 or 12 is ok for you to use", then - specify (1 << 11) | (1 << 12) = 0x1800 . - - sx_debug: You can enable different sorts of debug traces with this. - At "-1" all debugging traces are active. You'll get several - times more debugging output than you'll get characters - transmitted. - - -Baud rates -========== - -Theoretically new SXDCs should be capable of more than 460k -baud. However the line drivers usually give up before that. Also the -CPU on the card may not be able to handle 8 channels going at full -blast at that speed. Moreover, the buffers are not large enough to -allow operation with 100 interrupts per second. You'll have to realize -that the card has a 256 byte buffer, so you'll have to increase the -number of interrupts per second if you have more than 256*100 bytes -per second to transmit. If you do any performance testing in this -area, I'd be glad to hear from you... - -(Psst Linux users..... I think the Linux driver is more efficient than -the driver for other OSes. If you can and want to benchmark them -against each other, be my guest, and report your findings...... :-) - - -Ports and devices -================= - -Port 0 is the top connector on the module closest to the host -card. Oh, the ports on the SXDCs and TAs are labelled from 1 to 8 -instead of from 0 to 7, as they are numbered by linux. I'm stubborn in -this: I know for sure that I wouldn't be able to calculate which port -is which anymore if I would change that.... - - -Devices: - -You should make the device files as follows: - -#!/bin/sh -# (I recommend that you cut-and-paste this into a file and run that) -cd /dev -t=0 -mknod specialix_sxctl c 10 167 -while [ $t -lt 64 ] - do - echo -n "$t " - mknod ttyX$t c 32 $t - mknod cux$t c 33 $t - t=`expr $t + 1` -done -echo "" -rm /etc/psdevtab -ps > /dev/null - - -This creates 64 devices. If you have more, increase the constant on -the line with "while". The devices start at 0, as is customary on -Linux. Specialix seems to like starting the numbering at 1. - -If your system doesn't come with these devices pre-installed, bug your -linux-vendor about this. They should have these devices -"pre-installed" before the new millennium. The "ps" stuff at the end -is to "tell" ps that the new devices exist. - -Officially the maximum number of cards per computer is 4. This driver -however supports as many cards in one machine as you want. You'll run -out of interrupts after a few, but you can switch to polled operation -then. At about 256 ports (More than 8 cards), we run out of minor -device numbers. Sorry. I suggest you buy a second computer.... (Or -switch to RIO). - ------------------------------------------------------------------------- - - - Fixed bugs and restrictions: - - Hangup processing. - -- Done. - - - the write path in generic_serial (lockup / oops). - -- Done (Ugly: not the way I want it. Copied from serial.c). - - - write buffer isn't flushed at close. - -- Done. I still seem to lose a few chars at close. - Sorry. I think that this is a firmware issue. (-> Specialix) - - - drain hardware before changing termios - - Change debug on the fly. - - ISA free irq -1. (no firmware loaded). - - adding c8000 as a probe address. Added warning. - - Add a RAMtest for the RAM on the card.c - - Crash when opening a port "way" of the number of allowed ports. - (for example opening port 60 when there are only 24 ports attached) - - Sometimes the use-count strays a bit. After a few hours of - testing the use count is sometimes "3". If you are not like - me and can remember what you did to get it that way, I'd - appreciate an Email. Possibly fixed. Tell me if anyone still - sees this. - - TAs don't work right if you don't connect all the modem control - signals. SXDCs do. T225 firmware problem -> Specialix. - (Mostly fixed now, I think. Tell me if you encounter this!) - - Bugs & restrictions: - - - Arbitrary baud rates. Requires firmware update. (-> Specialix) - - - Low latency (mostly firmware, -> Specialix) - - - diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 7ccf933..48148d6 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -2026,8 +2026,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. ------------------- Module for sound cards based on the Asus AV66/AV100/AV200 chips, - i.e., Xonar D1, DX, D2, D2X, DS, Essence ST (Deluxe), Essence STX, - HDAV1.3 (Deluxe), and HDAV1.3 Slim. + i.e., Xonar D1, DX, D2, D2X, DS, DSX, Essence ST (Deluxe), + Essence STX (II), HDAV1.3 (Deluxe), and HDAV1.3 Slim. This module supports autoprobe and multiple cards. diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 85c362d..a5e7547 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -284,8 +284,18 @@ STAC92HD83* hp-zephyr HP Zephyr hp-led HP with broken BIOS for mute LED hp-inv-led HP with broken BIOS for inverted mute LED + hp-mic-led HP with mic-mute LED + headset-jack Dell Latitude with a 4-pin headset jack + hp-envy-bass Pin fixup for HP Envy bass speaker (NID 0x0f) + hp-envy-ts-bass Pin fixup for HP Envy TS bass speaker (NID 0x10) + hp-bnb13-eq Hardware equalizer setup for HP laptops auto BIOS setup (default) +STAC92HD95 +========== + hp-led LED support for HP laptops + hp-bass Bass HPF setup for HP Spectre 13 + STAC9872 ======== vaio VAIO laptop without SPDIF diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index b0714d8..aee73e7 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 @@ -39,7 +42,7 @@ Procedure for submitting patches to the -stable tree: the stable tree without anything else needing to be done by the author or subsystem maintainer. - If the patch requires other patches as prerequisites which can be - cherry-picked than this can be specified in the following format in + cherry-picked, then this can be specified in the following format in the sign-off area: Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index ec8be46..c14374e 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -75,8 +75,10 @@ show up in /proc/sys/kernel: - shmall - shmmax [ sysv ipc ] - shmmni +- softlockup_all_cpu_backtrace - stop-a [ SPARC only ] - sysrq ==> Documentation/sysrq.txt +- sysctl_writes_strict - tainted - threads-max - unknown_nmi_panic @@ -317,6 +319,7 @@ for more than this value report a warning. This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. 0: means infinite timeout - no checking done. +Possible values to set are in range {0..LONG_MAX/HZ}. ============================================================== @@ -761,6 +764,42 @@ without users and with a dead originative process will be destroyed. ============================================================== +sysctl_writes_strict: + +Control how file position affects the behavior of updating sysctl values +via the /proc/sys interface: + + -1 - Legacy per-write sysctl value handling, with no printk warnings. + Each write syscall must fully contain the sysctl value to be + written, and multiple writes on the same sysctl file descriptor + will rewrite the sysctl value, regardless of file position. + 0 - (default) Same behavior as above, but warn about processes that + perform writes to a sysctl file descriptor when the file position + is not 0. + 1 - Respect file position when writing sysctl strings. Multiple writes + will append to the sysctl value buffer. Anything past the max length + of the sysctl value buffer will be ignored. Writes to numeric sysctl + entries must always be at file position 0 and the value must be + fully contained in the buffer sent in the write syscall. + +============================================================== + +softlockup_all_cpu_backtrace: + +This value controls the soft lockup detector thread's behavior +when a soft lockup condition is detected as to whether or not +to gather further debug information. If enabled, each cpu will +be issued an NMI and instructed to capture stack trace. + +This feature is only applicable for architectures which support +NMI. + +0: do nothing. This is the default behavior. + +1: on detection capture more debug information. + +============================================================== + tainted: Non-zero if the kernel has been tainted. Numeric values, which @@ -785,6 +824,8 @@ can be ORed together: 1024 - A module from drivers/staging was loaded. 2048 - The system is working around a severe firmware bug. 4096 - An out-of-tree module has been loaded. +8192 - An unsigned module has been loaded in a kernel supporting module + signature. ============================================================== diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index d614a9b..4415aa9 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -175,18 +175,39 @@ Setting this to zero disables periodic writeback altogether. drop_caches -Writing to this will cause the kernel to drop clean caches, dentries and -inodes from memory, causing that memory to become free. +Writing to this will cause the kernel to drop clean caches, as well as +reclaimable slab objects like dentries and inodes. Once dropped, their +memory becomes free. To free pagecache: echo 1 > /proc/sys/vm/drop_caches -To free dentries and inodes: +To free reclaimable slab objects (includes dentries and inodes): echo 2 > /proc/sys/vm/drop_caches -To free pagecache, dentries and inodes: +To free slab objects and pagecache: echo 3 > /proc/sys/vm/drop_caches -As this is a non-destructive operation and dirty objects are not freeable, the -user should run `sync' first. +This is a non-destructive operation and will not free any dirty objects. +To increase the number of objects freed by this operation, the user may run +`sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the +number of dirty objects on the system and create more candidates to be +dropped. + +This file is not a means to control the growth of the various kernel caches +(inodes, dentries, pagecache, etc...) These objects are automatically +reclaimed by the kernel when memory is needed elsewhere on the system. + +Use of this file can cause performance problems. Since it discards cached +objects, it may cost a significant amount of I/O and CPU to recreate the +dropped objects, especially if they were under heavy use. Because of this, +use outside of a testing or debugging environment is not recommended. + +You may see informational messages in your kernel log when this file is +used: + + cat (1234): drop_caches: 3 + +These are informational only. They do not mean that anything is wrong +with your system. To disable them, echo 4 (bit 3) into drop_caches. ============================================================== @@ -681,7 +702,8 @@ The batch value of each per cpu pagelist is also updated as a result. It is set to pcp->high/4. The upper limit of batch is (PAGE_SHIFT * 8) The initial value is zero. Kernel does not use this value at boot time to set -the high water marks for each per cpu page list. +the high water marks for each per cpu page list. If the user writes '0' to this +sysctl, it will revert to this default behavior. ============================================================== @@ -725,8 +747,8 @@ Changing this takes effect whenever an application requests memory. vfs_cache_pressure ------------------ -Controls the tendency of the kernel to reclaim the memory which is used for -caching of directory and inode objects. +This percentage value controls the tendency of the kernel to reclaim +the memory which is used for caching of directory and inode objects. At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and @@ -736,6 +758,11 @@ never reclaim dentries and inodes due to memory pressure and this can easily lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes. +Increasing vfs_cache_pressure significantly beyond 100 may have negative +performance impact. Reclaim code needs to take various locks to find freeable +directory and inode objects. With vfs_cache_pressure=1000, it will look for +ten times more freeable objects than there are. + ============================================================== zone_reclaim_mode: @@ -751,16 +778,17 @@ This is value ORed together of 2 = Zone reclaim writes dirty pages out 4 = Zone reclaim swaps pages -zone_reclaim_mode is set during bootup to 1 if it is determined that pages -from remote zones will cause a measurable performance reduction. The -page allocator will then reclaim easily reusable pages (those page -cache pages that are currently not used) before allocating off node pages. - -It may be beneficial to switch off zone reclaim if the system is -used for a file server and all of memory should be used for caching files -from disk. In that case the caching effect is more important than +zone_reclaim_mode is disabled by default. For file servers or workloads +that benefit from having their data cached, zone_reclaim_mode should be +left disabled as the caching effect is likely to be more important than data locality. +zone_reclaim may be enabled if it's known that the workload is partitioned +such that each partition fits within a NUMA node and that accessing remote +memory would cause a measurable performance reduction. The page allocator +will then reclaim easily reusable pages (those page cache pages that are +currently not used) before allocating off node pages. + Allowing zone reclaim to write out pages stops processes that are writing large amounts of data from dirtying pages on other nodes. Zone reclaim will write out dirty pages if a zone fills up and so effectively diff --git a/Documentation/thermal/nouveau_thermal b/Documentation/thermal/nouveau_thermal index efceb78..60bc293 100644 --- a/Documentation/thermal/nouveau_thermal +++ b/Documentation/thermal/nouveau_thermal @@ -4,7 +4,7 @@ Kernel driver nouveau Supported chips: * NV43+ -Authors: Martin Peres (mupuf) <martin.peres@labri.fr> +Authors: Martin Peres (mupuf) <martin.peres@free.fr> Description --------- @@ -68,8 +68,9 @@ Your fan can be driven in different modes: NOTE: Be sure to use the manual mode if you want to drive the fan speed manually -NOTE2: Not all fan management modes may be supported on all chipsets. We are -working on it. +NOTE2: When operating in manual mode outside the vbios-defined +[PWM_min, PWM_max] range, the reported fan speed (RPM) may not be accurate +depending on your hardware. Bug reports --------- diff --git a/Documentation/timers/00-INDEX b/Documentation/timers/00-INDEX index 6d042dc..ee212a2 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 0000000..f3a8cf2 --- /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/timers/timer_stats.txt b/Documentation/timers/timer_stats.txt index 8abd40b..de835ee 100644 --- a/Documentation/timers/timer_stats.txt +++ b/Documentation/timers/timer_stats.txt @@ -39,9 +39,9 @@ To stop a sample period issue: The statistics can be retrieved by: # cat /proc/timer_stats -The readout of /proc/timer_stats automatically disables sampling. The sampled -information is kept until a new sample period is started. This allows multiple -readouts. +While sampling is enabled, each readout from /proc/timer_stats will see +newly updated statistics. Once sampling is disabled, the sampled information +is kept until a new sample period is started. This allows multiple readouts. Sample output of /proc/timer_stats: diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt index 79fcafc..dd5f916 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 = ...; @@ -358,11 +332,8 @@ Every arch has an init callback function. If you need to do something early on to initialize some state, this is the time to do that. Otherwise, this simple function below should be sufficient for most people: -int __init ftrace_dyn_arch_init(void *data) +int __init ftrace_dyn_arch_init(void) { - /* return value is done indirectly via data */ - *(unsigned long *)data = 0; - return 0; } diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index bd36598..4da4261 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 @@ -2003,6 +2003,32 @@ want, depending on your needs. 360.774530 | 1) 0.594 us | __phys_addr(); +The function name is always displayed after the closing bracket +for a function if the start of that function is not in the +trace buffer. + +Display of the function name after the closing bracket may be +enabled for functions whose start is in the trace buffer, +allowing easier searching with grep for function durations. +It is default disabled. + + hide: echo nofuncgraph-tail > trace_options + show: echo funcgraph-tail > trace_options + + Example with nofuncgraph-tail (default): + 0) | putname() { + 0) | kmem_cache_free() { + 0) 0.518 us | __phys_addr(); + 0) 1.757 us | } + 0) 2.861 us | } + + Example with funcgraph-tail: + 0) | putname() { + 0) | kmem_cache_free() { + 0) 0.518 us | __phys_addr(); + 0) 1.757 us | } /* kmem_cache_free() */ + 0) 2.861 us | } /* putname() */ + You can put some comments on specific functions by using trace_printk() For example, if you want to put a comment inside the __might_sleep() function, you just have to include diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl index 00e425f..78c9a7b 100644 --- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl +++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl @@ -47,7 +47,6 @@ use constant HIGH_KSWAPD_REWAKEUP => 21; use constant HIGH_NR_SCANNED => 22; use constant HIGH_NR_TAKEN => 23; use constant HIGH_NR_RECLAIMED => 24; -use constant HIGH_NR_CONTIG_DIRTY => 25; my %perprocesspid; my %perprocess; @@ -105,7 +104,7 @@ my $regex_direct_end_default = 'nr_reclaimed=([0-9]*)'; my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)'; my $regex_kswapd_sleep_default = 'nid=([0-9]*)'; my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)'; -my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) contig_taken=([0-9]*) contig_dirty=([0-9]*) contig_failed=([0-9]*)'; +my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) file=([0-9]*)'; my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) zid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)'; my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)'; my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)'; @@ -200,7 +199,7 @@ $regex_lru_isolate = generate_traceevent_regex( $regex_lru_isolate_default, "isolate_mode", "order", "nr_requested", "nr_scanned", "nr_taken", - "contig_taken", "contig_dirty", "contig_failed"); + "file"); $regex_lru_shrink_inactive = generate_traceevent_regex( "vmscan/mm_vmscan_lru_shrink_inactive", $regex_lru_shrink_inactive_default, @@ -375,7 +374,6 @@ EVENT_PROCESS: } my $isolate_mode = $1; my $nr_scanned = $4; - my $nr_contig_dirty = $7; # To closer match vmstat scanning statistics, only count isolate_both # and isolate_inactive as scanning. isolate_active is rotation @@ -385,7 +383,6 @@ EVENT_PROCESS: if ($isolate_mode != 2) { $perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned; } - $perprocesspid{$process_pid}->{HIGH_NR_CONTIG_DIRTY} += $nr_contig_dirty; } elsif ($tracepoint eq "mm_vmscan_lru_shrink_inactive") { $details = $6; if ($details !~ /$regex_lru_shrink_inactive/o) { @@ -539,13 +536,6 @@ sub dump_stats { } } } - if ($stats{$process_pid}->{HIGH_NR_CONTIG_DIRTY}) { - print " "; - my $count = $stats{$process_pid}->{HIGH_NR_CONTIG_DIRTY}; - if ($count != 0) { - print "contig-dirty=$count "; - } - } print "\n"; } diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.txt index 6b018b5..a3efac6 100644 --- a/Documentation/trace/tracepoints.txt +++ b/Documentation/trace/tracepoints.txt @@ -115,6 +115,30 @@ If the tracepoint has to be used in kernel modules, an EXPORT_TRACEPOINT_SYMBOL_GPL() or EXPORT_TRACEPOINT_SYMBOL() can be used to export the defined tracepoints. +If you need to do a bit of work for a tracepoint parameter, and +that work is only used for the tracepoint, that work can be encapsulated +within an if statement with the following: + + if (trace_foo_bar_enabled()) { + int i; + int tot = 0; + + for (i = 0; i < count; i++) + tot += calculate_nuggets(); + + trace_foo_bar(tot); + } + +All trace_<tracepoint>() calls have a matching trace_<tracepoint>_enabled() +function defined that returns true if the tracepoint is enabled and +false otherwise. The trace_<tracepoint>() should always be within the +block of the if (trace_<tracepoint>_enabled()) to prevent races between +the tracepoint being enabled and the check being seen. + +The advantage of using the trace_<tracepoint>_enabled() is that it uses +the static_key of the tracepoint to allow the if statement to be implemented +with jump labels and avoid conditional branches. + Note: The convenience macro TRACE_EVENT provides an alternative way to define tracepoints. Check http://lwn.net/Articles/379903, http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362 diff --git a/Documentation/usb/chipidea.txt b/Documentation/usb/chipidea.txt new file mode 100644 index 0000000..995c8bc --- /dev/null +++ b/Documentation/usb/chipidea.txt @@ -0,0 +1,71 @@ +1. How to test OTG FSM(HNP and SRP) +----------------------------------- +To show how to demo OTG HNP and SRP functions via sys input files +with 2 Freescale i.MX6Q sabre SD boards. + +1.1 How to enable OTG FSM in menuconfig +--------------------------------------- +Select CONFIG_USB_OTG_FSM, rebuild kernel Image and modules. +If you want to check some internal variables for otg fsm, +select CONFIG_USB_CHIPIDEA_DEBUG, there are 2 files which +can show otg fsm variables and some controller registers value: +cat /sys/kernel/debug/ci_hdrc.0/otg +cat /sys/kernel/debug/ci_hdrc.0/registers + +1.2 Test operations +------------------- +1) Power up 2 Freescale i.MX6Q sabre SD boards with gadget class driver loaded + (e.g. g_mass_storage). + +2) Connect 2 boards with usb cable with one end is micro A plug, the other end + is micro B plug. + + The A-device(with micro A plug inserted) should enumrate B-device. + +3) Role switch + On B-device: + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + + if HNP polling is not supported, also need: + On A-device: + echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req + + B-device should take host role and enumrate A-device. + +4) A-device switch back to host. + On B-device: + echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + + A-device should switch back to host and enumrate B-device. + +5) Remove B-device(unplug micro B plug) and insert again in 10 seconds, + A-device should enumrate B-device again. + +6) Remove B-device(unplug micro B plug) and insert again after 10 seconds, + A-device should NOT enumrate B-device. + + if A-device wants to use bus: + On A-device: + echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req + + if B-device wants to use bus: + On B-device: + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + +7) A-device power down the bus. + On A-device: + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop + + A-device should disconnect with B-device and power down the bus. + +8) B-device does data pulse for SRP. + On B-device: + echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req + + A-device should resume usb bus and enumrate B-device. + +1.3 Reference document +---------------------- +"On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification +July 27, 2012 Revision 2.0 version 1.1a" diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt index 1392b61..7b90fe0 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/vDSO/parse_vdso.c b/Documentation/vDSO/parse_vdso.c index 8587020..1dbb4b8 100644 --- a/Documentation/vDSO/parse_vdso.c +++ b/Documentation/vDSO/parse_vdso.c @@ -1,6 +1,6 @@ /* * parse_vdso.c: Linux reference vDSO parser - * Written by Andrew Lutomirski, 2011. + * Written by Andrew Lutomirski, 2011-2014. * * This code is meant to be linked in to various programs that run on Linux. * As such, it is available with as few restrictions as possible. This file @@ -11,13 +11,14 @@ * it starts a program. It works equally well in statically and dynamically * linked binaries. * - * This code is tested on x86_64. In principle it should work on any 64-bit + * This code is tested on x86. In principle it should work on any * architecture that has a vDSO. */ #include <stdbool.h> #include <stdint.h> #include <string.h> +#include <limits.h> #include <elf.h> /* @@ -45,11 +46,18 @@ extern void *vdso_sym(const char *version, const char *name); /* And here's the code. */ - -#ifndef __x86_64__ -# error Not yet ported to non-x86_64 architectures +#ifndef ELF_BITS +# if ULONG_MAX > 0xffffffffUL +# define ELF_BITS 64 +# else +# define ELF_BITS 32 +# endif #endif +#define ELF_BITS_XFORM2(bits, x) Elf##bits##_##x +#define ELF_BITS_XFORM(bits, x) ELF_BITS_XFORM2(bits, x) +#define ELF(x) ELF_BITS_XFORM(ELF_BITS, x) + static struct vdso_info { bool valid; @@ -59,14 +67,14 @@ static struct vdso_info uintptr_t load_offset; /* load_addr - recorded vaddr */ /* Symbol table */ - Elf64_Sym *symtab; + ELF(Sym) *symtab; const char *symstrings; - Elf64_Word *bucket, *chain; - Elf64_Word nbucket, nchain; + ELF(Word) *bucket, *chain; + ELF(Word) nbucket, nchain; /* Version table */ - Elf64_Versym *versym; - Elf64_Verdef *verdef; + ELF(Versym) *versym; + ELF(Verdef) *verdef; } vdso_info; /* Straight from the ELF specification. */ @@ -92,9 +100,14 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base) vdso_info.load_addr = base; - Elf64_Ehdr *hdr = (Elf64_Ehdr*)base; - Elf64_Phdr *pt = (Elf64_Phdr*)(vdso_info.load_addr + hdr->e_phoff); - Elf64_Dyn *dyn = 0; + ELF(Ehdr) *hdr = (ELF(Ehdr)*)base; + if (hdr->e_ident[EI_CLASS] != + (ELF_BITS == 32 ? ELFCLASS32 : ELFCLASS64)) { + return; /* Wrong ELF class -- check ELF_BITS */ + } + + ELF(Phdr) *pt = (ELF(Phdr)*)(vdso_info.load_addr + hdr->e_phoff); + ELF(Dyn) *dyn = 0; /* * We need two things from the segment table: the load offset @@ -108,7 +121,7 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base) + (uintptr_t)pt[i].p_offset - (uintptr_t)pt[i].p_vaddr; } else if (pt[i].p_type == PT_DYNAMIC) { - dyn = (Elf64_Dyn*)(base + pt[i].p_offset); + dyn = (ELF(Dyn)*)(base + pt[i].p_offset); } } @@ -118,7 +131,7 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base) /* * Fish out the useful bits of the dynamic table. */ - Elf64_Word *hash = 0; + ELF(Word) *hash = 0; vdso_info.symstrings = 0; vdso_info.symtab = 0; vdso_info.versym = 0; @@ -131,22 +144,22 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base) + vdso_info.load_offset); break; case DT_SYMTAB: - vdso_info.symtab = (Elf64_Sym *) + vdso_info.symtab = (ELF(Sym) *) ((uintptr_t)dyn[i].d_un.d_ptr + vdso_info.load_offset); break; case DT_HASH: - hash = (Elf64_Word *) + hash = (ELF(Word) *) ((uintptr_t)dyn[i].d_un.d_ptr + vdso_info.load_offset); break; case DT_VERSYM: - vdso_info.versym = (Elf64_Versym *) + vdso_info.versym = (ELF(Versym) *) ((uintptr_t)dyn[i].d_un.d_ptr + vdso_info.load_offset); break; case DT_VERDEF: - vdso_info.verdef = (Elf64_Verdef *) + vdso_info.verdef = (ELF(Verdef) *) ((uintptr_t)dyn[i].d_un.d_ptr + vdso_info.load_offset); break; @@ -168,8 +181,8 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base) vdso_info.valid = true; } -static bool vdso_match_version(Elf64_Versym ver, - const char *name, Elf64_Word hash) +static bool vdso_match_version(ELF(Versym) ver, + const char *name, ELF(Word) hash) { /* * This is a helper function to check if the version indexed by @@ -188,7 +201,7 @@ static bool vdso_match_version(Elf64_Versym ver, /* First step: find the version definition */ ver &= 0x7fff; /* Apparently bit 15 means "hidden" */ - Elf64_Verdef *def = vdso_info.verdef; + ELF(Verdef) *def = vdso_info.verdef; while(true) { if ((def->vd_flags & VER_FLG_BASE) == 0 && (def->vd_ndx & 0x7fff) == ver) @@ -197,11 +210,11 @@ static bool vdso_match_version(Elf64_Versym ver, if (def->vd_next == 0) return false; /* No definition. */ - def = (Elf64_Verdef *)((char *)def + def->vd_next); + def = (ELF(Verdef) *)((char *)def + def->vd_next); } /* Now figure out whether it matches. */ - Elf64_Verdaux *aux = (Elf64_Verdaux*)((char *)def + def->vd_aux); + ELF(Verdaux) *aux = (ELF(Verdaux)*)((char *)def + def->vd_aux); return def->vd_hash == hash && !strcmp(name, vdso_info.symstrings + aux->vda_name); } @@ -213,10 +226,10 @@ void *vdso_sym(const char *version, const char *name) return 0; ver_hash = elf_hash(version); - Elf64_Word chain = vdso_info.bucket[elf_hash(name) % vdso_info.nbucket]; + ELF(Word) chain = vdso_info.bucket[elf_hash(name) % vdso_info.nbucket]; for (; chain != STN_UNDEF; chain = vdso_info.chain[chain]) { - Elf64_Sym *sym = &vdso_info.symtab[chain]; + ELF(Sym) *sym = &vdso_info.symtab[chain]; /* Check for a defined global or weak function w/ right name. */ if (ELF64_ST_TYPE(sym->st_info) != STT_FUNC) @@ -243,7 +256,7 @@ void *vdso_sym(const char *version, const char *name) void vdso_init_from_auxv(void *auxv) { - Elf64_auxv_t *elf_auxv = auxv; + ELF(auxv_t) *elf_auxv = auxv; for (int i = 0; elf_auxv[i].a_type != AT_NULL; i++) { if (elf_auxv[i].a_type == AT_SYSINFO_EHDR) { diff --git a/Documentation/vDSO/vdso_standalone_test_x86.c b/Documentation/vDSO/vdso_standalone_test_x86.c new file mode 100644 index 0000000..d462402 --- /dev/null +++ b/Documentation/vDSO/vdso_standalone_test_x86.c @@ -0,0 +1,128 @@ +/* + * vdso_test.c: Sample code to test parse_vdso.c on x86 + * Copyright (c) 2011-2014 Andy Lutomirski + * Subject to the GNU General Public License, version 2 + * + * You can amuse yourself by compiling with: + * gcc -std=gnu99 -nostdlib + * -Os -fno-asynchronous-unwind-tables -flto -lgcc_s + * vdso_standalone_test_x86.c parse_vdso.c + * to generate a small binary. On x86_64, you can omit -lgcc_s + * if you want the binary to be completely standalone. + */ + +#include <sys/syscall.h> +#include <sys/time.h> +#include <unistd.h> +#include <stdint.h> + +extern void *vdso_sym(const char *version, const char *name); +extern void vdso_init_from_sysinfo_ehdr(uintptr_t base); +extern void vdso_init_from_auxv(void *auxv); + +/* We need a libc functions... */ +int strcmp(const char *a, const char *b) +{ + /* This implementation is buggy: it never returns -1. */ + while (*a || *b) { + if (*a != *b) + return 1; + if (*a == 0 || *b == 0) + return 1; + a++; + b++; + } + + return 0; +} + +/* ...and two syscalls. This is x86-specific. */ +static inline long x86_syscall3(long nr, long a0, long a1, long a2) +{ + long ret; +#ifdef __x86_64__ + asm volatile ("syscall" : "=a" (ret) : "a" (nr), + "D" (a0), "S" (a1), "d" (a2) : + "cc", "memory", "rcx", + "r8", "r9", "r10", "r11" ); +#else + asm volatile ("int $0x80" : "=a" (ret) : "a" (nr), + "b" (a0), "c" (a1), "d" (a2) : + "cc", "memory" ); +#endif + return ret; +} + +static inline long linux_write(int fd, const void *data, size_t len) +{ + return x86_syscall3(__NR_write, fd, (long)data, (long)len); +} + +static inline void linux_exit(int code) +{ + x86_syscall3(__NR_exit, code, 0, 0); +} + +void to_base10(char *lastdig, uint64_t n) +{ + while (n) { + *lastdig = (n % 10) + '0'; + n /= 10; + lastdig--; + } +} + +__attribute__((externally_visible)) void c_main(void **stack) +{ + /* Parse the stack */ + long argc = (long)*stack; + stack += argc + 2; + + /* Now we're pointing at the environment. Skip it. */ + while(*stack) + stack++; + stack++; + + /* Now we're pointing at auxv. Initialize the vDSO parser. */ + vdso_init_from_auxv((void *)stack); + + /* Find gettimeofday. */ + typedef long (*gtod_t)(struct timeval *tv, struct timezone *tz); + gtod_t gtod = (gtod_t)vdso_sym("LINUX_2.6", "__vdso_gettimeofday"); + + if (!gtod) + linux_exit(1); + + struct timeval tv; + long ret = gtod(&tv, 0); + + if (ret == 0) { + char buf[] = "The time is .000000\n"; + to_base10(buf + 31, tv.tv_sec); + to_base10(buf + 38, tv.tv_usec); + linux_write(1, buf, sizeof(buf) - 1); + } else { + linux_exit(ret); + } + + linux_exit(0); +} + +/* + * This is the real entry point. It passes the initial stack into + * the C entry point. + */ +asm ( + ".text\n" + ".global _start\n" + ".type _start,@function\n" + "_start:\n\t" +#ifdef __x86_64__ + "mov %rsp,%rdi\n\t" + "jmp c_main" +#else + "push %esp\n\t" + "call c_main\n\t" + "int $3" +#endif + ); diff --git a/Documentation/vDSO/vdso_test.c b/Documentation/vDSO/vdso_test.c index fff6334..8daeb7d7 100644 --- a/Documentation/vDSO/vdso_test.c +++ b/Documentation/vDSO/vdso_test.c @@ -1,111 +1,52 @@ /* - * vdso_test.c: Sample code to test parse_vdso.c on x86_64 - * Copyright (c) 2011 Andy Lutomirski + * vdso_test.c: Sample code to test parse_vdso.c + * Copyright (c) 2014 Andy Lutomirski * Subject to the GNU General Public License, version 2 * - * You can amuse yourself by compiling with: - * gcc -std=gnu99 -nostdlib - * -Os -fno-asynchronous-unwind-tables -flto - * vdso_test.c parse_vdso.c -o vdso_test - * to generate a small binary with no dependencies at all. + * Compile with: + * gcc -std=gnu99 vdso_test.c parse_vdso.c + * + * Tested on x86, 32-bit and 64-bit. It may work on other architectures, too. */ -#include <sys/syscall.h> -#include <sys/time.h> -#include <unistd.h> #include <stdint.h> +#include <elf.h> +#include <stdio.h> +#include <sys/auxv.h> +#include <sys/time.h> extern void *vdso_sym(const char *version, const char *name); extern void vdso_init_from_sysinfo_ehdr(uintptr_t base); extern void vdso_init_from_auxv(void *auxv); -/* We need a libc functions... */ -int strcmp(const char *a, const char *b) +int main(int argc, char **argv) { - /* This implementation is buggy: it never returns -1. */ - while (*a || *b) { - if (*a != *b) - return 1; - if (*a == 0 || *b == 0) - return 1; - a++; - b++; + unsigned long sysinfo_ehdr = getauxval(AT_SYSINFO_EHDR); + if (!sysinfo_ehdr) { + printf("AT_SYSINFO_EHDR is not present!\n"); + return 0; } - return 0; -} - -/* ...and two syscalls. This is x86_64-specific. */ -static inline long linux_write(int fd, const void *data, size_t len) -{ - - long ret; - asm volatile ("syscall" : "=a" (ret) : "a" (__NR_write), - "D" (fd), "S" (data), "d" (len) : - "cc", "memory", "rcx", - "r8", "r9", "r10", "r11" ); - return ret; -} - -static inline void linux_exit(int code) -{ - asm volatile ("syscall" : : "a" (__NR_exit), "D" (code)); -} - -void to_base10(char *lastdig, uint64_t n) -{ - while (n) { - *lastdig = (n % 10) + '0'; - n /= 10; - lastdig--; - } -} - -__attribute__((externally_visible)) void c_main(void **stack) -{ - /* Parse the stack */ - long argc = (long)*stack; - stack += argc + 2; - - /* Now we're pointing at the environment. Skip it. */ - while(*stack) - stack++; - stack++; - - /* Now we're pointing at auxv. Initialize the vDSO parser. */ - vdso_init_from_auxv((void *)stack); + vdso_init_from_sysinfo_ehdr(getauxval(AT_SYSINFO_EHDR)); /* Find gettimeofday. */ typedef long (*gtod_t)(struct timeval *tv, struct timezone *tz); gtod_t gtod = (gtod_t)vdso_sym("LINUX_2.6", "__vdso_gettimeofday"); - if (!gtod) - linux_exit(1); + if (!gtod) { + printf("Could not find __vdso_gettimeofday\n"); + return 1; + } struct timeval tv; long ret = gtod(&tv, 0); if (ret == 0) { - char buf[] = "The time is .000000\n"; - to_base10(buf + 31, tv.tv_sec); - to_base10(buf + 38, tv.tv_usec); - linux_write(1, buf, sizeof(buf) - 1); + printf("The time is %lld.%06lld\n", + (long long)tv.tv_sec, (long long)tv.tv_usec); } else { - linux_exit(ret); + printf("__vdso_gettimeofday failed\n"); } - linux_exit(0); + return 0; } - -/* - * This is the real entry point. It passes the initial stack into - * the C entry point. - */ -asm ( - ".text\n" - ".global _start\n" - ".type _start,@function\n" - "_start:\n\t" - "mov %rsp,%rdi\n\t" - "jmp c_main" - ); diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv index f144750..b092c0a 100644 --- a/Documentation/video4linux/CARDLIST.bttv +++ b/Documentation/video4linux/CARDLIST.bttv @@ -163,3 +163,5 @@ 162 -> Adlink MPG24 163 -> Bt848 Capture 14MHz 164 -> CyberVision CV06 (SV) +165 -> Kworld V-Stream Xpert TV PVR878 +166 -> PCI-8604PW diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 9f056d5..a74eecc 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 @@ -31,10 +31,15 @@ 30 -> NetUP Dual DVB-T/C-CI RF [1b55:e2e4] 31 -> Leadtek Winfast PxDVR3200 H XC4000 [107d:6f39] 32 -> MPX-885 - 33 -> Mygica X8507 [14f1:8502] + 33 -> Mygica X8502/X8507 ISDB-T [14f1:8502] 34 -> TerraTec Cinergy T PCIe Dual [153b:117e] 35 -> TeVii S471 [d471:9022] 36 -> Hauppauge WinTV-HVR1255 [0070:2259] 37 -> Prof Revolution DVB-S2 8000 [8000:3034] 38 -> Hauppauge WinTV-HVR4400 [0070:c108,0070:c138,0070:c12a,0070:c1f8] 39 -> AVerTV Hybrid Express Slim HC81R [1461:d939] + 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 e818644..bc3351b 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -57,6 +57,7 @@ 56 -> Pinnacle Hybrid Pro (330e) (em2882) [2304:0226] 57 -> Kworld PlusTV HD Hybrid 330 (em2883) [eb1a:a316] 58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041] + 59 -> Pinnacle PCTV HD Mini (em2874) [2304:023f] 60 -> Hauppauge WinTV HVR 850 (em2883) [2040:651f] 61 -> Pixelview PlayTV Box 4 USB 2.0 (em2820/em2840) 62 -> Gadmei TVR200 (em2820/em2840) @@ -76,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] @@ -86,3 +87,9 @@ 86 -> PCTV QuatroStick nano (520e) (em2884) [2013:0251] 87 -> Terratec Cinergy HTC USB XS (em2884) [0ccd:008e,0ccd:00ac] 88 -> C3 Tech Digital Duo HDTV/SDTV USB (em2884) [1b80:e755] + 89 -> Delock 61959 (em2874) [1b80:e1cc] + 90 -> KWorld USB ATSC TV Stick UB435-Q V2 (em2874) [1b80:e346] + 91 -> SpeedLink Vicious And Devine Laplace webcam (em2765) [1ae7:9003,1ae7:9004] + 92 -> PCTV DVB-S2 Stick (461e) (em28178) + 93 -> KWorld USB ATSC TV Stick UB435-Q V3 (em2874) [1b80:e34c] + 94 -> PCTV tripleStick (292e) (em28178) diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt index e51f1b5..e0c6b8b 100644 --- a/Documentation/video4linux/fimc.txt +++ b/Documentation/video4linux/fimc.txt @@ -140,40 +140,9 @@ You can either grep through the kernel log to find relevant information, i.e. or retrieve the information from /dev/media? with help of the media-ctl tool: # media-ctl -p -6. Platform support -=================== - -The machine code (arch/arm/plat-samsung and arch/arm/mach-*) must select -following options: - -CONFIG_S5P_DEV_FIMC0 mandatory -CONFIG_S5P_DEV_FIMC1 \ -CONFIG_S5P_DEV_FIMC2 | optional -CONFIG_S5P_DEV_FIMC3 | -CONFIG_S5P_SETUP_FIMC / -CONFIG_S5P_SETUP_MIPIPHY \ -CONFIG_S5P_DEV_CSIS0 | optional for MIPI-CSI interface -CONFIG_S5P_DEV_CSIS1 / - -Except that, relevant s5p_device_fimc? should be registered in the machine code -in addition to a "s5p-fimc-md" platform device to which the media device driver -is bound. The "s5p-fimc-md" device instance is required even if only mem-to-mem -operation is used. - -The description of sensor(s) attached to FIMC/MIPI-CSIS camera inputs should be -passed as the "s5p-fimc-md" device platform_data. The platform data structure -is defined in file include/media/s5p_fimc.h. - 7. Build ======== -This driver depends on following config options: -PLAT_S5P, -PM_RUNTIME, -I2C, -REGULATOR, -VIDEO_V4L2_SUBDEV_API, - If the driver is built as a loadable kernel module (CONFIG_VIDEO_SAMSUNG_S5P_FIMC=m) two modules are created (in addition to the core v4l2 modules): s5p-fimc.ko and optional s5p-csis.ko (MIPI-CSI receiver subdev). diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 1e6b653..d2ba80b 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -55,6 +55,7 @@ zc3xx 0458:700f Genius VideoCam Web V2 sonixj 0458:7025 Genius Eye 311Q sn9c20x 0458:7029 Genius Look 320s sonixj 0458:702e Genius Slim 310 NB +sn9c20x 0458:7045 Genius Look 1320 V2 sn9c20x 0458:704a Genius Slim 1320 sn9c20x 0458:704c Genius i-Look 1321 sn9c20x 045e:00f4 LifeCam VX-6000 (SN9C20x + OV9650) diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt index 06cf3ac..0f84ce8 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 6c4866b..a11dff0 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -34,6 +34,10 @@ So this framework sets up the basic building blocks that all drivers need and this same framework should make it much easier to refactor common code into utility functions shared by all drivers. +A good example to look at as a reference is the v4l2-pci-skeleton.c +source that is available in this directory. It is a skeleton driver for +a PCI capture card, and demonstrates how to use the V4L2 driver +framework. It can be used as a template for real PCI video capture driver. Structure of a driver --------------------- @@ -671,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. @@ -768,6 +767,7 @@ types exist: VFL_TYPE_GRABBER: videoX for video input/output devices VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext) VFL_TYPE_RADIO: radioX for radio tuners +VFL_TYPE_SDR: swradioX for Software Defined Radio tuners The last argument gives you a certain amount of control over the device device node number used (i.e. the X in videoX). Normally you will pass -1 @@ -904,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 new file mode 100644 index 0000000..006721e --- /dev/null +++ b/Documentation/video4linux/v4l2-pci-skeleton.c @@ -0,0 +1,924 @@ +/* + * This is a V4L2 PCI Skeleton Driver. It gives an initial skeleton source + * for use with other PCI drivers. + * + * This skeleton PCI driver assumes that the card has an S-Video connector as + * input 0 and an HDMI connector as input 1. + * + * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights reserved. + * + * This program is free software; you may redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. + */ + +#include <linux/types.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/init.h> +#include <linux/kmod.h> +#include <linux/mutex.h> +#include <linux/pci.h> +#include <linux/interrupt.h> +#include <linux/videodev2.h> +#include <linux/v4l2-dv-timings.h> +#include <media/v4l2-device.h> +#include <media/v4l2-dev.h> +#include <media/v4l2-ioctl.h> +#include <media/v4l2-dv-timings.h> +#include <media/v4l2-ctrls.h> +#include <media/v4l2-event.h> +#include <media/videobuf2-dma-contig.h> + +MODULE_DESCRIPTION("V4L2 PCI Skeleton Driver"); +MODULE_AUTHOR("Hans Verkuil"); +MODULE_LICENSE("GPL v2"); +MODULE_DEVICE_TABLE(pci, skeleton_pci_tbl); + +/** + * struct skeleton - All internal data for one instance of device + * @pdev: PCI device + * @v4l2_dev: top-level v4l2 device struct + * @vdev: video node structure + * @ctrl_handler: control handler structure + * @lock: ioctl serialization mutex + * @std: current SDTV standard + * @timings: current HDTV timings + * @format: current pix format + * @input: current video input (0 = SDTV, 1 = HDTV) + * @queue: vb2 video capture queue + * @alloc_ctx: vb2 contiguous DMA context + * @qlock: spinlock controlling access to buf_list and sequence + * @buf_list: list of buffers queued for DMA + * @sequence: frame sequence counter + */ +struct skeleton { + struct pci_dev *pdev; + struct v4l2_device v4l2_dev; + struct video_device vdev; + struct v4l2_ctrl_handler ctrl_handler; + struct mutex lock; + v4l2_std_id std; + struct v4l2_dv_timings timings; + struct v4l2_pix_format format; + unsigned input; + + struct vb2_queue queue; + struct vb2_alloc_ctx *alloc_ctx; + + spinlock_t qlock; + struct list_head buf_list; + unsigned field; + unsigned sequence; +}; + +struct skel_buffer { + struct vb2_buffer vb; + struct list_head list; +}; + +static inline struct skel_buffer *to_skel_buffer(struct vb2_buffer *vb2) +{ + return container_of(vb2, struct skel_buffer, vb); +} + +static const struct pci_device_id skeleton_pci_tbl[] = { + /* { PCI_DEVICE(PCI_VENDOR_ID_, PCI_DEVICE_ID_) }, */ + { 0, } +}; + +/* + * HDTV: this structure has the capabilities of the HDTV receiver. + * It is used to constrain the huge list of possible formats based + * upon the hardware capabilities. + */ +static const struct v4l2_dv_timings_cap skel_timings_cap = { + .type = V4L2_DV_BT_656_1120, + /* keep this initialization for compatibility with GCC < 4.4.6 */ + .reserved = { 0 }, + V4L2_INIT_BT_TIMINGS( + 720, 1920, /* min/max width */ + 480, 1080, /* min/max height */ + 27000000, 74250000, /* min/max pixelclock*/ + V4L2_DV_BT_STD_CEA861, /* Supported standards */ + /* capabilities */ + V4L2_DV_BT_CAP_INTERLACED | V4L2_DV_BT_CAP_PROGRESSIVE + ) +}; + +/* + * Supported SDTV standards. This does the same job as skel_timings_cap, but + * for standard TV formats. + */ +#define SKEL_TVNORMS V4L2_STD_ALL + +/* + * Interrupt handler: typically interrupts happen after a new frame has been + * captured. It is the job of the handler to remove the new frame from the + * internal list and give it back to the vb2 framework, updating the sequence + * counter, field and timestamp at the same time. + */ +static irqreturn_t skeleton_irq(int irq, void *dev_id) +{ +#ifdef TODO + struct skeleton *skel = dev_id; + + /* handle interrupt */ + + /* Once a new frame has been captured, mark it as done like this: */ + if (captured_new_frame) { + ... + spin_lock(&skel->qlock); + list_del(&new_buf->list); + spin_unlock(&skel->qlock); + v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp); + new_buf->vb.v4l2_buf.sequence = skel->sequence++; + new_buf->vb.v4l2_buf.field = skel->field; + if (skel->format.field == V4L2_FIELD_ALTERNATE) { + if (skel->field == V4L2_FIELD_BOTTOM) + skel->field = V4L2_FIELD_TOP; + else if (skel->field == V4L2_FIELD_TOP) + skel->field = V4L2_FIELD_BOTTOM; + } + vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_DONE); + } +#endif + return IRQ_HANDLED; +} + +/* + * Setup the constraints of the queue: besides setting the number of planes + * per buffer and the size and allocation context of each plane, it also + * checks if sufficient buffers have been allocated. Usually 3 is a good + * minimum number: many DMA engines need a minimum of 2 buffers in the + * queue and you need to have another available for userspace processing. + */ +static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt, + unsigned int *nbuffers, unsigned int *nplanes, + unsigned int sizes[], void *alloc_ctxs[]) +{ + struct skeleton *skel = vb2_get_drv_priv(vq); + + skel->field = skel->format.field; + if (skel->field == V4L2_FIELD_ALTERNATE) { + /* + * You cannot use read() with FIELD_ALTERNATE since the field + * information (TOP/BOTTOM) cannot be passed back to the user. + */ + if (vb2_fileio_is_active(vq)) + return -EINVAL; + skel->field = V4L2_FIELD_TOP; + } + + if (vq->num_buffers + *nbuffers < 3) + *nbuffers = 3 - vq->num_buffers; + + if (fmt && fmt->fmt.pix.sizeimage < skel->format.sizeimage) + return -EINVAL; + *nplanes = 1; + sizes[0] = fmt ? fmt->fmt.pix.sizeimage : skel->format.sizeimage; + alloc_ctxs[0] = skel->alloc_ctx; + return 0; +} + +/* + * Prepare the buffer for queueing to the DMA engine: check and set the + * payload size. + */ +static int buffer_prepare(struct vb2_buffer *vb) +{ + struct skeleton *skel = vb2_get_drv_priv(vb->vb2_queue); + unsigned long size = skel->format.sizeimage; + + if (vb2_plane_size(vb, 0) < size) { + dev_err(&skel->pdev->dev, "buffer too small (%lu < %lu)\n", + vb2_plane_size(vb, 0), size); + return -EINVAL; + } + + vb2_set_plane_payload(vb, 0, size); + return 0; +} + +/* + * Queue this buffer to the DMA engine. + */ +static void buffer_queue(struct vb2_buffer *vb) +{ + struct skeleton *skel = vb2_get_drv_priv(vb->vb2_queue); + struct skel_buffer *buf = to_skel_buffer(vb); + unsigned long flags; + + spin_lock_irqsave(&skel->qlock, flags); + list_add_tail(&buf->list, &skel->buf_list); + + /* TODO: Update any DMA pointers if necessary */ + + spin_unlock_irqrestore(&skel->qlock, flags); +} + +static void return_all_buffers(struct skeleton *skel, + enum vb2_buffer_state state) +{ + struct skel_buffer *buf, *node; + unsigned long flags; + + spin_lock_irqsave(&skel->qlock, flags); + list_for_each_entry_safe(buf, node, &skel->buf_list, list) { + vb2_buffer_done(&buf->vb, state); + list_del(&buf->list); + } + spin_unlock_irqrestore(&skel->qlock, flags); +} + +/* + * Start streaming. First check if the minimum number of buffers have been + * queued. If not, then return -ENOBUFS and the vb2 framework will call + * this function again the next time a buffer has been queued until enough + * buffers are available to actually start the DMA engine. + */ +static int start_streaming(struct vb2_queue *vq, unsigned int count) +{ + struct skeleton *skel = vb2_get_drv_priv(vq); + int ret = 0; + + skel->sequence = 0; + + /* TODO: start DMA */ + + if (ret) { + /* + * In case of an error, return all active buffers to the + * QUEUED state + */ + return_all_buffers(skel, VB2_BUF_STATE_QUEUED); + } + return ret; +} + +/* + * Stop the DMA engine. Any remaining buffers in the DMA queue are dequeued + * and passed on to the vb2 framework marked as STATE_ERROR. + */ +static void stop_streaming(struct vb2_queue *vq) +{ + struct skeleton *skel = vb2_get_drv_priv(vq); + + /* TODO: stop DMA */ + + /* Release all active buffers */ + return_all_buffers(skel, VB2_BUF_STATE_ERROR); +} + +/* + * The vb2 queue ops. Note that since q->lock is set we can use the standard + * vb2_ops_wait_prepare/finish helper functions. If q->lock would be NULL, + * then this driver would have to provide these ops. + */ +static struct vb2_ops skel_qops = { + .queue_setup = queue_setup, + .buf_prepare = buffer_prepare, + .buf_queue = buffer_queue, + .start_streaming = start_streaming, + .stop_streaming = stop_streaming, + .wait_prepare = vb2_ops_wait_prepare, + .wait_finish = vb2_ops_wait_finish, +}; + +/* + * Required ioctl querycap. Note that the version field is prefilled with + * the version of the kernel. + */ +static int skeleton_querycap(struct file *file, void *priv, + struct v4l2_capability *cap) +{ + struct skeleton *skel = video_drvdata(file); + + strlcpy(cap->driver, KBUILD_MODNAME, sizeof(cap->driver)); + strlcpy(cap->card, "V4L2 PCI Skeleton", sizeof(cap->card)); + snprintf(cap->bus_info, sizeof(cap->bus_info), "PCI:%s", + pci_name(skel->pdev)); + cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_READWRITE | + V4L2_CAP_STREAMING; + cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS; + return 0; +} + +/* + * Helper function to check and correct struct v4l2_pix_format. It's used + * not only in VIDIOC_TRY/S_FMT, but also elsewhere if changes to the SDTV + * standard, HDTV timings or the video input would require updating the + * current format. + */ +static void skeleton_fill_pix_format(struct skeleton *skel, + struct v4l2_pix_format *pix) +{ + pix->pixelformat = V4L2_PIX_FMT_YUYV; + if (skel->input == 0) { + /* S-Video input */ + pix->width = 720; + pix->height = (skel->std & V4L2_STD_525_60) ? 480 : 576; + pix->field = V4L2_FIELD_INTERLACED; + pix->colorspace = V4L2_COLORSPACE_SMPTE170M; + } else { + /* HDMI input */ + pix->width = skel->timings.bt.width; + pix->height = skel->timings.bt.height; + if (skel->timings.bt.interlaced) { + pix->field = V4L2_FIELD_ALTERNATE; + pix->height /= 2; + } else { + pix->field = V4L2_FIELD_NONE; + } + pix->colorspace = V4L2_COLORSPACE_REC709; + } + + /* + * The YUYV format is four bytes for every two pixels, so bytesperline + * is width * 2. + */ + pix->bytesperline = pix->width * 2; + pix->sizeimage = pix->bytesperline * pix->height; + pix->priv = 0; +} + +static int skeleton_try_fmt_vid_cap(struct file *file, void *priv, + struct v4l2_format *f) +{ + struct skeleton *skel = video_drvdata(file); + struct v4l2_pix_format *pix = &f->fmt.pix; + + /* + * Due to historical reasons providing try_fmt with an unsupported + * pixelformat will return -EINVAL for video receivers. Webcam drivers, + * however, will silently correct the pixelformat. Some video capture + * applications rely on this behavior... + */ + if (pix->pixelformat != V4L2_PIX_FMT_YUYV) + return -EINVAL; + skeleton_fill_pix_format(skel, pix); + return 0; +} + +static int skeleton_s_fmt_vid_cap(struct file *file, void *priv, + struct v4l2_format *f) +{ + struct skeleton *skel = video_drvdata(file); + int ret; + + ret = skeleton_try_fmt_vid_cap(file, priv, f); + if (ret) + return ret; + + /* + * It is not allowed to change the format while buffers for use with + * streaming have already been allocated. + */ + if (vb2_is_busy(&skel->queue)) + return -EBUSY; + + /* TODO: change format */ + skel->format = f->fmt.pix; + return 0; +} + +static int skeleton_g_fmt_vid_cap(struct file *file, void *priv, + struct v4l2_format *f) +{ + struct skeleton *skel = video_drvdata(file); + + f->fmt.pix = skel->format; + return 0; +} + +static int skeleton_enum_fmt_vid_cap(struct file *file, void *priv, + struct v4l2_fmtdesc *f) +{ + if (f->index != 0) + return -EINVAL; + + strlcpy(f->description, "4:2:2, packed, YUYV", sizeof(f->description)); + f->pixelformat = V4L2_PIX_FMT_YUYV; + f->flags = 0; + return 0; +} + +static int skeleton_s_std(struct file *file, void *priv, v4l2_std_id std) +{ + struct skeleton *skel = video_drvdata(file); + + /* S_STD is not supported on the HDMI input */ + if (skel->input) + return -ENODATA; + + /* + * No change, so just return. Some applications call S_STD again after + * the buffers for streaming have been set up, so we have to allow for + * this behavior. + */ + if (std == skel->std) + return 0; + + /* + * Changing the standard implies a format change, which is not allowed + * while buffers for use with streaming have already been allocated. + */ + if (vb2_is_busy(&skel->queue)) + return -EBUSY; + + /* TODO: handle changing std */ + + skel->std = std; + + /* Update the internal format */ + skeleton_fill_pix_format(skel, &skel->format); + return 0; +} + +static int skeleton_g_std(struct file *file, void *priv, v4l2_std_id *std) +{ + struct skeleton *skel = video_drvdata(file); + + /* G_STD is not supported on the HDMI input */ + if (skel->input) + return -ENODATA; + + *std = skel->std; + return 0; +} + +/* + * Query the current standard as seen by the hardware. This function shall + * never actually change the standard, it just detects and reports. + * The framework will initially set *std to tvnorms (i.e. the set of + * supported standards by this input), and this function should just AND + * this value. If there is no signal, then *std should be set to 0. + */ +static int skeleton_querystd(struct file *file, void *priv, v4l2_std_id *std) +{ + struct skeleton *skel = video_drvdata(file); + + /* QUERY_STD is not supported on the HDMI input */ + if (skel->input) + return -ENODATA; + +#ifdef TODO + /* + * Query currently seen standard. Initial value of *std is + * V4L2_STD_ALL. This function should look something like this: + */ + get_signal_info(); + if (no_signal) { + *std = 0; + return 0; + } + /* Use signal information to reduce the number of possible standards */ + if (signal_has_525_lines) + *std &= V4L2_STD_525_60; + else + *std &= V4L2_STD_625_50; +#endif + return 0; +} + +static int skeleton_s_dv_timings(struct file *file, void *_fh, + struct v4l2_dv_timings *timings) +{ + struct skeleton *skel = video_drvdata(file); + + /* S_DV_TIMINGS is not supported on the S-Video input */ + if (skel->input == 0) + return -ENODATA; + + /* Quick sanity check */ + if (!v4l2_valid_dv_timings(timings, &skel_timings_cap, NULL, NULL)) + return -EINVAL; + + /* Check if the timings are part of the CEA-861 timings. */ + if (!v4l2_find_dv_timings_cap(timings, &skel_timings_cap, + 0, NULL, NULL)) + return -EINVAL; + + /* Return 0 if the new timings are the same as the current timings. */ + if (v4l2_match_dv_timings(timings, &skel->timings, 0)) + return 0; + + /* + * Changing the timings implies a format change, which is not allowed + * while buffers for use with streaming have already been allocated. + */ + if (vb2_is_busy(&skel->queue)) + return -EBUSY; + + /* TODO: Configure new timings */ + + /* Save timings */ + skel->timings = *timings; + + /* Update the internal format */ + skeleton_fill_pix_format(skel, &skel->format); + return 0; +} + +static int skeleton_g_dv_timings(struct file *file, void *_fh, + struct v4l2_dv_timings *timings) +{ + struct skeleton *skel = video_drvdata(file); + + /* G_DV_TIMINGS is not supported on the S-Video input */ + if (skel->input == 0) + return -ENODATA; + + *timings = skel->timings; + return 0; +} + +static int skeleton_enum_dv_timings(struct file *file, void *_fh, + struct v4l2_enum_dv_timings *timings) +{ + struct skeleton *skel = video_drvdata(file); + + /* ENUM_DV_TIMINGS is not supported on the S-Video input */ + if (skel->input == 0) + return -ENODATA; + + return v4l2_enum_dv_timings_cap(timings, &skel_timings_cap, + NULL, NULL); +} + +/* + * Query the current timings as seen by the hardware. This function shall + * never actually change the timings, it just detects and reports. + * If no signal is detected, then return -ENOLINK. If the hardware cannot + * lock to the signal, then return -ENOLCK. If the signal is out of range + * of the capabilities of the system (e.g., it is possible that the receiver + * can lock but that the DMA engine it is connected to cannot handle + * pixelclocks above a certain frequency), then -ERANGE is returned. + */ +static int skeleton_query_dv_timings(struct file *file, void *_fh, + struct v4l2_dv_timings *timings) +{ + struct skeleton *skel = video_drvdata(file); + + /* QUERY_DV_TIMINGS is not supported on the S-Video input */ + if (skel->input == 0) + return -ENODATA; + +#ifdef TODO + /* + * Query currently seen timings. This function should look + * something like this: + */ + detect_timings(); + if (no_signal) + return -ENOLINK; + if (cannot_lock_to_signal) + return -ENOLCK; + if (signal_out_of_range_of_capabilities) + return -ERANGE; + + /* Useful for debugging */ + v4l2_print_dv_timings(skel->v4l2_dev.name, "query_dv_timings:", + timings, true); +#endif + return 0; +} + +static int skeleton_dv_timings_cap(struct file *file, void *fh, + struct v4l2_dv_timings_cap *cap) +{ + struct skeleton *skel = video_drvdata(file); + + /* DV_TIMINGS_CAP is not supported on the S-Video input */ + if (skel->input == 0) + return -ENODATA; + *cap = skel_timings_cap; + return 0; +} + +static int skeleton_enum_input(struct file *file, void *priv, + struct v4l2_input *i) +{ + if (i->index > 1) + return -EINVAL; + + i->type = V4L2_INPUT_TYPE_CAMERA; + if (i->index == 0) { + i->std = SKEL_TVNORMS; + strlcpy(i->name, "S-Video", sizeof(i->name)); + i->capabilities = V4L2_IN_CAP_STD; + } else { + i->std = 0; + strlcpy(i->name, "HDMI", sizeof(i->name)); + i->capabilities = V4L2_IN_CAP_DV_TIMINGS; + } + return 0; +} + +static int skeleton_s_input(struct file *file, void *priv, unsigned int i) +{ + struct skeleton *skel = video_drvdata(file); + + if (i > 1) + return -EINVAL; + + /* + * Changing the input implies a format change, which is not allowed + * while buffers for use with streaming have already been allocated. + */ + if (vb2_is_busy(&skel->queue)) + return -EBUSY; + + skel->input = i; + /* + * Update tvnorms. The tvnorms value is used by the core to implement + * VIDIOC_ENUMSTD so it has to be correct. If tvnorms == 0, then + * ENUMSTD will return -ENODATA. + */ + skel->vdev.tvnorms = i ? 0 : SKEL_TVNORMS; + + /* Update the internal format */ + skeleton_fill_pix_format(skel, &skel->format); + return 0; +} + +static int skeleton_g_input(struct file *file, void *priv, unsigned int *i) +{ + struct skeleton *skel = video_drvdata(file); + + *i = skel->input; + return 0; +} + +/* The control handler. */ +static int skeleton_s_ctrl(struct v4l2_ctrl *ctrl) +{ + /*struct skeleton *skel = + container_of(ctrl->handler, struct skeleton, ctrl_handler);*/ + + switch (ctrl->id) { + case V4L2_CID_BRIGHTNESS: + /* TODO: set brightness to ctrl->val */ + break; + case V4L2_CID_CONTRAST: + /* TODO: set contrast to ctrl->val */ + break; + case V4L2_CID_SATURATION: + /* TODO: set saturation to ctrl->val */ + break; + case V4L2_CID_HUE: + /* TODO: set hue to ctrl->val */ + break; + default: + return -EINVAL; + } + return 0; +} + +/* ------------------------------------------------------------------ + File operations for the device + ------------------------------------------------------------------*/ + +static const struct v4l2_ctrl_ops skel_ctrl_ops = { + .s_ctrl = skeleton_s_ctrl, +}; + +/* + * The set of all supported ioctls. Note that all the streaming ioctls + * use the vb2 helper functions that take care of all the locking and + * that also do ownership tracking (i.e. only the filehandle that requested + * the buffers can call the streaming ioctls, all other filehandles will + * receive -EBUSY if they attempt to call the same streaming ioctls). + * + * The last three ioctls also use standard helper functions: these implement + * standard behavior for drivers with controls. + */ +static const struct v4l2_ioctl_ops skel_ioctl_ops = { + .vidioc_querycap = skeleton_querycap, + .vidioc_try_fmt_vid_cap = skeleton_try_fmt_vid_cap, + .vidioc_s_fmt_vid_cap = skeleton_s_fmt_vid_cap, + .vidioc_g_fmt_vid_cap = skeleton_g_fmt_vid_cap, + .vidioc_enum_fmt_vid_cap = skeleton_enum_fmt_vid_cap, + + .vidioc_g_std = skeleton_g_std, + .vidioc_s_std = skeleton_s_std, + .vidioc_querystd = skeleton_querystd, + + .vidioc_s_dv_timings = skeleton_s_dv_timings, + .vidioc_g_dv_timings = skeleton_g_dv_timings, + .vidioc_enum_dv_timings = skeleton_enum_dv_timings, + .vidioc_query_dv_timings = skeleton_query_dv_timings, + .vidioc_dv_timings_cap = skeleton_dv_timings_cap, + + .vidioc_enum_input = skeleton_enum_input, + .vidioc_g_input = skeleton_g_input, + .vidioc_s_input = skeleton_s_input, + + .vidioc_reqbufs = vb2_ioctl_reqbufs, + .vidioc_create_bufs = vb2_ioctl_create_bufs, + .vidioc_querybuf = vb2_ioctl_querybuf, + .vidioc_qbuf = vb2_ioctl_qbuf, + .vidioc_dqbuf = vb2_ioctl_dqbuf, + .vidioc_expbuf = vb2_ioctl_expbuf, + .vidioc_streamon = vb2_ioctl_streamon, + .vidioc_streamoff = vb2_ioctl_streamoff, + + .vidioc_log_status = v4l2_ctrl_log_status, + .vidioc_subscribe_event = v4l2_ctrl_subscribe_event, + .vidioc_unsubscribe_event = v4l2_event_unsubscribe, +}; + +/* + * The set of file operations. Note that all these ops are standard core + * helper functions. + */ +static const struct v4l2_file_operations skel_fops = { + .owner = THIS_MODULE, + .open = v4l2_fh_open, + .release = vb2_fop_release, + .unlocked_ioctl = video_ioctl2, + .read = vb2_fop_read, + .mmap = vb2_fop_mmap, + .poll = vb2_fop_poll, +}; + +/* + * The initial setup of this device instance. Note that the initial state of + * the driver should be complete. So the initial format, standard, timings + * and video input should all be initialized to some reasonable value. + */ +static int skeleton_probe(struct pci_dev *pdev, const struct pci_device_id *ent) +{ + /* The initial timings are chosen to be 720p60. */ + static const struct v4l2_dv_timings timings_def = + V4L2_DV_BT_CEA_1280X720P60; + struct skeleton *skel; + struct video_device *vdev; + struct v4l2_ctrl_handler *hdl; + struct vb2_queue *q; + int ret; + + /* Enable PCI */ + ret = pci_enable_device(pdev); + if (ret) + return ret; + ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(32)); + if (ret) { + dev_err(&pdev->dev, "no suitable DMA available.\n"); + goto disable_pci; + } + + /* Allocate a new instance */ + skel = devm_kzalloc(&pdev->dev, sizeof(struct skeleton), GFP_KERNEL); + if (!skel) + return -ENOMEM; + + /* Allocate the interrupt */ + ret = devm_request_irq(&pdev->dev, pdev->irq, + skeleton_irq, 0, KBUILD_MODNAME, skel); + if (ret) { + dev_err(&pdev->dev, "request_irq failed\n"); + goto disable_pci; + } + skel->pdev = pdev; + + /* Fill in the initial format-related settings */ + skel->timings = timings_def; + skel->std = V4L2_STD_625_50; + skeleton_fill_pix_format(skel, &skel->format); + + /* Initialize the top-level structure */ + ret = v4l2_device_register(&pdev->dev, &skel->v4l2_dev); + if (ret) + goto disable_pci; + + mutex_init(&skel->lock); + + /* Add the controls */ + hdl = &skel->ctrl_handler; + v4l2_ctrl_handler_init(hdl, 4); + v4l2_ctrl_new_std(hdl, &skel_ctrl_ops, + V4L2_CID_BRIGHTNESS, 0, 255, 1, 127); + v4l2_ctrl_new_std(hdl, &skel_ctrl_ops, + V4L2_CID_CONTRAST, 0, 255, 1, 16); + v4l2_ctrl_new_std(hdl, &skel_ctrl_ops, + V4L2_CID_SATURATION, 0, 255, 1, 127); + v4l2_ctrl_new_std(hdl, &skel_ctrl_ops, + V4L2_CID_HUE, -128, 127, 1, 0); + if (hdl->error) { + ret = hdl->error; + goto free_hdl; + } + skel->v4l2_dev.ctrl_handler = hdl; + + /* Initialize the vb2 queue */ + q = &skel->queue; + q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + q->io_modes = VB2_MMAP | VB2_DMABUF | VB2_READ; + q->drv_priv = skel; + q->buf_struct_size = sizeof(struct skel_buffer); + q->ops = &skel_qops; + q->mem_ops = &vb2_dma_contig_memops; + q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; + /* + * Assume that this DMA engine needs to have at least two buffers + * available before it can be started. The start_streaming() op + * won't be called until at least this many buffers are queued up. + */ + q->min_buffers_needed = 2; + /* + * The serialization lock for the streaming ioctls. This is the same + * as the main serialization lock, but if some of the non-streaming + * ioctls could take a long time to execute, then you might want to + * have a different lock here to prevent VIDIOC_DQBUF from being + * blocked while waiting for another action to finish. This is + * generally not needed for PCI devices, but USB devices usually do + * want a separate lock here. + */ + q->lock = &skel->lock; + /* + * Since this driver can only do 32-bit DMA we must make sure that + * the vb2 core will allocate the buffers in 32-bit DMA memory. + */ + q->gfp_flags = GFP_DMA32; + ret = vb2_queue_init(q); + if (ret) + goto free_hdl; + + skel->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev); + if (IS_ERR(skel->alloc_ctx)) { + dev_err(&pdev->dev, "Can't allocate buffer context"); + ret = PTR_ERR(skel->alloc_ctx); + goto free_hdl; + } + INIT_LIST_HEAD(&skel->buf_list); + spin_lock_init(&skel->qlock); + + /* Initialize the video_device structure */ + vdev = &skel->vdev; + strlcpy(vdev->name, KBUILD_MODNAME, sizeof(vdev->name)); + /* + * There is nothing to clean up, so release is set to an empty release + * function. The release callback must be non-NULL. + */ + vdev->release = video_device_release_empty; + vdev->fops = &skel_fops, + vdev->ioctl_ops = &skel_ioctl_ops, + /* + * The main serialization lock. All ioctls are serialized by this + * lock. Exception: if q->lock is set, then the streaming ioctls + * are serialized by that separate lock. + */ + vdev->lock = &skel->lock; + vdev->queue = q; + vdev->v4l2_dev = &skel->v4l2_dev; + /* Supported SDTV standards, if any */ + vdev->tvnorms = SKEL_TVNORMS; + video_set_drvdata(vdev, skel); + + ret = video_register_device(vdev, VFL_TYPE_GRABBER, -1); + if (ret) + goto free_ctx; + + dev_info(&pdev->dev, "V4L2 PCI Skeleton Driver loaded\n"); + return 0; + +free_ctx: + vb2_dma_contig_cleanup_ctx(skel->alloc_ctx); +free_hdl: + v4l2_ctrl_handler_free(&skel->ctrl_handler); + v4l2_device_unregister(&skel->v4l2_dev); +disable_pci: + pci_disable_device(pdev); + return ret; +} + +static void skeleton_remove(struct pci_dev *pdev) +{ + struct v4l2_device *v4l2_dev = pci_get_drvdata(pdev); + struct skeleton *skel = container_of(v4l2_dev, struct skeleton, v4l2_dev); + + video_unregister_device(&skel->vdev); + v4l2_ctrl_handler_free(&skel->ctrl_handler); + vb2_dma_contig_cleanup_ctx(skel->alloc_ctx); + v4l2_device_unregister(&skel->v4l2_dev); + pci_disable_device(skel->pdev); +} + +static struct pci_driver skeleton_driver = { + .name = KBUILD_MODNAME, + .probe = skeleton_probe, + .remove = skeleton_remove, + .id_table = skeleton_pci_tbl, +}; + +module_pci_driver(skeleton_driver); diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index fe97350..68cda1f 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,116 +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_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_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: @@ -1922,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 @@ -2126,7 +2200,7 @@ into the hash PTE second double word). 4.75 KVM_IRQFD Capability: KVM_CAP_IRQFD -Architectures: x86 +Architectures: x86 s390 Type: vm ioctl Parameters: struct kvm_irqfd (in) Returns: 0 on success, -1 on error @@ -2211,6 +2285,8 @@ KVM_S390_SIGP_STOP (vcpu) - sigp restart KVM_S390_PROGRAM_INT (vcpu) - program check; code in parm KVM_S390_SIGP_SET_PREFIX (vcpu) - sigp set prefix; prefix address in parm KVM_S390_RESTART (vcpu) - restart +KVM_S390_INT_CLOCK_COMP (vcpu) - clock comparator interrupt +KVM_S390_INT_CPU_TIMER (vcpu) - CPU timer interrupt KVM_S390_INT_VIRTIO (vm) - virtio external interrupt; external interrupt parameters in parm and parm64 KVM_S390_INT_SERVICE (vm) - sclp external interrupt; sclp parameter in parm @@ -2314,8 +2390,8 @@ struct kvm_create_device { 4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR -Capability: KVM_CAP_DEVICE_CTRL -Type: device ioctl +Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device +Type: device ioctl, vm ioctl Parameters: struct kvm_device_attr Returns: 0 on success, -1 on error Errors: @@ -2340,8 +2416,8 @@ struct kvm_device_attr { 4.81 KVM_HAS_DEVICE_ATTR -Capability: KVM_CAP_DEVICE_CTRL -Type: device ioctl +Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device +Type: device ioctl, vm ioctl Parameters: struct kvm_device_attr Returns: 0 on success, -1 on error Errors: @@ -2376,6 +2452,8 @@ Possible features: Depends on KVM_CAP_ARM_PSCI. - KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode. Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only). + - KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU. + Depends on KVM_CAP_ARM_PSCI_0_2. 4.83 KVM_ARM_PREFERRED_TARGET @@ -2405,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 @@ -2738,6 +2816,21 @@ It gets triggered whenever both KVM_CAP_PPC_EPR are enabled and an external interrupt has just been delivered into the guest. User space should put the acknowledged interrupt vector into the 'epr' field. + /* KVM_EXIT_SYSTEM_EVENT */ + struct { +#define KVM_SYSTEM_EVENT_SHUTDOWN 1 +#define KVM_SYSTEM_EVENT_RESET 2 + __u32 type; + __u64 flags; + } system_event; + +If exit_reason is KVM_EXIT_SYSTEM_EVENT then the vcpu has triggered +a system-level event using some architecture specific mechanism (hypercall +or some special instruction). In case of ARM/ARM64, this is triggered using +HVC instruction based PSCI call from the vcpu. The 'type' field describes +the system-level event type. The 'flags' field describes architecture +specific flags for the system-level event. + /* Fix the size of the union. */ char padding[256]; }; @@ -2841,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) @@ -2859,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 @@ -2873,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 @@ -2892,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 @@ -2934,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 @@ -2945,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 @@ -2973,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/virtual/kvm/devices/vm.txt b/Documentation/virtual/kvm/devices/vm.txt new file mode 100644 index 0000000..0d16f96 --- /dev/null +++ b/Documentation/virtual/kvm/devices/vm.txt @@ -0,0 +1,26 @@ +Generic vm interface +==================================== + +The virtual machine "device" also accepts the ioctls KVM_SET_DEVICE_ATTR, +KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same +struct kvm_device_attr as other devices, but targets VM-wide settings +and controls. + +The groups and attributes per virtual machine, if any, are architecture +specific. + +1. GROUP: KVM_S390_VM_MEM_CTRL +Architectures: s390 + +1.1. ATTRIBUTE: KVM_S390_VM_MEM_CTRL +Parameters: none +Returns: -EBUSY if already a vcpus is defined, otherwise 0 + +Enables CMMA for the virtual machine + +1.2. ATTRIBUTE: KVM_S390_VM_CLR_CMMA +Parameteres: none +Returns: 0 + +Clear the CMMA status for all guest pages, so any pages the guest marked +as unused are again used any may not be reclaimed by the host. diff --git a/Documentation/virtual/kvm/ppc-pv.txt b/Documentation/virtual/kvm/ppc-pv.txt index 4643cde..3195606 100644 --- a/Documentation/virtual/kvm/ppc-pv.txt +++ b/Documentation/virtual/kvm/ppc-pv.txt @@ -94,10 +94,24 @@ a bitmap of available features inside the magic page. The following enhancements to the magic page are currently available: KVM_MAGIC_FEAT_SR Maps SR registers r/w in the magic page + KVM_MAGIC_FEAT_MAS0_TO_SPRG7 Maps MASn, ESR, PIR and high SPRGs For enhanced features in the magic page, please check for the existence of the feature before using them! +Magic page flags +================ + +In addition to features that indicate whether a host is capable of a particular +feature we also have a channel for a guest to tell the guest whether it's capable +of something. This is what we call "flags". + +Flags are passed to the host in the low 12 bits of the Effective Address. + +The following flags are currently available for a guest to expose: + + MAGIC_PAGE_FLAG_NOT_MAPPED_NX Guest handles NX bits correclty wrt magic page + MSR bits ======== diff --git a/Documentation/virtual/kvm/s390-diag.txt b/Documentation/virtual/kvm/s390-diag.txt index f1de4fb..48c4921 100644 --- a/Documentation/virtual/kvm/s390-diag.txt +++ b/Documentation/virtual/kvm/s390-diag.txt @@ -78,3 +78,5 @@ DIAGNOSE function code 'X'501 - KVM breakpoint If the function code specifies 0x501, breakpoint functions may be performed. This function code is handled by userspace. + +This diagnose function code has no subfunctions and uses no parameters. diff --git a/Documentation/vm/hwpoison.txt b/Documentation/vm/hwpoison.txt index 5500684..6ae89a9 100644 --- a/Documentation/vm/hwpoison.txt +++ b/Documentation/vm/hwpoison.txt @@ -84,6 +84,11 @@ PR_MCE_KILL PR_MCE_KILL_EARLY: Early kill PR_MCE_KILL_LATE: Late kill PR_MCE_KILL_DEFAULT: Use system global default + Note that if you want to have a dedicated thread which handles + the SIGBUS(BUS_MCEERR_AO) on behalf of the process, you should + call prctl(PR_MCE_KILL_EARLY) on the designated thread. Otherwise, + the SIGBUS is sent to the main thread. + PR_MCE_KILL_GET return current mode diff --git a/Documentation/vm/numa_memory_policy.txt b/Documentation/vm/numa_memory_policy.txt index 4e7da65..badb050 100644 --- a/Documentation/vm/numa_memory_policy.txt +++ b/Documentation/vm/numa_memory_policy.txt @@ -174,7 +174,6 @@ Components of Memory Policies allocation fails, the kernel will search other nodes, in order of increasing distance from the preferred node based on information provided by the platform firmware. - containing the cpu where the allocation takes place. Internally, the Preferred policy uses a single node--the preferred_node member of struct mempolicy. When the internal @@ -275,9 +274,9 @@ Components of Memory Policies For example, consider a task that is attached to a cpuset with mems 2-5 that sets an Interleave policy over the same set with MPOL_F_RELATIVE_NODES. If the cpuset's mems change to 3-7, the - interleave now occurs over nodes 3,5-6. If the cpuset's mems + interleave now occurs over nodes 3,5-7. If the cpuset's mems then change to 0,2-3,5, then the interleave occurs over nodes - 0,3,5. + 0,2-3,5. Thanks to the consistent remapping, applications preparing nodemasks to specify memory policies using this flag should diff --git a/Documentation/vm/remap_file_pages.txt b/Documentation/vm/remap_file_pages.txt new file mode 100644 index 0000000..560e436 --- /dev/null +++ b/Documentation/vm/remap_file_pages.txt @@ -0,0 +1,28 @@ +The remap_file_pages() system call is used to create a nonlinear mapping, +that is, a mapping in which the pages of the file are mapped into a +nonsequential order in memory. The advantage of using remap_file_pages() +over using repeated calls to mmap(2) is that the former approach does not +require the kernel to create additional VMA (Virtual Memory Area) data +structures. + +Supporting of nonlinear mapping requires significant amount of non-trivial +code in kernel virtual memory subsystem including hot paths. Also to get +nonlinear mapping work kernel need a way to distinguish normal page table +entries from entries with file offset (pte_file). Kernel reserves flag in +PTE for this purpose. PTE flags are scarce resource especially on some CPU +architectures. It would be nice to free up the flag for other usage. + +Fortunately, there are not many users of remap_file_pages() in the wild. +It's only known that one enterprise RDBMS implementation uses the syscall +on 32-bit systems to map files bigger than can linearly fit into 32-bit +virtual address space. This use-case is not critical anymore since 64-bit +systems are widely available. + +The plan is to deprecate the syscall and replace it with an emulation. +The emulation will create new VMAs instead of nonlinear mappings. It's +going to work slower for rare users of remap_file_pages() but ABI is +preserved. + +One side effect of emulation (apart from performance) is that user can hit +vm.max_map_count limit more easily due to additional VMAs. See comment for +DEFAULT_MAX_MAP_COUNT for more details on the limit. diff --git a/Documentation/w1/slaves/w1_ds2406 b/Documentation/w1/slaves/w1_ds2406 new file mode 100644 index 0000000..8137fe6 --- /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/w1/w1.generic b/Documentation/w1/w1.generic index a31c5a2..b2033c6 100644 --- a/Documentation/w1/w1.generic +++ b/Documentation/w1/w1.generic @@ -82,7 +82,7 @@ driver - (standard) symlink to the w1 driver w1_master_add - Manually register a slave device w1_master_attempts - the number of times a search was attempted w1_master_max_slave_count - - the maximum slaves that may be attached to a master + - maximum number of slaves to search for at a time w1_master_name - the name of the device (w1_bus_masterX) w1_master_pullup - 5V strong pullup 0 enabled, 1 disabled w1_master_remove - Manually remove a slave device diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1.netlink index 927a52c..ef27271 100644 --- a/Documentation/w1/w1.netlink +++ b/Documentation/w1/w1.netlink @@ -30,7 +30,7 @@ Protocol. W1_SLAVE_CMD userspace command for slave device (read/write/touch) - __u8 res - reserved + __u8 status - error indication from kernel __u16 len - size of data attached to this header data union { __u8 id[8]; - slave unique device id @@ -44,10 +44,14 @@ Protocol. __u8 cmd - command opcode. W1_CMD_READ - read command W1_CMD_WRITE - write command - W1_CMD_TOUCH - touch command - (write and sample data back to userspace) W1_CMD_SEARCH - search command W1_CMD_ALARM_SEARCH - alarm search command + W1_CMD_TOUCH - touch command + (write and sample data back to userspace) + W1_CMD_RESET - send bus reset + W1_CMD_SLAVE_ADD - add slave to kernel list + W1_CMD_SLAVE_REMOVE - remove slave from kernel list + W1_CMD_LIST_SLAVES - get slaves list from kernel __u8 res - reserved __u16 len - length of data for this command For read command data must be allocated like for write command @@ -87,8 +91,7 @@ format: id0 ... idN Each message is at most 4k in size, so if number of master devices - exceeds this, it will be split into several messages, - cn.seq will be increased for each one. + exceeds this, it will be split into several messages. W1 search and alarm search commands. request: diff --git a/Documentation/x86/tlb.txt b/Documentation/x86/tlb.txt new file mode 100644 index 0000000..2b3a82e --- /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/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt index c584a51..afe68dd 100644 --- a/Documentation/x86/x86_64/mm.txt +++ b/Documentation/x86/x86_64/mm.txt @@ -12,6 +12,8 @@ ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) ... unused hole ... +ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks +... unused hole ... ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0 ffffffffa0000000 - ffffffffff5fffff (=1525 MB) module mapping space ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls diff --git a/Documentation/zh_CN/HOWTO b/Documentation/zh_CN/HOWTO index 6c914aa..54ea24f 100644 --- a/Documentation/zh_CN/HOWTO +++ b/Documentation/zh_CN/HOWTO @@ -237,7 +237,7 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循 如果没有2.6.x.y版本内核存在，那么最新的2.6.x版本内核就相当于是当前的稳定 版内核。 -2.6.x.y版本由“稳定版”小组（邮件地址<stable@kernel.org>）维护，一般隔周发 +2.6.x.y版本由“稳定版”小组（邮件地址<stable@vger.kernel.org>）维护，一般隔周发 布新版本。 内核源码中的Documentation/stable_kernel_rules.txt文件具体描述了可被稳定 diff --git a/Documentation/zh_CN/SubmittingPatches b/Documentation/zh_CN/SubmittingPatches index be0bd47..1d3a10f 100644 --- a/Documentation/zh_CN/SubmittingPatches +++ b/Documentation/zh_CN/SubmittingPatches @@ -82,10 +82,6 @@ Documentation/SubmittingDrivers 。 Quilt: http://savannah.nongnu.org/projects/quilt -Andrew Morton 的补丁脚本: -http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz -作为这些脚本的替代，quilt 是值得推荐的补丁管理工具(看上面的链接)。 - 2)描述你的改动。 描述你的改动包含的技术细节。 @@ -394,7 +390,7 @@ Static inline 函数相比宏来说，是好得多的选择。Static inline 函 ---------------- Andrew Morton, "The perfect patch" (tpp). - <http://userweb.kernel.org/~akpm/stuff/tpp.txt> + <http://www.ozlabs.org/~akpm/stuff/tpp.txt> Jeff Garzik, "Linux kernel patch submission format". <http://linux.yyz.us/patch-format.html> @@ -406,7 +402,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". <http://www.kroah.com/log/2006/01/11/> NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! - <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> + <https://lkml.org/lkml/2005/7/11/336> Kernel Documentation/CodingStyle: <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle> diff --git a/Documentation/zh_CN/io_ordering.txt b/Documentation/zh_CN/io_ordering.txt new file mode 100644 index 0000000..e592daf --- /dev/null +++ b/Documentation/zh_CN/io_ordering.txt @@ -0,0 +1,67 @@ +Chinese translated version of Documentation/io_orderings.txt + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +Chinese maintainer: Lin Yongting <linyongting@gmail.com> +--------------------------------------------------------------------- +Documentation/io_ordering.txt 的中文翻译 + +如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 +交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题，请联系中文版维护者。 + +中文版维护者： 林永听 Lin Yongting <linyongting@gmail.com> +中文版翻译者： 林永听 Lin Yongting <linyongting@gmail.com> +中文版校译者： 林永听 Lin Yongting <linyongting@gmail.com> + + +以下为正文 +--------------------------------------------------------------------- + +在某些平台上，所谓的内存映射I/O是弱顺序。在这些平台上，驱动开发者有责任 +保证I/O内存映射地址的写操作按程序图意的顺序达到设备。通常读取一个“安全” +设备寄存器或桥寄存器，触发IO芯片清刷未处理的写操作到达设备后才处理读操作， +而达到保证目的。驱动程序通常在spinlock保护的临界区退出之前使用这种技术。 +这也可以保证后面的写操作只在前面的写操作之后到达设备（这非常类似于内存 +屏障操作，mb()，不过仅适用于I/O）。 + +假设一个设备驱动程的具体例子： + + ... +CPU A: spin_lock_irqsave(&dev_lock, flags) +CPU A: val = readl(my_status); +CPU A: ... +CPU A: writel(newval, ring_ptr); +CPU A: spin_unlock_irqrestore(&dev_lock, flags) + ... +CPU B: spin_lock_irqsave(&dev_lock, flags) +CPU B: val = readl(my_status); +CPU B: ... +CPU B: writel(newval2, ring_ptr); +CPU B: spin_unlock_irqrestore(&dev_lock, flags) + ... + +上述例子中，设备可能会先接收到newval2的值，然后接收到newval的值，问题就 +发生了。不过很容易通过下面方法来修复： + + ... +CPU A: spin_lock_irqsave(&dev_lock, flags) +CPU A: val = readl(my_status); +CPU A: ... +CPU A: writel(newval, ring_ptr); +CPU A: (void)readl(safe_register); /* 配置寄存器？*/ +CPU A: spin_unlock_irqrestore(&dev_lock, flags) + ... +CPU B: spin_lock_irqsave(&dev_lock, flags) +CPU B: val = readl(my_status); +CPU B: ... +CPU B: writel(newval2, ring_ptr); +CPU B: (void)readl(safe_register); /* 配置寄存器？*/ +CPU B: spin_unlock_irqrestore(&dev_lock, flags) + +在解决方案中，读取safe_register寄存器，触发IO芯片清刷未处理的写操作， +再处理后面的读操作，防止引发数据不一致问题。 diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt index 2ebe539..dfb72a5 100644 --- a/Documentation/zh_CN/magic-number.txt +++ b/Documentation/zh_CN/magic-number.txt @@ -63,8 +63,6 @@ struct tty_ldisc { PG_MAGIC 'P' pg_{read,write}_hdr include/linux/pg.h CMAGIC 0x0111 user include/linux/a.out.h MKISS_DRIVER_MAGIC 0x04bf mkiss_channel drivers/net/mkiss.h -RISCOM8_MAGIC 0x0907 riscom_port drivers/char/riscom8.h -SPECIALIX_MAGIC 0x0907 specialix_port drivers/char/specialix_io8.h HDLC_MAGIC 0x239e n_hdlc drivers/char/n_hdlc.c APM_BIOS_MAGIC 0x4101 apm_user arch/x86/kernel/apm_32.c CYCLADES_MAGIC 0x4359 cyclades_port include/linux/cyclades.h @@ -82,7 +80,6 @@ STRIP_MAGIC 0x5303 strip drivers/net/strip.c X25_ASY_MAGIC 0x5303 x25_asy drivers/net/x25_asy.h SIXPACK_MAGIC 0x5304 sixpack drivers/net/hamradio/6pack.h AX25_MAGIC 0x5316 ax_disp drivers/net/mkiss.h -ESP_MAGIC 0x53ee esp_struct drivers/char/esp.h TTY_MAGIC 0x5401 tty_struct include/linux/tty.h MGSL_MAGIC 0x5401 mgsl_info drivers/char/synclink.c TTY_DRIVER_MAGIC 0x5402 tty_driver include/linux/tty_driver.h @@ -94,13 +91,10 @@ USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth drivers/usb/class/bluetty.c RFCOMM_TTY_MAGIC 0x6d02 net/bluetooth/rfcomm/tty.c USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port drivers/usb/serial/usb-serial.h CG_MAGIC 0x00090255 ufs_cylinder_group include/linux/ufs_fs.h -A2232_MAGIC 0x000a2232 gs_port drivers/char/ser_a2232.h RPORT_MAGIC 0x00525001 r_port drivers/char/rocket_int.h LSEMAGIC 0x05091998 lse drivers/fc4/fc.c GDTIOCTL_MAGIC 0x06030f07 gdth_iowr_str drivers/scsi/gdth_ioctl.h RIEBL_MAGIC 0x09051990 drivers/net/atarilance.c -RIO_MAGIC 0x12345678 gs_port drivers/char/rio/rio_linux.c -SX_MAGIC 0x12345678 gs_port drivers/char/sx.h NBD_REQUEST_MAGIC 0x12560953 nbd_request include/linux/nbd.h RED_MAGIC2 0x170fc2a5 (any) mm/slab.c BAYCOM_MAGIC 0x19730510 baycom_state drivers/net/baycom_epp.c @@ -116,7 +110,6 @@ ISDN_ASYNC_MAGIC 0x49344C01 modem_info include/linux/isdn.h CTC_ASYNC_MAGIC 0x49344C01 ctc_tty_info drivers/s390/net/ctctty.c ISDN_NET_MAGIC 0x49344C02 isdn_net_local_s drivers/isdn/i4l/isdn_net_lib.h SAVEKMSG_MAGIC2 0x4B4D5347 savekmsg arch/*/amiga/config.c -STLI_BOARDMAGIC 0x4bc6c825 stlibrd include/linux/istallion.h CS_STATE_MAGIC 0x4c4f4749 cs_state sound/oss/cs46xx.c SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c @@ -127,10 +120,8 @@ SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h RED_MAGIC1 0x5a2cf071 (any) mm/slab.c -STL_PORTMAGIC 0x5a7182c9 stlport include/linux/stallion.h EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev drivers/atm/lanai.c HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h -EPCA_MAGIC 0x5c6df104 channel include/linux/epca.h PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h KV_MAGIC 0x5f4b565f kernel_vars_s arch/mips/include/asm/sn/klkernvars.h I810_STATE_MAGIC 0x63657373 i810_state sound/oss/i810_audio.c @@ -142,17 +133,14 @@ SLOT_MAGIC 0x67267322 slot drivers/hotplug/acpiphp.h LO_MAGIC 0x68797548 nbd_device include/linux/nbd.h OPROFILE_MAGIC 0x6f70726f super_block drivers/oprofile/oprofilefs.h M3_STATE_MAGIC 0x734d724d m3_state sound/oss/maestro3.c -STL_PANELMAGIC 0x7ef621a1 stlpanel include/linux/stallion.h VMALLOC_MAGIC 0x87654320 snd_alloc_track sound/core/memory.c KMALLOC_MAGIC 0x87654321 snd_alloc_track sound/core/memory.c PWC_MAGIC 0x89DC10AB pwc_device drivers/usb/media/pwc.h NBD_REPLY_MAGIC 0x96744668 nbd_reply include/linux/nbd.h -STL_BOARDMAGIC 0xa2267f52 stlbrd include/linux/stallion.h ENI155_MAGIC 0xa54b872d midway_eprom drivers/atm/eni.h SCI_MAGIC 0xbabeface gs_port drivers/char/sh-sci.h CODA_MAGIC 0xC0DAC0DA coda_file_info include/linux/coda_fs_i.h DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram drivers/scsi/gdth.h -STLI_PORTMAGIC 0xe671c7a1 stliport include/linux/istallion.h YAM_MAGIC 0xF10A7654 yam_port drivers/net/hamradio/yam.c CCB_MAGIC 0xf2691ad2 ccb drivers/scsi/ncr53c8xx.c QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry drivers/scsi/arm/queue.c diff --git a/Documentation/zh_CN/stable_kernel_rules.txt b/Documentation/zh_CN/stable_kernel_rules.txt index b5b9b0a..26ea5ed 100644 --- a/Documentation/zh_CN/stable_kernel_rules.txt +++ b/Documentation/zh_CN/stable_kernel_rules.txt @@ -42,7 +42,7 @@ Documentation/stable_kernel_rules.txt 的中文翻译 向稳定版代码树提交补丁的过程： - - 在确认了补丁符合以上的规则后，将补丁发送到stable@kernel.org。 + - 在确认了补丁符合以上的规则后，将补丁发送到stable@vger.kernel.org。 - 如果补丁被接受到队列里，发送者会收到一个ACK回复，如果没有被接受，收 到的是NAK回复。回复需要几天的时间，这取决于开发者的时间安排。 - 被接受的补丁会被加到稳定版本队列里，等待其他开发者的审查。 diff --git a/Documentation/zh_CN/video4linux/v4l2-framework.txt b/Documentation/zh_CN/video4linux/v4l2-framework.txt index 0da95db..2b828e6 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 框架中，并非驱动）可通过测试 |
