diff options
Diffstat (limited to 'Documentation')
363 files changed, 18932 insertions, 3663 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 2214f12..49c0513 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -218,8 +218,6 @@ m68k/ - directory with info about Linux on Motorola 68k architecture. magic-number.txt - list of magic numbers used to mark/protect kernel data structures. -mca.txt - - info on supporting Micro Channel Architecture (e.g. PS/2) systems. md.txt - info on boot arguments for the multiple devices driver. memory-barriers.txt diff --git a/Documentation/ABI/removed/ip_queue b/Documentation/ABI/removed/ip_queue new file mode 100644 index 0000000..3243613 --- /dev/null +++ b/Documentation/ABI/removed/ip_queue @@ -0,0 +1,9 @@ +What: ip_queue +Date: finally removed in kernel v3.5.0 +Contact: Pablo Neira Ayuso <pablo@netfilter.org> +Description: + ip_queue has been replaced by nfnetlink_queue which provides + more advanced queueing mechanism to user-space. The ip_queue + module was already announced to become obsolete years ago. + +Users: diff --git a/Documentation/ABI/stable/sysfs-bus-firewire b/Documentation/ABI/stable/sysfs-bus-firewire index 3d484e5..41e5a0c 100644 --- a/Documentation/ABI/stable/sysfs-bus-firewire +++ b/Documentation/ABI/stable/sysfs-bus-firewire @@ -39,6 +39,17 @@ Users: udev rules to set ownership and access permissions or ACLs of /dev/fw[0-9]+ character device files +What: /sys/bus/firewire/devices/fw[0-9]+/is_local +Date: July 2012 +KernelVersion: 3.6 +Contact: linux1394-devel@lists.sourceforge.net +Description: + IEEE 1394 node device attribute. + Read-only and immutable. +Values: 1: The sysfs entry represents a local node (a controller card). + 0: The sysfs entry represents a remote node. + + What: /sys/bus/firewire/devices/fw[0-9]+[.][0-9]+/ Date: May 2007 KernelVersion: 2.6.22 diff --git a/Documentation/ABI/stable/sysfs-driver-w1_ds28e04 b/Documentation/ABI/stable/sysfs-driver-w1_ds28e04 new file mode 100644 index 0000000..26579ee --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-w1_ds28e04 @@ -0,0 +1,15 @@ +What: /sys/bus/w1/devices/.../pio +Date: May 2012 +Contact: Markus Franke <franm@hrz.tu-chemnitz.de> +Description: read/write the contents of the two PIO's of the DS28E04-100 + see Documentation/w1/slaves/w1_ds28e04 for detailed information +Users: any user space application which wants to communicate with DS28E04-100 + + + +What: /sys/bus/w1/devices/.../eeprom +Date: May 2012 +Contact: Markus Franke <franm@hrz.tu-chemnitz.de> +Description: read/write the contents of the EEPROM memory of the DS28E04-100 + see Documentation/w1/slaves/w1_ds28e04 for detailed information +Users: any user space application which wants to communicate with DS28E04-100 diff --git a/Documentation/ABI/testing/debugfs-pfo-nx-crypto b/Documentation/ABI/testing/debugfs-pfo-nx-crypto new file mode 100644 index 0000000..685d5a4 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-pfo-nx-crypto @@ -0,0 +1,45 @@ +What: /sys/kernel/debug/nx-crypto/* +Date: March 2012 +KernelVersion: 3.4 +Contact: Kent Yoder <key@linux.vnet.ibm.com> +Description: + + These debugfs interfaces are built by the nx-crypto driver, built in +arch/powerpc/crypto/nx. + +Error Detection +=============== + +errors: +- A u32 providing a total count of errors since the driver was loaded. The +only errors counted here are those returned from the hcall, H_COP_OP. + +last_error: +- The most recent non-zero return code from the H_COP_OP hcall. -EBUSY is not +recorded here (the hcall will retry until -EBUSY goes away). + +last_error_pid: +- The process ID of the process who received the most recent error from the +hcall. + +Device Use +========== + +aes_bytes: +- The total number of bytes encrypted using AES in any of the driver's +supported modes. + +aes_ops: +- The total number of AES operations submitted to the hardware. + +sha256_bytes: +- The total number of bytes hashed by the hardware using SHA-256. + +sha256_ops: +- The total number of SHA-256 operations submitted to the hardware. + +sha512_bytes: +- The total number of bytes hashed by the hardware using SHA-512. + +sha512_ops: +- The total number of SHA-512 operations submitted to the hardware. diff --git a/Documentation/ABI/testing/dev-kmsg b/Documentation/ABI/testing/dev-kmsg new file mode 100644 index 0000000..7e7e07a --- /dev/null +++ b/Documentation/ABI/testing/dev-kmsg @@ -0,0 +1,101 @@ +What: /dev/kmsg +Date: Mai 2012 +KernelVersion: 3.5 +Contact: Kay Sievers <kay@vrfy.org> +Description: The /dev/kmsg character device node provides userspace access + to the kernel's printk buffer. + + Injecting messages: + Every write() to the opened device node places a log entry in + the kernel's printk buffer. + + The logged line can be prefixed with a <N> syslog prefix, which + carries the syslog priority and facility. The single decimal + prefix number is composed of the 3 lowest bits being the syslog + priority and the higher bits the syslog facility number. + + If no prefix is given, the priority number is the default kernel + log priority and the facility number is set to LOG_USER (1). It + is not possible to inject messages from userspace with the + facility number LOG_KERN (0), to make sure that the origin of + the messages can always be reliably determined. + + Accessing the buffer: + Every read() from the opened device node receives one record + of the kernel's printk buffer. + + The first read() directly following an open() always returns + first message in the buffer; there is no kernel-internal + persistent state; many readers can concurrently open the device + and read from it, without affecting other readers. + + Every read() will receive the next available record. If no more + records are available read() will block, or if O_NONBLOCK is + used -EAGAIN returned. + + Messages in the record ring buffer get overwritten as whole, + there are never partial messages received by read(). + + In case messages get overwritten in the circular buffer while + the device is kept open, the next read() will return -EPIPE, + and the seek position be updated to the next available record. + Subsequent reads() will return available records again. + + Unlike the classic syslog() interface, the 64 bit record + sequence numbers allow to calculate the amount of lost + messages, in case the buffer gets overwritten. And they allow + to reconnect to the buffer and reconstruct the read position + if needed, without limiting the interface to a single reader. + + The device supports seek with the following parameters: + SEEK_SET, 0 + seek to the first entry in the buffer + SEEK_END, 0 + seek after the last entry in the buffer + SEEK_DATA, 0 + seek after the last record available at the time + the last SYSLOG_ACTION_CLEAR was issued. + + The output format consists of a prefix carrying the syslog + prefix including priority and facility, the 64 bit message + sequence number and the monotonic timestamp in microseconds, + and a flag field. All fields are separated by a ','. + + Future extensions might add more comma separated values before + the terminating ';'. Unknown fields and values should be + gracefully ignored. + + The human readable text string starts directly after the ';' + and is terminated by a '\n'. Untrusted values derived from + hardware or other facilities are printed, therefore + all non-printable characters and '\' itself in the log message + are escaped by "\x00" C-style hex encoding. + + A line starting with ' ', is a continuation line, adding + key/value pairs to the log message, which provide the machine + readable context of the message, for reliable processing in + userspace. + + Example: + 7,160,424069,-;pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored) + SUBSYSTEM=acpi + DEVICE=+acpi:PNP0A03:00 + 6,339,5140900,-;NET: Registered protocol family 10 + 30,340,5690716,-;udevd[80]: starting version 181 + + The DEVICE= key uniquely identifies devices the following way: + b12:8 - block dev_t + c127:3 - char dev_t + n8 - netdev ifindex + +sound:card0 - subsystem:devname + + The flags field carries '-' by default. A 'c' indicates a + fragment of a line. All following fragments are flagged with + '+'. Note, that these hints about continuation lines are not + neccessarily correct, and the stream could be interleaved with + unrelated messages, but merging the lines in the output + usually produces better human readable results. A similar + logic is used internally when messages are printed to the + console, /proc/kmsg or the syslog() syscall. + +Users: dmesg(1), userspace kernel log consumers diff --git a/Documentation/ABI/testing/sysfs-block-rssd b/Documentation/ABI/testing/sysfs-block-rssd index d535757..beef30c 100644 --- a/Documentation/ABI/testing/sysfs-block-rssd +++ b/Documentation/ABI/testing/sysfs-block-rssd @@ -1,18 +1,5 @@ -What: /sys/block/rssd*/registers -Date: March 2012 -KernelVersion: 3.3 -Contact: Asai Thambi S P <asamymuthupa@micron.com> -Description: This is a read-only file. Dumps below driver information and - hardware registers. - - S ACTive - - Command Issue - - Allocated - - Completed - - PORT IRQ STAT - - HOST IRQ STAT - What: /sys/block/rssd*/status Date: April 2012 KernelVersion: 3.4 Contact: Asai Thambi S P <asamymuthupa@micron.com> -Description: This is a read-only file. Indicates the status of the device. +Description: This is a read-only file. Indicates the status of the device. diff --git a/Documentation/ABI/testing/sysfs-bus-fcoe b/Documentation/ABI/testing/sysfs-bus-fcoe new file mode 100644 index 0000000..469d09c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-fcoe @@ -0,0 +1,77 @@ +What: /sys/bus/fcoe/ctlr_X +Date: March 2012 +KernelVersion: TBD +Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org +Description: 'FCoE Controller' instances on the fcoe bus +Attributes: + + fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing + this value will change the dev_loss_tmo for all + FCFs discovered by this controller. + + lesb_link_fail: Link Error Status Block (LESB) link failure count. + + lesb_vlink_fail: Link Error Status Block (LESB) virtual link + failure count. + + lesb_miss_fka: Link Error Status Block (LESB) missed FCoE + Initialization Protocol (FIP) Keep-Alives (FKA). + + lesb_symb_err: Link Error Status Block (LESB) symbolic error count. + + lesb_err_block: Link Error Status Block (LESB) block error count. + + lesb_fcs_error: Link Error Status Block (LESB) Fibre Channel + Serivces error count. + +Notes: ctlr_X (global increment starting at 0) + +What: /sys/bus/fcoe/fcf_X +Date: March 2012 +KernelVersion: TBD +Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org +Description: 'FCoE FCF' instances on the fcoe bus. A FCF is a Fibre Channel + Forwarder, which is a FCoE switch that can accept FCoE + (Ethernet) packets, unpack them, and forward the embedded + Fibre Channel frames into a FC fabric. It can also take + outbound FC frames and pack them in Ethernet packets to + be sent to their destination on the Ethernet segment. +Attributes: + + fabric_name: Identifies the fabric that the FCF services. + + switch_name: Identifies the FCF. + + priority: The switch's priority amongst other FCFs on the same + fabric. + + selected: 1 indicates that the switch has been selected for use; + 0 indicates that the swich will not be used. + + fc_map: The Fibre Channel MAP + + vfid: The Virtual Fabric ID + + mac: The FCF's MAC address + + fka_peroid: The FIP Keep-Alive peroid + + fabric_state: The internal kernel state + "Unknown" - Initialization value + "Disconnected" - No link to the FCF/fabric + "Connected" - Host is connected to the FCF + "Deleted" - FCF is being removed from the system + + dev_loss_tmo: The device loss timeout peroid for this FCF. + +Notes: A device loss infrastructre similar to the FC Transport's + is present in fcoe_sysfs. It is nice to have so that a + link flapping adapter doesn't continually advance the count + used to identify the discovered FCF. FCFs will exist in a + "Disconnected" state until either the timer expires and the + FCF becomes "Deleted" or the FCF is rediscovered and becomes + "Connected." + + +Users: The first user of this interface will be the fcoeadm application, + which is commonly packaged in the fcoe-utils package. diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533 b/Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533 new file mode 100644 index 0000000..1b62230 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-lm3533 @@ -0,0 +1,15 @@ +What: /sys/bus/i2c/devices/.../output_hvled[n] +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Set the controlling backlight device for high-voltage current + sink HVLED[n] (n = 1, 2) (0, 1). + +What: /sys/bus/i2c/devices/.../output_lvled[n] +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Set the controlling led device for low-voltage current sink + LVLED[n] (n = 1..5) (0..3). diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio new file mode 100644 index 0000000..2f06d40 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -0,0 +1,770 @@ +What: /sys/bus/iio/devices/iio:deviceX +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Hardware chip or device accessed by one communication port. + Corresponds to a grouping of sensor channels. X is the IIO + index of the device. + +What: /sys/bus/iio/devices/triggerX +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + An event driven driver of data capture to an in kernel buffer. + May be provided by a device driver that also has an IIO device + based on hardware generated events (e.g. data ready) or + provided by a separate driver for other hardware (e.g. + periodic timer, GPIO or high resolution timer). + Contains trigger type specific elements. These do not + generalize well and hence are not documented in this file. + X is the IIO index of the trigger. + +What: /sys/bus/iio/devices/iio:deviceX/buffer +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Directory of attributes relating to the buffer for the device. + +What: /sys/bus/iio/devices/iio:deviceX/name +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Description of the physical chip / device for device X. + Typically a part number. + +What: /sys/bus/iio/devices/iio:deviceX/sampling_frequency +What: /sys/bus/iio/devices/iio:deviceX/buffer/sampling_frequency +What: /sys/bus/iio/devices/triggerX/sampling_frequency +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Some devices have internal clocks. This parameter sets the + resulting sampling frequency. In many devices this + parameter has an effect on input filters etc. rather than + simply controlling when the input is sampled. As this + effects data ready triggers, hardware buffers and the sysfs + direct access interfaces, it may be found in any of the + relevant directories. If it effects all of the above + then it is to be found in the base device directory. + +What: /sys/bus/iio/devices/iio:deviceX/sampling_frequency_available +What: /sys/.../iio:deviceX/buffer/sampling_frequency_available +What: /sys/bus/iio/devices/triggerX/sampling_frequency_available +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + When the internal sampling clock can only take a small + discrete set of values, this file lists those available. + +What: /sys/bus/iio/devices/iio:deviceX/oversampling_ratio +KernelVersion: 2.6.38 +Contact: linux-iio@vger.kernel.org +Description: + Hardware dependent ADC oversampling. Controls the sampling ratio + of the digital filter if available. + +What: /sys/bus/iio/devices/iio:deviceX/oversampling_ratio_available +KernelVersion: 2.6.38 +Contact: linux-iio@vger.kernel.org +Description: + Hardware dependent values supported by the oversampling filter. + +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_raw +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_raw +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Raw (unscaled no bias removal etc.) voltage measurement from + channel Y. In special cases where the channel does not + correspond to externally available input one of the named + versions may be used. The number must always be specified and + unique to allow association with event codes. Units after + application of scale and offset are microvolts. + +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_raw +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Raw (unscaled) differential voltage measurement equivalent to + channel Y - channel Z where these channel numbers apply to the + physically equivalent inputs when non differential readings are + separately available. In differential only parts, then all that + is required is a consistent labeling. Units after application + of scale and offset are microvolts. + +What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw +KernelVersion: 3.2 +Contact: linux-iio@vger.kernel.org +Description: + Raw capacitance measurement from channel Y. Units after + application of scale and offset are nanofarads. + +What: /sys/.../iio:deviceX/in_capacitanceY-in_capacitanceZ_raw +KernelVersion: 3.2 +Contact: linux-iio@vger.kernel.org +Description: + Raw differential capacitance measurement equivalent to + channel Y - channel Z where these channel numbers apply to the + physically equivalent inputs when non differential readings are + separately available. In differential only parts, then all that + is required is a consistent labeling. Units after application + of scale and offset are nanofarads. + +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 +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 + are milli degrees Celsius. + +What: /sys/bus/iio/devices/iio:deviceX/in_tempX_input +KernelVersion: 2.6.38 +Contact: linux-iio@vger.kernel.org +Description: + Scaled temperature measurement in milli degrees Celsius. + +What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_raw +What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_raw +What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_raw +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Acceleration in direction x, y or z (may be arbitrarily assigned + but should match other such assignments on device). + Has all of the equivalent parameters as per voltageY. Units + after application of scale and offset are m/s^2. + +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_raw +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_raw +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_raw +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Angular velocity about axis x, y or z (may be arbitrarily + assigned). Has all the equivalent parameters as per voltageY. + Units after application of scale and offset are radians per + second. + +What: /sys/bus/iio/devices/iio:deviceX/in_incli_x_raw +What: /sys/bus/iio/devices/iio:deviceX/in_incli_y_raw +What: /sys/bus/iio/devices/iio:deviceX/in_incli_z_raw +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Inclination raw reading about axis x, y or z (may be + arbitrarily assigned). Data converted by application of offset + and scale to degrees. + +What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_raw +What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_raw +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Magnetic field along axis x, y or z (may be arbitrarily + assigned). Data converted by application of offset + then scale to Gauss. + +What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_peak_raw +What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_peak_raw +What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_peak_raw +KernelVersion: 2.6.36 +Contact: linux-iio@vger.kernel.org +Description: + Highest value since some reset condition. These + attributes allow access to this and are otherwise + the direct equivalent of the <type>Y[_name]_raw attributes. + +What: /sys/bus/iio/devices/iio:deviceX/in_accel_xyz_squared_peak_raw +KernelVersion: 2.6.36 +Contact: linux-iio@vger.kernel.org +Description: + A computed peak value based on the sum squared magnitude of + the underlying value in the specified directions. + +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 +What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_offset +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_offset +What: /sys/bus/iio/devices/iio:deviceX/in_voltage_offset +What: /sys/bus/iio/devices/iio:deviceX/in_tempY_offset +What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + If known for a device, offset to be added to <type>[Y]_raw prior + to scaling by <type>[Y]_scale in order to obtain value in the + <type> units as specified in <type>[Y]_raw documentation. + Not present if the offset is always 0 or unknown. If Y or + axis <x|y|z> is not present, then the offset applies to all + in channels of <type>. + May be writable if a variable offset can be applied on the + device. Note that this is different to calibbias which + is for devices (or drivers) that apply offsets to compensate + for variation between different instances of the part, typically + adjusted by using some hardware supported calibration procedure. + Calibbias is applied internally, offset is applied in userspace + to the _raw output. + +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_scale +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_scale +What: /sys/bus/iio/devices/iio:deviceX/in_voltage_scale +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_scale +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale +What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale +What: /sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_scale +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 +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + If known for a device, scale to be applied to <type>Y[_name]_raw + post addition of <type>[Y][_name]_offset in order to obtain the + measured value in <type> units as specified in + <type>[Y][_name]_raw documentation. If shared across all in + channels then Y and <x|y|z> are not present and the value is + called <type>[Y][_name]_scale. The peak modifier means this + value is applied to <type>Y[_name]_peak_raw values. + +What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibbias +What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Hardware applied calibration offset (assumed to fix production + inaccuracies). + +What /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibscale +What /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibscale +what /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibscale +what /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Hardware applied calibration scale factor (assumed to fix + production inaccuracies). If shared across all channels, + <type>_calibscale is used. + +What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale_available +What: /sys/.../iio:deviceX/in_voltageX_scale_available +What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available +What: /sys/.../iio:deviceX/out_voltageX_scale_available +What: /sys/.../iio:deviceX/out_altvoltageX_scale_available +What: /sys/.../iio:deviceX/in_capacitance_scale_available +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + If a discrete set of scale values is available, they + are listed in this attribute. + +What /sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Hardware applied gain factor. If shared across all channels, + <type>_hardwaregain is used. + +What: /sys/.../in_accel_filter_low_pass_3db_frequency +What: /sys/.../in_magn_filter_low_pass_3db_frequency +What: /sys/.../in_anglvel_filter_low_pass_3db_frequency +KernelVersion: 3.2 +Contact: linux-iio@vger.kernel.org +Description: + If a known or controllable low pass filter is applied + to the underlying data channel, then this parameter + gives the 3dB frequency of the filter in Hz. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_raw +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Raw (unscaled, no bias etc.) output voltage for + channel Y. The number must always be specified and + unique if the output corresponds to a single channel. + While DAC like devices typically use out_voltage, + a continuous frequency generating device, such as + a DDS or PLL should use out_altvoltage. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY&Z_raw +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY&Z_raw +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Raw (unscaled, no bias etc.) output voltage for an aggregate of + channel Y, channel Z, etc. This interface is available in cases + where a single output sets the value for multiple channels + simultaneously. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_powerdown_mode +What: /sys/bus/iio/devices/iio:deviceX/out_voltage_powerdown_mode +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown_mode +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltage_powerdown_mode +KernelVersion: 2.6.38 +Contact: linux-iio@vger.kernel.org +Description: + Specifies the output powerdown mode. + DAC output stage is disconnected from the amplifier and + 1kohm_to_gnd: connected to ground via an 1kOhm resistor, + 6kohm_to_gnd: connected to ground via a 6kOhm resistor, + 20kohm_to_gnd: connected to ground via a 20kOhm resistor, + 100kohm_to_gnd: connected to ground via an 100kOhm resistor, + three_state: left floating. + For a list of available output power down options read + outX_powerdown_mode_available. If Y is not present the + mode is shared across all outputs. + +What: /sys/.../iio:deviceX/out_votlageY_powerdown_mode_available +What: /sys/.../iio:deviceX/out_voltage_powerdown_mode_available +What: /sys/.../iio:deviceX/out_altvotlageY_powerdown_mode_available +What: /sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available +KernelVersion: 2.6.38 +Contact: linux-iio@vger.kernel.org +Description: + Lists all available output power down modes. + If Y is not present the mode is shared across all outputs. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_powerdown +What: /sys/bus/iio/devices/iio:deviceX/out_voltage_powerdown +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltage_powerdown +KernelVersion: 2.6.38 +Contact: linux-iio@vger.kernel.org +Description: + Writing 1 causes output Y to enter the power down mode specified + by the corresponding outY_powerdown_mode. DAC output stage is + disconnected from the amplifier. Clearing returns to normal + operation. Y may be suppressed if all outputs are controlled + together. + +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency +KernelVersion: 3.4.0 +Contact: linux-iio@vger.kernel.org +Description: + Output frequency for channel Y in Hz. The number must always be + specified and unique if the output corresponds to a single + channel. + +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase +KernelVersion: 3.4.0 +Contact: linux-iio@vger.kernel.org +Description: + Phase in radians of one frequency/clock output Y + (out_altvoltageY) relative to another frequency/clock output + (out_altvoltageZ) of the device X. The number must always be + specified and unique if the output corresponds to a single + channel. + +What: /sys/bus/iio/devices/iio:deviceX/events +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Configuration of which hardware generated events are passed up + to user-space. + +What: /sys/.../iio:deviceX/events/in_accel_x_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_accel_x_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_accel_y_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_accel_y_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_accel_z_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_accel_z_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_anglvel_x_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_anglvel_x_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_anglvel_y_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_anglvel_y_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_anglvel_z_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_anglvel_z_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_magn_x_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_magn_x_thresh_falling_en +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_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 +What: /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_tempY_thresh_rising_en +What: /sys/.../iio:deviceX/events/in_tempY_thresh_falling_en +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Event generated when channel passes a threshold in the specified + (_rising|_falling) direction. If the direction is not specified, + then either the device will report an event which ever direction + a single threshold value is passed in (e.g. + <type>[Y][_name]_<raw|input>_thresh_value) or + <type>[Y][_name]_<raw|input>_thresh_rising_value and + <type>[Y][_name]_<raw|input>_thresh_falling_value may take + different values, but the device can only enable both thresholds + or neither. + Note the driver will assume the last p events requested are + to be enabled where p is how many it supports (which may vary + depending on the exact set requested. So if you want to be + sure you have set what you think you have, check the contents of + these attributes after everything is configured. Drivers may + have to buffer any parameters so that they are consistent when + a given event type is enabled at a future point (and not those for + whatever event was previously enabled). + +What: /sys/.../iio:deviceX/events/in_accel_x_roc_rising_en +What: /sys/.../iio:deviceX/events/in_accel_x_roc_falling_en +What: /sys/.../iio:deviceX/events/in_accel_y_roc_rising_en +What: /sys/.../iio:deviceX/events/in_accel_y_roc_falling_en +What: /sys/.../iio:deviceX/events/in_accel_z_roc_rising_en +What: /sys/.../iio:deviceX/events/in_accel_z_roc_falling_en +What: /sys/.../iio:deviceX/events/in_anglvel_x_roc_rising_en +What: /sys/.../iio:deviceX/events/in_anglvel_x_roc_falling_en +What: /sys/.../iio:deviceX/events/in_anglvel_y_roc_rising_en +What: /sys/.../iio:deviceX/events/in_anglvel_y_roc_falling_en +What: /sys/.../iio:deviceX/events/in_anglvel_z_roc_rising_en +What: /sys/.../iio:deviceX/events/in_anglvel_z_roc_falling_en +What: /sys/.../iio:deviceX/events/in_magn_x_roc_rising_en +What: /sys/.../iio:deviceX/events/in_magn_x_roc_falling_en +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_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 +What: /sys/.../iio:deviceX/events/in_voltageY_roc_falling_en +What: /sys/.../iio:deviceX/events/in_tempY_roc_rising_en +What: /sys/.../iio:deviceX/events/in_tempY_roc_falling_en +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Event generated when channel passes a threshold on the rate of + change (1st differential) in the specified (_rising|_falling) + direction. If the direction is not specified, then either the + device will report an event which ever direction a single + threshold value is passed in (e.g. + <type>[Y][_name]_<raw|input>_roc_value) or + <type>[Y][_name]_<raw|input>_roc_rising_value and + <type>[Y][_name]_<raw|input>_roc_falling_value may take + different values, but the device can only enable both rate of + change thresholds or neither. + Note the driver will assume the last p events requested are + to be enabled where p is however many it supports (which may + vary depending on the exact set requested. So if you want to be + sure you have set what you think you have, check the contents of + these attributes after everything is configured. Drivers may + have to buffer any parameters so that they are consistent when + a given event type is enabled a future point (and not those for + whatever event was previously enabled). + +What: /sys/.../events/in_accel_x_raw_thresh_rising_value +What: /sys/.../events/in_accel_x_raw_thresh_falling_value +What: /sys/.../events/in_accel_y_raw_thresh_rising_value +What: /sys/.../events/in_accel_y_raw_thresh_falling_value +What: /sys/.../events/in_accel_z_raw_thresh_rising_value +What: /sys/.../events/in_accel_z_raw_thresh_falling_value +What: /sys/.../events/in_anglvel_x_raw_thresh_rising_value +What: /sys/.../events/in_anglvel_x_raw_thresh_falling_value +What: /sys/.../events/in_anglvel_y_raw_thresh_rising_value +What: /sys/.../events/in_anglvel_y_raw_thresh_falling_value +What: /sys/.../events/in_anglvel_z_raw_thresh_rising_value +What: /sys/.../events/in_anglvel_z_raw_thresh_falling_value +What: /sys/.../events/in_magn_x_raw_thresh_rising_value +What: /sys/.../events/in_magn_x_raw_thresh_falling_value +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_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 +What: /sys/.../events/in_voltageY_raw_thresh_falling_value +What: /sys/.../events/in_tempY_raw_thresh_rising_value +What: /sys/.../events/in_tempY_raw_thresh_falling_value +What: /sys/.../events/in_illuminance0_thresh_falling_value +what: /sys/.../events/in_illuminance0_thresh_rising_value +what: /sys/.../events/in_proximity0_thresh_falling_value +what: /sys/.../events/in_proximity0_thresh_rising_value +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Specifies the value of threshold that the device is comparing + against for the events enabled by + <type>Y[_name]_thresh[_rising|falling]_en. + If separate attributes exist for the two directions, but + direction is not specified for this attribute, then a single + threshold value applies to both directions. + The raw or input element of the name indicates whether the + value is in raw device units or in processed units (as _raw + and _input do on sysfs direct channel read attributes). + +What: /sys/.../events/in_accel_x_raw_roc_rising_value +What: /sys/.../events/in_accel_x_raw_roc_falling_value +What: /sys/.../events/in_accel_y_raw_roc_rising_value +What: /sys/.../events/in_accel_y_raw_roc_falling_value +What: /sys/.../events/in_accel_z_raw_roc_rising_value +What: /sys/.../events/in_accel_z_raw_roc_falling_value +What: /sys/.../events/in_anglvel_x_raw_roc_rising_value +What: /sys/.../events/in_anglvel_x_raw_roc_falling_value +What: /sys/.../events/in_anglvel_y_raw_roc_rising_value +What: /sys/.../events/in_anglvel_y_raw_roc_falling_value +What: /sys/.../events/in_anglvel_z_raw_roc_rising_value +What: /sys/.../events/in_anglvel_z_raw_roc_falling_value +What: /sys/.../events/in_magn_x_raw_roc_rising_value +What: /sys/.../events/in_magn_x_raw_roc_falling_value +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_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 +What: /sys/.../events/in_voltageY_raw_roc_falling_value +What: /sys/.../events/in_tempY_raw_roc_rising_value +What: /sys/.../events/in_tempY_raw_roc_falling_value +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Specifies the value of rate of change threshold that the + device is comparing against for the events enabled by + <type>[Y][_name]_roc[_rising|falling]_en. + If separate attributes exist for the two directions, + but direction is not specified for this attribute, + then a single threshold value applies to both directions. + The raw or input element of the name indicates whether the + value is in raw device units or in processed units (as _raw + and _input do on sysfs direct channel read attributes). + +What: /sys/.../events/in_accel_x_thresh_rising_period +What: /sys/.../events/in_accel_x_thresh_falling_period +hat: /sys/.../events/in_accel_x_roc_rising_period +What: /sys/.../events/in_accel_x_roc_falling_period +What: /sys/.../events/in_accel_y_thresh_rising_period +What: /sys/.../events/in_accel_y_thresh_falling_period +What: /sys/.../events/in_accel_y_roc_rising_period +What: /sys/.../events/in_accel_y_roc_falling_period +What: /sys/.../events/in_accel_z_thresh_rising_period +What: /sys/.../events/in_accel_z_thresh_falling_period +What: /sys/.../events/in_accel_z_roc_rising_period +What: /sys/.../events/in_accel_z_roc_falling_period +What: /sys/.../events/in_anglvel_x_thresh_rising_period +What: /sys/.../events/in_anglvel_x_thresh_falling_period +What: /sys/.../events/in_anglvel_x_roc_rising_period +What: /sys/.../events/in_anglvel_x_roc_falling_period +What: /sys/.../events/in_anglvel_y_thresh_rising_period +What: /sys/.../events/in_anglvel_y_thresh_falling_period +What: /sys/.../events/in_anglvel_y_roc_rising_period +What: /sys/.../events/in_anglvel_y_roc_falling_period +What: /sys/.../events/in_anglvel_z_thresh_rising_period +What: /sys/.../events/in_anglvel_z_thresh_falling_period +What: /sys/.../events/in_anglvel_z_roc_rising_period +What: /sys/.../events/in_anglvel_z_roc_falling_period +What: /sys/.../events/in_magn_x_thresh_rising_period +What: /sys/.../events/in_magn_x_thresh_falling_period +What: /sys/.../events/in_magn_x_roc_rising_period +What: /sys/.../events/in_magn_x_roc_falling_period +What: /sys/.../events/in_magn_y_thresh_rising_period +What: /sys/.../events/in_magn_y_thresh_falling_period +What: /sys/.../events/in_magn_y_roc_rising_period +What: /sys/.../events/in_magn_y_roc_falling_period +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_voltageY_supply_thresh_rising_period +What: /sys/.../events/in_voltageY_supply_thresh_falling_period +What: /sys/.../events/in_voltageY_supply_roc_rising_period +What: /sys/.../events/in_voltageY_supply_roc_falling_period +What: /sys/.../events/in_voltageY_thresh_rising_period +What: /sys/.../events/in_voltageY_thresh_falling_period +What: /sys/.../events/in_voltageY_roc_rising_period +What: /sys/.../events/in_voltageY_roc_falling_period +What: /sys/.../events/in_tempY_thresh_rising_period +What: /sys/.../events/in_tempY_thresh_falling_period +What: /sys/.../events/in_tempY_roc_rising_period +What: /sys/.../events/in_tempY_roc_falling_period +What: /sys/.../events/in_accel_x&y&z_mag_falling_period +What: /sys/.../events/in_intensity0_thresh_period +What: /sys/.../events/in_proximity0_thresh_period +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Period of time (in seconds) for which the condition must be + met before an event is generated. If direction is not + specified then this period applies to both directions. + +What: /sys/.../iio:deviceX/events/in_accel_mag_en +What: /sys/.../iio:deviceX/events/in_accel_mag_rising_en +What: /sys/.../iio:deviceX/events/in_accel_mag_falling_en +What: /sys/.../iio:deviceX/events/in_accel_x_mag_en +What: /sys/.../iio:deviceX/events/in_accel_x_mag_rising_en +What: /sys/.../iio:deviceX/events/in_accel_x_mag_falling_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_rising_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_falling_en +What: /sys/.../iio:deviceX/events/in_accel_z_mag_en +What: /sys/.../iio:deviceX/events/in_accel_z_mag_rising_en +What: /sys/.../iio:deviceX/events/in_accel_z_mag_falling_en +What: /sys/.../iio:deviceX/events/in_accel_x&y&z_mag_rising_en +What: /sys/.../iio:deviceX/events/in_accel_x&y&z_mag_falling_en +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Similar to in_accel_x_thresh[_rising|_falling]_en, but here the + magnitude of the channel is compared to the threshold, not its + signed value. + +What: /sys/.../events/in_accel_raw_mag_value +What: /sys/.../events/in_accel_x_raw_mag_rising_value +What: /sys/.../events/in_accel_y_raw_mag_rising_value +What: /sys/.../events/in_accel_z_raw_mag_rising_value +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + The value to which the magnitude of the channel is compared. If + number or direction is not specified, applies to all channels of + this type. + +What: /sys/bus/iio/devices/iio:deviceX/trigger/current_trigger +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + The name of the trigger source being used, as per string given + in /sys/class/iio/triggerY/name. + +What: /sys/bus/iio/devices/iio:deviceX/buffer/length +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Number of scans contained by the buffer. + +What: /sys/bus/iio/devices/iio:deviceX/buffer/bytes_per_datum +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Bytes per scan. Due to alignment fun, the scan may be larger + than implied directly by the scan_element parameters. + +What: /sys/bus/iio/devices/iio:deviceX/buffer/enable +KernelVersion: 2.6.35 +Contact: linux-iio@vger.kernel.org +Description: + Actually start the buffer capture up. Will start trigger + if first device and appropriate. + +What: /sys/bus/iio/devices/iio:deviceX/buffer/scan_elements +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Directory containing interfaces for elements that will be + captured for a single triggered sample set in the buffer. + +What: /sys/.../buffer/scan_elements/in_accel_x_en +What: /sys/.../buffer/scan_elements/in_accel_y_en +What: /sys/.../buffer/scan_elements/in_accel_z_en +What: /sys/.../buffer/scan_elements/in_anglvel_x_en +What: /sys/.../buffer/scan_elements/in_anglvel_y_en +What: /sys/.../buffer/scan_elements/in_anglvel_z_en +What: /sys/.../buffer/scan_elements/in_magn_x_en +What: /sys/.../buffer/scan_elements/in_magn_y_en +What: /sys/.../buffer/scan_elements/in_magn_z_en +What: /sys/.../buffer/scan_elements/in_timestamp_en +What: /sys/.../buffer/scan_elements/in_voltageY_supply_en +What: /sys/.../buffer/scan_elements/in_voltageY_en +What: /sys/.../buffer/scan_elements/in_voltageY-voltageZ_en +What: /sys/.../buffer/scan_elements/in_incli_x_en +What: /sys/.../buffer/scan_elements/in_incli_y_en +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Scan element control for triggered data capture. + +What: /sys/.../buffer/scan_elements/in_accel_type +What: /sys/.../buffer/scan_elements/in_anglvel_type +What: /sys/.../buffer/scan_elements/in_magn_type +What: /sys/.../buffer/scan_elements/in_incli_type +What: /sys/.../buffer/scan_elements/in_voltageY_type +What: /sys/.../buffer/scan_elements/in_voltage_type +What: /sys/.../buffer/scan_elements/in_voltageY_supply_type +What: /sys/.../buffer/scan_elements/in_timestamp_type +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + Description of the scan element data storage within the buffer + and hence the form in which it is read from user-space. + Form is [be|le]:[s|u]bits/storagebits[>>shift]. + be or le specifies big or little endian. s or u specifies if + signed (2's complement) or unsigned. bits is the number of bits + of data and storagebits is the space (after padding) that it + occupies in the buffer. shift if specified, is the shift that + needs to be applied prior to masking out unused bits. Some + devices put their data in the middle of the transferred elements + with additional information on both sides. Note that some + devices will have additional information in the unused bits + so to get a clean value, the bits value must be used to mask + the buffer output value appropriately. The storagebits value + also specifies the data alignment. So s48/64>>2 will be a + signed 48 bit integer stored in a 64 bit location aligned to + a 64 bit boundary. To obtain the clean value, shift right 2 + and apply a mask to zero the top 16 bits of the result. + For other storage combinations this attribute will be extended + appropriately. + +What: /sys/.../buffer/scan_elements/in_accel_type_available +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + If the type parameter can take one of a small set of values, + this attribute lists them. + +What: /sys/.../buffer/scan_elements/in_voltageY_index +What: /sys/.../buffer/scan_elements/in_voltageY_supply_index +What: /sys/.../buffer/scan_elements/in_accel_x_index +What: /sys/.../buffer/scan_elements/in_accel_y_index +What: /sys/.../buffer/scan_elements/in_accel_z_index +What: /sys/.../buffer/scan_elements/in_anglvel_x_index +What: /sys/.../buffer/scan_elements/in_anglvel_y_index +What: /sys/.../buffer/scan_elements/in_anglvel_z_index +What: /sys/.../buffer/scan_elements/in_magn_x_index +What: /sys/.../buffer/scan_elements/in_magn_y_index +What: /sys/.../buffer/scan_elements/in_magn_z_index +What: /sys/.../buffer/scan_elements/in_incli_x_index +What: /sys/.../buffer/scan_elements/in_incli_y_index +What: /sys/.../buffer/scan_elements/in_timestamp_index +KernelVersion: 2.6.37 +Contact: linux-iio@vger.kernel.org +Description: + A single positive integer specifying the position of this + scan element in the buffer. Note these are not dependent on + what is enabled and may not be contiguous. Thus for user-space + to establish the full layout these must be used in conjunction + with all _en attributes to establish which channels are present, + and the relevant _type attributes to establish the data storage + format. + +What: /sys/.../iio:deviceX/in_anglvel_z_quadrature_correction_raw +KernelVersion: 2.6.38 +Contact: linux-iio@vger.kernel.org +Description: + This attribute is used to read the amount of quadrature error + present in the device at a given time. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523 new file mode 100644 index 0000000..2ce9c3f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523 @@ -0,0 +1,37 @@ +What: /sys/bus/iio/devices/iio:deviceX/pll2_feedback_clk_present +What: /sys/bus/iio/devices/iio:deviceX/pll2_reference_clk_present +What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_a_present +What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_b_present +What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_test_present +What: /sys/bus/iio/devices/iio:deviceX/vcxo_clk_present +KernelVersion: 3.4.0 +Contact: linux-iio@vger.kernel.org +Description: + Reading returns either '1' or '0'. + '1' means that the clock in question is present. + '0' means that the clock is missing. + +What: /sys/bus/iio/devices/iio:deviceX/pllY_locked +KernelVersion: 3.4.0 +Contact: linux-iio@vger.kernel.org +Description: + Reading returns either '1' or '0'. '1' means that the + pllY is locked. + +What: /sys/bus/iio/devices/iio:deviceX/store_eeprom +KernelVersion: 3.4.0 +Contact: linux-iio@vger.kernel.org +Description: + Writing '1' stores the current device configuration into + on-chip EEPROM. After power-up or chip reset the device will + automatically load the saved configuration. + +What: /sys/bus/iio/devices/iio:deviceX/sync_dividers +KernelVersion: 3.4.0 +Contact: linux-iio@vger.kernel.org +Description: + Writing '1' triggers the clock distribution synchronization + functionality. All dividers are reset and the channels start + with their predefined phase offsets (out_altvoltageY_phase). + Writing this file has the effect as driving the external + /SYNC pin low. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 new file mode 100644 index 0000000..d89aded --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 @@ -0,0 +1,21 @@ +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_resolution +KernelVersion: 3.4.0 +Contact: linux-iio@vger.kernel.org +Description: + Stores channel Y frequency resolution/channel spacing in Hz. + The value given directly influences the MODULUS used by + the fractional-N PLL. It is assumed that the algorithm + that is used to compute the various dividers, is able to + generate proper values for multiples of channel spacing. + +What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_refin_frequency +KernelVersion: 3.4.0 +Contact: linux-iio@vger.kernel.org +Description: + Sets channel Y REFin frequency in Hz. In some clock chained + applications, the reference frequency used by the PLL may + change during runtime. This attribute allows the user to + adjust the reference frequency accordingly. + The value written has no effect until out_altvoltageY_frequency + is updated. Consider to use out_altvoltageY_powerdown to power + down the PLL and it's RFOut buffers during REFin changes. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als b/Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als new file mode 100644 index 0000000..22c5ea6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als @@ -0,0 +1,61 @@ +What: /sys/.../events/in_illuminance0_thresh_either_en +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Event generated when channel passes one of the four thresholds + in each direction (rising|falling) and a zone change occurs. + The corresponding light zone can be read from + in_illuminance0_zone. + +What: /sys/.../events/in_illuminance0_threshY_hysteresis +Date: May 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Get the hysteresis for thresholds Y, that is, + threshY_hysteresis = threshY_raising - threshY_falling + +What: /sys/.../events/illuminance_threshY_falling_value +What: /sys/.../events/illuminance_threshY_raising_value +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Specifies the value of threshold that the device is comparing + against for the events enabled by + in_illuminance0_thresh_either_en (0..255), where Y in 0..3. + + Note that threshY_falling must be less than or equal to + threshY_raising. + + These thresholds correspond to the eight zone-boundary + registers (boundaryY_{low,high}) and define the five light + zones. + +What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_zone +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Get the current light zone (0..4) as defined by the + in_illuminance0_threshY_{falling,rising} thresholds. + +What: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw +Date: May 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Get output current for channel Y (0..255), that is, + out_currentY_currentZ_raw, where Z is the current zone. + +What: /sys/bus/iio/devices/iio:deviceX/out_currentY_currentZ_raw +Date: May 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Set the output current for channel out_currentY when in zone + Z (0..255), where Y in 0..2 and Z in 0..4. + + These values correspond to the ALS-mapper target registers for + ALS-mapper Y + 1. diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd index dbedafb..3c17b62 100644 --- a/Documentation/ABI/testing/sysfs-bus-rbd +++ b/Documentation/ABI/testing/sysfs-bus-rbd @@ -35,8 +35,14 @@ name pool - The pool where this rbd image resides. The pool-name pair is unique - per rados system. + The name of the storage pool where this rbd image resides. + An rbd image name is unique within its pool. + +pool_id + + The unique identifier for the rbd image's pool. This is + a permanent attribute of the pool. A pool's id will never + change. size @@ -65,11 +71,11 @@ snap_* Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name> ------------------------------------------------------------- -id +snap_id The rados internal snapshot id assigned for this snapshot -size +snap_size The size of the image when this snapshot was taken. diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index 7c22a532..5f75f8f 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -135,6 +135,17 @@ Description: for the device and attempt to bind to it. For example: # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id + Reading from this file will list all dynamically added + device IDs in the same format, with one entry per + line. For example: + # cat /sys/bus/usb/drivers/foo/new_id + 8086 10f5 + dead beef 06 + f00d cafe + + The list will be truncated at PAGE_SIZE bytes due to + sysfs restrictions. + What: /sys/bus/usb-serial/drivers/.../new_id Date: October 2011 Contact: linux-usb@vger.kernel.org @@ -157,6 +168,10 @@ Description: match the driver to the device. For example: # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id + Reading from this file will list the dynamically added + device IDs, exactly like reading from the entry + "/sys/bus/usb/drivers/.../new_id" + What: /sys/bus/usb/device/.../avoid_reset_quirk Date: December 2009 Contact: Oliver Neukum <oliver@neukum.org> @@ -189,7 +204,19 @@ Contact: Matthew Garrett <mjg@redhat.com> Description: Some information about whether a given USB device is physically fixed to the platform can be inferred from a - combination of hub decriptor bits and platform-specific data + combination of hub descriptor bits and platform-specific data such as ACPI. This file will read either "removable" or "fixed" if the information is available, and "unknown" - otherwise.
\ No newline at end of file + otherwise. + +What: /sys/bus/usb/devices/.../ltm_capable +Date: July 2012 +Contact: Sarah Sharp <sarah.a.sharp@linux.intel.com> +Description: + USB 3.0 devices may optionally support Latency Tolerance + Messaging (LTM). They indicate their support by setting a bit + in the bmAttributes field of their SuperSpeed BOS descriptors. + If that bit is set for the device, ltm_capable will read "yes". + If the device doesn't support LTM, the file will read "no". + The file will be present for all speeds of USB devices, and will + always read "no" for USB 1.1 and USB 2.0 devices. diff --git a/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533 b/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533 new file mode 100644 index 0000000..77cf7ac --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight-driver-lm3533 @@ -0,0 +1,48 @@ +What: /sys/class/backlight/<backlight>/als_channel +Date: May 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Get the ALS output channel used as input in + ALS-current-control mode (0, 1), where + + 0 - out_current0 (backlight 0) + 1 - out_current1 (backlight 1) + +What: /sys/class/backlight/<backlight>/als_en +Date: May 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Enable ALS-current-control mode (0, 1). + +What: /sys/class/backlight/<backlight>/id +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Get the id of this backlight (0, 1). + +What: /sys/class/backlight/<backlight>/linear +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Set the brightness-mapping mode (0, 1), where + + 0 - exponential mode + 1 - linear mode + +What: /sys/class/backlight/<backlight>/pwm +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Set the PWM-input control mask (5 bits), where + + bit 5 - PWM-input enabled in Zone 4 + bit 4 - PWM-input enabled in Zone 3 + bit 3 - PWM-input enabled in Zone 2 + bit 2 - PWM-input enabled in Zone 1 + bit 1 - PWM-input enabled in Zone 0 + bit 0 - PWM-input enabled diff --git a/Documentation/ABI/testing/sysfs-class-extcon b/Documentation/ABI/testing/sysfs-class-extcon new file mode 100644 index 0000000..20ab361 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-extcon @@ -0,0 +1,97 @@ +What: /sys/class/extcon/.../ +Date: February 2012 +Contact: MyungJoo Ham <myungjoo.ham@samsung.com> +Description: + Provide a place in sysfs for the extcon objects. + This allows accessing extcon specific variables. + The name of extcon object denoted as ... is the name given + with extcon_dev_register. + + One extcon device denotes a single external connector + port. An external connector may have multiple cables + attached simultaneously. Many of docks, cradles, and + accessory cables have such capability. For example, + the 30-pin port of Nuri board (/arch/arm/mach-exynos) + may have both HDMI and Charger attached, or analog audio, + video, and USB cables attached simulteneously. + + If there are cables mutually exclusive with each other, + such binary relations may be expressed with extcon_dev's + mutually_exclusive array. + +What: /sys/class/extcon/.../name +Date: February 2012 +Contact: MyungJoo Ham <myungjoo.ham@samsung.com> +Description: + The /sys/class/extcon/.../name shows the name of the extcon + object. If the extcon object has an optional callback + "show_name" defined, the callback will provide the name with + this sysfs node. + +What: /sys/class/extcon/.../state +Date: February 2012 +Contact: MyungJoo Ham <myungjoo.ham@samsung.com> +Description: + The /sys/class/extcon/.../state shows and stores the cable + attach/detach information of the corresponding extcon object. + If the extcon object has an optional callback "show_state" + defined, the showing function is overriden with the optional + callback. + + If the default callback for showing function is used, the + format is like this: + # cat state + USB_OTG=1 + HDMI=0 + TA=1 + EAR_JACK=0 + # + In this example, the extcon device have USB_OTG and TA + cables attached and HDMI and EAR_JACK cables detached. + + In order to update the state of an extcon device, enter a hex + state number starting with 0x. + echo 0xHEX > state + + This updates the whole state of the extcon dev. + Inputs of all the methods are required to meet the + mutually_exclusive contidions if they exist. + + It is recommended to use this "global" state interface if + you need to enter the value atomically. The later state + interface associated with each cable cannot update + multiple cable states of an extcon device simultaneously. + +What: /sys/class/extcon/.../cable.x/name +Date: February 2012 +Contact: MyungJoo Ham <myungjoo.ham@samsung.com> +Description: + The /sys/class/extcon/.../cable.x/name shows the name of cable + "x" (integer between 0 and 31) of an extcon device. + +What: /sys/class/extcon/.../cable.x/state +Date: February 2012 +Contact: MyungJoo Ham <myungjoo.ham@samsung.com> +Description: + The /sys/class/extcon/.../cable.x/name shows and stores the + state of cable "x" (integer between 0 and 31) of an extcon + device. The state value is either 0 (detached) or 1 + (attached). + +What: /sys/class/extcon/.../mutually_exclusive/... +Date: December 2011 +Contact: MyungJoo Ham <myungjoo.ham@samsung.com> +Description: + Shows the relations of mutually exclusiveness. For example, + if the mutually_exclusive array of extcon_dev is + {0x3, 0x5, 0xC, 0x0}, the, the output is: + # ls mutually_exclusive/ + 0x3 + 0x5 + 0xc + # + + Note that mutually_exclusive is a sub-directory of the extcon + device and the file names under the mutually_exclusive + directory show the mutually-exclusive sets, not the contents + of the files. diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-lm3533 b/Documentation/ABI/testing/sysfs-class-led-driver-lm3533 new file mode 100644 index 0000000..620ebb3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led-driver-lm3533 @@ -0,0 +1,65 @@ +What: /sys/class/leds/<led>/als_channel +Date: May 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Set the ALS output channel to use as input in + ALS-current-control mode (1, 2), where + + 1 - out_current1 + 2 - out_current2 + +What: /sys/class/leds/<led>/als_en +Date: May 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Enable ALS-current-control mode (0, 1). + +What: /sys/class/leds/<led>/falltime +What: /sys/class/leds/<led>/risetime +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Set the pattern generator fall and rise times (0..7), where + + 0 - 2048 us + 1 - 262 ms + 2 - 524 ms + 3 - 1.049 s + 4 - 2.097 s + 5 - 4.194 s + 6 - 8.389 s + 7 - 16.78 s + +What: /sys/class/leds/<led>/id +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Get the id of this led (0..3). + +What: /sys/class/leds/<led>/linear +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Set the brightness-mapping mode (0, 1), where + + 0 - exponential mode + 1 - linear mode + +What: /sys/class/leds/<led>/pwm +Date: April 2012 +KernelVersion: 3.5 +Contact: Johan Hovold <jhovold@gmail.com> +Description: + Set the PWM-input control mask (5 bits), where + + bit 5 - PWM-input enabled in Zone 4 + bit 4 - PWM-input enabled in Zone 3 + bit 3 - PWM-input enabled in Zone 2 + bit 2 - PWM-input enabled in Zone 1 + bit 1 - PWM-input enabled in Zone 0 + bit 0 - PWM-input enabled diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd index 4d55a18..938ef71 100644 --- a/Documentation/ABI/testing/sysfs-class-mtd +++ b/Documentation/ABI/testing/sysfs-class-mtd @@ -123,3 +123,55 @@ Description: half page, or a quarter page). In the case of ECC NOR, it is the ECC block size. + +What: /sys/class/mtd/mtdX/ecc_strength +Date: April 2012 +KernelVersion: 3.4 +Contact: linux-mtd@lists.infradead.org +Description: + Maximum number of bit errors that the device is capable of + correcting within each region covering an ecc step. This will + always be a non-negative integer. Note that some devices will + have multiple ecc steps within each writesize region. + + In the case of devices lacking any ECC capability, it is 0. + +What: /sys/class/mtd/mtdX/bitflip_threshold +Date: April 2012 +KernelVersion: 3.4 +Contact: linux-mtd@lists.infradead.org +Description: + This allows the user to examine and adjust the criteria by which + mtd returns -EUCLEAN from mtd_read() and mtd_read_oob(). If the + maximum number of bit errors that were corrected on any single + region comprising an ecc step (as reported by the driver) equals + or exceeds this value, -EUCLEAN is returned. Otherwise, absent + an error, 0 is returned. Higher layers (e.g., UBI) use this + return code as an indication that an erase block may be + degrading and should be scrutinized as a candidate for being + marked as bad. + + The initial value may be specified by the flash device driver. + If not, then the default value is ecc_strength. + + The introduction of this feature brings a subtle change to the + meaning of the -EUCLEAN return code. Previously, it was + interpreted to mean simply "one or more bit errors were + corrected". Its new interpretation can be phrased as "a + dangerously high number of bit errors were corrected on one or + more regions comprising an ecc step". The precise definition of + "dangerously high" can be adjusted by the user with + bitflip_threshold. Users are discouraged from doing this, + however, unless they know what they are doing and have intimate + knowledge of the properties of their device. Broadly speaking, + bitflip_threshold should be low enough to detect genuine erase + block degradation, but high enough to avoid the consequences of + a persistent return value of -EUCLEAN on devices where sticky + bitflips occur. Note that if bitflip_threshold exceeds + ecc_strength, -EUCLEAN is never returned by the read operations. + Conversely, if bitflip_threshold is zero, -EUCLEAN is always + returned, absent a hard error. + + This is generally applicable only to NAND flash devices with ECC + capability. It is ignored on devices lacking ECC capability; + i.e., devices for which ecc_strength is zero. diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh index b218e0f..c81fe89 100644 --- a/Documentation/ABI/testing/sysfs-class-net-mesh +++ b/Documentation/ABI/testing/sysfs-class-net-mesh @@ -14,6 +14,15 @@ Description: mesh will be sent using multiple interfaces at the same time (if available). +What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance +Date: November 2011 +Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> +Description: + Indicates whether the bridge loop avoidance feature + is enabled. This feature detects and avoids loops + between the mesh and devices bridged with the soft + interface <mesh_iface>. + What: /sys/class/net/<mesh_iface>/mesh/fragmentation Date: October 2010 Contact: Andreas Langer <an.langer@gmx.de> diff --git a/Documentation/ABI/testing/sysfs-devices-edac b/Documentation/ABI/testing/sysfs-devices-edac new file mode 100644 index 0000000..30ee78a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-edac @@ -0,0 +1,140 @@ +What: /sys/devices/system/edac/mc/mc*/reset_counters +Date: January 2006 +Contact: linux-edac@vger.kernel.org +Description: This write-only control file will zero all the statistical + counters for UE and CE errors on the given memory controller. + Zeroing the counters will also reset the timer indicating how + long since the last counter were reset. This is useful for + computing errors/time. Since the counters are always reset + at driver initialization time, no module/kernel parameter + is available. + +What: /sys/devices/system/edac/mc/mc*/seconds_since_reset +Date: January 2006 +Contact: linux-edac@vger.kernel.org +Description: This attribute file displays how many seconds have elapsed + since the last counter reset. This can be used with the error + counters to measure error rates. + +What: /sys/devices/system/edac/mc/mc*/mc_name +Date: January 2006 +Contact: linux-edac@vger.kernel.org +Description: This attribute file displays the type of memory controller + that is being utilized. + +What: /sys/devices/system/edac/mc/mc*/size_mb +Date: January 2006 +Contact: linux-edac@vger.kernel.org +Description: This attribute file displays, in count of megabytes, of memory + that this memory controller manages. + +What: /sys/devices/system/edac/mc/mc*/ue_count +Date: January 2006 +Contact: linux-edac@vger.kernel.org +Description: This attribute file displays the total count of uncorrectable + errors that have occurred on this memory controller. If + panic_on_ue is set, this counter will not have a chance to + increment, since EDAC will panic the system + +What: /sys/devices/system/edac/mc/mc*/ue_noinfo_count +Date: January 2006 +Contact: linux-edac@vger.kernel.org +Description: This attribute file displays the number of UEs that have + occurred on this memory controller with no information as to + which DIMM slot is having errors. + +What: /sys/devices/system/edac/mc/mc*/ce_count +Date: January 2006 +Contact: linux-edac@vger.kernel.org +Description: This attribute file displays the total count of correctable + errors that have occurred on this memory controller. This + count is very important to examine. CEs provide early + indications that a DIMM is beginning to fail. This count + field should be monitored for non-zero values and report + such information to the system administrator. + +What: /sys/devices/system/edac/mc/mc*/ce_noinfo_count +Date: January 2006 +Contact: linux-edac@vger.kernel.org +Description: This attribute file displays the number of CEs that + have occurred on this memory controller wherewith no + information as to which DIMM slot is having errors. Memory is + handicapped, but operational, yet no information is available + to indicate which slot the failing memory is in. This count + field should be also be monitored for non-zero values. + +What: /sys/devices/system/edac/mc/mc*/sdram_scrub_rate +Date: February 2007 +Contact: linux-edac@vger.kernel.org +Description: Read/Write attribute file that controls memory scrubbing. + The scrubbing rate used by the memory controller is set by + writing a minimum bandwidth in bytes/sec to the attribute file. + The rate will be translated to an internal value that gives at + least the specified rate. + Reading the file will return the actual scrubbing rate employed. + If configuration fails or memory scrubbing is not implemented, + the value of the attribute file will be -1. + +What: /sys/devices/system/edac/mc/mc*/max_location +Date: April 2012 +Contact: Mauro Carvalho Chehab <mchehab@redhat.com> + linux-edac@vger.kernel.org +Description: This attribute file displays the information about the last + available memory slot in this memory controller. It is used by + userspace tools in order to display the memory filling layout. + +What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/size +Date: April 2012 +Contact: Mauro Carvalho Chehab <mchehab@redhat.com> + linux-edac@vger.kernel.org +Description: This attribute file will display the size of dimm or rank. + For dimm*/size, this is the size, in MB of the DIMM memory + stick. For rank*/size, this is the size, in MB for one rank + of the DIMM memory stick. On single rank memories (1R), this + is also the total size of the dimm. On dual rank (2R) memories, + this is half the size of the total DIMM memories. + +What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_dev_type +Date: April 2012 +Contact: Mauro Carvalho Chehab <mchehab@redhat.com> + linux-edac@vger.kernel.org +Description: This attribute file will display what type of DRAM device is + being utilized on this DIMM (x1, x2, x4, x8, ...). + +What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_edac_mode +Date: April 2012 +Contact: Mauro Carvalho Chehab <mchehab@redhat.com> + linux-edac@vger.kernel.org +Description: This attribute file will display what type of Error detection + and correction is being utilized. For example: S4ECD4ED would + mean a Chipkill with x4 DRAM. + +What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_label +Date: April 2012 +Contact: Mauro Carvalho Chehab <mchehab@redhat.com> + linux-edac@vger.kernel.org +Description: This control file allows this DIMM to have a label assigned + to it. With this label in the module, when errors occur + the output can provide the DIMM label in the system log. + This becomes vital for panic events to isolate the + cause of the UE event. + DIMM Labels must be assigned after booting, with information + that correctly identifies the physical slot with its + silk screen label. This information is currently very + motherboard specific and determination of this information + must occur in userland at this time. + +What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_location +Date: April 2012 +Contact: Mauro Carvalho Chehab <mchehab@redhat.com> + linux-edac@vger.kernel.org +Description: This attribute file will display the location (csrow/channel, + branch/channel/slot or channel/slot) of the dimm or rank. + +What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_mem_type +Date: April 2012 +Contact: Mauro Carvalho Chehab <mchehab@redhat.com> + linux-edac@vger.kernel.org +Description: This attribute file will display what type of memory is + currently on this csrow. Normally, either buffered or + unbuffered memory (for example, Unbuffered-DDR3). diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 840f7d6..45000f0 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -96,16 +96,26 @@ Description: is read-only. If the device is not enabled to wake up the system from sleep states, this attribute is not present. -What: /sys/devices/.../power/wakeup_hit_count -Date: September 2010 +What: /sys/devices/.../power/wakeup_abort_count +Date: February 2012 Contact: Rafael J. Wysocki <rjw@sisk.pl> Description: - The /sys/devices/.../wakeup_hit_count attribute contains the + The /sys/devices/.../wakeup_abort_count attribute contains the number of times the processing of a wakeup event associated with - the device might prevent the system from entering a sleep state. - This attribute is read-only. If the device is not enabled to - wake up the system from sleep states, this attribute is not - present. + 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. + +What: /sys/devices/.../power/wakeup_expire_count +Date: February 2012 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +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. What: /sys/devices/.../power/wakeup_active Date: September 2010 @@ -148,6 +158,17 @@ Description: not enabled to wake up the system from sleep states, this attribute is not present. +What: /sys/devices/.../power/wakeup_prevent_sleep_time_ms +Date: February 2012 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +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 occuring. + This attribute is read-only. If the device is not enabled to + wake up the system from sleep states, this attribute is not + present. + What: /sys/devices/.../power/autosuspend_delay_ms Date: September 2010 Contact: Alan Stern <stern@rowland.harvard.edu> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index e7be75b..5dab364 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -9,31 +9,6 @@ Description: /sys/devices/system/cpu/cpu#/ -What: /sys/devices/system/cpu/sched_mc_power_savings - /sys/devices/system/cpu/sched_smt_power_savings -Date: June 2006 -Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> -Description: Discover and adjust the kernel's multi-core scheduler support. - - Possible values are: - - 0 - No power saving load balance (default value) - 1 - Fill one thread/core/package first for long running threads - 2 - Also bias task wakeups to semi-idle cpu package for power - savings - - sched_mc_power_savings is dependent upon SCHED_MC, which is - itself architecture dependent. - - sched_smt_power_savings is dependent upon SCHED_SMT, which - is itself architecture dependent. - - The two files are independent of each other. It is possible - that one file may be present without the other. - - Introduced by git commit 5c45bf27. - - What: /sys/devices/system/cpu/kernel_max /sys/devices/system/cpu/offline /sys/devices/system/cpu/online diff --git a/Documentation/ABI/testing/sysfs-devices-system-xen_cpu b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu new file mode 100644 index 0000000..9ca02fb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-system-xen_cpu @@ -0,0 +1,20 @@ +What: /sys/devices/system/xen_cpu/ +Date: May 2012 +Contact: Liu, Jinsong <jinsong.liu@intel.com> +Description: + A collection of global/individual Xen physical cpu attributes + + Individual physical cpu attributes are contained in + subdirectories named by the Xen's logical cpu number, e.g.: + /sys/devices/system/xen_cpu/xen_cpu#/ + + +What: /sys/devices/system/xen_cpu/xen_cpu#/online +Date: May 2012 +Contact: Liu, Jinsong <jinsong.liu@intel.com> +Description: + Interface to online/offline Xen physical cpus + + When running under Xen platform, it provide user interface + to online/offline physical cpus, except cpu0 due to several + logic restrictions and assumptions. diff --git a/Documentation/ABI/testing/sysfs-driver-hid-lenovo-tpkbd b/Documentation/ABI/testing/sysfs-driver-hid-lenovo-tpkbd new file mode 100644 index 0000000..57b92cb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-lenovo-tpkbd @@ -0,0 +1,38 @@ +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_to_select +Date: July 2011 +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. + +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. + +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. + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/select_right +Date: July 2011 +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. + +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). + +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). + diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu b/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu new file mode 100644 index 0000000..b42922c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu @@ -0,0 +1,77 @@ +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/buttons +Date: Mai 2012 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split into general settings and + button settings. buttons holds informations about button layout. + When written, this file lets one write the respective profile + buttons to the mouse. The data has to be 47 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/control +Date: Mai 2012 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When written, this file lets one select which data from which + profile will be read next. The data has to be 3 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/general +Date: Mai 2012 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split into general settings and + button settings. profile holds informations like resolution, sensitivity + and light effects. + When written, this file lets one write the respective profile + settings back to the mouse. The data has to be 43 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/info +Date: Mai 2012 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When read, this file returns general data like firmware version. + The data is 8 bytes long. + This file is readonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/macro +Date: Mai 2012 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: When written, this file lets one store macros with max 500 + keystrokes for a specific button for a specific profile. + Button and profile numbers are included in written data. + The data has to be 2083 bytes long. + Before reading this file, control has to be written to select + which profile and key to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/profile +Date: Mai 2012 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The mouse can store 5 profiles which can be switched by the + press of a button. profile holds number of actual profile. + This value is persistent, so its value determines the profile + that's active when the mouse is powered on next time. + When written, the mouse activates the set profile immediately. + The data has to be 3 bytes long. + The mouse will reject invalid data. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/sensor +Date: July 2012 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: The mouse has a Avago ADNS-3090 sensor. + This file allows reading and writing of the mouse sensors registers. + The data has to be 4 bytes long. +Users: http://roccat.sourceforge.net + diff --git a/Documentation/ABI/testing/sysfs-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom index 0130d66..8d55a83 100644 --- a/Documentation/ABI/testing/sysfs-driver-wacom +++ b/Documentation/ABI/testing/sysfs-driver-wacom @@ -9,15 +9,24 @@ Description: or 0 otherwise. Writing to this file one of these values switches reporting speed. +What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/ +Date: May 2012 +Kernel Version: 3.5 +Contact: linux-bluetooth@vger.kernel.org +Description: + LED selector for Intuos4 WL. There are 4 leds, but only one LED + can be lit at a time. Max brightness is 127. + What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led Date: August 2011 Contact: linux-input@vger.kernel.org Description: Attribute group for control of the status LEDs and the OLEDs. This attribute group is only available for Intuos 4 M, L, - and XL (with LEDs and OLEDs) and Cintiq 21UX2 and Cintiq 24HD - (LEDs only). Therefore its presence implicitly signifies the - presence of said LEDs and OLEDs on the tablet device. + and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq + 21UX2 and Cintiq 24HD (LEDs only). Therefore its presence + implicitly signifies the presence of said LEDs and OLEDs on the + tablet device. What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance Date: August 2011 @@ -40,10 +49,10 @@ What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0 Date: August 2011 Contact: linux-input@vger.kernel.org Description: - Writing to this file sets which one of the four (for Intuos 4) - or of the right four (for Cintiq 21UX2 and Cintiq 24HD) status - LEDs is active (0..3). The other three LEDs on the same side are - always inactive. + Writing to this file sets which one of the four (for Intuos 4 + and Intuos 5) or of the right four (for Cintiq 21UX2 and Cintiq + 24HD) status LEDs is active (0..3). The other three LEDs on the + same side are always inactive. What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select Date: September 2011 diff --git a/Documentation/ABI/testing/sysfs-kernel-iommu_groups b/Documentation/ABI/testing/sysfs-kernel-iommu_groups new file mode 100644 index 0000000..9b31556 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-iommu_groups @@ -0,0 +1,14 @@ +What: /sys/kernel/iommu_groups/ +Date: May 2012 +KernelVersion: v3.5 +Contact: Alex Williamson <alex.williamson@redhat.com> +Description: /sys/kernel/iommu_groups/ contains a number of sub- + directories, each representing an IOMMU group. The + name of the sub-directory matches the iommu_group_id() + for the group, which is an integer value. Within each + subdirectory is another directory named "devices" with + links to the sysfs devices contained in this group. + The group directory also optionally contains a "name" + file if the IOMMU driver has chosen to register a more + common name for the group. +Users: diff --git a/Documentation/ABI/testing/sysfs-platform-asus-wmi b/Documentation/ABI/testing/sysfs-platform-asus-wmi index 2e7df91..019e1e2 100644 --- a/Documentation/ABI/testing/sysfs-platform-asus-wmi +++ b/Documentation/ABI/testing/sysfs-platform-asus-wmi @@ -29,3 +29,10 @@ KernelVersion: 2.6.39 Contact: "Corentin Chary" <corentincj@iksaif.net> Description: Control the card touchpad. 1 means on, 0 means off. + +What: /sys/devices/platform/<platform>/lid_resume +Date: May 2012 +KernelVersion: 3.5 +Contact: "AceLan Kao" <acelan.kao@canonical.com> +Description: + Resume on lid open. 1 means on, 0 means off. diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index b464d1276..2177726 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -172,3 +172,75 @@ Description: Reading from this file will display the current value, which is set to 1 MB by default. + +What: /sys/power/autosleep +Date: April 2012 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +Description: + The /sys/power/autosleep file can be written one of the strings + returned by reads from /sys/power/state. If that happens, a + work item attempting to trigger a transition of the system to + the sleep state represented by that string is queued up. This + attempt will only succeed if there are no active wakeup sources + in the system at that time. After every execution, regardless + of whether or not the attempt to put the system to sleep has + succeeded, the work item requeues itself until user space + writes "off" to /sys/power/autosleep. + + Reading from this file causes the last string successfully + written to it to be returned. + +What: /sys/power/wake_lock +Date: February 2012 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +Description: + The /sys/power/wake_lock file allows user space to create + wakeup source objects and activate them on demand (if one of + those wakeup sources is active, reads from the + /sys/power/wakeup_count file block or return false). When a + string without white space is written to /sys/power/wake_lock, + it will be assumed to represent a wakeup source name. If there + is a wakeup source object with that name, it will be activated + (unless active already). Otherwise, a new wakeup source object + will be registered, assigned the given name and activated. + If a string written to /sys/power/wake_lock contains white + space, the part of the string preceding the white space will be + regarded as a wakeup source name and handled as descrived above. + The other part of the string will be regarded as a timeout (in + nanoseconds) such that the wakeup source will be automatically + deactivated after it has expired. The timeout, if present, is + set regardless of the current state of the wakeup source object + in question. + + Reads from this file return a string consisting of the names of + wakeup sources created with the help of it that are active at + the moment, separated with spaces. + + +What: /sys/power/wake_unlock +Date: February 2012 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +Description: + The /sys/power/wake_unlock file allows user space to deactivate + wakeup sources created with the help of /sys/power/wake_lock. + When a string is written to /sys/power/wake_unlock, it will be + assumed to represent the name of a wakeup source to deactivate. + If a wakeup source object of that name exists and is active at + the moment, it will be deactivated. + + Reads from this file return a string consisting of the names of + wakeup sources created with the help of /sys/power/wake_lock + that are inactive at the moment, separated with spaces. + +What: /sys/power/pm_print_times +Date: May 2012 +Contact: Sameer Nanda <snanda@chromium.org> +Description: + The /sys/power/pm_print_times file allows user space to + control whether the time taken by devices to suspend and + resume is printed. These prints are useful for hunting down + devices that take too long to suspend or resume. + + Writing a "1" enables this printing while writing a "0" + disables it. The default value is "0". Reading from this file + will display the current value. diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index c58b236..cb9258b 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -671,8 +671,9 @@ ones already enabled by DEBUG. Chapter 14: Allocating memory The kernel provides the following general purpose memory allocators: -kmalloc(), kzalloc(), kcalloc(), vmalloc(), and vzalloc(). Please refer to -the API documentation for further information about them. +kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and +vzalloc(). Please refer to the API documentation for further information +about them. The preferred form for passing a size of a struct is the following: @@ -686,6 +687,17 @@ Casting the return value which is a void pointer is redundant. The conversion from void pointer to any other pointer type is guaranteed by the C programming language. +The preferred form for allocating an array is the following: + + p = kmalloc_array(n, sizeof(...), ...); + +The preferred form for allocating a zeroed array is the following: + + p = kcalloc(n, sizeof(...), ...); + +Both forms check for overflow on the allocation size n * sizeof(...), +and return NULL if that occurred. + Chapter 15: The inline disease diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt index 5c72eed..f503090 100644 --- a/Documentation/DMA-attributes.txt +++ b/Documentation/DMA-attributes.txt @@ -49,3 +49,45 @@ DMA_ATTR_NON_CONSISTENT lets the platform to choose to return either consistent or non-consistent memory as it sees fit. By using this API, you are guaranteeing to the platform that you have all the correct and necessary sync points for this memory in the driver. + +DMA_ATTR_NO_KERNEL_MAPPING +-------------------------- + +DMA_ATTR_NO_KERNEL_MAPPING lets the platform to avoid creating a kernel +virtual mapping for the allocated buffer. On some architectures creating +such mapping is non-trivial task and consumes very limited resources +(like kernel virtual address space or dma consistent address space). +Buffers allocated with this attribute can be only passed to user space +by calling dma_mmap_attrs(). By using this API, you are guaranteeing +that you won't dereference the pointer returned by dma_alloc_attr(). You +can threat it as a cookie that must be passed to dma_mmap_attrs() and +dma_free_attrs(). Make sure that both of these also get this attribute +set on each call. + +Since it is optional for platforms to implement +DMA_ATTR_NO_KERNEL_MAPPING, those that do not will simply ignore the +attribute and exhibit default behavior. + +DMA_ATTR_SKIP_CPU_SYNC +---------------------- + +By default dma_map_{single,page,sg} functions family transfer a given +buffer from CPU domain to device domain. Some advanced use cases might +require sharing a buffer between more than one device. This requires +having a mapping created separately for each device and is usually +performed by calling dma_map_{single,page,sg} function more than once +for the given buffer with device pointer to each device taking part in +the buffer sharing. The first call transfers a buffer from 'CPU' domain +to 'device' domain, what synchronizes CPU caches for the given region +(usually it means that the cache has been flushed or invalidated +depending on the dma direction). However, next calls to +dma_map_{single,page,sg}() for other devices will perform exactly the +same sychronization operation on the CPU cache. CPU cache sychronization +might be a time consuming operation, especially if the buffers are +large, so it is highly recommended to avoid it if possible. +DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of +the CPU cache for the given buffer assuming that it has been already +transferred to 'device' domain. This attribute can be also used for +dma_unmap_{single,page,sg} functions family to force buffer to stay in +device domain after releasing a mapping for it. Use this attribute with +care! diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index c5ac692..42e7f03 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -404,7 +404,6 @@ !Finclude/net/mac80211.h ieee80211_get_tkip_p1k !Finclude/net/mac80211.h ieee80211_get_tkip_p1k_iv !Finclude/net/mac80211.h ieee80211_get_tkip_p2k -!Finclude/net/mac80211.h ieee80211_key_removed </chapter> <chapter id="powersave"> @@ -516,7 +515,7 @@ !Finclude/net/mac80211.h ieee80211_start_tx_ba_cb_irqsafe !Finclude/net/mac80211.h ieee80211_stop_tx_ba_session !Finclude/net/mac80211.h ieee80211_stop_tx_ba_cb_irqsafe -!Finclude/net/mac80211.h rate_control_changed +!Finclude/net/mac80211.h ieee80211_rate_control_changed !Finclude/net/mac80211.h ieee80211_tx_rate_control !Finclude/net/mac80211.h rate_control_send_low </chapter> diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 66725a3..bc3d9f8c 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -6,7 +6,7 @@ # To add a new book the only step required is to add the book to the # list of DOCBOOKS. -DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \ +DOCBOOKS := z8530book.xml device-drivers.xml \ kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ writing_usb_driver.xml networking.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 7160652..00687ee 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -212,19 +212,6 @@ X!Edrivers/pci/hotplug.c <sect1><title>PCI Hotplug Support Library</title> !Edrivers/pci/hotplug/pci_hotplug_core.c </sect1> - <sect1><title>MCA Architecture</title> - <sect2><title>MCA Device Functions</title> - <para> - Refer to the file arch/x86/kernel/mca_32.c for more information. - </para> -<!-- FIXME: Removed for now since no structured comments in source -X!Earch/x86/kernel/mca_32.c ---> - </sect2> - <sect2><title>MCA Bus DMA</title> -!Iarch/x86/include/asm/mca_dma.h - </sect2> - </sect1> </chapter> <chapter id="firmware"> diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl index 07a9c48..eee7142 100644 --- a/Documentation/DocBook/kernel-hacking.tmpl +++ b/Documentation/DocBook/kernel-hacking.tmpl @@ -1289,7 +1289,7 @@ static struct block_device_operations opt_fops = { * Sparc assembly will do this to ya. */ C_LABEL(cputypvar): - .asciz "compatability" + .asciz "compatibility" /* Tested on SS-5, SS-10. Probably someone at Sun applied a spell-checker. */ .align 4 diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index 31df1aa..deb71ba 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -918,7 +918,7 @@ and other resources, etc. <title>HSM violation</title> <para> This error is indicated when STATUS value doesn't match HSM - requirement during issuing or excution any ATA/ATAPI command. + requirement during issuing or execution any ATA/ATAPI command. </para> <itemizedlist> diff --git a/Documentation/DocBook/mcabook.tmpl b/Documentation/DocBook/mcabook.tmpl deleted file mode 100644 index 467ccac..0000000 --- a/Documentation/DocBook/mcabook.tmpl +++ /dev/null @@ -1,107 +0,0 @@ -<?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="MCAGuide"> - <bookinfo> - <title>MCA Driver Programming Interface</title> - - <authorgroup> - <author> - <firstname>Alan</firstname> - <surname>Cox</surname> - <affiliation> - <address> - <email>alan@lxorguk.ukuu.org.uk</email> - </address> - </affiliation> - </author> - <author> - <firstname>David</firstname> - <surname>Weinehall</surname> - </author> - <author> - <firstname>Chris</firstname> - <surname>Beauregard</surname> - </author> - </authorgroup> - - <copyright> - <year>2000</year> - <holder>Alan Cox</holder> - <holder>David Weinehall</holder> - <holder>Chris Beauregard</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 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. - </para> - - <para> - 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., 59 Temple Place, Suite 330, Boston, - MA 02111-1307 USA - </para> - - <para> - For more details see the file COPYING in the source - distribution of Linux. - </para> - </legalnotice> - </bookinfo> - -<toc></toc> - - <chapter id="intro"> - <title>Introduction</title> - <para> - The MCA bus functions provide a generalised interface to find MCA - bus cards, to claim them for a driver, and to read and manipulate POS - registers without being aware of the motherboard internals or - certain deep magic specific to onboard devices. - </para> - <para> - The basic interface to the MCA bus devices is the slot. Each slot - is numbered and virtual slot numbers are assigned to the internal - devices. Using a pci_dev as other busses do does not really make - sense in the MCA context as the MCA bus resources require card - specific interpretation. - </para> - <para> - Finally the MCA bus functions provide a parallel set of DMA - functions mimicing the ISA bus DMA functions as closely as possible, - although also supporting the additional DMA functionality on the - MCA bus controllers. - </para> - </chapter> - <chapter id="bugs"> - <title>Known Bugs And Assumptions</title> - <para> - None. - </para> - </chapter> - - <chapter id="pubfunctions"> - <title>Public Functions Provided</title> -!Edrivers/mca/mca-legacy.c - </chapter> - - <chapter id="dmafunctions"> - <title>DMA Functions Provided</title> -!Iarch/x86/include/asm/mca_dma.h - </chapter> - -</book> diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 6c27f7b..b0964fb 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -2102,7 +2102,7 @@ Possible values are:</entry> <entry>integer</entry> </row> <row><entry spanname="descr">Cyclic intra macroblock refresh. This is the number of continuous macroblocks -refreshed every frame. Each frame a succesive set of macroblocks is refreshed until the cycle completes and starts from the +refreshed every frame. Each frame a successive set of macroblocks is refreshed until the cycle completes and starts from the top of the frame. Applicable to H264, H263 and MPEG4 encoder.</entry> </row> @@ -2262,7 +2262,7 @@ Applicable to the MPEG4 and H264 encoders.</entry> <entry>integer</entry> </row> <row><entry spanname="descr">The Video Buffer Verifier size in kilobytes, it is used as a limitation of frame skip. -The VBV is defined in the standard as a mean to verify that the produced stream will be succesfully decoded. +The VBV is defined in the standard as a mean to verify that the produced stream will be successfully decoded. The standard describes it as "Part of a hypothetical decoder that is conceptually connected to the output of the encoder. Its purpose is to provide a constraint on the variability of the data rate that an encoder or editing process may produce.". @@ -2275,7 +2275,7 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry> <entry>integer</entry> </row> <row><entry spanname="descr">The Coded Picture Buffer size in kilobytes, it is used as a limitation of frame skip. -The CPB is defined in the H264 standard as a mean to verify that the produced stream will be succesfully decoded. +The CPB is defined in the H264 standard as a mean to verify that the produced stream will be successfully decoded. Applicable to the H264 encoder.</entry> </row> diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index 0c674be..e0aedb7 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -1119,8 +1119,6 @@ in this page</entry> These constants are defined in nand.h. They are ored together to describe the chip functionality. <programlisting> -/* Chip can not auto increment pages */ -#define NAND_NO_AUTOINCR 0x00000001 /* Buswitdh is 16 bit */ #define NAND_BUSWIDTH_16 0x00000002 /* Device supports partial programming without padding */ diff --git a/Documentation/HOWTO b/Documentation/HOWTO index f7ade3b..59c080f 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO @@ -218,16 +218,16 @@ The development process Linux kernel development process currently consists of a few different main kernel "branches" and lots of different subsystem-specific kernel branches. These different branches are: - - main 2.6.x kernel tree - - 2.6.x.y -stable kernel tree - - 2.6.x -git kernel patches + - main 3.x kernel tree + - 3.x.y -stable kernel tree + - 3.x -git kernel patches - subsystem specific kernel trees and patches - - the 2.6.x -next kernel tree for integration tests + - the 3.x -next kernel tree for integration tests -2.6.x kernel tree +3.x kernel tree ----------------- -2.6.x kernels are maintained by Linus Torvalds, and can be found on -kernel.org in the pub/linux/kernel/v2.6/ directory. Its development +3.x kernels are maintained by Linus Torvalds, and can be found on +kernel.org in the pub/linux/kernel/v3.x/ directory. Its development process is as follows: - As soon as a new kernel is released a two weeks window is open, during this period of time maintainers can submit big diffs to @@ -262,20 +262,20 @@ mailing list about kernel releases: released according to perceived bug status, not according to a preconceived timeline." -2.6.x.y -stable kernel tree +3.x.y -stable kernel tree --------------------------- -Kernels with 4-part versions are -stable kernels. They contain +Kernels with 3-part versions are -stable kernels. They contain relatively small and critical fixes for security problems or significant -regressions discovered in a given 2.6.x kernel. +regressions discovered in a given 3.x kernel. This is the recommended branch for users who want the most recent stable kernel and are not interested in helping test development/experimental versions. -If no 2.6.x.y kernel is available, then the highest numbered 2.6.x +If no 3.x.y kernel is available, then the highest numbered 3.x kernel is the current stable kernel. -2.6.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and +3.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and are released as needs dictate. The normal release period is approximately two weeks, but it can be longer if there are no pressing problems. A security-related problem, instead, can cause a release to happen almost @@ -285,7 +285,7 @@ The file Documentation/stable_kernel_rules.txt in the kernel tree documents what kinds of changes are acceptable for the -stable tree, and how the release process works. -2.6.x -git patches +3.x -git patches ------------------ These are daily snapshots of Linus' kernel tree which are managed in a git repository (hence the name.) These patches are usually released @@ -317,13 +317,13 @@ revisions to it, and maintainers can mark patches as under review, accepted, or rejected. Most of these patchwork sites are listed at http://patchwork.kernel.org/. -2.6.x -next kernel tree for integration tests +3.x -next kernel tree for integration tests --------------------------------------------- -Before updates from subsystem trees are merged into the mainline 2.6.x +Before updates from subsystem trees are merged into the mainline 3.x tree, they need to be integration-tested. For this purpose, a special testing repository exists into which virtually all subsystem trees are pulled on an almost daily basis: - http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git + http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git http://linux.f-seidel.de/linux-next/pmwiki/ This way, the -next kernel gives a summary outlook onto what will be diff --git a/Documentation/Makefile b/Documentation/Makefile index 30b656e..31d302b 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -1,3 +1,3 @@ obj-m := DocBook/ accounting/ auxdisplay/ connector/ \ filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \ - pcmcia/ spi/ timers/ watchdog/src/ + pcmcia/ spi/ timers/ watchdog/src/ misc-devices/mei/ diff --git a/Documentation/ManagementStyle b/Documentation/ManagementStyle index a5f0ea5..a211ee8 100644 --- a/Documentation/ManagementStyle +++ b/Documentation/ManagementStyle @@ -178,7 +178,7 @@ sadly that you are one too, and that while we can all bask in the secure knowledge that we're better than the average person (let's face it, nobody ever believes that they're average or below-average), we should also admit that we're not the sharpest knife around, and there will be -other people that are less of an idiot that you are. +other people that are less of an idiot than you are. Some people react badly to smart people. Others take advantage of them. diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 5c8d749..fc103d7 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -162,9 +162,9 @@ over a rather long period of time, but improvements are always welcome! when publicizing a pointer to a structure that can be traversed by an RCU read-side critical section. -5. If call_rcu(), or a related primitive such as call_rcu_bh() or - call_rcu_sched(), is used, the callback function must be - written to be called from softirq context. In particular, +5. If call_rcu(), or a related primitive such as call_rcu_bh(), + call_rcu_sched(), or call_srcu() is used, the callback function + must be written to be called from softirq context. In particular, it cannot block. 6. Since synchronize_rcu() can block, it cannot be called from @@ -202,11 +202,12 @@ over a rather long period of time, but improvements are always welcome! updater uses call_rcu_sched() or synchronize_sched(), then the corresponding readers must disable preemption, possibly by calling rcu_read_lock_sched() and rcu_read_unlock_sched(). - If the updater uses synchronize_srcu(), the the corresponding - readers must use srcu_read_lock() and srcu_read_unlock(), - and with the same srcu_struct. The rules for the expedited - primitives are the same as for their non-expedited counterparts. - Mixing things up will result in confusion and broken kernels. + If the updater uses synchronize_srcu() or call_srcu(), + the the corresponding readers must use srcu_read_lock() and + srcu_read_unlock(), and with the same srcu_struct. The rules for + the expedited primitives are the same as for their non-expedited + counterparts. Mixing things up will result in confusion and + broken kernels. One exception to this rule: rcu_read_lock() and rcu_read_unlock() may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh() @@ -333,14 +334,14 @@ over a rather long period of time, but improvements are always welcome! victim CPU from ever going offline.) 14. SRCU (srcu_read_lock(), srcu_read_unlock(), srcu_dereference(), - synchronize_srcu(), and synchronize_srcu_expedited()) may only - be invoked from process context. Unlike other forms of RCU, it - -is- permissible to block in an SRCU read-side critical section - (demarked by srcu_read_lock() and srcu_read_unlock()), hence the - "SRCU": "sleepable RCU". Please note that if you don't need - to sleep in read-side critical sections, you should be using - RCU rather than SRCU, because RCU is almost always faster and - easier to use than is SRCU. + synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu()) + may only be invoked from process context. Unlike other forms of + RCU, it -is- permissible to block in an SRCU read-side critical + section (demarked by srcu_read_lock() and srcu_read_unlock()), + hence the "SRCU": "sleepable RCU". Please note that if you + don't need to sleep in read-side critical sections, you should be + using RCU rather than SRCU, because RCU is almost always faster + and easier to use than is SRCU. If you need to enter your read-side critical section in a hardirq or exception handler, and then exit that same read-side @@ -353,8 +354,8 @@ over a rather long period of time, but improvements are always welcome! cleanup_srcu_struct(). These are passed a "struct srcu_struct" that defines the scope of a given SRCU domain. Once initialized, the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock() - synchronize_srcu(), and synchronize_srcu_expedited(). A given - synchronize_srcu() waits only for SRCU read-side critical + synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu(). + A given synchronize_srcu() waits only for SRCU read-side critical sections governed by srcu_read_lock() and srcu_read_unlock() calls that have been passed the same srcu_struct. This property is what makes sleeping read-side critical sections tolerable -- @@ -374,7 +375,7 @@ over a rather long period of time, but improvements are always welcome! requiring SRCU's read-side deadlock immunity or low read-side realtime latency. - Note that, rcu_assign_pointer() relates to SRCU just as they do + Note that, rcu_assign_pointer() relates to SRCU just as it does to other forms of RCU. 15. The whole point of call_rcu(), synchronize_rcu(), and friends diff --git a/Documentation/RCU/rcubarrier.txt b/Documentation/RCU/rcubarrier.txt index e439a0e..38428c1 100644 --- a/Documentation/RCU/rcubarrier.txt +++ b/Documentation/RCU/rcubarrier.txt @@ -79,8 +79,6 @@ complete. Pseudo-code using rcu_barrier() is as follows: 2. Execute rcu_barrier(). 3. Allow the module to be unloaded. -Quick Quiz #1: Why is there no srcu_barrier()? - The rcutorture module makes use of rcu_barrier in its exit function as follows: @@ -162,7 +160,7 @@ for any pre-existing callbacks to complete. Then lines 55-62 print status and do operation-specific cleanup, and then return, permitting the module-unload operation to be completed. -Quick Quiz #2: Is there any other situation where rcu_barrier() might +Quick Quiz #1: Is there any other situation where rcu_barrier() might be required? Your module might have additional complications. For example, if your @@ -242,7 +240,7 @@ reaches zero, as follows: 4 complete(&rcu_barrier_completion); 5 } -Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes +Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes immediately (thus incrementing rcu_barrier_cpu_count to the value one), but the other CPU's rcu_barrier_func() invocations are delayed for a full grace period? Couldn't this result in @@ -259,12 +257,7 @@ so that your module may be safely unloaded. Answers to Quick Quizzes -Quick Quiz #1: Why is there no srcu_barrier()? - -Answer: Since there is no call_srcu(), there can be no outstanding SRCU - callbacks. Therefore, there is no need to wait for them. - -Quick Quiz #2: Is there any other situation where rcu_barrier() might +Quick Quiz #1: Is there any other situation where rcu_barrier() might be required? Answer: Interestingly enough, rcu_barrier() was not originally @@ -278,7 +271,7 @@ Answer: Interestingly enough, rcu_barrier() was not originally implementing rcutorture, and found that rcu_barrier() solves this problem as well. -Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes +Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes immediately (thus incrementing rcu_barrier_cpu_count to the value one), but the other CPU's rcu_barrier_func() invocations are delayed for a full grace period? Couldn't this result in diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt index 375d3fb..7dce8a1 100644 --- a/Documentation/RCU/torture.txt +++ b/Documentation/RCU/torture.txt @@ -47,6 +47,16 @@ irqreader Says to invoke RCU readers from irq level. This is currently permit this. (Or, more accurately, variants of RCU that do -not- permit this know to ignore this variable.) +n_barrier_cbs If this is nonzero, RCU barrier testing will be conducted, + in which case n_barrier_cbs specifies the number of + RCU callbacks (and corresponding kthreads) to use for + this testing. The value cannot be negative. If you + specify this to be non-zero when torture_type indicates a + synchronous RCU implementation (one for which a member of + the synchronize_rcu() rather than the call_rcu() family is + used -- see the documentation for torture_type below), an + error will be reported and no testing will be carried out. + nfakewriters This is the number of RCU fake writer threads to run. Fake writer threads repeatedly use the synchronous "wait for current readers" function of the interface selected by @@ -164,11 +174,20 @@ torture_type The type of RCU to test, with string values as follows: and synchronize_rcu_bh_expedited(). "srcu": srcu_read_lock(), srcu_read_unlock() and + call_srcu(). + + "srcu_sync": srcu_read_lock(), srcu_read_unlock() and synchronize_srcu(). "srcu_expedited": srcu_read_lock(), srcu_read_unlock() and synchronize_srcu_expedited(). + "srcu_raw": srcu_read_lock_raw(), srcu_read_unlock_raw(), + and call_srcu(). + + "srcu_raw_sync": srcu_read_lock_raw(), srcu_read_unlock_raw(), + and synchronize_srcu(). + "sched": preempt_disable(), preempt_enable(), and call_rcu_sched(). @@ -188,7 +207,7 @@ OUTPUT The statistics output is as follows: rcu-torture:--- Start of test: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4 - rcu-torture: rtc: (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767 + rcu-torture: rtc: (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767 rcu-torture: Reader Pipe: 727860534 34213 0 0 0 0 0 0 0 0 0 rcu-torture: Reader Batch: 727877838 17003 0 0 0 0 0 0 0 0 0 rcu-torture: Free-Block Circulation: 155440 155440 155440 155440 155440 155440 155440 155440 155440 155440 0 @@ -230,6 +249,9 @@ o "rtmbe": A non-zero value indicates that rcutorture believes that rcu_assign_pointer() and rcu_dereference() are not working correctly. This value should be zero. +o "rtbe": A non-zero value indicates that one of the rcu_barrier() + family of functions is not working correctly. + o "rtbke": rcutorture was unable to create the real-time kthreads used to force RCU priority inversion. This value should be zero. diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 6bbe8dc..69ee188 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -833,9 +833,9 @@ sched: Critical sections Grace period Barrier SRCU: Critical sections Grace period Barrier - srcu_read_lock synchronize_srcu N/A - srcu_read_unlock synchronize_srcu_expedited - srcu_read_lock_raw + srcu_read_lock synchronize_srcu srcu_barrier + srcu_read_unlock call_srcu + srcu_read_lock_raw synchronize_srcu_expedited srcu_read_unlock_raw srcu_dereference diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 4468ce2..c379a2a 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -150,7 +150,8 @@ be able to justify all violations that remain in your patch. Look through the MAINTAINERS file and the source code, and determine if your change applies to a specific subsystem of the kernel, with -an assigned maintainer. If so, e-mail that person. +an assigned maintainer. If so, e-mail that person. The script +scripts/get_maintainer.pl can be very useful at this step. If no maintainer is listed, or the maintainer does not respond, send your patch to the primary Linux kernel developer's mailing list, diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX index 91c24a1..36420e1 100644 --- a/Documentation/arm/00-INDEX +++ b/Documentation/arm/00-INDEX @@ -4,8 +4,6 @@ Booting - requirements for booting Interrupts - ARM Interrupt subsystem documentation -IXP2000 - - Release Notes for Linux on Intel's IXP2000 Network Processor msm - MSM specific documentation Netwinder diff --git a/Documentation/arm/IXP2000 b/Documentation/arm/IXP2000 deleted file mode 100644 index 68d21d9..0000000 --- a/Documentation/arm/IXP2000 +++ /dev/null @@ -1,69 +0,0 @@ - -------------------------------------------------------------------------- -Release Notes for Linux on Intel's IXP2000 Network Processor - -Maintained by Deepak Saxena <dsaxena@plexity.net> -------------------------------------------------------------------------- - -1. Overview - -Intel's IXP2000 family of NPUs (IXP2400, IXP2800, IXP2850) is designed -for high-performance network applications such high-availability -telecom systems. In addition to an XScale core, it contains up to 8 -"MicroEngines" that run special code, several high-end networking -interfaces (UTOPIA, SPI, etc), a PCI host bridge, one serial port, -flash interface, and some other odds and ends. For more information, see: - -http://developer.intel.com - -2. Linux Support - -Linux currently supports the following features on the IXP2000 NPUs: - -- On-chip serial -- PCI -- Flash (MTD/JFFS2) -- I2C through GPIO -- Timers (watchdog, OS) - -That is about all we can support under Linux ATM b/c the core networking -components of the chip are accessed via Intel's closed source SDK. -Please contact Intel directly on issues with using those. There is -also a mailing list run by some folks at Princeton University that might -be of help: https://lists.cs.princeton.edu/mailman/listinfo/ixp2xxx - -WHATEVER YOU DO, DO NOT POST EMAIL TO THE LINUX-ARM OR LINUX-ARM-KERNEL -MAILING LISTS REGARDING THE INTEL SDK. - -3. Supported Platforms - -- Intel IXDP2400 Reference Platform -- Intel IXDP2800 Reference Platform -- Intel IXDP2401 Reference Platform -- Intel IXDP2801 Reference Platform -- RadiSys ENP-2611 - -4. Usage Notes - -- The IXP2000 platforms usually have rather complex PCI bus topologies - with large memory space requirements. In addition, b/c of the way the - Intel SDK is designed, devices are enumerated in a very specific - way. B/c of this this, we use "pci=firmware" option in the kernel - command line so that we do not re-enumerate the bus. - -- IXDP2x01 systems have variable clock tick rates that we cannot determine - via HW registers. The "ixdp2x01_clk=XXX" cmd line options allow you - to pass the clock rate to the board port. - -5. Thanks - -The IXP2000 work has been funded by Intel Corp. and MontaVista Software, Inc. - -The following people have contributed patches/comments/etc: - -Naeem F. Afzal -Lennert Buytenhek -Jeffrey Daly - -------------------------------------------------------------------------- -Last Update: 8/09/2004 diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS index 888ae7b..a564cee 100644 --- a/Documentation/arm/OMAP/DSS +++ b/Documentation/arm/OMAP/DSS @@ -47,6 +47,51 @@ flexible way to enable non-common multi-display configuration. In addition to modelling the hardware overlays, omapdss supports virtual overlays and overlay managers. These can be used when updating a display with CPU or system DMA. +omapdss driver support for audio +-------------------------------- +There exist several display technologies and standards that support audio as +well. Hence, it is relevant to update the DSS device driver to provide an audio +interface that may be used by an audio driver or any other driver interested in +the functionality. + +The audio_enable function is intended to prepare the relevant +IP for playback (e.g., enabling an audio FIFO, taking in/out of reset +some IP, enabling companion chips, etc). It is intended to be called before +audio_start. The audio_disable function performs the reverse operation and is +intended to be called after audio_stop. + +While a given DSS device driver may support audio, it is possible that for +certain configurations audio is not supported (e.g., an HDMI display using a +VESA video timing). The audio_supported function is intended to query whether +the current configuration of the display supports audio. + +The audio_config function is intended to configure all the relevant audio +parameters of the display. In order to make the function independent of any +specific DSS device driver, a struct omap_dss_audio is defined. Its purpose +is to contain all the required parameters for audio configuration. At the +moment, such structure contains pointers to IEC-60958 channel status word +and CEA-861 audio infoframe structures. This should be enough to support +HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958. + +The audio_enable/disable, audio_config and audio_supported functions could be +implemented as functions that may sleep. Hence, they should not be called +while holding a spinlock or a readlock. + +The audio_start/audio_stop function is intended to effectively start/stop audio +playback after the configuration has taken place. These functions are designed +to be used in an atomic context. Hence, audio_start should return quickly and be +called only after all the needed resources for audio playback (audio FIFOs, +DMA channels, companion chips, etc) have been enabled to begin data transfers. +audio_stop is designed to only stop the audio transfers. The resources used +for playback are released using audio_disable. + +The enum omap_dss_audio_state may be used to help the implementations of +the interface to keep track of the audio state. The initial state is _DISABLED; +then, the state transitions to _CONFIGURED, and then, when it is ready to +play audio, to _ENABLED. The state _PLAYING is used when the audio is being +rendered. + + Panel and controller drivers ---------------------------- @@ -156,6 +201,7 @@ timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw) "pal" and "ntsc" panel_name tear_elim Tearing elimination 0=off, 1=on +output_type Output type (video encoder only): "composite" or "svideo" There are also some debugfs files at <debugfs>/omapdss/ which show information about clocks and registers. diff --git a/Documentation/arm/SPEAr/overview.txt b/Documentation/arm/SPEAr/overview.txt index 253a35c..65610bf 100644 --- a/Documentation/arm/SPEAr/overview.txt +++ b/Documentation/arm/SPEAr/overview.txt @@ -8,53 +8,56 @@ Introduction weblink : http://www.st.com/spear The ST Microelectronics SPEAr range of ARM9/CortexA9 System-on-Chip CPUs are - supported by the 'spear' platform of ARM Linux. Currently SPEAr300, - SPEAr310, SPEAr320 and SPEAr600 SOCs are supported. Support for the SPEAr13XX - series is in progress. + supported by the 'spear' platform of ARM Linux. Currently SPEAr1310, + SPEAr1340, SPEAr300, SPEAr310, SPEAr320 and SPEAr600 SOCs are supported. Hierarchy in SPEAr is as follows: SPEAr (Platform) - SPEAr3XX (3XX SOC series, based on ARM9) - SPEAr300 (SOC) - - SPEAr300_EVB (Evaluation Board) + - SPEAr300 Evaluation Board - SPEAr310 (SOC) - - SPEAr310_EVB (Evaluation Board) + - SPEAr310 Evaluation Board - SPEAr320 (SOC) - - SPEAr320_EVB (Evaluation Board) + - SPEAr320 Evaluation Board - SPEAr6XX (6XX SOC series, based on ARM9) - SPEAr600 (SOC) - - SPEAr600_EVB (Evaluation Board) + - SPEAr600 Evaluation Board - SPEAr13XX (13XX SOC series, based on ARM CORTEXA9) - - SPEAr1300 (SOC) + - SPEAr1310 (SOC) + - SPEAr1310 Evaluation Board + - SPEAr1340 (SOC) + - SPEAr1340 Evaluation Board Configuration ------------- A generic configuration is provided for each machine, and can be used as the default by - make spear600_defconfig - make spear300_defconfig - make spear310_defconfig - make spear320_defconfig + make spear13xx_defconfig + make spear3xx_defconfig + make spear6xx_defconfig Layout ------ - The common files for multiple machine families (SPEAr3XX, SPEAr6XX and - SPEAr13XX) are located in the platform code contained in arch/arm/plat-spear + The common files for multiple machine families (SPEAr3xx, SPEAr6xx and + SPEAr13xx) are located in the platform code contained in arch/arm/plat-spear with headers in plat/. Each machine series have a directory with name arch/arm/mach-spear followed by series name. Like mach-spear3xx, mach-spear6xx and mach-spear13xx. - Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c and for - spear6xx is mach-spear6xx/spear6xx.c. mach-spear* also contain soc/machine - specific files, like spear300.c, spear310.c, spear320.c and spear600.c. - mach-spear* also contains board specific files for each machine type. + Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c, for + spear6xx is mach-spear6xx/spear6xx.c and for spear13xx family is + mach-spear13xx/spear13xx.c. mach-spear* also contain soc/machine specific + files, like spear1310.c, spear1340.c spear300.c, spear310.c, spear320.c and + spear600.c. mach-spear* doesn't contains board specific files as they fully + support Flattened Device Tree. Document Author --------------- - Viresh Kumar, (c) 2010 ST Microelectronics + Viresh Kumar <viresh.linux@gmail.com>, (c) 2010-2012 ST Microelectronics diff --git a/Documentation/blackfin/bfin-gpio-notes.txt b/Documentation/blackfin/bfin-gpio-notes.txt index d36b01f..d245f39 100644 --- a/Documentation/blackfin/bfin-gpio-notes.txt +++ b/Documentation/blackfin/bfin-gpio-notes.txt @@ -53,7 +53,7 @@ 3. But there are some exceptions - Kernel permit the identical GPIO be requested both as GPIO and GPIO - interrut. + interrupt. Some drivers, like gpio-keys, need this behavior. Kernel only print out warning messages like, bfin-gpio: GPIO 24 is already reserved by gpio-keys: BTN0, and you are diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index 8e74980..4a0b64c 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -370,15 +370,12 @@ To mount a cgroup hierarchy with just the cpuset and memory subsystems, type: # mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1 -To change the set of subsystems bound to a mounted hierarchy, just -remount with different options: -# mount -o remount,cpuset,blkio hier1 /sys/fs/cgroup/rg1 - -Now memory is removed from the hierarchy and blkio is added. - -Note this will add blkio to the hierarchy but won't remove memory or -cpuset, because the new options are appended to the old ones: -# mount -o remount,blkio /sys/fs/cgroup/rg1 +While remounting cgroups is currently supported, it is not recommend +to use it. Remounting allows changing bound subsystems and +release_agent. Rebinding is hardly useful as it only works when the +hierarchy is empty and release_agent itself should be replaced with +conventional fsnotify. The support for remounting will be removed in +the future. To Specify a hierarchy's release_agent: # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \ @@ -637,16 +634,6 @@ void exit(struct task_struct *task) Called during task exit. -int populate(struct cgroup *cgrp) -(cgroup_mutex held by caller) - -Called after creation of a cgroup to allow a subsystem to populate -the cgroup directory with file entries. The subsystem should make -calls to cgroup_add_file() with objects of type cftype (see -include/linux/cgroup.h for details). Note that although this -method can return an error code, the error code is currently not -always handled well. - void post_clone(struct cgroup *cgrp) (cgroup_mutex held by caller) @@ -656,7 +643,7 @@ example in cpusets, no task may attach before 'cpus' and 'mems' are set up. void bind(struct cgroup *root) -(cgroup_mutex and ss->hierarchy_mutex held by caller) +(cgroup_mutex held by caller) Called when a cgroup subsystem is rebound to a different hierarchy and root cgroup. Currently this will only involve movement between diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 9b1067a..dd88540 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -184,12 +184,14 @@ behind this approach is that a cgroup that aggressively uses a shared page will eventually get charged for it (once it is uncharged from the cgroup that brought it in -- this will happen on memory pressure). +But see section 8.2: when moving a task to another cgroup, its pages may +be recharged to the new cgroup, if move_charge_at_immigrate has been chosen. + Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used. When you do swapoff and make swapped-out pages of shmem(tmpfs) to be backed into memory in force, charges for pages are accounted against the caller of swapoff rather than the users of shmem. - 2.4 Swap Extension (CONFIG_CGROUP_MEM_RES_CTLR_SWAP) Swap Extension allows you to record charge for swap. A swapped-in page is @@ -374,14 +376,15 @@ cgroup might have some charge associated with it, even though all tasks have migrated away from it. (because we charge against pages, not against tasks.) -Such charges are freed or moved to their parent. At moving, both of RSS -and CACHES are moved to parent. -rmdir() may return -EBUSY if freeing/moving fails. See 5.1 also. +We move the stats to root (if use_hierarchy==0) or parent (if +use_hierarchy==1), and no change on the charge except uncharging +from the child. Charges recorded in swap information is not updated at removal of cgroup. Recorded information is discarded and a cgroup which uses swap (swapcache) will be charged as a new owner of it. +About use_hierarchy, see Section 6. 5. Misc. interfaces. @@ -394,13 +397,15 @@ will be charged as a new owner of it. 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 and this cgroup will be empty. This may return -EBUSY if - VM is too busy to free/move all pages immediately. + moved to parent(if use_hierarchy==1) or root (if use_hierarchy==0) and this + cgroup will be empty. Typical use case of this interface is that calling this before rmdir(). Because rmdir() moves all pages to parent, some out-of-use page caches can be moved to the parent. If you want to avoid that, force_empty will be useful. + About use_hierarchy, see Section 6. + 5.2 stat file memory.stat file includes following statistics @@ -430,17 +435,10 @@ hierarchical_memory_limit - # of bytes of memory limit with regard to hierarchy hierarchical_memsw_limit - # of bytes of memory+swap limit with regard to hierarchy under which memory cgroup is. -total_cache - sum of all children's "cache" -total_rss - sum of all children's "rss" -total_mapped_file - sum of all children's "cache" -total_pgpgin - sum of all children's "pgpgin" -total_pgpgout - sum of all children's "pgpgout" -total_swap - sum of all children's "swap" -total_inactive_anon - sum of all children's "inactive_anon" -total_active_anon - sum of all children's "active_anon" -total_inactive_file - sum of all children's "inactive_file" -total_active_file - sum of all children's "active_file" -total_unevictable - sum of all children's "unevictable" +total_<counter> - # hierarchical version of <counter>, which in + addition to the cgroup's own value includes the + sum of all hierarchical children's values of + <counter>, i.e. total_cache # The following additional stats are dependent on CONFIG_DEBUG_VM. @@ -622,8 +620,7 @@ memory cgroup. bit | what type of charges would be moved ? -----+------------------------------------------------------------------------ 0 | A charge of an anonymous page(or swap of it) used by the target task. - | Those pages and swaps must be used only by the target task. You must - | enable Swap Extension(see 2.4) to enable move of swap charges. + | You must enable Swap Extension(see 2.4) to enable move of swap charges. -----+------------------------------------------------------------------------ 1 | A charge of file pages(normal file, tmpfs file(e.g. ipc shared memory) | and swaps of tmpfs file) mmapped by the target task. Unlike the case of @@ -636,8 +633,6 @@ memory cgroup. 8.3 TODO -- Implement madvise(2) to let users decide the vma to be moved or not to be - moved. - All of moving charge operations are done under cgroup_mutex. It's not good behavior to hold the mutex too long, so we may need some trick. diff --git a/Documentation/cgroups/resource_counter.txt b/Documentation/cgroups/resource_counter.txt index 95b24d7..0c4a344 100644 --- a/Documentation/cgroups/resource_counter.txt +++ b/Documentation/cgroups/resource_counter.txt @@ -77,11 +77,11 @@ to work with it. where the charging failed. d. int res_counter_charge_locked - (struct res_counter *rc, unsigned long val) + (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). + held). The force parameter indicates whether we can bypass the limit. e. void res_counter_uncharge[_locked] (struct res_counter *rc, unsigned long val) @@ -92,6 +92,14 @@ to work with it. The _locked routines imply that the res_counter->lock is taken. + f. void res_counter_uncharge_until + (struct res_counter *rc, struct res_counter *top, + unsinged long val) + + Almost same as res_cunter_uncharge() but propagation of uncharge + stops when rc == top. This is useful when kill a res_coutner in + child cgroup. + 2.1 Other accounting routines There are more routines that may help you with common needs, like diff --git a/Documentation/connector/cn_test.c b/Documentation/connector/cn_test.c index 7764594..adcca03 100644 --- a/Documentation/connector/cn_test.c +++ b/Documentation/connector/cn_test.c @@ -69,9 +69,13 @@ static int cn_test_want_notify(void) return -ENOMEM; } - nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh)); + nlh = nlmsg_put(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh), 0); + if (!nlh) { + kfree_skb(skb); + return -EMSGSIZE; + } - msg = (struct cn_msg *)NLMSG_DATA(nlh); + msg = nlmsg_data(nlh); memset(msg, 0, size0); @@ -117,11 +121,6 @@ static int cn_test_want_notify(void) pr_info("request was sent: group=0x%x\n", ctl->group); return 0; - -nlmsg_failure: - pr_err("failed to send %u.%u\n", msg->seq, msg->ack); - kfree_skb(skb); - return -EINVAL; } #endif diff --git a/Documentation/cris/README b/Documentation/cris/README index d9b0868..8dbdb1a 100644 --- a/Documentation/cris/README +++ b/Documentation/cris/README @@ -1,38 +1,34 @@ -Linux 2.4 on the CRIS architecture -================================== -$Id: README,v 1.7 2001/04/19 12:38:32 bjornw Exp $ +Linux on the CRIS architecture +============================== -This is a port of Linux 2.4 to Axis Communications ETRAX 100LX embedded -network CPU. For more information about CRIS and ETRAX please see further -below. +This is a port of Linux to Axis Communications ETRAX 100LX, +ETRAX FS and ARTPEC-3 embedded network CPUs. + +For more information about CRIS and ETRAX please see further below. In order to compile this you need a version of gcc with support for the -ETRAX chip family. Please see this link for more information on how to +ETRAX chip family. Please see this link for more information on how to download the compiler and other tools useful when building and booting software for the ETRAX platform: -http://developer.axis.com/doc/software/devboard_lx/install-howto.html - -<more specific information should come in this document later> +http://developer.axis.com/wiki/doku.php?id=axis:install-howto-2_20 What is CRIS ? -------------- CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU architecture in Axis Communication AB's range of embedded network CPU's, -called ETRAX. The latest CPU is called ETRAX 100LX, where LX stands for -'Linux' because the chip was designed to be a good host for the Linux -operating system. +called ETRAX. The ETRAX 100LX chip -------------------- -For reference, please see the press-release: +For reference, please see the following link: -http://www.axis.com/news/us/001101_etrax.htm +http://www.axis.com/products/dev_etrax_100lx/index.htm -The ETRAX 100LX is a 100 MIPS processor with 8kB cache, MMU, and a very broad -range of built-in interfaces, all with modern scatter/gather DMA. +The ETRAX 100LX is a 100 MIPS processor with 8kB cache, MMU, and a very broad +range of built-in interfaces, all with modern scatter/gather DMA. Memory interfaces: @@ -51,20 +47,28 @@ I/O interfaces: * SCSI * two parallel-ports * two generic 8-bit ports - - (not all interfaces are available at the same time due to chip pin + + (not all interfaces are available at the same time due to chip pin multiplexing) -The previous version of the ETRAX, the ETRAX 100, sits in almost all of -Axis shipping thin-servers like the Axis 2100 web camera or the ETRAX 100 -developer-board. It lacks an MMU so the Linux we run on that is a version -of uClinux (Linux 2.0 without MM-support) ported to the CRIS architecture. -The new Linux 2.4 port has full MM and needs a CPU with an MMU, so it will -not run on the ETRAX 100. +ETRAX 100LX is CRISv10 architecture. + + +The ETRAX FS and ARTPEC-3 chips +------------------------------- -A version of the Axis developer-board with ETRAX 100LX (running Linux -2.4) is now available. For more information please see developer.axis.com. +The ETRAX FS is a 200MHz 32-bit RISC processor with on-chip 16kB +I-cache and 16kB D-cache and with a wide range of device interfaces +including multiple high speed serial ports and an integrated USB 1.1 PHY. +The ARTPEC-3 is a variant of the ETRAX FS with additional IO-units +used by the Axis Communications network cameras. + +See below link for more information: + +http://www.axis.com/products/dev_etrax_fs/index.htm + +ETRAX FS and ARTPEC-3 are both CRISv32 architectures. Bootlog ------- @@ -182,10 +186,6 @@ SwapFree: 0 kB -rwxr-xr-x 1 342 100 16252 Jan 01 00:00 telnetd -(All programs are statically linked to the libc at this point - we have not ported the - shared libraries yet) - - diff --git a/Documentation/device-mapper/striped.txt b/Documentation/device-mapper/striped.txt index f34d323..45f3b91 100644 --- a/Documentation/device-mapper/striped.txt +++ b/Documentation/device-mapper/striped.txt @@ -9,15 +9,14 @@ devices in parallel. Parameters: <num devs> <chunk size> [<dev path> <offset>]+ <num devs>: Number of underlying devices. - <chunk size>: Size of each chunk of data. Must be a power-of-2 and at - least as large as the system's PAGE_SIZE. + <chunk size>: Size of each chunk of data. Must be at least as + large as the system's PAGE_SIZE. <dev path>: Full pathname to the underlying block-device, or a "major:minor" device-number. <offset>: Starting sector within the device. One or more underlying devices can be specified. The striped device size must -be a multiple of the chunk size and a multiple of the number of underlying -devices. +be a multiple of the chunk size multiplied by the number of underlying devices. Example scripts diff --git a/Documentation/device-mapper/thin-provisioning.txt b/Documentation/device-mapper/thin-provisioning.txt index 3370bc4..30b8b83 100644 --- a/Documentation/device-mapper/thin-provisioning.txt +++ b/Documentation/device-mapper/thin-provisioning.txt @@ -231,6 +231,9 @@ i) Constructor no_discard_passdown: Don't pass discards down to the underlying data device, but just remove the mapping. + read_only: Don't allow any changes to be made to the pool + metadata. + Data block size must be between 64KB (128 sectors) and 1GB (2097152 sectors) inclusive. @@ -239,7 +242,7 @@ ii) Status <transaction id> <used metadata blocks>/<total metadata blocks> <used data blocks>/<total data blocks> <held metadata root> - + [no_]discard_passdown ro|rw transaction id: A 64-bit number used by userspace to help synchronise with metadata @@ -257,6 +260,21 @@ ii) Status held root. This feature is not yet implemented so '-' is always returned. + discard_passdown|no_discard_passdown + Whether or not discards are actually being passed down to the + underlying device. When this is enabled when loading the table, + it can get disabled if the underlying device doesn't support it. + + ro|rw + If the pool encounters certain types of device failures it will + drop into a read-only metadata mode in which no changes to + the pool metadata (like allocating new blocks) are permitted. + + In serious cases where even a read-only mode is deemed unsafe + no further I/O will be permitted and the status will just + contain the string 'Fail'. The userspace recovery tools + should then be used. + iii) Messages create_thin <dev id> @@ -287,6 +305,17 @@ iii) Messages the current transaction id is when you change it with this compare-and-swap message. + reserve_metadata_snap + + Reserve a copy of the data mapping btree for use by userland. + This allows userland to inspect the mappings as they were when + this message was executed. Use the pool's status command to + get the root block associated with the metadata snapshot. + + release_metadata_snap + + Release a previously reserved copy of the data mapping btree. + 'thin' target ------------- @@ -318,3 +347,7 @@ regain some space then send the 'trim' message to the pool. ii) Status <nr mapped sectors> <highest mapped sector> + + If the pool has encountered device errors and failed, the status + will just contain the string 'Fail'. The userspace recovery + tools should then be used. diff --git a/Documentation/device-mapper/verity.txt b/Documentation/device-mapper/verity.txt index 32e4879..9884681 100644 --- a/Documentation/device-mapper/verity.txt +++ b/Documentation/device-mapper/verity.txt @@ -7,39 +7,39 @@ This target is read-only. Construction Parameters ======================= - <version> <dev> <hash_dev> <hash_start> + <version> <dev> <hash_dev> <data_block_size> <hash_block_size> <num_data_blocks> <hash_start_block> <algorithm> <digest> <salt> <version> - This is the version number of the on-disk format. + This is the type of the on-disk hash format. 0 is the original format used in the Chromium OS. - The salt is appended when hashing, digests are stored continuously and - the rest of the block is padded with zeros. + The salt is appended when hashing, digests are stored continuously and + the rest of the block is padded with zeros. 1 is the current format that should be used for new devices. - The salt is prepended when hashing and each digest is - padded with zeros to the power of two. + The salt is prepended when hashing and each digest is + padded with zeros to the power of two. <dev> - This is the device containing the data the integrity of which needs to be + This is the device containing data, the integrity of which needs to be checked. It may be specified as a path, like /dev/sdaX, or a device number, <major>:<minor>. <hash_dev> - This is the device that that supplies the hash tree data. It may be + This is the device that supplies the hash tree data. It may be specified similarly to the device path and may be the same device. If the - same device is used, the hash_start should be outside of the dm-verity - configured device size. + same device is used, the hash_start should be outside the configured + dm-verity device. <data_block_size> - The block size on a data device. Each block corresponds to one digest on - the hash device. + The block size on a data device in bytes. + Each block corresponds to one digest on the hash device. <hash_block_size> - The size of a hash block. + The size of a hash block in bytes. <num_data_blocks> The number of data blocks on the data device. Additional blocks are @@ -65,7 +65,7 @@ Construction Parameters Theory of operation =================== -dm-verity is meant to be setup as part of a verified boot path. This +dm-verity is meant to be set up as part of a verified boot path. This may be anything ranging from a boot using tboot or trustedgrub to just booting from a known-good device (like a USB drive or CD). @@ -73,20 +73,20 @@ When a dm-verity device is configured, it is expected that the caller has been authenticated in some way (cryptographic signatures, etc). After instantiation, all hashes will be verified on-demand during disk access. If they cannot be verified up to the root node of the -tree, the root hash, then the I/O will fail. This should identify +tree, the root hash, then the I/O will fail. This should detect tampering with any data on the device and the hash data. Cryptographic hashes are used to assert the integrity of the device on a -per-block basis. This allows for a lightweight hash computation on first read -into the page cache. Block hashes are stored linearly-aligned to the nearest -block the size of a page. +per-block basis. This allows for a lightweight hash computation on first read +into the page cache. Block hashes are stored linearly, aligned to the nearest +block size. Hash Tree --------- Each node in the tree is a cryptographic hash. If it is a leaf node, the hash -is of some block data on disk. If it is an intermediary node, then the hash is -of a number of child nodes. +of some data block on disk is calculated. If it is an intermediary node, +the hash of a number of child nodes is calculated. Each entry in the tree is a collection of neighboring nodes that fit in one block. The number is determined based on block_size and the size of the @@ -110,63 +110,23 @@ alg = sha256, num_blocks = 32768, block_size = 4096 On-disk format ============== -Below is the recommended on-disk format. The verity kernel code does not -read the on-disk header. It only reads the hash blocks which directly -follow the header. It is expected that a user-space tool will verify the -integrity of the verity_header and then call dmsetup with the correct -parameters. Alternatively, the header can be omitted and the dmsetup -parameters can be passed via the kernel command-line in a rooted chain -of trust where the command-line is verified. +The verity kernel code does not read the verity metadata on-disk header. +It only reads the hash blocks which directly follow the header. +It is expected that a user-space tool will verify the integrity of the +verity header. -The on-disk format is especially useful in cases where the hash blocks -are on a separate partition. The magic number allows easy identification -of the partition contents. Alternatively, the hash blocks can be stored -in the same partition as the data to be verified. In such a configuration -the filesystem on the partition would be sized a little smaller than -the full-partition, leaving room for the hash blocks. - -struct superblock { - uint8_t signature[8] - "verity\0\0"; - - uint8_t version; - 1 - current format - - uint8_t data_block_bits; - log2(data block size) - - uint8_t hash_block_bits; - log2(hash block size) - - uint8_t pad1[1]; - zero padding - - uint16_t salt_size; - big-endian salt size - - uint8_t pad2[2]; - zero padding - - uint32_t data_blocks_hi; - big-endian high 32 bits of the 64-bit number of data blocks - - uint32_t data_blocks_lo; - big-endian low 32 bits of the 64-bit number of data blocks - - uint8_t algorithm[16]; - cryptographic algorithm - - uint8_t salt[384]; - salt (the salt size is specified above) - - uint8_t pad3[88]; - zero padding to 512-byte boundary -} +Alternatively, the header can be omitted and the dmsetup parameters can +be passed via the kernel command-line in a rooted chain of trust where +the command-line is verified. Directly following the header (and with sector number padded to the next hash block boundary) are the hash blocks which are stored a depth at a time (starting from the root), sorted in order of increasing index. +The full specification of kernel parameters and on-disk metadata format +is available at the cryptsetup project's wiki page + http://code.google.com/p/cryptsetup/wiki/DMVerity + Status ====== V (for Valid) is returned if every check performed so far was valid. @@ -174,21 +134,22 @@ If any check failed, C (for Corruption) is returned. Example ======= - -Setup a device: - dmsetup create vroot --table \ - "0 2097152 "\ - "verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\ +Set up a device: + # dmsetup create vroot --readonly --table \ + "0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 "\ "4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\ "1234000000000000000000000000000000000000000000000000000000000000" A command line tool veritysetup is available to compute or verify -the hash tree or activate the kernel driver. This is available from -the LVM2 upstream repository and may be supplied as a package called -device-mapper-verity-tools: - git://sources.redhat.com/git/lvm2 - http://sourceware.org/git/?p=lvm2.git - http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2 - -veritysetup -a vroot /dev/sda1 /dev/sda2 \ - 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 +the hash tree or activate the kernel device. This is available from +the cryptsetup upstream repository http://code.google.com/p/cryptsetup/ +(as a libcryptsetup extension). + +Create hash on the device: + # veritysetup format /dev/sda1 /dev/sda2 + ... + Root hash: 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 + +Activate the device: + # veritysetup create vroot /dev/sda1 /dev/sda2 \ + 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 0038318..b6251cc 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -98,7 +98,8 @@ Your cooperation is appreciated. 8 = /dev/random Nondeterministic random number gen. 9 = /dev/urandom Faster, less secure random number gen. 10 = /dev/aio Asynchronous I/O notification interface - 11 = /dev/kmsg Writes to this come out as printk's + 11 = /dev/kmsg Writes to this come out as printk's, reads + export the buffered printk records. 12 = /dev/oldmem Used by crashdump kernels to access the memory of the kernel that crashed. @@ -846,13 +847,7 @@ Your cooperation is appreciated. ... 31 = /dev/tap15 16th Ethertap device - 36 block MCA ESDI hard disk - 0 = /dev/eda First ESDI disk whole disk - 64 = /dev/edb Second ESDI disk whole disk - ... - - Partitions are handled in the same way as IDE disks - (see major number 3). + 36 block OBSOLETE (was MCA ESDI hard disk) 37 char IDE tape 0 = /dev/ht0 First IDE tape @@ -2421,6 +2416,8 @@ Your cooperation is appreciated. 1 = /dev/raw/raw1 First raw I/O device 2 = /dev/raw/raw2 Second raw I/O device ... + max minor number of raw device is set by kernel config + MAX_RAW_DEVS or raw module parameter 'max_raw_devs' 163 char diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt new file mode 100644 index 0000000..52478c8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt @@ -0,0 +1,27 @@ +* ARM architected timer + +ARM Cortex-A7 and Cortex-A15 have a per-core architected timer, which +provides per-cpu timers. + +The timer is attached to a GIC to deliver its per-processor interrupts. + +** Timer node properties: + +- compatible : Should at least contain "arm,armv7-timer". + +- interrupts : Interrupt list for secure, non-secure, virtual and + hypervisor timers, in that order. + +- clock-frequency : The frequency of the main counter, in Hz. Optional. + +Example: + + timer { + compatible = "arm,cortex-a15-timer", + "arm,armv7-timer"; + interrupts = <1 13 0xf08>, + <1 14 0xf08>, + <1 11 0xf08>, + <1 10 0xf08>; + clock-frequency = <100000000>; + }; diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt new file mode 100644 index 0000000..70c0dc5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt @@ -0,0 +1,23 @@ +Marvell Armada 370 and Armada XP Interrupt Controller +----------------------------------------------------- + +Required properties: +- compatible: Should be "marvell,mpic" +- interrupt-controller: Identifies the node as an interrupt controller. +- #interrupt-cells: The number of cells to define the interrupts. Should be 1. + The cell is the IRQ number +- reg: Should contain PMIC registers location and length. First pair + for the main interrupt registers, second pair for the per-CPU + interrupt registers + +Example: + + mpic: interrupt-controller@d0020000 { + compatible = "marvell,mpic"; + #interrupt-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + interrupt-controller; + reg = <0xd0020000 0x1000>, + <0xd0021000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt new file mode 100644 index 0000000..8b6ea22 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt @@ -0,0 +1,11 @@ +Marvell Armada 370 and Armada XP Global Timers +---------------------------------------------- + +Required properties: +- compatible: Should be "marvell,armada-370-xp-timer" +- interrupts: Should contain the list of Global Timer interrupts +- reg: Should contain the base address of the Global Timer registers + +Optional properties: +- marvell,timer-25Mhz: Tells whether the Global timer supports the 25 + Mhz fixed mode (available on Armada XP and not on Armada 370) diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp.txt b/Documentation/devicetree/bindings/arm/armada-370-xp.txt new file mode 100644 index 0000000..c6ed90e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-370-xp.txt @@ -0,0 +1,24 @@ +Marvell Armada 370 and Armada XP Platforms Device Tree Bindings +--------------------------------------------------------------- + +Boards with a SoC of the Marvell Armada 370 and Armada XP families +shall have the following property: + +Required root node property: + +compatible: must contain "marvell,armada-370-xp" + +In addition, boards using the Marvell Armada 370 SoC shall have the +following property: + +Required root node property: + +compatible: must contain "marvell,armada370" + +In addition, boards using the Marvell Armada XP SoC shall have the +following property: + +Required root node property: + +compatible: must contain "marvell,armadaxp" + diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt new file mode 100644 index 0000000..c63097d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt @@ -0,0 +1,65 @@ +* AT91's Analog to Digital Converter (ADC) + +Required properties: + - compatible: Should be "atmel,at91sam9260-adc" + - reg: Should contain ADC registers location and length + - interrupts: Should contain the IRQ line for the ADC + - atmel,adc-channel-base: Offset of the first channel data register + - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this + device + - atmel,adc-drdy-mask: Mask of the DRDY interruption in the ADC + - atmel,adc-num-channels: Number of channels available in the ADC + - atmel,adc-startup-time: Startup Time of the ADC in microseconds as + defined in the datasheet + - atmel,adc-status-register: Offset of the Interrupt Status Register + - atmel,adc-trigger-register: Offset of the Trigger Register + - atmel,adc-vref: Reference voltage in millivolts for the conversions + +Optional properties: + - atmel,adc-use-external: Boolean to enable of external triggers + +Optional trigger Nodes: + - Required properties: + * trigger-name: Name of the trigger exposed to the user + * trigger-value: Value to put in the Trigger register + to activate this trigger + - Optional properties: + * trigger-external: Is the trigger an external trigger? + +Examples: +adc0: adc@fffb0000 { + compatible = "atmel,at91sam9260-adc"; + reg = <0xfffb0000 0x100>; + interrupts = <20 4>; + 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-vref = <3300>; + + trigger@0 { + trigger-name = "external-rising"; + trigger-value = <0x1>; + trigger-external; + }; + trigger@1 { + trigger-name = "external-falling"; + trigger-value = <0x2>; + trigger-external; + }; + + trigger@2 { + trigger-name = "external-any"; + trigger-value = <0x3>; + trigger-external; + }; + + trigger@3 { + trigger-name = "continuous"; + trigger-value = <0x6>; + }; +}; diff --git a/Documentation/devicetree/bindings/arm/atmel-aic.txt b/Documentation/devicetree/bindings/arm/atmel-aic.txt index aabca4f..19078bf 100644 --- a/Documentation/devicetree/bindings/arm/atmel-aic.txt +++ b/Documentation/devicetree/bindings/arm/atmel-aic.txt @@ -4,7 +4,7 @@ Required properties: - compatible: Should be "atmel,<chip>-aic" - interrupt-controller: Identifies the node as an interrupt controller. - interrupt-parent: For single AIC system, it is an empty property. -- #interrupt-cells: The number of cells to define the interrupts. It sould be 2. +- #interrupt-cells: The number of cells to define the interrupts. It sould be 3. The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet). The second cell is used to specify flags: bits[3:0] trigger type and level flags: @@ -14,7 +14,10 @@ Required properties: 8 = active low level-sensitive. Valid combinations are 1, 2, 3, 4, 8. Default flag for internal sources should be set to 4 (active high). + The third cell is used to specify the irq priority from 0 (lowest) to 7 + (highest). - reg: Should contain AIC registers location and length +- atmel,external-irqs: u32 array of external irqs. Examples: /* @@ -24,7 +27,7 @@ Examples: compatible = "atmel,at91rm9200-aic"; interrupt-controller; interrupt-parent; - #interrupt-cells = <2>; + #interrupt-cells = <3>; reg = <0xfffff000 0x200>; }; @@ -34,5 +37,5 @@ Examples: dma: dma-controller@ffffec00 { compatible = "atmel,at91sam9g45-dma"; reg = <0xffffec00 0x200>; - interrupts = <21 4>; + interrupts = <21 4 5>; }; diff --git a/Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt b/Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt new file mode 100644 index 0000000..94e642a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt @@ -0,0 +1,15 @@ +Calxeda Highbank L2 cache ECC + +Properties: +- compatible : Should be "calxeda,hb-sregs-l2-ecc" +- reg : Address and size for ECC error interrupt clear registers. +- interrupts : Should be single bit error interrupt, then double bit error + interrupt. + +Example: + + sregs@fff3c200 { + compatible = "calxeda,hb-sregs-l2-ecc"; + reg = <0xfff3c200 0x100>; + interrupts = <0 71 4 0 72 4>; + }; diff --git a/Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt b/Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt new file mode 100644 index 0000000..f770ac0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt @@ -0,0 +1,14 @@ +Calxeda DDR memory controller + +Properties: +- compatible : Should be "calxeda,hb-ddr-ctrl" +- reg : Address and size for DDR controller registers. +- interrupts : Interrupt for DDR controller. + +Example: + + memory-controller@fff00000 { + compatible = "calxeda,hb-ddr-ctrl"; + reg = <0xfff00000 0x1000>; + interrupts = <0 91 4>; + }; diff --git a/Documentation/devicetree/bindings/arm/davinci/cp-intc.txt b/Documentation/devicetree/bindings/arm/davinci/cp-intc.txt new file mode 100644 index 0000000..597e8a0 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/davinci/cp-intc.txt @@ -0,0 +1,27 @@ +* TI Common Platform Interrupt Controller + +Common Platform Interrupt Controller (cp_intc) is used on +OMAP-L1x SoCs and can support several configurable number +of interrupts. + +Main node required properties: + +- compatible : should be: + "ti,cp-intc" +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The type shall be a <u32> and the value shall be 1. + + The cell contains the interrupt number in the range [0-128]. +- ti,intc-size: Number of interrupts handled by the interrupt controller. +- reg: physical base address and size of the intc registers map. + +Example: + + intc: interrupt-controller@1 { + compatible = "ti,cp-intc"; + interrupt-controller; + #interrupt-cells = <1>; + ti,intc-size = <101>; + reg = <0xfffee000 0x2000>; + }; diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt index bfbc771..ac9e751 100644 --- a/Documentation/devicetree/bindings/arm/fsl.txt +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -1,6 +1,14 @@ Freescale i.MX Platforms Device Tree Bindings ----------------------------------------------- +i.MX23 Evaluation Kit +Required root node properties: + - compatible = "fsl,imx23-evk", "fsl,imx23"; + +i.MX28 Evaluation Kit +Required root node properties: + - compatible = "fsl,imx28-evk", "fsl,imx28"; + i.MX51 Babbage Board Required root node properties: - compatible = "fsl,imx51-babbage", "fsl,imx51"; @@ -29,6 +37,10 @@ i.MX6 Quad SABRE Lite Board Required root node properties: - compatible = "fsl,imx6q-sabrelite", "fsl,imx6q"; +i.MX6 Quad SABRE Smart Device Board +Required root node properties: + - compatible = "fsl,imx6q-sabresd", "fsl,imx6q"; + Generic i.MX boards ------------------- diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index 9b4b82a..62eb8df 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -11,7 +11,9 @@ have PPIs or SGIs. Main node required properties: - compatible : should be one of: + "arm,cortex-a15-gic" "arm,cortex-a9-gic" + "arm,cortex-a7-gic" "arm,arm11mp-gic" - interrupt-controller : Identifies the node as an interrupt controller - #interrupt-cells : Specifies the number of cells needed to encode an @@ -39,8 +41,9 @@ Main node required properties: the GIC cpu interface register base and size. Optional -- interrupts : Interrupt source of the parent interrupt controller. Only - present on secondary GICs. +- interrupts : Interrupt source of the parent interrupt controller on + secondary GICs, or VGIC maintainance interrupt on primary GIC (see + below). - cpu-offset : per-cpu offset within the distributor and cpu interface regions, used when the GIC doesn't have banked registers. The offset is @@ -57,3 +60,31 @@ Example: <0xfff10100 0x100>; }; + +* GIC virtualization extensions (VGIC) + +For ARM cores that support the virtualization extensions, additional +properties must be described (they only exist if the GIC is the +primary interrupt controller). + +Required properties: + +- reg : Additional regions specifying the base physical address and + size of the VGIC registers. The first additional region is the GIC + virtual interface control register base and size. The 2nd additional + region is the GIC virtual cpu interface register base and size. + +- interrupts : VGIC maintainance interrupt. + +Example: + + interrupt-controller@2c001000 { + compatible = "arm,cortex-a15-gic"; + #interrupt-cells = <3>; + interrupt-controller; + reg = <0x2c001000 0x1000>, + <0x2c002000 0x1000>, + <0x2c004000 0x2000>, + <0x2c006000 0x2000>; + interrupts = <1 9 0xf04>; + }; diff --git a/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt b/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt new file mode 100644 index 0000000..539adca --- /dev/null +++ b/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt @@ -0,0 +1,38 @@ +* NXP LPC32xx Main Interrupt Controller + (MIC, including SIC1 and SIC2 secondary controllers) + +Required properties: +- compatible: Should be "nxp,lpc3220-mic" +- interrupt-controller: Identifies the node as an interrupt controller. +- interrupt-parent: Empty for the interrupt controller itself +- #interrupt-cells: The number of cells to define the interrupts. Should be 2. + The first cell is the IRQ number + The second cell is used to specify mode: + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered + 4 = active high level-sensitive + 8 = active low level-sensitive + Default for internal sources should be set to 4 (active high). +- reg: Should contain MIC registers location and length + +Examples: + /* + * MIC + */ + mic: interrupt-controller@40008000 { + compatible = "nxp,lpc3220-mic"; + interrupt-controller; + interrupt-parent; + #interrupt-cells = <2>; + reg = <0x40008000 0xC000>; + }; + + /* + * ADC + */ + adc@40048000 { + compatible = "nxp,lpc3220-adc"; + reg = <0x40048000 0x1000>; + interrupt-parent = <&mic>; + interrupts = <39 4>; + }; diff --git a/Documentation/devicetree/bindings/arm/lpc32xx.txt b/Documentation/devicetree/bindings/arm/lpc32xx.txt new file mode 100644 index 0000000..56ec8dd --- /dev/null +++ b/Documentation/devicetree/bindings/arm/lpc32xx.txt @@ -0,0 +1,8 @@ +NXP LPC32xx Platforms Device Tree Bindings +------------------------------------------ + +Boards with the NXP LPC32xx SoC shall have the following properties: + +Required root node property: + +compatible: must be "nxp,lpc3220", "nxp,lpc3230", "nxp,lpc3240" or "nxp,lpc3250" diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt new file mode 100644 index 0000000..80b9a94 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mrvl/intc.txt @@ -0,0 +1,40 @@ +* Marvell MMP Interrupt controller + +Required properties: +- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or + "mrvl,mmp2-mux-intc" +- reg : Address and length of the register set of the interrupt controller. + If the interrupt controller is intc, address and length means the range + of the whold interrupt controller. If the interrupt controller is mux-intc, + address and length means one register. Since address of mux-intc is in the + range of intc. mux-intc is secondary interrupt controller. +- reg-names : Name of the register set of the interrupt controller. It's + only required in mux-intc interrupt controller. +- interrupts : Should be the port interrupt shared by mux interrupts. It's + only required in mux-intc interrupt controller. +- interrupt-controller : Identifies the node as an interrupt controller. +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. +- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt + controller. +- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge + detection first. + +Example: + intc: interrupt-controller@d4282000 { + compatible = "mrvl,mmp2-intc"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0xd4282000 0x1000>; + mrvl,intc-nr-irqs = <64>; + }; + + intcmux4@d4282150 { + compatible = "mrvl,mmp2-mux-intc"; + interrupts = <4>; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x150 0x4>, <0x168 0x4>; + reg-names = "mux status", "mux mask"; + mrvl,intc-nr-irqs = <2>; + }; diff --git a/Documentation/devicetree/bindings/arm/mrvl.txt b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt index d8de933..117d741 100644 --- a/Documentation/devicetree/bindings/arm/mrvl.txt +++ b/Documentation/devicetree/bindings/arm/mrvl/mrvl.txt @@ -4,3 +4,11 @@ Marvell Platforms Device Tree Bindings PXA168 Aspenite Board Required root node properties: - compatible = "mrvl,pxa168-aspenite", "mrvl,pxa168"; + +PXA910 DKB Board +Required root node properties: + - compatible = "mrvl,pxa910-dkb"; + +MMP2 Brownstone Board +Required root node properties: + - compatible = "mrvl,mmp2-brownstone"; diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt b/Documentation/devicetree/bindings/arm/mrvl/timer.txt new file mode 100644 index 0000000..9a6e251 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt @@ -0,0 +1,13 @@ +* Marvell MMP Timer controller + +Required properties: +- compatible : Should be "mrvl,mmp-timer". +- reg : Address and length of the register set of timer controller. +- interrupts : Should be the interrupt number. + +Example: + timer0: timer@d4014000 { + compatible = "mrvl,mmp-timer"; + reg = <0xd4014000 0x100>; + interrupts = <13>; + }; diff --git a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt new file mode 100644 index 0000000..081c6a7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt @@ -0,0 +1,17 @@ +MVEBU System Controller +----------------------- +MVEBU (Marvell SOCs: Armada 370/XP, Dove, mv78xx0, Kirkwood, Orion5x) + +Required properties: + +- compatible: one of: + - "marvell,orion-system-controller" + - "marvell,armada-370-xp-system-controller" +- reg: Should contain system controller registers location and length. + +Example: + + system-controller@d0018200 { + compatible = "marvell,armada-370-xp-system-controller"; + reg = <0xd0018200 0x500>; + }; diff --git a/Documentation/devicetree/bindings/arm/olimex.txt b/Documentation/devicetree/bindings/arm/olimex.txt new file mode 100644 index 0000000..007fb5c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/olimex.txt @@ -0,0 +1,6 @@ +Olimex i.MX Platforms Device Tree Bindings +------------------------------------------ + +i.MX23 Olinuxino Low Cost Board +Required root node properties: + - compatible = "olimex,imx23-olinuxino", "fsl,imx23"; diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index e78e8bc..ccdd0e5 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -47,3 +47,9 @@ Boards: - AM335X EVM : Software Developement Board for AM335x compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3" + +- AM335X Bone : Low cost community board + compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3" + +- OMAP5 EVM : Evaluation Module + compatible = "ti,omap5-evm", "ti,omap5" diff --git a/Documentation/devicetree/bindings/arm/primecell.txt b/Documentation/devicetree/bindings/arm/primecell.txt index 951ca46..64fc82b 100644 --- a/Documentation/devicetree/bindings/arm/primecell.txt +++ b/Documentation/devicetree/bindings/arm/primecell.txt @@ -13,11 +13,17 @@ Required properties: Optional properties: - arm,primecell-periphid : Value to override the h/w value with +- clocks : From common clock binding. First clock is phandle to clock for apb + pclk. Additional clocks are optional and specific to those peripherals. +- clock-names : From common clock binding. Shall be "apb_pclk" for first clock. Example: serial@fff36000 { compatible = "arm,pl011", "arm,primecell"; arm,primecell-periphid = <0x00341011>; + clocks = <&pclk>; + clock-names = "apb_pclk"; + }; diff --git a/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt b/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt new file mode 100644 index 0000000..f2f2171 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt @@ -0,0 +1,52 @@ +* Samsung Exynos Interrupt Combiner Controller + +Samsung's Exynos4 architecture includes a interrupt combiner controller which +can combine interrupt sources as a group and provide a single interrupt request +for the group. The interrupt request from each group are connected to a parent +interrupt controller, such as GIC in case of Exynos4210. + +The interrupt combiner controller consists of multiple combiners. Upto eight +interrupt sources can be connected to a combiner. The combiner outputs one +combined interrupt for its eight interrupt sources. The combined interrupt +is usually connected to a parent interrupt controller. + +A single node in the device tree is used to describe the interrupt combiner +controller module (which includes multiple combiners). A combiner in the +interrupt controller module shares config/control registers with other +combiners. For example, a 32-bit interrupt enable/disable config register +can accommodate upto 4 interrupt combiners (with each combiner supporting +upto 8 interrupt sources). + +Required properties: +- compatible: should be "samsung,exynos4210-combiner". +- interrupt-controller: Identifies the node as an interrupt controller. +- #interrupt-cells: should be <2>. The meaning of the cells are + * First Cell: Combiner Group Number. + * Second Cell: Interrupt number within the group. +- reg: Base address and size of interrupt combiner registers. +- interrupts: The list of interrupts generated by the combiners which are then + connected to a parent interrupt controller. The format of the interrupt + specifier depends in the interrupt parent controller. + +Optional properties: +- samsung,combiner-nr: The number of interrupt combiners supported. If this + property is not specified, the default number of combiners is assumed + to be 16. +- interrupt-parent: pHandle of the parent interrupt controller, if not + inherited from the parent node. + + +Example: + + The following is a an example from the Exynos4210 SoC dtsi file. + + combiner:interrupt-controller@10440000 { + compatible = "samsung,exynos4210-combiner"; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0x10440000 0x1000>; + interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, + <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>, + <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>, + <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>; + }; diff --git a/Documentation/devicetree/bindings/arm/spear-timer.txt b/Documentation/devicetree/bindings/arm/spear-timer.txt new file mode 100644 index 0000000..c001722 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/spear-timer.txt @@ -0,0 +1,18 @@ +* SPEAr ARM Timer + +** Timer node required properties: + +- compatible : Should be: + "st,spear-timer" +- reg: Address range of the timer registers +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupt: Should contain the timer interrupt number + +Example: + + timer@f0000000 { + compatible = "st,spear-timer"; + reg = <0xf0000000 0x400>; + interrupts = <2>; + }; diff --git a/Documentation/devicetree/bindings/arm/spear.txt b/Documentation/devicetree/bindings/arm/spear.txt index f8e54f0..0d42949 100644 --- a/Documentation/devicetree/bindings/arm/spear.txt +++ b/Documentation/devicetree/bindings/arm/spear.txt @@ -2,7 +2,25 @@ ST SPEAr Platforms Device Tree Bindings --------------------------------------- Boards with the ST SPEAr600 SoC shall have the following properties: +Required root node property: +compatible = "st,spear600"; +Boards with the ST SPEAr300 SoC shall have the following properties: Required root node property: +compatible = "st,spear300"; -compatible = "st,spear600"; +Boards with the ST SPEAr310 SoC shall have the following properties: +Required root node property: +compatible = "st,spear310"; + +Boards with the ST SPEAr320 SoC shall have the following properties: +Required root node property: +compatible = "st,spear320"; + +Boards with the ST SPEAr1310 SoC shall have the following properties: +Required root node property: +compatible = "st,spear1310"; + +Boards with the ST SPEAr1340 SoC shall have the following properties: +Required root node property: +compatible = "st,spear1340"; diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt new file mode 100644 index 0000000..234406d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt @@ -0,0 +1,11 @@ +NVIDIA Tegra AHB + +Required properties: +- compatible : "nvidia,tegra20-ahb" or "nvidia,tegra30-ahb" +- reg : Should contain 1 register ranges(address and length) + +Example: + ahb: ahb@6000c004 { + compatible = "nvidia,tegra20-ahb"; + reg = <0x6000c004 0x10c>; /* AHB Arbitration + Gizmo Controller */ + }; diff --git a/Documentation/devicetree/bindings/arm/tegra/emc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt index 09335f8..4c33b29 100644 --- a/Documentation/devicetree/bindings/arm/tegra/emc.txt +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt @@ -15,7 +15,7 @@ Child device nodes describe the memory settings for different configurations and Example: - emc@7000f400 { + memory-controller@7000f400 { #address-cells = < 1 >; #size-cells = < 0 >; compatible = "nvidia,tegra20-emc"; diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt new file mode 100644 index 0000000..866d934 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt @@ -0,0 +1,16 @@ +NVIDIA Tegra20 MC(Memory Controller) + +Required properties: +- compatible : "nvidia,tegra20-mc" +- reg : Should contain 2 register ranges(address and length); see the + example below. Note that the MC registers are interleaved with the + GART registers, and hence must be represented as multiple ranges. +- interrupts : Should contain MC General interrupt. + +Example: + memory-controller@0x7000f000 { + compatible = "nvidia,tegra20-mc"; + reg = <0x7000f000 0x024 + 0x7000f03c 0x3c4>; + interrupts = <0 77 0x04>; + }; diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt new file mode 100644 index 0000000..bdf1a61 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt @@ -0,0 +1,18 @@ +NVIDIA Tegra30 MC(Memory Controller) + +Required properties: +- compatible : "nvidia,tegra30-mc" +- reg : Should contain 4 register ranges(address and length); see the + example below. Note that the MC registers are interleaved with the + SMMU registers, and hence must be represented as multiple ranges. +- interrupts : Should contain MC General interrupt. + +Example: + memory-controller { + compatible = "nvidia,tegra30-mc"; + reg = <0x7000f000 0x010 + 0x7000f03c 0x1b4 + 0x7000f200 0x028 + 0x7000f284 0x17c>; + interrupts = <0 77 0x04>; + }; diff --git a/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt b/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt new file mode 100644 index 0000000..93986a5 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/cavium-compact-flash.txt @@ -0,0 +1,30 @@ +* Compact Flash + +The Cavium Compact Flash device is connected to the Octeon Boot Bus, +and is thus a child of the Boot Bus device. It can read and write +industry standard compact flash devices. + +Properties: +- compatible: "cavium,ebt3000-compact-flash"; + + Compatibility with many Cavium evaluation boards. + +- reg: The base address of the the CF chip select banks. Depending on + the device configuration, there may be one or two banks. + +- cavium,bus-width: The width of the connection to the CF devices. Valid + values are 8 and 16. + +- cavium,true-ide: Optional, if present the CF connection is in True IDE mode. + +- cavium,dma-engine-handle: Optional, a phandle for the DMA Engine connected + to this device. + +Example: + compact-flash@5,0 { + compatible = "cavium,ebt3000-compact-flash"; + reg = <5 0 0x10000>, <6 0 0x10000>; + cavium,bus-width = <16>; + cavium,true-ide; + cavium,dma-engine-handle = <&dma0>; + }; diff --git a/Documentation/devicetree/bindings/clock/calxeda.txt b/Documentation/devicetree/bindings/clock/calxeda.txt new file mode 100644 index 0000000..0a6ac1b --- /dev/null +++ b/Documentation/devicetree/bindings/clock/calxeda.txt @@ -0,0 +1,17 @@ +Device Tree Clock bindings for Calxeda highbank platform + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be one of the following: + "calxeda,hb-pll-clock" - for a PLL clock + "calxeda,hb-a9periph-clock" - The A9 peripheral clock divided from the + A9 clock. + "calxeda,hb-a9bus-clock" - The A9 bus clock divided from the A9 clock. + "calxeda,hb-emmc-clock" - Divided clock for MMC/SD controller. +- reg : shall be the control register offset from SYSREGs base for the clock. +- clocks : shall be the input parent clock phandle for the clock. This is + either an oscillator or a pll output. +- #clock-cells : from common clock binding; shall be set to 0. diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt b/Documentation/devicetree/bindings/clock/clock-bindings.txt new file mode 100644 index 0000000..eb65d41 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt @@ -0,0 +1,117 @@ +This binding is a work-in-progress, and are based on some experimental +work by benh[1]. + +Sources of clock signal can be represented by any node in the device +tree. Those nodes are designated as clock providers. Clock consumer +nodes use a phandle and clock specifier pair to connect clock provider +outputs to clock inputs. Similar to the gpio specifiers, a clock +specifier is an array of one more more cells identifying the clock +output on a device. The length of a clock specifier is defined by the +value of a #clock-cells property in the clock provider node. + +[1] http://patchwork.ozlabs.org/patch/31551/ + +==Clock providers== + +Required properties: +#clock-cells: Number of cells in a clock specifier; Typically 0 for nodes + with a single clock output and 1 for nodes with multiple + clock outputs. + +Optional properties: +clock-output-names: Recommended to be a list of strings of clock output signal + names indexed by the first cell in the clock specifier. + However, the meaning of clock-output-names is domain + specific to the clock provider, and is only provided to + encourage using the same meaning for the majority of clock + providers. This format may not work for clock providers + using a complex clock specifier format. In those cases it + is recommended to omit this property and create a binding + specific names property. + + Clock consumer nodes must never directly reference + the provider's clock-output-names property. + +For example: + + oscillator { + #clock-cells = <1>; + clock-output-names = "ckil", "ckih"; + }; + +- this node defines a device with two clock outputs, the first named + "ckil" and the second named "ckih". Consumer nodes always reference + clocks by index. The names should reflect the clock output signal + names for the device. + +==Clock consumers== + +Required properties: +clocks: List of phandle and clock specifier pairs, one pair + for each clock input to the device. Note: if the + clock provider specifies '0' for #clock-cells, then + only the phandle portion of the pair will appear. + +Optional properties: +clock-names: List of clock input name strings sorted in the same + order as the clocks property. Consumers drivers + will use clock-names to match clock input names + with clocks specifiers. +clock-ranges: Empty property indicating that child nodes can inherit named + clocks from this node. Useful for bus nodes to provide a + clock to their children. + +For example: + + device { + clocks = <&osc 1>, <&ref 0>; + clock-names = "baud", "register"; + }; + + +This represents a device with two clock inputs, named "baud" and "register". +The baud clock is connected to output 1 of the &osc device, and the register +clock is connected to output 0 of the &ref. + +==Example== + + /* external oscillator */ + osc: oscillator { + compatible = "fixed-clock"; + #clock-cells = <1>; + clock-frequency = <32678>; + clock-output-names = "osc"; + }; + + /* phase-locked-loop device, generates a higher frequency clock + * from the external oscillator reference */ + pll: pll@4c000 { + compatible = "vendor,some-pll-interface" + #clock-cells = <1>; + clocks = <&osc 0>; + clock-names = "ref"; + reg = <0x4c000 0x1000>; + clock-output-names = "pll", "pll-switched"; + }; + + /* UART, using the low frequency oscillator for the baud clock, + * and the high frequency switched PLL output for register + * clocking */ + uart@a000 { + compatible = "fsl,imx-uart"; + reg = <0xa000 0x1000>; + interrupts = <33>; + clocks = <&osc 0>, <&pll 1>; + clock-names = "baud", "register"; + }; + +This DT fragment defines three devices: an external oscillator to provide a +low-frequency reference clock, a PLL device to generate a higher frequency +clock signal, and a UART. + +* The oscillator is fixed-frequency, and provides one clock output, named "osc". +* The PLL is both a clock provider and a clock consumer. It uses the clock + signal generated by the external oscillator, and provides two output signals + ("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) diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.txt b/Documentation/devicetree/bindings/clock/fixed-clock.txt new file mode 100644 index 0000000..0b1fe78 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/fixed-clock.txt @@ -0,0 +1,21 @@ +Binding for simple fixed-rate clock sources. + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be "fixed-clock". +- #clock-cells : from common clock binding; shall be set to 0. +- clock-frequency : frequency of clock in Hz. Should be a single cell. + +Optional properties: +- gpios : From common gpio binding; gpio connection to clock enable pin. +- clock-output-names : From common clock binding. + +Example: + clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <1000000000>; + }; diff --git a/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt new file mode 100644 index 0000000..ded0398 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/fsl-mxs-dma.txt @@ -0,0 +1,19 @@ +* Freescale MXS DMA + +Required properties: +- compatible : Should be "fsl,<chip>-dma-apbh" or "fsl,<chip>-dma-apbx" +- reg : Should contain registers location and length + +Supported chips: +imx23, imx28. + +Examples: +dma-apbh@80004000 { + compatible = "fsl,imx28-dma-apbh"; + reg = <0x80004000 2000>; +}; + +dma-apbx@80024000 { + compatible = "fsl,imx28-dma-apbx"; + reg = <0x80024000 2000>; +}; diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt new file mode 100644 index 0000000..c0d85db --- /dev/null +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt @@ -0,0 +1,17 @@ +* Synopsys Designware DMA Controller + +Required properties: +- compatible: "snps,dma-spear1340" +- reg: Address range of the DMAC registers +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupt: Should contain the DMAC interrupt number + +Example: + + dma@fc000000 { + compatible = "snps,dma-spear1340"; + reg = <0xfc000000 0x1000>; + interrupt-parent = <&vic1>; + interrupts = <12>; + }; diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt new file mode 100644 index 0000000..b41e5e52 --- /dev/null +++ b/Documentation/devicetree/bindings/fb/mxsfb.txt @@ -0,0 +1,19 @@ +* Freescale MXS LCD Interface (LCDIF) + +Required properties: +- compatible: Should be "fsl,<chip>-lcdif". Supported chips include + imx23 and imx28. +- reg: Address and length of the register set for lcdif +- interrupts: Should contain lcdif interrupts + +Optional properties: +- panel-enable-gpios : Should specify the gpio for panel enable + +Examples: + +lcdif@80030000 { + compatible = "fsl,imx28-lcdif"; + reg = <0x80030000 2000>; + interrupts = <38 86>; + panel-enable-gpios = <&gpio3 30 0>; +}; diff --git a/Documentation/devicetree/bindings/gpio/cavium-octeon-gpio.txt b/Documentation/devicetree/bindings/gpio/cavium-octeon-gpio.txt new file mode 100644 index 0000000..9d6dcd3 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/cavium-octeon-gpio.txt @@ -0,0 +1,49 @@ +* General Purpose Input Output (GPIO) bus. + +Properties: +- compatible: "cavium,octeon-3860-gpio" + + Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs. + +- reg: The base address of the GPIO unit's register bank. + +- gpio-controller: This is a GPIO controller. + +- #gpio-cells: Must be <2>. The first cell is the GPIO pin. + +- interrupt-controller: The GPIO controller is also an interrupt + controller, many of its pins may be configured as an interrupt + source. + +- #interrupt-cells: Must be <2>. The first cell is the GPIO pin + connected to the interrupt source. The second cell is the interrupt + triggering protocol and may have one of four values: + 1 - edge triggered on the rising edge. + 2 - edge triggered on the falling edge + 4 - level triggered active high. + 8 - level triggered active low. + +- interrupts: Interrupt routing for each pin. + +Example: + + gpio-controller@1070000000800 { + #gpio-cells = <2>; + compatible = "cavium,octeon-3860-gpio"; + reg = <0x10700 0x00000800 0x0 0x100>; + gpio-controller; + /* Interrupts are specified by two parts: + * 1) GPIO pin number (0..15) + * 2) Triggering (1 - edge rising + * 2 - edge falling + * 4 - level active high + * 8 - level active low) + */ + interrupt-controller; + #interrupt-cells = <2>; + /* The GPIO pin connect to 16 consecutive CUI bits */ + interrupts = <0 16>, <0 17>, <0 18>, <0 19>, + <0 20>, <0 21>, <0 22>, <0 23>, + <0 24>, <0 25>, <0 26>, <0 27>, + <0 28>, <0 29>, <0 30>, <0 31>; + }; diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt index 4363ae4..dbd22e0 100644 --- a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt +++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt @@ -8,15 +8,25 @@ Required properties: by low 16 pins and the second one is for high 16 pins. - 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 optional parameters (currently - unused). + the second cell is used to specify the gpio polarity: + 0 = active high + 1 = active low +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells : Should be 2. The first cell is the GPIO number. + The second cell bits[3:0] is used to specify trigger type and level flags: + 1 = low-to-high edge triggered. + 2 = high-to-low edge triggered. + 4 = active high level-sensitive. + 8 = active low level-sensitive. Example: gpio0: gpio@73f84000 { - compatible = "fsl,imx51-gpio", "fsl,imx31-gpio"; + compatible = "fsl,imx51-gpio", "fsl,imx35-gpio"; reg = <0x73f84000 0x4000>; interrupts = <50 51>; gpio-controller; #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-mm-lantiq.txt b/Documentation/devicetree/bindings/gpio/gpio-mm-lantiq.txt new file mode 100644 index 0000000..f93d514 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-mm-lantiq.txt @@ -0,0 +1,38 @@ +Lantiq SoC External Bus memory mapped GPIO controller + +By attaching hardware latches to the EBU it is possible to create output +only gpios. This driver configures a special memory address, which when +written to outputs 16 bit to the latches. + +The node describing the memory mapped GPIOs needs to be a child of the node +describing the "lantiq,localbus". + +Required properties: +- compatible : Should be "lantiq,gpio-mm-lantiq" +- 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. + +Optional properties: +- lantiq,shadow : The default value that we shall assume as already set on the + shift register cascade. + +Example: + +localbus@0 { + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0 0x0 0x3ffffff /* addrsel0 */ + 1 0 0x4000000 0x4000010>; /* addsel1 */ + compatible = "lantiq,localbus", "simple-bus"; + + gpio_mm0: gpio@4000000 { + compatible = "lantiq,gpio-mm"; + reg = <1 0x0 0x10>; + gpio-controller; + #gpio-cells = <2>; + lantiq,shadow = <0x77f> + }; +} diff --git a/Documentation/devicetree/bindings/gpio/gpio-mxs.txt b/Documentation/devicetree/bindings/gpio/gpio-mxs.txt new file mode 100644 index 0000000..1e677a4 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-mxs.txt @@ -0,0 +1,88 @@ +* Freescale MXS GPIO controller + +The Freescale MXS GPIO controller is part of MXS PIN controller. The +GPIOs are organized in port/bank. Each port consists of 32 GPIOs. + +As the GPIO controller is embedded in the PIN controller and all the +GPIO ports share the same IO space with PIN controller, the GPIO node +will be represented as sub-nodes of MXS pinctrl node. + +Required properties for GPIO node: +- compatible : Should be "fsl,<soc>-gpio". The supported SoCs include + imx23 and imx28. +- interrupts : Should be the port interrupt shared by all 32 pins. +- 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 +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells : Should be 2. The first cell is the GPIO number. + The second cell bits[3:0] is used to specify trigger type and level flags: + 1 = low-to-high edge triggered. + 2 = high-to-low edge triggered. + 4 = active high level-sensitive. + 8 = active low level-sensitive. + +Note: Each GPIO port should have an alias correctly numbered in "aliases" +node. + +Examples: + +aliases { + gpio0 = &gpio0; + gpio1 = &gpio1; + gpio2 = &gpio2; + gpio3 = &gpio3; + gpio4 = &gpio4; +}; + +pinctrl@80018000 { + compatible = "fsl,imx28-pinctrl", "simple-bus"; + reg = <0x80018000 2000>; + + gpio0: gpio@0 { + compatible = "fsl,imx28-gpio"; + interrupts = <127>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio1: gpio@1 { + compatible = "fsl,imx28-gpio"; + interrupts = <126>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio2: gpio@2 { + compatible = "fsl,imx28-gpio"; + interrupts = <125>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio3: gpio@3 { + compatible = "fsl,imx28-gpio"; + interrupts = <124>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio4: gpio@4 { + compatible = "fsl,imx28-gpio"; + interrupts = <123>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; +}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt new file mode 100644 index 0000000..8315ac7 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt @@ -0,0 +1,31 @@ +Nomadik GPIO controller + +Required properties: +- compatible : Should be "st,nomadik-gpio". +- reg : Physical base address and length of the controller's registers. +- interrupts : The interrupt outputs from the controller. +- #gpio-cells : Should be two: + The first cell is the pin number. + The second cell is used to specify optional parameters: + - bits[3:0] trigger type and level flags: + 1 = low-to-high edge triggered. + 2 = high-to-low edge triggered. + 4 = active high level-sensitive. + 8 = active low level-sensitive. +- gpio-controller : Marks the device node as a GPIO controller. +- interrupt-controller : Marks the device node as an interrupt controller. +- gpio-bank : Specifies which bank a controller owns. +- st,supports-sleepmode : Specifies whether controller can sleep or not + +Example: + + gpio1: gpio@8012e080 { + compatible = "st,nomadik-gpio"; + reg = <0x8012e080 0x80>; + interrupts = <0 120 0x4>; + #gpio-cells = <2>; + gpio-controller; + interrupt-controller; + st,supports-sleepmode; + gpio-bank = <1>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt index 8f50fe5..5375625 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt @@ -11,14 +11,15 @@ Required properties: <[phandle of the gpio controller node] [pin number within the gpio controller] [mux function] - [pull up/down] + [flags and pull up/down] [drive strength]> Values for gpio specifier: - Pin number: is a value between 0 to 7. - - Pull Up/Down: 0 - Pull Up/Down Disabled. - 1 - Pull Down Enabled. - 3 - Pull Up Enabled. + - Flags and Pull Up/Down: 0 - Pull Up/Down Disabled. + 1 - Pull Down Enabled. + 3 - Pull Up Enabled. + Bit 16 (0x00010000) - Input is active low. - Drive Strength: 0 - 1x, 1 - 3x, 2 - 2x, diff --git a/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt new file mode 100644 index 0000000..854de13 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt @@ -0,0 +1,42 @@ +Lantiq SoC Serial To Parallel (STP) GPIO controller + +The Serial To Parallel (STP) is found on MIPS based Lantiq socs. It is a +peripheral controller used to drive external shift register cascades. At most +3 groups of 8 bits can be driven. The hardware is able to allow the DSL modem +to drive the 2 LSBs of the cascade automatically. + + +Required properties: +- compatible : Should be "lantiq,gpio-stp-xway" +- 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. + +Optional properties: +- lantiq,shadow : The default value that we shall assume as already set on the + shift register cascade. +- lantiq,groups : Set the 3 bit mask to select which of the 3 groups are enabled + in the shift register cascade. +- lantiq,dsl : The dsl core can control the 2 LSBs of the gpio cascade. This 2 bit + property can enable this feature. +- lantiq,phy1 : The gphy1 core can control 3 bits of the gpio cascade. +- lantiq,phy2 : The gphy2 core can control 3 bits of the gpio cascade. +- lantiq,rising : use rising instead of falling edge for the shift register + +Example: + +gpio1: stp@E100BB0 { + compatible = "lantiq,gpio-stp-xway"; + reg = <0xE100BB0 0x40>; + #gpio-cells = <2>; + gpio-controller; + + lantiq,shadow = <0xffff>; + lantiq,groups = <0x7>; + lantiq,dsl = <0x3>; + lantiq,phy1 = <0x7>; + lantiq,phy2 = <0x7>; + /* lantiq,rising; */ +}; diff --git a/Documentation/devicetree/bindings/gpio/gpio_lpc32xx.txt b/Documentation/devicetree/bindings/gpio/gpio_lpc32xx.txt new file mode 100644 index 0000000..4981936 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio_lpc32xx.txt @@ -0,0 +1,43 @@ +NXP LPC32xx SoC GPIO controller + +Required properties: +- compatible: must be "nxp,lpc3220-gpio" +- reg: Physical base address and length of the controller's registers. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells: Should be 3: + 1) bank: + 0: GPIO P0 + 1: GPIO P1 + 2: GPIO P2 + 3: GPIO P3 + 4: GPI P3 + 5: GPO P3 + 2) pin number + 3) optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted) +- reg: Index of the GPIO group + +Example: + + gpio: gpio@40028000 { + compatible = "nxp,lpc3220-gpio"; + reg = <0x40028000 0x1000>; + gpio-controller; + #gpio-cells = <3>; /* bank, pin, flags */ + }; + + leds { + compatible = "gpio-leds"; + + led0 { + gpios = <&gpio 5 1 1>; /* GPO_P3 1, active low */ + linux,default-trigger = "heartbeat"; + default-state = "off"; + }; + + led1 { + gpios = <&gpio 5 14 1>; /* GPO_P3 14, active low */ + linux,default-trigger = "timer"; + default-state = "off"; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/led.txt b/Documentation/devicetree/bindings/gpio/led.txt index fd2bd56..9bb308a 100644 --- a/Documentation/devicetree/bindings/gpio/led.txt +++ b/Documentation/devicetree/bindings/gpio/led.txt @@ -55,4 +55,4 @@ run-control { gpios = <&mpc8572 7 0>; default-state = "on"; }; -} +}; diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt index 1e34cfe..05428f3 100644 --- a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt +++ b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt @@ -3,19 +3,25 @@ Required properties: - compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio" - reg : Address and length of the register set for the device -- interrupts : Should be the port interrupt shared by all gpio pins, if -- interrupt-name : Should be the name of irq resource. - one number. +- interrupts : Should be the port interrupt shared by all gpio pins. + There're three gpio interrupts in arch-pxa, and they're gpio0, + gpio1 and gpio_mux. There're only one gpio interrupt in arch-mmp, + gpio_mux. +- interrupt-name : Should be the name of irq resource. Each interrupt + binds its interrupt-name. +- interrupt-controller : Identifies the node as an interrupt controller. +- #interrupt-cells: Specifies the number of cells needed to encode an + interrupt source. - gpio-controller : Marks the device node as a gpio controller. - #gpio-cells : Should be one. It is the pin number. Example: gpio: gpio@d4019000 { - compatible = "mrvl,mmp-gpio", "mrvl,pxa-gpio"; + compatible = "mrvl,mmp-gpio"; reg = <0xd4019000 0x1000>; - interrupts = <49>, <17>, <18>; - interrupt-name = "gpio_mux", "gpio0", "gpio1"; + interrupts = <49>; + interrupt-name = "gpio_mux"; gpio-controller; #gpio-cells = <1>; interrupt-controller; diff --git a/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt index 023c952..023c952 100644 --- a/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt +++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt diff --git a/Documentation/devicetree/bindings/i2c/cavium-i2c.txt b/Documentation/devicetree/bindings/i2c/cavium-i2c.txt new file mode 100644 index 0000000..dced82e --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/cavium-i2c.txt @@ -0,0 +1,34 @@ +* Two Wire Serial Interface (TWSI) / I2C + +- compatible: "cavium,octeon-3860-twsi" + + Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs. + +- reg: The base address of the TWSI/I2C bus controller register bank. + +- #address-cells: Must be <1>. + +- #size-cells: Must be <0>. I2C addresses have no size component. + +- interrupts: A single interrupt specifier. + +- clock-frequency: The I2C bus clock rate in Hz. + +Example: + twsi0: i2c@1180000001000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "cavium,octeon-3860-twsi"; + reg = <0x11800 0x00001000 0x0 0x200>; + interrupts = <0 45>; + clock-frequency = <100000>; + + rtc@68 { + compatible = "dallas,ds1337"; + reg = <0x68>; + }; + tmp@4c { + compatible = "ti,tmp421"; + reg = <0x4c>; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio_i2c.txt b/Documentation/devicetree/bindings/i2c/gpio-i2c.txt index 4f8ec94..4f8ec94 100644 --- a/Documentation/devicetree/bindings/gpio/gpio_i2c.txt +++ b/Documentation/devicetree/bindings/i2c/gpio-i2c.txt diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt new file mode 100644 index 0000000..ae8af16 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt @@ -0,0 +1,93 @@ +Pinctrl-based I2C Bus Mux + +This binding describes an I2C bus multiplexer that uses pin multiplexing to +route the I2C signals, and represents the pin multiplexing configuration +using the pinctrl device tree bindings. + + +-----+ +-----+ + | dev | | dev | + +------------------------+ +-----+ +-----+ + | SoC | | | + | /----|------+--------+ + | +---+ +------+ | child bus A, on first set of pins + | |I2C|---|Pinmux| | + | +---+ +------+ | child bus B, on second set of pins + | \----|------+--------+--------+ + | | | | | + +------------------------+ +-----+ +-----+ +-----+ + | dev | | dev | | dev | + +-----+ +-----+ +-----+ + +Required properties: +- compatible: i2c-mux-pinctrl +- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side + port is connected to. + +Also required are: + +* Standard pinctrl properties that specify the pin mux state for each child + bus. See ../pinctrl/pinctrl-bindings.txt. + +* Standard I2C mux properties. See mux.txt in this directory. + +* I2C child bus nodes. See mux.txt in this directory. + +For each named state defined in the pinctrl-names property, an I2C child bus +will be created. I2C child bus numbers are assigned based on the index into +the pinctrl-names property. + +The only exception is that no bus will be created for a state named "idle". If +such a state is defined, it must be the last entry in pinctrl-names. For +example: + + pinctrl-names = "ddc", "pta", "idle" -> ddc = bus 0, pta = bus 1 + pinctrl-names = "ddc", "idle", "pta" -> Invalid ("idle" not last) + pinctrl-names = "idle", "ddc", "pta" -> Invalid ("idle" not last) + +Whenever an access is made to a device on a child bus, the relevant pinctrl +state will be programmed into hardware. + +If an idle state is defined, whenever an access is not being made to a device +on a child bus, the idle pinctrl state will be programmed into hardware. + +If an idle state is not defined, the most recently used pinctrl state will be +left programmed into hardware whenever no access is being made of a device on +a child bus. + +Example: + + i2cmux { + compatible = "i2c-mux-pinctrl"; + #address-cells = <1>; + #size-cells = <0>; + + i2c-parent = <&i2c1>; + + pinctrl-names = "ddc", "pta", "idle"; + pinctrl-0 = <&state_i2cmux_ddc>; + pinctrl-1 = <&state_i2cmux_pta>; + pinctrl-2 = <&state_i2cmux_idle>; + + i2c@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + eeprom { + compatible = "eeprom"; + reg = <0x50>; + }; + }; + + i2c@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + eeprom { + compatible = "eeprom"; + reg = <0x50>; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt new file mode 100644 index 0000000..30ac3a0 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt @@ -0,0 +1,19 @@ +* Freescale MXS Inter IC (I2C) Controller + +Required properties: +- compatible: Should be "fsl,<chip>-i2c" +- reg: Should contain registers location and length +- interrupts: Should contain ERROR and DMA interrupts +- clock-frequency: Desired I2C bus clock frequency in Hz. + Only 100000Hz and 400000Hz modes are supported. + +Examples: + +i2c0: i2c@80058000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx28-i2c"; + reg = <0x80058000 2000>; + interrupts = <111 68>; + clock-frequency = <100000>; +}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt new file mode 100644 index 0000000..c15781f --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt @@ -0,0 +1,33 @@ +Device tree configuration for i2c-ocores + +Required properties: +- compatible : "opencores,i2c-ocores" +- reg : bus address start and address range size of device +- interrupts : interrupt number +- clock-frequency : frequency of bus clock in Hz +- #address-cells : should be <1> +- #size-cells : should be <0> + +Optional properties: +- reg-shift : device register offsets are shifted by this value +- reg-io-width : io register width in bytes (1, 2 or 4) +- regstep : deprecated, use reg-shift above + +Example: + + i2c0: ocores@a0000000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "opencores,i2c-ocores"; + reg = <0xa0000000 0x8>; + interrupts = <10>; + clock-frequency = <20000000>; + + reg-shift = <0>; /* 8 bit registers */ + reg-io-width = <1>; /* 8 bit read/write */ + + dummy@60 { + compatible = "dummy"; + reg = <0x60>; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt index 071eb3c..0f79450 100644 --- a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt @@ -1,37 +1,51 @@ -* I2C +* Marvell MMP I2C controller Required properties : - reg : Offset and length of the register set for the device - - compatible : should be "mrvl,mmp-twsi" where CHIP is the name of a + - compatible : should be "mrvl,mmp-twsi" where mmp is the name of a compatible processor, e.g. pxa168, pxa910, mmp2, mmp3. For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required as shown in the example below. Recommended properties : - - interrupts : <a b> where a is the interrupt number and b is a - field that represents an encoding of the sense and level - information for the interrupt. This should be encoded based on - the information in section 2) depending on the type of interrupt - controller you have. + - interrupts : the interrupt number - interrupt-parent : the phandle for the interrupt controller that - services interrupts for this device. + services interrupts for this device. If the parent is the default + interrupt controller in device tree, it could be ignored. - mrvl,i2c-polling : Disable interrupt of i2c controller. Polling status register of i2c controller instead. - mrvl,i2c-fast-mode : Enable fast mode of i2c controller. Examples: twsi1: i2c@d4011000 { - compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c"; + compatible = "mrvl,mmp-twsi"; reg = <0xd4011000 0x1000>; interrupts = <7>; mrvl,i2c-fast-mode; }; twsi2: i2c@d4025000 { - compatible = "mrvl,mmp-twsi", "mrvl,pxa-i2c"; + compatible = "mrvl,mmp-twsi"; reg = <0xd4025000 0x1000>; interrupts = <58>; }; +* Marvell MV64XXX I2C controller + +Required properties : + + - reg : Offset and length of the register set for the device + - compatible : Should be "marvell,mv64xxx-i2c" + - interrupts : The interrupt number + - clock-frequency : Desired I2C bus clock frequency in Hz. + +Examples: + + i2c@11000 { + compatible = "marvell,mv64xxx-i2c"; + reg = <0x11000 0x20>; + interrupts = <29>; + clock-frequency = <100000>; + }; diff --git a/Documentation/devicetree/bindings/i2c/mux.txt b/Documentation/devicetree/bindings/i2c/mux.txt new file mode 100644 index 0000000..af84cce --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/mux.txt @@ -0,0 +1,60 @@ +Common i2c bus multiplexer/switch properties. + +An i2c bus multiplexer/switch will have several child busses that are +numbered uniquely in a device dependent manner. The nodes for an i2c bus +multiplexer/switch will have one child node for each child +bus. + +Required properties: +- #address-cells = <1>; +- #size-cells = <0>; + +Required properties for child nodes: +- #address-cells = <1>; +- #size-cells = <0>; +- reg : The sub-bus number. + +Optional properties for child nodes: +- Other properties specific to the multiplexer/switch hardware. +- Child nodes conforming to i2c bus binding + + +Example : + + /* + An NXP pca9548 8 channel I2C multiplexer at address 0x70 + with two NXP pca8574 GPIO expanders attached, one each to + ports 3 and 4. + */ + + mux@70 { + compatible = "nxp,pca9548"; + reg = <0x70>; + #address-cells = <1>; + #size-cells = <0>; + + i2c@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + + gpio1: gpio@38 { + compatible = "nxp,pca8574"; + reg = <0x38>; + #gpio-cells = <2>; + gpio-controller; + }; + }; + i2c@4 { + #address-cells = <1>; + #size-cells = <0>; + reg = <4>; + + gpio2: gpio@38 { + compatible = "nxp,pca8574"; + reg = <0x38>; + #gpio-cells = <2>; + gpio-controller; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/pnx.txt b/Documentation/devicetree/bindings/i2c/pnx.txt new file mode 100644 index 0000000..fe98ada --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/pnx.txt @@ -0,0 +1,36 @@ +* NXP PNX I2C Controller + +Required properties: + + - reg: Offset and length of the register set for the device + - compatible: should be "nxp,pnx-i2c" + - interrupts: configure one interrupt line + - #address-cells: always 1 (for i2c addresses) + - #size-cells: always 0 + - interrupt-parent: the phandle for the interrupt controller that + services interrupts for this device. + +Optional properties: + + - clock-frequency: desired I2C bus clock frequency in Hz, Default: 100000 Hz + +Examples: + + i2c1: i2c@400a0000 { + compatible = "nxp,pnx-i2c"; + reg = <0x400a0000 0x100>; + interrupt-parent = <&mic>; + interrupts = <51 0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + i2c2: i2c@400a8000 { + compatible = "nxp,pnx-i2c"; + reg = <0x400a8000 0x100>; + interrupt-parent = <&mic>; + interrupts = <50 0>; + #address-cells = <1>; + #size-cells = <0>; + clock-frequency = <100000>; + }; diff --git a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt index 38832c7..b6cb5a1 100644 --- a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt @@ -6,14 +6,18 @@ Required properties: - compatible: value should be either of the following. (a) "samsung, s3c2410-i2c", for i2c compatible with s3c2410 i2c. (b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c. + (c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used + inside HDMIPHY block found on several samsung SoCs - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt number to the cpu. - samsung,i2c-sda-delay: Delay (in ns) applied to data line (SDA) edges. - - gpios: The order of the gpios should be the following: <SDA, SCL>. - The gpio specifier depends on the gpio controller. Optional properties: + - gpios: The order of the gpios should be the following: <SDA, SCL>. + The gpio specifier depends on the gpio controller. Required in all + cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output + lines are permanently wired to the respective client - samsung,i2c-slave-addr: Slave address in multi-master enviroment. If not specified, default value is 0. - samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not diff --git a/Documentation/devicetree/bindings/i2c/xiic.txt b/Documentation/devicetree/bindings/i2c/xiic.txt new file mode 100644 index 0000000..ceabbe9 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/xiic.txt @@ -0,0 +1,22 @@ +Xilinx IIC controller: + +Required properties: +- compatible : Must be "xlnx,xps-iic-2.00.a" +- reg : IIC register location and length +- interrupts : IIC controller unterrupt +- #address-cells = <1> +- #size-cells = <0> + +Optional properties: +- Child nodes conforming to i2c bus binding + +Example: + + axi_iic_0: i2c@40800000 { + compatible = "xlnx,xps-iic-2.00.a"; + interrupts = < 1 2 >; + reg = < 0x40800000 0x10000 >; + + #size-cells = <0>; + #address-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/input/fsl-mma8450.txt b/Documentation/devicetree/bindings/input/fsl-mma8450.txt index a00c94c..0b96e57 100644 --- a/Documentation/devicetree/bindings/input/fsl-mma8450.txt +++ b/Documentation/devicetree/bindings/input/fsl-mma8450.txt @@ -2,6 +2,7 @@ Required properties: - compatible : "fsl,mma8450". +- reg: the I2C address of MMA8450 Example: diff --git a/Documentation/devicetree/bindings/input/lpc32xx-key.txt b/Documentation/devicetree/bindings/input/lpc32xx-key.txt new file mode 100644 index 0000000..31afd50 --- /dev/null +++ b/Documentation/devicetree/bindings/input/lpc32xx-key.txt @@ -0,0 +1,28 @@ +NXP LPC32xx Key Scan Interface + +Required Properties: +- compatible: Should be "nxp,lpc3220-key" +- reg: Physical base address of the controller and length of memory mapped + region. +- interrupts: The interrupt number to the cpu. +- keypad,num-rows: Number of rows and columns, e.g. 1: 1x1, 6: 6x6 +- keypad,num-columns: Must be equal to keypad,num-rows since LPC32xx only + supports square matrices +- nxp,debounce-delay-ms: Debounce delay in ms +- nxp,scan-delay-ms: Repeated scan period in ms +- linux,keymap: the key-code to be reported when the key is pressed + and released, see also + Documentation/devicetree/bindings/input/matrix-keymap.txt + +Example: + + key@40050000 { + compatible = "nxp,lpc3220-key"; + reg = <0x40050000 0x1000>; + interrupts = <54 0>; + keypad,num-rows = <1>; + keypad,num-columns = <1>; + nxp,debounce-delay-ms = <3>; + nxp,scan-delay-ms = <34>; + linux,keymap = <0x00000002>; + }; diff --git a/Documentation/devicetree/bindings/input/tegra-kbc.txt b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt index 72683be..72683be 100644 --- a/Documentation/devicetree/bindings/input/tegra-kbc.txt +++ b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt diff --git a/Documentation/devicetree/bindings/input/omap-keypad.txt b/Documentation/devicetree/bindings/input/omap-keypad.txt new file mode 100644 index 0000000..f2fa5e1 --- /dev/null +++ b/Documentation/devicetree/bindings/input/omap-keypad.txt @@ -0,0 +1,31 @@ +* TI's Keypad Controller device tree bindings + +TI's Keypad controller is used to interface a SoC with a matrix-type +keypad device. The keypad controller supports multiple row and column lines. +A key can be placed at each intersection of a unique row and a unique column. +The keypad controller can sense a key-press and key-release and report the +event using a interrupt to the cpu. + +Required SoC Specific Properties: +- compatible: should be one of the following + - "ti,omap4-keypad": For controllers compatible with omap4 keypad + controller. + +Required Board Specific Properties, in addition to those specified by +the shared matrix-keyboard bindings: +- 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 Properties specific to linux: +- linux,keypad-no-autorepeat: do no enable autorepeat feature. + +Example: + keypad@4ae1c000{ + compatible = "ti,omap4-keypad"; + keypad,num-rows = <2>; + keypad,num-columns = <8>; + linux,keypad-no-autorepeat; + }; diff --git a/Documentation/devicetree/bindings/input/spear-keyboard.txt b/Documentation/devicetree/bindings/input/spear-keyboard.txt new file mode 100644 index 0000000..4a846d2 --- /dev/null +++ b/Documentation/devicetree/bindings/input/spear-keyboard.txt @@ -0,0 +1,20 @@ +* SPEAr keyboard controller + +Required properties: +- compatible: "st,spear300-kbd" + +Optional properties, in addition to those specified by the shared +matrix-keyboard bindings: +- autorepeat: bool: enables key autorepeat +- st,mode: keyboard mode: 0 - 9x9, 1 - 6x6, 2 - 2x2 + +Example: + +kbd@fc400000 { + compatible = "st,spear300-kbd"; + reg = <0xfc400000 0x100>; + linux,keymap = < 0x00030012 + 0x0102003a >; + autorepeat; + st,mode = <0>; +}; diff --git a/Documentation/devicetree/bindings/input/touchscreen/lpc32xx-tsc.txt b/Documentation/devicetree/bindings/input/touchscreen/lpc32xx-tsc.txt new file mode 100644 index 0000000..41cbf4b --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/lpc32xx-tsc.txt @@ -0,0 +1,16 @@ +* NXP LPC32xx SoC Touchscreen Controller (TSC) + +Required properties: +- compatible: must be "nxp,lpc3220-tsc" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: The TSC/ADC interrupt + +Example: + + tsc@40048000 { + compatible = "nxp,lpc3220-tsc"; + reg = <0x40048000 0x1000>; + interrupt-parent = <&mic>; + interrupts = <39 0>; + }; diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt new file mode 100644 index 0000000..099d936 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/nvidia,tegra20-gart.txt @@ -0,0 +1,14 @@ +NVIDIA Tegra 20 GART + +Required properties: +- compatible: "nvidia,tegra20-gart" +- reg: Two pairs of cells specifying the physical address and size of + the memory controller registers and the GART aperture respectively. + +Example: + + gart { + compatible = "nvidia,tegra20-gart"; + reg = <0x7000f024 0x00000018 /* controller registers */ + 0x58000000 0x02000000>; /* GART aperture */ + }; diff --git a/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt new file mode 100644 index 0000000..89fb543 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/nvidia,tegra30-smmu.txt @@ -0,0 +1,21 @@ +NVIDIA Tegra 30 IOMMU H/W, SMMU (System Memory Management Unit) + +Required properties: +- compatible : "nvidia,tegra30-smmu" +- reg : Should contain 3 register banks(address and length) for each + of the SMMU register blocks. +- interrupts : Should contain MC General interrupt. +- nvidia,#asids : # of ASIDs +- dma-window : IOVA start address and length. +- nvidia,ahb : phandle to the ahb bus connected to SMMU. + +Example: + smmu { + compatible = "nvidia,tegra30-smmu"; + reg = <0x7000f010 0x02c + 0x7000f1f0 0x010 + 0x7000f228 0x05c>; + nvidia,#asids = <4>; /* # of ASIDs */ + dma-window = <0 0x40000000>; /* IOVA start & length */ + nvidia,ahb = <&ahb>; + }; diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt new file mode 100644 index 0000000..69e757a --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/ab8500.txt @@ -0,0 +1,123 @@ +* AB8500 Multi-Functional Device (MFD) + +Required parent device properties: +- compatible : contains "stericsson,ab8500"; +- interrupts : contains the IRQ line for the AB8500 +- interrupt-controller : describes the AB8500 as an Interrupt Controller (has its own domain) +- #interrupt-cells : should be 2, for 2-cell format + - The first cell is the AB8500 local IRQ number + - The second cell is used to specify optional parameters + - bits[3:0] trigger type and level flags: + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered + 4 = active high level-sensitive + 8 = active low level-sensitive + +Optional parent device properties: +- reg : contains the PRCMU mailbox address for the AB8500 i2c port + +The AB8500 consists of a large and varied group of sub-devices: + +Device IRQ Names Supply Names Description +------ --------- ------------ ----------- +ab8500-bm : : : Battery Manager +ab8500-btemp : : : Battery Temperature +ab8500-charger : : : Battery Charger +ab8500-fg : : : Fuel Gauge +ab8500-gpadc : HW_CONV_END : vddadc : Analogue to Digital Converter + SW_CONV_END : : +ab8500-gpio : : : GPIO Controller +ab8500-ponkey : ONKEY_DBF : : Power-on Key + ONKEY_DBR : : +ab8500-pwm : : : Pulse Width Modulator +ab8500-regulator : : : Regulators +ab8500-rtc : 60S : : Real Time Clock + : ALARM : : +ab8500-sysctrl : : : System Control +ab8500-usb : ID_WAKEUP_R : vddulpivio18 : Universal Serial Bus + : ID_WAKEUP_F : v-ape : + : VBUS_DET_F : musb_1v8 : + : VBUS_DET_R : : + : USB_LINK_STATUS : : + : USB_ADP_PROBE_PLUG : : + : USB_ADP_PROBE_UNPLUG : : + +Required child device properties: +- compatible : "stericsson,ab8500-[bm|btemp|charger|fg|gpadc|gpio|ponkey| + pwm|regulator|rtc|sysctrl|usb]"; + +Optional child device properties: +- interrupts : contains the device IRQ(s) using the 2-cell format (see above) +- interrupt-names : contains names of IRQ resource in the order in which they were + supplied in the interrupts property +- <supply_name>-supply : contains a phandle to the regulator supply node in Device Tree + +ab8500@5 { + compatible = "stericsson,ab8500"; + reg = <5>; /* mailbox 5 is i2c */ + interrupts = <0 40 0x4>; + interrupt-controller; + #interrupt-cells = <2>; + + ab8500-rtc { + compatible = "stericsson,ab8500-rtc"; + interrupts = <17 0x4 + 18 0x4>; + interrupt-names = "60S", "ALARM"; + }; + + ab8500-gpadc { + compatible = "stericsson,ab8500-gpadc"; + interrupts = <32 0x4 + 39 0x4>; + interrupt-names = "HW_CONV_END", "SW_CONV_END"; + vddadc-supply = <&ab8500_ldo_tvout_reg>; + }; + + ab8500-usb { + compatible = "stericsson,ab8500-usb"; + interrupts = < 90 0x4 + 96 0x4 + 14 0x4 + 15 0x4 + 79 0x4 + 74 0x4 + 75 0x4>; + interrupt-names = "ID_WAKEUP_R", + "ID_WAKEUP_F", + "VBUS_DET_F", + "VBUS_DET_R", + "USB_LINK_STATUS", + "USB_ADP_PROBE_PLUG", + "USB_ADP_PROBE_UNPLUG"; + vddulpivio18-supply = <&ab8500_ldo_initcore_reg>; + v-ape-supply = <&db8500_vape_reg>; + musb_1v8-supply = <&db8500_vsmps2_reg>; + }; + + ab8500-ponkey { + compatible = "stericsson,ab8500-ponkey"; + interrupts = <6 0x4 + 7 0x4>; + interrupt-names = "ONKEY_DBF", "ONKEY_DBR"; + }; + + ab8500-sysctrl { + compatible = "stericsson,ab8500-sysctrl"; + }; + + ab8500-pwm { + compatible = "stericsson,ab8500-pwm"; + }; + + ab8500-regulators { + compatible = "stericsson,ab8500-regulator"; + + ab8500_ldo_aux1_reg: ab8500_ldo_aux1 { + /* + * See: Documentation/devicetree/bindings/regulator/regulator.txt + * for more information on regulators + */ + }; + }; +}; diff --git a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt new file mode 100644 index 0000000..1857f4a --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt @@ -0,0 +1,60 @@ +* Dialog DA9052/53 Power Management Integrated Circuit (PMIC) + +Required properties: +- compatible : Should be "dlg,da9052", "dlg,da9053-aa", + "dlg,da9053-ab", or "dlg,da9053-bb" + +Sub-nodes: +- regulators : Contain the regulator nodes. The DA9052/53 regulators are + bound using their names as listed below: + + buck0 : regulator BUCK0 + buck1 : regulator BUCK1 + buck2 : regulator BUCK2 + buck3 : regulator BUCK3 + ldo4 : regulator LDO4 + ldo5 : regulator LDO5 + ldo6 : regulator LDO6 + ldo7 : regulator LDO7 + ldo8 : regulator LDO8 + ldo9 : regulator LDO9 + ldo10 : regulator LDO10 + ldo11 : regulator LDO11 + ldo12 : regulator LDO12 + ldo13 : regulator LDO13 + + The bindings details of individual regulator device can be found in: + Documentation/devicetree/bindings/regulator/regulator.txt + +Examples: + +i2c@63fc8000 { /* I2C1 */ + status = "okay"; + + pmic: dialog@48 { + compatible = "dlg,da9053-aa"; + reg = <0x48>; + + regulators { + buck0 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <2075000>; + }; + + buck1 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <2075000>; + }; + + buck2 { + regulator-min-microvolt = <925000>; + regulator-max-microvolt = <2500000>; + }; + + buck3 { + regulator-min-microvolt = <925000>; + regulator-max-microvolt = <2500000>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt b/Documentation/devicetree/bindings/mfd/max77686.txt new file mode 100644 index 0000000..c6a3469 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/max77686.txt @@ -0,0 +1,59 @@ +Maxim MAX77686 multi-function device + +MAX77686 is a Mulitifunction device with PMIC, RTC and Charger on chip. It is +interfaced to host controller using i2c interface. PMIC and Charger submodules +are addressed using same i2c slave address whereas RTC submodule uses +different i2c slave address,presently for which we are statically creating i2c +client while probing.This document describes the binding for mfd device and +PMIC submodule. + +Required properties: +- compatible : Must be "maxim,max77686"; +- reg : Specifies the i2c slave address of PMIC block. +- interrupts : This i2c device has an IRQ line connected to the main SoC. +- interrupt-parent : The parent interrupt controller. + +Optional node: +- voltage-regulators : The regulators of max77686 have to be instantiated + under subnode named "voltage-regulators" using the following format. + + regulator_name { + regulator-compatible = LDOn/BUCKn + standard regulator constraints.... + }; + refer Documentation/devicetree/bindings/regulator/regulator.txt + + The regulator-compatible property of regulator should initialized with string +to get matched with their hardware counterparts as follow: + + -LDOn : for LDOs, where n can lie in range 1 to 26. + example: LDO1, LDO2, LDO26. + -BUCKn : for BUCKs, where n can lie in range 1 to 9. + example: BUCK1, BUCK5, BUCK9. + +Example: + + max77686@09 { + compatible = "maxim,max77686"; + interrupt-parent = <&wakeup_eint>; + interrupts = <26 0>; + reg = <0x09>; + + voltage-regulators { + ldo11_reg { + regulator-compatible = "LDO11"; + regulator-name = "vdd_ldo11"; + regulator-min-microvolt = <1900000>; + regulator-max-microvolt = <1900000>; + regulator-always-on; + }; + + buck1_reg { + regulator-compatible = "BUCK1"; + regulator-name = "vdd_mif"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + regulator-boot-on; + }; + } diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt index 19f6af4..baf0798 100644 --- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt +++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt @@ -46,8 +46,8 @@ Examples: ecspi@70010000 { /* ECSPI1 */ fsl,spi-num-chipselects = <2>; - cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */ - <&gpio3 25 0>; /* GPIO4_25 */ + cs-gpios = <&gpio4 24 0>, /* GPIO4_24 */ + <&gpio4 25 0>; /* GPIO4_25 */ status = "okay"; pmic: mc13892@0 { diff --git a/Documentation/devicetree/bindings/mfd/tps65910.txt b/Documentation/devicetree/bindings/mfd/tps65910.txt new file mode 100644 index 0000000..db03599 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/tps65910.txt @@ -0,0 +1,197 @@ +TPS65910 Power Management Integrated Circuit + +Required properties: +- compatible: "ti,tps65910" or "ti,tps65911" +- reg: I2C slave address +- interrupts: the interrupt outputs of the controller +- #gpio-cells: number of cells to describe a GPIO, this should be 2. + The first cell is the GPIO number. + The second cell is used to specify additional options <unused>. +- gpio-controller: mark the device as a GPIO controller +- #interrupt-cells: the number of cells to describe an IRQ, this should be 2. + The first cell is the IRQ number. + The second cell is the flags, encoded as the trigger masks from + Documentation/devicetree/bindings/interrupts.txt +- regulators: This is the list of child nodes that specify the regulator + initialization data for defined regulators. Not all regulators for the given + device need to be present. The definition for each of these nodes is defined + using the standard binding for regulators found at + Documentation/devicetree/bindings/regulator/regulator.txt. + The regulator is matched with the regulator-compatible. + + The valid regulator-compatible values are: + tps65910: vrtc, vio, vdd1, vdd2, vdd3, vdig1, vdig2, vpll, vdac, vaux1, + vaux2, vaux33, vmmc + tps65911: vrtc, vio, vdd1, vdd3, vddctrl, ldo1, ldo2, ldo3, ldo4, ldo5, + ldo6, ldo7, ldo8 + +- xxx-supply: Input voltage supply regulator. + These entries are require if regulators are enabled for a device. Missing of these + properties can cause the regulator registration fails. + If some of input supply is powered through battery or always-on supply then + also it is require to have these parameters with proper node handle of always + on power supply. + tps65910: + vcc1-supply: VDD1 input. + vcc2-supply: VDD2 input. + vcc3-supply: VAUX33 and VMMC input. + vcc4-supply: VAUX1 and VAUX2 input. + vcc5-supply: VPLL and VDAC input. + vcc6-supply: VDIG1 and VDIG2 input. + vcc7-supply: VRTC input. + vccio-supply: VIO input. + tps65911: + vcc1-supply: VDD1 input. + vcc2-supply: VDD2 input. + vcc3-supply: LDO6, LDO7 and LDO8 input. + vcc4-supply: LDO5 input. + vcc5-supply: LDO3 and LDO4 input. + vcc6-supply: LDO1 and LDO2 input. + vcc7-supply: VRTC input. + vccio-supply: VIO input. + +Optional properties: +- ti,vmbch-threshold: (tps65911) main battery charged threshold + comparator. (see VMBCH_VSEL in TPS65910 datasheet) +- ti,vmbch2-threshold: (tps65911) main battery discharged threshold + comparator. (see VMBCH_VSEL in TPS65910 datasheet) +- ti,en-ck32k-xtal: enable external 32-kHz crystal oscillator (see CK32K_CTRL + in TPS6591X datasheet) +- ti,en-gpio-sleep: enable sleep control for gpios + There should be 9 entries here, one for each gpio. + +Regulator Optional properties: +- ti,regulator-ext-sleep-control: enable external sleep + control through external inputs [0 (not enabled), 1 (EN1), 2 (EN2) or 4(EN3)] + If this property is not defined, it defaults to 0 (not enabled). + +Example: + + pmu: tps65910@d2 { + compatible = "ti,tps65910"; + reg = <0xd2>; + interrupt-parent = <&intc>; + interrupts = < 0 118 0x04 >; + + #gpio-cells = <2>; + gpio-controller; + + #interrupt-cells = <2>; + interrupt-controller; + + ti,vmbch-threshold = 0; + ti,vmbch2-threshold = 0; + ti,en-ck32k-xtal; + ti,en-gpio-sleep = <0 0 1 0 0 0 0 0 0>; + + vcc1-supply = <®_parent>; + vcc2-supply = <&some_reg>; + vcc3-supply = <...>; + vcc4-supply = <...>; + vcc5-supply = <...>; + vcc6-supply = <...>; + vcc7-supply = <...>; + vccio-supply = <...>; + + regulators { + #address-cells = <1>; + #size-cells = <0>; + + vdd1_reg: regulator@0 { + regulator-compatible = "vdd1"; + reg = <0>; + regulator-min-microvolt = < 600000>; + regulator-max-microvolt = <1500000>; + regulator-always-on; + regulator-boot-on; + ti,regulator-ext-sleep-control = <0>; + }; + vdd2_reg: regulator@1 { + regulator-compatible = "vdd2"; + reg = <1>; + regulator-min-microvolt = < 600000>; + regulator-max-microvolt = <1500000>; + regulator-always-on; + regulator-boot-on; + ti,regulator-ext-sleep-control = <4>; + }; + vddctrl_reg: regulator@2 { + regulator-compatible = "vddctrl"; + reg = <2>; + regulator-min-microvolt = < 600000>; + regulator-max-microvolt = <1400000>; + regulator-always-on; + regulator-boot-on; + ti,regulator-ext-sleep-control = <0>; + }; + vio_reg: regulator@3 { + regulator-compatible = "vio"; + reg = <3>; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + regulator-boot-on; + ti,regulator-ext-sleep-control = <1>; + }; + ldo1_reg: regulator@4 { + regulator-compatible = "ldo1"; + reg = <4>; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <3300000>; + ti,regulator-ext-sleep-control = <0>; + }; + ldo2_reg: regulator@5 { + regulator-compatible = "ldo2"; + reg = <5>; + regulator-min-microvolt = <1050000>; + regulator-max-microvolt = <1050000>; + ti,regulator-ext-sleep-control = <0>; + }; + ldo3_reg: regulator@6 { + regulator-compatible = "ldo3"; + reg = <6>; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <3300000>; + ti,regulator-ext-sleep-control = <0>; + }; + ldo4_reg: regulator@7 { + regulator-compatible = "ldo4"; + reg = <7>; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + ti,regulator-ext-sleep-control = <0>; + }; + ldo5_reg: regulator@8 { + regulator-compatible = "ldo5"; + reg = <8>; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <3300000>; + ti,regulator-ext-sleep-control = <0>; + }; + ldo6_reg: regulator@9 { + regulator-compatible = "ldo6"; + reg = <9>; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + ti,regulator-ext-sleep-control = <0>; + }; + ldo7_reg: regulator@10 { + regulator-compatible = "ldo7"; + reg = <10>; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-always-on; + regulator-boot-on; + ti,regulator-ext-sleep-control = <1>; + }; + ldo8_reg: regulator@11 { + regulator-compatible = "ldo8"; + reg = <11>; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + ti,regulator-ext-sleep-control = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt b/Documentation/devicetree/bindings/mfd/twl6040.txt new file mode 100644 index 0000000..c855240 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/twl6040.txt @@ -0,0 +1,62 @@ +Texas Instruments TWL6040 family + +The TWL6040s are 8-channel high quality low-power audio codecs providing audio +and vibra functionality on OMAP4+ platforms. +They are connected ot the host processor via i2c for commands, McPDM for audio +data and commands. + +Required properties: +- compatible : "ti,twl6040" for twl6040, "ti,twl6041" for twl6041 +- reg: must be 0x4b for i2c address +- interrupts: twl6040 has one interrupt line connecteded to the main SoC +- interrupt-parent: The parent interrupt controller +- twl6040,audpwron-gpio: Power on GPIO line for the twl6040 + +- vio-supply: Regulator for the twl6040 VIO supply +- v2v1-supply: Regulator for the twl6040 V2V1 supply + +Optional properties, nodes: +- enable-active-high: To power on the twl6040 during boot. + +Vibra functionality +Required properties: +- vddvibl-supply: Regulator for the left vibra motor +- vddvibr-supply: Regulator for the right vibra motor +- vibra { }: Configuration section for vibra parameters containing the following + properties: +- ti,vibldrv-res: Resistance parameter for left driver +- ti,vibrdrv-res: Resistance parameter for right driver +- ti,viblmotor-res: Resistance parameter for left motor +- ti,viblmotor-res: Resistance parameter for right motor + +Optional properties within vibra { } section: +- vddvibl_uV: If the vddvibl default voltage need to be changed +- vddvibr_uV: If the vddvibr default voltage need to be changed + +Example: +&i2c1 { + twl6040: twl@4b { + compatible = "ti,twl6040"; + reg = <0x4b>; + + interrupts = <0 119 4>; + interrupt-parent = <&gic>; + twl6040,audpwron-gpio = <&gpio4 31 0>; + + vio-supply = <&v1v8>; + v2v1-supply = <&v2v1>; + enable-active-high; + + /* regulators for vibra motor */ + vddvibl-supply = <&vbat>; + vddvibr-supply = <&vbat>; + + vibra { + /* Vibra driver, motor resistance parameters */ + ti,vibldrv-res = <8>; + ti,vibrdrv-res = <3>; + ti,viblmotor-res = <10>; + ti,vibrmotor-res = <10>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/mips/cavium/bootbus.txt b/Documentation/devicetree/bindings/mips/cavium/bootbus.txt new file mode 100644 index 0000000..6581478 --- /dev/null +++ b/Documentation/devicetree/bindings/mips/cavium/bootbus.txt @@ -0,0 +1,126 @@ +* Boot Bus + +The Octeon Boot Bus is a configurable parallel bus with 8 chip +selects. Each chip select is independently configurable. + +Properties: +- compatible: "cavium,octeon-3860-bootbus" + + Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs. + +- reg: The base address of the Boot Bus' register bank. + +- #address-cells: Must be <2>. The first cell is the chip select + within the bootbus. The second cell is the offset from the chip select. + +- #size-cells: Must be <1>. + +- ranges: There must be one one triplet of (child-bus-address, + parent-bus-address, length) for each active chip select. If the + length element for any triplet is zero, the chip select is disabled, + making it inactive. + +The configuration parameters for each chip select are stored in child +nodes. + +Configuration Properties: +- compatible: "cavium,octeon-3860-bootbus-config" + +- cavium,cs-index: A single cell indicating the chip select that + corresponds to this configuration. + +- cavium,t-adr: A cell specifying the ADR timing (in nS). + +- cavium,t-ce: A cell specifying the CE timing (in nS). + +- cavium,t-oe: A cell specifying the OE timing (in nS). + +- cavium,t-we: A cell specifying the WE timing (in nS). + +- cavium,t-rd-hld: A cell specifying the RD_HLD timing (in nS). + +- cavium,t-wr-hld: A cell specifying the WR_HLD timing (in nS). + +- cavium,t-pause: A cell specifying the PAUSE timing (in nS). + +- cavium,t-wait: A cell specifying the WAIT timing (in nS). + +- cavium,t-page: A cell specifying the PAGE timing (in nS). + +- cavium,t-rd-dly: A cell specifying the RD_DLY timing (in nS). + +- cavium,pages: A cell specifying the PAGES parameter (0 = 8 bytes, 1 + = 2 bytes, 2 = 4 bytes, 3 = 8 bytes). + +- cavium,wait-mode: Optional. If present, wait mode (WAITM) is selected. + +- cavium,page-mode: Optional. If present, page mode (PAGEM) is selected. + +- cavium,bus-width: A cell specifying the WIDTH parameter (in bits) of + the bus for this chip select. + +- cavium,ale-mode: Optional. If present, ALE mode is selected. + +- cavium,sam-mode: Optional. If present, SAM mode is selected. + +- cavium,or-mode: Optional. If present, OR mode is selected. + +Example: + bootbus: bootbus@1180000000000 { + compatible = "cavium,octeon-3860-bootbus"; + reg = <0x11800 0x00000000 0x0 0x200>; + /* The chip select number and offset */ + #address-cells = <2>; + /* The size of the chip select region */ + #size-cells = <1>; + ranges = <0 0 0x0 0x1f400000 0xc00000>, + <1 0 0x10000 0x30000000 0>, + <2 0 0x10000 0x40000000 0>, + <3 0 0x10000 0x50000000 0>, + <4 0 0x0 0x1d020000 0x10000>, + <5 0 0x0 0x1d040000 0x10000>, + <6 0 0x0 0x1d050000 0x10000>, + <7 0 0x10000 0x90000000 0>; + + cavium,cs-config@0 { + compatible = "cavium,octeon-3860-bootbus-config"; + cavium,cs-index = <0>; + cavium,t-adr = <20>; + cavium,t-ce = <60>; + cavium,t-oe = <60>; + cavium,t-we = <45>; + cavium,t-rd-hld = <35>; + cavium,t-wr-hld = <45>; + cavium,t-pause = <0>; + cavium,t-wait = <0>; + cavium,t-page = <35>; + cavium,t-rd-dly = <0>; + + cavium,pages = <0>; + cavium,bus-width = <8>; + }; + . + . + . + cavium,cs-config@6 { + compatible = "cavium,octeon-3860-bootbus-config"; + cavium,cs-index = <6>; + cavium,t-adr = <5>; + cavium,t-ce = <300>; + cavium,t-oe = <270>; + cavium,t-we = <150>; + cavium,t-rd-hld = <100>; + cavium,t-wr-hld = <70>; + cavium,t-pause = <0>; + cavium,t-wait = <0>; + cavium,t-page = <320>; + cavium,t-rd-dly = <0>; + + cavium,pages = <0>; + cavium,wait-mode; + cavium,bus-width = <16>; + }; + . + . + . + }; diff --git a/Documentation/devicetree/bindings/mips/cavium/ciu.txt b/Documentation/devicetree/bindings/mips/cavium/ciu.txt new file mode 100644 index 0000000..2c2d074 --- /dev/null +++ b/Documentation/devicetree/bindings/mips/cavium/ciu.txt @@ -0,0 +1,26 @@ +* Central Interrupt Unit + +Properties: +- compatible: "cavium,octeon-3860-ciu" + + Compatibility with all cn3XXX, cn5XXX and cn63XX SOCs. + +- interrupt-controller: This is an interrupt controller. + +- reg: The base address of the CIU's register bank. + +- #interrupt-cells: Must be <2>. The first cell is the bank within + the CIU and may have a value of 0 or 1. The second cell is the bit + within the bank and may have a value between 0 and 63. + +Example: + interrupt-controller@1070000000000 { + compatible = "cavium,octeon-3860-ciu"; + interrupt-controller; + /* Interrupts are specified by two parts: + * 1) Controller register (0 or 1) + * 2) Bit within the register (0..63) + */ + #interrupt-cells = <2>; + reg = <0x10700 0x00000000 0x0 0x7000>; + }; diff --git a/Documentation/devicetree/bindings/mips/cavium/ciu2.txt b/Documentation/devicetree/bindings/mips/cavium/ciu2.txt new file mode 100644 index 0000000..0ec7ba8 --- /dev/null +++ b/Documentation/devicetree/bindings/mips/cavium/ciu2.txt @@ -0,0 +1,27 @@ +* Central Interrupt Unit + +Properties: +- compatible: "cavium,octeon-6880-ciu2" + + Compatibility with 68XX SOCs. + +- interrupt-controller: This is an interrupt controller. + +- reg: The base address of the CIU's register bank. + +- #interrupt-cells: Must be <2>. The first cell is the bank within + the CIU and may have a value between 0 and 63. The second cell is + the bit within the bank and may also have a value between 0 and 63. + +Example: + interrupt-controller@1070100000000 { + compatible = "cavium,octeon-6880-ciu2"; + interrupt-controller; + /* Interrupts are specified by two parts: + * 1) Controller register (0..63) + * 2) Bit within the register (0..63) + */ + #address-cells = <0>; + #interrupt-cells = <2>; + reg = <0x10701 0x00000000 0x0 0x4000000>; + }; diff --git a/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt b/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt new file mode 100644 index 0000000..cb4291e --- /dev/null +++ b/Documentation/devicetree/bindings/mips/cavium/dma-engine.txt @@ -0,0 +1,21 @@ +* DMA Engine. + +The Octeon DMA Engine transfers between the Boot Bus and main memory. +The DMA Engine will be refered to by phandle by any device that is +connected to it. + +Properties: +- compatible: "cavium,octeon-5750-bootbus-dma" + + Compatibility with all cn52XX, cn56XX and cn6XXX SOCs. + +- reg: The base address of the DMA Engine's register bank. + +- interrupts: A single interrupt specifier. + +Example: + dma0: dma-engine@1180000000100 { + compatible = "cavium,octeon-5750-bootbus-dma"; + reg = <0x11800 0x00000100 0x0 0x8>; + interrupts = <0 63>; + }; diff --git a/Documentation/devicetree/bindings/mips/cavium/uctl.txt b/Documentation/devicetree/bindings/mips/cavium/uctl.txt new file mode 100644 index 0000000..aa66b9b --- /dev/null +++ b/Documentation/devicetree/bindings/mips/cavium/uctl.txt @@ -0,0 +1,46 @@ +* UCTL USB controller glue + +Properties: +- compatible: "cavium,octeon-6335-uctl" + + Compatibility with all cn6XXX SOCs. + +- reg: The base address of the UCTL register bank. + +- #address-cells: Must be <2>. + +- #size-cells: Must be <2>. + +- ranges: Empty to signify direct mapping of the children. + +- refclk-frequency: A single cell containing the reference clock + frequency in Hz. + +- refclk-type: A string describing the reference clock connection + either "crystal" or "external". + +Example: + uctl@118006f000000 { + compatible = "cavium,octeon-6335-uctl"; + reg = <0x11800 0x6f000000 0x0 0x100>; + ranges; /* Direct mapping */ + #address-cells = <2>; + #size-cells = <2>; + /* 12MHz, 24MHz and 48MHz allowed */ + refclk-frequency = <24000000>; + /* Either "crystal" or "external" */ + refclk-type = "crystal"; + + ehci@16f0000000000 { + compatible = "cavium,octeon-6335-ehci","usb-ehci"; + reg = <0x16f00 0x00000000 0x0 0x100>; + interrupts = <0 56>; + big-endian-regs; + }; + ohci@16f0000000400 { + compatible = "cavium,octeon-6335-ohci","usb-ohci"; + reg = <0x16f00 0x00000400 0x0 0x100>; + interrupts = <0 56>; + big-endian-regs; + }; + }; diff --git a/Documentation/devicetree/bindings/misc/at25.txt b/Documentation/devicetree/bindings/misc/at25.txt new file mode 100644 index 0000000..ab3c327 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/at25.txt @@ -0,0 +1,21 @@ +Atmel AT25 eeprom + +Required properties: +- compatible : "atmel,at25". +- reg : chip select number +- spi-max-frequency : max spi frequency to use + +- at25,byte-len : total eeprom size in bytes +- at25,addr-mode : addr-mode flags, as defined in include/linux/spi/eeprom.h +- at25,page-size : size of the eeprom page + +Examples: +at25@0 { + compatible = "atmel,at25"; + reg = <0> + spi-max-frequency = <5000000>; + + at25,byte-len = <0x8000>; + at25,addr-mode = <2>; + at25,page-size = <64>; +}; diff --git a/Documentation/devicetree/bindings/misc/bmp085.txt b/Documentation/devicetree/bindings/misc/bmp085.txt new file mode 100644 index 0000000..91dfda2 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/bmp085.txt @@ -0,0 +1,20 @@ +BMP085/BMP18x digital pressure sensors + +Required properties: +- compatible: bosch,bmp085 + +Optional properties: +- chip-id: configurable chip id for non-default chip revisions +- temp-measurement-period: temperature measurement period (milliseconds) +- default-oversampling: default oversampling value to be used at startup, + value range is 0-3 with rising sensitivity. + +Example: + +pressure@77 { + compatible = "bosch,bmp085"; + reg = <0x77>; + chip-id = <10>; + temp-measurement-period = <100>; + default-oversampling = <2>; +}; diff --git a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt index 64bcb8b..bd9be0b 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt +++ b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt @@ -3,19 +3,22 @@ The Enhanced Secure Digital Host Controller provides an interface for MMC, SD, and SDIO types of memory cards. +This file documents differences between the core properties described +by mmc.txt and the properties used by the sdhci-esdhc driver. + Required properties: - - compatible : should be - "fsl,<chip>-esdhc", "fsl,esdhc" - - reg : should contain eSDHC registers location and length. - - interrupts : should contain eSDHC interrupt. - interrupt-parent : interrupt source phandle. - clock-frequency : specifies eSDHC base clock frequency. - - sdhci,wp-inverted : (optional) specifies that eSDHC controller - reports inverted write-protect state; - - sdhci,1-bit-only : (optional) specifies that a controller can - only handle 1-bit data transfers. - - sdhci,auto-cmd12: (optional) specifies that a controller can - only handle auto CMD12. + +Optional properties: + - sdhci,wp-inverted : specifies that eSDHC controller reports + inverted write-protect state; New devices should use the generic + "wp-inverted" property. + - sdhci,1-bit-only : specifies that a controller can only handle + 1-bit data transfers. New devices should use the generic + "bus-width = <1>" property. + - sdhci,auto-cmd12: specifies that a controller can only handle auto + CMD12. Example: diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt index ab22fe6..70cd49b 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt @@ -3,17 +3,15 @@ The Enhanced Secure Digital Host Controller on Freescale i.MX family provides an interface for MMC, SD, and SDIO types of memory cards. +This file documents differences between the core properties described +by mmc.txt and the properties used by the sdhci-esdhc-imx driver. + Required properties: - compatible : Should be "fsl,<chip>-esdhc" -- reg : Should contain eSDHC registers location and length -- interrupts : Should contain eSDHC interrupt Optional properties: -- fsl,card-wired : Indicate the card is wired to host permanently - fsl,cd-internal : Indicate to use controller internal card detection - fsl,wp-internal : Indicate to use controller internal write protection -- cd-gpios : Specify GPIOs for card detection -- wp-gpios : Specify GPIOs for write protection Examples: @@ -29,6 +27,6 @@ esdhc@70008000 { compatible = "fsl,imx51-esdhc"; reg = <0x70008000 0x4000>; interrupts = <2>; - cd-gpios = <&gpio0 6 0>; /* GPIO1_6 */ - wp-gpios = <&gpio0 5 0>; /* GPIO1_5 */ + cd-gpios = <&gpio1 6 0>; /* GPIO1_6 */ + wp-gpios = <&gpio1 5 0>; /* GPIO1_5 */ }; diff --git a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt index 89a0084..0e5e2ec 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt +++ b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt @@ -1,8 +1,9 @@ MMC/SD/SDIO slot directly connected to a SPI bus +This file documents differences between the core properties described +by mmc.txt and the properties used by the mmc_spi driver. + Required properties: -- compatible : should be "mmc-spi-slot". -- reg : should specify SPI address (chip-select number). - spi-max-frequency : maximum frequency for this device (Hz). - voltage-ranges : two cells are required, first cell specifies minimum slot voltage (mV), second cell specifies maximum slot voltage (mV). @@ -10,8 +11,8 @@ Required properties: Optional properties: - gpios : may specify GPIOs in this order: Card-Detect GPIO, - Write-Protect GPIO. -- interrupts : the interrupt of a card detect interrupt. + Write-Protect GPIO. Note that this does not follow the + binding from mmc.txt, for historical reasons. - interrupt-parent : the phandle for the interrupt controller that services interrupts for this device. diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt new file mode 100644 index 0000000..8a6811f --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -0,0 +1,31 @@ +These properties are common to multiple MMC host controllers. Any host +that requires the respective functionality should implement them using +these definitions. + +Interpreted by the OF core: +- reg: Registers location and length. +- interrupts: Interrupts used by the MMC controller. + +Required properties: +- bus-width: Number of data lines, can be <1>, <4>, or <8> + +Optional properties: +- cd-gpios: Specify GPIOs for card detection, see gpio binding +- wp-gpios: Specify GPIOs for write protection, see gpio binding +- cd-inverted: when present, polarity on the cd gpio line is inverted +- wp-inverted: when present, polarity on the wp gpio line is inverted +- non-removable: non-removable slot (like eMMC) +- max-frequency: maximum operating clock frequency + +Example: + +sdhci@ab000000 { + compatible = "sdhci"; + reg = <0xab000000 0x200>; + interrupts = <23>; + bus-width = <4>; + cd-gpios = <&gpio 69 0>; + cd-inverted; + wp-gpios = <&gpio 70 0>; + max-frequency = <50000000>; +} diff --git a/Documentation/devicetree/bindings/mmc/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt new file mode 100644 index 0000000..2b584ca --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mmci.txt @@ -0,0 +1,15 @@ +* ARM PrimeCell MultiMedia Card Interface (MMCI) PL180/1 + +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. + +Required properties: +- compatible : contains "arm,pl18x", "arm,primecell". +- arm,primecell-periphid : contains the PrimeCell Peripheral ID. + +Optional properties: +- mmc-cap-mmc-highspeed : indicates whether MMC is high speed capable +- mmc-cap-sd-highspeed : indicates whether SD is high speed capable diff --git a/Documentation/devicetree/bindings/mmc/mxs-mmc.txt b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt new file mode 100644 index 0000000..54949f6 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/mxs-mmc.txt @@ -0,0 +1,23 @@ +* Freescale MXS MMC controller + +The Freescale MXS Synchronous Serial Ports (SSP) can act as a MMC controller +to support MMC, SD, and SDIO types of memory cards. + +This file documents differences between the core properties in mmc.txt +and the properties used by the mxsmmc driver. + +Required properties: +- compatible: Should be "fsl,<chip>-mmc". The supported chips include + imx23 and imx28. +- interrupts: Should contain ERROR and DMA interrupts +- fsl,ssp-dma-channel: APBH DMA channel for the SSP + +Examples: + +ssp0: ssp@80010000 { + compatible = "fsl,imx28-mmc"; + reg = <0x80010000 2000>; + interrupts = <96 82>; + fsl,ssp-dma-channel = <0>; + bus-width = <8>; +}; diff --git a/Documentation/devicetree/bindings/mmc/nvidia-sdhci.txt b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt index 7e51154..c6d7b11 100644 --- a/Documentation/devicetree/bindings/mmc/nvidia-sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt @@ -3,16 +3,14 @@ This controller on Tegra family SoCs provides an interface for MMC, SD, and SDIO types of memory cards. +This file documents differences between the core properties described +by mmc.txt and the properties used by the sdhci-tegra driver. + Required properties: - compatible : Should be "nvidia,<chip>-sdhci" -- reg : Should contain SD/MMC registers location and length -- interrupts : Should contain SD/MMC interrupt Optional properties: -- cd-gpios : Specify GPIOs for card detection -- wp-gpios : Specify GPIOs for write protection - power-gpios : Specify GPIOs for power control -- support-8bit : Boolean, indicates if 8-bit mode should be used. Example: @@ -23,5 +21,5 @@ sdhci@c8000200 { cd-gpios = <&gpio 69 0>; /* gpio PI5 */ wp-gpios = <&gpio 57 0>; /* gpio PH1 */ power-gpios = <&gpio 155 0>; /* gpio PT3 */ - support-8bit; + bus-width = <8>; }; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt new file mode 100644 index 0000000..dbe98a3 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt @@ -0,0 +1,21 @@ +* Marvell sdhci-pxa v2/v3 controller + +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". + +Optional properties: +- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning. + +Example: + +sdhci@d4280800 { + compatible = "mrvl,pxav3-mmc"; + reg = <0xd4280800 0x800>; + bus-width = <8>; + interrupts = <27>; + non-removable; + mrvl,clk-delay-cycles = <31>; +}; diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index dbd4368..be76a23 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -3,21 +3,20 @@ The Highspeed MMC Host Controller on TI OMAP family provides an interface for MMC, SD, and SDIO types of memory cards. +This file documents differences between the core properties described +by mmc.txt and the properties used by the omap_hsmmc driver. + Required properties: - compatible: Should be "ti,omap2-hsmmc", for OMAP2 controllers Should be "ti,omap3-hsmmc", for OMAP3 controllers Should be "ti,omap4-hsmmc", for OMAP4 controllers - ti,hwmods: Must be "mmc<n>", n is controller instance starting 1 -- reg : should contain hsmmc registers location and length Optional properties: ti,dual-volt: boolean, supports dual voltage cards <supply-name>-supply: phandle to the regulator device tree node "supply-name" examples are "vmmc", "vmmc_aux" etc -ti,bus-width: Number of data lines, default assumed is 1 if the property is missing. -cd-gpios: GPIOs for card detection -wp-gpios: GPIOs for write protection ti,non-removable: non-removable slot (like eMMC) ti,needs-special-reset: Requires a special softreset sequence @@ -27,7 +26,7 @@ Example: reg = <0x4809c000 0x400>; ti,hwmods = "mmc1"; ti,dual-volt; - ti,bus-width = <4>; + bus-width = <4>; vmmc-supply = <&vmmc>; /* phandle to regulator node */ ti,non-removable; }; diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt new file mode 100644 index 0000000..1a5bbd3 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt @@ -0,0 +1,33 @@ +* Freescale General-Purpose Media Interface (GPMI) + +The GPMI nand controller provides an interface to control the +NAND flash chips. We support only one NAND chip now. + +Required properties: + - compatible : should be "fsl,<chip>-gpmi-nand" + - reg : should contain registers location and length for gpmi and bch. + - reg-names: Should contain the reg names "gpmi-nand" and "bch" + - interrupts : The first is the DMA interrupt number for GPMI. + The second is the BCH interrupt number. + - interrupt-names : The interrupt names "gpmi-dma", "bch"; + - fsl,gpmi-dma-channel : Should contain the dma channel it uses. + +The device tree may optionally contain sub-nodes describing partitions of the +address space. See partition.txt for more detail. + +Examples: + +gpmi-nand@8000c000 { + compatible = "fsl,imx28-gpmi-nand"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x8000c000 2000>, <0x8000a000 2000>; + reg-names = "gpmi-nand", "bch"; + interrupts = <88>, <41>; + interrupt-names = "gpmi-dma", "bch"; + fsl,gpmi-dma-channel = <4>; + + partition@0 { + ... + }; +}; diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.txt b/Documentation/devicetree/bindings/mtd/mxc-nand.txt new file mode 100644 index 0000000..b5833d1 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mxc-nand.txt @@ -0,0 +1,19 @@ +* Freescale's mxc_nand + +Required properties: +- compatible: "fsl,imxXX-nand" +- reg: address range of the nfc block +- interrupts: irq to be used +- nand-bus-width: see nand.txt +- nand-ecc-mode: see nand.txt +- nand-on-flash-bbt: see nand.txt + +Example: + + nand@d8000000 { + compatible = "fsl,imx27-nand"; + reg = <0xd8000000 0x1000>; + interrupts = <29>; + nand-bus-width = <8>; + nand-ecc-mode = "hw"; + }; diff --git a/Documentation/devicetree/bindings/mtd/orion-nand.txt b/Documentation/devicetree/bindings/mtd/orion-nand.txt new file mode 100644 index 0000000..2d6ab66 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/orion-nand.txt @@ -0,0 +1,50 @@ +NAND support for Marvell Orion SoC platforms + +Required properties: +- compatible : "marvell,orion-nand". +- reg : Base physical address of the NAND and length of memory mapped + region + +Optional properties: +- cle : Address line number connected to CLE. Default is 0 +- ale : Address line number connected to ALE. Default is 1 +- bank-width : Width in bytes of the device. Default is 1 +- chip-delay : Chip dependent delay for transferring data from array to read + registers in usecs + +The device tree may optionally contain sub-nodes describing partitions of the +address space. See partition.txt for more detail. + +Example: + +nand@f4000000 { + #address-cells = <1>; + #size-cells = <1>; + cle = <0>; + ale = <1>; + bank-width = <1>; + chip-delay = <25>; + compatible = "marvell,orion-nand"; + reg = <0xf4000000 0x400>; + + partition@0 { + label = "u-boot"; + reg = <0x0000000 0x100000>; + read-only; + }; + + partition@100000 { + label = "uImage"; + reg = <0x0100000 0x200000>; + }; + + partition@300000 { + label = "dtb"; + reg = <0x0300000 0x100000>; + }; + + partition@400000 { + label = "root"; + reg = <0x0400000 0x7d00000>; + }; +}; diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt index f114ce1..6e1f61f1 100644 --- a/Documentation/devicetree/bindings/mtd/partition.txt +++ b/Documentation/devicetree/bindings/mtd/partition.txt @@ -35,4 +35,4 @@ flash@0 { uimage@100000 { reg = <0x0100000 0x200000>; }; -]; +}; diff --git a/Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt b/Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt new file mode 100644 index 0000000..7c86d5e --- /dev/null +++ b/Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt @@ -0,0 +1,29 @@ +The Broadcom BCM87XX devices are a family of 10G Ethernet PHYs. They +have these bindings in addition to the standard PHY bindings. + +Compatible: Should contain "broadcom,bcm8706" or "broadcom,bcm8727" and + "ethernet-phy-ieee802.3-c45" + +Optional Properties: + +- broadcom,c45-reg-init : one of more sets of 4 cells. The first cell + is the MDIO Manageable Device (MMD) address, the second a register + address within the MMD, the third cell contains a mask to be ANDed + with the existing register value, and the fourth cell is ORed with + he result to yield the new register value. If the third cell has a + value of zero, no read of the existing value is performed. + +Example: + + ethernet-phy@5 { + reg = <5>; + compatible = "broadcom,bcm8706", "ethernet-phy-ieee802.3-c45"; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + /* + * Set PMD Digital Control Register for + * GPIO[1] Tx/Rx + * GPIO[0] R64 Sync Acquired + */ + broadcom,c45-reg-init = <1 0xc808 0xff8f 0x70>; + }; diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt index 1ad80d5..8ff324e 100644 --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt @@ -1,4 +1,4 @@ -Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC). +Flexcan CAN controller on Freescale's ARM and PowerPC system-on-a-chip (SOC). Required properties: @@ -11,6 +11,9 @@ Required properties: - reg : Offset and length of the register set for this device - interrupts : Interrupt tuple for this device + +Optional properties: + - clock-frequency : The oscillator frequency driving the flexcan device Example: diff --git a/Documentation/devicetree/bindings/net/cavium-mdio.txt b/Documentation/devicetree/bindings/net/cavium-mdio.txt new file mode 100644 index 0000000..04cb749 --- /dev/null +++ b/Documentation/devicetree/bindings/net/cavium-mdio.txt @@ -0,0 +1,27 @@ +* System Management Interface (SMI) / MDIO + +Properties: +- compatible: "cavium,octeon-3860-mdio" + + Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs. + +- reg: The base address of the MDIO bus controller register bank. + +- #address-cells: Must be <1>. + +- #size-cells: Must be <0>. MDIO addresses have no size component. + +Typically an MDIO bus might have several children. + +Example: + mdio@1180000001800 { + compatible = "cavium,octeon-3860-mdio"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x11800 0x00001800 0x0 0x40>; + + ethernet-phy@0 { + ... + reg = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/cavium-mix.txt b/Documentation/devicetree/bindings/net/cavium-mix.txt new file mode 100644 index 0000000..5da628d --- /dev/null +++ b/Documentation/devicetree/bindings/net/cavium-mix.txt @@ -0,0 +1,39 @@ +* MIX Ethernet controller. + +Properties: +- compatible: "cavium,octeon-5750-mix" + + Compatibility with all cn5XXX and cn6XXX SOCs populated with MIX + devices. + +- reg: The base addresses of four separate register banks. The first + bank contains the MIX registers. The second bank the corresponding + AGL registers. The third bank are the AGL registers shared by all + MIX devices present. The fourth bank is the AGL_PRT_CTL shared by + all MIX devices present. + +- cell-index: A single cell specifying which portion of the shared + register banks corresponds to this MIX device. + +- 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. + +Example: + ethernet@1070000100800 { + compatible = "cavium,octeon-5750-mix"; + reg = <0x10700 0x00100800 0x0 0x100>, /* MIX */ + <0x11800 0xE0000800 0x0 0x300>, /* AGL */ + <0x11800 0xE0000400 0x0 0x400>, /* AGL_SHARED */ + <0x11800 0xE0002008 0x0 0x8>; /* AGL_PRT_CTL */ + cell-index = <1>; + interrupts = <1 18>, < 1 46>; + local-mac-address = [ 00 0f b7 10 63 54 ]; + phy-handle = <&phy1>; + }; diff --git a/Documentation/devicetree/bindings/net/cavium-pip.txt b/Documentation/devicetree/bindings/net/cavium-pip.txt new file mode 100644 index 0000000..d4c53ba --- /dev/null +++ b/Documentation/devicetree/bindings/net/cavium-pip.txt @@ -0,0 +1,98 @@ +* PIP Ethernet nexus. + +The PIP Ethernet nexus can control several data packet input/output +devices. The devices have a two level grouping scheme. There may be +several interfaces, and each interface may have several ports. These +ports might be an individual Ethernet PHY. + + +Properties for the PIP nexus: +- compatible: "cavium,octeon-3860-pip" + + Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs. + +- reg: The base address of the PIP's register bank. + +- #address-cells: Must be <1>. + +- #size-cells: Must be <0>. + +Properties for PIP interfaces which is a child the PIP nexus: +- compatible: "cavium,octeon-3860-pip-interface" + + Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs. + +- reg: The interface number. + +- #address-cells: Must be <1>. + +- #size-cells: Must be <0>. + +Properties for PIP port which is a child the PIP interface: +- compatible: "cavium,octeon-3860-pip-port" + + Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs. + +- 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. + +Example: + + pip@11800a0000000 { + compatible = "cavium,octeon-3860-pip"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x11800 0xa0000000 0x0 0x2000>; + + interface@0 { + compatible = "cavium,octeon-3860-pip-interface"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; /* interface */ + + ethernet@0 { + compatible = "cavium,octeon-3860-pip-port"; + reg = <0x0>; /* Port */ + local-mac-address = [ 00 0f b7 10 63 60 ]; + phy-handle = <&phy2>; + }; + ethernet@1 { + compatible = "cavium,octeon-3860-pip-port"; + reg = <0x1>; /* Port */ + local-mac-address = [ 00 0f b7 10 63 61 ]; + phy-handle = <&phy3>; + }; + ethernet@2 { + compatible = "cavium,octeon-3860-pip-port"; + reg = <0x2>; /* Port */ + local-mac-address = [ 00 0f b7 10 63 62 ]; + phy-handle = <&phy4>; + }; + ethernet@3 { + compatible = "cavium,octeon-3860-pip-port"; + reg = <0x3>; /* Port */ + local-mac-address = [ 00 0f b7 10 63 63 ]; + phy-handle = <&phy5>; + }; + }; + + interface@1 { + compatible = "cavium,octeon-3860-pip-interface"; + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; /* interface */ + + ethernet@0 { + compatible = "cavium,octeon-3860-pip-port"; + reg = <0x0>; /* Port */ + local-mac-address = [ 00 0f b7 10 63 64 ]; + phy-handle = <&phy6>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/davinci_emac.txt b/Documentation/devicetree/bindings/net/davinci_emac.txt new file mode 100644 index 0000000..48b259e --- /dev/null +++ b/Documentation/devicetree/bindings/net/davinci_emac.txt @@ -0,0 +1,41 @@ +* Texas Instruments Davinci EMAC + +This file provides information, what the device node +for the davinci_emac interface contains. + +Required properties: +- compatible: "ti,davinci-dm6467-emac"; +- reg: Offset and length of the register set for the device +- ti,davinci-ctrl-reg-offset: offset to control register +- ti,davinci-ctrl-mod-reg-offset: offset to control module register +- ti,davinci-ctrl-ram-offset: offset to control module ram +- ti,davinci-ctrl-ram-size: size of control module ram +- ti,davinci-rmii-en: use RMII +- ti,davinci-no-bd-ram: has the emac controller BD RAM +- phy-handle: Contains a phandle to an Ethernet PHY. + if not, davinci_emac driver defaults to 100/FULL +- interrupts: interrupt mapping for the davinci emac interrupts sources: + 4 sources: <Receive Threshold Interrupt + Receive Interrupt + Transmit Interrupt + Miscellaneous Interrupt> + +Optional properties: +- local-mac-address : 6 bytes, mac address + +Example (enbw_cmc board): + eth0: emac@1e20000 { + compatible = "ti,davinci-dm6467-emac"; + reg = <0x220000 0x4000>; + ti,davinci-ctrl-reg-offset = <0x3000>; + ti,davinci-ctrl-mod-reg-offset = <0x2000>; + ti,davinci-ctrl-ram-offset = <0>; + ti,davinci-ctrl-ram-size = <0x2000>; + local-mac-address = [ 00 00 00 00 00 00 ]; + interrupts = <33 + 34 + 35 + 36 + >; + interrupt-parent = <&intc>; + }; diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt index de43951..d536392 100644 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt @@ -7,18 +7,22 @@ Required properties: - 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-reset-gpios : Should specify the gpio for phy reset 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 + will have the duration be 1 millisecond. Numbers greater than 1000 are + invalid and 1 millisecond will be used instead. Example: -fec@83fec000 { +ethernet@83fec000 { compatible = "fsl,imx51-fec", "fsl,imx27-fec"; reg = <0x83fec000 0x4000>; interrupts = <87>; phy-mode = "mii"; - phy-reset-gpios = <&gpio1 14 0>; /* GPIO2_14 */ + phy-reset-gpios = <&gpio2 14 0>; /* GPIO2_14 */ local-mac-address = [00 04 9F 01 1B B9]; }; diff --git a/Documentation/devicetree/bindings/net/lpc-eth.txt b/Documentation/devicetree/bindings/net/lpc-eth.txt new file mode 100644 index 0000000..585021a --- /dev/null +++ b/Documentation/devicetree/bindings/net/lpc-eth.txt @@ -0,0 +1,24 @@ +* NXP LPC32xx SoC Ethernet Controller + +Required properties: +- compatible: Should be "nxp,lpc-eth" +- reg: Address and length of the register set for the device +- interrupts: Should contain ethernet controller interrupt + +Optional properties: +- phy-mode: String, operation mode of the PHY interface. + Supported values are: "mii", "rmii" (default) +- use-iram: Use LPC32xx internal SRAM (IRAM) for DMA buffering +- local-mac-address : 6 bytes, mac address + +Example: + + mac: ethernet@31060000 { + compatible = "nxp,lpc-eth"; + reg = <0x31060000 0x1000>; + interrupt-parent = <&mic>; + interrupts = <29 0>; + + phy-mode = "rmii"; + use-iram; + }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt b/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt new file mode 100644 index 0000000..7938411 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt @@ -0,0 +1,127 @@ +Properties for an MDIO bus multiplexer/switch controlled by GPIO pins. + +This is a special case of a MDIO bus multiplexer. One or more GPIO +lines are used to control which child bus is connected. + +Required properties in addition to the generic multiplexer properties: + +- compatible : mdio-mux-gpio. +- gpios : GPIO specifiers for each GPIO line. One or more must be specified. + + +Example : + + /* The parent MDIO bus. */ + smi1: mdio@1180000001900 { + compatible = "cavium,octeon-3860-mdio"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x11800 0x00001900 0x0 0x40>; + }; + + /* + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a + pair of GPIO lines. Child busses 2 and 3 populated with 4 + PHYs each. + */ + mdio-mux { + compatible = "mdio-mux-gpio"; + gpios = <&gpio1 3 0>, <&gpio1 4 0>; + mdio-parent-bus = <&smi1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@2 { + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + + phy11: ethernet-phy@1 { + reg = <1>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy12: ethernet-phy@2 { + reg = <2>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy13: ethernet-phy@3 { + reg = <3>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy14: ethernet-phy@4 { + reg = <4>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + }; + + mdio@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + phy21: ethernet-phy@1 { + reg = <1>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy22: ethernet-phy@2 { + reg = <2>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy23: ethernet-phy@3 { + reg = <3>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy24: ethernet-phy@4 { + reg = <4>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt new file mode 100644 index 0000000..f65606f --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux.txt @@ -0,0 +1,136 @@ +Common MDIO bus multiplexer/switch properties. + +An MDIO bus multiplexer/switch will have several child busses that are +numbered uniquely in a device dependent manner. The nodes for an MDIO +bus multiplexer/switch will have one child node for each child bus. + +Required properties: +- mdio-parent-bus : phandle to the parent MDIO bus. +- #address-cells = <1>; +- #size-cells = <0>; + +Optional properties: +- Other properties specific to the multiplexer/switch hardware. + +Required properties for child nodes: +- #address-cells = <1>; +- #size-cells = <0>; +- reg : The sub-bus number. + + +Example : + + /* The parent MDIO bus. */ + smi1: mdio@1180000001900 { + compatible = "cavium,octeon-3860-mdio"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x11800 0x00001900 0x0 0x40>; + }; + + /* + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a + pair of GPIO lines. Child busses 2 and 3 populated with 4 + PHYs each. + */ + mdio-mux { + compatible = "mdio-mux-gpio"; + gpios = <&gpio1 3 0>, <&gpio1 4 0>; + mdio-parent-bus = <&smi1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@2 { + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + + phy11: ethernet-phy@1 { + reg = <1>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy12: ethernet-phy@2 { + reg = <2>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy13: ethernet-phy@3 { + reg = <3>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + phy14: ethernet-phy@4 { + reg = <4>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + }; + + mdio@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + phy21: ethernet-phy@1 { + reg = <1>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy22: ethernet-phy@2 { + reg = <2>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy23: ethernet-phy@3 { + reg = <3>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + phy24: ethernet-phy@4 { + reg = <4>; + compatible = "marvell,88e1149r"; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt index bb8c742..7cd18fb 100644 --- a/Documentation/devicetree/bindings/net/phy.txt +++ b/Documentation/devicetree/bindings/net/phy.txt @@ -14,10 +14,20 @@ Required properties: - linux,phandle : phandle for this node; likely referenced by an ethernet controller node. +Optional Properties: + +- compatible: Compatible list, may contain + "ethernet-phy-ieee802.3-c22" or "ethernet-phy-ieee802.3-c45" for + PHYs that implement IEEE802.3 clause 22 or IEEE802.3 clause 45 + specifications. If neither of these are specified, the default is to + assume clause 22. The compatible list may also contain other + elements. + Example: ethernet-phy@0 { - linux,phandle = <2452000> + compatible = "ethernet-phy-ieee802.3-c22"; + linux,phandle = <2452000>; interrupt-parent = <40000>; interrupts = <35 1>; reg = <0>; diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index 1f62623..060bbf0 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -1,7 +1,8 @@ * STMicroelectronics 10/100/1000 Ethernet driver (GMAC) Required properties: -- compatible: Should be "st,spear600-gmac" +- compatible: Should be "snps,dwmac-<ip_version>" "snps,dwmac" + For backwards compatibility: "st,spear600-gmac" is also supported. - 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 diff --git a/Documentation/devicetree/bindings/nvec/nvec_nvidia.txt b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt index 5aeee53..5aeee53 100644 --- a/Documentation/devicetree/bindings/nvec/nvec_nvidia.txt +++ b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt new file mode 100644 index 0000000..ab19e6b --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt @@ -0,0 +1,95 @@ +* Freescale IOMUX Controller (IOMUXC) for i.MX + +The IOMUX Controller (IOMUXC), together with the IOMUX, enables the IC +to share one PAD to several functional blocks. The sharing is done by +multiplexing the PAD input/output signals. For each PAD there are up to +8 muxing options (called ALT modes). Since different modules require +different PAD settings (like pull up, keeper, etc) the IOMUXC controls +also the PAD settings parameters. + +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". + +Freescale IMX pin configuration node is a node of a group of pins which can be +used for a specific device or function. This node represents both mux and config +of the pins in that group. The 'mux' selects the function mode(also named mux +mode) this pin can work on and the 'config' configures various pad settings +such as pull-up, open drain, drive strength, etc. + +Required properties for iomux controller: +- compatible: "fsl,<soc>-iomuxc" + Please refer to each fsl,<soc>-pinctrl.txt binding doc for supported SoCs. + +Required properties for pin configuration node: +- fsl,pins: two integers array, represents a group of pins mux and config + setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a + pin working on a specific function, CONFIG is the pad setting value like + pull-up on this pin. Please refer to fsl,<soc>-pinctrl.txt for the valid + pins and functions of each SoC. + +Bits used for CONFIG: +NO_PAD_CTL(1 << 31): indicate this pin does not need config. + +SION(1 << 30): Software Input On Field. +Force the selected mux mode input path no matter of MUX_MODE functionality. +By default the input path is determined by functionality of the selected +mux mode (regular). + +Other bits are used for PAD setting. +Please refer to each fsl,<soc>-pinctrl,txt binding doc for SoC specific part +of bits definitions. + +NOTE: +Some requirements for using fsl,imx-pinctrl binding: +1. We have pin function node defined under iomux controller node to represent + what pinmux functions this SoC supports. +2. The pin configuration node intends to work on a specific function should + to be defined under that specific function node. + The function node's name should represent well about what function + this group of pins in this pin configuration node are working on. +3. The driver can use the function node's name and pin configuration node's + name describe the pin function and group hierarchy. + For example, Linux IMX pinctrl driver takes the function node's name + as the function name and pin configuration node's name as group name to + create the map table. +4. Each pin configuration node should have a phandle, devices can set pins + configurations by referring to the phandle of that pin configuration node. + +Examples: +usdhc@0219c000 { /* uSDHC4 */ + fsl,card-wired; + vmmc-supply = <®_3p3v>; + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usdhc4_1>; +}; + +iomuxc@020e0000 { + compatible = "fsl,imx6q-iomuxc"; + reg = <0x020e0000 0x4000>; + + /* shared pinctrl settings */ + usdhc4 { + pinctrl_usdhc4_1: usdhc4grp-1 { + fsl,pins = <1386 0x17059 /* MX6Q_PAD_SD4_CMD__USDHC4_CMD */ + 1392 0x10059 /* MX6Q_PAD_SD4_CLK__USDHC4_CLK */ + 1462 0x17059 /* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */ + 1470 0x17059 /* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */ + 1478 0x17059 /* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */ + 1486 0x17059 /* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */ + 1493 0x17059 /* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */ + 1501 0x17059 /* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */ + 1509 0x17059 /* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */ + 1517 0x17059>; /* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */ + }; + }; + .... +}; +Refer to the IOMUXC controller chapter in imx6q datasheet, +0x17059 means enable hysteresis, 47KOhm Pull Up, 50Mhz speed, +80Ohm driver strength and Fast Slew Rate. +User should refer to each SoC spec to set the correct value. + +TODO: when dtc macro support is available, we can change above raw data +to dt macro which can get better readability in dts file. diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt new file mode 100644 index 0000000..b96fa4c --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx51-pinctrl.txt @@ -0,0 +1,787 @@ +* Freescale IMX51 IOMUX Controller + +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part +and usage. + +Required properties: +- compatible: "fsl,imx51-iomuxc" +- fsl,pins: two integers array, represents a group of pins mux and config + setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a + pin working on a specific function, CONFIG is the pad setting value like + pull-up for this pin. Please refer to imx51 datasheet for the valid pad + config settings. + +CONFIG bits definition: +PAD_CTL_HVE (1 << 13) +PAD_CTL_HYS (1 << 8) +PAD_CTL_PKE (1 << 7) +PAD_CTL_PUE (1 << 6) +PAD_CTL_PUS_100K_DOWN (0 << 4) +PAD_CTL_PUS_47K_UP (1 << 4) +PAD_CTL_PUS_100K_UP (2 << 4) +PAD_CTL_PUS_22K_UP (3 << 4) +PAD_CTL_ODE (1 << 3) +PAD_CTL_DSE_LOW (0 << 1) +PAD_CTL_DSE_MED (1 << 1) +PAD_CTL_DSE_HIGH (2 << 1) +PAD_CTL_DSE_MAX (3 << 1) +PAD_CTL_SRE_FAST (1 << 0) +PAD_CTL_SRE_SLOW (0 << 0) + +See below for available PIN_FUNC_ID for imx51: +MX51_PAD_EIM_D16__AUD4_RXFS 0 +MX51_PAD_EIM_D16__AUD5_TXD 1 +MX51_PAD_EIM_D16__EIM_D16 2 +MX51_PAD_EIM_D16__GPIO2_0 3 +MX51_PAD_EIM_D16__I2C1_SDA 4 +MX51_PAD_EIM_D16__UART2_CTS 5 +MX51_PAD_EIM_D16__USBH2_DATA0 6 +MX51_PAD_EIM_D17__AUD5_RXD 7 +MX51_PAD_EIM_D17__EIM_D17 8 +MX51_PAD_EIM_D17__GPIO2_1 9 +MX51_PAD_EIM_D17__UART2_RXD 10 +MX51_PAD_EIM_D17__UART3_CTS 11 +MX51_PAD_EIM_D17__USBH2_DATA1 12 +MX51_PAD_EIM_D18__AUD5_TXC 13 +MX51_PAD_EIM_D18__EIM_D18 14 +MX51_PAD_EIM_D18__GPIO2_2 15 +MX51_PAD_EIM_D18__UART2_TXD 16 +MX51_PAD_EIM_D18__UART3_RTS 17 +MX51_PAD_EIM_D18__USBH2_DATA2 18 +MX51_PAD_EIM_D19__AUD4_RXC 19 +MX51_PAD_EIM_D19__AUD5_TXFS 20 +MX51_PAD_EIM_D19__EIM_D19 21 +MX51_PAD_EIM_D19__GPIO2_3 22 +MX51_PAD_EIM_D19__I2C1_SCL 23 +MX51_PAD_EIM_D19__UART2_RTS 24 +MX51_PAD_EIM_D19__USBH2_DATA3 25 +MX51_PAD_EIM_D20__AUD4_TXD 26 +MX51_PAD_EIM_D20__EIM_D20 27 +MX51_PAD_EIM_D20__GPIO2_4 28 +MX51_PAD_EIM_D20__SRTC_ALARM_DEB 29 +MX51_PAD_EIM_D20__USBH2_DATA4 30 +MX51_PAD_EIM_D21__AUD4_RXD 31 +MX51_PAD_EIM_D21__EIM_D21 32 +MX51_PAD_EIM_D21__GPIO2_5 33 +MX51_PAD_EIM_D21__SRTC_ALARM_DEB 34 +MX51_PAD_EIM_D21__USBH2_DATA5 35 +MX51_PAD_EIM_D22__AUD4_TXC 36 +MX51_PAD_EIM_D22__EIM_D22 37 +MX51_PAD_EIM_D22__GPIO2_6 38 +MX51_PAD_EIM_D22__USBH2_DATA6 39 +MX51_PAD_EIM_D23__AUD4_TXFS 40 +MX51_PAD_EIM_D23__EIM_D23 41 +MX51_PAD_EIM_D23__GPIO2_7 42 +MX51_PAD_EIM_D23__SPDIF_OUT1 43 +MX51_PAD_EIM_D23__USBH2_DATA7 44 +MX51_PAD_EIM_D24__AUD6_RXFS 45 +MX51_PAD_EIM_D24__EIM_D24 46 +MX51_PAD_EIM_D24__GPIO2_8 47 +MX51_PAD_EIM_D24__I2C2_SDA 48 +MX51_PAD_EIM_D24__UART3_CTS 49 +MX51_PAD_EIM_D24__USBOTG_DATA0 50 +MX51_PAD_EIM_D25__EIM_D25 51 +MX51_PAD_EIM_D25__KEY_COL6 52 +MX51_PAD_EIM_D25__UART2_CTS 53 +MX51_PAD_EIM_D25__UART3_RXD 54 +MX51_PAD_EIM_D25__USBOTG_DATA1 55 +MX51_PAD_EIM_D26__EIM_D26 56 +MX51_PAD_EIM_D26__KEY_COL7 57 +MX51_PAD_EIM_D26__UART2_RTS 58 +MX51_PAD_EIM_D26__UART3_TXD 59 +MX51_PAD_EIM_D26__USBOTG_DATA2 60 +MX51_PAD_EIM_D27__AUD6_RXC 61 +MX51_PAD_EIM_D27__EIM_D27 62 +MX51_PAD_EIM_D27__GPIO2_9 63 +MX51_PAD_EIM_D27__I2C2_SCL 64 +MX51_PAD_EIM_D27__UART3_RTS 65 +MX51_PAD_EIM_D27__USBOTG_DATA3 66 +MX51_PAD_EIM_D28__AUD6_TXD 67 +MX51_PAD_EIM_D28__EIM_D28 68 +MX51_PAD_EIM_D28__KEY_ROW4 69 +MX51_PAD_EIM_D28__USBOTG_DATA4 70 +MX51_PAD_EIM_D29__AUD6_RXD 71 +MX51_PAD_EIM_D29__EIM_D29 72 +MX51_PAD_EIM_D29__KEY_ROW5 73 +MX51_PAD_EIM_D29__USBOTG_DATA5 74 +MX51_PAD_EIM_D30__AUD6_TXC 75 +MX51_PAD_EIM_D30__EIM_D30 76 +MX51_PAD_EIM_D30__KEY_ROW6 77 +MX51_PAD_EIM_D30__USBOTG_DATA6 78 +MX51_PAD_EIM_D31__AUD6_TXFS 79 +MX51_PAD_EIM_D31__EIM_D31 80 +MX51_PAD_EIM_D31__KEY_ROW7 81 +MX51_PAD_EIM_D31__USBOTG_DATA7 82 +MX51_PAD_EIM_A16__EIM_A16 83 +MX51_PAD_EIM_A16__GPIO2_10 84 +MX51_PAD_EIM_A16__OSC_FREQ_SEL0 85 +MX51_PAD_EIM_A17__EIM_A17 86 +MX51_PAD_EIM_A17__GPIO2_11 87 +MX51_PAD_EIM_A17__OSC_FREQ_SEL1 88 +MX51_PAD_EIM_A18__BOOT_LPB0 89 +MX51_PAD_EIM_A18__EIM_A18 90 +MX51_PAD_EIM_A18__GPIO2_12 91 +MX51_PAD_EIM_A19__BOOT_LPB1 92 +MX51_PAD_EIM_A19__EIM_A19 93 +MX51_PAD_EIM_A19__GPIO2_13 94 +MX51_PAD_EIM_A20__BOOT_UART_SRC0 95 +MX51_PAD_EIM_A20__EIM_A20 96 +MX51_PAD_EIM_A20__GPIO2_14 97 +MX51_PAD_EIM_A21__BOOT_UART_SRC1 98 +MX51_PAD_EIM_A21__EIM_A21 99 +MX51_PAD_EIM_A21__GPIO2_15 100 +MX51_PAD_EIM_A22__EIM_A22 101 +MX51_PAD_EIM_A22__GPIO2_16 102 +MX51_PAD_EIM_A23__BOOT_HPN_EN 103 +MX51_PAD_EIM_A23__EIM_A23 104 +MX51_PAD_EIM_A23__GPIO2_17 105 +MX51_PAD_EIM_A24__EIM_A24 106 +MX51_PAD_EIM_A24__GPIO2_18 107 +MX51_PAD_EIM_A24__USBH2_CLK 108 +MX51_PAD_EIM_A25__DISP1_PIN4 109 +MX51_PAD_EIM_A25__EIM_A25 110 +MX51_PAD_EIM_A25__GPIO2_19 111 +MX51_PAD_EIM_A25__USBH2_DIR 112 +MX51_PAD_EIM_A26__CSI1_DATA_EN 113 +MX51_PAD_EIM_A26__DISP2_EXT_CLK 114 +MX51_PAD_EIM_A26__EIM_A26 115 +MX51_PAD_EIM_A26__GPIO2_20 116 +MX51_PAD_EIM_A26__USBH2_STP 117 +MX51_PAD_EIM_A27__CSI2_DATA_EN 118 +MX51_PAD_EIM_A27__DISP1_PIN1 119 +MX51_PAD_EIM_A27__EIM_A27 120 +MX51_PAD_EIM_A27__GPIO2_21 121 +MX51_PAD_EIM_A27__USBH2_NXT 122 +MX51_PAD_EIM_EB0__EIM_EB0 123 +MX51_PAD_EIM_EB1__EIM_EB1 124 +MX51_PAD_EIM_EB2__AUD5_RXFS 125 +MX51_PAD_EIM_EB2__CSI1_D2 126 +MX51_PAD_EIM_EB2__EIM_EB2 127 +MX51_PAD_EIM_EB2__FEC_MDIO 128 +MX51_PAD_EIM_EB2__GPIO2_22 129 +MX51_PAD_EIM_EB2__GPT_CMPOUT1 130 +MX51_PAD_EIM_EB3__AUD5_RXC 131 +MX51_PAD_EIM_EB3__CSI1_D3 132 +MX51_PAD_EIM_EB3__EIM_EB3 133 +MX51_PAD_EIM_EB3__FEC_RDATA1 134 +MX51_PAD_EIM_EB3__GPIO2_23 135 +MX51_PAD_EIM_EB3__GPT_CMPOUT2 136 +MX51_PAD_EIM_OE__EIM_OE 137 +MX51_PAD_EIM_OE__GPIO2_24 138 +MX51_PAD_EIM_CS0__EIM_CS0 139 +MX51_PAD_EIM_CS0__GPIO2_25 140 +MX51_PAD_EIM_CS1__EIM_CS1 141 +MX51_PAD_EIM_CS1__GPIO2_26 142 +MX51_PAD_EIM_CS2__AUD5_TXD 143 +MX51_PAD_EIM_CS2__CSI1_D4 144 +MX51_PAD_EIM_CS2__EIM_CS2 145 +MX51_PAD_EIM_CS2__FEC_RDATA2 146 +MX51_PAD_EIM_CS2__GPIO2_27 147 +MX51_PAD_EIM_CS2__USBOTG_STP 148 +MX51_PAD_EIM_CS3__AUD5_RXD 149 +MX51_PAD_EIM_CS3__CSI1_D5 150 +MX51_PAD_EIM_CS3__EIM_CS3 151 +MX51_PAD_EIM_CS3__FEC_RDATA3 152 +MX51_PAD_EIM_CS3__GPIO2_28 153 +MX51_PAD_EIM_CS3__USBOTG_NXT 154 +MX51_PAD_EIM_CS4__AUD5_TXC 155 +MX51_PAD_EIM_CS4__CSI1_D6 156 +MX51_PAD_EIM_CS4__EIM_CS4 157 +MX51_PAD_EIM_CS4__FEC_RX_ER 158 +MX51_PAD_EIM_CS4__GPIO2_29 159 +MX51_PAD_EIM_CS4__USBOTG_CLK 160 +MX51_PAD_EIM_CS5__AUD5_TXFS 161 +MX51_PAD_EIM_CS5__CSI1_D7 162 +MX51_PAD_EIM_CS5__DISP1_EXT_CLK 163 +MX51_PAD_EIM_CS5__EIM_CS5 164 +MX51_PAD_EIM_CS5__FEC_CRS 165 +MX51_PAD_EIM_CS5__GPIO2_30 166 +MX51_PAD_EIM_CS5__USBOTG_DIR 167 +MX51_PAD_EIM_DTACK__EIM_DTACK 168 +MX51_PAD_EIM_DTACK__GPIO2_31 169 +MX51_PAD_EIM_LBA__EIM_LBA 170 +MX51_PAD_EIM_LBA__GPIO3_1 171 +MX51_PAD_EIM_CRE__EIM_CRE 172 +MX51_PAD_EIM_CRE__GPIO3_2 173 +MX51_PAD_DRAM_CS1__DRAM_CS1 174 +MX51_PAD_NANDF_WE_B__GPIO3_3 175 +MX51_PAD_NANDF_WE_B__NANDF_WE_B 176 +MX51_PAD_NANDF_WE_B__PATA_DIOW 177 +MX51_PAD_NANDF_WE_B__SD3_DATA0 178 +MX51_PAD_NANDF_RE_B__GPIO3_4 179 +MX51_PAD_NANDF_RE_B__NANDF_RE_B 180 +MX51_PAD_NANDF_RE_B__PATA_DIOR 181 +MX51_PAD_NANDF_RE_B__SD3_DATA1 182 +MX51_PAD_NANDF_ALE__GPIO3_5 183 +MX51_PAD_NANDF_ALE__NANDF_ALE 184 +MX51_PAD_NANDF_ALE__PATA_BUFFER_EN 185 +MX51_PAD_NANDF_CLE__GPIO3_6 186 +MX51_PAD_NANDF_CLE__NANDF_CLE 187 +MX51_PAD_NANDF_CLE__PATA_RESET_B 188 +MX51_PAD_NANDF_WP_B__GPIO3_7 189 +MX51_PAD_NANDF_WP_B__NANDF_WP_B 190 +MX51_PAD_NANDF_WP_B__PATA_DMACK 191 +MX51_PAD_NANDF_WP_B__SD3_DATA2 192 +MX51_PAD_NANDF_RB0__ECSPI2_SS1 193 +MX51_PAD_NANDF_RB0__GPIO3_8 194 +MX51_PAD_NANDF_RB0__NANDF_RB0 195 +MX51_PAD_NANDF_RB0__PATA_DMARQ 196 +MX51_PAD_NANDF_RB0__SD3_DATA3 197 +MX51_PAD_NANDF_RB1__CSPI_MOSI 198 +MX51_PAD_NANDF_RB1__ECSPI2_RDY 199 +MX51_PAD_NANDF_RB1__GPIO3_9 200 +MX51_PAD_NANDF_RB1__NANDF_RB1 201 +MX51_PAD_NANDF_RB1__PATA_IORDY 202 +MX51_PAD_NANDF_RB1__SD4_CMD 203 +MX51_PAD_NANDF_RB2__DISP2_WAIT 204 +MX51_PAD_NANDF_RB2__ECSPI2_SCLK 205 +MX51_PAD_NANDF_RB2__FEC_COL 206 +MX51_PAD_NANDF_RB2__GPIO3_10 207 +MX51_PAD_NANDF_RB2__NANDF_RB2 208 +MX51_PAD_NANDF_RB2__USBH3_H3_DP 209 +MX51_PAD_NANDF_RB2__USBH3_NXT 210 +MX51_PAD_NANDF_RB3__DISP1_WAIT 211 +MX51_PAD_NANDF_RB3__ECSPI2_MISO 212 +MX51_PAD_NANDF_RB3__FEC_RX_CLK 213 +MX51_PAD_NANDF_RB3__GPIO3_11 214 +MX51_PAD_NANDF_RB3__NANDF_RB3 215 +MX51_PAD_NANDF_RB3__USBH3_CLK 216 +MX51_PAD_NANDF_RB3__USBH3_H3_DM 217 +MX51_PAD_GPIO_NAND__GPIO_NAND 218 +MX51_PAD_GPIO_NAND__PATA_INTRQ 219 +MX51_PAD_NANDF_CS0__GPIO3_16 220 +MX51_PAD_NANDF_CS0__NANDF_CS0 221 +MX51_PAD_NANDF_CS1__GPIO3_17 222 +MX51_PAD_NANDF_CS1__NANDF_CS1 223 +MX51_PAD_NANDF_CS2__CSPI_SCLK 224 +MX51_PAD_NANDF_CS2__FEC_TX_ER 225 +MX51_PAD_NANDF_CS2__GPIO3_18 226 +MX51_PAD_NANDF_CS2__NANDF_CS2 227 +MX51_PAD_NANDF_CS2__PATA_CS_0 228 +MX51_PAD_NANDF_CS2__SD4_CLK 229 +MX51_PAD_NANDF_CS2__USBH3_H1_DP 230 +MX51_PAD_NANDF_CS3__FEC_MDC 231 +MX51_PAD_NANDF_CS3__GPIO3_19 232 +MX51_PAD_NANDF_CS3__NANDF_CS3 233 +MX51_PAD_NANDF_CS3__PATA_CS_1 234 +MX51_PAD_NANDF_CS3__SD4_DAT0 235 +MX51_PAD_NANDF_CS3__USBH3_H1_DM 236 +MX51_PAD_NANDF_CS4__FEC_TDATA1 237 +MX51_PAD_NANDF_CS4__GPIO3_20 238 +MX51_PAD_NANDF_CS4__NANDF_CS4 239 +MX51_PAD_NANDF_CS4__PATA_DA_0 240 +MX51_PAD_NANDF_CS4__SD4_DAT1 241 +MX51_PAD_NANDF_CS4__USBH3_STP 242 +MX51_PAD_NANDF_CS5__FEC_TDATA2 243 +MX51_PAD_NANDF_CS5__GPIO3_21 244 +MX51_PAD_NANDF_CS5__NANDF_CS5 245 +MX51_PAD_NANDF_CS5__PATA_DA_1 246 +MX51_PAD_NANDF_CS5__SD4_DAT2 247 +MX51_PAD_NANDF_CS5__USBH3_DIR 248 +MX51_PAD_NANDF_CS6__CSPI_SS3 249 +MX51_PAD_NANDF_CS6__FEC_TDATA3 250 +MX51_PAD_NANDF_CS6__GPIO3_22 251 +MX51_PAD_NANDF_CS6__NANDF_CS6 252 +MX51_PAD_NANDF_CS6__PATA_DA_2 253 +MX51_PAD_NANDF_CS6__SD4_DAT3 254 +MX51_PAD_NANDF_CS7__FEC_TX_EN 255 +MX51_PAD_NANDF_CS7__GPIO3_23 256 +MX51_PAD_NANDF_CS7__NANDF_CS7 257 +MX51_PAD_NANDF_CS7__SD3_CLK 258 +MX51_PAD_NANDF_RDY_INT__ECSPI2_SS0 259 +MX51_PAD_NANDF_RDY_INT__FEC_TX_CLK 260 +MX51_PAD_NANDF_RDY_INT__GPIO3_24 261 +MX51_PAD_NANDF_RDY_INT__NANDF_RDY_INT 262 +MX51_PAD_NANDF_RDY_INT__SD3_CMD 263 +MX51_PAD_NANDF_D15__ECSPI2_MOSI 264 +MX51_PAD_NANDF_D15__GPIO3_25 265 +MX51_PAD_NANDF_D15__NANDF_D15 266 +MX51_PAD_NANDF_D15__PATA_DATA15 267 +MX51_PAD_NANDF_D15__SD3_DAT7 268 +MX51_PAD_NANDF_D14__ECSPI2_SS3 269 +MX51_PAD_NANDF_D14__GPIO3_26 270 +MX51_PAD_NANDF_D14__NANDF_D14 271 +MX51_PAD_NANDF_D14__PATA_DATA14 272 +MX51_PAD_NANDF_D14__SD3_DAT6 273 +MX51_PAD_NANDF_D13__ECSPI2_SS2 274 +MX51_PAD_NANDF_D13__GPIO3_27 275 +MX51_PAD_NANDF_D13__NANDF_D13 276 +MX51_PAD_NANDF_D13__PATA_DATA13 277 +MX51_PAD_NANDF_D13__SD3_DAT5 278 +MX51_PAD_NANDF_D12__ECSPI2_SS1 279 +MX51_PAD_NANDF_D12__GPIO3_28 280 +MX51_PAD_NANDF_D12__NANDF_D12 281 +MX51_PAD_NANDF_D12__PATA_DATA12 282 +MX51_PAD_NANDF_D12__SD3_DAT4 283 +MX51_PAD_NANDF_D11__FEC_RX_DV 284 +MX51_PAD_NANDF_D11__GPIO3_29 285 +MX51_PAD_NANDF_D11__NANDF_D11 286 +MX51_PAD_NANDF_D11__PATA_DATA11 287 +MX51_PAD_NANDF_D11__SD3_DATA3 288 +MX51_PAD_NANDF_D10__GPIO3_30 289 +MX51_PAD_NANDF_D10__NANDF_D10 290 +MX51_PAD_NANDF_D10__PATA_DATA10 291 +MX51_PAD_NANDF_D10__SD3_DATA2 292 +MX51_PAD_NANDF_D9__FEC_RDATA0 293 +MX51_PAD_NANDF_D9__GPIO3_31 294 +MX51_PAD_NANDF_D9__NANDF_D9 295 +MX51_PAD_NANDF_D9__PATA_DATA9 296 +MX51_PAD_NANDF_D9__SD3_DATA1 297 +MX51_PAD_NANDF_D8__FEC_TDATA0 298 +MX51_PAD_NANDF_D8__GPIO4_0 299 +MX51_PAD_NANDF_D8__NANDF_D8 300 +MX51_PAD_NANDF_D8__PATA_DATA8 301 +MX51_PAD_NANDF_D8__SD3_DATA0 302 +MX51_PAD_NANDF_D7__GPIO4_1 303 +MX51_PAD_NANDF_D7__NANDF_D7 304 +MX51_PAD_NANDF_D7__PATA_DATA7 305 +MX51_PAD_NANDF_D7__USBH3_DATA0 306 +MX51_PAD_NANDF_D6__GPIO4_2 307 +MX51_PAD_NANDF_D6__NANDF_D6 308 +MX51_PAD_NANDF_D6__PATA_DATA6 309 +MX51_PAD_NANDF_D6__SD4_LCTL 310 +MX51_PAD_NANDF_D6__USBH3_DATA1 311 +MX51_PAD_NANDF_D5__GPIO4_3 312 +MX51_PAD_NANDF_D5__NANDF_D5 313 +MX51_PAD_NANDF_D5__PATA_DATA5 314 +MX51_PAD_NANDF_D5__SD4_WP 315 +MX51_PAD_NANDF_D5__USBH3_DATA2 316 +MX51_PAD_NANDF_D4__GPIO4_4 317 +MX51_PAD_NANDF_D4__NANDF_D4 318 +MX51_PAD_NANDF_D4__PATA_DATA4 319 +MX51_PAD_NANDF_D4__SD4_CD 320 +MX51_PAD_NANDF_D4__USBH3_DATA3 321 +MX51_PAD_NANDF_D3__GPIO4_5 322 +MX51_PAD_NANDF_D3__NANDF_D3 323 +MX51_PAD_NANDF_D3__PATA_DATA3 324 +MX51_PAD_NANDF_D3__SD4_DAT4 325 +MX51_PAD_NANDF_D3__USBH3_DATA4 326 +MX51_PAD_NANDF_D2__GPIO4_6 327 +MX51_PAD_NANDF_D2__NANDF_D2 328 +MX51_PAD_NANDF_D2__PATA_DATA2 329 +MX51_PAD_NANDF_D2__SD4_DAT5 330 +MX51_PAD_NANDF_D2__USBH3_DATA5 331 +MX51_PAD_NANDF_D1__GPIO4_7 332 +MX51_PAD_NANDF_D1__NANDF_D1 333 +MX51_PAD_NANDF_D1__PATA_DATA1 334 +MX51_PAD_NANDF_D1__SD4_DAT6 335 +MX51_PAD_NANDF_D1__USBH3_DATA6 336 +MX51_PAD_NANDF_D0__GPIO4_8 337 +MX51_PAD_NANDF_D0__NANDF_D0 338 +MX51_PAD_NANDF_D0__PATA_DATA0 339 +MX51_PAD_NANDF_D0__SD4_DAT7 340 +MX51_PAD_NANDF_D0__USBH3_DATA7 341 +MX51_PAD_CSI1_D8__CSI1_D8 342 +MX51_PAD_CSI1_D8__GPIO3_12 343 +MX51_PAD_CSI1_D9__CSI1_D9 344 +MX51_PAD_CSI1_D9__GPIO3_13 345 +MX51_PAD_CSI1_D10__CSI1_D10 346 +MX51_PAD_CSI1_D11__CSI1_D11 347 +MX51_PAD_CSI1_D12__CSI1_D12 348 +MX51_PAD_CSI1_D13__CSI1_D13 349 +MX51_PAD_CSI1_D14__CSI1_D14 350 +MX51_PAD_CSI1_D15__CSI1_D15 351 +MX51_PAD_CSI1_D16__CSI1_D16 352 +MX51_PAD_CSI1_D17__CSI1_D17 353 +MX51_PAD_CSI1_D18__CSI1_D18 354 +MX51_PAD_CSI1_D19__CSI1_D19 355 +MX51_PAD_CSI1_VSYNC__CSI1_VSYNC 356 +MX51_PAD_CSI1_VSYNC__GPIO3_14 357 +MX51_PAD_CSI1_HSYNC__CSI1_HSYNC 358 +MX51_PAD_CSI1_HSYNC__GPIO3_15 359 +MX51_PAD_CSI1_PIXCLK__CSI1_PIXCLK 360 +MX51_PAD_CSI1_MCLK__CSI1_MCLK 361 +MX51_PAD_CSI2_D12__CSI2_D12 362 +MX51_PAD_CSI2_D12__GPIO4_9 363 +MX51_PAD_CSI2_D13__CSI2_D13 364 +MX51_PAD_CSI2_D13__GPIO4_10 365 +MX51_PAD_CSI2_D14__CSI2_D14 366 +MX51_PAD_CSI2_D15__CSI2_D15 367 +MX51_PAD_CSI2_D16__CSI2_D16 368 +MX51_PAD_CSI2_D17__CSI2_D17 369 +MX51_PAD_CSI2_D18__CSI2_D18 370 +MX51_PAD_CSI2_D18__GPIO4_11 371 +MX51_PAD_CSI2_D19__CSI2_D19 372 +MX51_PAD_CSI2_D19__GPIO4_12 373 +MX51_PAD_CSI2_VSYNC__CSI2_VSYNC 374 +MX51_PAD_CSI2_VSYNC__GPIO4_13 375 +MX51_PAD_CSI2_HSYNC__CSI2_HSYNC 376 +MX51_PAD_CSI2_HSYNC__GPIO4_14 377 +MX51_PAD_CSI2_PIXCLK__CSI2_PIXCLK 378 +MX51_PAD_CSI2_PIXCLK__GPIO4_15 379 +MX51_PAD_I2C1_CLK__GPIO4_16 380 +MX51_PAD_I2C1_CLK__I2C1_CLK 381 +MX51_PAD_I2C1_DAT__GPIO4_17 382 +MX51_PAD_I2C1_DAT__I2C1_DAT 383 +MX51_PAD_AUD3_BB_TXD__AUD3_TXD 384 +MX51_PAD_AUD3_BB_TXD__GPIO4_18 385 +MX51_PAD_AUD3_BB_RXD__AUD3_RXD 386 +MX51_PAD_AUD3_BB_RXD__GPIO4_19 387 +MX51_PAD_AUD3_BB_RXD__UART3_RXD 388 +MX51_PAD_AUD3_BB_CK__AUD3_TXC 389 +MX51_PAD_AUD3_BB_CK__GPIO4_20 390 +MX51_PAD_AUD3_BB_FS__AUD3_TXFS 391 +MX51_PAD_AUD3_BB_FS__GPIO4_21 392 +MX51_PAD_AUD3_BB_FS__UART3_TXD 393 +MX51_PAD_CSPI1_MOSI__ECSPI1_MOSI 394 +MX51_PAD_CSPI1_MOSI__GPIO4_22 395 +MX51_PAD_CSPI1_MOSI__I2C1_SDA 396 +MX51_PAD_CSPI1_MISO__AUD4_RXD 397 +MX51_PAD_CSPI1_MISO__ECSPI1_MISO 398 +MX51_PAD_CSPI1_MISO__GPIO4_23 399 +MX51_PAD_CSPI1_SS0__AUD4_TXC 400 +MX51_PAD_CSPI1_SS0__ECSPI1_SS0 401 +MX51_PAD_CSPI1_SS0__GPIO4_24 402 +MX51_PAD_CSPI1_SS1__AUD4_TXD 403 +MX51_PAD_CSPI1_SS1__ECSPI1_SS1 404 +MX51_PAD_CSPI1_SS1__GPIO4_25 405 +MX51_PAD_CSPI1_RDY__AUD4_TXFS 406 +MX51_PAD_CSPI1_RDY__ECSPI1_RDY 407 +MX51_PAD_CSPI1_RDY__GPIO4_26 408 +MX51_PAD_CSPI1_SCLK__ECSPI1_SCLK 409 +MX51_PAD_CSPI1_SCLK__GPIO4_27 410 +MX51_PAD_CSPI1_SCLK__I2C1_SCL 411 +MX51_PAD_UART1_RXD__GPIO4_28 412 +MX51_PAD_UART1_RXD__UART1_RXD 413 +MX51_PAD_UART1_TXD__GPIO4_29 414 +MX51_PAD_UART1_TXD__PWM2_PWMO 415 +MX51_PAD_UART1_TXD__UART1_TXD 416 +MX51_PAD_UART1_RTS__GPIO4_30 417 +MX51_PAD_UART1_RTS__UART1_RTS 418 +MX51_PAD_UART1_CTS__GPIO4_31 419 +MX51_PAD_UART1_CTS__UART1_CTS 420 +MX51_PAD_UART2_RXD__FIRI_TXD 421 +MX51_PAD_UART2_RXD__GPIO1_20 422 +MX51_PAD_UART2_RXD__UART2_RXD 423 +MX51_PAD_UART2_TXD__FIRI_RXD 424 +MX51_PAD_UART2_TXD__GPIO1_21 425 +MX51_PAD_UART2_TXD__UART2_TXD 426 +MX51_PAD_UART3_RXD__CSI1_D0 427 +MX51_PAD_UART3_RXD__GPIO1_22 428 +MX51_PAD_UART3_RXD__UART1_DTR 429 +MX51_PAD_UART3_RXD__UART3_RXD 430 +MX51_PAD_UART3_TXD__CSI1_D1 431 +MX51_PAD_UART3_TXD__GPIO1_23 432 +MX51_PAD_UART3_TXD__UART1_DSR 433 +MX51_PAD_UART3_TXD__UART3_TXD 434 +MX51_PAD_OWIRE_LINE__GPIO1_24 435 +MX51_PAD_OWIRE_LINE__OWIRE_LINE 436 +MX51_PAD_OWIRE_LINE__SPDIF_OUT 437 +MX51_PAD_KEY_ROW0__KEY_ROW0 438 +MX51_PAD_KEY_ROW1__KEY_ROW1 439 +MX51_PAD_KEY_ROW2__KEY_ROW2 440 +MX51_PAD_KEY_ROW3__KEY_ROW3 441 +MX51_PAD_KEY_COL0__KEY_COL0 442 +MX51_PAD_KEY_COL0__PLL1_BYP 443 +MX51_PAD_KEY_COL1__KEY_COL1 444 +MX51_PAD_KEY_COL1__PLL2_BYP 445 +MX51_PAD_KEY_COL2__KEY_COL2 446 +MX51_PAD_KEY_COL2__PLL3_BYP 447 +MX51_PAD_KEY_COL3__KEY_COL3 448 +MX51_PAD_KEY_COL4__I2C2_SCL 449 +MX51_PAD_KEY_COL4__KEY_COL4 450 +MX51_PAD_KEY_COL4__SPDIF_OUT1 451 +MX51_PAD_KEY_COL4__UART1_RI 452 +MX51_PAD_KEY_COL4__UART3_RTS 453 +MX51_PAD_KEY_COL5__I2C2_SDA 454 +MX51_PAD_KEY_COL5__KEY_COL5 455 +MX51_PAD_KEY_COL5__UART1_DCD 456 +MX51_PAD_KEY_COL5__UART3_CTS 457 +MX51_PAD_USBH1_CLK__CSPI_SCLK 458 +MX51_PAD_USBH1_CLK__GPIO1_25 459 +MX51_PAD_USBH1_CLK__I2C2_SCL 460 +MX51_PAD_USBH1_CLK__USBH1_CLK 461 +MX51_PAD_USBH1_DIR__CSPI_MOSI 462 +MX51_PAD_USBH1_DIR__GPIO1_26 463 +MX51_PAD_USBH1_DIR__I2C2_SDA 464 +MX51_PAD_USBH1_DIR__USBH1_DIR 465 +MX51_PAD_USBH1_STP__CSPI_RDY 466 +MX51_PAD_USBH1_STP__GPIO1_27 467 +MX51_PAD_USBH1_STP__UART3_RXD 468 +MX51_PAD_USBH1_STP__USBH1_STP 469 +MX51_PAD_USBH1_NXT__CSPI_MISO 470 +MX51_PAD_USBH1_NXT__GPIO1_28 471 +MX51_PAD_USBH1_NXT__UART3_TXD 472 +MX51_PAD_USBH1_NXT__USBH1_NXT 473 +MX51_PAD_USBH1_DATA0__GPIO1_11 474 +MX51_PAD_USBH1_DATA0__UART2_CTS 475 +MX51_PAD_USBH1_DATA0__USBH1_DATA0 476 +MX51_PAD_USBH1_DATA1__GPIO1_12 477 +MX51_PAD_USBH1_DATA1__UART2_RXD 478 +MX51_PAD_USBH1_DATA1__USBH1_DATA1 479 +MX51_PAD_USBH1_DATA2__GPIO1_13 480 +MX51_PAD_USBH1_DATA2__UART2_TXD 481 +MX51_PAD_USBH1_DATA2__USBH1_DATA2 482 +MX51_PAD_USBH1_DATA3__GPIO1_14 483 +MX51_PAD_USBH1_DATA3__UART2_RTS 484 +MX51_PAD_USBH1_DATA3__USBH1_DATA3 485 +MX51_PAD_USBH1_DATA4__CSPI_SS0 486 +MX51_PAD_USBH1_DATA4__GPIO1_15 487 +MX51_PAD_USBH1_DATA4__USBH1_DATA4 488 +MX51_PAD_USBH1_DATA5__CSPI_SS1 489 +MX51_PAD_USBH1_DATA5__GPIO1_16 490 +MX51_PAD_USBH1_DATA5__USBH1_DATA5 491 +MX51_PAD_USBH1_DATA6__CSPI_SS3 492 +MX51_PAD_USBH1_DATA6__GPIO1_17 493 +MX51_PAD_USBH1_DATA6__USBH1_DATA6 494 +MX51_PAD_USBH1_DATA7__ECSPI1_SS3 495 +MX51_PAD_USBH1_DATA7__ECSPI2_SS3 496 +MX51_PAD_USBH1_DATA7__GPIO1_18 497 +MX51_PAD_USBH1_DATA7__USBH1_DATA7 498 +MX51_PAD_DI1_PIN11__DI1_PIN11 499 +MX51_PAD_DI1_PIN11__ECSPI1_SS2 500 +MX51_PAD_DI1_PIN11__GPIO3_0 501 +MX51_PAD_DI1_PIN12__DI1_PIN12 502 +MX51_PAD_DI1_PIN12__GPIO3_1 503 +MX51_PAD_DI1_PIN13__DI1_PIN13 504 +MX51_PAD_DI1_PIN13__GPIO3_2 505 +MX51_PAD_DI1_D0_CS__DI1_D0_CS 506 +MX51_PAD_DI1_D0_CS__GPIO3_3 507 +MX51_PAD_DI1_D1_CS__DI1_D1_CS 508 +MX51_PAD_DI1_D1_CS__DISP1_PIN14 509 +MX51_PAD_DI1_D1_CS__DISP1_PIN5 510 +MX51_PAD_DI1_D1_CS__GPIO3_4 511 +MX51_PAD_DISPB2_SER_DIN__DISP1_PIN1 512 +MX51_PAD_DISPB2_SER_DIN__DISPB2_SER_DIN 513 +MX51_PAD_DISPB2_SER_DIN__GPIO3_5 514 +MX51_PAD_DISPB2_SER_DIO__DISP1_PIN6 515 +MX51_PAD_DISPB2_SER_DIO__DISPB2_SER_DIO 516 +MX51_PAD_DISPB2_SER_DIO__GPIO3_6 517 +MX51_PAD_DISPB2_SER_CLK__DISP1_PIN17 518 +MX51_PAD_DISPB2_SER_CLK__DISP1_PIN7 519 +MX51_PAD_DISPB2_SER_CLK__DISPB2_SER_CLK 520 +MX51_PAD_DISPB2_SER_CLK__GPIO3_7 521 +MX51_PAD_DISPB2_SER_RS__DISP1_EXT_CLK 522 +MX51_PAD_DISPB2_SER_RS__DISP1_PIN16 523 +MX51_PAD_DISPB2_SER_RS__DISP1_PIN8 524 +MX51_PAD_DISPB2_SER_RS__DISPB2_SER_RS 525 +MX51_PAD_DISPB2_SER_RS__DISPB2_SER_RS 526 +MX51_PAD_DISPB2_SER_RS__GPIO3_8 527 +MX51_PAD_DISP1_DAT0__DISP1_DAT0 528 +MX51_PAD_DISP1_DAT1__DISP1_DAT1 529 +MX51_PAD_DISP1_DAT2__DISP1_DAT2 530 +MX51_PAD_DISP1_DAT3__DISP1_DAT3 531 +MX51_PAD_DISP1_DAT4__DISP1_DAT4 532 +MX51_PAD_DISP1_DAT5__DISP1_DAT5 533 +MX51_PAD_DISP1_DAT6__BOOT_USB_SRC 534 +MX51_PAD_DISP1_DAT6__DISP1_DAT6 535 +MX51_PAD_DISP1_DAT7__BOOT_EEPROM_CFG 536 +MX51_PAD_DISP1_DAT7__DISP1_DAT7 537 +MX51_PAD_DISP1_DAT8__BOOT_SRC0 538 +MX51_PAD_DISP1_DAT8__DISP1_DAT8 539 +MX51_PAD_DISP1_DAT9__BOOT_SRC1 540 +MX51_PAD_DISP1_DAT9__DISP1_DAT9 541 +MX51_PAD_DISP1_DAT10__BOOT_SPARE_SIZE 542 +MX51_PAD_DISP1_DAT10__DISP1_DAT10 543 +MX51_PAD_DISP1_DAT11__BOOT_LPB_FREQ2 544 +MX51_PAD_DISP1_DAT11__DISP1_DAT11 545 +MX51_PAD_DISP1_DAT12__BOOT_MLC_SEL 546 +MX51_PAD_DISP1_DAT12__DISP1_DAT12 547 +MX51_PAD_DISP1_DAT13__BOOT_MEM_CTL0 548 +MX51_PAD_DISP1_DAT13__DISP1_DAT13 549 +MX51_PAD_DISP1_DAT14__BOOT_MEM_CTL1 550 +MX51_PAD_DISP1_DAT14__DISP1_DAT14 551 +MX51_PAD_DISP1_DAT15__BOOT_BUS_WIDTH 552 +MX51_PAD_DISP1_DAT15__DISP1_DAT15 553 +MX51_PAD_DISP1_DAT16__BOOT_PAGE_SIZE0 554 +MX51_PAD_DISP1_DAT16__DISP1_DAT16 555 +MX51_PAD_DISP1_DAT17__BOOT_PAGE_SIZE1 556 +MX51_PAD_DISP1_DAT17__DISP1_DAT17 557 +MX51_PAD_DISP1_DAT18__BOOT_WEIM_MUXED0 558 +MX51_PAD_DISP1_DAT18__DISP1_DAT18 559 +MX51_PAD_DISP1_DAT18__DISP2_PIN11 560 +MX51_PAD_DISP1_DAT18__DISP2_PIN5 561 +MX51_PAD_DISP1_DAT19__BOOT_WEIM_MUXED1 562 +MX51_PAD_DISP1_DAT19__DISP1_DAT19 563 +MX51_PAD_DISP1_DAT19__DISP2_PIN12 564 +MX51_PAD_DISP1_DAT19__DISP2_PIN6 565 +MX51_PAD_DISP1_DAT20__BOOT_MEM_TYPE0 566 +MX51_PAD_DISP1_DAT20__DISP1_DAT20 567 +MX51_PAD_DISP1_DAT20__DISP2_PIN13 568 +MX51_PAD_DISP1_DAT20__DISP2_PIN7 569 +MX51_PAD_DISP1_DAT21__BOOT_MEM_TYPE1 570 +MX51_PAD_DISP1_DAT21__DISP1_DAT21 571 +MX51_PAD_DISP1_DAT21__DISP2_PIN14 572 +MX51_PAD_DISP1_DAT21__DISP2_PIN8 573 +MX51_PAD_DISP1_DAT22__BOOT_LPB_FREQ0 574 +MX51_PAD_DISP1_DAT22__DISP1_DAT22 575 +MX51_PAD_DISP1_DAT22__DISP2_D0_CS 576 +MX51_PAD_DISP1_DAT22__DISP2_DAT16 577 +MX51_PAD_DISP1_DAT23__BOOT_LPB_FREQ1 578 +MX51_PAD_DISP1_DAT23__DISP1_DAT23 579 +MX51_PAD_DISP1_DAT23__DISP2_D1_CS 580 +MX51_PAD_DISP1_DAT23__DISP2_DAT17 581 +MX51_PAD_DISP1_DAT23__DISP2_SER_CS 582 +MX51_PAD_DI1_PIN3__DI1_PIN3 583 +MX51_PAD_DI1_PIN2__DI1_PIN2 584 +MX51_PAD_DI_GP2__DISP1_SER_CLK 585 +MX51_PAD_DI_GP2__DISP2_WAIT 586 +MX51_PAD_DI_GP3__CSI1_DATA_EN 587 +MX51_PAD_DI_GP3__DISP1_SER_DIO 588 +MX51_PAD_DI_GP3__FEC_TX_ER 589 +MX51_PAD_DI2_PIN4__CSI2_DATA_EN 590 +MX51_PAD_DI2_PIN4__DI2_PIN4 591 +MX51_PAD_DI2_PIN4__FEC_CRS 592 +MX51_PAD_DI2_PIN2__DI2_PIN2 593 +MX51_PAD_DI2_PIN2__FEC_MDC 594 +MX51_PAD_DI2_PIN3__DI2_PIN3 595 +MX51_PAD_DI2_PIN3__FEC_MDIO 596 +MX51_PAD_DI2_DISP_CLK__DI2_DISP_CLK 597 +MX51_PAD_DI2_DISP_CLK__FEC_RDATA1 598 +MX51_PAD_DI_GP4__DI2_PIN15 599 +MX51_PAD_DI_GP4__DISP1_SER_DIN 600 +MX51_PAD_DI_GP4__DISP2_PIN1 601 +MX51_PAD_DI_GP4__FEC_RDATA2 602 +MX51_PAD_DISP2_DAT0__DISP2_DAT0 603 +MX51_PAD_DISP2_DAT0__FEC_RDATA3 604 +MX51_PAD_DISP2_DAT0__KEY_COL6 605 +MX51_PAD_DISP2_DAT0__UART3_RXD 606 +MX51_PAD_DISP2_DAT0__USBH3_CLK 607 +MX51_PAD_DISP2_DAT1__DISP2_DAT1 608 +MX51_PAD_DISP2_DAT1__FEC_RX_ER 609 +MX51_PAD_DISP2_DAT1__KEY_COL7 610 +MX51_PAD_DISP2_DAT1__UART3_TXD 611 +MX51_PAD_DISP2_DAT1__USBH3_DIR 612 +MX51_PAD_DISP2_DAT2__DISP2_DAT2 613 +MX51_PAD_DISP2_DAT3__DISP2_DAT3 614 +MX51_PAD_DISP2_DAT4__DISP2_DAT4 615 +MX51_PAD_DISP2_DAT5__DISP2_DAT5 616 +MX51_PAD_DISP2_DAT6__DISP2_DAT6 617 +MX51_PAD_DISP2_DAT6__FEC_TDATA1 618 +MX51_PAD_DISP2_DAT6__GPIO1_19 619 +MX51_PAD_DISP2_DAT6__KEY_ROW4 620 +MX51_PAD_DISP2_DAT6__USBH3_STP 621 +MX51_PAD_DISP2_DAT7__DISP2_DAT7 622 +MX51_PAD_DISP2_DAT7__FEC_TDATA2 623 +MX51_PAD_DISP2_DAT7__GPIO1_29 624 +MX51_PAD_DISP2_DAT7__KEY_ROW5 625 +MX51_PAD_DISP2_DAT7__USBH3_NXT 626 +MX51_PAD_DISP2_DAT8__DISP2_DAT8 627 +MX51_PAD_DISP2_DAT8__FEC_TDATA3 628 +MX51_PAD_DISP2_DAT8__GPIO1_30 629 +MX51_PAD_DISP2_DAT8__KEY_ROW6 630 +MX51_PAD_DISP2_DAT8__USBH3_DATA0 631 +MX51_PAD_DISP2_DAT9__AUD6_RXC 632 +MX51_PAD_DISP2_DAT9__DISP2_DAT9 633 +MX51_PAD_DISP2_DAT9__FEC_TX_EN 634 +MX51_PAD_DISP2_DAT9__GPIO1_31 635 +MX51_PAD_DISP2_DAT9__USBH3_DATA1 636 +MX51_PAD_DISP2_DAT10__DISP2_DAT10 637 +MX51_PAD_DISP2_DAT10__DISP2_SER_CS 638 +MX51_PAD_DISP2_DAT10__FEC_COL 639 +MX51_PAD_DISP2_DAT10__KEY_ROW7 640 +MX51_PAD_DISP2_DAT10__USBH3_DATA2 641 +MX51_PAD_DISP2_DAT11__AUD6_TXD 642 +MX51_PAD_DISP2_DAT11__DISP2_DAT11 643 +MX51_PAD_DISP2_DAT11__FEC_RX_CLK 644 +MX51_PAD_DISP2_DAT11__GPIO1_10 645 +MX51_PAD_DISP2_DAT11__USBH3_DATA3 646 +MX51_PAD_DISP2_DAT12__AUD6_RXD 647 +MX51_PAD_DISP2_DAT12__DISP2_DAT12 648 +MX51_PAD_DISP2_DAT12__FEC_RX_DV 649 +MX51_PAD_DISP2_DAT12__USBH3_DATA4 650 +MX51_PAD_DISP2_DAT13__AUD6_TXC 651 +MX51_PAD_DISP2_DAT13__DISP2_DAT13 652 +MX51_PAD_DISP2_DAT13__FEC_TX_CLK 653 +MX51_PAD_DISP2_DAT13__USBH3_DATA5 654 +MX51_PAD_DISP2_DAT14__AUD6_TXFS 655 +MX51_PAD_DISP2_DAT14__DISP2_DAT14 656 +MX51_PAD_DISP2_DAT14__FEC_RDATA0 657 +MX51_PAD_DISP2_DAT14__USBH3_DATA6 658 +MX51_PAD_DISP2_DAT15__AUD6_RXFS 659 +MX51_PAD_DISP2_DAT15__DISP1_SER_CS 660 +MX51_PAD_DISP2_DAT15__DISP2_DAT15 661 +MX51_PAD_DISP2_DAT15__FEC_TDATA0 662 +MX51_PAD_DISP2_DAT15__USBH3_DATA7 663 +MX51_PAD_SD1_CMD__AUD5_RXFS 664 +MX51_PAD_SD1_CMD__CSPI_MOSI 665 +MX51_PAD_SD1_CMD__SD1_CMD 666 +MX51_PAD_SD1_CLK__AUD5_RXC 667 +MX51_PAD_SD1_CLK__CSPI_SCLK 668 +MX51_PAD_SD1_CLK__SD1_CLK 669 +MX51_PAD_SD1_DATA0__AUD5_TXD 670 +MX51_PAD_SD1_DATA0__CSPI_MISO 671 +MX51_PAD_SD1_DATA0__SD1_DATA0 672 +MX51_PAD_EIM_DA0__EIM_DA0 673 +MX51_PAD_EIM_DA1__EIM_DA1 674 +MX51_PAD_EIM_DA2__EIM_DA2 675 +MX51_PAD_EIM_DA3__EIM_DA3 676 +MX51_PAD_SD1_DATA1__AUD5_RXD 677 +MX51_PAD_SD1_DATA1__SD1_DATA1 678 +MX51_PAD_EIM_DA4__EIM_DA4 679 +MX51_PAD_EIM_DA5__EIM_DA5 680 +MX51_PAD_EIM_DA6__EIM_DA6 681 +MX51_PAD_EIM_DA7__EIM_DA7 682 +MX51_PAD_SD1_DATA2__AUD5_TXC 683 +MX51_PAD_SD1_DATA2__SD1_DATA2 684 +MX51_PAD_EIM_DA10__EIM_DA10 685 +MX51_PAD_EIM_DA11__EIM_DA11 686 +MX51_PAD_EIM_DA8__EIM_DA8 687 +MX51_PAD_EIM_DA9__EIM_DA9 688 +MX51_PAD_SD1_DATA3__AUD5_TXFS 689 +MX51_PAD_SD1_DATA3__CSPI_SS1 690 +MX51_PAD_SD1_DATA3__SD1_DATA3 691 +MX51_PAD_GPIO1_0__CSPI_SS2 692 +MX51_PAD_GPIO1_0__GPIO1_0 693 +MX51_PAD_GPIO1_0__SD1_CD 694 +MX51_PAD_GPIO1_1__CSPI_MISO 695 +MX51_PAD_GPIO1_1__GPIO1_1 696 +MX51_PAD_GPIO1_1__SD1_WP 697 +MX51_PAD_EIM_DA12__EIM_DA12 698 +MX51_PAD_EIM_DA13__EIM_DA13 699 +MX51_PAD_EIM_DA14__EIM_DA14 700 +MX51_PAD_EIM_DA15__EIM_DA15 701 +MX51_PAD_SD2_CMD__CSPI_MOSI 702 +MX51_PAD_SD2_CMD__I2C1_SCL 703 +MX51_PAD_SD2_CMD__SD2_CMD 704 +MX51_PAD_SD2_CLK__CSPI_SCLK 705 +MX51_PAD_SD2_CLK__I2C1_SDA 706 +MX51_PAD_SD2_CLK__SD2_CLK 707 +MX51_PAD_SD2_DATA0__CSPI_MISO 708 +MX51_PAD_SD2_DATA0__SD1_DAT4 709 +MX51_PAD_SD2_DATA0__SD2_DATA0 710 +MX51_PAD_SD2_DATA1__SD1_DAT5 711 +MX51_PAD_SD2_DATA1__SD2_DATA1 712 +MX51_PAD_SD2_DATA1__USBH3_H2_DP 713 +MX51_PAD_SD2_DATA2__SD1_DAT6 714 +MX51_PAD_SD2_DATA2__SD2_DATA2 715 +MX51_PAD_SD2_DATA2__USBH3_H2_DM 716 +MX51_PAD_SD2_DATA3__CSPI_SS2 717 +MX51_PAD_SD2_DATA3__SD1_DAT7 718 +MX51_PAD_SD2_DATA3__SD2_DATA3 719 +MX51_PAD_GPIO1_2__CCM_OUT_2 720 +MX51_PAD_GPIO1_2__GPIO1_2 721 +MX51_PAD_GPIO1_2__I2C2_SCL 722 +MX51_PAD_GPIO1_2__PLL1_BYP 723 +MX51_PAD_GPIO1_2__PWM1_PWMO 724 +MX51_PAD_GPIO1_3__GPIO1_3 725 +MX51_PAD_GPIO1_3__I2C2_SDA 726 +MX51_PAD_GPIO1_3__PLL2_BYP 727 +MX51_PAD_GPIO1_3__PWM2_PWMO 728 +MX51_PAD_PMIC_INT_REQ__PMIC_INT_REQ 729 +MX51_PAD_PMIC_INT_REQ__PMIC_PMU_IRQ_B 730 +MX51_PAD_GPIO1_4__DISP2_EXT_CLK 731 +MX51_PAD_GPIO1_4__EIM_RDY 732 +MX51_PAD_GPIO1_4__GPIO1_4 733 +MX51_PAD_GPIO1_4__WDOG1_WDOG_B 734 +MX51_PAD_GPIO1_5__CSI2_MCLK 735 +MX51_PAD_GPIO1_5__DISP2_PIN16 736 +MX51_PAD_GPIO1_5__GPIO1_5 737 +MX51_PAD_GPIO1_5__WDOG2_WDOG_B 738 +MX51_PAD_GPIO1_6__DISP2_PIN17 739 +MX51_PAD_GPIO1_6__GPIO1_6 740 +MX51_PAD_GPIO1_6__REF_EN_B 741 +MX51_PAD_GPIO1_7__CCM_OUT_0 742 +MX51_PAD_GPIO1_7__GPIO1_7 743 +MX51_PAD_GPIO1_7__SD2_WP 744 +MX51_PAD_GPIO1_7__SPDIF_OUT1 745 +MX51_PAD_GPIO1_8__CSI2_DATA_EN 746 +MX51_PAD_GPIO1_8__GPIO1_8 747 +MX51_PAD_GPIO1_8__SD2_CD 748 +MX51_PAD_GPIO1_8__USBH3_PWR 749 +MX51_PAD_GPIO1_9__CCM_OUT_1 750 +MX51_PAD_GPIO1_9__DISP2_D1_CS 751 +MX51_PAD_GPIO1_9__DISP2_SER_CS 752 +MX51_PAD_GPIO1_9__GPIO1_9 753 +MX51_PAD_GPIO1_9__SD2_LCTL 754 +MX51_PAD_GPIO1_9__USBH3_OC 755 diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt new file mode 100644 index 0000000..ca85ca4 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx53-pinctrl.txt @@ -0,0 +1,1202 @@ +* Freescale IMX53 IOMUX Controller + +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part +and usage. + +Required properties: +- compatible: "fsl,imx53-iomuxc" +- fsl,pins: two integers array, represents a group of pins mux and config + setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a + pin working on a specific function, CONFIG is the pad setting value like + pull-up for this pin. Please refer to imx53 datasheet for the valid pad + config settings. + +CONFIG bits definition: +PAD_CTL_HVE (1 << 13) +PAD_CTL_HYS (1 << 8) +PAD_CTL_PKE (1 << 7) +PAD_CTL_PUE (1 << 6) +PAD_CTL_PUS_100K_DOWN (0 << 4) +PAD_CTL_PUS_47K_UP (1 << 4) +PAD_CTL_PUS_100K_UP (2 << 4) +PAD_CTL_PUS_22K_UP (3 << 4) +PAD_CTL_ODE (1 << 3) +PAD_CTL_DSE_LOW (0 << 1) +PAD_CTL_DSE_MED (1 << 1) +PAD_CTL_DSE_HIGH (2 << 1) +PAD_CTL_DSE_MAX (3 << 1) +PAD_CTL_SRE_FAST (1 << 0) +PAD_CTL_SRE_SLOW (0 << 0) + +See below for available PIN_FUNC_ID for imx53: +MX53_PAD_GPIO_19__KPP_COL_5 0 +MX53_PAD_GPIO_19__GPIO4_5 1 +MX53_PAD_GPIO_19__CCM_CLKO 2 +MX53_PAD_GPIO_19__SPDIF_OUT1 3 +MX53_PAD_GPIO_19__RTC_CE_RTC_EXT_TRIG2 4 +MX53_PAD_GPIO_19__ECSPI1_RDY 5 +MX53_PAD_GPIO_19__FEC_TDATA_3 6 +MX53_PAD_GPIO_19__SRC_INT_BOOT 7 +MX53_PAD_KEY_COL0__KPP_COL_0 8 +MX53_PAD_KEY_COL0__GPIO4_6 9 +MX53_PAD_KEY_COL0__AUDMUX_AUD5_TXC 10 +MX53_PAD_KEY_COL0__UART4_TXD_MUX 11 +MX53_PAD_KEY_COL0__ECSPI1_SCLK 12 +MX53_PAD_KEY_COL0__FEC_RDATA_3 13 +MX53_PAD_KEY_COL0__SRC_ANY_PU_RST 14 +MX53_PAD_KEY_ROW0__KPP_ROW_0 15 +MX53_PAD_KEY_ROW0__GPIO4_7 16 +MX53_PAD_KEY_ROW0__AUDMUX_AUD5_TXD 17 +MX53_PAD_KEY_ROW0__UART4_RXD_MUX 18 +MX53_PAD_KEY_ROW0__ECSPI1_MOSI 19 +MX53_PAD_KEY_ROW0__FEC_TX_ER 20 +MX53_PAD_KEY_COL1__KPP_COL_1 21 +MX53_PAD_KEY_COL1__GPIO4_8 22 +MX53_PAD_KEY_COL1__AUDMUX_AUD5_TXFS 23 +MX53_PAD_KEY_COL1__UART5_TXD_MUX 24 +MX53_PAD_KEY_COL1__ECSPI1_MISO 25 +MX53_PAD_KEY_COL1__FEC_RX_CLK 26 +MX53_PAD_KEY_COL1__USBPHY1_TXREADY 27 +MX53_PAD_KEY_ROW1__KPP_ROW_1 28 +MX53_PAD_KEY_ROW1__GPIO4_9 29 +MX53_PAD_KEY_ROW1__AUDMUX_AUD5_RXD 30 +MX53_PAD_KEY_ROW1__UART5_RXD_MUX 31 +MX53_PAD_KEY_ROW1__ECSPI1_SS0 32 +MX53_PAD_KEY_ROW1__FEC_COL 33 +MX53_PAD_KEY_ROW1__USBPHY1_RXVALID 34 +MX53_PAD_KEY_COL2__KPP_COL_2 35 +MX53_PAD_KEY_COL2__GPIO4_10 36 +MX53_PAD_KEY_COL2__CAN1_TXCAN 37 +MX53_PAD_KEY_COL2__FEC_MDIO 38 +MX53_PAD_KEY_COL2__ECSPI1_SS1 39 +MX53_PAD_KEY_COL2__FEC_RDATA_2 40 +MX53_PAD_KEY_COL2__USBPHY1_RXACTIVE 41 +MX53_PAD_KEY_ROW2__KPP_ROW_2 42 +MX53_PAD_KEY_ROW2__GPIO4_11 43 +MX53_PAD_KEY_ROW2__CAN1_RXCAN 44 +MX53_PAD_KEY_ROW2__FEC_MDC 45 +MX53_PAD_KEY_ROW2__ECSPI1_SS2 46 +MX53_PAD_KEY_ROW2__FEC_TDATA_2 47 +MX53_PAD_KEY_ROW2__USBPHY1_RXERROR 48 +MX53_PAD_KEY_COL3__KPP_COL_3 49 +MX53_PAD_KEY_COL3__GPIO4_12 50 +MX53_PAD_KEY_COL3__USBOH3_H2_DP 51 +MX53_PAD_KEY_COL3__SPDIF_IN1 52 +MX53_PAD_KEY_COL3__I2C2_SCL 53 +MX53_PAD_KEY_COL3__ECSPI1_SS3 54 +MX53_PAD_KEY_COL3__FEC_CRS 55 +MX53_PAD_KEY_COL3__USBPHY1_SIECLOCK 56 +MX53_PAD_KEY_ROW3__KPP_ROW_3 57 +MX53_PAD_KEY_ROW3__GPIO4_13 58 +MX53_PAD_KEY_ROW3__USBOH3_H2_DM 59 +MX53_PAD_KEY_ROW3__CCM_ASRC_EXT_CLK 60 +MX53_PAD_KEY_ROW3__I2C2_SDA 61 +MX53_PAD_KEY_ROW3__OSC32K_32K_OUT 62 +MX53_PAD_KEY_ROW3__CCM_PLL4_BYP 63 +MX53_PAD_KEY_ROW3__USBPHY1_LINESTATE_0 64 +MX53_PAD_KEY_COL4__KPP_COL_4 65 +MX53_PAD_KEY_COL4__GPIO4_14 66 +MX53_PAD_KEY_COL4__CAN2_TXCAN 67 +MX53_PAD_KEY_COL4__IPU_SISG_4 68 +MX53_PAD_KEY_COL4__UART5_RTS 69 +MX53_PAD_KEY_COL4__USBOH3_USBOTG_OC 70 +MX53_PAD_KEY_COL4__USBPHY1_LINESTATE_1 71 +MX53_PAD_KEY_ROW4__KPP_ROW_4 72 +MX53_PAD_KEY_ROW4__GPIO4_15 73 +MX53_PAD_KEY_ROW4__CAN2_RXCAN 74 +MX53_PAD_KEY_ROW4__IPU_SISG_5 75 +MX53_PAD_KEY_ROW4__UART5_CTS 76 +MX53_PAD_KEY_ROW4__USBOH3_USBOTG_PWR 77 +MX53_PAD_KEY_ROW4__USBPHY1_VBUSVALID 78 +MX53_PAD_DI0_DISP_CLK__IPU_DI0_DISP_CLK 79 +MX53_PAD_DI0_DISP_CLK__GPIO4_16 80 +MX53_PAD_DI0_DISP_CLK__USBOH3_USBH2_DIR 81 +MX53_PAD_DI0_DISP_CLK__SDMA_DEBUG_CORE_STATE_0 82 +MX53_PAD_DI0_DISP_CLK__EMI_EMI_DEBUG_0 83 +MX53_PAD_DI0_DISP_CLK__USBPHY1_AVALID 84 +MX53_PAD_DI0_PIN15__IPU_DI0_PIN15 85 +MX53_PAD_DI0_PIN15__GPIO4_17 86 +MX53_PAD_DI0_PIN15__AUDMUX_AUD6_TXC 87 +MX53_PAD_DI0_PIN15__SDMA_DEBUG_CORE_STATE_1 88 +MX53_PAD_DI0_PIN15__EMI_EMI_DEBUG_1 89 +MX53_PAD_DI0_PIN15__USBPHY1_BVALID 90 +MX53_PAD_DI0_PIN2__IPU_DI0_PIN2 91 +MX53_PAD_DI0_PIN2__GPIO4_18 92 +MX53_PAD_DI0_PIN2__AUDMUX_AUD6_TXD 93 +MX53_PAD_DI0_PIN2__SDMA_DEBUG_CORE_STATE_2 94 +MX53_PAD_DI0_PIN2__EMI_EMI_DEBUG_2 95 +MX53_PAD_DI0_PIN2__USBPHY1_ENDSESSION 96 +MX53_PAD_DI0_PIN3__IPU_DI0_PIN3 97 +MX53_PAD_DI0_PIN3__GPIO4_19 98 +MX53_PAD_DI0_PIN3__AUDMUX_AUD6_TXFS 99 +MX53_PAD_DI0_PIN3__SDMA_DEBUG_CORE_STATE_3 100 +MX53_PAD_DI0_PIN3__EMI_EMI_DEBUG_3 101 +MX53_PAD_DI0_PIN3__USBPHY1_IDDIG 102 +MX53_PAD_DI0_PIN4__IPU_DI0_PIN4 103 +MX53_PAD_DI0_PIN4__GPIO4_20 104 +MX53_PAD_DI0_PIN4__AUDMUX_AUD6_RXD 105 +MX53_PAD_DI0_PIN4__ESDHC1_WP 106 +MX53_PAD_DI0_PIN4__SDMA_DEBUG_YIELD 107 +MX53_PAD_DI0_PIN4__EMI_EMI_DEBUG_4 108 +MX53_PAD_DI0_PIN4__USBPHY1_HOSTDISCONNECT 109 +MX53_PAD_DISP0_DAT0__IPU_DISP0_DAT_0 110 +MX53_PAD_DISP0_DAT0__GPIO4_21 111 +MX53_PAD_DISP0_DAT0__CSPI_SCLK 112 +MX53_PAD_DISP0_DAT0__USBOH3_USBH2_DATA_0 113 +MX53_PAD_DISP0_DAT0__SDMA_DEBUG_CORE_RUN 114 +MX53_PAD_DISP0_DAT0__EMI_EMI_DEBUG_5 115 +MX53_PAD_DISP0_DAT0__USBPHY2_TXREADY 116 +MX53_PAD_DISP0_DAT1__IPU_DISP0_DAT_1 117 +MX53_PAD_DISP0_DAT1__GPIO4_22 118 +MX53_PAD_DISP0_DAT1__CSPI_MOSI 119 +MX53_PAD_DISP0_DAT1__USBOH3_USBH2_DATA_1 120 +MX53_PAD_DISP0_DAT1__SDMA_DEBUG_EVENT_CHANNEL_SEL 121 +MX53_PAD_DISP0_DAT1__EMI_EMI_DEBUG_6 122 +MX53_PAD_DISP0_DAT1__USBPHY2_RXVALID 123 +MX53_PAD_DISP0_DAT2__IPU_DISP0_DAT_2 124 +MX53_PAD_DISP0_DAT2__GPIO4_23 125 +MX53_PAD_DISP0_DAT2__CSPI_MISO 126 +MX53_PAD_DISP0_DAT2__USBOH3_USBH2_DATA_2 127 +MX53_PAD_DISP0_DAT2__SDMA_DEBUG_MODE 128 +MX53_PAD_DISP0_DAT2__EMI_EMI_DEBUG_7 129 +MX53_PAD_DISP0_DAT2__USBPHY2_RXACTIVE 130 +MX53_PAD_DISP0_DAT3__IPU_DISP0_DAT_3 131 +MX53_PAD_DISP0_DAT3__GPIO4_24 132 +MX53_PAD_DISP0_DAT3__CSPI_SS0 133 +MX53_PAD_DISP0_DAT3__USBOH3_USBH2_DATA_3 134 +MX53_PAD_DISP0_DAT3__SDMA_DEBUG_BUS_ERROR 135 +MX53_PAD_DISP0_DAT3__EMI_EMI_DEBUG_8 136 +MX53_PAD_DISP0_DAT3__USBPHY2_RXERROR 137 +MX53_PAD_DISP0_DAT4__IPU_DISP0_DAT_4 138 +MX53_PAD_DISP0_DAT4__GPIO4_25 139 +MX53_PAD_DISP0_DAT4__CSPI_SS1 140 +MX53_PAD_DISP0_DAT4__USBOH3_USBH2_DATA_4 141 +MX53_PAD_DISP0_DAT4__SDMA_DEBUG_BUS_RWB 142 +MX53_PAD_DISP0_DAT4__EMI_EMI_DEBUG_9 143 +MX53_PAD_DISP0_DAT4__USBPHY2_SIECLOCK 144 +MX53_PAD_DISP0_DAT5__IPU_DISP0_DAT_5 145 +MX53_PAD_DISP0_DAT5__GPIO4_26 146 +MX53_PAD_DISP0_DAT5__CSPI_SS2 147 +MX53_PAD_DISP0_DAT5__USBOH3_USBH2_DATA_5 148 +MX53_PAD_DISP0_DAT5__SDMA_DEBUG_MATCHED_DMBUS 149 +MX53_PAD_DISP0_DAT5__EMI_EMI_DEBUG_10 150 +MX53_PAD_DISP0_DAT5__USBPHY2_LINESTATE_0 151 +MX53_PAD_DISP0_DAT6__IPU_DISP0_DAT_6 152 +MX53_PAD_DISP0_DAT6__GPIO4_27 153 +MX53_PAD_DISP0_DAT6__CSPI_SS3 154 +MX53_PAD_DISP0_DAT6__USBOH3_USBH2_DATA_6 155 +MX53_PAD_DISP0_DAT6__SDMA_DEBUG_RTBUFFER_WRITE 156 +MX53_PAD_DISP0_DAT6__EMI_EMI_DEBUG_11 157 +MX53_PAD_DISP0_DAT6__USBPHY2_LINESTATE_1 158 +MX53_PAD_DISP0_DAT7__IPU_DISP0_DAT_7 159 +MX53_PAD_DISP0_DAT7__GPIO4_28 160 +MX53_PAD_DISP0_DAT7__CSPI_RDY 161 +MX53_PAD_DISP0_DAT7__USBOH3_USBH2_DATA_7 162 +MX53_PAD_DISP0_DAT7__SDMA_DEBUG_EVENT_CHANNEL_0 163 +MX53_PAD_DISP0_DAT7__EMI_EMI_DEBUG_12 164 +MX53_PAD_DISP0_DAT7__USBPHY2_VBUSVALID 165 +MX53_PAD_DISP0_DAT8__IPU_DISP0_DAT_8 166 +MX53_PAD_DISP0_DAT8__GPIO4_29 167 +MX53_PAD_DISP0_DAT8__PWM1_PWMO 168 +MX53_PAD_DISP0_DAT8__WDOG1_WDOG_B 169 +MX53_PAD_DISP0_DAT8__SDMA_DEBUG_EVENT_CHANNEL_1 170 +MX53_PAD_DISP0_DAT8__EMI_EMI_DEBUG_13 171 +MX53_PAD_DISP0_DAT8__USBPHY2_AVALID 172 +MX53_PAD_DISP0_DAT9__IPU_DISP0_DAT_9 173 +MX53_PAD_DISP0_DAT9__GPIO4_30 174 +MX53_PAD_DISP0_DAT9__PWM2_PWMO 175 +MX53_PAD_DISP0_DAT9__WDOG2_WDOG_B 176 +MX53_PAD_DISP0_DAT9__SDMA_DEBUG_EVENT_CHANNEL_2 177 +MX53_PAD_DISP0_DAT9__EMI_EMI_DEBUG_14 178 +MX53_PAD_DISP0_DAT9__USBPHY2_VSTATUS_0 179 +MX53_PAD_DISP0_DAT10__IPU_DISP0_DAT_10 180 +MX53_PAD_DISP0_DAT10__GPIO4_31 181 +MX53_PAD_DISP0_DAT10__USBOH3_USBH2_STP 182 +MX53_PAD_DISP0_DAT10__SDMA_DEBUG_EVENT_CHANNEL_3 183 +MX53_PAD_DISP0_DAT10__EMI_EMI_DEBUG_15 184 +MX53_PAD_DISP0_DAT10__USBPHY2_VSTATUS_1 185 +MX53_PAD_DISP0_DAT11__IPU_DISP0_DAT_11 186 +MX53_PAD_DISP0_DAT11__GPIO5_5 187 +MX53_PAD_DISP0_DAT11__USBOH3_USBH2_NXT 188 +MX53_PAD_DISP0_DAT11__SDMA_DEBUG_EVENT_CHANNEL_4 189 +MX53_PAD_DISP0_DAT11__EMI_EMI_DEBUG_16 190 +MX53_PAD_DISP0_DAT11__USBPHY2_VSTATUS_2 191 +MX53_PAD_DISP0_DAT12__IPU_DISP0_DAT_12 192 +MX53_PAD_DISP0_DAT12__GPIO5_6 193 +MX53_PAD_DISP0_DAT12__USBOH3_USBH2_CLK 194 +MX53_PAD_DISP0_DAT12__SDMA_DEBUG_EVENT_CHANNEL_5 195 +MX53_PAD_DISP0_DAT12__EMI_EMI_DEBUG_17 196 +MX53_PAD_DISP0_DAT12__USBPHY2_VSTATUS_3 197 +MX53_PAD_DISP0_DAT13__IPU_DISP0_DAT_13 198 +MX53_PAD_DISP0_DAT13__GPIO5_7 199 +MX53_PAD_DISP0_DAT13__AUDMUX_AUD5_RXFS 200 +MX53_PAD_DISP0_DAT13__SDMA_DEBUG_EVT_CHN_LINES_0 201 +MX53_PAD_DISP0_DAT13__EMI_EMI_DEBUG_18 202 +MX53_PAD_DISP0_DAT13__USBPHY2_VSTATUS_4 203 +MX53_PAD_DISP0_DAT14__IPU_DISP0_DAT_14 204 +MX53_PAD_DISP0_DAT14__GPIO5_8 205 +MX53_PAD_DISP0_DAT14__AUDMUX_AUD5_RXC 206 +MX53_PAD_DISP0_DAT14__SDMA_DEBUG_EVT_CHN_LINES_1 207 +MX53_PAD_DISP0_DAT14__EMI_EMI_DEBUG_19 208 +MX53_PAD_DISP0_DAT14__USBPHY2_VSTATUS_5 209 +MX53_PAD_DISP0_DAT15__IPU_DISP0_DAT_15 210 +MX53_PAD_DISP0_DAT15__GPIO5_9 211 +MX53_PAD_DISP0_DAT15__ECSPI1_SS1 212 +MX53_PAD_DISP0_DAT15__ECSPI2_SS1 213 +MX53_PAD_DISP0_DAT15__SDMA_DEBUG_EVT_CHN_LINES_2 214 +MX53_PAD_DISP0_DAT15__EMI_EMI_DEBUG_20 215 +MX53_PAD_DISP0_DAT15__USBPHY2_VSTATUS_6 216 +MX53_PAD_DISP0_DAT16__IPU_DISP0_DAT_16 217 +MX53_PAD_DISP0_DAT16__GPIO5_10 218 +MX53_PAD_DISP0_DAT16__ECSPI2_MOSI 219 +MX53_PAD_DISP0_DAT16__AUDMUX_AUD5_TXC 220 +MX53_PAD_DISP0_DAT16__SDMA_EXT_EVENT_0 221 +MX53_PAD_DISP0_DAT16__SDMA_DEBUG_EVT_CHN_LINES_3 222 +MX53_PAD_DISP0_DAT16__EMI_EMI_DEBUG_21 223 +MX53_PAD_DISP0_DAT16__USBPHY2_VSTATUS_7 224 +MX53_PAD_DISP0_DAT17__IPU_DISP0_DAT_17 225 +MX53_PAD_DISP0_DAT17__GPIO5_11 226 +MX53_PAD_DISP0_DAT17__ECSPI2_MISO 227 +MX53_PAD_DISP0_DAT17__AUDMUX_AUD5_TXD 228 +MX53_PAD_DISP0_DAT17__SDMA_EXT_EVENT_1 229 +MX53_PAD_DISP0_DAT17__SDMA_DEBUG_EVT_CHN_LINES_4 230 +MX53_PAD_DISP0_DAT17__EMI_EMI_DEBUG_22 231 +MX53_PAD_DISP0_DAT18__IPU_DISP0_DAT_18 232 +MX53_PAD_DISP0_DAT18__GPIO5_12 233 +MX53_PAD_DISP0_DAT18__ECSPI2_SS0 234 +MX53_PAD_DISP0_DAT18__AUDMUX_AUD5_TXFS 235 +MX53_PAD_DISP0_DAT18__AUDMUX_AUD4_RXFS 236 +MX53_PAD_DISP0_DAT18__SDMA_DEBUG_EVT_CHN_LINES_5 237 +MX53_PAD_DISP0_DAT18__EMI_EMI_DEBUG_23 238 +MX53_PAD_DISP0_DAT18__EMI_WEIM_CS_2 239 +MX53_PAD_DISP0_DAT19__IPU_DISP0_DAT_19 240 +MX53_PAD_DISP0_DAT19__GPIO5_13 241 +MX53_PAD_DISP0_DAT19__ECSPI2_SCLK 242 +MX53_PAD_DISP0_DAT19__AUDMUX_AUD5_RXD 243 +MX53_PAD_DISP0_DAT19__AUDMUX_AUD4_RXC 244 +MX53_PAD_DISP0_DAT19__SDMA_DEBUG_EVT_CHN_LINES_6 245 +MX53_PAD_DISP0_DAT19__EMI_EMI_DEBUG_24 246 +MX53_PAD_DISP0_DAT19__EMI_WEIM_CS_3 247 +MX53_PAD_DISP0_DAT20__IPU_DISP0_DAT_20 248 +MX53_PAD_DISP0_DAT20__GPIO5_14 249 +MX53_PAD_DISP0_DAT20__ECSPI1_SCLK 250 +MX53_PAD_DISP0_DAT20__AUDMUX_AUD4_TXC 251 +MX53_PAD_DISP0_DAT20__SDMA_DEBUG_EVT_CHN_LINES_7 252 +MX53_PAD_DISP0_DAT20__EMI_EMI_DEBUG_25 253 +MX53_PAD_DISP0_DAT20__SATA_PHY_TDI 254 +MX53_PAD_DISP0_DAT21__IPU_DISP0_DAT_21 255 +MX53_PAD_DISP0_DAT21__GPIO5_15 256 +MX53_PAD_DISP0_DAT21__ECSPI1_MOSI 257 +MX53_PAD_DISP0_DAT21__AUDMUX_AUD4_TXD 258 +MX53_PAD_DISP0_DAT21__SDMA_DEBUG_BUS_DEVICE_0 259 +MX53_PAD_DISP0_DAT21__EMI_EMI_DEBUG_26 260 +MX53_PAD_DISP0_DAT21__SATA_PHY_TDO 261 +MX53_PAD_DISP0_DAT22__IPU_DISP0_DAT_22 262 +MX53_PAD_DISP0_DAT22__GPIO5_16 263 +MX53_PAD_DISP0_DAT22__ECSPI1_MISO 264 +MX53_PAD_DISP0_DAT22__AUDMUX_AUD4_TXFS 265 +MX53_PAD_DISP0_DAT22__SDMA_DEBUG_BUS_DEVICE_1 266 +MX53_PAD_DISP0_DAT22__EMI_EMI_DEBUG_27 267 +MX53_PAD_DISP0_DAT22__SATA_PHY_TCK 268 +MX53_PAD_DISP0_DAT23__IPU_DISP0_DAT_23 269 +MX53_PAD_DISP0_DAT23__GPIO5_17 270 +MX53_PAD_DISP0_DAT23__ECSPI1_SS0 271 +MX53_PAD_DISP0_DAT23__AUDMUX_AUD4_RXD 272 +MX53_PAD_DISP0_DAT23__SDMA_DEBUG_BUS_DEVICE_2 273 +MX53_PAD_DISP0_DAT23__EMI_EMI_DEBUG_28 274 +MX53_PAD_DISP0_DAT23__SATA_PHY_TMS 275 +MX53_PAD_CSI0_PIXCLK__IPU_CSI0_PIXCLK 276 +MX53_PAD_CSI0_PIXCLK__GPIO5_18 277 +MX53_PAD_CSI0_PIXCLK__SDMA_DEBUG_PC_0 278 +MX53_PAD_CSI0_PIXCLK__EMI_EMI_DEBUG_29 279 +MX53_PAD_CSI0_MCLK__IPU_CSI0_HSYNC 280 +MX53_PAD_CSI0_MCLK__GPIO5_19 281 +MX53_PAD_CSI0_MCLK__CCM_CSI0_MCLK 282 +MX53_PAD_CSI0_MCLK__SDMA_DEBUG_PC_1 283 +MX53_PAD_CSI0_MCLK__EMI_EMI_DEBUG_30 284 +MX53_PAD_CSI0_MCLK__TPIU_TRCTL 285 +MX53_PAD_CSI0_DATA_EN__IPU_CSI0_DATA_EN 286 +MX53_PAD_CSI0_DATA_EN__GPIO5_20 287 +MX53_PAD_CSI0_DATA_EN__SDMA_DEBUG_PC_2 288 +MX53_PAD_CSI0_DATA_EN__EMI_EMI_DEBUG_31 289 +MX53_PAD_CSI0_DATA_EN__TPIU_TRCLK 290 +MX53_PAD_CSI0_VSYNC__IPU_CSI0_VSYNC 291 +MX53_PAD_CSI0_VSYNC__GPIO5_21 292 +MX53_PAD_CSI0_VSYNC__SDMA_DEBUG_PC_3 293 +MX53_PAD_CSI0_VSYNC__EMI_EMI_DEBUG_32 294 +MX53_PAD_CSI0_VSYNC__TPIU_TRACE_0 295 +MX53_PAD_CSI0_DAT4__IPU_CSI0_D_4 296 +MX53_PAD_CSI0_DAT4__GPIO5_22 297 +MX53_PAD_CSI0_DAT4__KPP_COL_5 298 +MX53_PAD_CSI0_DAT4__ECSPI1_SCLK 299 +MX53_PAD_CSI0_DAT4__USBOH3_USBH3_STP 300 +MX53_PAD_CSI0_DAT4__AUDMUX_AUD3_TXC 301 +MX53_PAD_CSI0_DAT4__EMI_EMI_DEBUG_33 302 +MX53_PAD_CSI0_DAT4__TPIU_TRACE_1 303 +MX53_PAD_CSI0_DAT5__IPU_CSI0_D_5 304 +MX53_PAD_CSI0_DAT5__GPIO5_23 305 +MX53_PAD_CSI0_DAT5__KPP_ROW_5 306 +MX53_PAD_CSI0_DAT5__ECSPI1_MOSI 307 +MX53_PAD_CSI0_DAT5__USBOH3_USBH3_NXT 308 +MX53_PAD_CSI0_DAT5__AUDMUX_AUD3_TXD 309 +MX53_PAD_CSI0_DAT5__EMI_EMI_DEBUG_34 310 +MX53_PAD_CSI0_DAT5__TPIU_TRACE_2 311 +MX53_PAD_CSI0_DAT6__IPU_CSI0_D_6 312 +MX53_PAD_CSI0_DAT6__GPIO5_24 313 +MX53_PAD_CSI0_DAT6__KPP_COL_6 314 +MX53_PAD_CSI0_DAT6__ECSPI1_MISO 315 +MX53_PAD_CSI0_DAT6__USBOH3_USBH3_CLK 316 +MX53_PAD_CSI0_DAT6__AUDMUX_AUD3_TXFS 317 +MX53_PAD_CSI0_DAT6__EMI_EMI_DEBUG_35 318 +MX53_PAD_CSI0_DAT6__TPIU_TRACE_3 319 +MX53_PAD_CSI0_DAT7__IPU_CSI0_D_7 320 +MX53_PAD_CSI0_DAT7__GPIO5_25 321 +MX53_PAD_CSI0_DAT7__KPP_ROW_6 322 +MX53_PAD_CSI0_DAT7__ECSPI1_SS0 323 +MX53_PAD_CSI0_DAT7__USBOH3_USBH3_DIR 324 +MX53_PAD_CSI0_DAT7__AUDMUX_AUD3_RXD 325 +MX53_PAD_CSI0_DAT7__EMI_EMI_DEBUG_36 326 +MX53_PAD_CSI0_DAT7__TPIU_TRACE_4 327 +MX53_PAD_CSI0_DAT8__IPU_CSI0_D_8 328 +MX53_PAD_CSI0_DAT8__GPIO5_26 329 +MX53_PAD_CSI0_DAT8__KPP_COL_7 330 +MX53_PAD_CSI0_DAT8__ECSPI2_SCLK 331 +MX53_PAD_CSI0_DAT8__USBOH3_USBH3_OC 332 +MX53_PAD_CSI0_DAT8__I2C1_SDA 333 +MX53_PAD_CSI0_DAT8__EMI_EMI_DEBUG_37 334 +MX53_PAD_CSI0_DAT8__TPIU_TRACE_5 335 +MX53_PAD_CSI0_DAT9__IPU_CSI0_D_9 336 +MX53_PAD_CSI0_DAT9__GPIO5_27 337 +MX53_PAD_CSI0_DAT9__KPP_ROW_7 338 +MX53_PAD_CSI0_DAT9__ECSPI2_MOSI 339 +MX53_PAD_CSI0_DAT9__USBOH3_USBH3_PWR 340 +MX53_PAD_CSI0_DAT9__I2C1_SCL 341 +MX53_PAD_CSI0_DAT9__EMI_EMI_DEBUG_38 342 +MX53_PAD_CSI0_DAT9__TPIU_TRACE_6 343 +MX53_PAD_CSI0_DAT10__IPU_CSI0_D_10 344 +MX53_PAD_CSI0_DAT10__GPIO5_28 345 +MX53_PAD_CSI0_DAT10__UART1_TXD_MUX 346 +MX53_PAD_CSI0_DAT10__ECSPI2_MISO 347 +MX53_PAD_CSI0_DAT10__AUDMUX_AUD3_RXC 348 +MX53_PAD_CSI0_DAT10__SDMA_DEBUG_PC_4 349 +MX53_PAD_CSI0_DAT10__EMI_EMI_DEBUG_39 350 +MX53_PAD_CSI0_DAT10__TPIU_TRACE_7 351 +MX53_PAD_CSI0_DAT11__IPU_CSI0_D_11 352 +MX53_PAD_CSI0_DAT11__GPIO5_29 353 +MX53_PAD_CSI0_DAT11__UART1_RXD_MUX 354 +MX53_PAD_CSI0_DAT11__ECSPI2_SS0 355 +MX53_PAD_CSI0_DAT11__AUDMUX_AUD3_RXFS 356 +MX53_PAD_CSI0_DAT11__SDMA_DEBUG_PC_5 357 +MX53_PAD_CSI0_DAT11__EMI_EMI_DEBUG_40 358 +MX53_PAD_CSI0_DAT11__TPIU_TRACE_8 359 +MX53_PAD_CSI0_DAT12__IPU_CSI0_D_12 360 +MX53_PAD_CSI0_DAT12__GPIO5_30 361 +MX53_PAD_CSI0_DAT12__UART4_TXD_MUX 362 +MX53_PAD_CSI0_DAT12__USBOH3_USBH3_DATA_0 363 +MX53_PAD_CSI0_DAT12__SDMA_DEBUG_PC_6 364 +MX53_PAD_CSI0_DAT12__EMI_EMI_DEBUG_41 365 +MX53_PAD_CSI0_DAT12__TPIU_TRACE_9 366 +MX53_PAD_CSI0_DAT13__IPU_CSI0_D_13 367 +MX53_PAD_CSI0_DAT13__GPIO5_31 368 +MX53_PAD_CSI0_DAT13__UART4_RXD_MUX 369 +MX53_PAD_CSI0_DAT13__USBOH3_USBH3_DATA_1 370 +MX53_PAD_CSI0_DAT13__SDMA_DEBUG_PC_7 371 +MX53_PAD_CSI0_DAT13__EMI_EMI_DEBUG_42 372 +MX53_PAD_CSI0_DAT13__TPIU_TRACE_10 373 +MX53_PAD_CSI0_DAT14__IPU_CSI0_D_14 374 +MX53_PAD_CSI0_DAT14__GPIO6_0 375 +MX53_PAD_CSI0_DAT14__UART5_TXD_MUX 376 +MX53_PAD_CSI0_DAT14__USBOH3_USBH3_DATA_2 377 +MX53_PAD_CSI0_DAT14__SDMA_DEBUG_PC_8 378 +MX53_PAD_CSI0_DAT14__EMI_EMI_DEBUG_43 379 +MX53_PAD_CSI0_DAT14__TPIU_TRACE_11 380 +MX53_PAD_CSI0_DAT15__IPU_CSI0_D_15 381 +MX53_PAD_CSI0_DAT15__GPIO6_1 382 +MX53_PAD_CSI0_DAT15__UART5_RXD_MUX 383 +MX53_PAD_CSI0_DAT15__USBOH3_USBH3_DATA_3 384 +MX53_PAD_CSI0_DAT15__SDMA_DEBUG_PC_9 385 +MX53_PAD_CSI0_DAT15__EMI_EMI_DEBUG_44 386 +MX53_PAD_CSI0_DAT15__TPIU_TRACE_12 387 +MX53_PAD_CSI0_DAT16__IPU_CSI0_D_16 388 +MX53_PAD_CSI0_DAT16__GPIO6_2 389 +MX53_PAD_CSI0_DAT16__UART4_RTS 390 +MX53_PAD_CSI0_DAT16__USBOH3_USBH3_DATA_4 391 +MX53_PAD_CSI0_DAT16__SDMA_DEBUG_PC_10 392 +MX53_PAD_CSI0_DAT16__EMI_EMI_DEBUG_45 393 +MX53_PAD_CSI0_DAT16__TPIU_TRACE_13 394 +MX53_PAD_CSI0_DAT17__IPU_CSI0_D_17 395 +MX53_PAD_CSI0_DAT17__GPIO6_3 396 +MX53_PAD_CSI0_DAT17__UART4_CTS 397 +MX53_PAD_CSI0_DAT17__USBOH3_USBH3_DATA_5 398 +MX53_PAD_CSI0_DAT17__SDMA_DEBUG_PC_11 399 +MX53_PAD_CSI0_DAT17__EMI_EMI_DEBUG_46 400 +MX53_PAD_CSI0_DAT17__TPIU_TRACE_14 401 +MX53_PAD_CSI0_DAT18__IPU_CSI0_D_18 402 +MX53_PAD_CSI0_DAT18__GPIO6_4 403 +MX53_PAD_CSI0_DAT18__UART5_RTS 404 +MX53_PAD_CSI0_DAT18__USBOH3_USBH3_DATA_6 405 +MX53_PAD_CSI0_DAT18__SDMA_DEBUG_PC_12 406 +MX53_PAD_CSI0_DAT18__EMI_EMI_DEBUG_47 407 +MX53_PAD_CSI0_DAT18__TPIU_TRACE_15 408 +MX53_PAD_CSI0_DAT19__IPU_CSI0_D_19 409 +MX53_PAD_CSI0_DAT19__GPIO6_5 410 +MX53_PAD_CSI0_DAT19__UART5_CTS 411 +MX53_PAD_CSI0_DAT19__USBOH3_USBH3_DATA_7 412 +MX53_PAD_CSI0_DAT19__SDMA_DEBUG_PC_13 413 +MX53_PAD_CSI0_DAT19__EMI_EMI_DEBUG_48 414 +MX53_PAD_CSI0_DAT19__USBPHY2_BISTOK 415 +MX53_PAD_EIM_A25__EMI_WEIM_A_25 416 +MX53_PAD_EIM_A25__GPIO5_2 417 +MX53_PAD_EIM_A25__ECSPI2_RDY 418 +MX53_PAD_EIM_A25__IPU_DI1_PIN12 419 +MX53_PAD_EIM_A25__CSPI_SS1 420 +MX53_PAD_EIM_A25__IPU_DI0_D1_CS 421 +MX53_PAD_EIM_A25__USBPHY1_BISTOK 422 +MX53_PAD_EIM_EB2__EMI_WEIM_EB_2 423 +MX53_PAD_EIM_EB2__GPIO2_30 424 +MX53_PAD_EIM_EB2__CCM_DI1_EXT_CLK 425 +MX53_PAD_EIM_EB2__IPU_SER_DISP1_CS 426 +MX53_PAD_EIM_EB2__ECSPI1_SS0 427 +MX53_PAD_EIM_EB2__I2C2_SCL 428 +MX53_PAD_EIM_D16__EMI_WEIM_D_16 429 +MX53_PAD_EIM_D16__GPIO3_16 430 +MX53_PAD_EIM_D16__IPU_DI0_PIN5 431 +MX53_PAD_EIM_D16__IPU_DISPB1_SER_CLK 432 +MX53_PAD_EIM_D16__ECSPI1_SCLK 433 +MX53_PAD_EIM_D16__I2C2_SDA 434 +MX53_PAD_EIM_D17__EMI_WEIM_D_17 435 +MX53_PAD_EIM_D17__GPIO3_17 436 +MX53_PAD_EIM_D17__IPU_DI0_PIN6 437 +MX53_PAD_EIM_D17__IPU_DISPB1_SER_DIN 438 +MX53_PAD_EIM_D17__ECSPI1_MISO 439 +MX53_PAD_EIM_D17__I2C3_SCL 440 +MX53_PAD_EIM_D18__EMI_WEIM_D_18 441 +MX53_PAD_EIM_D18__GPIO3_18 442 +MX53_PAD_EIM_D18__IPU_DI0_PIN7 443 +MX53_PAD_EIM_D18__IPU_DISPB1_SER_DIO 444 +MX53_PAD_EIM_D18__ECSPI1_MOSI 445 +MX53_PAD_EIM_D18__I2C3_SDA 446 +MX53_PAD_EIM_D18__IPU_DI1_D0_CS 447 +MX53_PAD_EIM_D19__EMI_WEIM_D_19 448 +MX53_PAD_EIM_D19__GPIO3_19 449 +MX53_PAD_EIM_D19__IPU_DI0_PIN8 450 +MX53_PAD_EIM_D19__IPU_DISPB1_SER_RS 451 +MX53_PAD_EIM_D19__ECSPI1_SS1 452 +MX53_PAD_EIM_D19__EPIT1_EPITO 453 +MX53_PAD_EIM_D19__UART1_CTS 454 +MX53_PAD_EIM_D19__USBOH3_USBH2_OC 455 +MX53_PAD_EIM_D20__EMI_WEIM_D_20 456 +MX53_PAD_EIM_D20__GPIO3_20 457 +MX53_PAD_EIM_D20__IPU_DI0_PIN16 458 +MX53_PAD_EIM_D20__IPU_SER_DISP0_CS 459 +MX53_PAD_EIM_D20__CSPI_SS0 460 +MX53_PAD_EIM_D20__EPIT2_EPITO 461 +MX53_PAD_EIM_D20__UART1_RTS 462 +MX53_PAD_EIM_D20__USBOH3_USBH2_PWR 463 +MX53_PAD_EIM_D21__EMI_WEIM_D_21 464 +MX53_PAD_EIM_D21__GPIO3_21 465 +MX53_PAD_EIM_D21__IPU_DI0_PIN17 466 +MX53_PAD_EIM_D21__IPU_DISPB0_SER_CLK 467 +MX53_PAD_EIM_D21__CSPI_SCLK 468 +MX53_PAD_EIM_D21__I2C1_SCL 469 +MX53_PAD_EIM_D21__USBOH3_USBOTG_OC 470 +MX53_PAD_EIM_D22__EMI_WEIM_D_22 471 +MX53_PAD_EIM_D22__GPIO3_22 472 +MX53_PAD_EIM_D22__IPU_DI0_PIN1 473 +MX53_PAD_EIM_D22__IPU_DISPB0_SER_DIN 474 +MX53_PAD_EIM_D22__CSPI_MISO 475 +MX53_PAD_EIM_D22__USBOH3_USBOTG_PWR 476 +MX53_PAD_EIM_D23__EMI_WEIM_D_23 477 +MX53_PAD_EIM_D23__GPIO3_23 478 +MX53_PAD_EIM_D23__UART3_CTS 479 +MX53_PAD_EIM_D23__UART1_DCD 480 +MX53_PAD_EIM_D23__IPU_DI0_D0_CS 481 +MX53_PAD_EIM_D23__IPU_DI1_PIN2 482 +MX53_PAD_EIM_D23__IPU_CSI1_DATA_EN 483 +MX53_PAD_EIM_D23__IPU_DI1_PIN14 484 +MX53_PAD_EIM_EB3__EMI_WEIM_EB_3 485 +MX53_PAD_EIM_EB3__GPIO2_31 486 +MX53_PAD_EIM_EB3__UART3_RTS 487 +MX53_PAD_EIM_EB3__UART1_RI 488 +MX53_PAD_EIM_EB3__IPU_DI1_PIN3 489 +MX53_PAD_EIM_EB3__IPU_CSI1_HSYNC 490 +MX53_PAD_EIM_EB3__IPU_DI1_PIN16 491 +MX53_PAD_EIM_D24__EMI_WEIM_D_24 492 +MX53_PAD_EIM_D24__GPIO3_24 493 +MX53_PAD_EIM_D24__UART3_TXD_MUX 494 +MX53_PAD_EIM_D24__ECSPI1_SS2 495 +MX53_PAD_EIM_D24__CSPI_SS2 496 +MX53_PAD_EIM_D24__AUDMUX_AUD5_RXFS 497 +MX53_PAD_EIM_D24__ECSPI2_SS2 498 +MX53_PAD_EIM_D24__UART1_DTR 499 +MX53_PAD_EIM_D25__EMI_WEIM_D_25 500 +MX53_PAD_EIM_D25__GPIO3_25 501 +MX53_PAD_EIM_D25__UART3_RXD_MUX 502 +MX53_PAD_EIM_D25__ECSPI1_SS3 503 +MX53_PAD_EIM_D25__CSPI_SS3 504 +MX53_PAD_EIM_D25__AUDMUX_AUD5_RXC 505 +MX53_PAD_EIM_D25__ECSPI2_SS3 506 +MX53_PAD_EIM_D25__UART1_DSR 507 +MX53_PAD_EIM_D26__EMI_WEIM_D_26 508 +MX53_PAD_EIM_D26__GPIO3_26 509 +MX53_PAD_EIM_D26__UART2_TXD_MUX 510 +MX53_PAD_EIM_D26__FIRI_RXD 511 +MX53_PAD_EIM_D26__IPU_CSI0_D_1 512 +MX53_PAD_EIM_D26__IPU_DI1_PIN11 513 +MX53_PAD_EIM_D26__IPU_SISG_2 514 +MX53_PAD_EIM_D26__IPU_DISP1_DAT_22 515 +MX53_PAD_EIM_D27__EMI_WEIM_D_27 516 +MX53_PAD_EIM_D27__GPIO3_27 517 +MX53_PAD_EIM_D27__UART2_RXD_MUX 518 +MX53_PAD_EIM_D27__FIRI_TXD 519 +MX53_PAD_EIM_D27__IPU_CSI0_D_0 520 +MX53_PAD_EIM_D27__IPU_DI1_PIN13 521 +MX53_PAD_EIM_D27__IPU_SISG_3 522 +MX53_PAD_EIM_D27__IPU_DISP1_DAT_23 523 +MX53_PAD_EIM_D28__EMI_WEIM_D_28 524 +MX53_PAD_EIM_D28__GPIO3_28 525 +MX53_PAD_EIM_D28__UART2_CTS 526 +MX53_PAD_EIM_D28__IPU_DISPB0_SER_DIO 527 +MX53_PAD_EIM_D28__CSPI_MOSI 528 +MX53_PAD_EIM_D28__I2C1_SDA 529 +MX53_PAD_EIM_D28__IPU_EXT_TRIG 530 +MX53_PAD_EIM_D28__IPU_DI0_PIN13 531 +MX53_PAD_EIM_D29__EMI_WEIM_D_29 532 +MX53_PAD_EIM_D29__GPIO3_29 533 +MX53_PAD_EIM_D29__UART2_RTS 534 +MX53_PAD_EIM_D29__IPU_DISPB0_SER_RS 535 +MX53_PAD_EIM_D29__CSPI_SS0 536 +MX53_PAD_EIM_D29__IPU_DI1_PIN15 537 +MX53_PAD_EIM_D29__IPU_CSI1_VSYNC 538 +MX53_PAD_EIM_D29__IPU_DI0_PIN14 539 +MX53_PAD_EIM_D30__EMI_WEIM_D_30 540 +MX53_PAD_EIM_D30__GPIO3_30 541 +MX53_PAD_EIM_D30__UART3_CTS 542 +MX53_PAD_EIM_D30__IPU_CSI0_D_3 543 +MX53_PAD_EIM_D30__IPU_DI0_PIN11 544 +MX53_PAD_EIM_D30__IPU_DISP1_DAT_21 545 +MX53_PAD_EIM_D30__USBOH3_USBH1_OC 546 +MX53_PAD_EIM_D30__USBOH3_USBH2_OC 547 +MX53_PAD_EIM_D31__EMI_WEIM_D_31 548 +MX53_PAD_EIM_D31__GPIO3_31 549 +MX53_PAD_EIM_D31__UART3_RTS 550 +MX53_PAD_EIM_D31__IPU_CSI0_D_2 551 +MX53_PAD_EIM_D31__IPU_DI0_PIN12 552 +MX53_PAD_EIM_D31__IPU_DISP1_DAT_20 553 +MX53_PAD_EIM_D31__USBOH3_USBH1_PWR 554 +MX53_PAD_EIM_D31__USBOH3_USBH2_PWR 555 +MX53_PAD_EIM_A24__EMI_WEIM_A_24 556 +MX53_PAD_EIM_A24__GPIO5_4 557 +MX53_PAD_EIM_A24__IPU_DISP1_DAT_19 558 +MX53_PAD_EIM_A24__IPU_CSI1_D_19 559 +MX53_PAD_EIM_A24__IPU_SISG_2 560 +MX53_PAD_EIM_A24__USBPHY2_BVALID 561 +MX53_PAD_EIM_A23__EMI_WEIM_A_23 562 +MX53_PAD_EIM_A23__GPIO6_6 563 +MX53_PAD_EIM_A23__IPU_DISP1_DAT_18 564 +MX53_PAD_EIM_A23__IPU_CSI1_D_18 565 +MX53_PAD_EIM_A23__IPU_SISG_3 566 +MX53_PAD_EIM_A23__USBPHY2_ENDSESSION 567 +MX53_PAD_EIM_A22__EMI_WEIM_A_22 568 +MX53_PAD_EIM_A22__GPIO2_16 569 +MX53_PAD_EIM_A22__IPU_DISP1_DAT_17 570 +MX53_PAD_EIM_A22__IPU_CSI1_D_17 571 +MX53_PAD_EIM_A22__SRC_BT_CFG1_7 572 +MX53_PAD_EIM_A21__EMI_WEIM_A_21 573 +MX53_PAD_EIM_A21__GPIO2_17 574 +MX53_PAD_EIM_A21__IPU_DISP1_DAT_16 575 +MX53_PAD_EIM_A21__IPU_CSI1_D_16 576 +MX53_PAD_EIM_A21__SRC_BT_CFG1_6 577 +MX53_PAD_EIM_A20__EMI_WEIM_A_20 578 +MX53_PAD_EIM_A20__GPIO2_18 579 +MX53_PAD_EIM_A20__IPU_DISP1_DAT_15 580 +MX53_PAD_EIM_A20__IPU_CSI1_D_15 581 +MX53_PAD_EIM_A20__SRC_BT_CFG1_5 582 +MX53_PAD_EIM_A19__EMI_WEIM_A_19 583 +MX53_PAD_EIM_A19__GPIO2_19 584 +MX53_PAD_EIM_A19__IPU_DISP1_DAT_14 585 +MX53_PAD_EIM_A19__IPU_CSI1_D_14 586 +MX53_PAD_EIM_A19__SRC_BT_CFG1_4 587 +MX53_PAD_EIM_A18__EMI_WEIM_A_18 588 +MX53_PAD_EIM_A18__GPIO2_20 589 +MX53_PAD_EIM_A18__IPU_DISP1_DAT_13 590 +MX53_PAD_EIM_A18__IPU_CSI1_D_13 591 +MX53_PAD_EIM_A18__SRC_BT_CFG1_3 592 +MX53_PAD_EIM_A17__EMI_WEIM_A_17 593 +MX53_PAD_EIM_A17__GPIO2_21 594 +MX53_PAD_EIM_A17__IPU_DISP1_DAT_12 595 +MX53_PAD_EIM_A17__IPU_CSI1_D_12 596 +MX53_PAD_EIM_A17__SRC_BT_CFG1_2 597 +MX53_PAD_EIM_A16__EMI_WEIM_A_16 598 +MX53_PAD_EIM_A16__GPIO2_22 599 +MX53_PAD_EIM_A16__IPU_DI1_DISP_CLK 600 +MX53_PAD_EIM_A16__IPU_CSI1_PIXCLK 601 +MX53_PAD_EIM_A16__SRC_BT_CFG1_1 602 +MX53_PAD_EIM_CS0__EMI_WEIM_CS_0 603 +MX53_PAD_EIM_CS0__GPIO2_23 604 +MX53_PAD_EIM_CS0__ECSPI2_SCLK 605 +MX53_PAD_EIM_CS0__IPU_DI1_PIN5 606 +MX53_PAD_EIM_CS1__EMI_WEIM_CS_1 607 +MX53_PAD_EIM_CS1__GPIO2_24 608 +MX53_PAD_EIM_CS1__ECSPI2_MOSI 609 +MX53_PAD_EIM_CS1__IPU_DI1_PIN6 610 +MX53_PAD_EIM_OE__EMI_WEIM_OE 611 +MX53_PAD_EIM_OE__GPIO2_25 612 +MX53_PAD_EIM_OE__ECSPI2_MISO 613 +MX53_PAD_EIM_OE__IPU_DI1_PIN7 614 +MX53_PAD_EIM_OE__USBPHY2_IDDIG 615 +MX53_PAD_EIM_RW__EMI_WEIM_RW 616 +MX53_PAD_EIM_RW__GPIO2_26 617 +MX53_PAD_EIM_RW__ECSPI2_SS0 618 +MX53_PAD_EIM_RW__IPU_DI1_PIN8 619 +MX53_PAD_EIM_RW__USBPHY2_HOSTDISCONNECT 620 +MX53_PAD_EIM_LBA__EMI_WEIM_LBA 621 +MX53_PAD_EIM_LBA__GPIO2_27 622 +MX53_PAD_EIM_LBA__ECSPI2_SS1 623 +MX53_PAD_EIM_LBA__IPU_DI1_PIN17 624 +MX53_PAD_EIM_LBA__SRC_BT_CFG1_0 625 +MX53_PAD_EIM_EB0__EMI_WEIM_EB_0 626 +MX53_PAD_EIM_EB0__GPIO2_28 627 +MX53_PAD_EIM_EB0__IPU_DISP1_DAT_11 628 +MX53_PAD_EIM_EB0__IPU_CSI1_D_11 629 +MX53_PAD_EIM_EB0__GPC_PMIC_RDY 630 +MX53_PAD_EIM_EB0__SRC_BT_CFG2_7 631 +MX53_PAD_EIM_EB1__EMI_WEIM_EB_1 632 +MX53_PAD_EIM_EB1__GPIO2_29 633 +MX53_PAD_EIM_EB1__IPU_DISP1_DAT_10 634 +MX53_PAD_EIM_EB1__IPU_CSI1_D_10 635 +MX53_PAD_EIM_EB1__SRC_BT_CFG2_6 636 +MX53_PAD_EIM_DA0__EMI_NAND_WEIM_DA_0 637 +MX53_PAD_EIM_DA0__GPIO3_0 638 +MX53_PAD_EIM_DA0__IPU_DISP1_DAT_9 639 +MX53_PAD_EIM_DA0__IPU_CSI1_D_9 640 +MX53_PAD_EIM_DA0__SRC_BT_CFG2_5 641 +MX53_PAD_EIM_DA1__EMI_NAND_WEIM_DA_1 642 +MX53_PAD_EIM_DA1__GPIO3_1 643 +MX53_PAD_EIM_DA1__IPU_DISP1_DAT_8 644 +MX53_PAD_EIM_DA1__IPU_CSI1_D_8 645 +MX53_PAD_EIM_DA1__SRC_BT_CFG2_4 646 +MX53_PAD_EIM_DA2__EMI_NAND_WEIM_DA_2 647 +MX53_PAD_EIM_DA2__GPIO3_2 648 +MX53_PAD_EIM_DA2__IPU_DISP1_DAT_7 649 +MX53_PAD_EIM_DA2__IPU_CSI1_D_7 650 +MX53_PAD_EIM_DA2__SRC_BT_CFG2_3 651 +MX53_PAD_EIM_DA3__EMI_NAND_WEIM_DA_3 652 +MX53_PAD_EIM_DA3__GPIO3_3 653 +MX53_PAD_EIM_DA3__IPU_DISP1_DAT_6 654 +MX53_PAD_EIM_DA3__IPU_CSI1_D_6 655 +MX53_PAD_EIM_DA3__SRC_BT_CFG2_2 656 +MX53_PAD_EIM_DA4__EMI_NAND_WEIM_DA_4 657 +MX53_PAD_EIM_DA4__GPIO3_4 658 +MX53_PAD_EIM_DA4__IPU_DISP1_DAT_5 659 +MX53_PAD_EIM_DA4__IPU_CSI1_D_5 660 +MX53_PAD_EIM_DA4__SRC_BT_CFG3_7 661 +MX53_PAD_EIM_DA5__EMI_NAND_WEIM_DA_5 662 +MX53_PAD_EIM_DA5__GPIO3_5 663 +MX53_PAD_EIM_DA5__IPU_DISP1_DAT_4 664 +MX53_PAD_EIM_DA5__IPU_CSI1_D_4 665 +MX53_PAD_EIM_DA5__SRC_BT_CFG3_6 666 +MX53_PAD_EIM_DA6__EMI_NAND_WEIM_DA_6 667 +MX53_PAD_EIM_DA6__GPIO3_6 668 +MX53_PAD_EIM_DA6__IPU_DISP1_DAT_3 669 +MX53_PAD_EIM_DA6__IPU_CSI1_D_3 670 +MX53_PAD_EIM_DA6__SRC_BT_CFG3_5 671 +MX53_PAD_EIM_DA7__EMI_NAND_WEIM_DA_7 672 +MX53_PAD_EIM_DA7__GPIO3_7 673 +MX53_PAD_EIM_DA7__IPU_DISP1_DAT_2 674 +MX53_PAD_EIM_DA7__IPU_CSI1_D_2 675 +MX53_PAD_EIM_DA7__SRC_BT_CFG3_4 676 +MX53_PAD_EIM_DA8__EMI_NAND_WEIM_DA_8 677 +MX53_PAD_EIM_DA8__GPIO3_8 678 +MX53_PAD_EIM_DA8__IPU_DISP1_DAT_1 679 +MX53_PAD_EIM_DA8__IPU_CSI1_D_1 680 +MX53_PAD_EIM_DA8__SRC_BT_CFG3_3 681 +MX53_PAD_EIM_DA9__EMI_NAND_WEIM_DA_9 682 +MX53_PAD_EIM_DA9__GPIO3_9 683 +MX53_PAD_EIM_DA9__IPU_DISP1_DAT_0 684 +MX53_PAD_EIM_DA9__IPU_CSI1_D_0 685 +MX53_PAD_EIM_DA9__SRC_BT_CFG3_2 686 +MX53_PAD_EIM_DA10__EMI_NAND_WEIM_DA_10 687 +MX53_PAD_EIM_DA10__GPIO3_10 688 +MX53_PAD_EIM_DA10__IPU_DI1_PIN15 689 +MX53_PAD_EIM_DA10__IPU_CSI1_DATA_EN 690 +MX53_PAD_EIM_DA10__SRC_BT_CFG3_1 691 +MX53_PAD_EIM_DA11__EMI_NAND_WEIM_DA_11 692 +MX53_PAD_EIM_DA11__GPIO3_11 693 +MX53_PAD_EIM_DA11__IPU_DI1_PIN2 694 +MX53_PAD_EIM_DA11__IPU_CSI1_HSYNC 695 +MX53_PAD_EIM_DA12__EMI_NAND_WEIM_DA_12 696 +MX53_PAD_EIM_DA12__GPIO3_12 697 +MX53_PAD_EIM_DA12__IPU_DI1_PIN3 698 +MX53_PAD_EIM_DA12__IPU_CSI1_VSYNC 699 +MX53_PAD_EIM_DA13__EMI_NAND_WEIM_DA_13 700 +MX53_PAD_EIM_DA13__GPIO3_13 701 +MX53_PAD_EIM_DA13__IPU_DI1_D0_CS 702 +MX53_PAD_EIM_DA13__CCM_DI1_EXT_CLK 703 +MX53_PAD_EIM_DA14__EMI_NAND_WEIM_DA_14 704 +MX53_PAD_EIM_DA14__GPIO3_14 705 +MX53_PAD_EIM_DA14__IPU_DI1_D1_CS 706 +MX53_PAD_EIM_DA14__CCM_DI0_EXT_CLK 707 +MX53_PAD_EIM_DA15__EMI_NAND_WEIM_DA_15 708 +MX53_PAD_EIM_DA15__GPIO3_15 709 +MX53_PAD_EIM_DA15__IPU_DI1_PIN1 710 +MX53_PAD_EIM_DA15__IPU_DI1_PIN4 711 +MX53_PAD_NANDF_WE_B__EMI_NANDF_WE_B 712 +MX53_PAD_NANDF_WE_B__GPIO6_12 713 +MX53_PAD_NANDF_RE_B__EMI_NANDF_RE_B 714 +MX53_PAD_NANDF_RE_B__GPIO6_13 715 +MX53_PAD_EIM_WAIT__EMI_WEIM_WAIT 716 +MX53_PAD_EIM_WAIT__GPIO5_0 717 +MX53_PAD_EIM_WAIT__EMI_WEIM_DTACK_B 718 +MX53_PAD_LVDS1_TX3_P__GPIO6_22 719 +MX53_PAD_LVDS1_TX3_P__LDB_LVDS1_TX3 720 +MX53_PAD_LVDS1_TX2_P__GPIO6_24 721 +MX53_PAD_LVDS1_TX2_P__LDB_LVDS1_TX2 722 +MX53_PAD_LVDS1_CLK_P__GPIO6_26 723 +MX53_PAD_LVDS1_CLK_P__LDB_LVDS1_CLK 724 +MX53_PAD_LVDS1_TX1_P__GPIO6_28 725 +MX53_PAD_LVDS1_TX1_P__LDB_LVDS1_TX1 726 +MX53_PAD_LVDS1_TX0_P__GPIO6_30 727 +MX53_PAD_LVDS1_TX0_P__LDB_LVDS1_TX0 728 +MX53_PAD_LVDS0_TX3_P__GPIO7_22 729 +MX53_PAD_LVDS0_TX3_P__LDB_LVDS0_TX3 730 +MX53_PAD_LVDS0_CLK_P__GPIO7_24 731 +MX53_PAD_LVDS0_CLK_P__LDB_LVDS0_CLK 732 +MX53_PAD_LVDS0_TX2_P__GPIO7_26 733 +MX53_PAD_LVDS0_TX2_P__LDB_LVDS0_TX2 734 +MX53_PAD_LVDS0_TX1_P__GPIO7_28 735 +MX53_PAD_LVDS0_TX1_P__LDB_LVDS0_TX1 736 +MX53_PAD_LVDS0_TX0_P__GPIO7_30 737 +MX53_PAD_LVDS0_TX0_P__LDB_LVDS0_TX0 738 +MX53_PAD_GPIO_10__GPIO4_0 739 +MX53_PAD_GPIO_10__OSC32k_32K_OUT 740 +MX53_PAD_GPIO_11__GPIO4_1 741 +MX53_PAD_GPIO_12__GPIO4_2 742 +MX53_PAD_GPIO_13__GPIO4_3 743 +MX53_PAD_GPIO_14__GPIO4_4 744 +MX53_PAD_NANDF_CLE__EMI_NANDF_CLE 745 +MX53_PAD_NANDF_CLE__GPIO6_7 746 +MX53_PAD_NANDF_CLE__USBPHY1_VSTATUS_0 747 +MX53_PAD_NANDF_ALE__EMI_NANDF_ALE 748 +MX53_PAD_NANDF_ALE__GPIO6_8 749 +MX53_PAD_NANDF_ALE__USBPHY1_VSTATUS_1 750 +MX53_PAD_NANDF_WP_B__EMI_NANDF_WP_B 751 +MX53_PAD_NANDF_WP_B__GPIO6_9 752 +MX53_PAD_NANDF_WP_B__USBPHY1_VSTATUS_2 753 +MX53_PAD_NANDF_RB0__EMI_NANDF_RB_0 754 +MX53_PAD_NANDF_RB0__GPIO6_10 755 +MX53_PAD_NANDF_RB0__USBPHY1_VSTATUS_3 756 +MX53_PAD_NANDF_CS0__EMI_NANDF_CS_0 757 +MX53_PAD_NANDF_CS0__GPIO6_11 758 +MX53_PAD_NANDF_CS0__USBPHY1_VSTATUS_4 759 +MX53_PAD_NANDF_CS1__EMI_NANDF_CS_1 760 +MX53_PAD_NANDF_CS1__GPIO6_14 761 +MX53_PAD_NANDF_CS1__MLB_MLBCLK 762 +MX53_PAD_NANDF_CS1__USBPHY1_VSTATUS_5 763 +MX53_PAD_NANDF_CS2__EMI_NANDF_CS_2 764 +MX53_PAD_NANDF_CS2__GPIO6_15 765 +MX53_PAD_NANDF_CS2__IPU_SISG_0 766 +MX53_PAD_NANDF_CS2__ESAI1_TX0 767 +MX53_PAD_NANDF_CS2__EMI_WEIM_CRE 768 +MX53_PAD_NANDF_CS2__CCM_CSI0_MCLK 769 +MX53_PAD_NANDF_CS2__MLB_MLBSIG 770 +MX53_PAD_NANDF_CS2__USBPHY1_VSTATUS_6 771 +MX53_PAD_NANDF_CS3__EMI_NANDF_CS_3 772 +MX53_PAD_NANDF_CS3__GPIO6_16 773 +MX53_PAD_NANDF_CS3__IPU_SISG_1 774 +MX53_PAD_NANDF_CS3__ESAI1_TX1 775 +MX53_PAD_NANDF_CS3__EMI_WEIM_A_26 776 +MX53_PAD_NANDF_CS3__MLB_MLBDAT 777 +MX53_PAD_NANDF_CS3__USBPHY1_VSTATUS_7 778 +MX53_PAD_FEC_MDIO__FEC_MDIO 779 +MX53_PAD_FEC_MDIO__GPIO1_22 780 +MX53_PAD_FEC_MDIO__ESAI1_SCKR 781 +MX53_PAD_FEC_MDIO__FEC_COL 782 +MX53_PAD_FEC_MDIO__RTC_CE_RTC_PS2 783 +MX53_PAD_FEC_MDIO__SDMA_DEBUG_BUS_DEVICE_3 784 +MX53_PAD_FEC_MDIO__EMI_EMI_DEBUG_49 785 +MX53_PAD_FEC_REF_CLK__FEC_TX_CLK 786 +MX53_PAD_FEC_REF_CLK__GPIO1_23 787 +MX53_PAD_FEC_REF_CLK__ESAI1_FSR 788 +MX53_PAD_FEC_REF_CLK__SDMA_DEBUG_BUS_DEVICE_4 789 +MX53_PAD_FEC_REF_CLK__EMI_EMI_DEBUG_50 790 +MX53_PAD_FEC_RX_ER__FEC_RX_ER 791 +MX53_PAD_FEC_RX_ER__GPIO1_24 792 +MX53_PAD_FEC_RX_ER__ESAI1_HCKR 793 +MX53_PAD_FEC_RX_ER__FEC_RX_CLK 794 +MX53_PAD_FEC_RX_ER__RTC_CE_RTC_PS3 795 +MX53_PAD_FEC_CRS_DV__FEC_RX_DV 796 +MX53_PAD_FEC_CRS_DV__GPIO1_25 797 +MX53_PAD_FEC_CRS_DV__ESAI1_SCKT 798 +MX53_PAD_FEC_RXD1__FEC_RDATA_1 799 +MX53_PAD_FEC_RXD1__GPIO1_26 800 +MX53_PAD_FEC_RXD1__ESAI1_FST 801 +MX53_PAD_FEC_RXD1__MLB_MLBSIG 802 +MX53_PAD_FEC_RXD1__RTC_CE_RTC_PS1 803 +MX53_PAD_FEC_RXD0__FEC_RDATA_0 804 +MX53_PAD_FEC_RXD0__GPIO1_27 805 +MX53_PAD_FEC_RXD0__ESAI1_HCKT 806 +MX53_PAD_FEC_RXD0__OSC32k_32K_OUT 807 +MX53_PAD_FEC_TX_EN__FEC_TX_EN 808 +MX53_PAD_FEC_TX_EN__GPIO1_28 809 +MX53_PAD_FEC_TX_EN__ESAI1_TX3_RX2 810 +MX53_PAD_FEC_TXD1__FEC_TDATA_1 811 +MX53_PAD_FEC_TXD1__GPIO1_29 812 +MX53_PAD_FEC_TXD1__ESAI1_TX2_RX3 813 +MX53_PAD_FEC_TXD1__MLB_MLBCLK 814 +MX53_PAD_FEC_TXD1__RTC_CE_RTC_PRSC_CLK 815 +MX53_PAD_FEC_TXD0__FEC_TDATA_0 816 +MX53_PAD_FEC_TXD0__GPIO1_30 817 +MX53_PAD_FEC_TXD0__ESAI1_TX4_RX1 818 +MX53_PAD_FEC_TXD0__USBPHY2_DATAOUT_0 819 +MX53_PAD_FEC_MDC__FEC_MDC 820 +MX53_PAD_FEC_MDC__GPIO1_31 821 +MX53_PAD_FEC_MDC__ESAI1_TX5_RX0 822 +MX53_PAD_FEC_MDC__MLB_MLBDAT 823 +MX53_PAD_FEC_MDC__RTC_CE_RTC_ALARM1_TRIG 824 +MX53_PAD_FEC_MDC__USBPHY2_DATAOUT_1 825 +MX53_PAD_PATA_DIOW__PATA_DIOW 826 +MX53_PAD_PATA_DIOW__GPIO6_17 827 +MX53_PAD_PATA_DIOW__UART1_TXD_MUX 828 +MX53_PAD_PATA_DIOW__USBPHY2_DATAOUT_2 829 +MX53_PAD_PATA_DMACK__PATA_DMACK 830 +MX53_PAD_PATA_DMACK__GPIO6_18 831 +MX53_PAD_PATA_DMACK__UART1_RXD_MUX 832 +MX53_PAD_PATA_DMACK__USBPHY2_DATAOUT_3 833 +MX53_PAD_PATA_DMARQ__PATA_DMARQ 834 +MX53_PAD_PATA_DMARQ__GPIO7_0 835 +MX53_PAD_PATA_DMARQ__UART2_TXD_MUX 836 +MX53_PAD_PATA_DMARQ__CCM_CCM_OUT_0 837 +MX53_PAD_PATA_DMARQ__USBPHY2_DATAOUT_4 838 +MX53_PAD_PATA_BUFFER_EN__PATA_BUFFER_EN 839 +MX53_PAD_PATA_BUFFER_EN__GPIO7_1 840 +MX53_PAD_PATA_BUFFER_EN__UART2_RXD_MUX 841 +MX53_PAD_PATA_BUFFER_EN__CCM_CCM_OUT_1 842 +MX53_PAD_PATA_BUFFER_EN__USBPHY2_DATAOUT_5 843 +MX53_PAD_PATA_INTRQ__PATA_INTRQ 844 +MX53_PAD_PATA_INTRQ__GPIO7_2 845 +MX53_PAD_PATA_INTRQ__UART2_CTS 846 +MX53_PAD_PATA_INTRQ__CAN1_TXCAN 847 +MX53_PAD_PATA_INTRQ__CCM_CCM_OUT_2 848 +MX53_PAD_PATA_INTRQ__USBPHY2_DATAOUT_6 849 +MX53_PAD_PATA_DIOR__PATA_DIOR 850 +MX53_PAD_PATA_DIOR__GPIO7_3 851 +MX53_PAD_PATA_DIOR__UART2_RTS 852 +MX53_PAD_PATA_DIOR__CAN1_RXCAN 853 +MX53_PAD_PATA_DIOR__USBPHY2_DATAOUT_7 854 +MX53_PAD_PATA_RESET_B__PATA_PATA_RESET_B 855 +MX53_PAD_PATA_RESET_B__GPIO7_4 856 +MX53_PAD_PATA_RESET_B__ESDHC3_CMD 857 +MX53_PAD_PATA_RESET_B__UART1_CTS 858 +MX53_PAD_PATA_RESET_B__CAN2_TXCAN 859 +MX53_PAD_PATA_RESET_B__USBPHY1_DATAOUT_0 860 +MX53_PAD_PATA_IORDY__PATA_IORDY 861 +MX53_PAD_PATA_IORDY__GPIO7_5 862 +MX53_PAD_PATA_IORDY__ESDHC3_CLK 863 +MX53_PAD_PATA_IORDY__UART1_RTS 864 +MX53_PAD_PATA_IORDY__CAN2_RXCAN 865 +MX53_PAD_PATA_IORDY__USBPHY1_DATAOUT_1 866 +MX53_PAD_PATA_DA_0__PATA_DA_0 867 +MX53_PAD_PATA_DA_0__GPIO7_6 868 +MX53_PAD_PATA_DA_0__ESDHC3_RST 869 +MX53_PAD_PATA_DA_0__OWIRE_LINE 870 +MX53_PAD_PATA_DA_0__USBPHY1_DATAOUT_2 871 +MX53_PAD_PATA_DA_1__PATA_DA_1 872 +MX53_PAD_PATA_DA_1__GPIO7_7 873 +MX53_PAD_PATA_DA_1__ESDHC4_CMD 874 +MX53_PAD_PATA_DA_1__UART3_CTS 875 +MX53_PAD_PATA_DA_1__USBPHY1_DATAOUT_3 876 +MX53_PAD_PATA_DA_2__PATA_DA_2 877 +MX53_PAD_PATA_DA_2__GPIO7_8 878 +MX53_PAD_PATA_DA_2__ESDHC4_CLK 879 +MX53_PAD_PATA_DA_2__UART3_RTS 880 +MX53_PAD_PATA_DA_2__USBPHY1_DATAOUT_4 881 +MX53_PAD_PATA_CS_0__PATA_CS_0 882 +MX53_PAD_PATA_CS_0__GPIO7_9 883 +MX53_PAD_PATA_CS_0__UART3_TXD_MUX 884 +MX53_PAD_PATA_CS_0__USBPHY1_DATAOUT_5 885 +MX53_PAD_PATA_CS_1__PATA_CS_1 886 +MX53_PAD_PATA_CS_1__GPIO7_10 887 +MX53_PAD_PATA_CS_1__UART3_RXD_MUX 888 +MX53_PAD_PATA_CS_1__USBPHY1_DATAOUT_6 889 +MX53_PAD_PATA_DATA0__PATA_DATA_0 890 +MX53_PAD_PATA_DATA0__GPIO2_0 891 +MX53_PAD_PATA_DATA0__EMI_NANDF_D_0 892 +MX53_PAD_PATA_DATA0__ESDHC3_DAT4 893 +MX53_PAD_PATA_DATA0__GPU3d_GPU_DEBUG_OUT_0 894 +MX53_PAD_PATA_DATA0__IPU_DIAG_BUS_0 895 +MX53_PAD_PATA_DATA0__USBPHY1_DATAOUT_7 896 +MX53_PAD_PATA_DATA1__PATA_DATA_1 897 +MX53_PAD_PATA_DATA1__GPIO2_1 898 +MX53_PAD_PATA_DATA1__EMI_NANDF_D_1 899 +MX53_PAD_PATA_DATA1__ESDHC3_DAT5 900 +MX53_PAD_PATA_DATA1__GPU3d_GPU_DEBUG_OUT_1 901 +MX53_PAD_PATA_DATA1__IPU_DIAG_BUS_1 902 +MX53_PAD_PATA_DATA2__PATA_DATA_2 903 +MX53_PAD_PATA_DATA2__GPIO2_2 904 +MX53_PAD_PATA_DATA2__EMI_NANDF_D_2 905 +MX53_PAD_PATA_DATA2__ESDHC3_DAT6 906 +MX53_PAD_PATA_DATA2__GPU3d_GPU_DEBUG_OUT_2 907 +MX53_PAD_PATA_DATA2__IPU_DIAG_BUS_2 908 +MX53_PAD_PATA_DATA3__PATA_DATA_3 909 +MX53_PAD_PATA_DATA3__GPIO2_3 910 +MX53_PAD_PATA_DATA3__EMI_NANDF_D_3 911 +MX53_PAD_PATA_DATA3__ESDHC3_DAT7 912 +MX53_PAD_PATA_DATA3__GPU3d_GPU_DEBUG_OUT_3 913 +MX53_PAD_PATA_DATA3__IPU_DIAG_BUS_3 914 +MX53_PAD_PATA_DATA4__PATA_DATA_4 915 +MX53_PAD_PATA_DATA4__GPIO2_4 916 +MX53_PAD_PATA_DATA4__EMI_NANDF_D_4 917 +MX53_PAD_PATA_DATA4__ESDHC4_DAT4 918 +MX53_PAD_PATA_DATA4__GPU3d_GPU_DEBUG_OUT_4 919 +MX53_PAD_PATA_DATA4__IPU_DIAG_BUS_4 920 +MX53_PAD_PATA_DATA5__PATA_DATA_5 921 +MX53_PAD_PATA_DATA5__GPIO2_5 922 +MX53_PAD_PATA_DATA5__EMI_NANDF_D_5 923 +MX53_PAD_PATA_DATA5__ESDHC4_DAT5 924 +MX53_PAD_PATA_DATA5__GPU3d_GPU_DEBUG_OUT_5 925 +MX53_PAD_PATA_DATA5__IPU_DIAG_BUS_5 926 +MX53_PAD_PATA_DATA6__PATA_DATA_6 927 +MX53_PAD_PATA_DATA6__GPIO2_6 928 +MX53_PAD_PATA_DATA6__EMI_NANDF_D_6 929 +MX53_PAD_PATA_DATA6__ESDHC4_DAT6 930 +MX53_PAD_PATA_DATA6__GPU3d_GPU_DEBUG_OUT_6 931 +MX53_PAD_PATA_DATA6__IPU_DIAG_BUS_6 932 +MX53_PAD_PATA_DATA7__PATA_DATA_7 933 +MX53_PAD_PATA_DATA7__GPIO2_7 934 +MX53_PAD_PATA_DATA7__EMI_NANDF_D_7 935 +MX53_PAD_PATA_DATA7__ESDHC4_DAT7 936 +MX53_PAD_PATA_DATA7__GPU3d_GPU_DEBUG_OUT_7 937 +MX53_PAD_PATA_DATA7__IPU_DIAG_BUS_7 938 +MX53_PAD_PATA_DATA8__PATA_DATA_8 939 +MX53_PAD_PATA_DATA8__GPIO2_8 940 +MX53_PAD_PATA_DATA8__ESDHC1_DAT4 941 +MX53_PAD_PATA_DATA8__EMI_NANDF_D_8 942 +MX53_PAD_PATA_DATA8__ESDHC3_DAT0 943 +MX53_PAD_PATA_DATA8__GPU3d_GPU_DEBUG_OUT_8 944 +MX53_PAD_PATA_DATA8__IPU_DIAG_BUS_8 945 +MX53_PAD_PATA_DATA9__PATA_DATA_9 946 +MX53_PAD_PATA_DATA9__GPIO2_9 947 +MX53_PAD_PATA_DATA9__ESDHC1_DAT5 948 +MX53_PAD_PATA_DATA9__EMI_NANDF_D_9 949 +MX53_PAD_PATA_DATA9__ESDHC3_DAT1 950 +MX53_PAD_PATA_DATA9__GPU3d_GPU_DEBUG_OUT_9 951 +MX53_PAD_PATA_DATA9__IPU_DIAG_BUS_9 952 +MX53_PAD_PATA_DATA10__PATA_DATA_10 953 +MX53_PAD_PATA_DATA10__GPIO2_10 954 +MX53_PAD_PATA_DATA10__ESDHC1_DAT6 955 +MX53_PAD_PATA_DATA10__EMI_NANDF_D_10 956 +MX53_PAD_PATA_DATA10__ESDHC3_DAT2 957 +MX53_PAD_PATA_DATA10__GPU3d_GPU_DEBUG_OUT_10 958 +MX53_PAD_PATA_DATA10__IPU_DIAG_BUS_10 959 +MX53_PAD_PATA_DATA11__PATA_DATA_11 960 +MX53_PAD_PATA_DATA11__GPIO2_11 961 +MX53_PAD_PATA_DATA11__ESDHC1_DAT7 962 +MX53_PAD_PATA_DATA11__EMI_NANDF_D_11 963 +MX53_PAD_PATA_DATA11__ESDHC3_DAT3 964 +MX53_PAD_PATA_DATA11__GPU3d_GPU_DEBUG_OUT_11 965 +MX53_PAD_PATA_DATA11__IPU_DIAG_BUS_11 966 +MX53_PAD_PATA_DATA12__PATA_DATA_12 967 +MX53_PAD_PATA_DATA12__GPIO2_12 968 +MX53_PAD_PATA_DATA12__ESDHC2_DAT4 969 +MX53_PAD_PATA_DATA12__EMI_NANDF_D_12 970 +MX53_PAD_PATA_DATA12__ESDHC4_DAT0 971 +MX53_PAD_PATA_DATA12__GPU3d_GPU_DEBUG_OUT_12 972 +MX53_PAD_PATA_DATA12__IPU_DIAG_BUS_12 973 +MX53_PAD_PATA_DATA13__PATA_DATA_13 974 +MX53_PAD_PATA_DATA13__GPIO2_13 975 +MX53_PAD_PATA_DATA13__ESDHC2_DAT5 976 +MX53_PAD_PATA_DATA13__EMI_NANDF_D_13 977 +MX53_PAD_PATA_DATA13__ESDHC4_DAT1 978 +MX53_PAD_PATA_DATA13__GPU3d_GPU_DEBUG_OUT_13 979 +MX53_PAD_PATA_DATA13__IPU_DIAG_BUS_13 980 +MX53_PAD_PATA_DATA14__PATA_DATA_14 981 +MX53_PAD_PATA_DATA14__GPIO2_14 982 +MX53_PAD_PATA_DATA14__ESDHC2_DAT6 983 +MX53_PAD_PATA_DATA14__EMI_NANDF_D_14 984 +MX53_PAD_PATA_DATA14__ESDHC4_DAT2 985 +MX53_PAD_PATA_DATA14__GPU3d_GPU_DEBUG_OUT_14 986 +MX53_PAD_PATA_DATA14__IPU_DIAG_BUS_14 987 +MX53_PAD_PATA_DATA15__PATA_DATA_15 988 +MX53_PAD_PATA_DATA15__GPIO2_15 989 +MX53_PAD_PATA_DATA15__ESDHC2_DAT7 990 +MX53_PAD_PATA_DATA15__EMI_NANDF_D_15 991 +MX53_PAD_PATA_DATA15__ESDHC4_DAT3 992 +MX53_PAD_PATA_DATA15__GPU3d_GPU_DEBUG_OUT_15 993 +MX53_PAD_PATA_DATA15__IPU_DIAG_BUS_15 994 +MX53_PAD_SD1_DATA0__ESDHC1_DAT0 995 +MX53_PAD_SD1_DATA0__GPIO1_16 996 +MX53_PAD_SD1_DATA0__GPT_CAPIN1 997 +MX53_PAD_SD1_DATA0__CSPI_MISO 998 +MX53_PAD_SD1_DATA0__CCM_PLL3_BYP 999 +MX53_PAD_SD1_DATA1__ESDHC1_DAT1 1000 +MX53_PAD_SD1_DATA1__GPIO1_17 1001 +MX53_PAD_SD1_DATA1__GPT_CAPIN2 1002 +MX53_PAD_SD1_DATA1__CSPI_SS0 1003 +MX53_PAD_SD1_DATA1__CCM_PLL4_BYP 1004 +MX53_PAD_SD1_CMD__ESDHC1_CMD 1005 +MX53_PAD_SD1_CMD__GPIO1_18 1006 +MX53_PAD_SD1_CMD__GPT_CMPOUT1 1007 +MX53_PAD_SD1_CMD__CSPI_MOSI 1008 +MX53_PAD_SD1_CMD__CCM_PLL1_BYP 1009 +MX53_PAD_SD1_DATA2__ESDHC1_DAT2 1010 +MX53_PAD_SD1_DATA2__GPIO1_19 1011 +MX53_PAD_SD1_DATA2__GPT_CMPOUT2 1012 +MX53_PAD_SD1_DATA2__PWM2_PWMO 1013 +MX53_PAD_SD1_DATA2__WDOG1_WDOG_B 1014 +MX53_PAD_SD1_DATA2__CSPI_SS1 1015 +MX53_PAD_SD1_DATA2__WDOG1_WDOG_RST_B_DEB 1016 +MX53_PAD_SD1_DATA2__CCM_PLL2_BYP 1017 +MX53_PAD_SD1_CLK__ESDHC1_CLK 1018 +MX53_PAD_SD1_CLK__GPIO1_20 1019 +MX53_PAD_SD1_CLK__OSC32k_32K_OUT 1020 +MX53_PAD_SD1_CLK__GPT_CLKIN 1021 +MX53_PAD_SD1_CLK__CSPI_SCLK 1022 +MX53_PAD_SD1_CLK__SATA_PHY_DTB_0 1023 +MX53_PAD_SD1_DATA3__ESDHC1_DAT3 1024 +MX53_PAD_SD1_DATA3__GPIO1_21 1025 +MX53_PAD_SD1_DATA3__GPT_CMPOUT3 1026 +MX53_PAD_SD1_DATA3__PWM1_PWMO 1027 +MX53_PAD_SD1_DATA3__WDOG2_WDOG_B 1028 +MX53_PAD_SD1_DATA3__CSPI_SS2 1029 +MX53_PAD_SD1_DATA3__WDOG2_WDOG_RST_B_DEB 1030 +MX53_PAD_SD1_DATA3__SATA_PHY_DTB_1 1031 +MX53_PAD_SD2_CLK__ESDHC2_CLK 1032 +MX53_PAD_SD2_CLK__GPIO1_10 1033 +MX53_PAD_SD2_CLK__KPP_COL_5 1034 +MX53_PAD_SD2_CLK__AUDMUX_AUD4_RXFS 1035 +MX53_PAD_SD2_CLK__CSPI_SCLK 1036 +MX53_PAD_SD2_CLK__SCC_RANDOM_V 1037 +MX53_PAD_SD2_CMD__ESDHC2_CMD 1038 +MX53_PAD_SD2_CMD__GPIO1_11 1039 +MX53_PAD_SD2_CMD__KPP_ROW_5 1040 +MX53_PAD_SD2_CMD__AUDMUX_AUD4_RXC 1041 +MX53_PAD_SD2_CMD__CSPI_MOSI 1042 +MX53_PAD_SD2_CMD__SCC_RANDOM 1043 +MX53_PAD_SD2_DATA3__ESDHC2_DAT3 1044 +MX53_PAD_SD2_DATA3__GPIO1_12 1045 +MX53_PAD_SD2_DATA3__KPP_COL_6 1046 +MX53_PAD_SD2_DATA3__AUDMUX_AUD4_TXC 1047 +MX53_PAD_SD2_DATA3__CSPI_SS2 1048 +MX53_PAD_SD2_DATA3__SJC_DONE 1049 +MX53_PAD_SD2_DATA2__ESDHC2_DAT2 1050 +MX53_PAD_SD2_DATA2__GPIO1_13 1051 +MX53_PAD_SD2_DATA2__KPP_ROW_6 1052 +MX53_PAD_SD2_DATA2__AUDMUX_AUD4_TXD 1053 +MX53_PAD_SD2_DATA2__CSPI_SS1 1054 +MX53_PAD_SD2_DATA2__SJC_FAIL 1055 +MX53_PAD_SD2_DATA1__ESDHC2_DAT1 1056 +MX53_PAD_SD2_DATA1__GPIO1_14 1057 +MX53_PAD_SD2_DATA1__KPP_COL_7 1058 +MX53_PAD_SD2_DATA1__AUDMUX_AUD4_TXFS 1059 +MX53_PAD_SD2_DATA1__CSPI_SS0 1060 +MX53_PAD_SD2_DATA1__RTIC_SEC_VIO 1061 +MX53_PAD_SD2_DATA0__ESDHC2_DAT0 1062 +MX53_PAD_SD2_DATA0__GPIO1_15 1063 +MX53_PAD_SD2_DATA0__KPP_ROW_7 1064 +MX53_PAD_SD2_DATA0__AUDMUX_AUD4_RXD 1065 +MX53_PAD_SD2_DATA0__CSPI_MISO 1066 +MX53_PAD_SD2_DATA0__RTIC_DONE_INT 1067 +MX53_PAD_GPIO_0__CCM_CLKO 1068 +MX53_PAD_GPIO_0__GPIO1_0 1069 +MX53_PAD_GPIO_0__KPP_COL_5 1070 +MX53_PAD_GPIO_0__CCM_SSI_EXT1_CLK 1071 +MX53_PAD_GPIO_0__EPIT1_EPITO 1072 +MX53_PAD_GPIO_0__SRTC_ALARM_DEB 1073 +MX53_PAD_GPIO_0__USBOH3_USBH1_PWR 1074 +MX53_PAD_GPIO_0__CSU_TD 1075 +MX53_PAD_GPIO_1__ESAI1_SCKR 1076 +MX53_PAD_GPIO_1__GPIO1_1 1077 +MX53_PAD_GPIO_1__KPP_ROW_5 1078 +MX53_PAD_GPIO_1__CCM_SSI_EXT2_CLK 1079 +MX53_PAD_GPIO_1__PWM2_PWMO 1080 +MX53_PAD_GPIO_1__WDOG2_WDOG_B 1081 +MX53_PAD_GPIO_1__ESDHC1_CD 1082 +MX53_PAD_GPIO_1__SRC_TESTER_ACK 1083 +MX53_PAD_GPIO_9__ESAI1_FSR 1084 +MX53_PAD_GPIO_9__GPIO1_9 1085 +MX53_PAD_GPIO_9__KPP_COL_6 1086 +MX53_PAD_GPIO_9__CCM_REF_EN_B 1087 +MX53_PAD_GPIO_9__PWM1_PWMO 1088 +MX53_PAD_GPIO_9__WDOG1_WDOG_B 1089 +MX53_PAD_GPIO_9__ESDHC1_WP 1090 +MX53_PAD_GPIO_9__SCC_FAIL_STATE 1091 +MX53_PAD_GPIO_3__ESAI1_HCKR 1092 +MX53_PAD_GPIO_3__GPIO1_3 1093 +MX53_PAD_GPIO_3__I2C3_SCL 1094 +MX53_PAD_GPIO_3__DPLLIP1_TOG_EN 1095 +MX53_PAD_GPIO_3__CCM_CLKO2 1096 +MX53_PAD_GPIO_3__OBSERVE_MUX_OBSRV_INT_OUT0 1097 +MX53_PAD_GPIO_3__USBOH3_USBH1_OC 1098 +MX53_PAD_GPIO_3__MLB_MLBCLK 1099 +MX53_PAD_GPIO_6__ESAI1_SCKT 1100 +MX53_PAD_GPIO_6__GPIO1_6 1101 +MX53_PAD_GPIO_6__I2C3_SDA 1102 +MX53_PAD_GPIO_6__CCM_CCM_OUT_0 1103 +MX53_PAD_GPIO_6__CSU_CSU_INT_DEB 1104 +MX53_PAD_GPIO_6__OBSERVE_MUX_OBSRV_INT_OUT1 1105 +MX53_PAD_GPIO_6__ESDHC2_LCTL 1106 +MX53_PAD_GPIO_6__MLB_MLBSIG 1107 +MX53_PAD_GPIO_2__ESAI1_FST 1108 +MX53_PAD_GPIO_2__GPIO1_2 1109 +MX53_PAD_GPIO_2__KPP_ROW_6 1110 +MX53_PAD_GPIO_2__CCM_CCM_OUT_1 1111 +MX53_PAD_GPIO_2__CSU_CSU_ALARM_AUT_0 1112 +MX53_PAD_GPIO_2__OBSERVE_MUX_OBSRV_INT_OUT2 1113 +MX53_PAD_GPIO_2__ESDHC2_WP 1114 +MX53_PAD_GPIO_2__MLB_MLBDAT 1115 +MX53_PAD_GPIO_4__ESAI1_HCKT 1116 +MX53_PAD_GPIO_4__GPIO1_4 1117 +MX53_PAD_GPIO_4__KPP_COL_7 1118 +MX53_PAD_GPIO_4__CCM_CCM_OUT_2 1119 +MX53_PAD_GPIO_4__CSU_CSU_ALARM_AUT_1 1120 +MX53_PAD_GPIO_4__OBSERVE_MUX_OBSRV_INT_OUT3 1121 +MX53_PAD_GPIO_4__ESDHC2_CD 1122 +MX53_PAD_GPIO_4__SCC_SEC_STATE 1123 +MX53_PAD_GPIO_5__ESAI1_TX2_RX3 1124 +MX53_PAD_GPIO_5__GPIO1_5 1125 +MX53_PAD_GPIO_5__KPP_ROW_7 1126 +MX53_PAD_GPIO_5__CCM_CLKO 1127 +MX53_PAD_GPIO_5__CSU_CSU_ALARM_AUT_2 1128 +MX53_PAD_GPIO_5__OBSERVE_MUX_OBSRV_INT_OUT4 1129 +MX53_PAD_GPIO_5__I2C3_SCL 1130 +MX53_PAD_GPIO_5__CCM_PLL1_BYP 1131 +MX53_PAD_GPIO_7__ESAI1_TX4_RX1 1132 +MX53_PAD_GPIO_7__GPIO1_7 1133 +MX53_PAD_GPIO_7__EPIT1_EPITO 1134 +MX53_PAD_GPIO_7__CAN1_TXCAN 1135 +MX53_PAD_GPIO_7__UART2_TXD_MUX 1136 +MX53_PAD_GPIO_7__FIRI_RXD 1137 +MX53_PAD_GPIO_7__SPDIF_PLOCK 1138 +MX53_PAD_GPIO_7__CCM_PLL2_BYP 1139 +MX53_PAD_GPIO_8__ESAI1_TX5_RX0 1140 +MX53_PAD_GPIO_8__GPIO1_8 1141 +MX53_PAD_GPIO_8__EPIT2_EPITO 1142 +MX53_PAD_GPIO_8__CAN1_RXCAN 1143 +MX53_PAD_GPIO_8__UART2_RXD_MUX 1144 +MX53_PAD_GPIO_8__FIRI_TXD 1145 +MX53_PAD_GPIO_8__SPDIF_SRCLK 1146 +MX53_PAD_GPIO_8__CCM_PLL3_BYP 1147 +MX53_PAD_GPIO_16__ESAI1_TX3_RX2 1148 +MX53_PAD_GPIO_16__GPIO7_11 1149 +MX53_PAD_GPIO_16__TZIC_PWRFAIL_INT 1150 +MX53_PAD_GPIO_16__RTC_CE_RTC_EXT_TRIG1 1151 +MX53_PAD_GPIO_16__SPDIF_IN1 1152 +MX53_PAD_GPIO_16__I2C3_SDA 1153 +MX53_PAD_GPIO_16__SJC_DE_B 1154 +MX53_PAD_GPIO_17__ESAI1_TX0 1155 +MX53_PAD_GPIO_17__GPIO7_12 1156 +MX53_PAD_GPIO_17__SDMA_EXT_EVENT_0 1157 +MX53_PAD_GPIO_17__GPC_PMIC_RDY 1158 +MX53_PAD_GPIO_17__RTC_CE_RTC_FSV_TRIG 1159 +MX53_PAD_GPIO_17__SPDIF_OUT1 1160 +MX53_PAD_GPIO_17__IPU_SNOOP2 1161 +MX53_PAD_GPIO_17__SJC_JTAG_ACT 1162 +MX53_PAD_GPIO_18__ESAI1_TX1 1163 +MX53_PAD_GPIO_18__GPIO7_13 1164 +MX53_PAD_GPIO_18__SDMA_EXT_EVENT_1 1165 +MX53_PAD_GPIO_18__OWIRE_LINE 1166 +MX53_PAD_GPIO_18__RTC_CE_RTC_ALARM2_TRIG 1167 +MX53_PAD_GPIO_18__CCM_ASRC_EXT_CLK 1168 +MX53_PAD_GPIO_18__ESDHC1_LCTL 1169 +MX53_PAD_GPIO_18__SRC_SYSTEM_RST 1170 diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt new file mode 100644 index 0000000..a4119f6 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt @@ -0,0 +1,1630 @@ +* Freescale IMX6Q IOMUX Controller + +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part +and usage. + +Required properties: +- compatible: "fsl,imx6q-iomuxc" +- fsl,pins: two integers array, represents a group of pins mux and config + setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is a + pin working on a specific function, CONFIG is the pad setting value like + pull-up for this pin. Please refer to imx6q datasheet for the valid pad + 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 (1 << 6) +PAD_CTL_SPEED_MED (2 << 6) +PAD_CTL_SPEED_HIGH (3 << 6) +PAD_CTL_DSE_DISABLE (0 << 3) +PAD_CTL_DSE_240ohm (1 << 3) +PAD_CTL_DSE_120ohm (2 << 3) +PAD_CTL_DSE_80ohm (3 << 3) +PAD_CTL_DSE_60ohm (4 << 3) +PAD_CTL_DSE_48ohm (5 << 3) +PAD_CTL_DSE_40ohm (6 << 3) +PAD_CTL_DSE_34ohm (7 << 3) +PAD_CTL_SRE_FAST (1 << 0) +PAD_CTL_SRE_SLOW (0 << 0) + +See below for available PIN_FUNC_ID for imx6q: +MX6Q_PAD_SD2_DAT1__USDHC2_DAT1 0 +MX6Q_PAD_SD2_DAT1__ECSPI5_SS0 1 +MX6Q_PAD_SD2_DAT1__WEIM_WEIM_CS_2 2 +MX6Q_PAD_SD2_DAT1__AUDMUX_AUD4_TXFS 3 +MX6Q_PAD_SD2_DAT1__KPP_COL_7 4 +MX6Q_PAD_SD2_DAT1__GPIO_1_14 5 +MX6Q_PAD_SD2_DAT1__CCM_WAIT 6 +MX6Q_PAD_SD2_DAT1__ANATOP_TESTO_0 7 +MX6Q_PAD_SD2_DAT2__USDHC2_DAT2 8 +MX6Q_PAD_SD2_DAT2__ECSPI5_SS1 9 +MX6Q_PAD_SD2_DAT2__WEIM_WEIM_CS_3 10 +MX6Q_PAD_SD2_DAT2__AUDMUX_AUD4_TXD 11 +MX6Q_PAD_SD2_DAT2__KPP_ROW_6 12 +MX6Q_PAD_SD2_DAT2__GPIO_1_13 13 +MX6Q_PAD_SD2_DAT2__CCM_STOP 14 +MX6Q_PAD_SD2_DAT2__ANATOP_TESTO_1 15 +MX6Q_PAD_SD2_DAT0__USDHC2_DAT0 16 +MX6Q_PAD_SD2_DAT0__ECSPI5_MISO 17 +MX6Q_PAD_SD2_DAT0__AUDMUX_AUD4_RXD 18 +MX6Q_PAD_SD2_DAT0__KPP_ROW_7 19 +MX6Q_PAD_SD2_DAT0__GPIO_1_15 20 +MX6Q_PAD_SD2_DAT0__DCIC2_DCIC_OUT 21 +MX6Q_PAD_SD2_DAT0__TESTO_2 22 +MX6Q_PAD_RGMII_TXC__USBOH3_H2_DATA 23 +MX6Q_PAD_RGMII_TXC__ENET_RGMII_TXC 24 +MX6Q_PAD_RGMII_TXC__SPDIF_SPDIF_EXTCLK 25 +MX6Q_PAD_RGMII_TXC__GPIO_6_19 26 +MX6Q_PAD_RGMII_TXC__MIPI_CORE_DPHY_IN_0 27 +MX6Q_PAD_RGMII_TXC__ANATOP_24M_OUT 28 +MX6Q_PAD_RGMII_TD0__MIPI_HSI_CRL_TX_RDY 29 +MX6Q_PAD_RGMII_TD0__ENET_RGMII_TD0 30 +MX6Q_PAD_RGMII_TD0__GPIO_6_20 31 +MX6Q_PAD_RGMII_TD0__MIPI_CORE_DPHY_IN_1 32 +MX6Q_PAD_RGMII_TD1__MIPI_HSI_CRL_RX_FLG 33 +MX6Q_PAD_RGMII_TD1__ENET_RGMII_TD1 34 +MX6Q_PAD_RGMII_TD1__GPIO_6_21 35 +MX6Q_PAD_RGMII_TD1__MIPI_CORE_DPHY_IN_2 36 +MX6Q_PAD_RGMII_TD1__CCM_PLL3_BYP 37 +MX6Q_PAD_RGMII_TD2__MIPI_HSI_CRL_RX_DTA 38 +MX6Q_PAD_RGMII_TD2__ENET_RGMII_TD2 39 +MX6Q_PAD_RGMII_TD2__GPIO_6_22 40 +MX6Q_PAD_RGMII_TD2__MIPI_CORE_DPHY_IN_3 41 +MX6Q_PAD_RGMII_TD2__CCM_PLL2_BYP 42 +MX6Q_PAD_RGMII_TD3__MIPI_HSI_CRL_RX_WAK 43 +MX6Q_PAD_RGMII_TD3__ENET_RGMII_TD3 44 +MX6Q_PAD_RGMII_TD3__GPIO_6_23 45 +MX6Q_PAD_RGMII_TD3__MIPI_CORE_DPHY_IN_4 46 +MX6Q_PAD_RGMII_RX_CTL__USBOH3_H3_DATA 47 +MX6Q_PAD_RGMII_RX_CTL__RGMII_RX_CTL 48 +MX6Q_PAD_RGMII_RX_CTL__GPIO_6_24 49 +MX6Q_PAD_RGMII_RX_CTL__MIPI_DPHY_IN_5 50 +MX6Q_PAD_RGMII_RD0__MIPI_HSI_CRL_RX_RDY 51 +MX6Q_PAD_RGMII_RD0__ENET_RGMII_RD0 52 +MX6Q_PAD_RGMII_RD0__GPIO_6_25 53 +MX6Q_PAD_RGMII_RD0__MIPI_CORE_DPHY_IN_6 54 +MX6Q_PAD_RGMII_TX_CTL__USBOH3_H2_STROBE 55 +MX6Q_PAD_RGMII_TX_CTL__RGMII_TX_CTL 56 +MX6Q_PAD_RGMII_TX_CTL__GPIO_6_26 57 +MX6Q_PAD_RGMII_TX_CTL__CORE_DPHY_IN_7 58 +MX6Q_PAD_RGMII_TX_CTL__ANATOP_REF_OUT 59 +MX6Q_PAD_RGMII_RD1__MIPI_HSI_CTRL_TX_FL 60 +MX6Q_PAD_RGMII_RD1__ENET_RGMII_RD1 61 +MX6Q_PAD_RGMII_RD1__GPIO_6_27 62 +MX6Q_PAD_RGMII_RD1__CORE_DPHY_TEST_IN_8 63 +MX6Q_PAD_RGMII_RD1__SJC_FAIL 64 +MX6Q_PAD_RGMII_RD2__MIPI_HSI_CRL_TX_DTA 65 +MX6Q_PAD_RGMII_RD2__ENET_RGMII_RD2 66 +MX6Q_PAD_RGMII_RD2__GPIO_6_28 67 +MX6Q_PAD_RGMII_RD2__MIPI_CORE_DPHY_IN_9 68 +MX6Q_PAD_RGMII_RD3__MIPI_HSI_CRL_TX_WAK 69 +MX6Q_PAD_RGMII_RD3__ENET_RGMII_RD3 70 +MX6Q_PAD_RGMII_RD3__GPIO_6_29 71 +MX6Q_PAD_RGMII_RD3__MIPI_CORE_DPHY_IN10 72 +MX6Q_PAD_RGMII_RXC__USBOH3_H3_STROBE 73 +MX6Q_PAD_RGMII_RXC__ENET_RGMII_RXC 74 +MX6Q_PAD_RGMII_RXC__GPIO_6_30 75 +MX6Q_PAD_RGMII_RXC__MIPI_CORE_DPHY_IN11 76 +MX6Q_PAD_EIM_A25__WEIM_WEIM_A_25 77 +MX6Q_PAD_EIM_A25__ECSPI4_SS1 78 +MX6Q_PAD_EIM_A25__ECSPI2_RDY 79 +MX6Q_PAD_EIM_A25__IPU1_DI1_PIN12 80 +MX6Q_PAD_EIM_A25__IPU1_DI0_D1_CS 81 +MX6Q_PAD_EIM_A25__GPIO_5_2 82 +MX6Q_PAD_EIM_A25__HDMI_TX_CEC_LINE 83 +MX6Q_PAD_EIM_A25__PL301_PER1_HBURST_0 84 +MX6Q_PAD_EIM_EB2__WEIM_WEIM_EB_2 85 +MX6Q_PAD_EIM_EB2__ECSPI1_SS0 86 +MX6Q_PAD_EIM_EB2__CCM_DI1_EXT_CLK 87 +MX6Q_PAD_EIM_EB2__IPU2_CSI1_D_19 88 +MX6Q_PAD_EIM_EB2__HDMI_TX_DDC_SCL 89 +MX6Q_PAD_EIM_EB2__GPIO_2_30 90 +MX6Q_PAD_EIM_EB2__I2C2_SCL 91 +MX6Q_PAD_EIM_EB2__SRC_BT_CFG_30 92 +MX6Q_PAD_EIM_D16__WEIM_WEIM_D_16 93 +MX6Q_PAD_EIM_D16__ECSPI1_SCLK 94 +MX6Q_PAD_EIM_D16__IPU1_DI0_PIN5 95 +MX6Q_PAD_EIM_D16__IPU2_CSI1_D_18 96 +MX6Q_PAD_EIM_D16__HDMI_TX_DDC_SDA 97 +MX6Q_PAD_EIM_D16__GPIO_3_16 98 +MX6Q_PAD_EIM_D16__I2C2_SDA 99 +MX6Q_PAD_EIM_D17__WEIM_WEIM_D_17 100 +MX6Q_PAD_EIM_D17__ECSPI1_MISO 101 +MX6Q_PAD_EIM_D17__IPU1_DI0_PIN6 102 +MX6Q_PAD_EIM_D17__IPU2_CSI1_PIXCLK 103 +MX6Q_PAD_EIM_D17__DCIC1_DCIC_OUT 104 +MX6Q_PAD_EIM_D17__GPIO_3_17 105 +MX6Q_PAD_EIM_D17__I2C3_SCL 106 +MX6Q_PAD_EIM_D17__PL301_PER1_HBURST_1 107 +MX6Q_PAD_EIM_D18__WEIM_WEIM_D_18 108 +MX6Q_PAD_EIM_D18__ECSPI1_MOSI 109 +MX6Q_PAD_EIM_D18__IPU1_DI0_PIN7 110 +MX6Q_PAD_EIM_D18__IPU2_CSI1_D_17 111 +MX6Q_PAD_EIM_D18__IPU1_DI1_D0_CS 112 +MX6Q_PAD_EIM_D18__GPIO_3_18 113 +MX6Q_PAD_EIM_D18__I2C3_SDA 114 +MX6Q_PAD_EIM_D18__PL301_PER1_HBURST_2 115 +MX6Q_PAD_EIM_D19__WEIM_WEIM_D_19 116 +MX6Q_PAD_EIM_D19__ECSPI1_SS1 117 +MX6Q_PAD_EIM_D19__IPU1_DI0_PIN8 118 +MX6Q_PAD_EIM_D19__IPU2_CSI1_D_16 119 +MX6Q_PAD_EIM_D19__UART1_CTS 120 +MX6Q_PAD_EIM_D19__GPIO_3_19 121 +MX6Q_PAD_EIM_D19__EPIT1_EPITO 122 +MX6Q_PAD_EIM_D19__PL301_PER1_HRESP 123 +MX6Q_PAD_EIM_D20__WEIM_WEIM_D_20 124 +MX6Q_PAD_EIM_D20__ECSPI4_SS0 125 +MX6Q_PAD_EIM_D20__IPU1_DI0_PIN16 126 +MX6Q_PAD_EIM_D20__IPU2_CSI1_D_15 127 +MX6Q_PAD_EIM_D20__UART1_RTS 128 +MX6Q_PAD_EIM_D20__GPIO_3_20 129 +MX6Q_PAD_EIM_D20__EPIT2_EPITO 130 +MX6Q_PAD_EIM_D21__WEIM_WEIM_D_21 131 +MX6Q_PAD_EIM_D21__ECSPI4_SCLK 132 +MX6Q_PAD_EIM_D21__IPU1_DI0_PIN17 133 +MX6Q_PAD_EIM_D21__IPU2_CSI1_D_11 134 +MX6Q_PAD_EIM_D21__USBOH3_USBOTG_OC 135 +MX6Q_PAD_EIM_D21__GPIO_3_21 136 +MX6Q_PAD_EIM_D21__I2C1_SCL 137 +MX6Q_PAD_EIM_D21__SPDIF_IN1 138 +MX6Q_PAD_EIM_D22__WEIM_WEIM_D_22 139 +MX6Q_PAD_EIM_D22__ECSPI4_MISO 140 +MX6Q_PAD_EIM_D22__IPU1_DI0_PIN1 141 +MX6Q_PAD_EIM_D22__IPU2_CSI1_D_10 142 +MX6Q_PAD_EIM_D22__USBOH3_USBOTG_PWR 143 +MX6Q_PAD_EIM_D22__GPIO_3_22 144 +MX6Q_PAD_EIM_D22__SPDIF_OUT1 145 +MX6Q_PAD_EIM_D22__PL301_PER1_HWRITE 146 +MX6Q_PAD_EIM_D23__WEIM_WEIM_D_23 147 +MX6Q_PAD_EIM_D23__IPU1_DI0_D0_CS 148 +MX6Q_PAD_EIM_D23__UART3_CTS 149 +MX6Q_PAD_EIM_D23__UART1_DCD 150 +MX6Q_PAD_EIM_D23__IPU2_CSI1_DATA_EN 151 +MX6Q_PAD_EIM_D23__GPIO_3_23 152 +MX6Q_PAD_EIM_D23__IPU1_DI1_PIN2 153 +MX6Q_PAD_EIM_D23__IPU1_DI1_PIN14 154 +MX6Q_PAD_EIM_EB3__WEIM_WEIM_EB_3 155 +MX6Q_PAD_EIM_EB3__ECSPI4_RDY 156 +MX6Q_PAD_EIM_EB3__UART3_RTS 157 +MX6Q_PAD_EIM_EB3__UART1_RI 158 +MX6Q_PAD_EIM_EB3__IPU2_CSI1_HSYNC 159 +MX6Q_PAD_EIM_EB3__GPIO_2_31 160 +MX6Q_PAD_EIM_EB3__IPU1_DI1_PIN3 161 +MX6Q_PAD_EIM_EB3__SRC_BT_CFG_31 162 +MX6Q_PAD_EIM_D24__WEIM_WEIM_D_24 163 +MX6Q_PAD_EIM_D24__ECSPI4_SS2 164 +MX6Q_PAD_EIM_D24__UART3_TXD 165 +MX6Q_PAD_EIM_D24__ECSPI1_SS2 166 +MX6Q_PAD_EIM_D24__ECSPI2_SS2 167 +MX6Q_PAD_EIM_D24__GPIO_3_24 168 +MX6Q_PAD_EIM_D24__AUDMUX_AUD5_RXFS 169 +MX6Q_PAD_EIM_D24__UART1_DTR 170 +MX6Q_PAD_EIM_D25__WEIM_WEIM_D_25 171 +MX6Q_PAD_EIM_D25__ECSPI4_SS3 172 +MX6Q_PAD_EIM_D25__UART3_RXD 173 +MX6Q_PAD_EIM_D25__ECSPI1_SS3 174 +MX6Q_PAD_EIM_D25__ECSPI2_SS3 175 +MX6Q_PAD_EIM_D25__GPIO_3_25 176 +MX6Q_PAD_EIM_D25__AUDMUX_AUD5_RXC 177 +MX6Q_PAD_EIM_D25__UART1_DSR 178 +MX6Q_PAD_EIM_D26__WEIM_WEIM_D_26 179 +MX6Q_PAD_EIM_D26__IPU1_DI1_PIN11 180 +MX6Q_PAD_EIM_D26__IPU1_CSI0_D_1 181 +MX6Q_PAD_EIM_D26__IPU2_CSI1_D_14 182 +MX6Q_PAD_EIM_D26__UART2_TXD 183 +MX6Q_PAD_EIM_D26__GPIO_3_26 184 +MX6Q_PAD_EIM_D26__IPU1_SISG_2 185 +MX6Q_PAD_EIM_D26__IPU1_DISP1_DAT_22 186 +MX6Q_PAD_EIM_D27__WEIM_WEIM_D_27 187 +MX6Q_PAD_EIM_D27__IPU1_DI1_PIN13 188 +MX6Q_PAD_EIM_D27__IPU1_CSI0_D_0 189 +MX6Q_PAD_EIM_D27__IPU2_CSI1_D_13 190 +MX6Q_PAD_EIM_D27__UART2_RXD 191 +MX6Q_PAD_EIM_D27__GPIO_3_27 192 +MX6Q_PAD_EIM_D27__IPU1_SISG_3 193 +MX6Q_PAD_EIM_D27__IPU1_DISP1_DAT_23 194 +MX6Q_PAD_EIM_D28__WEIM_WEIM_D_28 195 +MX6Q_PAD_EIM_D28__I2C1_SDA 196 +MX6Q_PAD_EIM_D28__ECSPI4_MOSI 197 +MX6Q_PAD_EIM_D28__IPU2_CSI1_D_12 198 +MX6Q_PAD_EIM_D28__UART2_CTS 199 +MX6Q_PAD_EIM_D28__GPIO_3_28 200 +MX6Q_PAD_EIM_D28__IPU1_EXT_TRIG 201 +MX6Q_PAD_EIM_D28__IPU1_DI0_PIN13 202 +MX6Q_PAD_EIM_D29__WEIM_WEIM_D_29 203 +MX6Q_PAD_EIM_D29__IPU1_DI1_PIN15 204 +MX6Q_PAD_EIM_D29__ECSPI4_SS0 205 +MX6Q_PAD_EIM_D29__UART2_RTS 206 +MX6Q_PAD_EIM_D29__GPIO_3_29 207 +MX6Q_PAD_EIM_D29__IPU2_CSI1_VSYNC 208 +MX6Q_PAD_EIM_D29__IPU1_DI0_PIN14 209 +MX6Q_PAD_EIM_D30__WEIM_WEIM_D_30 210 +MX6Q_PAD_EIM_D30__IPU1_DISP1_DAT_21 211 +MX6Q_PAD_EIM_D30__IPU1_DI0_PIN11 212 +MX6Q_PAD_EIM_D30__IPU1_CSI0_D_3 213 +MX6Q_PAD_EIM_D30__UART3_CTS 214 +MX6Q_PAD_EIM_D30__GPIO_3_30 215 +MX6Q_PAD_EIM_D30__USBOH3_USBH1_OC 216 +MX6Q_PAD_EIM_D30__PL301_PER1_HPROT_0 217 +MX6Q_PAD_EIM_D31__WEIM_WEIM_D_31 218 +MX6Q_PAD_EIM_D31__IPU1_DISP1_DAT_20 219 +MX6Q_PAD_EIM_D31__IPU1_DI0_PIN12 220 +MX6Q_PAD_EIM_D31__IPU1_CSI0_D_2 221 +MX6Q_PAD_EIM_D31__UART3_RTS 222 +MX6Q_PAD_EIM_D31__GPIO_3_31 223 +MX6Q_PAD_EIM_D31__USBOH3_USBH1_PWR 224 +MX6Q_PAD_EIM_D31__PL301_PER1_HPROT_1 225 +MX6Q_PAD_EIM_A24__WEIM_WEIM_A_24 226 +MX6Q_PAD_EIM_A24__IPU1_DISP1_DAT_19 227 +MX6Q_PAD_EIM_A24__IPU2_CSI1_D_19 228 +MX6Q_PAD_EIM_A24__IPU2_SISG_2 229 +MX6Q_PAD_EIM_A24__IPU1_SISG_2 230 +MX6Q_PAD_EIM_A24__GPIO_5_4 231 +MX6Q_PAD_EIM_A24__PL301_PER1_HPROT_2 232 +MX6Q_PAD_EIM_A24__SRC_BT_CFG_24 233 +MX6Q_PAD_EIM_A23__WEIM_WEIM_A_23 234 +MX6Q_PAD_EIM_A23__IPU1_DISP1_DAT_18 235 +MX6Q_PAD_EIM_A23__IPU2_CSI1_D_18 236 +MX6Q_PAD_EIM_A23__IPU2_SISG_3 237 +MX6Q_PAD_EIM_A23__IPU1_SISG_3 238 +MX6Q_PAD_EIM_A23__GPIO_6_6 239 +MX6Q_PAD_EIM_A23__PL301_PER1_HPROT_3 240 +MX6Q_PAD_EIM_A23__SRC_BT_CFG_23 241 +MX6Q_PAD_EIM_A22__WEIM_WEIM_A_22 242 +MX6Q_PAD_EIM_A22__IPU1_DISP1_DAT_17 243 +MX6Q_PAD_EIM_A22__IPU2_CSI1_D_17 244 +MX6Q_PAD_EIM_A22__GPIO_2_16 245 +MX6Q_PAD_EIM_A22__TPSMP_HDATA_0 246 +MX6Q_PAD_EIM_A22__SRC_BT_CFG_22 247 +MX6Q_PAD_EIM_A21__WEIM_WEIM_A_21 248 +MX6Q_PAD_EIM_A21__IPU1_DISP1_DAT_16 249 +MX6Q_PAD_EIM_A21__IPU2_CSI1_D_16 250 +MX6Q_PAD_EIM_A21__RESERVED_RESERVED 251 +MX6Q_PAD_EIM_A21__MIPI_CORE_DPHY_OUT_18 252 +MX6Q_PAD_EIM_A21__GPIO_2_17 253 +MX6Q_PAD_EIM_A21__TPSMP_HDATA_1 254 +MX6Q_PAD_EIM_A21__SRC_BT_CFG_21 255 +MX6Q_PAD_EIM_A20__WEIM_WEIM_A_20 256 +MX6Q_PAD_EIM_A20__IPU1_DISP1_DAT_15 257 +MX6Q_PAD_EIM_A20__IPU2_CSI1_D_15 258 +MX6Q_PAD_EIM_A20__RESERVED_RESERVED 259 +MX6Q_PAD_EIM_A20__MIPI_CORE_DPHY_OUT_19 260 +MX6Q_PAD_EIM_A20__GPIO_2_18 261 +MX6Q_PAD_EIM_A20__TPSMP_HDATA_2 262 +MX6Q_PAD_EIM_A20__SRC_BT_CFG_20 263 +MX6Q_PAD_EIM_A19__WEIM_WEIM_A_19 264 +MX6Q_PAD_EIM_A19__IPU1_DISP1_DAT_14 265 +MX6Q_PAD_EIM_A19__IPU2_CSI1_D_14 266 +MX6Q_PAD_EIM_A19__RESERVED_RESERVED 267 +MX6Q_PAD_EIM_A19__MIPI_CORE_DPHY_OUT_20 268 +MX6Q_PAD_EIM_A19__GPIO_2_19 269 +MX6Q_PAD_EIM_A19__TPSMP_HDATA_3 270 +MX6Q_PAD_EIM_A19__SRC_BT_CFG_19 271 +MX6Q_PAD_EIM_A18__WEIM_WEIM_A_18 272 +MX6Q_PAD_EIM_A18__IPU1_DISP1_DAT_13 273 +MX6Q_PAD_EIM_A18__IPU2_CSI1_D_13 274 +MX6Q_PAD_EIM_A18__RESERVED_RESERVED 275 +MX6Q_PAD_EIM_A18__MIPI_CORE_DPHY_OUT_21 276 +MX6Q_PAD_EIM_A18__GPIO_2_20 277 +MX6Q_PAD_EIM_A18__TPSMP_HDATA_4 278 +MX6Q_PAD_EIM_A18__SRC_BT_CFG_18 279 +MX6Q_PAD_EIM_A17__WEIM_WEIM_A_17 280 +MX6Q_PAD_EIM_A17__IPU1_DISP1_DAT_12 281 +MX6Q_PAD_EIM_A17__IPU2_CSI1_D_12 282 +MX6Q_PAD_EIM_A17__RESERVED_RESERVED 283 +MX6Q_PAD_EIM_A17__MIPI_CORE_DPHY_OUT_22 284 +MX6Q_PAD_EIM_A17__GPIO_2_21 285 +MX6Q_PAD_EIM_A17__TPSMP_HDATA_5 286 +MX6Q_PAD_EIM_A17__SRC_BT_CFG_17 287 +MX6Q_PAD_EIM_A16__WEIM_WEIM_A_16 288 +MX6Q_PAD_EIM_A16__IPU1_DI1_DISP_CLK 289 +MX6Q_PAD_EIM_A16__IPU2_CSI1_PIXCLK 290 +MX6Q_PAD_EIM_A16__MIPI_CORE_DPHY_OUT_23 291 +MX6Q_PAD_EIM_A16__GPIO_2_22 292 +MX6Q_PAD_EIM_A16__TPSMP_HDATA_6 293 +MX6Q_PAD_EIM_A16__SRC_BT_CFG_16 294 +MX6Q_PAD_EIM_CS0__WEIM_WEIM_CS_0 295 +MX6Q_PAD_EIM_CS0__IPU1_DI1_PIN5 296 +MX6Q_PAD_EIM_CS0__ECSPI2_SCLK 297 +MX6Q_PAD_EIM_CS0__MIPI_CORE_DPHY_OUT_24 298 +MX6Q_PAD_EIM_CS0__GPIO_2_23 299 +MX6Q_PAD_EIM_CS0__TPSMP_HDATA_7 300 +MX6Q_PAD_EIM_CS1__WEIM_WEIM_CS_1 301 +MX6Q_PAD_EIM_CS1__IPU1_DI1_PIN6 302 +MX6Q_PAD_EIM_CS1__ECSPI2_MOSI 303 +MX6Q_PAD_EIM_CS1__MIPI_CORE_DPHY_OUT_25 304 +MX6Q_PAD_EIM_CS1__GPIO_2_24 305 +MX6Q_PAD_EIM_CS1__TPSMP_HDATA_8 306 +MX6Q_PAD_EIM_OE__WEIM_WEIM_OE 307 +MX6Q_PAD_EIM_OE__IPU1_DI1_PIN7 308 +MX6Q_PAD_EIM_OE__ECSPI2_MISO 309 +MX6Q_PAD_EIM_OE__MIPI_CORE_DPHY_OUT_26 310 +MX6Q_PAD_EIM_OE__GPIO_2_25 311 +MX6Q_PAD_EIM_OE__TPSMP_HDATA_9 312 +MX6Q_PAD_EIM_RW__WEIM_WEIM_RW 313 +MX6Q_PAD_EIM_RW__IPU1_DI1_PIN8 314 +MX6Q_PAD_EIM_RW__ECSPI2_SS0 315 +MX6Q_PAD_EIM_RW__MIPI_CORE_DPHY_OUT_27 316 +MX6Q_PAD_EIM_RW__GPIO_2_26 317 +MX6Q_PAD_EIM_RW__TPSMP_HDATA_10 318 +MX6Q_PAD_EIM_RW__SRC_BT_CFG_29 319 +MX6Q_PAD_EIM_LBA__WEIM_WEIM_LBA 320 +MX6Q_PAD_EIM_LBA__IPU1_DI1_PIN17 321 +MX6Q_PAD_EIM_LBA__ECSPI2_SS1 322 +MX6Q_PAD_EIM_LBA__GPIO_2_27 323 +MX6Q_PAD_EIM_LBA__TPSMP_HDATA_11 324 +MX6Q_PAD_EIM_LBA__SRC_BT_CFG_26 325 +MX6Q_PAD_EIM_EB0__WEIM_WEIM_EB_0 326 +MX6Q_PAD_EIM_EB0__IPU1_DISP1_DAT_11 327 +MX6Q_PAD_EIM_EB0__IPU2_CSI1_D_11 328 +MX6Q_PAD_EIM_EB0__MIPI_CORE_DPHY_OUT_0 329 +MX6Q_PAD_EIM_EB0__CCM_PMIC_RDY 330 +MX6Q_PAD_EIM_EB0__GPIO_2_28 331 +MX6Q_PAD_EIM_EB0__TPSMP_HDATA_12 332 +MX6Q_PAD_EIM_EB0__SRC_BT_CFG_27 333 +MX6Q_PAD_EIM_EB1__WEIM_WEIM_EB_1 334 +MX6Q_PAD_EIM_EB1__IPU1_DISP1_DAT_10 335 +MX6Q_PAD_EIM_EB1__IPU2_CSI1_D_10 336 +MX6Q_PAD_EIM_EB1__MIPI_CORE_DPHY__OUT_1 337 +MX6Q_PAD_EIM_EB1__GPIO_2_29 338 +MX6Q_PAD_EIM_EB1__TPSMP_HDATA_13 339 +MX6Q_PAD_EIM_EB1__SRC_BT_CFG_28 340 +MX6Q_PAD_EIM_DA0__WEIM_WEIM_DA_A_0 341 +MX6Q_PAD_EIM_DA0__IPU1_DISP1_DAT_9 342 +MX6Q_PAD_EIM_DA0__IPU2_CSI1_D_9 343 +MX6Q_PAD_EIM_DA0__MIPI_CORE_DPHY__OUT_2 344 +MX6Q_PAD_EIM_DA0__GPIO_3_0 345 +MX6Q_PAD_EIM_DA0__TPSMP_HDATA_14 346 +MX6Q_PAD_EIM_DA0__SRC_BT_CFG_0 347 +MX6Q_PAD_EIM_DA1__WEIM_WEIM_DA_A_1 348 +MX6Q_PAD_EIM_DA1__IPU1_DISP1_DAT_8 349 +MX6Q_PAD_EIM_DA1__IPU2_CSI1_D_8 350 +MX6Q_PAD_EIM_DA1__MIPI_CORE_DPHY_OUT_3 351 +MX6Q_PAD_EIM_DA1__USBPHY1_TX_LS_MODE 352 +MX6Q_PAD_EIM_DA1__GPIO_3_1 353 +MX6Q_PAD_EIM_DA1__TPSMP_HDATA_15 354 +MX6Q_PAD_EIM_DA1__SRC_BT_CFG_1 355 +MX6Q_PAD_EIM_DA2__WEIM_WEIM_DA_A_2 356 +MX6Q_PAD_EIM_DA2__IPU1_DISP1_DAT_7 357 +MX6Q_PAD_EIM_DA2__IPU2_CSI1_D_7 358 +MX6Q_PAD_EIM_DA2__MIPI_CORE_DPHY_OUT_4 359 +MX6Q_PAD_EIM_DA2__USBPHY1_TX_HS_MODE 360 +MX6Q_PAD_EIM_DA2__GPIO_3_2 361 +MX6Q_PAD_EIM_DA2__TPSMP_HDATA_16 362 +MX6Q_PAD_EIM_DA2__SRC_BT_CFG_2 363 +MX6Q_PAD_EIM_DA3__WEIM_WEIM_DA_A_3 364 +MX6Q_PAD_EIM_DA3__IPU1_DISP1_DAT_6 365 +MX6Q_PAD_EIM_DA3__IPU2_CSI1_D_6 366 +MX6Q_PAD_EIM_DA3__MIPI_CORE_DPHY_OUT_5 367 +MX6Q_PAD_EIM_DA3__USBPHY1_TX_HIZ 368 +MX6Q_PAD_EIM_DA3__GPIO_3_3 369 +MX6Q_PAD_EIM_DA3__TPSMP_HDATA_17 370 +MX6Q_PAD_EIM_DA3__SRC_BT_CFG_3 371 +MX6Q_PAD_EIM_DA4__WEIM_WEIM_DA_A_4 372 +MX6Q_PAD_EIM_DA4__IPU1_DISP1_DAT_5 373 +MX6Q_PAD_EIM_DA4__IPU2_CSI1_D_5 374 +MX6Q_PAD_EIM_DA4__MIPI_CORE_DPHY_OUT_6 375 +MX6Q_PAD_EIM_DA4__ANATOP_USBPHY1_TX_EN 376 +MX6Q_PAD_EIM_DA4__GPIO_3_4 377 +MX6Q_PAD_EIM_DA4__TPSMP_HDATA_18 378 +MX6Q_PAD_EIM_DA4__SRC_BT_CFG_4 379 +MX6Q_PAD_EIM_DA5__WEIM_WEIM_DA_A_5 380 +MX6Q_PAD_EIM_DA5__IPU1_DISP1_DAT_4 381 +MX6Q_PAD_EIM_DA5__IPU2_CSI1_D_4 382 +MX6Q_PAD_EIM_DA5__MIPI_CORE_DPHY_OUT_7 383 +MX6Q_PAD_EIM_DA5__ANATOP_USBPHY1_TX_DP 384 +MX6Q_PAD_EIM_DA5__GPIO_3_5 385 +MX6Q_PAD_EIM_DA5__TPSMP_HDATA_19 386 +MX6Q_PAD_EIM_DA5__SRC_BT_CFG_5 387 +MX6Q_PAD_EIM_DA6__WEIM_WEIM_DA_A_6 388 +MX6Q_PAD_EIM_DA6__IPU1_DISP1_DAT_3 389 +MX6Q_PAD_EIM_DA6__IPU2_CSI1_D_3 390 +MX6Q_PAD_EIM_DA6__MIPI_CORE_DPHY_OUT_8 391 +MX6Q_PAD_EIM_DA6__ANATOP_USBPHY1_TX_DN 392 +MX6Q_PAD_EIM_DA6__GPIO_3_6 393 +MX6Q_PAD_EIM_DA6__TPSMP_HDATA_20 394 +MX6Q_PAD_EIM_DA6__SRC_BT_CFG_6 395 +MX6Q_PAD_EIM_DA7__WEIM_WEIM_DA_A_7 396 +MX6Q_PAD_EIM_DA7__IPU1_DISP1_DAT_2 397 +MX6Q_PAD_EIM_DA7__IPU2_CSI1_D_2 398 +MX6Q_PAD_EIM_DA7__MIPI_CORE_DPHY_OUT_9 399 +MX6Q_PAD_EIM_DA7__GPIO_3_7 400 +MX6Q_PAD_EIM_DA7__TPSMP_HDATA_21 401 +MX6Q_PAD_EIM_DA7__SRC_BT_CFG_7 402 +MX6Q_PAD_EIM_DA8__WEIM_WEIM_DA_A_8 403 +MX6Q_PAD_EIM_DA8__IPU1_DISP1_DAT_1 404 +MX6Q_PAD_EIM_DA8__IPU2_CSI1_D_1 405 +MX6Q_PAD_EIM_DA8__MIPI_CORE_DPHY_OUT_10 406 +MX6Q_PAD_EIM_DA8__GPIO_3_8 407 +MX6Q_PAD_EIM_DA8__TPSMP_HDATA_22 408 +MX6Q_PAD_EIM_DA8__SRC_BT_CFG_8 409 +MX6Q_PAD_EIM_DA9__WEIM_WEIM_DA_A_9 410 +MX6Q_PAD_EIM_DA9__IPU1_DISP1_DAT_0 411 +MX6Q_PAD_EIM_DA9__IPU2_CSI1_D_0 412 +MX6Q_PAD_EIM_DA9__MIPI_CORE_DPHY_OUT_11 413 +MX6Q_PAD_EIM_DA9__GPIO_3_9 414 +MX6Q_PAD_EIM_DA9__TPSMP_HDATA_23 415 +MX6Q_PAD_EIM_DA9__SRC_BT_CFG_9 416 +MX6Q_PAD_EIM_DA10__WEIM_WEIM_DA_A_10 417 +MX6Q_PAD_EIM_DA10__IPU1_DI1_PIN15 418 +MX6Q_PAD_EIM_DA10__IPU2_CSI1_DATA_EN 419 +MX6Q_PAD_EIM_DA10__MIPI_CORE_DPHY_OUT12 420 +MX6Q_PAD_EIM_DA10__GPIO_3_10 421 +MX6Q_PAD_EIM_DA10__TPSMP_HDATA_24 422 +MX6Q_PAD_EIM_DA10__SRC_BT_CFG_10 423 +MX6Q_PAD_EIM_DA11__WEIM_WEIM_DA_A_11 424 +MX6Q_PAD_EIM_DA11__IPU1_DI1_PIN2 425 +MX6Q_PAD_EIM_DA11__IPU2_CSI1_HSYNC 426 +MX6Q_PAD_EIM_DA11__MIPI_CORE_DPHY_OUT13 427 +MX6Q_PAD_EIM_DA11__SDMA_DBG_EVT_CHN_6 428 +MX6Q_PAD_EIM_DA11__GPIO_3_11 429 +MX6Q_PAD_EIM_DA11__TPSMP_HDATA_25 430 +MX6Q_PAD_EIM_DA11__SRC_BT_CFG_11 431 +MX6Q_PAD_EIM_DA12__WEIM_WEIM_DA_A_12 432 +MX6Q_PAD_EIM_DA12__IPU1_DI1_PIN3 433 +MX6Q_PAD_EIM_DA12__IPU2_CSI1_VSYNC 434 +MX6Q_PAD_EIM_DA12__MIPI_CORE_DPHY_OUT14 435 +MX6Q_PAD_EIM_DA12__SDMA_DEBUG_EVT_CHN_3 436 +MX6Q_PAD_EIM_DA12__GPIO_3_12 437 +MX6Q_PAD_EIM_DA12__TPSMP_HDATA_26 438 +MX6Q_PAD_EIM_DA12__SRC_BT_CFG_12 439 +MX6Q_PAD_EIM_DA13__WEIM_WEIM_DA_A_13 440 +MX6Q_PAD_EIM_DA13__IPU1_DI1_D0_CS 441 +MX6Q_PAD_EIM_DA13__CCM_DI1_EXT_CLK 442 +MX6Q_PAD_EIM_DA13__MIPI_CORE_DPHY_OUT15 443 +MX6Q_PAD_EIM_DA13__SDMA_DEBUG_EVT_CHN_4 444 +MX6Q_PAD_EIM_DA13__GPIO_3_13 445 +MX6Q_PAD_EIM_DA13__TPSMP_HDATA_27 446 +MX6Q_PAD_EIM_DA13__SRC_BT_CFG_13 447 +MX6Q_PAD_EIM_DA14__WEIM_WEIM_DA_A_14 448 +MX6Q_PAD_EIM_DA14__IPU1_DI1_D1_CS 449 +MX6Q_PAD_EIM_DA14__CCM_DI0_EXT_CLK 450 +MX6Q_PAD_EIM_DA14__MIPI_CORE_DPHY_OUT16 451 +MX6Q_PAD_EIM_DA14__SDMA_DEBUG_EVT_CHN_5 452 +MX6Q_PAD_EIM_DA14__GPIO_3_14 453 +MX6Q_PAD_EIM_DA14__TPSMP_HDATA_28 454 +MX6Q_PAD_EIM_DA14__SRC_BT_CFG_14 455 +MX6Q_PAD_EIM_DA15__WEIM_WEIM_DA_A_15 456 +MX6Q_PAD_EIM_DA15__IPU1_DI1_PIN1 457 +MX6Q_PAD_EIM_DA15__IPU1_DI1_PIN4 458 +MX6Q_PAD_EIM_DA15__MIPI_CORE_DPHY_OUT17 459 +MX6Q_PAD_EIM_DA15__GPIO_3_15 460 +MX6Q_PAD_EIM_DA15__TPSMP_HDATA_29 461 +MX6Q_PAD_EIM_DA15__SRC_BT_CFG_15 462 +MX6Q_PAD_EIM_WAIT__WEIM_WEIM_WAIT 463 +MX6Q_PAD_EIM_WAIT__WEIM_WEIM_DTACK_B 464 +MX6Q_PAD_EIM_WAIT__GPIO_5_0 465 +MX6Q_PAD_EIM_WAIT__TPSMP_HDATA_30 466 +MX6Q_PAD_EIM_WAIT__SRC_BT_CFG_25 467 +MX6Q_PAD_EIM_BCLK__WEIM_WEIM_BCLK 468 +MX6Q_PAD_EIM_BCLK__IPU1_DI1_PIN16 469 +MX6Q_PAD_EIM_BCLK__GPIO_6_31 470 +MX6Q_PAD_EIM_BCLK__TPSMP_HDATA_31 471 +MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DSP_CLK 472 +MX6Q_PAD_DI0_DISP_CLK__IPU2_DI0_DSP_CLK 473 +MX6Q_PAD_DI0_DISP_CLK__MIPI_CR_DPY_OT28 474 +MX6Q_PAD_DI0_DISP_CLK__SDMA_DBG_CR_STA0 475 +MX6Q_PAD_DI0_DISP_CLK__GPIO_4_16 476 +MX6Q_PAD_DI0_DISP_CLK__MMDC_DEBUG_0 477 +MX6Q_PAD_DI0_PIN15__IPU1_DI0_PIN15 478 +MX6Q_PAD_DI0_PIN15__IPU2_DI0_PIN15 479 +MX6Q_PAD_DI0_PIN15__AUDMUX_AUD6_TXC 480 +MX6Q_PAD_DI0_PIN15__MIPI_CR_DPHY_OUT_29 481 +MX6Q_PAD_DI0_PIN15__SDMA_DBG_CORE_STA_1 482 +MX6Q_PAD_DI0_PIN15__GPIO_4_17 483 +MX6Q_PAD_DI0_PIN15__MMDC_MMDC_DEBUG_1 484 +MX6Q_PAD_DI0_PIN2__IPU1_DI0_PIN2 485 +MX6Q_PAD_DI0_PIN2__IPU2_DI0_PIN2 486 +MX6Q_PAD_DI0_PIN2__AUDMUX_AUD6_TXD 487 +MX6Q_PAD_DI0_PIN2__MIPI_CR_DPHY_OUT_30 488 +MX6Q_PAD_DI0_PIN2__SDMA_DBG_CORE_STA_2 489 +MX6Q_PAD_DI0_PIN2__GPIO_4_18 490 +MX6Q_PAD_DI0_PIN2__MMDC_DEBUG_2 491 +MX6Q_PAD_DI0_PIN2__PL301_PER1_HADDR_9 492 +MX6Q_PAD_DI0_PIN3__IPU1_DI0_PIN3 493 +MX6Q_PAD_DI0_PIN3__IPU2_DI0_PIN3 494 +MX6Q_PAD_DI0_PIN3__AUDMUX_AUD6_TXFS 495 +MX6Q_PAD_DI0_PIN3__MIPI_CORE_DPHY_OUT31 496 +MX6Q_PAD_DI0_PIN3__SDMA_DBG_CORE_STA_3 497 +MX6Q_PAD_DI0_PIN3__GPIO_4_19 498 +MX6Q_PAD_DI0_PIN3__MMDC_MMDC_DEBUG_3 499 +MX6Q_PAD_DI0_PIN3__PL301_PER1_HADDR_10 500 +MX6Q_PAD_DI0_PIN4__IPU1_DI0_PIN4 501 +MX6Q_PAD_DI0_PIN4__IPU2_DI0_PIN4 502 +MX6Q_PAD_DI0_PIN4__AUDMUX_AUD6_RXD 503 +MX6Q_PAD_DI0_PIN4__USDHC1_WP 504 +MX6Q_PAD_DI0_PIN4__SDMA_DEBUG_YIELD 505 +MX6Q_PAD_DI0_PIN4__GPIO_4_20 506 +MX6Q_PAD_DI0_PIN4__MMDC_MMDC_DEBUG_4 507 +MX6Q_PAD_DI0_PIN4__PL301_PER1_HADDR_11 508 +MX6Q_PAD_DISP0_DAT0__IPU1_DISP0_DAT_0 509 +MX6Q_PAD_DISP0_DAT0__IPU2_DISP0_DAT_0 510 +MX6Q_PAD_DISP0_DAT0__ECSPI3_SCLK 511 +MX6Q_PAD_DISP0_DAT0__USDHC1_USDHC_DBG_0 512 +MX6Q_PAD_DISP0_DAT0__SDMA_DBG_CORE_RUN 513 +MX6Q_PAD_DISP0_DAT0__GPIO_4_21 514 +MX6Q_PAD_DISP0_DAT0__MMDC_MMDC_DEBUG_5 515 +MX6Q_PAD_DISP0_DAT1__IPU1_DISP0_DAT_1 516 +MX6Q_PAD_DISP0_DAT1__IPU2_DISP0_DAT_1 517 +MX6Q_PAD_DISP0_DAT1__ECSPI3_MOSI 518 +MX6Q_PAD_DISP0_DAT1__USDHC1_USDHC_DBG_1 519 +MX6Q_PAD_DISP0_DAT1__SDMA_DBG_EVT_CHNSL 520 +MX6Q_PAD_DISP0_DAT1__GPIO_4_22 521 +MX6Q_PAD_DISP0_DAT1__MMDC_DEBUG_6 522 +MX6Q_PAD_DISP0_DAT1__PL301_PER1_HADR_12 523 +MX6Q_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2 524 +MX6Q_PAD_DISP0_DAT2__IPU2_DISP0_DAT_2 525 +MX6Q_PAD_DISP0_DAT2__ECSPI3_MISO 526 +MX6Q_PAD_DISP0_DAT2__USDHC1_USDHC_DBG_2 527 +MX6Q_PAD_DISP0_DAT2__SDMA_DEBUG_MODE 528 +MX6Q_PAD_DISP0_DAT2__GPIO_4_23 529 +MX6Q_PAD_DISP0_DAT2__MMDC_DEBUG_7 530 +MX6Q_PAD_DISP0_DAT2__PL301_PER1_HADR_13 531 +MX6Q_PAD_DISP0_DAT3__IPU1_DISP0_DAT_3 532 +MX6Q_PAD_DISP0_DAT3__IPU2_DISP0_DAT_3 533 +MX6Q_PAD_DISP0_DAT3__ECSPI3_SS0 534 +MX6Q_PAD_DISP0_DAT3__USDHC1_USDHC_DBG_3 535 +MX6Q_PAD_DISP0_DAT3__SDMA_DBG_BUS_ERROR 536 +MX6Q_PAD_DISP0_DAT3__GPIO_4_24 537 +MX6Q_PAD_DISP0_DAT3__MMDC_MMDC_DBG_8 538 +MX6Q_PAD_DISP0_DAT3__PL301_PER1_HADR_14 539 +MX6Q_PAD_DISP0_DAT4__IPU1_DISP0_DAT_4 540 +MX6Q_PAD_DISP0_DAT4__IPU2_DISP0_DAT_4 541 +MX6Q_PAD_DISP0_DAT4__ECSPI3_SS1 542 +MX6Q_PAD_DISP0_DAT4__USDHC1_USDHC_DBG_4 543 +MX6Q_PAD_DISP0_DAT4__SDMA_DEBUG_BUS_RWB 544 +MX6Q_PAD_DISP0_DAT4__GPIO_4_25 545 +MX6Q_PAD_DISP0_DAT4__MMDC_MMDC_DEBUG_9 546 +MX6Q_PAD_DISP0_DAT4__PL301_PER1_HADR_15 547 +MX6Q_PAD_DISP0_DAT5__IPU1_DISP0_DAT_5 548 +MX6Q_PAD_DISP0_DAT5__IPU2_DISP0_DAT_5 549 +MX6Q_PAD_DISP0_DAT5__ECSPI3_SS2 550 +MX6Q_PAD_DISP0_DAT5__AUDMUX_AUD6_RXFS 551 +MX6Q_PAD_DISP0_DAT5__SDMA_DBG_MCH_DMBUS 552 +MX6Q_PAD_DISP0_DAT5__GPIO_4_26 553 +MX6Q_PAD_DISP0_DAT5__MMDC_DEBUG_10 554 +MX6Q_PAD_DISP0_DAT5__PL301_PER1_HADR_16 555 +MX6Q_PAD_DISP0_DAT6__IPU1_DISP0_DAT_6 556 +MX6Q_PAD_DISP0_DAT6__IPU2_DISP0_DAT_6 557 +MX6Q_PAD_DISP0_DAT6__ECSPI3_SS3 558 +MX6Q_PAD_DISP0_DAT6__AUDMUX_AUD6_RXC 559 +MX6Q_PAD_DISP0_DAT6__SDMA_DBG_RTBUF_WRT 560 +MX6Q_PAD_DISP0_DAT6__GPIO_4_27 561 +MX6Q_PAD_DISP0_DAT6__MMDC_DEBUG_11 562 +MX6Q_PAD_DISP0_DAT6__PL301_PER1_HADR_17 563 +MX6Q_PAD_DISP0_DAT7__IPU1_DISP0_DAT_7 564 +MX6Q_PAD_DISP0_DAT7__IPU2_DISP0_DAT_7 565 +MX6Q_PAD_DISP0_DAT7__ECSPI3_RDY 566 +MX6Q_PAD_DISP0_DAT7__USDHC1_USDHC_DBG_5 567 +MX6Q_PAD_DISP0_DAT7__SDMA_DBG_EVT_CHN_0 568 +MX6Q_PAD_DISP0_DAT7__GPIO_4_28 569 +MX6Q_PAD_DISP0_DAT7__MMDC_DEBUG_12 570 +MX6Q_PAD_DISP0_DAT7__PL301_PER1_HADR_18 571 +MX6Q_PAD_DISP0_DAT8__IPU1_DISP0_DAT_8 572 +MX6Q_PAD_DISP0_DAT8__IPU2_DISP0_DAT_8 573 +MX6Q_PAD_DISP0_DAT8__PWM1_PWMO 574 +MX6Q_PAD_DISP0_DAT8__WDOG1_WDOG_B 575 +MX6Q_PAD_DISP0_DAT8__SDMA_DBG_EVT_CHN_1 576 +MX6Q_PAD_DISP0_DAT8__GPIO_4_29 577 +MX6Q_PAD_DISP0_DAT8__MMDC_DEBUG_13 578 +MX6Q_PAD_DISP0_DAT8__PL301_PER1_HADR_19 579 +MX6Q_PAD_DISP0_DAT9__IPU1_DISP0_DAT_9 580 +MX6Q_PAD_DISP0_DAT9__IPU2_DISP0_DAT_9 581 +MX6Q_PAD_DISP0_DAT9__PWM2_PWMO 582 +MX6Q_PAD_DISP0_DAT9__WDOG2_WDOG_B 583 +MX6Q_PAD_DISP0_DAT9__SDMA_DBG_EVT_CHN_2 584 +MX6Q_PAD_DISP0_DAT9__GPIO_4_30 585 +MX6Q_PAD_DISP0_DAT9__MMDC_DEBUG_14 586 +MX6Q_PAD_DISP0_DAT9__PL301_PER1_HADR_20 587 +MX6Q_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10 588 +MX6Q_PAD_DISP0_DAT10__IPU2_DISP0_DAT_10 589 +MX6Q_PAD_DISP0_DAT10__USDHC1_DBG_6 590 +MX6Q_PAD_DISP0_DAT10__SDMA_DBG_EVT_CHN3 591 +MX6Q_PAD_DISP0_DAT10__GPIO_4_31 592 +MX6Q_PAD_DISP0_DAT10__MMDC_DEBUG_15 593 +MX6Q_PAD_DISP0_DAT10__PL301_PER1_HADR21 594 +MX6Q_PAD_DISP0_DAT11__IPU1_DISP0_DAT_11 595 +MX6Q_PAD_DISP0_DAT11__IPU2_DISP0_DAT_11 596 +MX6Q_PAD_DISP0_DAT11__USDHC1_USDHC_DBG7 597 +MX6Q_PAD_DISP0_DAT11__SDMA_DBG_EVT_CHN4 598 +MX6Q_PAD_DISP0_DAT11__GPIO_5_5 599 +MX6Q_PAD_DISP0_DAT11__MMDC_DEBUG_16 600 +MX6Q_PAD_DISP0_DAT11__PL301_PER1_HADR22 601 +MX6Q_PAD_DISP0_DAT12__IPU1_DISP0_DAT_12 602 +MX6Q_PAD_DISP0_DAT12__IPU2_DISP0_DAT_12 603 +MX6Q_PAD_DISP0_DAT12__RESERVED_RESERVED 604 +MX6Q_PAD_DISP0_DAT12__SDMA_DBG_EVT_CHN5 605 +MX6Q_PAD_DISP0_DAT12__GPIO_5_6 606 +MX6Q_PAD_DISP0_DAT12__MMDC_DEBUG_17 607 +MX6Q_PAD_DISP0_DAT12__PL301_PER1_HADR23 608 +MX6Q_PAD_DISP0_DAT13__IPU1_DISP0_DAT_13 609 +MX6Q_PAD_DISP0_DAT13__IPU2_DISP0_DAT_13 610 +MX6Q_PAD_DISP0_DAT13__AUDMUX_AUD5_RXFS 611 +MX6Q_PAD_DISP0_DAT13__SDMA_DBG_EVT_CHN0 612 +MX6Q_PAD_DISP0_DAT13__GPIO_5_7 613 +MX6Q_PAD_DISP0_DAT13__MMDC_DEBUG_18 614 +MX6Q_PAD_DISP0_DAT13__PL301_PER1_HADR24 615 +MX6Q_PAD_DISP0_DAT14__IPU1_DISP0_DAT_14 616 +MX6Q_PAD_DISP0_DAT14__IPU2_DISP0_DAT_14 617 +MX6Q_PAD_DISP0_DAT14__AUDMUX_AUD5_RXC 618 +MX6Q_PAD_DISP0_DAT14__SDMA_DBG_EVT_CHN1 619 +MX6Q_PAD_DISP0_DAT14__GPIO_5_8 620 +MX6Q_PAD_DISP0_DAT14__MMDC_DEBUG_19 621 +MX6Q_PAD_DISP0_DAT15__IPU1_DISP0_DAT_15 622 +MX6Q_PAD_DISP0_DAT15__IPU2_DISP0_DAT_15 623 +MX6Q_PAD_DISP0_DAT15__ECSPI1_SS1 624 +MX6Q_PAD_DISP0_DAT15__ECSPI2_SS1 625 +MX6Q_PAD_DISP0_DAT15__SDMA_DBG_EVT_CHN2 626 +MX6Q_PAD_DISP0_DAT15__GPIO_5_9 627 +MX6Q_PAD_DISP0_DAT15__MMDC_DEBUG_20 628 +MX6Q_PAD_DISP0_DAT15__PL301_PER1_HADR25 629 +MX6Q_PAD_DISP0_DAT16__IPU1_DISP0_DAT_16 630 +MX6Q_PAD_DISP0_DAT16__IPU2_DISP0_DAT_16 631 +MX6Q_PAD_DISP0_DAT16__ECSPI2_MOSI 632 +MX6Q_PAD_DISP0_DAT16__AUDMUX_AUD5_TXC 633 +MX6Q_PAD_DISP0_DAT16__SDMA_EXT_EVENT_0 634 +MX6Q_PAD_DISP0_DAT16__GPIO_5_10 635 +MX6Q_PAD_DISP0_DAT16__MMDC_DEBUG_21 636 +MX6Q_PAD_DISP0_DAT16__PL301_PER1_HADR26 637 +MX6Q_PAD_DISP0_DAT17__IPU1_DISP0_DAT_17 638 +MX6Q_PAD_DISP0_DAT17__IPU2_DISP0_DAT_17 639 +MX6Q_PAD_DISP0_DAT17__ECSPI2_MISO 640 +MX6Q_PAD_DISP0_DAT17__AUDMUX_AUD5_TXD 641 +MX6Q_PAD_DISP0_DAT17__SDMA_EXT_EVENT_1 642 +MX6Q_PAD_DISP0_DAT17__GPIO_5_11 643 +MX6Q_PAD_DISP0_DAT17__MMDC_DEBUG_22 644 +MX6Q_PAD_DISP0_DAT17__PL301_PER1_HADR27 645 +MX6Q_PAD_DISP0_DAT18__IPU1_DISP0_DAT_18 646 +MX6Q_PAD_DISP0_DAT18__IPU2_DISP0_DAT_18 647 +MX6Q_PAD_DISP0_DAT18__ECSPI2_SS0 648 +MX6Q_PAD_DISP0_DAT18__AUDMUX_AUD5_TXFS 649 +MX6Q_PAD_DISP0_DAT18__AUDMUX_AUD4_RXFS 650 +MX6Q_PAD_DISP0_DAT18__GPIO_5_12 651 +MX6Q_PAD_DISP0_DAT18__MMDC_DEBUG_23 652 +MX6Q_PAD_DISP0_DAT18__WEIM_WEIM_CS_2 653 +MX6Q_PAD_DISP0_DAT19__IPU1_DISP0_DAT_19 654 +MX6Q_PAD_DISP0_DAT19__IPU2_DISP0_DAT_19 655 +MX6Q_PAD_DISP0_DAT19__ECSPI2_SCLK 656 +MX6Q_PAD_DISP0_DAT19__AUDMUX_AUD5_RXD 657 +MX6Q_PAD_DISP0_DAT19__AUDMUX_AUD4_RXC 658 +MX6Q_PAD_DISP0_DAT19__GPIO_5_13 659 +MX6Q_PAD_DISP0_DAT19__MMDC_DEBUG_24 660 +MX6Q_PAD_DISP0_DAT19__WEIM_WEIM_CS_3 661 +MX6Q_PAD_DISP0_DAT20__IPU1_DISP0_DAT_20 662 +MX6Q_PAD_DISP0_DAT20__IPU2_DISP0_DAT_20 663 +MX6Q_PAD_DISP0_DAT20__ECSPI1_SCLK 664 +MX6Q_PAD_DISP0_DAT20__AUDMUX_AUD4_TXC 665 +MX6Q_PAD_DISP0_DAT20__SDMA_DBG_EVT_CHN7 666 +MX6Q_PAD_DISP0_DAT20__GPIO_5_14 667 +MX6Q_PAD_DISP0_DAT20__MMDC_DEBUG_25 668 +MX6Q_PAD_DISP0_DAT20__PL301_PER1_HADR28 669 +MX6Q_PAD_DISP0_DAT21__IPU1_DISP0_DAT_21 670 +MX6Q_PAD_DISP0_DAT21__IPU2_DISP0_DAT_21 671 +MX6Q_PAD_DISP0_DAT21__ECSPI1_MOSI 672 +MX6Q_PAD_DISP0_DAT21__AUDMUX_AUD4_TXD 673 +MX6Q_PAD_DISP0_DAT21__SDMA_DBG_BUS_DEV0 674 +MX6Q_PAD_DISP0_DAT21__GPIO_5_15 675 +MX6Q_PAD_DISP0_DAT21__MMDC_DEBUG_26 676 +MX6Q_PAD_DISP0_DAT21__PL301_PER1_HADR29 677 +MX6Q_PAD_DISP0_DAT22__IPU1_DISP0_DAT_22 678 +MX6Q_PAD_DISP0_DAT22__IPU2_DISP0_DAT_22 679 +MX6Q_PAD_DISP0_DAT22__ECSPI1_MISO 680 +MX6Q_PAD_DISP0_DAT22__AUDMUX_AUD4_TXFS 681 +MX6Q_PAD_DISP0_DAT22__SDMA_DBG_BUS_DEV1 682 +MX6Q_PAD_DISP0_DAT22__GPIO_5_16 683 +MX6Q_PAD_DISP0_DAT22__MMDC_DEBUG_27 684 +MX6Q_PAD_DISP0_DAT22__PL301_PER1_HADR30 685 +MX6Q_PAD_DISP0_DAT23__IPU1_DISP0_DAT_23 686 +MX6Q_PAD_DISP0_DAT23__IPU2_DISP0_DAT_23 687 +MX6Q_PAD_DISP0_DAT23__ECSPI1_SS0 688 +MX6Q_PAD_DISP0_DAT23__AUDMUX_AUD4_RXD 689 +MX6Q_PAD_DISP0_DAT23__SDMA_DBG_BUS_DEV2 690 +MX6Q_PAD_DISP0_DAT23__GPIO_5_17 691 +MX6Q_PAD_DISP0_DAT23__MMDC_DEBUG_28 692 +MX6Q_PAD_DISP0_DAT23__PL301_PER1_HADR31 693 +MX6Q_PAD_ENET_MDIO__RESERVED_RESERVED 694 +MX6Q_PAD_ENET_MDIO__ENET_MDIO 695 +MX6Q_PAD_ENET_MDIO__ESAI1_SCKR 696 +MX6Q_PAD_ENET_MDIO__SDMA_DEBUG_BUS_DEV3 697 +MX6Q_PAD_ENET_MDIO__ENET_1588_EVT1_OUT 698 +MX6Q_PAD_ENET_MDIO__GPIO_1_22 699 +MX6Q_PAD_ENET_MDIO__SPDIF_PLOCK 700 +MX6Q_PAD_ENET_REF_CLK__RESERVED_RSRVED 701 +MX6Q_PAD_ENET_REF_CLK__ENET_TX_CLK 702 +MX6Q_PAD_ENET_REF_CLK__ESAI1_FSR 703 +MX6Q_PAD_ENET_REF_CLK__SDMA_DBGBUS_DEV4 704 +MX6Q_PAD_ENET_REF_CLK__GPIO_1_23 705 +MX6Q_PAD_ENET_REF_CLK__SPDIF_SRCLK 706 +MX6Q_PAD_ENET_REF_CLK__USBPHY1_RX_SQH 707 +MX6Q_PAD_ENET_RX_ER__ENET_RX_ER 708 +MX6Q_PAD_ENET_RX_ER__ESAI1_HCKR 709 +MX6Q_PAD_ENET_RX_ER__SPDIF_IN1 710 +MX6Q_PAD_ENET_RX_ER__ENET_1588_EVT2_OUT 711 +MX6Q_PAD_ENET_RX_ER__GPIO_1_24 712 +MX6Q_PAD_ENET_RX_ER__PHY_TDI 713 +MX6Q_PAD_ENET_RX_ER__USBPHY1_RX_HS_RXD 714 +MX6Q_PAD_ENET_CRS_DV__RESERVED_RSRVED 715 +MX6Q_PAD_ENET_CRS_DV__ENET_RX_EN 716 +MX6Q_PAD_ENET_CRS_DV__ESAI1_SCKT 717 +MX6Q_PAD_ENET_CRS_DV__SPDIF_EXTCLK 718 +MX6Q_PAD_ENET_CRS_DV__GPIO_1_25 719 +MX6Q_PAD_ENET_CRS_DV__PHY_TDO 720 +MX6Q_PAD_ENET_CRS_DV__USBPHY1_RX_FS_RXD 721 +MX6Q_PAD_ENET_RXD1__MLB_MLBSIG 722 +MX6Q_PAD_ENET_RXD1__ENET_RDATA_1 723 +MX6Q_PAD_ENET_RXD1__ESAI1_FST 724 +MX6Q_PAD_ENET_RXD1__ENET_1588_EVT3_OUT 725 +MX6Q_PAD_ENET_RXD1__GPIO_1_26 726 +MX6Q_PAD_ENET_RXD1__PHY_TCK 727 +MX6Q_PAD_ENET_RXD1__USBPHY1_RX_DISCON 728 +MX6Q_PAD_ENET_RXD0__OSC32K_32K_OUT 729 +MX6Q_PAD_ENET_RXD0__ENET_RDATA_0 730 +MX6Q_PAD_ENET_RXD0__ESAI1_HCKT 731 +MX6Q_PAD_ENET_RXD0__SPDIF_OUT1 732 +MX6Q_PAD_ENET_RXD0__GPIO_1_27 733 +MX6Q_PAD_ENET_RXD0__PHY_TMS 734 +MX6Q_PAD_ENET_RXD0__USBPHY1_PLL_CK20DIV 735 +MX6Q_PAD_ENET_TX_EN__RESERVED_RSRVED 736 +MX6Q_PAD_ENET_TX_EN__ENET_TX_EN 737 +MX6Q_PAD_ENET_TX_EN__ESAI1_TX3_RX2 738 +MX6Q_PAD_ENET_TX_EN__GPIO_1_28 739 +MX6Q_PAD_ENET_TX_EN__SATA_PHY_TDI 740 +MX6Q_PAD_ENET_TX_EN__USBPHY2_RX_SQH 741 +MX6Q_PAD_ENET_TXD1__MLB_MLBCLK 742 +MX6Q_PAD_ENET_TXD1__ENET_TDATA_1 743 +MX6Q_PAD_ENET_TXD1__ESAI1_TX2_RX3 744 +MX6Q_PAD_ENET_TXD1__ENET_1588_EVENT0_IN 745 +MX6Q_PAD_ENET_TXD1__GPIO_1_29 746 +MX6Q_PAD_ENET_TXD1__SATA_PHY_TDO 747 +MX6Q_PAD_ENET_TXD1__USBPHY2_RX_HS_RXD 748 +MX6Q_PAD_ENET_TXD0__RESERVED_RSRVED 749 +MX6Q_PAD_ENET_TXD0__ENET_TDATA_0 750 +MX6Q_PAD_ENET_TXD0__ESAI1_TX4_RX1 751 +MX6Q_PAD_ENET_TXD0__GPIO_1_30 752 +MX6Q_PAD_ENET_TXD0__SATA_PHY_TCK 753 +MX6Q_PAD_ENET_TXD0__USBPHY2_RX_FS_RXD 754 +MX6Q_PAD_ENET_MDC__MLB_MLBDAT 755 +MX6Q_PAD_ENET_MDC__ENET_MDC 756 +MX6Q_PAD_ENET_MDC__ESAI1_TX5_RX0 757 +MX6Q_PAD_ENET_MDC__ENET_1588_EVENT1_IN 758 +MX6Q_PAD_ENET_MDC__GPIO_1_31 759 +MX6Q_PAD_ENET_MDC__SATA_PHY_TMS 760 +MX6Q_PAD_ENET_MDC__USBPHY2_RX_DISCON 761 +MX6Q_PAD_DRAM_D40__MMDC_DRAM_D_40 762 +MX6Q_PAD_DRAM_D41__MMDC_DRAM_D_41 763 +MX6Q_PAD_DRAM_D42__MMDC_DRAM_D_42 764 +MX6Q_PAD_DRAM_D43__MMDC_DRAM_D_43 765 +MX6Q_PAD_DRAM_D44__MMDC_DRAM_D_44 766 +MX6Q_PAD_DRAM_D45__MMDC_DRAM_D_45 767 +MX6Q_PAD_DRAM_D46__MMDC_DRAM_D_46 768 +MX6Q_PAD_DRAM_D47__MMDC_DRAM_D_47 769 +MX6Q_PAD_DRAM_SDQS5__MMDC_DRAM_SDQS_5 770 +MX6Q_PAD_DRAM_DQM5__MMDC_DRAM_DQM_5 771 +MX6Q_PAD_DRAM_D32__MMDC_DRAM_D_32 772 +MX6Q_PAD_DRAM_D33__MMDC_DRAM_D_33 773 +MX6Q_PAD_DRAM_D34__MMDC_DRAM_D_34 774 +MX6Q_PAD_DRAM_D35__MMDC_DRAM_D_35 775 +MX6Q_PAD_DRAM_D36__MMDC_DRAM_D_36 776 +MX6Q_PAD_DRAM_D37__MMDC_DRAM_D_37 777 +MX6Q_PAD_DRAM_D38__MMDC_DRAM_D_38 778 +MX6Q_PAD_DRAM_D39__MMDC_DRAM_D_39 779 +MX6Q_PAD_DRAM_DQM4__MMDC_DRAM_DQM_4 780 +MX6Q_PAD_DRAM_SDQS4__MMDC_DRAM_SDQS_4 781 +MX6Q_PAD_DRAM_D24__MMDC_DRAM_D_24 782 +MX6Q_PAD_DRAM_D25__MMDC_DRAM_D_25 783 +MX6Q_PAD_DRAM_D26__MMDC_DRAM_D_26 784 +MX6Q_PAD_DRAM_D27__MMDC_DRAM_D_27 785 +MX6Q_PAD_DRAM_D28__MMDC_DRAM_D_28 786 +MX6Q_PAD_DRAM_D29__MMDC_DRAM_D_29 787 +MX6Q_PAD_DRAM_SDQS3__MMDC_DRAM_SDQS_3 788 +MX6Q_PAD_DRAM_D30__MMDC_DRAM_D_30 789 +MX6Q_PAD_DRAM_D31__MMDC_DRAM_D_31 790 +MX6Q_PAD_DRAM_DQM3__MMDC_DRAM_DQM_3 791 +MX6Q_PAD_DRAM_D16__MMDC_DRAM_D_16 792 +MX6Q_PAD_DRAM_D17__MMDC_DRAM_D_17 793 +MX6Q_PAD_DRAM_D18__MMDC_DRAM_D_18 794 +MX6Q_PAD_DRAM_D19__MMDC_DRAM_D_19 795 +MX6Q_PAD_DRAM_D20__MMDC_DRAM_D_20 796 +MX6Q_PAD_DRAM_D21__MMDC_DRAM_D_21 797 +MX6Q_PAD_DRAM_D22__MMDC_DRAM_D_22 798 +MX6Q_PAD_DRAM_SDQS2__MMDC_DRAM_SDQS_2 799 +MX6Q_PAD_DRAM_D23__MMDC_DRAM_D_23 800 +MX6Q_PAD_DRAM_DQM2__MMDC_DRAM_DQM_2 801 +MX6Q_PAD_DRAM_A0__MMDC_DRAM_A_0 802 +MX6Q_PAD_DRAM_A1__MMDC_DRAM_A_1 803 +MX6Q_PAD_DRAM_A2__MMDC_DRAM_A_2 804 +MX6Q_PAD_DRAM_A3__MMDC_DRAM_A_3 805 +MX6Q_PAD_DRAM_A4__MMDC_DRAM_A_4 806 +MX6Q_PAD_DRAM_A5__MMDC_DRAM_A_5 807 +MX6Q_PAD_DRAM_A6__MMDC_DRAM_A_6 808 +MX6Q_PAD_DRAM_A7__MMDC_DRAM_A_7 809 +MX6Q_PAD_DRAM_A8__MMDC_DRAM_A_8 810 +MX6Q_PAD_DRAM_A9__MMDC_DRAM_A_9 811 +MX6Q_PAD_DRAM_A10__MMDC_DRAM_A_10 812 +MX6Q_PAD_DRAM_A11__MMDC_DRAM_A_11 813 +MX6Q_PAD_DRAM_A12__MMDC_DRAM_A_12 814 +MX6Q_PAD_DRAM_A13__MMDC_DRAM_A_13 815 +MX6Q_PAD_DRAM_A14__MMDC_DRAM_A_14 816 +MX6Q_PAD_DRAM_A15__MMDC_DRAM_A_15 817 +MX6Q_PAD_DRAM_CAS__MMDC_DRAM_CAS 818 +MX6Q_PAD_DRAM_CS0__MMDC_DRAM_CS_0 819 +MX6Q_PAD_DRAM_CS1__MMDC_DRAM_CS_1 820 +MX6Q_PAD_DRAM_RAS__MMDC_DRAM_RAS 821 +MX6Q_PAD_DRAM_RESET__MMDC_DRAM_RESET 822 +MX6Q_PAD_DRAM_SDBA0__MMDC_DRAM_SDBA_0 823 +MX6Q_PAD_DRAM_SDBA1__MMDC_DRAM_SDBA_1 824 +MX6Q_PAD_DRAM_SDCLK_0__MMDC_DRAM_SDCLK0 825 +MX6Q_PAD_DRAM_SDBA2__MMDC_DRAM_SDBA_2 826 +MX6Q_PAD_DRAM_SDCKE0__MMDC_DRAM_SDCKE_0 827 +MX6Q_PAD_DRAM_SDCLK_1__MMDC_DRAM_SDCLK1 828 +MX6Q_PAD_DRAM_SDCKE1__MMDC_DRAM_SDCKE_1 829 +MX6Q_PAD_DRAM_SDODT0__MMDC_DRAM_ODT_0 830 +MX6Q_PAD_DRAM_SDODT1__MMDC_DRAM_ODT_1 831 +MX6Q_PAD_DRAM_SDWE__MMDC_DRAM_SDWE 832 +MX6Q_PAD_DRAM_D0__MMDC_DRAM_D_0 833 +MX6Q_PAD_DRAM_D1__MMDC_DRAM_D_1 834 +MX6Q_PAD_DRAM_D2__MMDC_DRAM_D_2 835 +MX6Q_PAD_DRAM_D3__MMDC_DRAM_D_3 836 +MX6Q_PAD_DRAM_D4__MMDC_DRAM_D_4 837 +MX6Q_PAD_DRAM_D5__MMDC_DRAM_D_5 838 +MX6Q_PAD_DRAM_SDQS0__MMDC_DRAM_SDQS_0 839 +MX6Q_PAD_DRAM_D6__MMDC_DRAM_D_6 840 +MX6Q_PAD_DRAM_D7__MMDC_DRAM_D_7 841 +MX6Q_PAD_DRAM_DQM0__MMDC_DRAM_DQM_0 842 +MX6Q_PAD_DRAM_D8__MMDC_DRAM_D_8 843 +MX6Q_PAD_DRAM_D9__MMDC_DRAM_D_9 844 +MX6Q_PAD_DRAM_D10__MMDC_DRAM_D_10 845 +MX6Q_PAD_DRAM_D11__MMDC_DRAM_D_11 846 +MX6Q_PAD_DRAM_D12__MMDC_DRAM_D_12 847 +MX6Q_PAD_DRAM_D13__MMDC_DRAM_D_13 848 +MX6Q_PAD_DRAM_D14__MMDC_DRAM_D_14 849 +MX6Q_PAD_DRAM_SDQS1__MMDC_DRAM_SDQS_1 850 +MX6Q_PAD_DRAM_D15__MMDC_DRAM_D_15 851 +MX6Q_PAD_DRAM_DQM1__MMDC_DRAM_DQM_1 852 +MX6Q_PAD_DRAM_D48__MMDC_DRAM_D_48 853 +MX6Q_PAD_DRAM_D49__MMDC_DRAM_D_49 854 +MX6Q_PAD_DRAM_D50__MMDC_DRAM_D_50 855 +MX6Q_PAD_DRAM_D51__MMDC_DRAM_D_51 856 +MX6Q_PAD_DRAM_D52__MMDC_DRAM_D_52 857 +MX6Q_PAD_DRAM_D53__MMDC_DRAM_D_53 858 +MX6Q_PAD_DRAM_D54__MMDC_DRAM_D_54 859 +MX6Q_PAD_DRAM_D55__MMDC_DRAM_D_55 860 +MX6Q_PAD_DRAM_SDQS6__MMDC_DRAM_SDQS_6 861 +MX6Q_PAD_DRAM_DQM6__MMDC_DRAM_DQM_6 862 +MX6Q_PAD_DRAM_D56__MMDC_DRAM_D_56 863 +MX6Q_PAD_DRAM_SDQS7__MMDC_DRAM_SDQS_7 864 +MX6Q_PAD_DRAM_D57__MMDC_DRAM_D_57 865 +MX6Q_PAD_DRAM_D58__MMDC_DRAM_D_58 866 +MX6Q_PAD_DRAM_D59__MMDC_DRAM_D_59 867 +MX6Q_PAD_DRAM_D60__MMDC_DRAM_D_60 868 +MX6Q_PAD_DRAM_DQM7__MMDC_DRAM_DQM_7 869 +MX6Q_PAD_DRAM_D61__MMDC_DRAM_D_61 870 +MX6Q_PAD_DRAM_D62__MMDC_DRAM_D_62 871 +MX6Q_PAD_DRAM_D63__MMDC_DRAM_D_63 872 +MX6Q_PAD_KEY_COL0__ECSPI1_SCLK 873 +MX6Q_PAD_KEY_COL0__ENET_RDATA_3 874 +MX6Q_PAD_KEY_COL0__AUDMUX_AUD5_TXC 875 +MX6Q_PAD_KEY_COL0__KPP_COL_0 876 +MX6Q_PAD_KEY_COL0__UART4_TXD 877 +MX6Q_PAD_KEY_COL0__GPIO_4_6 878 +MX6Q_PAD_KEY_COL0__DCIC1_DCIC_OUT 879 +MX6Q_PAD_KEY_COL0__SRC_ANY_PU_RST 880 +MX6Q_PAD_KEY_ROW0__ECSPI1_MOSI 881 +MX6Q_PAD_KEY_ROW0__ENET_TDATA_3 882 +MX6Q_PAD_KEY_ROW0__AUDMUX_AUD5_TXD 883 +MX6Q_PAD_KEY_ROW0__KPP_ROW_0 884 +MX6Q_PAD_KEY_ROW0__UART4_RXD 885 +MX6Q_PAD_KEY_ROW0__GPIO_4_7 886 +MX6Q_PAD_KEY_ROW0__DCIC2_DCIC_OUT 887 +MX6Q_PAD_KEY_ROW0__PL301_PER1_HADR_0 888 +MX6Q_PAD_KEY_COL1__ECSPI1_MISO 889 +MX6Q_PAD_KEY_COL1__ENET_MDIO 890 +MX6Q_PAD_KEY_COL1__AUDMUX_AUD5_TXFS 891 +MX6Q_PAD_KEY_COL1__KPP_COL_1 892 +MX6Q_PAD_KEY_COL1__UART5_TXD 893 +MX6Q_PAD_KEY_COL1__GPIO_4_8 894 +MX6Q_PAD_KEY_COL1__USDHC1_VSELECT 895 +MX6Q_PAD_KEY_COL1__PL301MX_PER1_HADR_1 896 +MX6Q_PAD_KEY_ROW1__ECSPI1_SS0 897 +MX6Q_PAD_KEY_ROW1__ENET_COL 898 +MX6Q_PAD_KEY_ROW1__AUDMUX_AUD5_RXD 899 +MX6Q_PAD_KEY_ROW1__KPP_ROW_1 900 +MX6Q_PAD_KEY_ROW1__UART5_RXD 901 +MX6Q_PAD_KEY_ROW1__GPIO_4_9 902 +MX6Q_PAD_KEY_ROW1__USDHC2_VSELECT 903 +MX6Q_PAD_KEY_ROW1__PL301_PER1_HADDR_2 904 +MX6Q_PAD_KEY_COL2__ECSPI1_SS1 905 +MX6Q_PAD_KEY_COL2__ENET_RDATA_2 906 +MX6Q_PAD_KEY_COL2__CAN1_TXCAN 907 +MX6Q_PAD_KEY_COL2__KPP_COL_2 908 +MX6Q_PAD_KEY_COL2__ENET_MDC 909 +MX6Q_PAD_KEY_COL2__GPIO_4_10 910 +MX6Q_PAD_KEY_COL2__USBOH3_H1_PWRCTL_WKP 911 +MX6Q_PAD_KEY_COL2__PL301_PER1_HADDR_3 912 +MX6Q_PAD_KEY_ROW2__ECSPI1_SS2 913 +MX6Q_PAD_KEY_ROW2__ENET_TDATA_2 914 +MX6Q_PAD_KEY_ROW2__CAN1_RXCAN 915 +MX6Q_PAD_KEY_ROW2__KPP_ROW_2 916 +MX6Q_PAD_KEY_ROW2__USDHC2_VSELECT 917 +MX6Q_PAD_KEY_ROW2__GPIO_4_11 918 +MX6Q_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 919 +MX6Q_PAD_KEY_ROW2__PL301_PER1_HADR_4 920 +MX6Q_PAD_KEY_COL3__ECSPI1_SS3 921 +MX6Q_PAD_KEY_COL3__ENET_CRS 922 +MX6Q_PAD_KEY_COL3__HDMI_TX_DDC_SCL 923 +MX6Q_PAD_KEY_COL3__KPP_COL_3 924 +MX6Q_PAD_KEY_COL3__I2C2_SCL 925 +MX6Q_PAD_KEY_COL3__GPIO_4_12 926 +MX6Q_PAD_KEY_COL3__SPDIF_IN1 927 +MX6Q_PAD_KEY_COL3__PL301_PER1_HADR_5 928 +MX6Q_PAD_KEY_ROW3__OSC32K_32K_OUT 929 +MX6Q_PAD_KEY_ROW3__ASRC_ASRC_EXT_CLK 930 +MX6Q_PAD_KEY_ROW3__HDMI_TX_DDC_SDA 931 +MX6Q_PAD_KEY_ROW3__KPP_ROW_3 932 +MX6Q_PAD_KEY_ROW3__I2C2_SDA 933 +MX6Q_PAD_KEY_ROW3__GPIO_4_13 934 +MX6Q_PAD_KEY_ROW3__USDHC1_VSELECT 935 +MX6Q_PAD_KEY_ROW3__PL301_PER1_HADR_6 936 +MX6Q_PAD_KEY_COL4__CAN2_TXCAN 937 +MX6Q_PAD_KEY_COL4__IPU1_SISG_4 938 +MX6Q_PAD_KEY_COL4__USBOH3_USBOTG_OC 939 +MX6Q_PAD_KEY_COL4__KPP_COL_4 940 +MX6Q_PAD_KEY_COL4__UART5_RTS 941 +MX6Q_PAD_KEY_COL4__GPIO_4_14 942 +MX6Q_PAD_KEY_COL4__MMDC_DEBUG_49 943 +MX6Q_PAD_KEY_COL4__PL301_PER1_HADDR_7 944 +MX6Q_PAD_KEY_ROW4__CAN2_RXCAN 945 +MX6Q_PAD_KEY_ROW4__IPU1_SISG_5 946 +MX6Q_PAD_KEY_ROW4__USBOH3_USBOTG_PWR 947 +MX6Q_PAD_KEY_ROW4__KPP_ROW_4 948 +MX6Q_PAD_KEY_ROW4__UART5_CTS 949 +MX6Q_PAD_KEY_ROW4__GPIO_4_15 950 +MX6Q_PAD_KEY_ROW4__MMDC_DEBUG_50 951 +MX6Q_PAD_KEY_ROW4__PL301_PER1_HADR_8 952 +MX6Q_PAD_GPIO_0__CCM_CLKO 953 +MX6Q_PAD_GPIO_0__KPP_COL_5 954 +MX6Q_PAD_GPIO_0__ASRC_ASRC_EXT_CLK 955 +MX6Q_PAD_GPIO_0__EPIT1_EPITO 956 +MX6Q_PAD_GPIO_0__GPIO_1_0 957 +MX6Q_PAD_GPIO_0__USBOH3_USBH1_PWR 958 +MX6Q_PAD_GPIO_0__SNVS_HP_WRAP_SNVS_VIO5 959 +MX6Q_PAD_GPIO_1__ESAI1_SCKR 960 +MX6Q_PAD_GPIO_1__WDOG2_WDOG_B 961 +MX6Q_PAD_GPIO_1__KPP_ROW_5 962 +MX6Q_PAD_GPIO_1__PWM2_PWMO 963 +MX6Q_PAD_GPIO_1__GPIO_1_1 964 +MX6Q_PAD_GPIO_1__USDHC1_CD 965 +MX6Q_PAD_GPIO_1__SRC_TESTER_ACK 966 +MX6Q_PAD_GPIO_9__ESAI1_FSR 967 +MX6Q_PAD_GPIO_9__WDOG1_WDOG_B 968 +MX6Q_PAD_GPIO_9__KPP_COL_6 969 +MX6Q_PAD_GPIO_9__CCM_REF_EN_B 970 +MX6Q_PAD_GPIO_9__PWM1_PWMO 971 +MX6Q_PAD_GPIO_9__GPIO_1_9 972 +MX6Q_PAD_GPIO_9__USDHC1_WP 973 +MX6Q_PAD_GPIO_9__SRC_EARLY_RST 974 +MX6Q_PAD_GPIO_3__ESAI1_HCKR 975 +MX6Q_PAD_GPIO_3__OBSERVE_MUX_INT_OUT0 976 +MX6Q_PAD_GPIO_3__I2C3_SCL 977 +MX6Q_PAD_GPIO_3__ANATOP_24M_OUT 978 +MX6Q_PAD_GPIO_3__CCM_CLKO2 979 +MX6Q_PAD_GPIO_3__GPIO_1_3 980 +MX6Q_PAD_GPIO_3__USBOH3_USBH1_OC 981 +MX6Q_PAD_GPIO_3__MLB_MLBCLK 982 +MX6Q_PAD_GPIO_6__ESAI1_SCKT 983 +MX6Q_PAD_GPIO_6__OBSERVE_MUX_INT_OUT1 984 +MX6Q_PAD_GPIO_6__I2C3_SDA 985 +MX6Q_PAD_GPIO_6__CCM_CCM_OUT_0 986 +MX6Q_PAD_GPIO_6__CSU_CSU_INT_DEB 987 +MX6Q_PAD_GPIO_6__GPIO_1_6 988 +MX6Q_PAD_GPIO_6__USDHC2_LCTL 989 +MX6Q_PAD_GPIO_6__MLB_MLBSIG 990 +MX6Q_PAD_GPIO_2__ESAI1_FST 991 +MX6Q_PAD_GPIO_2__OBSERVE_MUX_INT_OUT2 992 +MX6Q_PAD_GPIO_2__KPP_ROW_6 993 +MX6Q_PAD_GPIO_2__CCM_CCM_OUT_1 994 +MX6Q_PAD_GPIO_2__CSU_CSU_ALARM_AUT_0 995 +MX6Q_PAD_GPIO_2__GPIO_1_2 996 +MX6Q_PAD_GPIO_2__USDHC2_WP 997 +MX6Q_PAD_GPIO_2__MLB_MLBDAT 998 +MX6Q_PAD_GPIO_4__ESAI1_HCKT 999 +MX6Q_PAD_GPIO_4__OBSERVE_MUX_INT_OUT3 1000 +MX6Q_PAD_GPIO_4__KPP_COL_7 1001 +MX6Q_PAD_GPIO_4__CCM_CCM_OUT_2 1002 +MX6Q_PAD_GPIO_4__CSU_CSU_ALARM_AUT_1 1003 +MX6Q_PAD_GPIO_4__GPIO_1_4 1004 +MX6Q_PAD_GPIO_4__USDHC2_CD 1005 +MX6Q_PAD_GPIO_4__OCOTP_CRL_WRAR_FUSE_LA 1006 +MX6Q_PAD_GPIO_5__ESAI1_TX2_RX3 1007 +MX6Q_PAD_GPIO_5__OBSERVE_MUX_INT_OUT4 1008 +MX6Q_PAD_GPIO_5__KPP_ROW_7 1009 +MX6Q_PAD_GPIO_5__CCM_CLKO 1010 +MX6Q_PAD_GPIO_5__CSU_CSU_ALARM_AUT_2 1011 +MX6Q_PAD_GPIO_5__GPIO_1_5 1012 +MX6Q_PAD_GPIO_5__I2C3_SCL 1013 +MX6Q_PAD_GPIO_5__CHEETAH_EVENTI 1014 +MX6Q_PAD_GPIO_7__ESAI1_TX4_RX1 1015 +MX6Q_PAD_GPIO_7__ECSPI5_RDY 1016 +MX6Q_PAD_GPIO_7__EPIT1_EPITO 1017 +MX6Q_PAD_GPIO_7__CAN1_TXCAN 1018 +MX6Q_PAD_GPIO_7__UART2_TXD 1019 +MX6Q_PAD_GPIO_7__GPIO_1_7 1020 +MX6Q_PAD_GPIO_7__SPDIF_PLOCK 1021 +MX6Q_PAD_GPIO_7__USBOH3_OTGUSB_HST_MODE 1022 +MX6Q_PAD_GPIO_8__ESAI1_TX5_RX0 1023 +MX6Q_PAD_GPIO_8__ANATOP_ANATOP_32K_OUT 1024 +MX6Q_PAD_GPIO_8__EPIT2_EPITO 1025 +MX6Q_PAD_GPIO_8__CAN1_RXCAN 1026 +MX6Q_PAD_GPIO_8__UART2_RXD 1027 +MX6Q_PAD_GPIO_8__GPIO_1_8 1028 +MX6Q_PAD_GPIO_8__SPDIF_SRCLK 1029 +MX6Q_PAD_GPIO_8__USBOH3_OTG_PWRCTL_WAK 1030 +MX6Q_PAD_GPIO_16__ESAI1_TX3_RX2 1031 +MX6Q_PAD_GPIO_16__ENET_1588_EVENT2_IN 1032 +MX6Q_PAD_GPIO_16__ENET_ETHERNET_REF_OUT 1033 +MX6Q_PAD_GPIO_16__USDHC1_LCTL 1034 +MX6Q_PAD_GPIO_16__SPDIF_IN1 1035 +MX6Q_PAD_GPIO_16__GPIO_7_11 1036 +MX6Q_PAD_GPIO_16__I2C3_SDA 1037 +MX6Q_PAD_GPIO_16__SJC_DE_B 1038 +MX6Q_PAD_GPIO_17__ESAI1_TX0 1039 +MX6Q_PAD_GPIO_17__ENET_1588_EVENT3_IN 1040 +MX6Q_PAD_GPIO_17__CCM_PMIC_RDY 1041 +MX6Q_PAD_GPIO_17__SDMA_SDMA_EXT_EVENT_0 1042 +MX6Q_PAD_GPIO_17__SPDIF_OUT1 1043 +MX6Q_PAD_GPIO_17__GPIO_7_12 1044 +MX6Q_PAD_GPIO_17__SJC_JTAG_ACT 1045 +MX6Q_PAD_GPIO_18__ESAI1_TX1 1046 +MX6Q_PAD_GPIO_18__ENET_RX_CLK 1047 +MX6Q_PAD_GPIO_18__USDHC3_VSELECT 1048 +MX6Q_PAD_GPIO_18__SDMA_SDMA_EXT_EVENT_1 1049 +MX6Q_PAD_GPIO_18__ASRC_ASRC_EXT_CLK 1050 +MX6Q_PAD_GPIO_18__GPIO_7_13 1051 +MX6Q_PAD_GPIO_18__SNVS_HP_WRA_SNVS_VIO5 1052 +MX6Q_PAD_GPIO_18__SRC_SYSTEM_RST 1053 +MX6Q_PAD_GPIO_19__KPP_COL_5 1054 +MX6Q_PAD_GPIO_19__ENET_1588_EVENT0_OUT 1055 +MX6Q_PAD_GPIO_19__SPDIF_OUT1 1056 +MX6Q_PAD_GPIO_19__CCM_CLKO 1057 +MX6Q_PAD_GPIO_19__ECSPI1_RDY 1058 +MX6Q_PAD_GPIO_19__GPIO_4_5 1059 +MX6Q_PAD_GPIO_19__ENET_TX_ER 1060 +MX6Q_PAD_GPIO_19__SRC_INT_BOOT 1061 +MX6Q_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 1062 +MX6Q_PAD_CSI0_PIXCLK__PCIE_CTRL_MUX_12 1063 +MX6Q_PAD_CSI0_PIXCLK__SDMA_DEBUG_PC_0 1064 +MX6Q_PAD_CSI0_PIXCLK__GPIO_5_18 1065 +MX6Q_PAD_CSI0_PIXCLK___MMDC_DEBUG_29 1066 +MX6Q_PAD_CSI0_PIXCLK__CHEETAH_EVENTO 1067 +MX6Q_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 1068 +MX6Q_PAD_CSI0_MCLK__PCIE_CTRL_MUX_13 1069 +MX6Q_PAD_CSI0_MCLK__CCM_CLKO 1070 +MX6Q_PAD_CSI0_MCLK__SDMA_DEBUG_PC_1 1071 +MX6Q_PAD_CSI0_MCLK__GPIO_5_19 1072 +MX6Q_PAD_CSI0_MCLK__MMDC_MMDC_DEBUG_30 1073 +MX6Q_PAD_CSI0_MCLK__CHEETAH_TRCTL 1074 +MX6Q_PAD_CSI0_DATA_EN__IPU1_CSI0_DA_EN 1075 +MX6Q_PAD_CSI0_DATA_EN__WEIM_WEIM_D_0 1076 +MX6Q_PAD_CSI0_DATA_EN__PCIE_CTRL_MUX_14 1077 +MX6Q_PAD_CSI0_DATA_EN__SDMA_DEBUG_PC_2 1078 +MX6Q_PAD_CSI0_DATA_EN__GPIO_5_20 1079 +MX6Q_PAD_CSI0_DATA_EN__MMDC_DEBUG_31 1080 +MX6Q_PAD_CSI0_DATA_EN__CHEETAH_TRCLK 1081 +MX6Q_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 1082 +MX6Q_PAD_CSI0_VSYNC__WEIM_WEIM_D_1 1083 +MX6Q_PAD_CSI0_VSYNC__PCIE_CTRL_MUX_15 1084 +MX6Q_PAD_CSI0_VSYNC__SDMA_DEBUG_PC_3 1085 +MX6Q_PAD_CSI0_VSYNC__GPIO_5_21 1086 +MX6Q_PAD_CSI0_VSYNC__MMDC_DEBUG_32 1087 +MX6Q_PAD_CSI0_VSYNC__CHEETAH_TRACE_0 1088 +MX6Q_PAD_CSI0_DAT4__IPU1_CSI0_D_4 1089 +MX6Q_PAD_CSI0_DAT4__WEIM_WEIM_D_2 1090 +MX6Q_PAD_CSI0_DAT4__ECSPI1_SCLK 1091 +MX6Q_PAD_CSI0_DAT4__KPP_COL_5 1092 +MX6Q_PAD_CSI0_DAT4__AUDMUX_AUD3_TXC 1093 +MX6Q_PAD_CSI0_DAT4__GPIO_5_22 1094 +MX6Q_PAD_CSI0_DAT4__MMDC_DEBUG_43 1095 +MX6Q_PAD_CSI0_DAT4__CHEETAH_TRACE_1 1096 +MX6Q_PAD_CSI0_DAT5__IPU1_CSI0_D_5 1097 +MX6Q_PAD_CSI0_DAT5__WEIM_WEIM_D_3 1098 +MX6Q_PAD_CSI0_DAT5__ECSPI1_MOSI 1099 +MX6Q_PAD_CSI0_DAT5__KPP_ROW_5 1100 +MX6Q_PAD_CSI0_DAT5__AUDMUX_AUD3_TXD 1101 +MX6Q_PAD_CSI0_DAT5__GPIO_5_23 1102 +MX6Q_PAD_CSI0_DAT5__MMDC_MMDC_DEBUG_44 1103 +MX6Q_PAD_CSI0_DAT5__CHEETAH_TRACE_2 1104 +MX6Q_PAD_CSI0_DAT6__IPU1_CSI0_D_6 1105 +MX6Q_PAD_CSI0_DAT6__WEIM_WEIM_D_4 1106 +MX6Q_PAD_CSI0_DAT6__ECSPI1_MISO 1107 +MX6Q_PAD_CSI0_DAT6__KPP_COL_6 1108 +MX6Q_PAD_CSI0_DAT6__AUDMUX_AUD3_TXFS 1109 +MX6Q_PAD_CSI0_DAT6__GPIO_5_24 1110 +MX6Q_PAD_CSI0_DAT6__MMDC_MMDC_DEBUG_45 1111 +MX6Q_PAD_CSI0_DAT6__CHEETAH_TRACE_3 1112 +MX6Q_PAD_CSI0_DAT7__IPU1_CSI0_D_7 1113 +MX6Q_PAD_CSI0_DAT7__WEIM_WEIM_D_5 1114 +MX6Q_PAD_CSI0_DAT7__ECSPI1_SS0 1115 +MX6Q_PAD_CSI0_DAT7__KPP_ROW_6 1116 +MX6Q_PAD_CSI0_DAT7__AUDMUX_AUD3_RXD 1117 +MX6Q_PAD_CSI0_DAT7__GPIO_5_25 1118 +MX6Q_PAD_CSI0_DAT7__MMDC_MMDC_DEBUG_46 1119 +MX6Q_PAD_CSI0_DAT7__CHEETAH_TRACE_4 1120 +MX6Q_PAD_CSI0_DAT8__IPU1_CSI0_D_8 1121 +MX6Q_PAD_CSI0_DAT8__WEIM_WEIM_D_6 1122 +MX6Q_PAD_CSI0_DAT8__ECSPI2_SCLK 1123 +MX6Q_PAD_CSI0_DAT8__KPP_COL_7 1124 +MX6Q_PAD_CSI0_DAT8__I2C1_SDA 1125 +MX6Q_PAD_CSI0_DAT8__GPIO_5_26 1126 +MX6Q_PAD_CSI0_DAT8__MMDC_MMDC_DEBUG_47 1127 +MX6Q_PAD_CSI0_DAT8__CHEETAH_TRACE_5 1128 +MX6Q_PAD_CSI0_DAT9__IPU1_CSI0_D_9 1129 +MX6Q_PAD_CSI0_DAT9__WEIM_WEIM_D_7 1130 +MX6Q_PAD_CSI0_DAT9__ECSPI2_MOSI 1131 +MX6Q_PAD_CSI0_DAT9__KPP_ROW_7 1132 +MX6Q_PAD_CSI0_DAT9__I2C1_SCL 1133 +MX6Q_PAD_CSI0_DAT9__GPIO_5_27 1134 +MX6Q_PAD_CSI0_DAT9__MMDC_MMDC_DEBUG_48 1135 +MX6Q_PAD_CSI0_DAT9__CHEETAH_TRACE_6 1136 +MX6Q_PAD_CSI0_DAT10__IPU1_CSI0_D_10 1137 +MX6Q_PAD_CSI0_DAT10__AUDMUX_AUD3_RXC 1138 +MX6Q_PAD_CSI0_DAT10__ECSPI2_MISO 1139 +MX6Q_PAD_CSI0_DAT10__UART1_TXD 1140 +MX6Q_PAD_CSI0_DAT10__SDMA_DEBUG_PC_4 1141 +MX6Q_PAD_CSI0_DAT10__GPIO_5_28 1142 +MX6Q_PAD_CSI0_DAT10__MMDC_MMDC_DEBUG_33 1143 +MX6Q_PAD_CSI0_DAT10__CHEETAH_TRACE_7 1144 +MX6Q_PAD_CSI0_DAT11__IPU1_CSI0_D_11 1145 +MX6Q_PAD_CSI0_DAT11__AUDMUX_AUD3_RXFS 1146 +MX6Q_PAD_CSI0_DAT11__ECSPI2_SS0 1147 +MX6Q_PAD_CSI0_DAT11__UART1_RXD 1148 +MX6Q_PAD_CSI0_DAT11__SDMA_DEBUG_PC_5 1149 +MX6Q_PAD_CSI0_DAT11__GPIO_5_29 1150 +MX6Q_PAD_CSI0_DAT11__MMDC_MMDC_DEBUG_34 1151 +MX6Q_PAD_CSI0_DAT11__CHEETAH_TRACE_8 1152 +MX6Q_PAD_CSI0_DAT12__IPU1_CSI0_D_12 1153 +MX6Q_PAD_CSI0_DAT12__WEIM_WEIM_D_8 1154 +MX6Q_PAD_CSI0_DAT12__PCIE_CTRL_MUX_16 1155 +MX6Q_PAD_CSI0_DAT12__UART4_TXD 1156 +MX6Q_PAD_CSI0_DAT12__SDMA_DEBUG_PC_6 1157 +MX6Q_PAD_CSI0_DAT12__GPIO_5_30 1158 +MX6Q_PAD_CSI0_DAT12__MMDC_MMDC_DEBUG_35 1159 +MX6Q_PAD_CSI0_DAT12__CHEETAH_TRACE_9 1160 +MX6Q_PAD_CSI0_DAT13__IPU1_CSI0_D_13 1161 +MX6Q_PAD_CSI0_DAT13__WEIM_WEIM_D_9 1162 +MX6Q_PAD_CSI0_DAT13__PCIE_CTRL_MUX_17 1163 +MX6Q_PAD_CSI0_DAT13__UART4_RXD 1164 +MX6Q_PAD_CSI0_DAT13__SDMA_DEBUG_PC_7 1165 +MX6Q_PAD_CSI0_DAT13__GPIO_5_31 1166 +MX6Q_PAD_CSI0_DAT13__MMDC_MMDC_DEBUG_36 1167 +MX6Q_PAD_CSI0_DAT13__CHEETAH_TRACE_10 1168 +MX6Q_PAD_CSI0_DAT14__IPU1_CSI0_D_14 1169 +MX6Q_PAD_CSI0_DAT14__WEIM_WEIM_D_10 1170 +MX6Q_PAD_CSI0_DAT14__PCIE_CTRL_MUX_18 1171 +MX6Q_PAD_CSI0_DAT14__UART5_TXD 1172 +MX6Q_PAD_CSI0_DAT14__SDMA_DEBUG_PC_8 1173 +MX6Q_PAD_CSI0_DAT14__GPIO_6_0 1174 +MX6Q_PAD_CSI0_DAT14__MMDC_MMDC_DEBUG_37 1175 +MX6Q_PAD_CSI0_DAT14__CHEETAH_TRACE_11 1176 +MX6Q_PAD_CSI0_DAT15__IPU1_CSI0_D_15 1177 +MX6Q_PAD_CSI0_DAT15__WEIM_WEIM_D_11 1178 +MX6Q_PAD_CSI0_DAT15__PCIE_CTRL_MUX_19 1179 +MX6Q_PAD_CSI0_DAT15__UART5_RXD 1180 +MX6Q_PAD_CSI0_DAT15__SDMA_DEBUG_PC_9 1181 +MX6Q_PAD_CSI0_DAT15__GPIO_6_1 1182 +MX6Q_PAD_CSI0_DAT15__MMDC_MMDC_DEBUG_38 1183 +MX6Q_PAD_CSI0_DAT15__CHEETAH_TRACE_12 1184 +MX6Q_PAD_CSI0_DAT16__IPU1_CSI0_D_16 1185 +MX6Q_PAD_CSI0_DAT16__WEIM_WEIM_D_12 1186 +MX6Q_PAD_CSI0_DAT16__PCIE_CTRL_MUX_20 1187 +MX6Q_PAD_CSI0_DAT16__UART4_RTS 1188 +MX6Q_PAD_CSI0_DAT16__SDMA_DEBUG_PC_10 1189 +MX6Q_PAD_CSI0_DAT16__GPIO_6_2 1190 +MX6Q_PAD_CSI0_DAT16__MMDC_MMDC_DEBUG_39 1191 +MX6Q_PAD_CSI0_DAT16__CHEETAH_TRACE_13 1192 +MX6Q_PAD_CSI0_DAT17__IPU1_CSI0_D_17 1193 +MX6Q_PAD_CSI0_DAT17__WEIM_WEIM_D_13 1194 +MX6Q_PAD_CSI0_DAT17__PCIE_CTRL_MUX_21 1195 +MX6Q_PAD_CSI0_DAT17__UART4_CTS 1196 +MX6Q_PAD_CSI0_DAT17__SDMA_DEBUG_PC_11 1197 +MX6Q_PAD_CSI0_DAT17__GPIO_6_3 1198 +MX6Q_PAD_CSI0_DAT17__MMDC_MMDC_DEBUG_40 1199 +MX6Q_PAD_CSI0_DAT17__CHEETAH_TRACE_14 1200 +MX6Q_PAD_CSI0_DAT18__IPU1_CSI0_D_18 1201 +MX6Q_PAD_CSI0_DAT18__WEIM_WEIM_D_14 1202 +MX6Q_PAD_CSI0_DAT18__PCIE_CTRL_MUX_22 1203 +MX6Q_PAD_CSI0_DAT18__UART5_RTS 1204 +MX6Q_PAD_CSI0_DAT18__SDMA_DEBUG_PC_12 1205 +MX6Q_PAD_CSI0_DAT18__GPIO_6_4 1206 +MX6Q_PAD_CSI0_DAT18__MMDC_MMDC_DEBUG_41 1207 +MX6Q_PAD_CSI0_DAT18__CHEETAH_TRACE_15 1208 +MX6Q_PAD_CSI0_DAT19__IPU1_CSI0_D_19 1209 +MX6Q_PAD_CSI0_DAT19__WEIM_WEIM_D_15 1210 +MX6Q_PAD_CSI0_DAT19__PCIE_CTRL_MUX_23 1211 +MX6Q_PAD_CSI0_DAT19__UART5_CTS 1212 +MX6Q_PAD_CSI0_DAT19__SDMA_DEBUG_PC_13 1213 +MX6Q_PAD_CSI0_DAT19__GPIO_6_5 1214 +MX6Q_PAD_CSI0_DAT19__MMDC_MMDC_DEBUG_42 1215 +MX6Q_PAD_CSI0_DAT19__ANATOP_TESTO_9 1216 +MX6Q_PAD_JTAG_TMS__SJC_TMS 1217 +MX6Q_PAD_JTAG_MOD__SJC_MOD 1218 +MX6Q_PAD_JTAG_TRSTB__SJC_TRSTB 1219 +MX6Q_PAD_JTAG_TDI__SJC_TDI 1220 +MX6Q_PAD_JTAG_TCK__SJC_TCK 1221 +MX6Q_PAD_JTAG_TDO__SJC_TDO 1222 +MX6Q_PAD_LVDS1_TX3_P__LDB_LVDS1_TX3 1223 +MX6Q_PAD_LVDS1_TX2_P__LDB_LVDS1_TX2 1224 +MX6Q_PAD_LVDS1_CLK_P__LDB_LVDS1_CLK 1225 +MX6Q_PAD_LVDS1_TX1_P__LDB_LVDS1_TX1 1226 +MX6Q_PAD_LVDS1_TX0_P__LDB_LVDS1_TX0 1227 +MX6Q_PAD_LVDS0_TX3_P__LDB_LVDS0_TX3 1228 +MX6Q_PAD_LVDS0_CLK_P__LDB_LVDS0_CLK 1229 +MX6Q_PAD_LVDS0_TX2_P__LDB_LVDS0_TX2 1230 +MX6Q_PAD_LVDS0_TX1_P__LDB_LVDS0_TX1 1231 +MX6Q_PAD_LVDS0_TX0_P__LDB_LVDS0_TX0 1232 +MX6Q_PAD_TAMPER__SNVS_LP_WRAP_SNVS_TD1 1233 +MX6Q_PAD_PMIC_ON_REQ__SNVS_LPWRAP_WKALM 1234 +MX6Q_PAD_PMIC_STBY_REQ__CCM_PMIC_STBYRQ 1235 +MX6Q_PAD_POR_B__SRC_POR_B 1236 +MX6Q_PAD_BOOT_MODE1__SRC_BOOT_MODE_1 1237 +MX6Q_PAD_RESET_IN_B__SRC_RESET_B 1238 +MX6Q_PAD_BOOT_MODE0__SRC_BOOT_MODE_0 1239 +MX6Q_PAD_TEST_MODE__TCU_TEST_MODE 1240 +MX6Q_PAD_SD3_DAT7__USDHC3_DAT7 1241 +MX6Q_PAD_SD3_DAT7__UART1_TXD 1242 +MX6Q_PAD_SD3_DAT7__PCIE_CTRL_MUX_24 1243 +MX6Q_PAD_SD3_DAT7__USBOH3_UH3_DFD_OUT_0 1244 +MX6Q_PAD_SD3_DAT7__USBOH3_UH2_DFD_OUT_0 1245 +MX6Q_PAD_SD3_DAT7__GPIO_6_17 1246 +MX6Q_PAD_SD3_DAT7__MIPI_CORE_DPHY_IN_12 1247 +MX6Q_PAD_SD3_DAT7__USBPHY2_CLK20DIV 1248 +MX6Q_PAD_SD3_DAT6__USDHC3_DAT6 1249 +MX6Q_PAD_SD3_DAT6__UART1_RXD 1250 +MX6Q_PAD_SD3_DAT6__PCIE_CTRL_MUX_25 1251 +MX6Q_PAD_SD3_DAT6__USBOH3_UH3_DFD_OUT_1 1252 +MX6Q_PAD_SD3_DAT6__USBOH3_UH2_DFD_OUT_1 1253 +MX6Q_PAD_SD3_DAT6__GPIO_6_18 1254 +MX6Q_PAD_SD3_DAT6__MIPI_CORE_DPHY_IN_13 1255 +MX6Q_PAD_SD3_DAT6__ANATOP_TESTO_10 1256 +MX6Q_PAD_SD3_DAT5__USDHC3_DAT5 1257 +MX6Q_PAD_SD3_DAT5__UART2_TXD 1258 +MX6Q_PAD_SD3_DAT5__PCIE_CTRL_MUX_26 1259 +MX6Q_PAD_SD3_DAT5__USBOH3_UH3_DFD_OUT_2 1260 +MX6Q_PAD_SD3_DAT5__USBOH3_UH2_DFD_OUT_2 1261 +MX6Q_PAD_SD3_DAT5__GPIO_7_0 1262 +MX6Q_PAD_SD3_DAT5__MIPI_CORE_DPHY_IN_14 1263 +MX6Q_PAD_SD3_DAT5__ANATOP_TESTO_11 1264 +MX6Q_PAD_SD3_DAT4__USDHC3_DAT4 1265 +MX6Q_PAD_SD3_DAT4__UART2_RXD 1266 +MX6Q_PAD_SD3_DAT4__PCIE_CTRL_MUX_27 1267 +MX6Q_PAD_SD3_DAT4__USBOH3_UH3_DFD_OUT_3 1268 +MX6Q_PAD_SD3_DAT4__USBOH3_UH2_DFD_OUT_3 1269 +MX6Q_PAD_SD3_DAT4__GPIO_7_1 1270 +MX6Q_PAD_SD3_DAT4__MIPI_CORE_DPHY_IN_15 1271 +MX6Q_PAD_SD3_DAT4__ANATOP_TESTO_12 1272 +MX6Q_PAD_SD3_CMD__USDHC3_CMD 1273 +MX6Q_PAD_SD3_CMD__UART2_CTS 1274 +MX6Q_PAD_SD3_CMD__CAN1_TXCAN 1275 +MX6Q_PAD_SD3_CMD__USBOH3_UH3_DFD_OUT_4 1276 +MX6Q_PAD_SD3_CMD__USBOH3_UH2_DFD_OUT_4 1277 +MX6Q_PAD_SD3_CMD__GPIO_7_2 1278 +MX6Q_PAD_SD3_CMD__MIPI_CORE_DPHY_IN_16 1279 +MX6Q_PAD_SD3_CMD__ANATOP_TESTO_13 1280 +MX6Q_PAD_SD3_CLK__USDHC3_CLK 1281 +MX6Q_PAD_SD3_CLK__UART2_RTS 1282 +MX6Q_PAD_SD3_CLK__CAN1_RXCAN 1283 +MX6Q_PAD_SD3_CLK__USBOH3_UH3_DFD_OUT_5 1284 +MX6Q_PAD_SD3_CLK__USBOH3_UH2_DFD_OUT_5 1285 +MX6Q_PAD_SD3_CLK__GPIO_7_3 1286 +MX6Q_PAD_SD3_CLK__MIPI_CORE_DPHY_IN_17 1287 +MX6Q_PAD_SD3_CLK__ANATOP_TESTO_14 1288 +MX6Q_PAD_SD3_DAT0__USDHC3_DAT0 1289 +MX6Q_PAD_SD3_DAT0__UART1_CTS 1290 +MX6Q_PAD_SD3_DAT0__CAN2_TXCAN 1291 +MX6Q_PAD_SD3_DAT0__USBOH3_UH3_DFD_OUT_6 1292 +MX6Q_PAD_SD3_DAT0__USBOH3_UH2_DFD_OUT_6 1293 +MX6Q_PAD_SD3_DAT0__GPIO_7_4 1294 +MX6Q_PAD_SD3_DAT0__MIPI_CORE_DPHY_IN_18 1295 +MX6Q_PAD_SD3_DAT0__ANATOP_TESTO_15 1296 +MX6Q_PAD_SD3_DAT1__USDHC3_DAT1 1297 +MX6Q_PAD_SD3_DAT1__UART1_RTS 1298 +MX6Q_PAD_SD3_DAT1__CAN2_RXCAN 1299 +MX6Q_PAD_SD3_DAT1__USBOH3_UH3_DFD_OUT_7 1300 +MX6Q_PAD_SD3_DAT1__USBOH3_UH2_DFD_OUT_7 1301 +MX6Q_PAD_SD3_DAT1__GPIO_7_5 1302 +MX6Q_PAD_SD3_DAT1__MIPI_CORE_DPHY_IN_19 1303 +MX6Q_PAD_SD3_DAT1__ANATOP_TESTI_0 1304 +MX6Q_PAD_SD3_DAT2__USDHC3_DAT2 1305 +MX6Q_PAD_SD3_DAT2__PCIE_CTRL_MUX_28 1306 +MX6Q_PAD_SD3_DAT2__USBOH3_UH3_DFD_OUT_8 1307 +MX6Q_PAD_SD3_DAT2__USBOH3_UH2_DFD_OUT_8 1308 +MX6Q_PAD_SD3_DAT2__GPIO_7_6 1309 +MX6Q_PAD_SD3_DAT2__MIPI_CORE_DPHY_IN_20 1310 +MX6Q_PAD_SD3_DAT2__ANATOP_TESTI_1 1311 +MX6Q_PAD_SD3_DAT3__USDHC3_DAT3 1312 +MX6Q_PAD_SD3_DAT3__UART3_CTS 1313 +MX6Q_PAD_SD3_DAT3__PCIE_CTRL_MUX_29 1314 +MX6Q_PAD_SD3_DAT3__USBOH3_UH3_DFD_OUT_9 1315 +MX6Q_PAD_SD3_DAT3__USBOH3_UH2_DFD_OUT_9 1316 +MX6Q_PAD_SD3_DAT3__GPIO_7_7 1317 +MX6Q_PAD_SD3_DAT3__MIPI_CORE_DPHY_IN_21 1318 +MX6Q_PAD_SD3_DAT3__ANATOP_TESTI_2 1319 +MX6Q_PAD_SD3_RST__USDHC3_RST 1320 +MX6Q_PAD_SD3_RST__UART3_RTS 1321 +MX6Q_PAD_SD3_RST__PCIE_CTRL_MUX_30 1322 +MX6Q_PAD_SD3_RST__USBOH3_UH3_DFD_OUT_10 1323 +MX6Q_PAD_SD3_RST__USBOH3_UH2_DFD_OUT_10 1324 +MX6Q_PAD_SD3_RST__GPIO_7_8 1325 +MX6Q_PAD_SD3_RST__MIPI_CORE_DPHY_IN_22 1326 +MX6Q_PAD_SD3_RST__ANATOP_ANATOP_TESTI_3 1327 +MX6Q_PAD_NANDF_CLE__RAWNAND_CLE 1328 +MX6Q_PAD_NANDF_CLE__IPU2_SISG_4 1329 +MX6Q_PAD_NANDF_CLE__PCIE_CTRL_MUX_31 1330 +MX6Q_PAD_NANDF_CLE__USBOH3_UH3_DFD_OT11 1331 +MX6Q_PAD_NANDF_CLE__USBOH3_UH2_DFD_OT11 1332 +MX6Q_PAD_NANDF_CLE__GPIO_6_7 1333 +MX6Q_PAD_NANDF_CLE__MIPI_CORE_DPHY_IN23 1334 +MX6Q_PAD_NANDF_CLE__TPSMP_HTRANS_0 1335 +MX6Q_PAD_NANDF_ALE__RAWNAND_ALE 1336 +MX6Q_PAD_NANDF_ALE__USDHC4_RST 1337 +MX6Q_PAD_NANDF_ALE__PCIE_CTRL_MUX_0 1338 +MX6Q_PAD_NANDF_ALE__USBOH3_UH3_DFD_OT12 1339 +MX6Q_PAD_NANDF_ALE__USBOH3_UH2_DFD_OT12 1340 +MX6Q_PAD_NANDF_ALE__GPIO_6_8 1341 +MX6Q_PAD_NANDF_ALE__MIPI_CR_DPHY_IN_24 1342 +MX6Q_PAD_NANDF_ALE__TPSMP_HTRANS_1 1343 +MX6Q_PAD_NANDF_WP_B__RAWNAND_RESETN 1344 +MX6Q_PAD_NANDF_WP_B__IPU2_SISG_5 1345 +MX6Q_PAD_NANDF_WP_B__PCIE_CTRL__MUX_1 1346 +MX6Q_PAD_NANDF_WP_B__USBOH3_UH3_DFDOT13 1347 +MX6Q_PAD_NANDF_WP_B__USBOH3_UH2_DFDOT13 1348 +MX6Q_PAD_NANDF_WP_B__GPIO_6_9 1349 +MX6Q_PAD_NANDF_WP_B__MIPI_CR_DPHY_OUT32 1350 +MX6Q_PAD_NANDF_WP_B__PL301_PER1_HSIZE_0 1351 +MX6Q_PAD_NANDF_RB0__RAWNAND_READY0 1352 +MX6Q_PAD_NANDF_RB0__IPU2_DI0_PIN1 1353 +MX6Q_PAD_NANDF_RB0__PCIE_CTRL_MUX_2 1354 +MX6Q_PAD_NANDF_RB0__USBOH3_UH3_DFD_OT14 1355 +MX6Q_PAD_NANDF_RB0__USBOH3_UH2_DFD_OT14 1356 +MX6Q_PAD_NANDF_RB0__GPIO_6_10 1357 +MX6Q_PAD_NANDF_RB0__MIPI_CR_DPHY_OUT_33 1358 +MX6Q_PAD_NANDF_RB0__PL301_PER1_HSIZE_1 1359 +MX6Q_PAD_NANDF_CS0__RAWNAND_CE0N 1360 +MX6Q_PAD_NANDF_CS0__USBOH3_UH3_DFD_OT15 1361 +MX6Q_PAD_NANDF_CS0__USBOH3_UH2_DFD_OT15 1362 +MX6Q_PAD_NANDF_CS0__GPIO_6_11 1363 +MX6Q_PAD_NANDF_CS0__PL301_PER1_HSIZE_2 1364 +MX6Q_PAD_NANDF_CS1__RAWNAND_CE1N 1365 +MX6Q_PAD_NANDF_CS1__USDHC4_VSELECT 1366 +MX6Q_PAD_NANDF_CS1__USDHC3_VSELECT 1367 +MX6Q_PAD_NANDF_CS1__PCIE_CTRL_MUX_3 1368 +MX6Q_PAD_NANDF_CS1__GPIO_6_14 1369 +MX6Q_PAD_NANDF_CS1__PL301_PER1_HRDYOUT 1370 +MX6Q_PAD_NANDF_CS2__RAWNAND_CE2N 1371 +MX6Q_PAD_NANDF_CS2__IPU1_SISG_0 1372 +MX6Q_PAD_NANDF_CS2__ESAI1_TX0 1373 +MX6Q_PAD_NANDF_CS2__WEIM_WEIM_CRE 1374 +MX6Q_PAD_NANDF_CS2__CCM_CLKO2 1375 +MX6Q_PAD_NANDF_CS2__GPIO_6_15 1376 +MX6Q_PAD_NANDF_CS2__IPU2_SISG_0 1377 +MX6Q_PAD_NANDF_CS3__RAWNAND_CE3N 1378 +MX6Q_PAD_NANDF_CS3__IPU1_SISG_1 1379 +MX6Q_PAD_NANDF_CS3__ESAI1_TX1 1380 +MX6Q_PAD_NANDF_CS3__WEIM_WEIM_A_26 1381 +MX6Q_PAD_NANDF_CS3__PCIE_CTRL_MUX_4 1382 +MX6Q_PAD_NANDF_CS3__GPIO_6_16 1383 +MX6Q_PAD_NANDF_CS3__IPU2_SISG_1 1384 +MX6Q_PAD_NANDF_CS3__TPSMP_CLK 1385 +MX6Q_PAD_SD4_CMD__USDHC4_CMD 1386 +MX6Q_PAD_SD4_CMD__RAWNAND_RDN 1387 +MX6Q_PAD_SD4_CMD__UART3_TXD 1388 +MX6Q_PAD_SD4_CMD__PCIE_CTRL_MUX_5 1389 +MX6Q_PAD_SD4_CMD__GPIO_7_9 1390 +MX6Q_PAD_SD4_CMD__TPSMP_HDATA_DIR 1391 +MX6Q_PAD_SD4_CLK__USDHC4_CLK 1392 +MX6Q_PAD_SD4_CLK__RAWNAND_WRN 1393 +MX6Q_PAD_SD4_CLK__UART3_RXD 1394 +MX6Q_PAD_SD4_CLK__PCIE_CTRL_MUX_6 1395 +MX6Q_PAD_SD4_CLK__GPIO_7_10 1396 +MX6Q_PAD_NANDF_D0__RAWNAND_D0 1397 +MX6Q_PAD_NANDF_D0__USDHC1_DAT4 1398 +MX6Q_PAD_NANDF_D0__GPU3D_GPU_DBG_OUT_0 1399 +MX6Q_PAD_NANDF_D0__USBOH3_UH2_DFD_OUT16 1400 +MX6Q_PAD_NANDF_D0__USBOH3_UH3_DFD_OUT16 1401 +MX6Q_PAD_NANDF_D0__GPIO_2_0 1402 +MX6Q_PAD_NANDF_D0__IPU1_IPU_DIAG_BUS_0 1403 +MX6Q_PAD_NANDF_D0__IPU2_IPU_DIAG_BUS_0 1404 +MX6Q_PAD_NANDF_D1__RAWNAND_D1 1405 +MX6Q_PAD_NANDF_D1__USDHC1_DAT5 1406 +MX6Q_PAD_NANDF_D1__GPU3D_GPU_DEBUG_OUT1 1407 +MX6Q_PAD_NANDF_D1__USBOH3_UH2_DFD_OUT17 1408 +MX6Q_PAD_NANDF_D1__USBOH3_UH3_DFD_OUT17 1409 +MX6Q_PAD_NANDF_D1__GPIO_2_1 1410 +MX6Q_PAD_NANDF_D1__IPU1_IPU_DIAG_BUS_1 1411 +MX6Q_PAD_NANDF_D1__IPU2_IPU_DIAG_BUS_1 1412 +MX6Q_PAD_NANDF_D2__RAWNAND_D2 1413 +MX6Q_PAD_NANDF_D2__USDHC1_DAT6 1414 +MX6Q_PAD_NANDF_D2__GPU3D_GPU_DBG_OUT_2 1415 +MX6Q_PAD_NANDF_D2__USBOH3_UH2_DFD_OUT18 1416 +MX6Q_PAD_NANDF_D2__USBOH3_UH3_DFD_OUT18 1417 +MX6Q_PAD_NANDF_D2__GPIO_2_2 1418 +MX6Q_PAD_NANDF_D2__IPU1_IPU_DIAG_BUS_2 1419 +MX6Q_PAD_NANDF_D2__IPU2_IPU_DIAG_BUS_2 1420 +MX6Q_PAD_NANDF_D3__RAWNAND_D3 1421 +MX6Q_PAD_NANDF_D3__USDHC1_DAT7 1422 +MX6Q_PAD_NANDF_D3__GPU3D_GPU_DBG_OUT_3 1423 +MX6Q_PAD_NANDF_D3__USBOH3_UH2_DFD_OUT19 1424 +MX6Q_PAD_NANDF_D3__USBOH3_UH3_DFD_OUT19 1425 +MX6Q_PAD_NANDF_D3__GPIO_2_3 1426 +MX6Q_PAD_NANDF_D3__IPU1_IPU_DIAG_BUS_3 1427 +MX6Q_PAD_NANDF_D3__IPU2_IPU_DIAG_BUS_3 1428 +MX6Q_PAD_NANDF_D4__RAWNAND_D4 1429 +MX6Q_PAD_NANDF_D4__USDHC2_DAT4 1430 +MX6Q_PAD_NANDF_D4__GPU3D_GPU_DBG_OUT_4 1431 +MX6Q_PAD_NANDF_D4__USBOH3_UH2_DFD_OUT20 1432 +MX6Q_PAD_NANDF_D4__USBOH3_UH3_DFD_OUT20 1433 +MX6Q_PAD_NANDF_D4__GPIO_2_4 1434 +MX6Q_PAD_NANDF_D4__IPU1_IPU_DIAG_BUS_4 1435 +MX6Q_PAD_NANDF_D4__IPU2_IPU_DIAG_BUS_4 1436 +MX6Q_PAD_NANDF_D5__RAWNAND_D5 1437 +MX6Q_PAD_NANDF_D5__USDHC2_DAT5 1438 +MX6Q_PAD_NANDF_D5__GPU3D_GPU_DBG_OUT_5 1439 +MX6Q_PAD_NANDF_D5__USBOH3_UH2_DFD_OUT21 1440 +MX6Q_PAD_NANDF_D5__USBOH3_UH3_DFD_OUT21 1441 +MX6Q_PAD_NANDF_D5__GPIO_2_5 1442 +MX6Q_PAD_NANDF_D5__IPU1_IPU_DIAG_BUS_5 1443 +MX6Q_PAD_NANDF_D5__IPU2_IPU_DIAG_BUS_5 1444 +MX6Q_PAD_NANDF_D6__RAWNAND_D6 1445 +MX6Q_PAD_NANDF_D6__USDHC2_DAT6 1446 +MX6Q_PAD_NANDF_D6__GPU3D_GPU_DBG_OUT_6 1447 +MX6Q_PAD_NANDF_D6__USBOH3_UH2_DFD_OUT22 1448 +MX6Q_PAD_NANDF_D6__USBOH3_UH3_DFD_OUT22 1449 +MX6Q_PAD_NANDF_D6__GPIO_2_6 1450 +MX6Q_PAD_NANDF_D6__IPU1_IPU_DIAG_BUS_6 1451 +MX6Q_PAD_NANDF_D6__IPU2_IPU_DIAG_BUS_6 1452 +MX6Q_PAD_NANDF_D7__RAWNAND_D7 1453 +MX6Q_PAD_NANDF_D7__USDHC2_DAT7 1454 +MX6Q_PAD_NANDF_D7__GPU3D_GPU_DBG_OUT_7 1455 +MX6Q_PAD_NANDF_D7__USBOH3_UH2_DFD_OUT23 1456 +MX6Q_PAD_NANDF_D7__USBOH3_UH3_DFD_OUT23 1457 +MX6Q_PAD_NANDF_D7__GPIO_2_7 1458 +MX6Q_PAD_NANDF_D7__IPU1_IPU_DIAG_BUS_7 1459 +MX6Q_PAD_NANDF_D7__IPU2_IPU_DIAG_BUS_7 1460 +MX6Q_PAD_SD4_DAT0__RAWNAND_D8 1461 +MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 1462 +MX6Q_PAD_SD4_DAT0__RAWNAND_DQS 1463 +MX6Q_PAD_SD4_DAT0__USBOH3_UH2_DFD_OUT24 1464 +MX6Q_PAD_SD4_DAT0__USBOH3_UH3_DFD_OUT24 1465 +MX6Q_PAD_SD4_DAT0__GPIO_2_8 1466 +MX6Q_PAD_SD4_DAT0__IPU1_IPU_DIAG_BUS_8 1467 +MX6Q_PAD_SD4_DAT0__IPU2_IPU_DIAG_BUS_8 1468 +MX6Q_PAD_SD4_DAT1__RAWNAND_D9 1469 +MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 1470 +MX6Q_PAD_SD4_DAT1__PWM3_PWMO 1471 +MX6Q_PAD_SD4_DAT1__USBOH3_UH2_DFD_OUT25 1472 +MX6Q_PAD_SD4_DAT1__USBOH3_UH3_DFD_OUT25 1473 +MX6Q_PAD_SD4_DAT1__GPIO_2_9 1474 +MX6Q_PAD_SD4_DAT1__IPU1_IPU_DIAG_BUS_9 1475 +MX6Q_PAD_SD4_DAT1__IPU2_IPU_DIAG_BUS_9 1476 +MX6Q_PAD_SD4_DAT2__RAWNAND_D10 1477 +MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 1478 +MX6Q_PAD_SD4_DAT2__PWM4_PWMO 1479 +MX6Q_PAD_SD4_DAT2__USBOH3_UH2_DFD_OUT26 1480 +MX6Q_PAD_SD4_DAT2__USBOH3_UH3_DFD_OUT26 1481 +MX6Q_PAD_SD4_DAT2__GPIO_2_10 1482 +MX6Q_PAD_SD4_DAT2__IPU1_IPU_DIAG_BUS_10 1483 +MX6Q_PAD_SD4_DAT2__IPU2_IPU_DIAG_BUS_10 1484 +MX6Q_PAD_SD4_DAT3__RAWNAND_D11 1485 +MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 1486 +MX6Q_PAD_SD4_DAT3__USBOH3_UH2_DFD_OUT27 1487 +MX6Q_PAD_SD4_DAT3__USBOH3_UH3_DFD_OUT27 1488 +MX6Q_PAD_SD4_DAT3__GPIO_2_11 1489 +MX6Q_PAD_SD4_DAT3__IPU1_IPU_DIAG_BUS_11 1490 +MX6Q_PAD_SD4_DAT3__IPU2_IPU_DIAG_BUS_11 1491 +MX6Q_PAD_SD4_DAT4__RAWNAND_D12 1492 +MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 1493 +MX6Q_PAD_SD4_DAT4__UART2_RXD 1494 +MX6Q_PAD_SD4_DAT4__USBOH3_UH2_DFD_OUT28 1495 +MX6Q_PAD_SD4_DAT4__USBOH3_UH3_DFD_OUT28 1496 +MX6Q_PAD_SD4_DAT4__GPIO_2_12 1497 +MX6Q_PAD_SD4_DAT4__IPU1_IPU_DIAG_BUS_12 1498 +MX6Q_PAD_SD4_DAT4__IPU2_IPU_DIAG_BUS_12 1499 +MX6Q_PAD_SD4_DAT5__RAWNAND_D13 1500 +MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 1501 +MX6Q_PAD_SD4_DAT5__UART2_RTS 1502 +MX6Q_PAD_SD4_DAT5__USBOH3_UH2_DFD_OUT29 1503 +MX6Q_PAD_SD4_DAT5__USBOH3_UH3_DFD_OUT29 1504 +MX6Q_PAD_SD4_DAT5__GPIO_2_13 1505 +MX6Q_PAD_SD4_DAT5__IPU1_IPU_DIAG_BUS_13 1506 +MX6Q_PAD_SD4_DAT5__IPU2_IPU_DIAG_BUS_13 1507 +MX6Q_PAD_SD4_DAT6__RAWNAND_D14 1508 +MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 1509 +MX6Q_PAD_SD4_DAT6__UART2_CTS 1510 +MX6Q_PAD_SD4_DAT6__USBOH3_UH2_DFD_OUT30 1511 +MX6Q_PAD_SD4_DAT6__USBOH3_UH3_DFD_OUT30 1512 +MX6Q_PAD_SD4_DAT6__GPIO_2_14 1513 +MX6Q_PAD_SD4_DAT6__IPU1_IPU_DIAG_BUS_14 1514 +MX6Q_PAD_SD4_DAT6__IPU2_IPU_DIAG_BUS_14 1515 +MX6Q_PAD_SD4_DAT7__RAWNAND_D15 1516 +MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 1517 +MX6Q_PAD_SD4_DAT7__UART2_TXD 1518 +MX6Q_PAD_SD4_DAT7__USBOH3_UH2_DFD_OUT31 1519 +MX6Q_PAD_SD4_DAT7__USBOH3_UH3_DFD_OUT31 1520 +MX6Q_PAD_SD4_DAT7__GPIO_2_15 1521 +MX6Q_PAD_SD4_DAT7__IPU1_IPU_DIAG_BUS_15 1522 +MX6Q_PAD_SD4_DAT7__IPU2_IPU_DIAG_BUS_15 1523 +MX6Q_PAD_SD1_DAT1__USDHC1_DAT1 1524 +MX6Q_PAD_SD1_DAT1__ECSPI5_SS0 1525 +MX6Q_PAD_SD1_DAT1__PWM3_PWMO 1526 +MX6Q_PAD_SD1_DAT1__GPT_CAPIN2 1527 +MX6Q_PAD_SD1_DAT1__PCIE_CTRL_MUX_7 1528 +MX6Q_PAD_SD1_DAT1__GPIO_1_17 1529 +MX6Q_PAD_SD1_DAT1__HDMI_TX_OPHYDTB_0 1530 +MX6Q_PAD_SD1_DAT1__ANATOP_TESTO_8 1531 +MX6Q_PAD_SD1_DAT0__USDHC1_DAT0 1532 +MX6Q_PAD_SD1_DAT0__ECSPI5_MISO 1533 +MX6Q_PAD_SD1_DAT0__CAAM_WRAP_RNG_OSCOBS 1534 +MX6Q_PAD_SD1_DAT0__GPT_CAPIN1 1535 +MX6Q_PAD_SD1_DAT0__PCIE_CTRL_MUX_8 1536 +MX6Q_PAD_SD1_DAT0__GPIO_1_16 1537 +MX6Q_PAD_SD1_DAT0__HDMI_TX_OPHYDTB_1 1538 +MX6Q_PAD_SD1_DAT0__ANATOP_TESTO_7 1539 +MX6Q_PAD_SD1_DAT3__USDHC1_DAT3 1540 +MX6Q_PAD_SD1_DAT3__ECSPI5_SS2 1541 +MX6Q_PAD_SD1_DAT3__GPT_CMPOUT3 1542 +MX6Q_PAD_SD1_DAT3__PWM1_PWMO 1543 +MX6Q_PAD_SD1_DAT3__WDOG2_WDOG_B 1544 +MX6Q_PAD_SD1_DAT3__GPIO_1_21 1545 +MX6Q_PAD_SD1_DAT3__WDOG2_WDOG_RST_B_DEB 1546 +MX6Q_PAD_SD1_DAT3__ANATOP_TESTO_6 1547 +MX6Q_PAD_SD1_CMD__USDHC1_CMD 1548 +MX6Q_PAD_SD1_CMD__ECSPI5_MOSI 1549 +MX6Q_PAD_SD1_CMD__PWM4_PWMO 1550 +MX6Q_PAD_SD1_CMD__GPT_CMPOUT1 1551 +MX6Q_PAD_SD1_CMD__GPIO_1_18 1552 +MX6Q_PAD_SD1_CMD__ANATOP_TESTO_5 1553 +MX6Q_PAD_SD1_DAT2__USDHC1_DAT2 1554 +MX6Q_PAD_SD1_DAT2__ECSPI5_SS1 1555 +MX6Q_PAD_SD1_DAT2__GPT_CMPOUT2 1556 +MX6Q_PAD_SD1_DAT2__PWM2_PWMO 1557 +MX6Q_PAD_SD1_DAT2__WDOG1_WDOG_B 1558 +MX6Q_PAD_SD1_DAT2__GPIO_1_19 1559 +MX6Q_PAD_SD1_DAT2__WDOG1_WDOG_RST_B_DEB 1560 +MX6Q_PAD_SD1_DAT2__ANATOP_TESTO_4 1561 +MX6Q_PAD_SD1_CLK__USDHC1_CLK 1562 +MX6Q_PAD_SD1_CLK__ECSPI5_SCLK 1563 +MX6Q_PAD_SD1_CLK__OSC32K_32K_OUT 1564 +MX6Q_PAD_SD1_CLK__GPT_CLKIN 1565 +MX6Q_PAD_SD1_CLK__GPIO_1_20 1566 +MX6Q_PAD_SD1_CLK__PHY_DTB_0 1567 +MX6Q_PAD_SD1_CLK__SATA_PHY_DTB_0 1568 +MX6Q_PAD_SD2_CLK__USDHC2_CLK 1569 +MX6Q_PAD_SD2_CLK__ECSPI5_SCLK 1570 +MX6Q_PAD_SD2_CLK__KPP_COL_5 1571 +MX6Q_PAD_SD2_CLK__AUDMUX_AUD4_RXFS 1572 +MX6Q_PAD_SD2_CLK__PCIE_CTRL_MUX_9 1573 +MX6Q_PAD_SD2_CLK__GPIO_1_10 1574 +MX6Q_PAD_SD2_CLK__PHY_DTB_1 1575 +MX6Q_PAD_SD2_CLK__SATA_PHY_DTB_1 1576 +MX6Q_PAD_SD2_CMD__USDHC2_CMD 1577 +MX6Q_PAD_SD2_CMD__ECSPI5_MOSI 1578 +MX6Q_PAD_SD2_CMD__KPP_ROW_5 1579 +MX6Q_PAD_SD2_CMD__AUDMUX_AUD4_RXC 1580 +MX6Q_PAD_SD2_CMD__PCIE_CTRL_MUX_10 1581 +MX6Q_PAD_SD2_CMD__GPIO_1_11 1582 +MX6Q_PAD_SD2_DAT3__USDHC2_DAT3 1583 +MX6Q_PAD_SD2_DAT3__ECSPI5_SS3 1584 +MX6Q_PAD_SD2_DAT3__KPP_COL_6 1585 +MX6Q_PAD_SD2_DAT3__AUDMUX_AUD4_TXC 1586 +MX6Q_PAD_SD2_DAT3__PCIE_CTRL_MUX_11 1587 +MX6Q_PAD_SD2_DAT3__GPIO_1_12 1588 +MX6Q_PAD_SD2_DAT3__SJC_DONE 1589 +MX6Q_PAD_SD2_DAT3__ANATOP_TESTO_3 1590 +MX6Q_PAD_ENET_RX_ER__ANATOP_USBOTG_ID 1591 +MX6Q_PAD_GPIO_1__ANATOP_USBOTG_ID 1592 diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt new file mode 100644 index 0000000..f7e8e8f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt @@ -0,0 +1,918 @@ +* Freescale MXS Pin Controller + +The pins controlled by mxs pin controller are organized in banks, each bank +has 32 pins. Each pin has 4 multiplexing functions, and generally, the 4th +function is GPIO. The configuration on the pins includes drive strength, +voltage and pull-up. + +Required properties: +- compatible: "fsl,imx23-pinctrl" or "fsl,imx28-pinctrl" +- reg: Should contain the register physical address and length for the + pin controller. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices. + +The node of mxs pin controller acts as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for +a group of pins, and only affects those parameters that are explicitly listed. +In other words, a subnode that describes a drive strength parameter implies no +information about pull-up. For this reason, even seemingly boolean values are +actually tristates in this binding: unspecified, off, or on. Unspecified is +represented as an absent property, and off/on are represented as integer +values 0 and 1. + +Those subnodes under mxs pin controller node will fall into two categories. +One is to set up a group of pins for a function, both mux selection and pin +configurations, and it's called group node in the binding document. The other +one is to adjust the pin configuration for some particular pins that need a +different configuration than what is defined in group node. The binding +document calls this type of node config node. + +On mxs, there is no hardware pin group. The pin group in this binding only +means a group of pins put together for particular peripheral to work in +particular function, like SSP0 functioning as mmc0-8bit. That said, the +group node should include all the pins needed for one function rather than +having these pins defined in several group nodes. It also means each of +"pinctrl-*" phandle in client device node should only have one group node +pointed in there, while the phandle can have multiple config node referenced +there to adjust configurations for some pins in the group. + +Required subnode-properties: +- fsl,pinmux-ids: An integer array. Each integer in the array specify a pin + with given mux function, with bank, pin and mux packed as below. + + [15..12] : bank number + [11..4] : pin number + [3..0] : mux selection + + This integer with mux selection packed is used as an entity by both group + and config nodes to identify a pin. The mux selection in the integer takes + effects only on group node, and will get ignored by driver with config node, + since config node is only meant to set up pin configurations. + + Valid values for these integers are listed below. + +- reg: Should be the index of the group nodes for same function. This property + is required only for group nodes, and should not be present in any config + nodes. + +Optional subnode-properties: +- fsl,drive-strength: Integer. + 0: 4 mA + 1: 8 mA + 2: 12 mA + 3: 16 mA +- fsl,voltage: Integer. + 0: 1.8 V + 1: 3.3 V +- fsl,pull-up: Integer. + 0: Disable the internal pull-up + 1: Enable the internal pull-up + +Examples: + +pinctrl@80018000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx28-pinctrl"; + reg = <0x80018000 2000>; + + mmc0_8bit_pins_a: mmc0-8bit@0 { + reg = <0>; + fsl,pinmux-ids = < + 0x2000 0x2010 0x2020 0x2030 + 0x2040 0x2050 0x2060 0x2070 + 0x2080 0x2090 0x20a0>; + fsl,drive-strength = <1>; + fsl,voltage = <1>; + fsl,pull-up = <1>; + }; + + mmc_cd_cfg: mmc-cd-cfg { + fsl,pinmux-ids = <0x2090>; + fsl,pull-up = <0>; + }; + + mmc_sck_cfg: mmc-sck-cfg { + fsl,pinmux-ids = <0x20a0>; + fsl,drive-strength = <2>; + fsl,pull-up = <0>; + }; +}; + +In this example, group node mmc0-8bit defines a group of pins for mxs SSP0 +to function as a 8-bit mmc device, with 8mA, 3.3V and pull-up configurations +applied on all these pins. And config nodes mmc-cd-cfg and mmc-sck-cfg are +adjusting the configuration for pins card-detection and clock from what group +node mmc0-8bit defines. Only the configuration properties to be adjusted need +to be listed in the config nodes. + +Valid values for i.MX28 pinmux-id: + +pinmux id +------ -- +MX28_PAD_GPMI_D00__GPMI_D0 0x0000 +MX28_PAD_GPMI_D01__GPMI_D1 0x0010 +MX28_PAD_GPMI_D02__GPMI_D2 0x0020 +MX28_PAD_GPMI_D03__GPMI_D3 0x0030 +MX28_PAD_GPMI_D04__GPMI_D4 0x0040 +MX28_PAD_GPMI_D05__GPMI_D5 0x0050 +MX28_PAD_GPMI_D06__GPMI_D6 0x0060 +MX28_PAD_GPMI_D07__GPMI_D7 0x0070 +MX28_PAD_GPMI_CE0N__GPMI_CE0N 0x0100 +MX28_PAD_GPMI_CE1N__GPMI_CE1N 0x0110 +MX28_PAD_GPMI_CE2N__GPMI_CE2N 0x0120 +MX28_PAD_GPMI_CE3N__GPMI_CE3N 0x0130 +MX28_PAD_GPMI_RDY0__GPMI_READY0 0x0140 +MX28_PAD_GPMI_RDY1__GPMI_READY1 0x0150 +MX28_PAD_GPMI_RDY2__GPMI_READY2 0x0160 +MX28_PAD_GPMI_RDY3__GPMI_READY3 0x0170 +MX28_PAD_GPMI_RDN__GPMI_RDN 0x0180 +MX28_PAD_GPMI_WRN__GPMI_WRN 0x0190 +MX28_PAD_GPMI_ALE__GPMI_ALE 0x01a0 +MX28_PAD_GPMI_CLE__GPMI_CLE 0x01b0 +MX28_PAD_GPMI_RESETN__GPMI_RESETN 0x01c0 +MX28_PAD_LCD_D00__LCD_D0 0x1000 +MX28_PAD_LCD_D01__LCD_D1 0x1010 +MX28_PAD_LCD_D02__LCD_D2 0x1020 +MX28_PAD_LCD_D03__LCD_D3 0x1030 +MX28_PAD_LCD_D04__LCD_D4 0x1040 +MX28_PAD_LCD_D05__LCD_D5 0x1050 +MX28_PAD_LCD_D06__LCD_D6 0x1060 +MX28_PAD_LCD_D07__LCD_D7 0x1070 +MX28_PAD_LCD_D08__LCD_D8 0x1080 +MX28_PAD_LCD_D09__LCD_D9 0x1090 +MX28_PAD_LCD_D10__LCD_D10 0x10a0 +MX28_PAD_LCD_D11__LCD_D11 0x10b0 +MX28_PAD_LCD_D12__LCD_D12 0x10c0 +MX28_PAD_LCD_D13__LCD_D13 0x10d0 +MX28_PAD_LCD_D14__LCD_D14 0x10e0 +MX28_PAD_LCD_D15__LCD_D15 0x10f0 +MX28_PAD_LCD_D16__LCD_D16 0x1100 +MX28_PAD_LCD_D17__LCD_D17 0x1110 +MX28_PAD_LCD_D18__LCD_D18 0x1120 +MX28_PAD_LCD_D19__LCD_D19 0x1130 +MX28_PAD_LCD_D20__LCD_D20 0x1140 +MX28_PAD_LCD_D21__LCD_D21 0x1150 +MX28_PAD_LCD_D22__LCD_D22 0x1160 +MX28_PAD_LCD_D23__LCD_D23 0x1170 +MX28_PAD_LCD_RD_E__LCD_RD_E 0x1180 +MX28_PAD_LCD_WR_RWN__LCD_WR_RWN 0x1190 +MX28_PAD_LCD_RS__LCD_RS 0x11a0 +MX28_PAD_LCD_CS__LCD_CS 0x11b0 +MX28_PAD_LCD_VSYNC__LCD_VSYNC 0x11c0 +MX28_PAD_LCD_HSYNC__LCD_HSYNC 0x11d0 +MX28_PAD_LCD_DOTCLK__LCD_DOTCLK 0x11e0 +MX28_PAD_LCD_ENABLE__LCD_ENABLE 0x11f0 +MX28_PAD_SSP0_DATA0__SSP0_D0 0x2000 +MX28_PAD_SSP0_DATA1__SSP0_D1 0x2010 +MX28_PAD_SSP0_DATA2__SSP0_D2 0x2020 +MX28_PAD_SSP0_DATA3__SSP0_D3 0x2030 +MX28_PAD_SSP0_DATA4__SSP0_D4 0x2040 +MX28_PAD_SSP0_DATA5__SSP0_D5 0x2050 +MX28_PAD_SSP0_DATA6__SSP0_D6 0x2060 +MX28_PAD_SSP0_DATA7__SSP0_D7 0x2070 +MX28_PAD_SSP0_CMD__SSP0_CMD 0x2080 +MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT 0x2090 +MX28_PAD_SSP0_SCK__SSP0_SCK 0x20a0 +MX28_PAD_SSP1_SCK__SSP1_SCK 0x20c0 +MX28_PAD_SSP1_CMD__SSP1_CMD 0x20d0 +MX28_PAD_SSP1_DATA0__SSP1_D0 0x20e0 +MX28_PAD_SSP1_DATA3__SSP1_D3 0x20f0 +MX28_PAD_SSP2_SCK__SSP2_SCK 0x2100 +MX28_PAD_SSP2_MOSI__SSP2_CMD 0x2110 +MX28_PAD_SSP2_MISO__SSP2_D0 0x2120 +MX28_PAD_SSP2_SS0__SSP2_D3 0x2130 +MX28_PAD_SSP2_SS1__SSP2_D4 0x2140 +MX28_PAD_SSP2_SS2__SSP2_D5 0x2150 +MX28_PAD_SSP3_SCK__SSP3_SCK 0x2180 +MX28_PAD_SSP3_MOSI__SSP3_CMD 0x2190 +MX28_PAD_SSP3_MISO__SSP3_D0 0x21a0 +MX28_PAD_SSP3_SS0__SSP3_D3 0x21b0 +MX28_PAD_AUART0_RX__AUART0_RX 0x3000 +MX28_PAD_AUART0_TX__AUART0_TX 0x3010 +MX28_PAD_AUART0_CTS__AUART0_CTS 0x3020 +MX28_PAD_AUART0_RTS__AUART0_RTS 0x3030 +MX28_PAD_AUART1_RX__AUART1_RX 0x3040 +MX28_PAD_AUART1_TX__AUART1_TX 0x3050 +MX28_PAD_AUART1_CTS__AUART1_CTS 0x3060 +MX28_PAD_AUART1_RTS__AUART1_RTS 0x3070 +MX28_PAD_AUART2_RX__AUART2_RX 0x3080 +MX28_PAD_AUART2_TX__AUART2_TX 0x3090 +MX28_PAD_AUART2_CTS__AUART2_CTS 0x30a0 +MX28_PAD_AUART2_RTS__AUART2_RTS 0x30b0 +MX28_PAD_AUART3_RX__AUART3_RX 0x30c0 +MX28_PAD_AUART3_TX__AUART3_TX 0x30d0 +MX28_PAD_AUART3_CTS__AUART3_CTS 0x30e0 +MX28_PAD_AUART3_RTS__AUART3_RTS 0x30f0 +MX28_PAD_PWM0__PWM_0 0x3100 +MX28_PAD_PWM1__PWM_1 0x3110 +MX28_PAD_PWM2__PWM_2 0x3120 +MX28_PAD_SAIF0_MCLK__SAIF0_MCLK 0x3140 +MX28_PAD_SAIF0_LRCLK__SAIF0_LRCLK 0x3150 +MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK 0x3160 +MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0 0x3170 +MX28_PAD_I2C0_SCL__I2C0_SCL 0x3180 +MX28_PAD_I2C0_SDA__I2C0_SDA 0x3190 +MX28_PAD_SAIF1_SDATA0__SAIF1_SDATA0 0x31a0 +MX28_PAD_SPDIF__SPDIF_TX 0x31b0 +MX28_PAD_PWM3__PWM_3 0x31c0 +MX28_PAD_PWM4__PWM_4 0x31d0 +MX28_PAD_LCD_RESET__LCD_RESET 0x31e0 +MX28_PAD_ENET0_MDC__ENET0_MDC 0x4000 +MX28_PAD_ENET0_MDIO__ENET0_MDIO 0x4010 +MX28_PAD_ENET0_RX_EN__ENET0_RX_EN 0x4020 +MX28_PAD_ENET0_RXD0__ENET0_RXD0 0x4030 +MX28_PAD_ENET0_RXD1__ENET0_RXD1 0x4040 +MX28_PAD_ENET0_TX_CLK__ENET0_TX_CLK 0x4050 +MX28_PAD_ENET0_TX_EN__ENET0_TX_EN 0x4060 +MX28_PAD_ENET0_TXD0__ENET0_TXD0 0x4070 +MX28_PAD_ENET0_TXD1__ENET0_TXD1 0x4080 +MX28_PAD_ENET0_RXD2__ENET0_RXD2 0x4090 +MX28_PAD_ENET0_RXD3__ENET0_RXD3 0x40a0 +MX28_PAD_ENET0_TXD2__ENET0_TXD2 0x40b0 +MX28_PAD_ENET0_TXD3__ENET0_TXD3 0x40c0 +MX28_PAD_ENET0_RX_CLK__ENET0_RX_CLK 0x40d0 +MX28_PAD_ENET0_COL__ENET0_COL 0x40e0 +MX28_PAD_ENET0_CRS__ENET0_CRS 0x40f0 +MX28_PAD_ENET_CLK__CLKCTRL_ENET 0x4100 +MX28_PAD_JTAG_RTCK__JTAG_RTCK 0x4140 +MX28_PAD_EMI_D00__EMI_DATA0 0x5000 +MX28_PAD_EMI_D01__EMI_DATA1 0x5010 +MX28_PAD_EMI_D02__EMI_DATA2 0x5020 +MX28_PAD_EMI_D03__EMI_DATA3 0x5030 +MX28_PAD_EMI_D04__EMI_DATA4 0x5040 +MX28_PAD_EMI_D05__EMI_DATA5 0x5050 +MX28_PAD_EMI_D06__EMI_DATA6 0x5060 +MX28_PAD_EMI_D07__EMI_DATA7 0x5070 +MX28_PAD_EMI_D08__EMI_DATA8 0x5080 +MX28_PAD_EMI_D09__EMI_DATA9 0x5090 +MX28_PAD_EMI_D10__EMI_DATA10 0x50a0 +MX28_PAD_EMI_D11__EMI_DATA11 0x50b0 +MX28_PAD_EMI_D12__EMI_DATA12 0x50c0 +MX28_PAD_EMI_D13__EMI_DATA13 0x50d0 +MX28_PAD_EMI_D14__EMI_DATA14 0x50e0 +MX28_PAD_EMI_D15__EMI_DATA15 0x50f0 +MX28_PAD_EMI_ODT0__EMI_ODT0 0x5100 +MX28_PAD_EMI_DQM0__EMI_DQM0 0x5110 +MX28_PAD_EMI_ODT1__EMI_ODT1 0x5120 +MX28_PAD_EMI_DQM1__EMI_DQM1 0x5130 +MX28_PAD_EMI_DDR_OPEN_FB__EMI_DDR_OPEN_FEEDBACK 0x5140 +MX28_PAD_EMI_CLK__EMI_CLK 0x5150 +MX28_PAD_EMI_DQS0__EMI_DQS0 0x5160 +MX28_PAD_EMI_DQS1__EMI_DQS1 0x5170 +MX28_PAD_EMI_DDR_OPEN__EMI_DDR_OPEN 0x51a0 +MX28_PAD_EMI_A00__EMI_ADDR0 0x6000 +MX28_PAD_EMI_A01__EMI_ADDR1 0x6010 +MX28_PAD_EMI_A02__EMI_ADDR2 0x6020 +MX28_PAD_EMI_A03__EMI_ADDR3 0x6030 +MX28_PAD_EMI_A04__EMI_ADDR4 0x6040 +MX28_PAD_EMI_A05__EMI_ADDR5 0x6050 +MX28_PAD_EMI_A06__EMI_ADDR6 0x6060 +MX28_PAD_EMI_A07__EMI_ADDR7 0x6070 +MX28_PAD_EMI_A08__EMI_ADDR8 0x6080 +MX28_PAD_EMI_A09__EMI_ADDR9 0x6090 +MX28_PAD_EMI_A10__EMI_ADDR10 0x60a0 +MX28_PAD_EMI_A11__EMI_ADDR11 0x60b0 +MX28_PAD_EMI_A12__EMI_ADDR12 0x60c0 +MX28_PAD_EMI_A13__EMI_ADDR13 0x60d0 +MX28_PAD_EMI_A14__EMI_ADDR14 0x60e0 +MX28_PAD_EMI_BA0__EMI_BA0 0x6100 +MX28_PAD_EMI_BA1__EMI_BA1 0x6110 +MX28_PAD_EMI_BA2__EMI_BA2 0x6120 +MX28_PAD_EMI_CASN__EMI_CASN 0x6130 +MX28_PAD_EMI_RASN__EMI_RASN 0x6140 +MX28_PAD_EMI_WEN__EMI_WEN 0x6150 +MX28_PAD_EMI_CE0N__EMI_CE0N 0x6160 +MX28_PAD_EMI_CE1N__EMI_CE1N 0x6170 +MX28_PAD_EMI_CKE__EMI_CKE 0x6180 +MX28_PAD_GPMI_D00__SSP1_D0 0x0001 +MX28_PAD_GPMI_D01__SSP1_D1 0x0011 +MX28_PAD_GPMI_D02__SSP1_D2 0x0021 +MX28_PAD_GPMI_D03__SSP1_D3 0x0031 +MX28_PAD_GPMI_D04__SSP1_D4 0x0041 +MX28_PAD_GPMI_D05__SSP1_D5 0x0051 +MX28_PAD_GPMI_D06__SSP1_D6 0x0061 +MX28_PAD_GPMI_D07__SSP1_D7 0x0071 +MX28_PAD_GPMI_CE0N__SSP3_D0 0x0101 +MX28_PAD_GPMI_CE1N__SSP3_D3 0x0111 +MX28_PAD_GPMI_CE2N__CAN1_TX 0x0121 +MX28_PAD_GPMI_CE3N__CAN1_RX 0x0131 +MX28_PAD_GPMI_RDY0__SSP1_CARD_DETECT 0x0141 +MX28_PAD_GPMI_RDY1__SSP1_CMD 0x0151 +MX28_PAD_GPMI_RDY2__CAN0_TX 0x0161 +MX28_PAD_GPMI_RDY3__CAN0_RX 0x0171 +MX28_PAD_GPMI_RDN__SSP3_SCK 0x0181 +MX28_PAD_GPMI_WRN__SSP1_SCK 0x0191 +MX28_PAD_GPMI_ALE__SSP3_D1 0x01a1 +MX28_PAD_GPMI_CLE__SSP3_D2 0x01b1 +MX28_PAD_GPMI_RESETN__SSP3_CMD 0x01c1 +MX28_PAD_LCD_D03__ETM_DA8 0x1031 +MX28_PAD_LCD_D04__ETM_DA9 0x1041 +MX28_PAD_LCD_D08__ETM_DA3 0x1081 +MX28_PAD_LCD_D09__ETM_DA4 0x1091 +MX28_PAD_LCD_D20__ENET1_1588_EVENT2_OUT 0x1141 +MX28_PAD_LCD_D21__ENET1_1588_EVENT2_IN 0x1151 +MX28_PAD_LCD_D22__ENET1_1588_EVENT3_OUT 0x1161 +MX28_PAD_LCD_D23__ENET1_1588_EVENT3_IN 0x1171 +MX28_PAD_LCD_RD_E__LCD_VSYNC 0x1181 +MX28_PAD_LCD_WR_RWN__LCD_HSYNC 0x1191 +MX28_PAD_LCD_RS__LCD_DOTCLK 0x11a1 +MX28_PAD_LCD_CS__LCD_ENABLE 0x11b1 +MX28_PAD_LCD_VSYNC__SAIF1_SDATA0 0x11c1 +MX28_PAD_LCD_HSYNC__SAIF1_SDATA1 0x11d1 +MX28_PAD_LCD_DOTCLK__SAIF1_MCLK 0x11e1 +MX28_PAD_SSP0_DATA4__SSP2_D0 0x2041 +MX28_PAD_SSP0_DATA5__SSP2_D3 0x2051 +MX28_PAD_SSP0_DATA6__SSP2_CMD 0x2061 +MX28_PAD_SSP0_DATA7__SSP2_SCK 0x2071 +MX28_PAD_SSP1_SCK__SSP2_D1 0x20c1 +MX28_PAD_SSP1_CMD__SSP2_D2 0x20d1 +MX28_PAD_SSP1_DATA0__SSP2_D6 0x20e1 +MX28_PAD_SSP1_DATA3__SSP2_D7 0x20f1 +MX28_PAD_SSP2_SCK__AUART2_RX 0x2101 +MX28_PAD_SSP2_MOSI__AUART2_TX 0x2111 +MX28_PAD_SSP2_MISO__AUART3_RX 0x2121 +MX28_PAD_SSP2_SS0__AUART3_TX 0x2131 +MX28_PAD_SSP2_SS1__SSP2_D1 0x2141 +MX28_PAD_SSP2_SS2__SSP2_D2 0x2151 +MX28_PAD_SSP3_SCK__AUART4_TX 0x2181 +MX28_PAD_SSP3_MOSI__AUART4_RX 0x2191 +MX28_PAD_SSP3_MISO__AUART4_RTS 0x21a1 +MX28_PAD_SSP3_SS0__AUART4_CTS 0x21b1 +MX28_PAD_AUART0_RX__I2C0_SCL 0x3001 +MX28_PAD_AUART0_TX__I2C0_SDA 0x3011 +MX28_PAD_AUART0_CTS__AUART4_RX 0x3021 +MX28_PAD_AUART0_RTS__AUART4_TX 0x3031 +MX28_PAD_AUART1_RX__SSP2_CARD_DETECT 0x3041 +MX28_PAD_AUART1_TX__SSP3_CARD_DETECT 0x3051 +MX28_PAD_AUART1_CTS__USB0_OVERCURRENT 0x3061 +MX28_PAD_AUART1_RTS__USB0_ID 0x3071 +MX28_PAD_AUART2_RX__SSP3_D1 0x3081 +MX28_PAD_AUART2_TX__SSP3_D2 0x3091 +MX28_PAD_AUART2_CTS__I2C1_SCL 0x30a1 +MX28_PAD_AUART2_RTS__I2C1_SDA 0x30b1 +MX28_PAD_AUART3_RX__CAN0_TX 0x30c1 +MX28_PAD_AUART3_TX__CAN0_RX 0x30d1 +MX28_PAD_AUART3_CTS__CAN1_TX 0x30e1 +MX28_PAD_AUART3_RTS__CAN1_RX 0x30f1 +MX28_PAD_PWM0__I2C1_SCL 0x3101 +MX28_PAD_PWM1__I2C1_SDA 0x3111 +MX28_PAD_PWM2__USB0_ID 0x3121 +MX28_PAD_SAIF0_MCLK__PWM_3 0x3141 +MX28_PAD_SAIF0_LRCLK__PWM_4 0x3151 +MX28_PAD_SAIF0_BITCLK__PWM_5 0x3161 +MX28_PAD_SAIF0_SDATA0__PWM_6 0x3171 +MX28_PAD_I2C0_SCL__TIMROT_ROTARYA 0x3181 +MX28_PAD_I2C0_SDA__TIMROT_ROTARYB 0x3191 +MX28_PAD_SAIF1_SDATA0__PWM_7 0x31a1 +MX28_PAD_LCD_RESET__LCD_VSYNC 0x31e1 +MX28_PAD_ENET0_MDC__GPMI_CE4N 0x4001 +MX28_PAD_ENET0_MDIO__GPMI_CE5N 0x4011 +MX28_PAD_ENET0_RX_EN__GPMI_CE6N 0x4021 +MX28_PAD_ENET0_RXD0__GPMI_CE7N 0x4031 +MX28_PAD_ENET0_RXD1__GPMI_READY4 0x4041 +MX28_PAD_ENET0_TX_CLK__HSADC_TRIGGER 0x4051 +MX28_PAD_ENET0_TX_EN__GPMI_READY5 0x4061 +MX28_PAD_ENET0_TXD0__GPMI_READY6 0x4071 +MX28_PAD_ENET0_TXD1__GPMI_READY7 0x4081 +MX28_PAD_ENET0_RXD2__ENET1_RXD0 0x4091 +MX28_PAD_ENET0_RXD3__ENET1_RXD1 0x40a1 +MX28_PAD_ENET0_TXD2__ENET1_TXD0 0x40b1 +MX28_PAD_ENET0_TXD3__ENET1_TXD1 0x40c1 +MX28_PAD_ENET0_RX_CLK__ENET0_RX_ER 0x40d1 +MX28_PAD_ENET0_COL__ENET1_TX_EN 0x40e1 +MX28_PAD_ENET0_CRS__ENET1_RX_EN 0x40f1 +MX28_PAD_GPMI_CE2N__ENET0_RX_ER 0x0122 +MX28_PAD_GPMI_CE3N__SAIF1_MCLK 0x0132 +MX28_PAD_GPMI_RDY0__USB0_ID 0x0142 +MX28_PAD_GPMI_RDY2__ENET0_TX_ER 0x0162 +MX28_PAD_GPMI_RDY3__HSADC_TRIGGER 0x0172 +MX28_PAD_GPMI_ALE__SSP3_D4 0x01a2 +MX28_PAD_GPMI_CLE__SSP3_D5 0x01b2 +MX28_PAD_LCD_D00__ETM_DA0 0x1002 +MX28_PAD_LCD_D01__ETM_DA1 0x1012 +MX28_PAD_LCD_D02__ETM_DA2 0x1022 +MX28_PAD_LCD_D03__ETM_DA3 0x1032 +MX28_PAD_LCD_D04__ETM_DA4 0x1042 +MX28_PAD_LCD_D05__ETM_DA5 0x1052 +MX28_PAD_LCD_D06__ETM_DA6 0x1062 +MX28_PAD_LCD_D07__ETM_DA7 0x1072 +MX28_PAD_LCD_D08__ETM_DA8 0x1082 +MX28_PAD_LCD_D09__ETM_DA9 0x1092 +MX28_PAD_LCD_D10__ETM_DA10 0x10a2 +MX28_PAD_LCD_D11__ETM_DA11 0x10b2 +MX28_PAD_LCD_D12__ETM_DA12 0x10c2 +MX28_PAD_LCD_D13__ETM_DA13 0x10d2 +MX28_PAD_LCD_D14__ETM_DA14 0x10e2 +MX28_PAD_LCD_D15__ETM_DA15 0x10f2 +MX28_PAD_LCD_D16__ETM_DA7 0x1102 +MX28_PAD_LCD_D17__ETM_DA6 0x1112 +MX28_PAD_LCD_D18__ETM_DA5 0x1122 +MX28_PAD_LCD_D19__ETM_DA4 0x1132 +MX28_PAD_LCD_D20__ETM_DA3 0x1142 +MX28_PAD_LCD_D21__ETM_DA2 0x1152 +MX28_PAD_LCD_D22__ETM_DA1 0x1162 +MX28_PAD_LCD_D23__ETM_DA0 0x1172 +MX28_PAD_LCD_RD_E__ETM_TCTL 0x1182 +MX28_PAD_LCD_WR_RWN__ETM_TCLK 0x1192 +MX28_PAD_LCD_HSYNC__ETM_TCTL 0x11d2 +MX28_PAD_LCD_DOTCLK__ETM_TCLK 0x11e2 +MX28_PAD_SSP1_SCK__ENET0_1588_EVENT2_OUT 0x20c2 +MX28_PAD_SSP1_CMD__ENET0_1588_EVENT2_IN 0x20d2 +MX28_PAD_SSP1_DATA0__ENET0_1588_EVENT3_OUT 0x20e2 +MX28_PAD_SSP1_DATA3__ENET0_1588_EVENT3_IN 0x20f2 +MX28_PAD_SSP2_SCK__SAIF0_SDATA1 0x2102 +MX28_PAD_SSP2_MOSI__SAIF0_SDATA2 0x2112 +MX28_PAD_SSP2_MISO__SAIF1_SDATA1 0x2122 +MX28_PAD_SSP2_SS0__SAIF1_SDATA2 0x2132 +MX28_PAD_SSP2_SS1__USB1_OVERCURRENT 0x2142 +MX28_PAD_SSP2_SS2__USB0_OVERCURRENT 0x2152 +MX28_PAD_SSP3_SCK__ENET1_1588_EVENT0_OUT 0x2182 +MX28_PAD_SSP3_MOSI__ENET1_1588_EVENT0_IN 0x2192 +MX28_PAD_SSP3_MISO__ENET1_1588_EVENT1_OUT 0x21a2 +MX28_PAD_SSP3_SS0__ENET1_1588_EVENT1_IN 0x21b2 +MX28_PAD_AUART0_RX__DUART_CTS 0x3002 +MX28_PAD_AUART0_TX__DUART_RTS 0x3012 +MX28_PAD_AUART0_CTS__DUART_RX 0x3022 +MX28_PAD_AUART0_RTS__DUART_TX 0x3032 +MX28_PAD_AUART1_RX__PWM_0 0x3042 +MX28_PAD_AUART1_TX__PWM_1 0x3052 +MX28_PAD_AUART1_CTS__TIMROT_ROTARYA 0x3062 +MX28_PAD_AUART1_RTS__TIMROT_ROTARYB 0x3072 +MX28_PAD_AUART2_RX__SSP3_D4 0x3082 +MX28_PAD_AUART2_TX__SSP3_D5 0x3092 +MX28_PAD_AUART2_CTS__SAIF1_BITCLK 0x30a2 +MX28_PAD_AUART2_RTS__SAIF1_LRCLK 0x30b2 +MX28_PAD_AUART3_RX__ENET0_1588_EVENT0_OUT 0x30c2 +MX28_PAD_AUART3_TX__ENET0_1588_EVENT0_IN 0x30d2 +MX28_PAD_AUART3_CTS__ENET0_1588_EVENT1_OUT 0x30e2 +MX28_PAD_AUART3_RTS__ENET0_1588_EVENT1_IN 0x30f2 +MX28_PAD_PWM0__DUART_RX 0x3102 +MX28_PAD_PWM1__DUART_TX 0x3112 +MX28_PAD_PWM2__USB1_OVERCURRENT 0x3122 +MX28_PAD_SAIF0_MCLK__AUART4_CTS 0x3142 +MX28_PAD_SAIF0_LRCLK__AUART4_RTS 0x3152 +MX28_PAD_SAIF0_BITCLK__AUART4_RX 0x3162 +MX28_PAD_SAIF0_SDATA0__AUART4_TX 0x3172 +MX28_PAD_I2C0_SCL__DUART_RX 0x3182 +MX28_PAD_I2C0_SDA__DUART_TX 0x3192 +MX28_PAD_SAIF1_SDATA0__SAIF0_SDATA1 0x31a2 +MX28_PAD_SPDIF__ENET1_RX_ER 0x31b2 +MX28_PAD_ENET0_MDC__SAIF0_SDATA1 0x4002 +MX28_PAD_ENET0_MDIO__SAIF0_SDATA2 0x4012 +MX28_PAD_ENET0_RX_EN__SAIF1_SDATA1 0x4022 +MX28_PAD_ENET0_RXD0__SAIF1_SDATA2 0x4032 +MX28_PAD_ENET0_TX_CLK__ENET0_1588_EVENT2_OUT 0x4052 +MX28_PAD_ENET0_RXD2__ENET0_1588_EVENT0_OUT 0x4092 +MX28_PAD_ENET0_RXD3__ENET0_1588_EVENT0_IN 0x40a2 +MX28_PAD_ENET0_TXD2__ENET0_1588_EVENT1_OUT 0x40b2 +MX28_PAD_ENET0_TXD3__ENET0_1588_EVENT1_IN 0x40c2 +MX28_PAD_ENET0_RX_CLK__ENET0_1588_EVENT2_IN 0x40d2 +MX28_PAD_ENET0_COL__ENET0_1588_EVENT3_OUT 0x40e2 +MX28_PAD_ENET0_CRS__ENET0_1588_EVENT3_IN 0x40f2 +MX28_PAD_GPMI_D00__GPIO_0_0 0x0003 +MX28_PAD_GPMI_D01__GPIO_0_1 0x0013 +MX28_PAD_GPMI_D02__GPIO_0_2 0x0023 +MX28_PAD_GPMI_D03__GPIO_0_3 0x0033 +MX28_PAD_GPMI_D04__GPIO_0_4 0x0043 +MX28_PAD_GPMI_D05__GPIO_0_5 0x0053 +MX28_PAD_GPMI_D06__GPIO_0_6 0x0063 +MX28_PAD_GPMI_D07__GPIO_0_7 0x0073 +MX28_PAD_GPMI_CE0N__GPIO_0_16 0x0103 +MX28_PAD_GPMI_CE1N__GPIO_0_17 0x0113 +MX28_PAD_GPMI_CE2N__GPIO_0_18 0x0123 +MX28_PAD_GPMI_CE3N__GPIO_0_19 0x0133 +MX28_PAD_GPMI_RDY0__GPIO_0_20 0x0143 +MX28_PAD_GPMI_RDY1__GPIO_0_21 0x0153 +MX28_PAD_GPMI_RDY2__GPIO_0_22 0x0163 +MX28_PAD_GPMI_RDY3__GPIO_0_23 0x0173 +MX28_PAD_GPMI_RDN__GPIO_0_24 0x0183 +MX28_PAD_GPMI_WRN__GPIO_0_25 0x0193 +MX28_PAD_GPMI_ALE__GPIO_0_26 0x01a3 +MX28_PAD_GPMI_CLE__GPIO_0_27 0x01b3 +MX28_PAD_GPMI_RESETN__GPIO_0_28 0x01c3 +MX28_PAD_LCD_D00__GPIO_1_0 0x1003 +MX28_PAD_LCD_D01__GPIO_1_1 0x1013 +MX28_PAD_LCD_D02__GPIO_1_2 0x1023 +MX28_PAD_LCD_D03__GPIO_1_3 0x1033 +MX28_PAD_LCD_D04__GPIO_1_4 0x1043 +MX28_PAD_LCD_D05__GPIO_1_5 0x1053 +MX28_PAD_LCD_D06__GPIO_1_6 0x1063 +MX28_PAD_LCD_D07__GPIO_1_7 0x1073 +MX28_PAD_LCD_D08__GPIO_1_8 0x1083 +MX28_PAD_LCD_D09__GPIO_1_9 0x1093 +MX28_PAD_LCD_D10__GPIO_1_10 0x10a3 +MX28_PAD_LCD_D11__GPIO_1_11 0x10b3 +MX28_PAD_LCD_D12__GPIO_1_12 0x10c3 +MX28_PAD_LCD_D13__GPIO_1_13 0x10d3 +MX28_PAD_LCD_D14__GPIO_1_14 0x10e3 +MX28_PAD_LCD_D15__GPIO_1_15 0x10f3 +MX28_PAD_LCD_D16__GPIO_1_16 0x1103 +MX28_PAD_LCD_D17__GPIO_1_17 0x1113 +MX28_PAD_LCD_D18__GPIO_1_18 0x1123 +MX28_PAD_LCD_D19__GPIO_1_19 0x1133 +MX28_PAD_LCD_D20__GPIO_1_20 0x1143 +MX28_PAD_LCD_D21__GPIO_1_21 0x1153 +MX28_PAD_LCD_D22__GPIO_1_22 0x1163 +MX28_PAD_LCD_D23__GPIO_1_23 0x1173 +MX28_PAD_LCD_RD_E__GPIO_1_24 0x1183 +MX28_PAD_LCD_WR_RWN__GPIO_1_25 0x1193 +MX28_PAD_LCD_RS__GPIO_1_26 0x11a3 +MX28_PAD_LCD_CS__GPIO_1_27 0x11b3 +MX28_PAD_LCD_VSYNC__GPIO_1_28 0x11c3 +MX28_PAD_LCD_HSYNC__GPIO_1_29 0x11d3 +MX28_PAD_LCD_DOTCLK__GPIO_1_30 0x11e3 +MX28_PAD_LCD_ENABLE__GPIO_1_31 0x11f3 +MX28_PAD_SSP0_DATA0__GPIO_2_0 0x2003 +MX28_PAD_SSP0_DATA1__GPIO_2_1 0x2013 +MX28_PAD_SSP0_DATA2__GPIO_2_2 0x2023 +MX28_PAD_SSP0_DATA3__GPIO_2_3 0x2033 +MX28_PAD_SSP0_DATA4__GPIO_2_4 0x2043 +MX28_PAD_SSP0_DATA5__GPIO_2_5 0x2053 +MX28_PAD_SSP0_DATA6__GPIO_2_6 0x2063 +MX28_PAD_SSP0_DATA7__GPIO_2_7 0x2073 +MX28_PAD_SSP0_CMD__GPIO_2_8 0x2083 +MX28_PAD_SSP0_DETECT__GPIO_2_9 0x2093 +MX28_PAD_SSP0_SCK__GPIO_2_10 0x20a3 +MX28_PAD_SSP1_SCK__GPIO_2_12 0x20c3 +MX28_PAD_SSP1_CMD__GPIO_2_13 0x20d3 +MX28_PAD_SSP1_DATA0__GPIO_2_14 0x20e3 +MX28_PAD_SSP1_DATA3__GPIO_2_15 0x20f3 +MX28_PAD_SSP2_SCK__GPIO_2_16 0x2103 +MX28_PAD_SSP2_MOSI__GPIO_2_17 0x2113 +MX28_PAD_SSP2_MISO__GPIO_2_18 0x2123 +MX28_PAD_SSP2_SS0__GPIO_2_19 0x2133 +MX28_PAD_SSP2_SS1__GPIO_2_20 0x2143 +MX28_PAD_SSP2_SS2__GPIO_2_21 0x2153 +MX28_PAD_SSP3_SCK__GPIO_2_24 0x2183 +MX28_PAD_SSP3_MOSI__GPIO_2_25 0x2193 +MX28_PAD_SSP3_MISO__GPIO_2_26 0x21a3 +MX28_PAD_SSP3_SS0__GPIO_2_27 0x21b3 +MX28_PAD_AUART0_RX__GPIO_3_0 0x3003 +MX28_PAD_AUART0_TX__GPIO_3_1 0x3013 +MX28_PAD_AUART0_CTS__GPIO_3_2 0x3023 +MX28_PAD_AUART0_RTS__GPIO_3_3 0x3033 +MX28_PAD_AUART1_RX__GPIO_3_4 0x3043 +MX28_PAD_AUART1_TX__GPIO_3_5 0x3053 +MX28_PAD_AUART1_CTS__GPIO_3_6 0x3063 +MX28_PAD_AUART1_RTS__GPIO_3_7 0x3073 +MX28_PAD_AUART2_RX__GPIO_3_8 0x3083 +MX28_PAD_AUART2_TX__GPIO_3_9 0x3093 +MX28_PAD_AUART2_CTS__GPIO_3_10 0x30a3 +MX28_PAD_AUART2_RTS__GPIO_3_11 0x30b3 +MX28_PAD_AUART3_RX__GPIO_3_12 0x30c3 +MX28_PAD_AUART3_TX__GPIO_3_13 0x30d3 +MX28_PAD_AUART3_CTS__GPIO_3_14 0x30e3 +MX28_PAD_AUART3_RTS__GPIO_3_15 0x30f3 +MX28_PAD_PWM0__GPIO_3_16 0x3103 +MX28_PAD_PWM1__GPIO_3_17 0x3113 +MX28_PAD_PWM2__GPIO_3_18 0x3123 +MX28_PAD_SAIF0_MCLK__GPIO_3_20 0x3143 +MX28_PAD_SAIF0_LRCLK__GPIO_3_21 0x3153 +MX28_PAD_SAIF0_BITCLK__GPIO_3_22 0x3163 +MX28_PAD_SAIF0_SDATA0__GPIO_3_23 0x3173 +MX28_PAD_I2C0_SCL__GPIO_3_24 0x3183 +MX28_PAD_I2C0_SDA__GPIO_3_25 0x3193 +MX28_PAD_SAIF1_SDATA0__GPIO_3_26 0x31a3 +MX28_PAD_SPDIF__GPIO_3_27 0x31b3 +MX28_PAD_PWM3__GPIO_3_28 0x31c3 +MX28_PAD_PWM4__GPIO_3_29 0x31d3 +MX28_PAD_LCD_RESET__GPIO_3_30 0x31e3 +MX28_PAD_ENET0_MDC__GPIO_4_0 0x4003 +MX28_PAD_ENET0_MDIO__GPIO_4_1 0x4013 +MX28_PAD_ENET0_RX_EN__GPIO_4_2 0x4023 +MX28_PAD_ENET0_RXD0__GPIO_4_3 0x4033 +MX28_PAD_ENET0_RXD1__GPIO_4_4 0x4043 +MX28_PAD_ENET0_TX_CLK__GPIO_4_5 0x4053 +MX28_PAD_ENET0_TX_EN__GPIO_4_6 0x4063 +MX28_PAD_ENET0_TXD0__GPIO_4_7 0x4073 +MX28_PAD_ENET0_TXD1__GPIO_4_8 0x4083 +MX28_PAD_ENET0_RXD2__GPIO_4_9 0x4093 +MX28_PAD_ENET0_RXD3__GPIO_4_10 0x40a3 +MX28_PAD_ENET0_TXD2__GPIO_4_11 0x40b3 +MX28_PAD_ENET0_TXD3__GPIO_4_12 0x40c3 +MX28_PAD_ENET0_RX_CLK__GPIO_4_13 0x40d3 +MX28_PAD_ENET0_COL__GPIO_4_14 0x40e3 +MX28_PAD_ENET0_CRS__GPIO_4_15 0x40f3 +MX28_PAD_ENET_CLK__GPIO_4_16 0x4103 +MX28_PAD_JTAG_RTCK__GPIO_4_20 0x4143 + +Valid values for i.MX23 pinmux-id: + +pinmux id +------ -- +MX23_PAD_GPMI_D00__GPMI_D00 0x0000 +MX23_PAD_GPMI_D01__GPMI_D01 0x0010 +MX23_PAD_GPMI_D02__GPMI_D02 0x0020 +MX23_PAD_GPMI_D03__GPMI_D03 0x0030 +MX23_PAD_GPMI_D04__GPMI_D04 0x0040 +MX23_PAD_GPMI_D05__GPMI_D05 0x0050 +MX23_PAD_GPMI_D06__GPMI_D06 0x0060 +MX23_PAD_GPMI_D07__GPMI_D07 0x0070 +MX23_PAD_GPMI_D08__GPMI_D08 0x0080 +MX23_PAD_GPMI_D09__GPMI_D09 0x0090 +MX23_PAD_GPMI_D10__GPMI_D10 0x00a0 +MX23_PAD_GPMI_D11__GPMI_D11 0x00b0 +MX23_PAD_GPMI_D12__GPMI_D12 0x00c0 +MX23_PAD_GPMI_D13__GPMI_D13 0x00d0 +MX23_PAD_GPMI_D14__GPMI_D14 0x00e0 +MX23_PAD_GPMI_D15__GPMI_D15 0x00f0 +MX23_PAD_GPMI_CLE__GPMI_CLE 0x0100 +MX23_PAD_GPMI_ALE__GPMI_ALE 0x0110 +MX23_PAD_GPMI_CE2N__GPMI_CE2N 0x0120 +MX23_PAD_GPMI_RDY0__GPMI_RDY0 0x0130 +MX23_PAD_GPMI_RDY1__GPMI_RDY1 0x0140 +MX23_PAD_GPMI_RDY2__GPMI_RDY2 0x0150 +MX23_PAD_GPMI_RDY3__GPMI_RDY3 0x0160 +MX23_PAD_GPMI_WPN__GPMI_WPN 0x0170 +MX23_PAD_GPMI_WRN__GPMI_WRN 0x0180 +MX23_PAD_GPMI_RDN__GPMI_RDN 0x0190 +MX23_PAD_AUART1_CTS__AUART1_CTS 0x01a0 +MX23_PAD_AUART1_RTS__AUART1_RTS 0x01b0 +MX23_PAD_AUART1_RX__AUART1_RX 0x01c0 +MX23_PAD_AUART1_TX__AUART1_TX 0x01d0 +MX23_PAD_I2C_SCL__I2C_SCL 0x01e0 +MX23_PAD_I2C_SDA__I2C_SDA 0x01f0 +MX23_PAD_LCD_D00__LCD_D00 0x1000 +MX23_PAD_LCD_D01__LCD_D01 0x1010 +MX23_PAD_LCD_D02__LCD_D02 0x1020 +MX23_PAD_LCD_D03__LCD_D03 0x1030 +MX23_PAD_LCD_D04__LCD_D04 0x1040 +MX23_PAD_LCD_D05__LCD_D05 0x1050 +MX23_PAD_LCD_D06__LCD_D06 0x1060 +MX23_PAD_LCD_D07__LCD_D07 0x1070 +MX23_PAD_LCD_D08__LCD_D08 0x1080 +MX23_PAD_LCD_D09__LCD_D09 0x1090 +MX23_PAD_LCD_D10__LCD_D10 0x10a0 +MX23_PAD_LCD_D11__LCD_D11 0x10b0 +MX23_PAD_LCD_D12__LCD_D12 0x10c0 +MX23_PAD_LCD_D13__LCD_D13 0x10d0 +MX23_PAD_LCD_D14__LCD_D14 0x10e0 +MX23_PAD_LCD_D15__LCD_D15 0x10f0 +MX23_PAD_LCD_D16__LCD_D16 0x1100 +MX23_PAD_LCD_D17__LCD_D17 0x1110 +MX23_PAD_LCD_RESET__LCD_RESET 0x1120 +MX23_PAD_LCD_RS__LCD_RS 0x1130 +MX23_PAD_LCD_WR__LCD_WR 0x1140 +MX23_PAD_LCD_CS__LCD_CS 0x1150 +MX23_PAD_LCD_DOTCK__LCD_DOTCK 0x1160 +MX23_PAD_LCD_ENABLE__LCD_ENABLE 0x1170 +MX23_PAD_LCD_HSYNC__LCD_HSYNC 0x1180 +MX23_PAD_LCD_VSYNC__LCD_VSYNC 0x1190 +MX23_PAD_PWM0__PWM0 0x11a0 +MX23_PAD_PWM1__PWM1 0x11b0 +MX23_PAD_PWM2__PWM2 0x11c0 +MX23_PAD_PWM3__PWM3 0x11d0 +MX23_PAD_PWM4__PWM4 0x11e0 +MX23_PAD_SSP1_CMD__SSP1_CMD 0x2000 +MX23_PAD_SSP1_DETECT__SSP1_DETECT 0x2010 +MX23_PAD_SSP1_DATA0__SSP1_DATA0 0x2020 +MX23_PAD_SSP1_DATA1__SSP1_DATA1 0x2030 +MX23_PAD_SSP1_DATA2__SSP1_DATA2 0x2040 +MX23_PAD_SSP1_DATA3__SSP1_DATA3 0x2050 +MX23_PAD_SSP1_SCK__SSP1_SCK 0x2060 +MX23_PAD_ROTARYA__ROTARYA 0x2070 +MX23_PAD_ROTARYB__ROTARYB 0x2080 +MX23_PAD_EMI_A00__EMI_A00 0x2090 +MX23_PAD_EMI_A01__EMI_A01 0x20a0 +MX23_PAD_EMI_A02__EMI_A02 0x20b0 +MX23_PAD_EMI_A03__EMI_A03 0x20c0 +MX23_PAD_EMI_A04__EMI_A04 0x20d0 +MX23_PAD_EMI_A05__EMI_A05 0x20e0 +MX23_PAD_EMI_A06__EMI_A06 0x20f0 +MX23_PAD_EMI_A07__EMI_A07 0x2100 +MX23_PAD_EMI_A08__EMI_A08 0x2110 +MX23_PAD_EMI_A09__EMI_A09 0x2120 +MX23_PAD_EMI_A10__EMI_A10 0x2130 +MX23_PAD_EMI_A11__EMI_A11 0x2140 +MX23_PAD_EMI_A12__EMI_A12 0x2150 +MX23_PAD_EMI_BA0__EMI_BA0 0x2160 +MX23_PAD_EMI_BA1__EMI_BA1 0x2170 +MX23_PAD_EMI_CASN__EMI_CASN 0x2180 +MX23_PAD_EMI_CE0N__EMI_CE0N 0x2190 +MX23_PAD_EMI_CE1N__EMI_CE1N 0x21a0 +MX23_PAD_GPMI_CE1N__GPMI_CE1N 0x21b0 +MX23_PAD_GPMI_CE0N__GPMI_CE0N 0x21c0 +MX23_PAD_EMI_CKE__EMI_CKE 0x21d0 +MX23_PAD_EMI_RASN__EMI_RASN 0x21e0 +MX23_PAD_EMI_WEN__EMI_WEN 0x21f0 +MX23_PAD_EMI_D00__EMI_D00 0x3000 +MX23_PAD_EMI_D01__EMI_D01 0x3010 +MX23_PAD_EMI_D02__EMI_D02 0x3020 +MX23_PAD_EMI_D03__EMI_D03 0x3030 +MX23_PAD_EMI_D04__EMI_D04 0x3040 +MX23_PAD_EMI_D05__EMI_D05 0x3050 +MX23_PAD_EMI_D06__EMI_D06 0x3060 +MX23_PAD_EMI_D07__EMI_D07 0x3070 +MX23_PAD_EMI_D08__EMI_D08 0x3080 +MX23_PAD_EMI_D09__EMI_D09 0x3090 +MX23_PAD_EMI_D10__EMI_D10 0x30a0 +MX23_PAD_EMI_D11__EMI_D11 0x30b0 +MX23_PAD_EMI_D12__EMI_D12 0x30c0 +MX23_PAD_EMI_D13__EMI_D13 0x30d0 +MX23_PAD_EMI_D14__EMI_D14 0x30e0 +MX23_PAD_EMI_D15__EMI_D15 0x30f0 +MX23_PAD_EMI_DQM0__EMI_DQM0 0x3100 +MX23_PAD_EMI_DQM1__EMI_DQM1 0x3110 +MX23_PAD_EMI_DQS0__EMI_DQS0 0x3120 +MX23_PAD_EMI_DQS1__EMI_DQS1 0x3130 +MX23_PAD_EMI_CLK__EMI_CLK 0x3140 +MX23_PAD_EMI_CLKN__EMI_CLKN 0x3150 +MX23_PAD_GPMI_D00__LCD_D8 0x0001 +MX23_PAD_GPMI_D01__LCD_D9 0x0011 +MX23_PAD_GPMI_D02__LCD_D10 0x0021 +MX23_PAD_GPMI_D03__LCD_D11 0x0031 +MX23_PAD_GPMI_D04__LCD_D12 0x0041 +MX23_PAD_GPMI_D05__LCD_D13 0x0051 +MX23_PAD_GPMI_D06__LCD_D14 0x0061 +MX23_PAD_GPMI_D07__LCD_D15 0x0071 +MX23_PAD_GPMI_D08__LCD_D18 0x0081 +MX23_PAD_GPMI_D09__LCD_D19 0x0091 +MX23_PAD_GPMI_D10__LCD_D20 0x00a1 +MX23_PAD_GPMI_D11__LCD_D21 0x00b1 +MX23_PAD_GPMI_D12__LCD_D22 0x00c1 +MX23_PAD_GPMI_D13__LCD_D23 0x00d1 +MX23_PAD_GPMI_D14__AUART2_RX 0x00e1 +MX23_PAD_GPMI_D15__AUART2_TX 0x00f1 +MX23_PAD_GPMI_CLE__LCD_D16 0x0101 +MX23_PAD_GPMI_ALE__LCD_D17 0x0111 +MX23_PAD_GPMI_CE2N__ATA_A2 0x0121 +MX23_PAD_AUART1_RTS__IR_CLK 0x01b1 +MX23_PAD_AUART1_RX__IR_RX 0x01c1 +MX23_PAD_AUART1_TX__IR_TX 0x01d1 +MX23_PAD_I2C_SCL__GPMI_RDY2 0x01e1 +MX23_PAD_I2C_SDA__GPMI_CE2N 0x01f1 +MX23_PAD_LCD_D00__ETM_DA8 0x1001 +MX23_PAD_LCD_D01__ETM_DA9 0x1011 +MX23_PAD_LCD_D02__ETM_DA10 0x1021 +MX23_PAD_LCD_D03__ETM_DA11 0x1031 +MX23_PAD_LCD_D04__ETM_DA12 0x1041 +MX23_PAD_LCD_D05__ETM_DA13 0x1051 +MX23_PAD_LCD_D06__ETM_DA14 0x1061 +MX23_PAD_LCD_D07__ETM_DA15 0x1071 +MX23_PAD_LCD_D08__ETM_DA0 0x1081 +MX23_PAD_LCD_D09__ETM_DA1 0x1091 +MX23_PAD_LCD_D10__ETM_DA2 0x10a1 +MX23_PAD_LCD_D11__ETM_DA3 0x10b1 +MX23_PAD_LCD_D12__ETM_DA4 0x10c1 +MX23_PAD_LCD_D13__ETM_DA5 0x10d1 +MX23_PAD_LCD_D14__ETM_DA6 0x10e1 +MX23_PAD_LCD_D15__ETM_DA7 0x10f1 +MX23_PAD_LCD_RESET__ETM_TCTL 0x1121 +MX23_PAD_LCD_RS__ETM_TCLK 0x1131 +MX23_PAD_LCD_DOTCK__GPMI_RDY3 0x1161 +MX23_PAD_LCD_ENABLE__I2C_SCL 0x1171 +MX23_PAD_LCD_HSYNC__I2C_SDA 0x1181 +MX23_PAD_LCD_VSYNC__LCD_BUSY 0x1191 +MX23_PAD_PWM0__ROTARYA 0x11a1 +MX23_PAD_PWM1__ROTARYB 0x11b1 +MX23_PAD_PWM2__GPMI_RDY3 0x11c1 +MX23_PAD_PWM3__ETM_TCTL 0x11d1 +MX23_PAD_PWM4__ETM_TCLK 0x11e1 +MX23_PAD_SSP1_DETECT__GPMI_CE3N 0x2011 +MX23_PAD_SSP1_DATA1__I2C_SCL 0x2031 +MX23_PAD_SSP1_DATA2__I2C_SDA 0x2041 +MX23_PAD_ROTARYA__AUART2_RTS 0x2071 +MX23_PAD_ROTARYB__AUART2_CTS 0x2081 +MX23_PAD_GPMI_D00__SSP2_DATA0 0x0002 +MX23_PAD_GPMI_D01__SSP2_DATA1 0x0012 +MX23_PAD_GPMI_D02__SSP2_DATA2 0x0022 +MX23_PAD_GPMI_D03__SSP2_DATA3 0x0032 +MX23_PAD_GPMI_D04__SSP2_DATA4 0x0042 +MX23_PAD_GPMI_D05__SSP2_DATA5 0x0052 +MX23_PAD_GPMI_D06__SSP2_DATA6 0x0062 +MX23_PAD_GPMI_D07__SSP2_DATA7 0x0072 +MX23_PAD_GPMI_D08__SSP1_DATA4 0x0082 +MX23_PAD_GPMI_D09__SSP1_DATA5 0x0092 +MX23_PAD_GPMI_D10__SSP1_DATA6 0x00a2 +MX23_PAD_GPMI_D11__SSP1_DATA7 0x00b2 +MX23_PAD_GPMI_D15__GPMI_CE3N 0x00f2 +MX23_PAD_GPMI_RDY0__SSP2_DETECT 0x0132 +MX23_PAD_GPMI_RDY1__SSP2_CMD 0x0142 +MX23_PAD_GPMI_WRN__SSP2_SCK 0x0182 +MX23_PAD_AUART1_CTS__SSP1_DATA4 0x01a2 +MX23_PAD_AUART1_RTS__SSP1_DATA5 0x01b2 +MX23_PAD_AUART1_RX__SSP1_DATA6 0x01c2 +MX23_PAD_AUART1_TX__SSP1_DATA7 0x01d2 +MX23_PAD_I2C_SCL__AUART1_TX 0x01e2 +MX23_PAD_I2C_SDA__AUART1_RX 0x01f2 +MX23_PAD_LCD_D08__SAIF2_SDATA0 0x1082 +MX23_PAD_LCD_D09__SAIF1_SDATA0 0x1092 +MX23_PAD_LCD_D10__SAIF_MCLK_BITCLK 0x10a2 +MX23_PAD_LCD_D11__SAIF_LRCLK 0x10b2 +MX23_PAD_LCD_D12__SAIF2_SDATA1 0x10c2 +MX23_PAD_LCD_D13__SAIF2_SDATA2 0x10d2 +MX23_PAD_LCD_D14__SAIF1_SDATA2 0x10e2 +MX23_PAD_LCD_D15__SAIF1_SDATA1 0x10f2 +MX23_PAD_LCD_D16__SAIF_ALT_BITCLK 0x1102 +MX23_PAD_LCD_RESET__GPMI_CE3N 0x1122 +MX23_PAD_PWM0__DUART_RX 0x11a2 +MX23_PAD_PWM1__DUART_TX 0x11b2 +MX23_PAD_PWM3__AUART1_CTS 0x11d2 +MX23_PAD_PWM4__AUART1_RTS 0x11e2 +MX23_PAD_SSP1_CMD__JTAG_TDO 0x2002 +MX23_PAD_SSP1_DETECT__USB_OTG_ID 0x2012 +MX23_PAD_SSP1_DATA0__JTAG_TDI 0x2022 +MX23_PAD_SSP1_DATA1__JTAG_TCLK 0x2032 +MX23_PAD_SSP1_DATA2__JTAG_RTCK 0x2042 +MX23_PAD_SSP1_DATA3__JTAG_TMS 0x2052 +MX23_PAD_SSP1_SCK__JTAG_TRST 0x2062 +MX23_PAD_ROTARYA__SPDIF 0x2072 +MX23_PAD_ROTARYB__GPMI_CE3N 0x2082 +MX23_PAD_GPMI_D00__GPIO_0_0 0x0003 +MX23_PAD_GPMI_D01__GPIO_0_1 0x0013 +MX23_PAD_GPMI_D02__GPIO_0_2 0x0023 +MX23_PAD_GPMI_D03__GPIO_0_3 0x0033 +MX23_PAD_GPMI_D04__GPIO_0_4 0x0043 +MX23_PAD_GPMI_D05__GPIO_0_5 0x0053 +MX23_PAD_GPMI_D06__GPIO_0_6 0x0063 +MX23_PAD_GPMI_D07__GPIO_0_7 0x0073 +MX23_PAD_GPMI_D08__GPIO_0_8 0x0083 +MX23_PAD_GPMI_D09__GPIO_0_9 0x0093 +MX23_PAD_GPMI_D10__GPIO_0_10 0x00a3 +MX23_PAD_GPMI_D11__GPIO_0_11 0x00b3 +MX23_PAD_GPMI_D12__GPIO_0_12 0x00c3 +MX23_PAD_GPMI_D13__GPIO_0_13 0x00d3 +MX23_PAD_GPMI_D14__GPIO_0_14 0x00e3 +MX23_PAD_GPMI_D15__GPIO_0_15 0x00f3 +MX23_PAD_GPMI_CLE__GPIO_0_16 0x0103 +MX23_PAD_GPMI_ALE__GPIO_0_17 0x0113 +MX23_PAD_GPMI_CE2N__GPIO_0_18 0x0123 +MX23_PAD_GPMI_RDY0__GPIO_0_19 0x0133 +MX23_PAD_GPMI_RDY1__GPIO_0_20 0x0143 +MX23_PAD_GPMI_RDY2__GPIO_0_21 0x0153 +MX23_PAD_GPMI_RDY3__GPIO_0_22 0x0163 +MX23_PAD_GPMI_WPN__GPIO_0_23 0x0173 +MX23_PAD_GPMI_WRN__GPIO_0_24 0x0183 +MX23_PAD_GPMI_RDN__GPIO_0_25 0x0193 +MX23_PAD_AUART1_CTS__GPIO_0_26 0x01a3 +MX23_PAD_AUART1_RTS__GPIO_0_27 0x01b3 +MX23_PAD_AUART1_RX__GPIO_0_28 0x01c3 +MX23_PAD_AUART1_TX__GPIO_0_29 0x01d3 +MX23_PAD_I2C_SCL__GPIO_0_30 0x01e3 +MX23_PAD_I2C_SDA__GPIO_0_31 0x01f3 +MX23_PAD_LCD_D00__GPIO_1_0 0x1003 +MX23_PAD_LCD_D01__GPIO_1_1 0x1013 +MX23_PAD_LCD_D02__GPIO_1_2 0x1023 +MX23_PAD_LCD_D03__GPIO_1_3 0x1033 +MX23_PAD_LCD_D04__GPIO_1_4 0x1043 +MX23_PAD_LCD_D05__GPIO_1_5 0x1053 +MX23_PAD_LCD_D06__GPIO_1_6 0x1063 +MX23_PAD_LCD_D07__GPIO_1_7 0x1073 +MX23_PAD_LCD_D08__GPIO_1_8 0x1083 +MX23_PAD_LCD_D09__GPIO_1_9 0x1093 +MX23_PAD_LCD_D10__GPIO_1_10 0x10a3 +MX23_PAD_LCD_D11__GPIO_1_11 0x10b3 +MX23_PAD_LCD_D12__GPIO_1_12 0x10c3 +MX23_PAD_LCD_D13__GPIO_1_13 0x10d3 +MX23_PAD_LCD_D14__GPIO_1_14 0x10e3 +MX23_PAD_LCD_D15__GPIO_1_15 0x10f3 +MX23_PAD_LCD_D16__GPIO_1_16 0x1103 +MX23_PAD_LCD_D17__GPIO_1_17 0x1113 +MX23_PAD_LCD_RESET__GPIO_1_18 0x1123 +MX23_PAD_LCD_RS__GPIO_1_19 0x1133 +MX23_PAD_LCD_WR__GPIO_1_20 0x1143 +MX23_PAD_LCD_CS__GPIO_1_21 0x1153 +MX23_PAD_LCD_DOTCK__GPIO_1_22 0x1163 +MX23_PAD_LCD_ENABLE__GPIO_1_23 0x1173 +MX23_PAD_LCD_HSYNC__GPIO_1_24 0x1183 +MX23_PAD_LCD_VSYNC__GPIO_1_25 0x1193 +MX23_PAD_PWM0__GPIO_1_26 0x11a3 +MX23_PAD_PWM1__GPIO_1_27 0x11b3 +MX23_PAD_PWM2__GPIO_1_28 0x11c3 +MX23_PAD_PWM3__GPIO_1_29 0x11d3 +MX23_PAD_PWM4__GPIO_1_30 0x11e3 +MX23_PAD_SSP1_CMD__GPIO_2_0 0x2003 +MX23_PAD_SSP1_DETECT__GPIO_2_1 0x2013 +MX23_PAD_SSP1_DATA0__GPIO_2_2 0x2023 +MX23_PAD_SSP1_DATA1__GPIO_2_3 0x2033 +MX23_PAD_SSP1_DATA2__GPIO_2_4 0x2043 +MX23_PAD_SSP1_DATA3__GPIO_2_5 0x2053 +MX23_PAD_SSP1_SCK__GPIO_2_6 0x2063 +MX23_PAD_ROTARYA__GPIO_2_7 0x2073 +MX23_PAD_ROTARYB__GPIO_2_8 0x2083 +MX23_PAD_EMI_A00__GPIO_2_9 0x2093 +MX23_PAD_EMI_A01__GPIO_2_10 0x20a3 +MX23_PAD_EMI_A02__GPIO_2_11 0x20b3 +MX23_PAD_EMI_A03__GPIO_2_12 0x20c3 +MX23_PAD_EMI_A04__GPIO_2_13 0x20d3 +MX23_PAD_EMI_A05__GPIO_2_14 0x20e3 +MX23_PAD_EMI_A06__GPIO_2_15 0x20f3 +MX23_PAD_EMI_A07__GPIO_2_16 0x2103 +MX23_PAD_EMI_A08__GPIO_2_17 0x2113 +MX23_PAD_EMI_A09__GPIO_2_18 0x2123 +MX23_PAD_EMI_A10__GPIO_2_19 0x2133 +MX23_PAD_EMI_A11__GPIO_2_20 0x2143 +MX23_PAD_EMI_A12__GPIO_2_21 0x2153 +MX23_PAD_EMI_BA0__GPIO_2_22 0x2163 +MX23_PAD_EMI_BA1__GPIO_2_23 0x2173 +MX23_PAD_EMI_CASN__GPIO_2_24 0x2183 +MX23_PAD_EMI_CE0N__GPIO_2_25 0x2193 +MX23_PAD_EMI_CE1N__GPIO_2_26 0x21a3 +MX23_PAD_GPMI_CE1N__GPIO_2_27 0x21b3 +MX23_PAD_GPMI_CE0N__GPIO_2_28 0x21c3 +MX23_PAD_EMI_CKE__GPIO_2_29 0x21d3 +MX23_PAD_EMI_RASN__GPIO_2_30 0x21e3 +MX23_PAD_EMI_WEN__GPIO_2_31 0x21f3 diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt new file mode 100644 index 0000000..c8e5782 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt @@ -0,0 +1,132 @@ +NVIDIA Tegra20 pinmux controller + +Required properties: +- compatible: "nvidia,tegra20-pinmux" +- reg: Should contain the register physical address and length for each of + the tri-state, mux, pull-up/down, and pad control register sets. + +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". + +Tegra'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, tristate, 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 or tristate parameter. For this +reason, even seemingly boolean values are actually tristates in this binding: +unspecified, off, or on. Unspecified is represented as an absent property, +and off/on are represented as integer values 0 and 1. + +Required subnode-properties: +- nvidia,pins : An array of strings. Each string contains the name of a pin or + group. Valid values for these names are listed below. + +Optional subnode-properties: +- nvidia,function: A string containing the name of the function to mux to the + pin or group. Valid values for function names are listed below. See the Tegra + TRM to determine which are valid for each pin or group. +- nvidia,pull: Integer, representing the pull-down/up to apply to the pin. + 0: none, 1: down, 2: up. +- nvidia,tristate: Integer. + 0: drive, 1: tristate. +- nvidia,high-speed-mode: Integer. Enable high speed mode the pins. + 0: no, 1: yes. +- nvidia,schmitt: Integer. Enables Schmitt Trigger on the input. + 0: no, 1: yes. +- nvidia,low-power-mode: Integer. Valid values 0-3. 0 is least power, 3 is + most power. Controls the drive power or current. See "Low Power Mode" + or "LPMD1" and "LPMD0" in the Tegra TRM. +- nvidia,pull-down-strength: Integer. Controls drive strength. 0 is weakest. + The range of valid values depends on the pingroup. See "CAL_DRVDN" in the + Tegra TRM. +- nvidia,pull-up-strength: Integer. Controls drive strength. 0 is weakest. + The range of valid values depends on the pingroup. See "CAL_DRVUP" in the + Tegra TRM. +- nvidia,slew-rate-rising: Integer. Controls rising signal slew rate. 0 is + fastest. The range of valid values depends on the pingroup. See + "DRVDN_SLWR" in the Tegra TRM. +- nvidia,slew-rate-falling: Integer. Controls falling signal slew rate. 0 is + fastest. The range of valid values depends on the pingroup. See + "DRVUP_SLWF" in the Tegra TRM. + +Note that many of these properties are only valid for certain specific pins +or groups. See the Tegra TRM and various pinmux spreadsheets for complete +details regarding which groups support which functionality. The Linux pinctrl +driver may also be a useful reference, since it consolidates, disambiguates, +and corrects data from all those sources. + +Valid values for pin and group names are: + + mux groups: + + These all support nvidia,function, nvidia,tristate, and many support + nvidia,pull. + + ata, atb, atc, atd, ate, cdev1, cdev2, crtp, csus, dap1, dap2, dap3, dap4, + ddc, dta, dtb, dtc, dtd, dte, dtf, gma, gmb, gmc, gmd, gme, gpu, gpu7, + gpv, hdint, i2cp, irrx, irtx, kbca, kbcb, kbcc, kbcd, kbce, kbcf, lcsn, + ld0, ld1, ld2, ld3, ld4, ld5, ld6, ld7, ld8, ld9, ld10, ld11, ld12, ld13, + ld14, ld15, ld16, ld17, ldc, ldi, lhp0, lhp1, lhp2, lhs, lm0, lm1, lpp, + lpw0, lpw1, lpw2, lsc0, lsc1, lsck, lsda, lsdi, lspi, lvp0, lvp1, lvs, + owc, pmc, pta, rm, sdb, sdc, sdd, sdio1, slxa, slxc, slxd, slxk, spdi, + spdo, spia, spib, spic, spid, spie, spif, spig, spih, uaa, uab, uac, uad, + uca, ucb, uda. + + tristate groups: + + These only support nvidia,pull. + + ck32, ddrc, pmca, pmcb, pmcc, pmcd, pmce, xm2c, xm2d, ls, lc, ld17_0, + ld19_18, ld21_20, ld23_22. + + drive groups: + + With some exceptions, these support nvidia,high-speed-mode, + nvidia,schmitt, nvidia,low-power-mode, nvidia,pull-down-strength, + nvidia,pull-up-strength, nvidia,slew_rate-rising, nvidia,slew_rate-falling. + + drive_ao1, drive_ao2, drive_at1, drive_at2, drive_cdev1, drive_cdev2, + drive_csus, drive_dap1, drive_dap2, drive_dap3, drive_dap4, drive_dbg, + drive_lcd1, drive_lcd2, drive_sdmmc2, drive_sdmmc3, drive_spi, drive_uaa, + drive_uab, drive_uart2, drive_uart3, drive_vi1, drive_vi2, drive_xm2a, + drive_xm2c, drive_xm2d, drive_xm2clk, drive_sdio1, drive_crt, drive_ddc, + drive_gma, drive_gmb, drive_gmc, drive_gmd, drive_gme, drive_owr, + drive_uda. + +Example: + + pinctrl@70000000 { + compatible = "nvidia,tegra20-pinmux"; + reg = < 0x70000014 0x10 /* Tri-state registers */ + 0x70000080 0x20 /* Mux registers */ + 0x700000a0 0x14 /* Pull-up/down registers */ + 0x70000868 0xa8 >; /* Pad control registers */ + }; + +Example board file extract: + + pinctrl@70000000 { + sdio4_default: sdio4_default { + atb { + nvidia,pins = "atb", "gma", "gme"; + nvidia,function = "sdio4"; + nvidia,pull = <0>; + nvidia,tristate = <0>; + }; + }; + }; + + sdhci@c8000600 { + pinctrl-names = "default"; + pinctrl-0 = <&sdio4_default>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt new file mode 100644 index 0000000..c275b70 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt @@ -0,0 +1,132 @@ +NVIDIA Tegra30 pinmux controller + +The Tegra30 pinctrl binding is very similar to the Tegra20 pinctrl binding, +as described in nvidia,tegra20-pinmux.txt. In fact, this document assumes +that binding as a baseline, and only documents the differences between the +two bindings. + +Required properties: +- compatible: "nvidia,tegra30-pinmux" +- reg: Should contain the register physical address and length for each of + the pad control and mux registers. + +Tegra30 adds the following optional properties for pin configuration subnodes: +- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes. +- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes. +- nvidia,lock: Integer. Lock the pin configuration against further changes + until reset. 0: no, 1: yes. +- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes. + +As with Tegra20, see the Tegra TRM for complete details regarding which groups +support which functionality. + +Valid values for pin and group names are: + + per-pin mux groups: + + These all support nvidia,function, nvidia,tristate, nvidia,pull, + nvidia,enable-input, nvidia,lock. Some support nvidia,open-drain, + nvidia,io-reset. + + clk_32k_out_pa0, uart3_cts_n_pa1, dap2_fs_pa2, dap2_sclk_pa3, + dap2_din_pa4, dap2_dout_pa5, sdmmc3_clk_pa6, sdmmc3_cmd_pa7, gmi_a17_pb0, + gmi_a18_pb1, lcd_pwr0_pb2, lcd_pclk_pb3, sdmmc3_dat3_pb4, sdmmc3_dat2_pb5, + sdmmc3_dat1_pb6, sdmmc3_dat0_pb7, uart3_rts_n_pc0, lcd_pwr1_pc1, + uart2_txd_pc2, uart2_rxd_pc3, gen1_i2c_scl_pc4, gen1_i2c_sda_pc5, + lcd_pwr2_pc6, gmi_wp_n_pc7, sdmmc3_dat5_pd0, sdmmc3_dat4_pd1, lcd_dc1_pd2, + sdmmc3_dat6_pd3, sdmmc3_dat7_pd4, vi_d1_pd5, vi_vsync_pd6, vi_hsync_pd7, + lcd_d0_pe0, lcd_d1_pe1, lcd_d2_pe2, lcd_d3_pe3, lcd_d4_pe4, lcd_d5_pe5, + lcd_d6_pe6, lcd_d7_pe7, lcd_d8_pf0, lcd_d9_pf1, lcd_d10_pf2, lcd_d11_pf3, + lcd_d12_pf4, lcd_d13_pf5, lcd_d14_pf6, lcd_d15_pf7, gmi_ad0_pg0, + gmi_ad1_pg1, gmi_ad2_pg2, gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5, + gmi_ad6_pg6, gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2, + gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, gmi_ad15_ph7, + gmi_wr_n_pi0, gmi_oe_n_pi1, gmi_dqs_pi2, gmi_cs6_n_pi3, gmi_rst_n_pi4, + gmi_iordy_pi5, gmi_cs7_n_pi6, gmi_wait_pi7, gmi_cs0_n_pj0, lcd_de_pj1, + gmi_cs1_n_pj2, lcd_hsync_pj3, lcd_vsync_pj4, uart2_cts_n_pj5, + uart2_rts_n_pj6, gmi_a16_pj7, gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs4_n_pk2, + gmi_cs2_n_pk3, gmi_cs3_n_pk4, spdif_out_pk5, spdif_in_pk6, gmi_a19_pk7, + vi_d2_pl0, vi_d3_pl1, vi_d4_pl2, vi_d5_pl3, vi_d6_pl4, vi_d7_pl5, + vi_d8_pl6, vi_d9_pl7, lcd_d16_pm0, lcd_d17_pm1, lcd_d18_pm2, lcd_d19_pm3, + lcd_d20_pm4, lcd_d21_pm5, lcd_d22_pm6, lcd_d23_pm7, dap1_fs_pn0, + dap1_din_pn1, dap1_dout_pn2, dap1_sclk_pn3, lcd_cs0_n_pn4, lcd_sdout_pn5, + lcd_dc0_pn6, hdmi_int_pn7, ulpi_data7_po0, ulpi_data0_po1, ulpi_data1_po2, + ulpi_data2_po3, ulpi_data3_po4, ulpi_data4_po5, ulpi_data5_po6, + ulpi_data6_po7, dap3_fs_pp0, dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, + dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7, kb_col0_pq0, + kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, + kb_col6_pq6, kb_col7_pq7, kb_row0_pr0, kb_row1_pr1, kb_row2_pr2, + kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7, + kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, kb_row12_ps4, + kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, vi_pclk_pt0, vi_mclk_pt1, + vi_d10_pt2, vi_d11_pt3, vi_d0_pt4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6, + sdmmc4_cmd_pt7, pu0, pu1, pu2, pu3, pu4, pu5, pu6, jtag_rtck_pu7, pv0, + pv1, pv2, pv3, ddc_scl_pv4, ddc_sda_pv5, crt_hsync_pv6, crt_vsync_pv7, + lcd_cs1_n_pw0, lcd_m1_pw1, spi2_cs1_n_pw2, spi2_cs2_n_pw3, clk1_out_pw4, + clk2_out_pw5, uart3_txd_pw6, uart3_rxd_pw7, spi2_mosi_px0, spi2_miso_px1, + spi2_sck_px2, spi2_cs0_n_px3, spi1_mosi_px4, spi1_sck_px5, spi1_cs0_n_px6, + spi1_miso_px7, ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, + sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6, sdmmc1_dat0_py7, + sdmmc1_clk_pz0, sdmmc1_cmd_pz1, lcd_sdin_pz2, lcd_wr_n_pz3, lcd_sck_pz4, + sys_clk_req_pz5, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, sdmmc4_dat0_paa0, + sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, + sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, pbb0, + cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, pbb7, + cam_mclk_pcc0, pcc1, pcc2, sdmmc4_rst_n_pcc3, sdmmc4_clk_pcc4, + clk2_req_pcc5, pex_l2_rst_n_pcc6, pex_l2_clkreq_n_pcc7, + pex_l0_prsnt_n_pdd0, pex_l0_rst_n_pdd1, pex_l0_clkreq_n_pdd2, + pex_wake_n_pdd3, pex_l1_prsnt_n_pdd4, pex_l1_rst_n_pdd5, + pex_l1_clkreq_n_pdd6, pex_l2_prsnt_n_pdd7, clk3_out_pee0, clk3_req_pee1, + clk1_req_pee2, hdmi_cec_pee3, clk_32k_in, core_pwr_req, cpu_pwr_req, owr, + pwr_int_n. + + drive groups: + + These all support nvidia,pull-down-strength, nvidia,pull-up-strength, + nvidia,slew_rate-rising, nvidia,slew_rate-falling. Most but not all + support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode. + + ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, cec, crt, csus, dap1, + dap2, dap3, dap4, dbg, ddc, dev3, gma, gmb, gmc, gmd, gme, gmf, gmg, + gmh, gpv, lcd1, lcd2, owr, sdio1, sdio2, sdio3, spi, uaa, uab, uart2, + uart3, uda, vi1. + +Example: + + pinctrl@70000000 { + compatible = "nvidia,tegra30-pinmux"; + reg = < 0x70000868 0xd0 /* Pad control registers */ + 0x70003000 0x3e0 >; /* Mux registers */ + }; + +Example board file extract: + + pinctrl@70000000 { + sdmmc4_default: pinmux { + sdmmc4_clk_pcc4 { + nvidia,pins = "sdmmc4_clk_pcc4", + "sdmmc4_rst_n_pcc3"; + nvidia,function = "sdmmc4"; + nvidia,pull = <0>; + nvidia,tristate = <0>; + }; + sdmmc4_dat0_paa0 { + nvidia,pins = "sdmmc4_dat0_paa0", + "sdmmc4_dat1_paa1", + "sdmmc4_dat2_paa2", + "sdmmc4_dat3_paa3", + "sdmmc4_dat4_paa4", + "sdmmc4_dat5_paa5", + "sdmmc4_dat6_paa6", + "sdmmc4_dat7_paa7"; + nvidia,function = "sdmmc4"; + nvidia,pull = <2>; + nvidia,tristate = <0>; + }; + }; + }; + + sdhci@78000400 { + pinctrl-names = "default"; + pinctrl-0 = <&sdmmc4_default>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt new file mode 100644 index 0000000..c95ea82 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -0,0 +1,128 @@ +== Introduction == + +Hardware modules that control pin multiplexing or configuration parameters +such as pull-up/down, tri-state, drive-strength etc are designated as pin +controllers. Each pin controller must be represented as a node in device tree, +just like any other hardware module. + +Hardware modules whose signals are affected by pin configuration are +designated client devices. Again, each client device must be represented as a +node in device tree, just like any other hardware module. + +For a client device to operate correctly, certain pin controllers must +set up certain specific pin configurations. Some client devices need a +single static pin configuration, e.g. set up during initialization. Others +need to reconfigure pins at run-time, for example to tri-state pins when the +device is inactive. Hence, each client device can define a set of named +states. The number and names of those states is defined by the client device's +own binding. + +The common pinctrl bindings defined in this file provide an infrastructure +for client device device tree nodes to map those state names to the pin +configuration used by those states. + +Note that pin controllers themselves may also be client devices of themselves. +For example, a pin controller may set up its own "active" state when the +driver loads. This would allow representing a board's static pin configuration +in a single place, rather than splitting it across multiple client device +nodes. The decision to do this or not somewhat rests with the author of +individual board device tree files, and any requirements imposed by the +bindings for the individual client devices in use by that board, i.e. whether +they require certain specific named states for dynamic pin configuration. + +== Pinctrl client devices == + +For each client device individually, every pin state is assigned an integer +ID. These numbers start at 0, and are contiguous. For each state ID, a unique +property exists to define the pin configuration. Each state may also be +assigned a name. When names are used, another property exists to map from +those names to the integer IDs. + +Each client device's own binding determines the set of states the must be +defined in its device tree node, and whether to define the set of state +IDs that must be provided, or whether to define the set of state names that +must be provided. + +Required properties: +pinctrl-0: List of phandles, each pointing at a pin configuration + node. These referenced pin configuration nodes must be child + nodes of the pin controller that they configure. Multiple + entries may exist in this list so that multiple pin + controllers may be configured, or so that a state may be built + from multiple nodes for a single pin controller, each + contributing part of the overall configuration. See the next + section of this document for details of the format of these + pin configuration nodes. + + In some cases, it may be useful to define a state, but for it + to be empty. This may be required when a common IP block is + used in an SoC either without a pin controller, or where the + pin controller does not affect the HW module in question. If + the binding for that IP block requires certain pin states to + exist, they must still be defined, but may be left empty. + +Optional properties: +pinctrl-1: List of phandles, each pointing at a pin configuration + node within a pin controller. +... +pinctrl-n: List of phandles, each pointing at a pin configuration + node within a pin controller. +pinctrl-names: The list of names to assign states. List entry 0 defines the + name for integer state ID 0, list entry 1 for state ID 1, and + so on. + +For example: + + /* For a client device requiring named states */ + device { + pinctrl-names = "active", "idle"; + pinctrl-0 = <&state_0_node_a>; + pinctrl-1 = <&state_1_node_a &state_1_node_b>; + }; + + /* For the same device if using state IDs */ + device { + pinctrl-0 = <&state_0_node_a>; + pinctrl-1 = <&state_1_node_a &state_1_node_b>; + }; + + /* + * For an IP block whose binding supports pin configuration, + * but in use on an SoC that doesn't have any pin control hardware + */ + device { + pinctrl-names = "active", "idle"; + pinctrl-0 = <>; + pinctrl-1 = <>; + }; + +== Pin controller devices == + +Pin controller devices should contain the pin configuration nodes that client +devices reference. + +For example: + + pincontroller { + ... /* Standard DT properties for the device itself elided */ + + state_0_node_a { + ... + }; + state_1_node_a { + ... + }; + state_1_node_b { + ... + }; + } + +The contents of each of those pin configuration child nodes is defined +entirely by the binding for the individual pin controller device. There +exists no common standard for this content. + +The pin configuration nodes need not be direct children of the pin controller +device; they may be grandchildren, for example. Whether this is legal, and +whether there is any interaction between the child and intermediate parent +nodes, is again defined entirely by the binding for the individual pin +controller device. diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt new file mode 100644 index 0000000..5187f0d --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt @@ -0,0 +1,93 @@ +One-register-per-pin type device tree based pinctrl driver + +Required properties: +- compatible : "pinctrl-single" + +- reg : offset and length of the register set for the mux registers + +- pinctrl-single,register-width : pinmux register access width in bits + +- pinctrl-single,function-mask : mask of allowed pinmux function bits + in the pinmux register + +Optional properties: +- pinctrl-single,function-off : function off mode for disabled state if + available and same for all registers; if not specified, disabling of + pin functions is ignored + +This driver assumes that there is only one register for each pin, +and uses the common pinctrl bindings as specified in the pinctrl-bindings.txt +document in this directory. + +The pin configuration nodes for pinctrl-single are specified as pinctrl +register offset and value pairs using pinctrl-single,pins. Only the bits +specified in pinctrl-single,function-mask are updated. For example, setting +a pin for a device could be done with: + + pinctrl-single,pins = <0xdc 0x118>; + +Where 0xdc is the offset from the pinctrl register base address for the +device pinctrl register, and 0x118 contains the desired value of the +pinctrl register. See the device example and static board pins example +below for more information. + +Example: + +/* SoC common file */ + +/* first controller instance for pins in core domain */ +pmx_core: pinmux@4a100040 { + compatible = "pinctrl-single"; + reg = <0x4a100040 0x0196>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-single,register-width = <16>; + pinctrl-single,function-mask = <0xffff>; +}; + +/* second controller instance for pins in wkup domain */ +pmx_wkup: pinmux@4a31e040 { + compatible = "pinctrl-single; + reg = <0x4a31e040 0x0038>; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-single,register-width = <16>; + pinctrl-single,function-mask = <0xffff>; +}; + + +/* board specific .dts file */ + +&pmx_core { + + /* + * map all board specific static pins enabled by the pinctrl driver + * itself during the boot (or just set them up in the bootloader) + */ + pinctrl-names = "default"; + pinctrl-0 = <&board_pins>; + + board_pins: pinmux_board_pins { + pinctrl-single,pins = < + 0x6c 0xf + 0x6e 0xf + 0x70 0xf + 0x72 0xf + >; + }; + + /* map uart2 pins */ + uart2_pins: pinmux_uart2_pins { + pinctrl-single,pins = < + 0xd8 0x118 + 0xda 0 + 0xdc 0x118 + 0xde 0 + >; + }; +}; + +&uart2 { + pinctrl-names = "default"; + pinctrl-0 = <&uart2_pins>; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl_spear.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl_spear.txt new file mode 100644 index 0000000..b4480d5 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl_spear.txt @@ -0,0 +1,155 @@ +ST Microelectronics, SPEAr pinmux controller + +Required properties: +- compatible : "st,spear300-pinmux" + : "st,spear310-pinmux" + : "st,spear320-pinmux" + : "st,spear1310-pinmux" + : "st,spear1340-pinmux" +- reg : Address range of the pinctrl registers +- st,pinmux-mode: Mandatory for SPEAr300 and SPEAr320 and invalid for others. + - Its values for SPEAr300: + - NAND_MODE : <0> + - NOR_MODE : <1> + - PHOTO_FRAME_MODE : <2> + - LEND_IP_PHONE_MODE : <3> + - HEND_IP_PHONE_MODE : <4> + - LEND_WIFI_PHONE_MODE : <5> + - HEND_WIFI_PHONE_MODE : <6> + - ATA_PABX_WI2S_MODE : <7> + - ATA_PABX_I2S_MODE : <8> + - CAML_LCDW_MODE : <9> + - CAMU_LCD_MODE : <10> + - CAMU_WLCD_MODE : <11> + - CAML_LCD_MODE : <12> + - Its values for SPEAr320: + - AUTO_NET_SMII_MODE : <0> + - AUTO_NET_MII_MODE : <1> + - AUTO_EXP_MODE : <2> + - SMALL_PRINTERS_MODE : <3> + - EXTENDED_MODE : <4> + +Please refer to pinctrl-bindings.txt in this directory for details of the common +pinctrl bindings used by client devices. + +SPEAr's pinmux nodes act as a container for an abitrary number of subnodes. Each +of these subnodes represents muxing for a pin, a group, or a list of pins or +groups. + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Required subnode-properties: +- st,pins : An array of strings. Each string contains the name of a pin or + group. +- st,function: A string containing the name of the function to mux to the pin or + group. See the SPEAr's TRM to determine which are valid for each pin or group. + + Valid values for group and function names can be found from looking at the + group and function arrays in driver files: + drivers/pinctrl/spear/pinctrl-spear3*0.c + +Valid values for group names are: +For All SPEAr3xx machines: + "firda_grp", "i2c0_grp", "ssp_cs_grp", "ssp0_grp", "mii0_grp", + "gpio0_pin0_grp", "gpio0_pin1_grp", "gpio0_pin2_grp", "gpio0_pin3_grp", + "gpio0_pin4_grp", "gpio0_pin5_grp", "uart0_ext_grp", "uart0_grp", + "timer_0_1_grp", timer_0_1_pins, "timer_2_3_grp" + +For SPEAr300 machines: + "fsmc_2chips_grp", "fsmc_4chips_grp", "clcd_lcdmode_grp", + "clcd_pfmode_grp", "tdm_grp", "i2c_clk_grp_grp", "caml_grp", "camu_grp", + "dac_grp", "i2s_grp", "sdhci_4bit_grp", "sdhci_8bit_grp", + "gpio1_0_to_3_grp", "gpio1_4_to_7_grp" + +For SPEAr310 machines: + "emi_cs_0_to_5_grp", "uart1_grp", "uart2_grp", "uart3_grp", "uart4_grp", + "uart5_grp", "fsmc_grp", "rs485_0_grp", "rs485_1_grp", "tdm_grp" + +For SPEAr320 machines: + "clcd_grp", "emi_grp", "fsmc_8bit_grp", "fsmc_16bit_grp", "spp_grp", + "sdhci_led_grp", "sdhci_cd_12_grp", "sdhci_cd_51_grp", "i2s_grp", + "uart1_grp", "uart1_modem_2_to_7_grp", "uart1_modem_31_to_36_grp", + "uart1_modem_34_to_45_grp", "uart1_modem_80_to_85_grp", "uart2_grp", + "uart3_8_9_grp", "uart3_15_16_grp", "uart3_41_42_grp", + "uart3_52_53_grp", "uart3_73_74_grp", "uart3_94_95_grp", + "uart3_98_99_grp", "uart4_6_7_grp", "uart4_13_14_grp", + "uart4_39_40_grp", "uart4_71_72_grp", "uart4_92_93_grp", + "uart4_100_101_grp", "uart5_4_5_grp", "uart5_37_38_grp", + "uart5_69_70_grp", "uart5_90_91_grp", "uart6_2_3_grp", + "uart6_88_89_grp", "rs485_grp", "touchscreen_grp", "can0_grp", + "can1_grp", "pwm0_1_pin_8_9_grp", "pwm0_1_pin_14_15_grp", + "pwm0_1_pin_30_31_grp", "pwm0_1_pin_37_38_grp", "pwm0_1_pin_42_43_grp", + "pwm0_1_pin_59_60_grp", "pwm0_1_pin_88_89_grp", "pwm2_pin_7_grp", + "pwm2_pin_13_grp", "pwm2_pin_29_grp", "pwm2_pin_34_grp", + "pwm2_pin_41_grp", "pwm2_pin_58_grp", "pwm2_pin_87_grp", + "pwm3_pin_6_grp", "pwm3_pin_12_grp", "pwm3_pin_28_grp", + "pwm3_pin_40_grp", "pwm3_pin_57_grp", "pwm3_pin_86_grp", + "ssp1_17_20_grp", "ssp1_36_39_grp", "ssp1_48_51_grp", "ssp1_65_68_grp", + "ssp1_94_97_grp", "ssp2_13_16_grp", "ssp2_32_35_grp", "ssp2_44_47_grp", + "ssp2_61_64_grp", "ssp2_90_93_grp", "mii2_grp", "smii0_1_grp", + "rmii0_1_grp", "i2c1_8_9_grp", "i2c1_98_99_grp", "i2c2_0_1_grp", + "i2c2_2_3_grp", "i2c2_19_20_grp", "i2c2_75_76_grp", "i2c2_96_97_grp" + +For SPEAr1310 machines: + "i2c0_grp", "ssp0_grp", "ssp0_cs0_grp", "ssp0_cs1_2_grp", "i2s0_grp", + "i2s1_grp", "clcd_grp", "clcd_high_res_grp", "arm_gpio_grp", + "smi_2_chips_grp", "smi_4_chips_grp", "gmii_grp", "rgmii_grp", + "smii_0_1_2_grp", "ras_mii_txclk_grp", "nand_8bit_grp", + "nand_16bit_grp", "nand_4_chips_grp", "keyboard_6x6_grp", + "keyboard_rowcol6_8_grp", "uart0_grp", "uart0_modem_grp", + "gpt0_tmr0_grp", "gpt0_tmr1_grp", "gpt1_tmr0_grp", "gpt1_tmr1_grp", + "sdhci_grp", "cf_grp", "xd_grp", "touch_xy_grp", + "uart1_disable_i2c_grp", "uart1_disable_sd_grp", "uart2_3_grp", + "uart4_grp", "uart5_grp", "rs485_0_1_tdm_0_1_grp", "i2c_1_2_grp", + "i2c3_dis_smi_clcd_grp", "i2c3_dis_sd_i2s0_grp", "i2c_4_5_dis_smi_grp", + "i2c4_dis_sd_grp", "i2c5_dis_sd_grp", "i2c_6_7_dis_kbd_grp", + "i2c6_dis_sd_grp", "i2c7_dis_sd_grp", "can0_dis_nor_grp", + "can0_dis_sd_grp", "can1_dis_sd_grp", "can1_dis_kbd_grp", "pcie0_grp", + "pcie1_grp", "pcie2_grp", "sata0_grp", "sata1_grp", "sata2_grp", + "ssp1_dis_kbd_grp", "ssp1_dis_sd_grp", "gpt64_grp" + +For SPEAr1340 machines: + "pads_as_gpio_grp", "fsmc_8bit_grp", "fsmc_16bit_grp", "fsmc_pnor_grp", + "keyboard_row_col_grp", "keyboard_col5_grp", "spdif_in_grp", + "spdif_out_grp", "gpt_0_1_grp", "pwm0_grp", "pwm1_grp", "pwm2_grp", + "pwm3_grp", "vip_mux_grp", "vip_mux_cam0_grp", "vip_mux_cam1_grp", + "vip_mux_cam2_grp", "vip_mux_cam3_grp", "cam0_grp", "cam1_grp", + "cam2_grp", "cam3_grp", "smi_grp", "ssp0_grp", "ssp0_cs1_grp", + "ssp0_cs2_grp", "ssp0_cs3_grp", "uart0_grp", "uart0_enh_grp", + "uart1_grp", "i2s_in_grp", "i2s_out_grp", "gmii_grp", "rgmii_grp", + "rmii_grp", "sgmii_grp", "i2c0_grp", "i2c1_grp", "cec0_grp", "cec1_grp", + "sdhci_grp", "cf_grp", "xd_grp", "clcd_grp", "arm_trace_grp", + "miphy_dbg_grp", "pcie_grp", "sata_grp" + +Valid values for function names are: +For All SPEAr3xx machines: + "firda", "i2c0", "ssp_cs", "ssp0", "mii0", "gpio0", "uart0_ext", + "uart0", "timer_0_1", "timer_2_3" + +For SPEAr300 machines: + "fsmc", "clcd", "tdm", "i2c1", "cam", "dac", "i2s", "sdhci", "gpio1" + +For SPEAr310 machines: + "emi", "uart1", "uart2", "uart3", "uart4", "uart5", "fsmc", "rs485_0", + "rs485_1", "tdm" + +For SPEAr320 machines: + "clcd", "emi", "fsmc", "spp", "sdhci", "i2s", "uart1", "uart1_modem", + "uart2", "uart3", "uart4", "uart5", "uart6", "rs485", "touchscreen", + "can0", "can1", "pwm0_1", "pwm2", "pwm3", "ssp1", "ssp2", "mii2", + "mii0_1", "i2c1", "i2c2" + + +For SPEAr1310 machines: + "i2c0", "ssp0", "i2s0", "i2s1", "clcd", "arm_gpio", "smi", "gmii", + "rgmii", "smii_0_1_2", "ras_mii_txclk", "nand", "keyboard", "uart0", + "gpt0", "gpt1", "sdhci", "cf", "xd", "touchscreen", "uart1", "uart2_3", + "uart4", "uart5", "rs485_0_1_tdm_0_1", "i2c_1_2", "i2c3_i2s1", + "i2c_4_5", "i2c_6_7", "can0", "can1", "pci", "sata", "ssp1", "gpt64" + +For SPEAr1340 machines: + "pads_as_gpio", "fsmc", "keyboard", "spdif_in", "spdif_out", "gpt_0_1", + "pwm", "vip", "cam0", "cam1", "cam2", "cam3", "smi", "ssp0", "uart0", + "uart1", "i2s", "gmac", "i2c0", "i2c1", "cec0", "cec1", "sdhci", "cf", + "xd", "clcd", "arm_trace", "miphy_dbg", "pcie", "sata" diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt deleted file mode 100644 index 36f82db..0000000 --- a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt +++ /dev/null @@ -1,5 +0,0 @@ -NVIDIA Tegra 2 pinmux controller - -Required properties: -- compatible : "nvidia,tegra20-pinmux" - diff --git a/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt b/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt new file mode 100644 index 0000000..cfe1db3 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt @@ -0,0 +1,12 @@ +LPC32XX PWM controller + +Required properties: +- compatible: should be "nxp,lpc3220-pwm" +- reg: physical base address and length of the controller's registers + +Examples: + +pwm@0x4005C000 { + compatible = "nxp,lpc3220-pwm"; + reg = <0x4005C000 0x8>; +}; diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt new file mode 100644 index 0000000..b16f4a5 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt @@ -0,0 +1,17 @@ +Freescale MXS PWM controller + +Required properties: +- compatible: should be "fsl,imx23-pwm" +- reg: physical base address and length of the controller's registers +- #pwm-cells: should be 2. The first cell specifies the per-chip index + of the PWM to use and the second cell is the duty cycle in nanoseconds. +- fsl,pwm-number: the number of PWM devices + +Example: + +pwm: pwm@80064000 { + compatible = "fsl,imx28-pwm", "fsl,imx23-pwm"; + reg = <0x80064000 2000>; + #pwm-cells = <2>; + fsl,pwm-number = <8>; +}; diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt new file mode 100644 index 0000000..bbbeedb --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt @@ -0,0 +1,18 @@ +Tegra SoC PWFM controller + +Required properties: +- compatible: should be one of: + - "nvidia,tegra20-pwm" + - "nvidia,tegra30-pwm" +- reg: physical base address and length of the controller's registers +- #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The + first cell specifies the per-chip index of the PWM to use and the second + cell is the duty cycle in nanoseconds. + +Example: + + pwm: pwm@7000a000 { + compatible = "nvidia,tegra20-pwm"; + reg = <0x7000a000 0x100>; + #pwm-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt b/Documentation/devicetree/bindings/pwm/pwm.txt new file mode 100644 index 0000000..73ec962 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm.txt @@ -0,0 +1,57 @@ +Specifying PWM information for devices +====================================== + +1) PWM user nodes +----------------- + +PWM users should specify a list of PWM devices that they want to use +with a property containing a 'pwm-list': + + pwm-list ::= <single-pwm> [pwm-list] + single-pwm ::= <pwm-phandle> <pwm-specifier> + pwm-phandle : phandle to PWM controller node + pwm-specifier : array of #pwm-cells specifying the given PWM + (controller specific) + +PWM properties should be named "pwms". The exact meaning of each pwms +property must be documented in the device tree binding for each device. +An optional property "pwm-names" may contain a list of strings to label +each of the PWM devices listed in the "pwms" property. If no "pwm-names" +property is given, the name of the user node will be used as fallback. + +Drivers for devices that use more than a single PWM device can use the +"pwm-names" property to map the name of the PWM device requested by the +pwm_get() call to an index into the list given by the "pwms" property. + +The following example could be used to describe a PWM-based backlight +device: + + pwm: pwm { + #pwm-cells = <2>; + }; + + [...] + + bl: backlight { + pwms = <&pwm 0 5000000>; + pwm-names = "backlight"; + }; + +pwm-specifier typically encodes the chip-relative PWM number and the PWM +period in nanoseconds. Note that in the example above, specifying the +"pwm-names" is redundant because the name "backlight" would be used as +fallback anyway. + +2) PWM controller nodes +----------------------- + +PWM controller nodes must specify the number of cells used for the +specifier using the '#pwm-cells' property. + +An example PWM controller might look like this: + + pwm: pwm@7000a000 { + compatible = "nvidia,tegra20-pwm"; + reg = <0x7000a000 0x100>; + #pwm-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt index 9cf57fd..4fae41d 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt @@ -8,6 +8,9 @@ Optional properties: - startup-delay-us: startup time in microseconds - enable-active-high: Polarity of GPIO is Active high If this property is missing, the default assumed is Active low. +- gpio-open-drain: GPIO is open drain type. + If this property is missing then default assumption is false. +-vin-supply: Input supply name. Any property defined as part of the core regulator binding, defined in regulator.txt, can also be used. @@ -25,5 +28,7 @@ Example: gpio = <&gpio1 16 0>; startup-delay-us = <70000>; enable-active-high; - regulator-boot-on + regulator-boot-on; + gpio-open-drain; + vin-supply = <&parent_reg>; }; diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index 5b7a408..66ece3f 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -10,6 +10,11 @@ Optional properties: - regulator-always-on: boolean, regulator should never be disabled - regulator-boot-on: bootloader/firmware enabled regulator - <name>-supply: phandle to the parent supply/regulator node +- regulator-ramp-delay: ramp delay for regulator(in uV/uS) +- regulator-compatible: If a regulator chip contains multiple + regulators, and if the chip's binding contains a child node that + describes each regulator, then this property indicates which regulator + this child node is intended to configure. Example: diff --git a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt new file mode 100644 index 0000000..c8ca6b8 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt @@ -0,0 +1,44 @@ +TPS62360 Voltage regulators + +Required properties: +- compatible: Must be one of the following. + "ti,tps62360" + "ti,tps62361", + "ti,tps62362", + "ti,tps62363", +- reg: I2C slave address + +Optional properties: +- ti,enable-vout-discharge: Enable output discharge. This is boolean value. +- ti,enable-pull-down: Enable pull down. This is boolean value. +- ti,vsel0-gpio: GPIO for controlling VSEL0 line. + If this property is missing, then assume that there is no GPIO + for vsel0 control. +- ti,vsel1-gpio: Gpio for controlling VSEL1 line. + If this property is missing, then assume that there is no GPIO + for vsel1 control. +- ti,vsel0-state-high: Inital state of vsel0 input is high. + If this property is missing, then assume the state as low (0). +- ti,vsel1-state-high: Inital state of vsel1 input is high. + If this property is missing, then assume the state as low (0). + +Any property defined as part of the core regulator binding, defined in +regulator.txt, can also be used. + +Example: + + abc: tps62360 { + compatible = "ti,tps62361"; + reg = <0x60>; + regulator-name = "tps62361-vout"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on + ti,vsel0-gpio = <&gpio1 16 0>; + ti,vsel1-gpio = <&gpio1 17 0>; + ti,vsel0-state-high; + ti,vsel1-state-high; + ti,enable-pull-down; + ti,enable-force-pwm; + ti,enable-vout-discharge; + }; diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt b/Documentation/devicetree/bindings/regulator/tps65217.txt new file mode 100644 index 0000000..0487e96 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/tps65217.txt @@ -0,0 +1,91 @@ +TPS65217 family of regulators + +Required properties: +- compatible: "ti,tps65217" +- reg: I2C slave address +- regulators: list of regulators provided by this controller, must be named + after their hardware counterparts: dcdc[1-3] and ldo[1-4] +- regulators: This is the list of child nodes that specify the regulator + initialization data for defined regulators. Not all regulators for the given + device need to be present. The definition for each of these nodes is defined + using the standard binding for regulators found at + Documentation/devicetree/bindings/regulator/regulator.txt. + + The valid names for regulators are: + tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4 + +Each regulator is defined using the standard binding for regulators. + +Example: + + tps: tps@24 { + compatible = "ti,tps65217"; + + regulators { + #address-cells = <1>; + #size-cells = <0>; + + dcdc1_reg: regulator@0 { + reg = <0>; + regulator-compatible = "dcdc1"; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <1800000>; + regulator-boot-on; + regulator-always-on; + }; + + dcdc2_reg: regulator@1 { + reg = <1>; + regulator-compatible = "dcdc2"; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + + dcdc3_reg: regulator@2 { + reg = <2>; + regulator-compatible = "dcdc3"; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo1_reg: regulator@3 { + reg = <3>; + regulator-compatible = "ldo1"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo2_reg: regulator@4 { + reg = <4>; + regulator-compatible = "ldo2"; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo3_reg: regulator@5 { + reg = <5>; + regulator-compatible = "ldo3"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo4_reg: regulator@6 { + reg = <6>; + regulator-compatible = "ldo4"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/tps6586x.txt b/Documentation/devicetree/bindings/regulator/tps6586x.txt new file mode 100644 index 0000000..d156e1b --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/tps6586x.txt @@ -0,0 +1,144 @@ +TPS6586x family of regulators + +Required properties: +- compatible: "ti,tps6586x" +- reg: I2C slave address +- interrupts: the interrupt outputs of the controller +- #gpio-cells: number of cells to describe a GPIO +- gpio-controller: mark the device as a GPIO controller +- regulators: list of regulators provided by this controller, must have + property "regulator-compatible" to match their hardware counterparts: + sm[0-2], ldo[0-9] and ldo_rtc +- sm0-supply: The input supply for the SM0. +- sm1-supply: The input supply for the SM1. +- sm2-supply: The input supply for the SM2. +- vinldo01-supply: The input supply for the LDO1 and LDO2 +- vinldo23-supply: The input supply for the LDO2 and LDO3 +- vinldo4-supply: The input supply for the LDO4 +- vinldo678-supply: The input supply for the LDO6, LDO7 and LDO8 +- vinldo9-supply: The input supply for the LDO9 + +Each regulator is defined using the standard binding for regulators. + +Example: + + pmu: tps6586x@34 { + compatible = "ti,tps6586x"; + reg = <0x34>; + interrupts = <0 88 0x4>; + + #gpio-cells = <2>; + gpio-controller; + + sm0-supply = <&some_reg>; + sm1-supply = <&some_reg>; + sm2-supply = <&some_reg>; + vinldo01-supply = <...>; + vinldo23-supply = <...>; + vinldo4-supply = <...>; + vinldo678-supply = <...>; + vinldo9-supply = <...>; + + regulators { + #address-cells = <1>; + #size-cells = <0>; + + sm0_reg: regulator@0 { + reg = <0>; + regulator-compatible = "sm0"; + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + regulator-always-on; + }; + + sm1_reg: regulator@1 { + reg = <1>; + regulator-compatible = "sm1"; + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + regulator-always-on; + }; + + sm2_reg: regulator@2 { + reg = <2>; + regulator-compatible = "sm2"; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <4550000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo0_reg: regulator@3 { + reg = <3>; + regulator-compatible = "ldo0"; + regulator-name = "PCIE CLK"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + ldo1_reg: regulator@4 { + reg = <4>; + regulator-compatible = "ldo1"; + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + }; + + ldo2_reg: regulator@5 { + reg = <5>; + regulator-compatible = "ldo2"; + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + }; + + ldo3_reg: regulator@6 { + reg = <6>; + regulator-compatible = "ldo3"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo4_reg: regulator@7 { + reg = <7>; + regulator-compatible = "ldo4"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <2475000>; + }; + + ldo5_reg: regulator@8 { + reg = <8>; + regulator-compatible = "ldo5"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo6_reg: regulator@9 { + reg = <9>; + regulator-compatible = "ldo6"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo7_reg: regulator@10 { + reg = <10>; + regulator-compatible = "ldo7"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo8_reg: regulator@11 { + reg = <11>; + regulator-compatible = "ldo8"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo9_reg: regulator@12 { + reg = <12>; + regulator-compatible = "ldo9"; + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt b/Documentation/devicetree/bindings/regulator/twl-regulator.txt index 0c3395d..658749b 100644 --- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt @@ -15,7 +15,6 @@ For twl6030 regulators/LDOs - "ti,twl6030-vusb" for VUSB LDO - "ti,twl6030-v1v8" for V1V8 LDO - "ti,twl6030-v2v1" for V2V1 LDO - - "ti,twl6030-clk32kg" for CLK32KG RESOURCE - "ti,twl6030-vdd1" for VDD1 SMPS - "ti,twl6030-vdd2" for VDD2 SMPS - "ti,twl6030-vdd3" for VDD3 SMPS diff --git a/Documentation/devicetree/bindings/rtc/dw-apb.txt b/Documentation/devicetree/bindings/rtc/dw-apb.txt new file mode 100644 index 0000000..93e2b0f --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/dw-apb.txt @@ -0,0 +1,25 @@ +* Designware APB timer + +Required properties: +- compatible: "snps,dw-apb-timer-sp" or "snps,dw-apb-timer-osc" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: IRQ line for the timer. +- clock-frequency: The frequency in HZ of the timer. +- clock-freq: For backwards compatibility with picoxcell + +Example: + + timer1: timer@ffc09000 { + compatible = "snps,dw-apb-timer-sp"; + interrupts = <0 168 4>; + clock-frequency = <200000000>; + reg = <0xffc09000 0x1000>; + }; + + timer2: timer@ffd00000 { + compatible = "snps,dw-apb-timer-osc"; + interrupts = <0 169 4>; + clock-frequency = <200000000>; + reg = <0xffd00000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt b/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt new file mode 100644 index 0000000..a87a1e9 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt @@ -0,0 +1,15 @@ +* NXP LPC32xx SoC Real Time Clock controller + +Required properties: +- compatible: must be "nxp,lpc3220-rtc" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: The RTC interrupt + +Example: + + rtc@40024000 { + compatible = "nxp,lpc3220-rtc"; + reg = <0x40024000 0x1000>; + interrupts = <52 0>; + }; diff --git a/Documentation/devicetree/bindings/rtc/spear-rtc.txt b/Documentation/devicetree/bindings/rtc/spear-rtc.txt new file mode 100644 index 0000000..ca67ac6 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/spear-rtc.txt @@ -0,0 +1,17 @@ +* SPEAr RTC + +Required properties: +- compatible : "st,spear600-rtc" +- reg : Address range of the rtc registers +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupt: Should contain the rtc interrupt number + +Example: + + rtc@fc000000 { + compatible = "st,spear600-rtc"; + reg = <0xfc000000 0x1000>; + interrupt-parent = <&vic1>; + interrupts = <12>; + }; diff --git a/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt b/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt new file mode 100644 index 0000000..b800070 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt @@ -0,0 +1,16 @@ +* STMP3xxx/i.MX28 Time Clock controller + +Required properties: +- compatible: should be one of the following. + * "fsl,stmp3xxx-rtc" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: rtc alarm interrupt + +Example: + +rtc@80056000 { + compatible = "fsl,imx28-rtc", "fsl,stmp3xxx-rtc"; + reg = <0x80056000 2000>; + interrupts = <29>; +}; diff --git a/Documentation/devicetree/bindings/serial/cavium-uart.txt b/Documentation/devicetree/bindings/serial/cavium-uart.txt new file mode 100644 index 0000000..87a6c37 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/cavium-uart.txt @@ -0,0 +1,19 @@ +* Universal Asynchronous Receiver/Transmitter (UART) + +- compatible: "cavium,octeon-3860-uart" + + Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs. + +- reg: The base address of the UART register bank. + +- interrupts: A single interrupt specifier. + +- current-speed: Optional, the current bit rate in bits per second. + +Example: + uart1: serial@1180000000c00 { + compatible = "cavium,octeon-3860-uart","ns16550"; + reg = <0x11800 0x00000c00 0x0 0x400>; + current-speed = <115200>; + interrupts = <0 35>; + }; diff --git a/Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt b/Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt new file mode 100644 index 0000000..e4acdd8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/imx-audio-sgtl5000.txt @@ -0,0 +1,49 @@ +Freescale i.MX audio complex with SGTL5000 codec + +Required properties: +- compatible : "fsl,imx-audio-sgtl5000" +- model : The user-visible name of this sound complex +- ssi-controller : The phandle of the i.MX SSI controller +- audio-codec : The phandle of the SGTL5000 audio codec +- 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 could be power + supplies, SGTL5000 pins, and the jacks on the board: + + Power supplies: + * Mic Bias + + SGTL5000 pins: + * MIC_IN + * LINE_IN + * HP_OUT + * LINE_OUT + + Board connectors: + * Mic Jack + * Line In Jack + * Headphone Jack + * Line Out Jack + * Ext Spk + +- mux-int-port : The internal port of the i.MX audio muxer (AUDMUX) +- mux-ext-port : The external port of the i.MX audio muxer + +Note: The AUDMUX port numbering should start at 1, which is consistent with +hardware manual. + +Example: + +sound { + compatible = "fsl,imx51-babbage-sgtl5000", + "fsl,imx-audio-sgtl5000"; + model = "imx51-babbage-sgtl5000"; + ssi-controller = <&ssi1>; + audio-codec = <&sgtl5000>; + audio-routing = + "MIC_IN", "Mic Jack", + "Mic Jack", "Mic Bias", + "Headphone Jack", "HP_OUT"; + mux-int-port = <1>; + mux-ext-port = <3>; +}; diff --git a/Documentation/devicetree/bindings/sound/mxs-audio-sgtl5000.txt b/Documentation/devicetree/bindings/sound/mxs-audio-sgtl5000.txt new file mode 100644 index 0000000..601c518 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mxs-audio-sgtl5000.txt @@ -0,0 +1,17 @@ +* Freescale MXS audio complex with SGTL5000 codec + +Required properties: +- compatible: "fsl,mxs-audio-sgtl5000" +- model: The user-visible name of this sound complex +- saif-controllers: The phandle list of the MXS SAIF controller +- audio-codec: The phandle of the SGTL5000 audio codec + +Example: + +sound { + compatible = "fsl,imx28-evk-sgtl5000", + "fsl,mxs-audio-sgtl5000"; + model = "imx28-evk-sgtl5000"; + saif-controllers = <&saif0 &saif1>; + audio-codec = <&sgtl5000>; +}; diff --git a/Documentation/devicetree/bindings/sound/mxs-saif.txt b/Documentation/devicetree/bindings/sound/mxs-saif.txt new file mode 100644 index 0000000..c37ba61 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mxs-saif.txt @@ -0,0 +1,36 @@ +* Freescale MXS Serial Audio Interface (SAIF) + +Required properties: +- compatible: Should be "fsl,<chip>-saif" +- reg: Should contain registers location and length +- interrupts: Should contain ERROR and DMA interrupts +- fsl,saif-dma-channel: APBX DMA channel for the SAIF + +Optional properties: +- fsl,saif-master: phandle to the master SAIF. It's only required for + the slave SAIF. + +Note: Each SAIF controller should have an alias correctly numbered +in "aliases" node. + +Example: + +aliases { + saif0 = &saif0; + saif1 = &saif1; +}; + +saif0: saif@80042000 { + compatible = "fsl,imx28-saif"; + reg = <0x80042000 2000>; + interrupts = <59 80>; + fsl,saif-dma-channel = <4>; +}; + +saif1: saif@80046000 { + compatible = "fsl,imx28-saif"; + reg = <0x80046000 2000>; + interrupts = <58 81>; + fsl,saif-dma-channel = <5>; + fsl,saif-master = <&saif0>; +}; diff --git a/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt index b77a97c..b77a97c 100644 --- a/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt new file mode 100644 index 0000000..04b14cf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt @@ -0,0 +1,14 @@ +NVIDIA Tegra audio complex for TrimSlice + +Required properties: +- compatible : "nvidia,tegra-audio-trimslice" +- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller +- nvidia,audio-codec : The phandle of the WM8903 audio codec + +Example: + +sound { + compatible = "nvidia,tegra-audio-trimslice"; + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&codec>; +}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt new file mode 100644 index 0000000..c4dd39c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt @@ -0,0 +1,54 @@ +NVIDIA Tegra audio complex + +Required properties: +- compatible : "nvidia,tegra-audio-wm8753" +- nvidia,model : The user-visible name of this sound complex. +- nvidia,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 WM8753's pins, and the jacks on the board: + + WM8753 pins: + + * LOUT1 + * LOUT2 + * ROUT1 + * ROUT2 + * MONO1 + * MONO2 + * OUT3 + * OUT4 + * LINE1 + * LINE2 + * RXP + * RXN + * ACIN + * ACOP + * MIC1N + * MIC1 + * MIC2N + * MIC2 + * Mic Bias + + Board connectors: + + * Headphone Jack + * Mic Jack + +- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller +- nvidia,audio-codec : The phandle of the WM8753 audio codec +Example: + +sound { + compatible = "nvidia,tegra-audio-wm8753-whistler", + "nvidia,tegra-audio-wm8753" + nvidia,model = "tegra-wm8753-harmony"; + + nvidia,audio-routing = + "Headphone Jack", "LOUT1", + "Headphone Jack", "ROUT1"; + + nvidia,i2s-controller = <&i2s1>; + nvidia,audio-codec = <&wm8753>; +}; + diff --git a/Documentation/devicetree/bindings/sound/tegra-audio-wm8903.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt index d5b0da8..d5b0da8 100644 --- a/Documentation/devicetree/bindings/sound/tegra-audio-wm8903.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt diff --git a/Documentation/devicetree/bindings/sound/tegra20-das.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt index 6de3a7e..6de3a7e 100644 --- a/Documentation/devicetree/bindings/sound/tegra20-das.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-das.txt diff --git a/Documentation/devicetree/bindings/sound/tegra20-i2s.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt index 0df2b5c..0df2b5c 100644 --- a/Documentation/devicetree/bindings/sound/tegra20-i2s.txt +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt new file mode 100644 index 0000000..1ac7b16 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt @@ -0,0 +1,32 @@ +NVIDIA Tegra30 AHUB (Audio Hub) + +Required properties: +- compatible : "nvidia,tegra30-ahub" +- reg : Should contain the register physical address and length for each of + the AHUB's APBIF registers and the AHUB's own registers. +- interrupts : Should contain AHUB interrupt +- nvidia,dma-request-selector : The Tegra DMA controller's phandle and + request selector for the first APBIF channel. +- ranges : The bus address mapping for the configlink register bus. + Can be empty since the mapping is 1:1. +- #address-cells : For the configlink bus. Should be <1>; +- #size-cells : For the configlink bus. Should be <1>. + +AHUB client modules need to specify the IDs of their CIFs (Client InterFaces). +For RX CIFs, the numbers indicate the register number within AHUB routing +register space (APBIF 0..3 RX, I2S 0..5 RX, DAM 0..2 RX 0..1, SPDIF RX 0..1). +For TX CIFs, the numbers indicate the bit position within the AHUB routing +registers (APBIF 0..3 TX, I2S 0..5 TX, DAM 0..2 TX, SPDIF TX 0..1). + +Example: + +ahub@70080000 { + compatible = "nvidia,tegra30-ahub"; + reg = <0x70080000 0x200 0x70080200 0x100>; + interrupts = < 0 103 0x04 >; + nvidia,dma-request-selector = <&apbdma 1>; + + ranges; + #address-cells = <1>; + #size-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt new file mode 100644 index 0000000..dfa6c03 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt @@ -0,0 +1,15 @@ +NVIDIA Tegra30 I2S controller + +Required properties: +- compatible : "nvidia,tegra30-i2s" +- reg : Should contain I2S registers location and length +- nvidia,ahub-cif-ids : The list of AHUB CIF IDs for this port, rx (playback) + first, tx (capture) second. See nvidia,tegra30-ahub.txt for values. + +Example: + +i2s@70002800 { + compatible = "nvidia,tegra30-i2s"; + reg = <0x70080300 0x100>; + nvidia,ahub-cif-ids = <4 4>; +}; diff --git a/Documentation/devicetree/bindings/sound/omap-dmic.txt b/Documentation/devicetree/bindings/sound/omap-dmic.txt new file mode 100644 index 0000000..fd8105f --- /dev/null +++ b/Documentation/devicetree/bindings/sound/omap-dmic.txt @@ -0,0 +1,21 @@ +* Texas Instruments OMAP4+ Digital Microphone Module + +Required properties: +- compatible: "ti,omap4-dmic" +- reg: Register location and size as an array: + <MPU access base address, size>, + <L3 interconnect address, size>; +- interrupts: Interrupt number for DMIC +- interrupt-parent: The parent interrupt controller +- ti,hwmods: Name of the hwmod associated with OMAP dmic IP + +Example: + +dmic: dmic@4012e000 { + compatible = "ti,omap4-dmic"; + reg = <0x4012e000 0x7f>, /* MPU private access */ + <0x4902e000 0x7f>; /* L3 Interconnect */ + interrupts = <0 114 0x4>; + interrupt-parent = <&gic>; + ti,hwmods = "dmic"; +}; diff --git a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt new file mode 100644 index 0000000..0741dff --- /dev/null +++ b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt @@ -0,0 +1,21 @@ +* Texas Instruments OMAP4+ McPDM + +Required properties: +- compatible: "ti,omap4-mcpdm" +- reg: Register location and size as an array: + <MPU access base address, size>, + <L3 interconnect address, size>; +- interrupts: Interrupt number for McPDM +- interrupt-parent: The parent interrupt controller +- ti,hwmods: Name of the hwmod associated to the McPDM + +Example: + +mcpdm: mcpdm@40132000 { + compatible = "ti,omap4-mcpdm"; + reg = <0x40132000 0x7f>, /* MPU private access */ + <0x49032000 0x7f>; /* L3 Interconnect */ + interrupts = <0 112 0x4>; + interrupt-parent = <&gic>; + ti,hwmods = "mcpdm"; +}; diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt index 9841057..4256a6d 100644 --- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt @@ -17,6 +17,6 @@ ecspi@70010000 { reg = <0x70010000 0x4000>; interrupts = <36>; fsl,spi-num-chipselects = <2>; - cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */ - <&gpio3 25 0>; /* GPIO4_25 */ + cs-gpios = <&gpio3 24 0>, /* GPIO3_24 */ + <&gpio3 25 0>; /* GPIO3_25 */ }; diff --git a/Documentation/devicetree/bindings/spi/spi_nvidia.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-spi.txt index 6b9e518..6b9e518 100644 --- a/Documentation/devicetree/bindings/spi/spi_nvidia.txt +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-spi.txt diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt new file mode 100644 index 0000000..a3ff50f --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-orion.txt @@ -0,0 +1,19 @@ +Marvell Orion SPI device + +Required properties: +- compatible : should be "marvell,orion-spi". +- reg : offset and length of the register set for the device +- cell-index : Which of multiple SPI controllers is this. +Optional properties: +- interrupts : Is currently not used. + +Example: + spi@10600 { + compatible = "marvell,orion-spi"; + #address-cells = <1>; + #size-cells = <0>; + cell-index = <0>; + reg = <0x10600 0x28>; + interrupts = <23>; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt b/Documentation/devicetree/bindings/spi/spi-samsung.txt new file mode 100644 index 0000000..a15ffed --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt @@ -0,0 +1,116 @@ +* Samsung SPI Controller + +The Samsung SPI controller is used to interface with various devices such as flash +and display controllers using the SPI communication interface. + +Required SoC Specific Properties: + +- compatible: should be one of the following. + - samsung,s3c2443-spi: for s3c2443, s3c2416 and s3c2450 platforms + - samsung,s3c6410-spi: for s3c6410 platforms + - samsung,s5p6440-spi: for s5p6440 and s5p6450 platforms + - samsung,s5pv210-spi: for s5pv210 and s5pc110 platforms + - samsung,exynos4210-spi: for exynos4 and exynos5 platforms + +- 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. + +[PRELIMINARY: the dma channel allocation will change once there are +official DMA bindings] + +- 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. + +Required Board Specific Properties: + +- #address-cells: should be 1. +- #size-cells: should be 0. +- gpios: The gpio specifier for clock, mosi and miso interface lines (in the + order specified). The format of the gpio specifier depends on the gpio + controller. + +Optional Board Specific Properties: + +- samsung,spi-src-clk: If the spi controller includes a internal clock mux to + select the clock source for the spi bus clock, this property can be used to + indicate the clock to be used for driving the spi bus clock. If not specified, + the clock number 0 is used as default. + +- num-cs: Specifies the number of chip select lines supported. If + not specified, the default number of chip select lines is set to 1. + +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. + + - 0: No phase shift. + - 1: 90 degree phase shift sampling. + - 2: 180 degree phase shift sampling. + - 3: 270 degree phase shift sampling. + +Aliases: + +- All the SPI controller nodes should be represented in the aliases node using + the following format 'spi{n}' where n is a unique number for the alias. + + +Example: + +- SoC Specific Portion: + + spi_0: spi@12d20000 { + compatible = "samsung,exynos4210-spi"; + reg = <0x12d20000 0x100>; + interrupts = <0 66 0>; + tx-dma-channel = <&pdma0 5>; + rx-dma-channel = <&pdma0 4>; + }; + +- Board Specific Portion: + + spi_0: spi@12d20000 { + #address-cells = <1>; + #size-cells = <0>; + gpios = <&gpa2 4 2 3 0>, + <&gpa2 6 2 3 0>, + <&gpa2 7 2 3 0>; + + w25q80bw@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "w25x80"; + reg = <0>; + spi-max-frequency = <10000>; + + controller-data { + cs-gpio = <&gpa2 5 1 0 3>; + samsung,spi-feedback-delay = <0>; + }; + + partition@0 { + label = "U-Boot"; + reg = <0x0 0x40000>; + read-only; + }; + + partition@40000 { + label = "Kernel"; + reg = <0x40000 0xc0000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt b/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt new file mode 100644 index 0000000..b3629d3 --- /dev/null +++ b/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt @@ -0,0 +1,16 @@ +* NXP LPC32xx SoC ADC controller + +Required properties: +- compatible: must be "nxp,lpc3220-adc" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: The ADC interrupt + +Example: + + adc@40048000 { + compatible = "nxp,lpc3220-adc"; + reg = <0x40048000 0x1000>; + interrupt-parent = <&mic>; + interrupts = <39 0>; + }; diff --git a/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt new file mode 100644 index 0000000..02ea23a --- /dev/null +++ b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt @@ -0,0 +1,26 @@ +* ST SPEAr ADC device driver + +Required properties: +- compatible: Should be "st,spear600-adc" +- 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 ADC interrupt +- sampling-frequency: Default sampling frequency + +Optional properties: +- vref-external: External voltage reference in milli-volts. If omitted + the internal voltage reference will be used. +- average-samples: Number of samples to generate an average value. If + omitted, single data conversion will be used. + +Examples: + + adc: adc@d8200000 { + compatible = "st,spear600-adc"; + reg = <0xd8200000 0x1000>; + interrupt-parent = <&vic1>; + interrupts = <6>; + sampling-frequency = <5000000>; + vref-external = <2500>; /* 2.5V VRef */ + }; diff --git a/Documentation/devicetree/bindings/thermal/spear-thermal.txt b/Documentation/devicetree/bindings/thermal/spear-thermal.txt new file mode 100644 index 0000000..93e3b67 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/spear-thermal.txt @@ -0,0 +1,14 @@ +* SPEAr Thermal + +Required properties: +- compatible : "st,thermal-spear1340" +- reg : Address range of the thermal registers +- st,thermal-flags: flags used to enable thermal sensor + +Example: + + thermal@fc000000 { + compatible = "st,thermal-spear1340"; + reg = <0xfc000000 0x1000>; + st,thermal-flags = <0x7000>; + }; diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt index a9c0406..b462d0c 100644 --- a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt +++ b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt @@ -11,7 +11,7 @@ Optional properties: Example: -uart@73fbc000 { +serial@73fbc000 { compatible = "fsl,imx51-uart", "fsl,imx21-uart"; reg = <0x73fbc000 0x4000>; interrupts = <31>; diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt new file mode 100644 index 0000000..2ee903f --- /dev/null +++ b/Documentation/devicetree/bindings/tty/serial/fsl-mxs-auart.txt @@ -0,0 +1,27 @@ +* Freescale MXS Application UART (AUART) + +Required properties: +- compatible : Should be "fsl,<soc>-auart". The supported SoCs include + imx23 and imx28. +- reg : Address and length of the register set for the device +- interrupts : Should contain the auart interrupt numbers + +Example: +auart0: serial@8006a000 { + compatible = "fsl,imx28-auart", "fsl,imx23-auart"; + reg = <0x8006a000 0x2000>; + interrupts = <112 70 71>; +}; + +Note: Each auart port should have an alias correctly numbered in "aliases" +node. + +Example: + +aliases { + serial0 = &auart0; + serial1 = &auart1; + serial2 = &auart2; + serial3 = &auart3; + serial4 = &auart4; +}; diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt b/Documentation/devicetree/bindings/tty/serial/of-serial.txt index b8b27b0..0847fde 100644 --- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt +++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt @@ -9,6 +9,7 @@ Required properties: - "ns16750" - "ns16850" - "nvidia,tegra20-uart" + - "nxp,lpc3220-uart" - "ibm,qpace-nwp-serial" - "serial" if the port type is unknown. - reg : offset and length of the register set for the device. diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt new file mode 100644 index 0000000..2c29041 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt @@ -0,0 +1,18 @@ +* Freescale i.MX ci13xxx usb controllers + +Required properties: +- compatible: Should be "fsl,imx27-usb" +- reg: Should contain registers location and length +- interrupts: Should contain controller interrupt + +Optional properties: +- fsl,usbphy: phandler of usb phy that connects to the only one port +- vbus-supply: regulator for vbus + +Examples: +usb@02184000 { /* USB OTG */ + compatible = "fsl,imx6q-usb", "fsl,imx27-usb"; + reg = <0x02184000 0x200>; + interrupts = <0 43 0x04>; + fsl,usbphy = <&usbphy1>; +}; diff --git a/Documentation/devicetree/bindings/usb/isp1301.txt b/Documentation/devicetree/bindings/usb/isp1301.txt new file mode 100644 index 0000000..5405d99 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/isp1301.txt @@ -0,0 +1,25 @@ +* NXP ISP1301 USB transceiver + +Required properties: +- compatible: must be "nxp,isp1301" +- reg: I2C address of the ISP1301 device + +Optional properties of devices using ISP1301: +- transceiver: phandle of isp1301 - this helps the ISP1301 driver to find the + ISP1301 instance associated with the respective USB driver + +Example: + + isp1301: usb-transceiver@2c { + compatible = "nxp,isp1301"; + reg = <0x2c>; + }; + + usbd@31020000 { + compatible = "nxp,lpc3220-udc"; + reg = <0x31020000 0x300>; + interrupt-parent = <&mic>; + interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>; + transceiver = <&isp1301>; + status = "okay"; + }; diff --git a/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt b/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt new file mode 100644 index 0000000..29f12a5 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/lpc32xx-udc.txt @@ -0,0 +1,28 @@ +* NXP LPC32xx SoC USB Device Controller (UDC) + +Required properties: +- compatible: Must be "nxp,lpc3220-udc" +- reg: Physical base address of the controller and length of memory mapped + region. +- interrupts: The USB interrupts: + * USB Device Low Priority Interrupt + * USB Device High Priority Interrupt + * USB Device DMA Interrupt + * External USB Transceiver Interrupt (OTG ATX) +- transceiver: phandle of the associated ISP1301 device - this is necessary for + the UDC controller for connecting to the USB physical layer + +Example: + + isp1301: usb-transceiver@2c { + compatible = "nxp,isp1301"; + reg = <0x2c>; + }; + + usbd@31020000 { + compatible = "nxp,lpc3220-udc"; + reg = <0x31020000 0x300>; + interrupt-parent = <&mic>; + interrupts = <0x3d 0>, <0x3e 0>, <0x3c 0>, <0x3a 0>; + transceiver = <&isp1301>; + }; diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt b/Documentation/devicetree/bindings/usb/mxs-phy.txt new file mode 100644 index 0000000..5835b27 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/mxs-phy.txt @@ -0,0 +1,13 @@ +* Freescale MXS USB Phy Device + +Required properties: +- compatible: Should be "fsl,imx23-usbphy" +- reg: Should contain registers location and length +- interrupts: Should contain phy interrupt + +Example: +usbphy1: usbphy@020c9000 { + compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy"; + reg = <0x020c9000 0x1000>; + interrupts = <0 44 0x04>; +}; diff --git a/Documentation/devicetree/bindings/usb/tegra-usb.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt index 007005d..e9b005d 100644 --- a/Documentation/devicetree/bindings/usb/tegra-usb.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt @@ -12,6 +12,9 @@ Required properties : - nvidia,vbus-gpio : If present, specifies a gpio that needs to be activated for the bus to be powered. +Required properties for phy_type == ulpi: + - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. + Optional properties: - dr_mode : dual role mode. Indicates the working mode for nvidia,tegra20-ehci compatible controllers. Can be "host", "peripheral", diff --git a/Documentation/devicetree/bindings/usb/ohci-nxp.txt b/Documentation/devicetree/bindings/usb/ohci-nxp.txt new file mode 100644 index 0000000..71e28c1 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ohci-nxp.txt @@ -0,0 +1,24 @@ +* OHCI controller, NXP ohci-nxp variant + +Required properties: +- compatible: must be "nxp,ohci-nxp" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: The OHCI interrupt +- transceiver: phandle of the associated ISP1301 device - this is necessary for + the UDC controller for connecting to the USB physical layer + +Example (LPC32xx): + + isp1301: usb-transceiver@2c { + compatible = "nxp,isp1301"; + reg = <0x2c>; + }; + + ohci@31020000 { + compatible = "nxp,ohci-nxp"; + reg = <0x31020000 0x300>; + interrupt-parent = <&mic>; + interrupts = <0x3b 0>; + transceiver = <&isp1301>; + }; diff --git a/Documentation/devicetree/bindings/usb/spear-usb.txt b/Documentation/devicetree/bindings/usb/spear-usb.txt new file mode 100644 index 0000000..f8a464a --- /dev/null +++ b/Documentation/devicetree/bindings/usb/spear-usb.txt @@ -0,0 +1,39 @@ +ST SPEAr SoC USB controllers: +----------------------------- + +EHCI: +----- + +Required properties: +- compatible: "st,spear600-ehci" +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the EHCI interrupt + +Example: + + ehci@e1800000 { + compatible = "st,spear600-ehci", "usb-ehci"; + reg = <0xe1800000 0x1000>; + interrupt-parent = <&vic1>; + interrupts = <27>; + }; + + +OHCI: +----- + +Required properties: +- compatible: "st,spear600-ohci" +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the OHCI interrupt + +Example: + + ohci@e1900000 { + compatible = "st,spear600-ohci", "usb-ohci"; + reg = <0xe1800000 0x1000>; + interrupt-parent = <&vic1>; + interrupts = <26>; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 82ac057..db4d3af 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -3,16 +3,19 @@ Device tree binding vendor prefix registry. Keep list in alphabetical order. This isn't an exhaustive list, but you should add new prefixes to it before using them to avoid name-space collisions. +ad Avionic Design GmbH adi Analog Devices, Inc. amcc Applied Micro Circuits Corporation (APM, formally AMCC) apm Applied Micro Circuits Corporation (APM) arm ARM Ltd. atmel Atmel Corporation +bosch Bosch Sensortec GmbH cavium Cavium, Inc. chrp Common Hardware Reference Platform cortina Cortina Systems, Inc. dallas Maxim Integrated Products (formerly Dallas Semiconductor) denx Denx Software Engineering +emmicro EM Microelectronic epson Seiko Epson Corp. est ESTeem Wireless Modems fsl Freescale Semiconductor diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt new file mode 100644 index 0000000..1e4fc72 --- /dev/null +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt @@ -0,0 +1,28 @@ +pwm-backlight bindings + +Required properties: + - compatible: "pwm-backlight" + - pwms: OF device-tree PWM specification (see PWM binding[0]) + - brightness-levels: Array of distinct brightness levels. Typically these + are in the range from 0 to 255, but any range starting at 0 will do. + The actual brightness level (PWM duty cycle) will be interpolated + from these values. 0 means a 0% duty cycle (darkest/off), while the + last value in the array represents a 100% duty cycle (brightest). + - default-brightness-level: the default brightness level (index into the + array defined by the "brightness-levels" property) + +Optional properties: + - pwm-names: a list of names for the PWM devices specified in the + "pwms" property (see PWM binding[0]) + +[0]: Documentation/devicetree/bindings/pwm/pwm.txt + +Example: + + backlight { + compatible = "pwm-backlight"; + pwms = <&pwm 0 5000000>; + + brightness-levels = <0 4 8 16 32 64 128 255>; + default-brightness-level = <6>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/omap-wdt.txt b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt new file mode 100644 index 0000000..c227970 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/omap-wdt.txt @@ -0,0 +1,14 @@ +TI Watchdog Timer (WDT) Controller for OMAP + +Required properties: +compatible: +- "ti,omap3-wdt" for OMAP3 +- "ti,omap4-wdt" for OMAP4 +- ti,hwmods: Name of the hwmod associated to the WDT + +Examples: + +wdt2: wdt@4a314000 { + compatible = "ti,omap4-wdt", "ti,omap3-wdt"; + ti,hwmods = "wd_timer2"; +}; diff --git a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt new file mode 100644 index 0000000..7c7f688 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt @@ -0,0 +1,13 @@ +* NXP PNX watchdog timer + +Required properties: +- compatible: must be "nxp,pnx4008-wdt" +- reg: physical base address of the controller and length of memory mapped + region. + +Example: + + watchdog@4003C000 { + compatible = "nxp,pnx4008-wdt"; + reg = <0x4003C000 0x1000>; + }; diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt index da0bfeb..d4d6675 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt @@ -551,12 +551,13 @@ Here is an example of a simple device-tree. In this example, an "o" designates a node followed by the node unit name. Properties are presented with their name followed by their content. "content" represents an ASCII string (zero terminated) value, while <content> -represents a 32-bit hexadecimal value. The various nodes in this -example will be discussed in a later chapter. At this point, it is -only meant to give you a idea of what a device-tree looks like. I have -purposefully kept the "name" and "linux,phandle" properties which -aren't necessary in order to give you a better idea of what the tree -looks like in practice. +represents a 32-bit value, specified in decimal or hexadecimal (the +latter prefixed 0x). The various nodes in this example will be +discussed in a later chapter. At this point, it is only meant to give +you a idea of what a device-tree looks like. I have purposefully kept +the "name" and "linux,phandle" properties which aren't necessary in +order to give you a better idea of what the tree looks like in +practice. / o device-tree |- name = "device-tree" @@ -576,14 +577,14 @@ looks like in practice. | |- name = "PowerPC,970" | |- device_type = "cpu" | |- reg = <0> - | |- clock-frequency = <5f5e1000> + | |- clock-frequency = <0x5f5e1000> | |- 64-bit | |- linux,phandle = <2> | o memory@0 | |- name = "memory" | |- device_type = "memory" - | |- reg = <00000000 00000000 00000000 20000000> + | |- reg = <0x00000000 0x00000000 0x00000000 0x20000000> | |- linux,phandle = <3> | o chosen @@ -1010,8 +1011,8 @@ compatibility. #size-cells = <1>; #interrupt-cells = <2>; device_type = "soc"; - ranges = <00000000 e0000000 00100000> - reg = <e0000000 00003000>; + ranges = <0x00000000 0xe0000000 0x00100000> + reg = <0xe0000000 0x00003000>; bus-frequency = <0>; } @@ -1085,16 +1086,16 @@ supported currently at the toplevel. * terminated string */ - property2 = <1234abcd>; /* define a property containing a + property2 = <0x1234abcd>; /* define a property containing a * numerical 32-bit value (hexadecimal) */ - property3 = <12345678 12345678 deadbeef>; + property3 = <0x12345678 0x12345678 0xdeadbeef>; /* define a property containing 3 * numerical 32-bit values (cells) in * hexadecimal */ - property4 = [0a 0b 0c 0d de ea ad be ef]; + property4 = [0x0a 0x0b 0x0c 0x0d 0xde 0xea 0xad 0xbe 0xef]; /* define a property whose content is * an arbitrary array of bytes */ @@ -1350,10 +1351,10 @@ Appendix A - Sample SOC node for MPC8540 model = "TSEC"; compatible = "gianfar", "simple-bus"; reg = <0x24000 0x1000>; - local-mac-address = [ 00 E0 0C 00 73 00 ]; - interrupts = <29 2 30 2 34 2>; + local-mac-address = [ 0x00 0xE0 0x0C 0x00 0x73 0x00 ]; + interrupts = <0x29 2 0x30 2 0x34 2>; phy-handle = <&phy0>; - sleep = <&pmc 00000080>; + sleep = <&pmc 0x00000080>; ranges; mdio@24520 { @@ -1385,10 +1386,10 @@ Appendix A - Sample SOC node for MPC8540 model = "TSEC"; compatible = "gianfar"; reg = <0x25000 0x1000>; - local-mac-address = [ 00 E0 0C 00 73 01 ]; - interrupts = <13 2 14 2 18 2>; + local-mac-address = [ 0x00 0xE0 0x0C 0x00 0x73 0x01 ]; + interrupts = <0x13 2 0x14 2 0x18 2>; phy-handle = <&phy1>; - sleep = <&pmc 00000040>; + sleep = <&pmc 0x00000040>; }; ethernet@26000 { @@ -1396,17 +1397,17 @@ Appendix A - Sample SOC node for MPC8540 model = "FEC"; compatible = "gianfar"; reg = <0x26000 0x1000>; - local-mac-address = [ 00 E0 0C 00 73 02 ]; - interrupts = <41 2>; + local-mac-address = [ 0x00 0xE0 0x0C 0x00 0x73 0x02 ]; + interrupts = <0x41 2>; phy-handle = <&phy3>; - sleep = <&pmc 00000020>; + sleep = <&pmc 0x00000020>; }; serial@4500 { #address-cells = <1>; #size-cells = <1>; compatible = "fsl,mpc8540-duart", "simple-bus"; - sleep = <&pmc 00000002>; + sleep = <&pmc 0x00000002>; ranges; serial@4500 { @@ -1414,7 +1415,7 @@ Appendix A - Sample SOC node for MPC8540 compatible = "ns16550"; reg = <0x4500 0x100>; clock-frequency = <0>; - interrupts = <42 2>; + interrupts = <0x42 2>; }; serial@4600 { @@ -1422,7 +1423,7 @@ Appendix A - Sample SOC node for MPC8540 compatible = "ns16550"; reg = <0x4600 0x100>; clock-frequency = <0>; - interrupts = <42 2>; + interrupts = <0x42 2>; }; }; @@ -1436,11 +1437,11 @@ Appendix A - Sample SOC node for MPC8540 }; i2c@3000 { - interrupts = <43 2>; + interrupts = <0x43 2>; reg = <0x3000 0x100>; compatible = "fsl-i2c"; dfsrr; - sleep = <&pmc 00000004>; + sleep = <&pmc 0x00000004>; }; pmc: power@e0070 { diff --git a/Documentation/devicetree/usage-model.txt b/Documentation/devicetree/usage-model.txt index c5a8009..dca90fe 100644 --- a/Documentation/devicetree/usage-model.txt +++ b/Documentation/devicetree/usage-model.txt @@ -312,7 +312,7 @@ device tree for the NVIDIA Tegra board. }; }; -At .machine_init() time, Tegra board support code will need to look at +At .init_machine() time, Tegra board support code will need to look at this DT and decide which nodes to create platform_devices for. However, looking at the tree, it is not immediately obvious what kind of device each node represents, or even if a node represents a device diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 3bbd5c5..ad86fb8 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -29,13 +29,6 @@ The buffer-user in memory, mapped into its own address space, so it can access the same area of memory. -*IMPORTANT*: [see https://lkml.org/lkml/2011/12/20/211 for more details] -For this first version, A buffer shared using the dma_buf sharing API: -- *may* be exported to user space using "mmap" *ONLY* by exporter, outside of - this framework. -- with this new iteration of the dma-buf api cpu access from the kernel has been - enable, see below for the details. - dma-buf operations for device dma only -------------------------------------- @@ -300,6 +293,17 @@ Access to a dma_buf from the kernel context involves three steps: Note that these calls need to always succeed. The exporter needs to complete any preparations that might fail in begin_cpu_access. + For some cases the overhead of kmap can be too high, a vmap interface + is introduced. This interface should be used very carefully, as vmalloc + space is a limited resources on many architectures. + + Interfaces: + void *dma_buf_vmap(struct dma_buf *dmabuf) + void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) + + The vmap call can fail if there is no vmap support in the exporter, or if it + runs out of vmalloc space. Fallback to kmap should be implemented. + 3. Finish access When the importer is done accessing the range specified in begin_cpu_access, @@ -313,6 +317,83 @@ Access to a dma_buf from the kernel context involves three steps: enum dma_data_direction dir); +Direct Userspace Access/mmap Support +------------------------------------ + +Being able to mmap an export dma-buf buffer object has 2 main use-cases: +- CPU fallback processing in a pipeline and +- supporting existing mmap interfaces in importers. + +1. CPU fallback processing in a pipeline + + In many processing pipelines it is sometimes required that the cpu can access + the data in a dma-buf (e.g. for thumbnail creation, snapshots, ...). To avoid + the need to handle this specially in userspace frameworks for buffer sharing + it's ideal if the dma_buf fd itself can be used to access the backing storage + from userspace using mmap. + + Furthermore Android's ION framework already supports this (and is otherwise + rather similar to dma-buf from a userspace consumer side with using fds as + handles, too). So it's beneficial to support this in a similar fashion on + dma-buf to have a good transition path for existing Android userspace. + + No special interfaces, userspace simply calls mmap on the dma-buf fd. + +2. Supporting existing mmap interfaces in exporters + + Similar to the motivation for kernel cpu access it is again important that + the userspace code of a given importing subsystem can use the same interfaces + with a imported dma-buf buffer object as with a native buffer object. This is + especially important for drm where the userspace part of contemporary OpenGL, + X, and other drivers is huge, and reworking them to use a different way to + mmap a buffer rather invasive. + + The assumption in the current dma-buf interfaces is that redirecting the + initial mmap is all that's needed. A survey of some of the existing + subsystems shows that no driver seems to do any nefarious thing like syncing + up with outstanding asynchronous processing on the device or allocating + special resources at fault time. So hopefully this is good enough, since + adding interfaces to intercept pagefaults and allow pte shootdowns would + increase the complexity quite a bit. + + Interface: + int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, + unsigned long); + + If the importing subsystem simply provides a special-purpose mmap call to set + up a mapping in userspace, calling do_mmap with dma_buf->file will equally + achieve that for a dma-buf object. + +3. Implementation notes for exporters + + Because dma-buf buffers have invariant size over their lifetime, the dma-buf + core checks whether a vma is too large and rejects such mappings. The + exporter hence does not need to duplicate this check. + + Because existing importing subsystems might presume coherent mappings for + userspace, the exporter needs to set up a coherent mapping. If that's not + possible, it needs to fake coherency by manually shooting down ptes when + leaving the cpu domain and flushing caches at fault time. Note that all the + dma_buf files share the same anon inode, hence the exporter needs to replace + the dma_buf file stored in vma->vm_file with it's own if pte shootdown is + requred. This is because the kernel uses the underlying inode's address_space + for vma tracking (and hence pte tracking at shootdown time with + unmap_mapping_range). + + If the above shootdown dance turns out to be too expensive in certain + scenarios, we can extend dma-buf with a more explicit cache tracking scheme + for userspace mappings. But the current assumption is that using mmap is + always a slower path, so some inefficiencies should be acceptable. + + Exporters that shoot down mappings (for any reasons) shall not do any + synchronization at fault time with outstanding device operations. + Synchronization is an orthogonal issue to sharing the backing storage of a + buffer and hence should not be handled by dma-buf itself. This is explictly + mentioned here because many people seem to want something like this, but if + different exporters handle this differently, buffer sharing can fail in + interesting ways depending upong the exporter (if userspace starts depending + upon this implicit synchronization). + Miscellaneous notes ------------------- @@ -336,6 +417,20 @@ Miscellaneous notes the exporting driver to create a dmabuf fd must provide a way to let userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). +- If an exporter needs to manually flush caches and hence needs to fake + coherency for mmap support, it needs to be able to zap all the ptes pointing + at the backing storage. Now linux mm needs a struct address_space associated + with the struct file stored in vma->vm_file to do that with the function + unmap_mapping_range. But the dma_buf framework only backs every dma_buf fd + with the anon_file struct file, i.e. all dma_bufs share the same file. + + Hence exporters need to setup their own file (and address_space) association + by setting vma->vm_file and adjusting vma->vm_pgoff in the dma_buf mmap + callback. In the specific case of a gem driver the exporter could use the + shmem file already provided by gem (and set vm_pgoff = 0). Exporters can then + zap ptes by unmapping the corresponding range of the struct address_space + associated with their own file. + References: [1] struct dma_buf_ops in include/linux/dma-buf.h [2] All interfaces mentioned above defined in include/linux/dma-buf.h diff --git a/Documentation/dontdiff b/Documentation/dontdiff index b4a898f..39462cf 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -150,7 +150,6 @@ keywords.c ksym.c* ksym.h* kxgettext -lkc_defs.h lex.c lex.*.c linux diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 2a596a4..950856b 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -276,3 +276,11 @@ REGULATOR devm_regulator_get() devm_regulator_put() devm_regulator_bulk_get() + +CLOCK + devm_clk_get() + devm_clk_put() + +PINCTRL + devm_pinctrl_get() + devm_pinctrl_put() diff --git a/Documentation/dvb/opera-firmware.txt b/Documentation/dvb/opera-firmware.txt index 93e784c..fb66831 100644 --- a/Documentation/dvb/opera-firmware.txt +++ b/Documentation/dvb/opera-firmware.txt @@ -8,7 +8,7 @@ from the windriver disk into this directory. Then run -./get_dvb_firware opera1 +./get_dvb_firmware opera1 and after that you have 2 files: @@ -24,4 +24,4 @@ After that the driver can load the firmware in kernel config and have hotplug running). -Marco Gittler <g.marco@freenet.de>
\ No newline at end of file +Marco Gittler <g.marco@freenet.de> diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt index 74e6c77..6e16849 100644 --- a/Documentation/dynamic-debug-howto.txt +++ b/Documentation/dynamic-debug-howto.txt @@ -2,17 +2,17 @@ Introduction ============ -This document describes how to use the dynamic debug (ddebug) feature. +This document describes how to use the dynamic debug (dyndbg) feature. -Dynamic debug is designed to allow you to dynamically enable/disable kernel -code to obtain additional kernel information. Currently, if -CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can be -dynamically enabled per-callsite. +Dynamic debug is designed to allow you to dynamically enable/disable +kernel code to obtain additional kernel information. Currently, if +CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can +be dynamically enabled per-callsite. Dynamic debug has even more useful features: - * Simple query language allows turning on and off debugging statements by - matching any combination of 0 or 1 of: + * Simple query language allows turning on and off debugging + statements by matching any combination of 0 or 1 of: - source filename - function name @@ -20,17 +20,19 @@ Dynamic debug has even more useful features: - module name - format string - * Provides a debugfs control file: <debugfs>/dynamic_debug/control which can be - read to display the complete list of known debug statements, to help guide you + * Provides a debugfs control file: <debugfs>/dynamic_debug/control + which can be read to display the complete list of known debug + statements, to help guide you Controlling dynamic debug Behaviour =================================== The behaviour of pr_debug()/dev_dbg()s are controlled via writing to a -control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs -filesystem, in order to make use of this feature. Subsequently, we refer to the -control file as: <debugfs>/dynamic_debug/control. For example, if you want to -enable printing from source file 'svcsock.c', line 1603 you simply do: +control file in the 'debugfs' filesystem. Thus, you must first mount +the debugfs filesystem, in order to make use of this feature. +Subsequently, we refer to the control file as: +<debugfs>/dynamic_debug/control. For example, if you want to enable +printing from source file 'svcsock.c', line 1603 you simply do: nullarbor:~ # echo 'file svcsock.c line 1603 +p' > <debugfs>/dynamic_debug/control @@ -44,15 +46,15 @@ nullarbor:~ # echo 'file svcsock.c wtf 1 +p' > Viewing Dynamic Debug Behaviour =========================== -You can view the currently configured behaviour of all the debug statements -via: +You can view the currently configured behaviour of all the debug +statements via: nullarbor:~ # cat <debugfs>/dynamic_debug/control # filename:lineno [module]function flags format -/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup - "SVCRDMA Module Removed, deregister RPC RDMA transport\012" -/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init - "\011max_inline : %d\012" -/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init - "\011sq_depth : %d\012" -/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init - "\011max_requests : %d\012" +/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:323 [svcxprt_rdma]svc_rdma_cleanup =_ "SVCRDMA Module Removed, deregister RPC RDMA transport\012" +/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:341 [svcxprt_rdma]svc_rdma_init =_ "\011max_inline : %d\012" +/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:340 [svcxprt_rdma]svc_rdma_init =_ "\011sq_depth : %d\012" +/usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svc_rdma.c:338 [svcxprt_rdma]svc_rdma_init =_ "\011max_requests : %d\012" ... @@ -65,12 +67,12 @@ nullarbor:~ # grep -i rdma <debugfs>/dynamic_debug/control | wc -l nullarbor:~ # grep -i tcp <debugfs>/dynamic_debug/control | wc -l 42 -Note in particular that the third column shows the enabled behaviour -flags for each debug statement callsite (see below for definitions of the -flags). The default value, no extra behaviour enabled, is "-". So -you can view all the debug statement callsites with any non-default flags: +The third column shows the currently enabled flags for each debug +statement callsite (see below for definitions of the flags). The +default value, with no flags enabled, is "=_". So you can view all +the debug statement callsites with any non-default flags: -nullarbor:~ # awk '$3 != "-"' <debugfs>/dynamic_debug/control +nullarbor:~ # awk '$3 != "=_"' <debugfs>/dynamic_debug/control # filename:lineno [module]function flags format /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c:1603 [sunrpc]svc_send p "svc_process: st_sendto returned %d\012" @@ -103,15 +105,14 @@ specifications, followed by a flags change specification. command ::= match-spec* flags-spec -The match-spec's are used to choose a subset of the known dprintk() +The match-spec's are used to choose a subset of the known pr_debug() callsites to which to apply the flags-spec. Think of them as a query with implicit ANDs between each pair. Note that an empty list of -match-specs is possible, but is not very useful because it will not -match any debug statement callsites. +match-specs will select all debug statement callsites. -A match specification comprises a keyword, which controls the attribute -of the callsite to be compared, and a value to compare against. Possible -keywords are: +A match specification comprises a keyword, which controls the +attribute of the callsite to be compared, and a value to compare +against. Possible keywords are: match-spec ::= 'func' string | 'file' string | @@ -164,15 +165,15 @@ format characters (") or single quote characters ('). Examples: - format svcrdma: // many of the NFS/RDMA server dprintks - format readahead // some dprintks in the readahead cache + format svcrdma: // many of the NFS/RDMA server pr_debugs + format readahead // some pr_debugs in the readahead cache format nfsd:\040SETATTR // one way to match a format with whitespace format "nfsd: SETATTR" // a neater way to match a format with whitespace format 'nfsd: SETATTR' // yet another way to match a format with whitespace line The given line number or range of line numbers is compared - against the line number of each dprintk() callsite. A single + against the line number of each pr_debug() callsite. A single line number matches the callsite line number exactly. A range of line numbers matches any callsite between the first and last line number inclusive. An empty first number means @@ -188,51 +189,93 @@ The flags specification comprises a change operation followed by one or more flag characters. The change operation is one of the characters: -- - remove the given flags - -+ - add the given flags - -= - set the flags to the given flags + - remove the given flags + + add the given flags + = set the flags to the given flags The flags are: -f - Include the function name in the printed message -l - Include line number in the printed message -m - Include module name in the printed message -p - Causes a printk() message to be emitted to dmesg -t - Include thread ID in messages not generated from interrupt context + p enables the pr_debug() callsite. + f Include the function name in the printed message + l Include line number in the printed message + m Include module name in the printed message + t Include thread ID in messages not generated from interrupt context + _ No flags are set. (Or'd with others on input) + +For display, the flags are preceded by '=' +(mnemonic: what the flags are currently equal to). -Note the regexp ^[-+=][flmpt]+$ matches a flags specification. -Note also that there is no convenient syntax to remove all -the flags at once, you need to use "-flmpt". +Note the regexp ^[-+=][flmpt_]+$ matches a flags specification. +To clear all flags at once, use "=_" or "-flmpt". -Debug messages during boot process +Debug messages during Boot Process ================================== -To be able to activate debug messages during the boot process, -even before userspace and debugfs exists, use the boot parameter: -ddebug_query="QUERY" +To activate debug messages for core code and built-in modules during +the boot process, even before userspace and debugfs exists, use +dyndbg="QUERY", module.dyndbg="QUERY", or ddebug_query="QUERY" +(ddebug_query is obsoleted by dyndbg, and deprecated). QUERY follows +the syntax described above, but must not exceed 1023 characters. Your +bootloader may impose lower limits. + +These dyndbg params are processed just after the ddebug tables are +processed, as part of the arch_initcall. Thus you can enable debug +messages in all code run after this arch_initcall via this boot +parameter. -QUERY follows the syntax described above, but must not exceed 1023 -characters. The enablement of debug messages is done as an arch_initcall. -Thus you can enable debug messages in all code processed after this -arch_initcall via this boot parameter. On an x86 system for example ACPI enablement is a subsys_initcall and -ddebug_query="file ec.c +p" + dyndbg="file ec.c +p" will show early Embedded Controller transactions during ACPI setup if your machine (typically a laptop) has an Embedded Controller. PCI (or other devices) initialization also is a hot candidate for using this boot parameter for debugging purposes. +If foo module is not built-in, foo.dyndbg will still be processed at +boot time, without effect, but will be reprocessed when module is +loaded later. dyndbg_query= and bare dyndbg= are only processed at +boot. + + +Debug Messages at Module Initialization Time +============================================ + +When "modprobe foo" is called, modprobe scans /proc/cmdline for +foo.params, strips "foo.", and passes them to the kernel along with +params given in modprobe args or /etc/modprob.d/*.conf files, +in the following order: + +1. # parameters given via /etc/modprobe.d/*.conf + options foo dyndbg=+pt + options foo dyndbg # defaults to +p + +2. # foo.dyndbg as given in boot args, "foo." is stripped and passed + foo.dyndbg=" func bar +p; func buz +mp" + +3. # args to modprobe + modprobe foo dyndbg==pmf # override previous settings + +These dyndbg queries are applied in order, with last having final say. +This allows boot args to override or modify those from /etc/modprobe.d +(sensible, since 1 is system wide, 2 is kernel or boot specific), and +modprobe args to override both. + +In the foo.dyndbg="QUERY" form, the query must exclude "module foo". +"foo" is extracted from the param-name, and applied to each query in +"QUERY", and only 1 match-spec of each type is allowed. + +The dyndbg option is a "fake" module parameter, which means: + +- modules do not need to define it explicitly +- every module gets it tacitly, whether they use pr_debug or not +- it doesnt appear in /sys/module/$module/parameters/ + To see it, grep the control file, or inspect /proc/cmdline. + +For CONFIG_DYNAMIC_DEBUG kernels, any settings given at boot-time (or +enabled by -DDEBUG flag during compilation) can be disabled later via +the sysfs interface if the debug messages are no longer needed: + + echo "module module_name -p" > <debugfs>/dynamic_debug/control Examples ======== @@ -260,3 +303,18 @@ nullarbor:~ # echo -n 'func svc_process -p' > // enable messages for NFS calls READ, READLINK, READDIR and READDIR+. nullarbor:~ # echo -n 'format "nfsd: READ" +p' > <debugfs>/dynamic_debug/control + +// enable all messages +nullarbor:~ # echo -n '+p' > <debugfs>/dynamic_debug/control + +// add module, function to all enabled messages +nullarbor:~ # echo -n '+mf' > <debugfs>/dynamic_debug/control + +// boot-args example, with newlines and comments for readability +Kernel command line: ... + // see whats going on in dyndbg=value processing + dynamic_debug.verbose=1 + // enable pr_debugs in 2 builtins, #cmt is stripped + dyndbg="module params +p #cmt ; module sys +p" + // enable pr_debugs in 2 functions in a module loaded later + pc87360.dyndbg="func pc87360_init_device +p; func pc87360_find +p" diff --git a/Documentation/edac.txt b/Documentation/edac.txt index fdcc49f..56c7e93 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt @@ -232,116 +232,20 @@ EDAC control and attribute files. In 'mcX' directories are EDAC control and attribute files for -this 'X' instance of the memory controllers: - - -Counter reset control file: - - 'reset_counters' - - This write-only control file will zero all the statistical counters - for UE and CE errors. Zeroing the counters will also reset the timer - indicating how long since the last counter zero. This is useful - for computing errors/time. Since the counters are always reset at - driver initialization time, no module/kernel parameter is available. - - RUN TIME: echo "anything" >/sys/devices/system/edac/mc/mc0/counter_reset - - This resets the counters on memory controller 0 - - -Seconds since last counter reset control file: - - 'seconds_since_reset' - - This attribute file displays how many seconds have elapsed since the - last counter reset. This can be used with the error counters to - measure error rates. - - - -Memory Controller name attribute file: - - 'mc_name' - - This attribute file displays the type of memory controller - that is being utilized. - - -Total memory managed by this memory controller attribute file: - - 'size_mb' - - This attribute file displays, in count of megabytes, of memory - that this instance of memory controller manages. - - -Total Uncorrectable Errors count attribute file: - - 'ue_count' - - This attribute file displays the total count of uncorrectable - errors that have occurred on this memory controller. If panic_on_ue - is set this counter will not have a chance to increment, - since EDAC will panic the system. - - -Total UE count that had no information attribute fileY: - - 'ue_noinfo_count' - - This attribute file displays the number of UEs that have occurred - with no information as to which DIMM slot is having errors. - - -Total Correctable Errors count attribute file: - - 'ce_count' - - This attribute file displays the total count of correctable - errors that have occurred on this memory controller. This - count is very important to examine. CEs provide early - indications that a DIMM is beginning to fail. This count - field should be monitored for non-zero values and report - such information to the system administrator. - - -Total Correctable Errors count attribute file: - - 'ce_noinfo_count' - - This attribute file displays the number of CEs that - have occurred wherewith no information as to which DIMM slot - is having errors. Memory is handicapped, but operational, - yet no information is available to indicate which slot - the failing memory is in. This count field should be also - be monitored for non-zero values. - -Device Symlink: - - 'device' - - Symlink to the memory controller device. - -Sdram memory scrubbing rate: - - 'sdram_scrub_rate' - - Read/Write attribute file that controls memory scrubbing. The scrubbing - rate is set by writing a minimum bandwidth in bytes/sec to the attribute - file. The rate will be translated to an internal value that gives at - least the specified rate. - - Reading the file will return the actual scrubbing rate employed. - - If configuration fails or memory scrubbing is not implemented, accessing - that attribute will fail. +this 'X' instance of the memory controllers. +For a description of the sysfs API, please see: + Documentation/ABI/testing/sysfs/devices-edac ============================================================================ 'csrowX' DIRECTORIES +When CONFIG_EDAC_LEGACY_SYSFS is enabled, the sysfs will contain the +csrowX directories. As this API doesn't work properly for Rambus, FB-DIMMs +and modern Intel Memory Controllers, this is being deprecated in favor +of dimmX directories. + In the 'csrowX' directories are EDAC control and attribute files for this 'X' instance of csrow: @@ -734,7 +638,7 @@ were done at i7core_edac driver. This chapter will cover those differences associated with a physical CPU socket. Each MC have 3 physical read channels, 3 physical write channels and - 3 logic channels. The driver currenty sees it as just 3 channels. + 3 logic channels. The driver currently sees it as just 3 channels. Each channel can have up to 3 DIMMs. The minimum known unity is DIMMs. There are no information about csrows. diff --git a/Documentation/eisa.txt b/Documentation/eisa.txt index 38cf0c7..a55e491 100644 --- a/Documentation/eisa.txt +++ b/Documentation/eisa.txt @@ -179,7 +179,7 @@ CONFIG_ALPHA_JENSEN or CONFIG_EISA_VLB_PRIMING are set. Converting an EISA driver to the new API mostly involves *deleting* code (since probing is now in the core EISA code). Unfortunately, most -drivers share their probing routine between ISA, MCA and EISA. Special +drivers share their probing routine between ISA, and EISA. Special care must be taken when ripping out the EISA code, so other busses won't suffer from these surgical strikes... diff --git a/Documentation/extcon/porting-android-switch-class b/Documentation/extcon/porting-android-switch-class new file mode 100644 index 0000000..eb0fa5f --- /dev/null +++ b/Documentation/extcon/porting-android-switch-class @@ -0,0 +1,124 @@ + + Staging/Android Switch Class Porting Guide + (linux/drivers/staging/android/switch) + (c) Copyright 2012 Samsung Electronics + +AUTHORS +MyungJoo Ham <myungjoo.ham@samsung.com> + +/***************************************************************** + * CHAPTER 1. * + * PORTING SWITCH CLASS DEVICE DRIVERS * + *****************************************************************/ + +****** STEP 1. Basic Functionality + No extcon extended feature, but switch features only. + +- struct switch_dev (fed to switch_dev_register/unregister) + @name: no change + @dev: no change + @index: drop (not used in switch device driver side anyway) + @state: no change + If you have used @state with magic numbers, keep it + at this step. + @print_name: no change but type change (switch_dev->extcon_dev) + @print_state: no change but type change (switch_dev->extcon_dev) + +- switch_dev_register(sdev, dev) + => extcon_dev_register(edev, dev) + : no change but type change (sdev->edev) +- switch_dev_unregister(sdev) + => extcon_dev_unregister(edev) + : no change but type change (sdev->edev) +- switch_get_state(sdev) + => extcon_get_state(edev) + : no change but type change (sdev->edev) and (return: int->u32) +- switch_set_state(sdev, state) + => extcon_set_state(edev, state) + : no change but type change (sdev->edev) and (state: int->u32) + +With this changes, the ex-switch extcon class device works as it once +worked as switch class device. However, it will now have additional +interfaces (both ABI and in-kernel API) and different ABI locations. +However, if CONFIG_ANDROID is enabled without CONFIG_ANDROID_SWITCH, +/sys/class/switch/* will be symbolically linked to /sys/class/extcon/ +so that they are still compatible with legacy userspace processes. + +****** STEP 2. Multistate (no more magic numbers in state value) + Extcon's extended features for switch device drivers with + complex features usually required magic numbers in state + value of switch_dev. With extcon, such magic numbers that + support multiple cables ( + + 1. Define cable names at edev->supported_cable. + 2. (Recommended) remove print_state callback. + 3. Use extcon_get_cable_state_(edev, index) or + extcon_get_cable_state(edev, cable_name) instead of + extcon_get_state(edev) if you intend to get a state of a specific + cable. Same for set_state. This way, you can remove the usage of + magic numbers in state value. + 4. Use extcon_update_state() if you are updating specific bits of + the state value. + +Example: a switch device driver w/ magic numbers for two cables. + "0x00": no cables connected. + "0x01": cable 1 connected + "0x02": cable 2 connected + "0x03": cable 1 and 2 connected + 1. edev->supported_cable = {"1", "2", NULL}; + 2. edev->print_state = NULL; + 3. extcon_get_cable_state_(edev, 0) shows cable 1's state. + extcon_get_cable_state(edev, "1") shows cable 1's state. + extcon_set_cable_state_(edev, 1) sets cable 2's state. + extcon_set_cable_state(edev, "2") sets cable 2's state + 4. extcon_update_state(edev, 0x01, 0) sets the least bit's 0. + +****** STEP 3. Notify other device drivers + + You can notify others of the cable attach/detach events with +notifier chains. + + At the side of other device drivers (the extcon device itself +does not need to get notified of its own events), there are two +methods to register notifier_block for cable events: +(a) for a specific cable or (b) for every cable. + + (a) extcon_register_interest(obj, extcon_name, cable_name, nb) + Example: want to get news of "MAX8997_MUIC"'s "USB" cable + + obj = kzalloc(sizeof(struct extcon_specific_cable_nb), + GFP_KERNEL); + nb->notifier_call = the_callback_to_handle_usb; + + extcon_register_intereset(obj, "MAX8997_MUIC", "USB", nb); + + (b) extcon_register_notifier(edev, nb) + Call nb for any changes in edev. + + Please note that in order to properly behave with method (a), +the extcon device driver should support multistate feature (STEP 2). + +****** STEP 4. Inter-cable relation (mutually exclusive) + + You can provide inter-cable mutually exclusiveness information +for an extcon device. When cables A and B are declared to be mutually +exclusive, the two cables cannot be in ATTACHED state simulteneously. + + +/***************************************************************** + * CHAPTER 2. * + * PORTING USERSPACE w/ SWITCH CLASS DEVICE SUPPORT * + *****************************************************************/ + +****** ABI Location + + If "CONFIG_ANDROID" is enabled and "CONFIG_ANDROID_SWITCH" is +disabled, /sys/class/switch/* are created as symbolic links to +/sys/class/extcon/*. Because CONFIG_ANDROID_SWITCH creates +/sys/class/switch directory, we disable symboling linking if +CONFIG_ANDROID_SWITCH is enabled. + + The two files of switch class, name and state, are provided with +extcon, too. When the multistate support (STEP 2 of CHAPTER 1.) is +not enabled or print_state callback is supplied, the output of +state ABI is same with switch class. diff --git a/Documentation/fault-injection/fault-injection.txt b/Documentation/fault-injection/fault-injection.txt index ba4be8b..4cf1a2a 100644 --- a/Documentation/fault-injection/fault-injection.txt +++ b/Documentation/fault-injection/fault-injection.txt @@ -240,3 +240,30 @@ trap "echo 0 > /sys/kernel/debug/$FAILTYPE/probability" SIGINT SIGTERM EXIT echo "Injecting errors into the module $module... (interrupt to stop)" sleep 1000000 +Tool to run command with failslab or fail_page_alloc +---------------------------------------------------- +In order to make it easier to accomplish the tasks mentioned above, we can use +tools/testing/fault-injection/failcmd.sh. Please run a command +"./tools/testing/fault-injection/failcmd.sh --help" for more information and +see the following examples. + +Examples: + +Run a command "make -C tools/testing/selftests/ run_tests" with injecting slab +allocation failure. + + # ./tools/testing/fault-injection/failcmd.sh \ + -- make -C tools/testing/selftests/ run_tests + +Same as above except to specify 100 times failures at most instead of one time +at most by default. + + # ./tools/testing/fault-injection/failcmd.sh --times=100 \ + -- make -C tools/testing/selftests/ run_tests + +Same as above except to inject page allocation failure instead of slab +allocation failure. + + # env FAILCMD_TYPE=fail_page_alloc \ + ./tools/testing/fault-injection/failcmd.sh --times=100 \ + -- make -C tools/testing/selftests/ run_tests diff --git a/Documentation/fault-injection/notifier-error-inject.txt b/Documentation/fault-injection/notifier-error-inject.txt new file mode 100644 index 0000000..c83526c --- /dev/null +++ b/Documentation/fault-injection/notifier-error-inject.txt @@ -0,0 +1,99 @@ +Notifier error injection +======================== + +Notifier error injection provides the ability to inject artifical errors to +specified notifier chain callbacks. It is useful to test the error handling of +notifier call chain failures which is rarely executed. There are kernel +modules that can be used to test the following notifiers. + + * CPU notifier + * PM notifier + * Memory hotplug notifier + * powerpc pSeries reconfig notifier + +CPU notifier error injection module +----------------------------------- +This feature can be used to test the error handling of the CPU notifiers by +injecting artifical errors to CPU notifier chain callbacks. + +If the notifier call chain should be failed with some events notified, write +the error code to debugfs interface +/sys/kernel/debug/notifier-error-inject/cpu/actions/<notifier event>/error + +Possible CPU notifier events to be failed are: + + * CPU_UP_PREPARE + * CPU_UP_PREPARE_FROZEN + * CPU_DOWN_PREPARE + * CPU_DOWN_PREPARE_FROZEN + +Example1: Inject CPU offline error (-1 == -EPERM) + + # cd /sys/kernel/debug/notifier-error-inject/cpu + # echo -1 > actions/CPU_DOWN_PREPARE/error + # echo 0 > /sys/devices/system/cpu/cpu1/online + bash: echo: write error: Operation not permitted + +Example2: inject CPU online error (-2 == -ENOENT) + + # echo -2 > actions/CPU_UP_PREPARE/error + # echo 1 > /sys/devices/system/cpu/cpu1/online + bash: echo: write error: No such file or directory + +PM notifier error injection module +---------------------------------- +This feature is controlled through debugfs interface +/sys/kernel/debug/notifier-error-inject/pm/actions/<notifier event>/error + +Possible PM notifier events to be failed are: + + * PM_HIBERNATION_PREPARE + * PM_SUSPEND_PREPARE + * PM_RESTORE_PREPARE + +Example: Inject PM suspend error (-12 = -ENOMEM) + + # cd /sys/kernel/debug/notifier-error-inject/pm/ + # echo -12 > actions/PM_SUSPEND_PREPARE/error + # echo mem > /sys/power/state + bash: echo: write error: Cannot allocate memory + +Memory hotplug notifier error injection module +---------------------------------------------- +This feature is controlled through debugfs interface +/sys/kernel/debug/notifier-error-inject/memory/actions/<notifier event>/error + +Possible memory notifier events to be failed are: + + * MEM_GOING_ONLINE + * MEM_GOING_OFFLINE + +Example: Inject memory hotplug offline error (-12 == -ENOMEM) + + # cd /sys/kernel/debug/notifier-error-inject/memory + # echo -12 > actions/MEM_GOING_OFFLINE/error + # echo offline > /sys/devices/system/memory/memoryXXX/state + bash: echo: write error: Cannot allocate memory + +powerpc pSeries reconfig notifier error injection module +-------------------------------------------------------- +This feature is controlled through debugfs interface +/sys/kernel/debug/notifier-error-inject/pSeries-reconfig/actions/<notifier event>/error + +Possible pSeries reconfig notifier events to be failed are: + + * PSERIES_RECONFIG_ADD + * PSERIES_RECONFIG_REMOVE + * PSERIES_DRCONF_MEM_ADD + * PSERIES_DRCONF_MEM_REMOVE + +For more usage examples +----------------------- +There are tools/testing/selftests using the notifier error injection features +for CPU and memory notifiers. + + * tools/testing/selftests/cpu-hotplug/on-off-test.sh + * tools/testing/selftests/memory-hotplug/on-off-test.sh + +These scripts first do simple online and offline tests and then do fault +injection tests if notifier error injection module is available. diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index dbefb17..09b132d 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -2,7 +2,14 @@ The following is a list of files and features that are going to be removed in the kernel source tree. Every entry should contain what exactly is going away, why it is happening, and who is going to be doing the work. When the feature is removed from the kernel, it should also -be removed from this file. +be removed from this file. The suggested deprecation period is 3 releases. + +--------------------------- + +What: ddebug_query="query" boot cmdline param +When: v3.8 +Why: obsoleted by dyndbg="query" and module.dyndbg="query" +Who: Jim Cromie <jim.cromie@gmail.com>, Jason Baron <jbaron@redhat.com> --------------------------- @@ -242,15 +249,6 @@ Who: Ravikiran Thirumalai <kiran@scalex86.org> --------------------------- -What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS - (in net/core/net-sysfs.c) -When: 3.5 -Why: Over 1K .text/.data size reduction, data is available in other - ways (ioctls) -Who: Johannes Berg <johannes@sipsolutions.net> - ---------------------------- - What: sysfs ui for changing p4-clockmod parameters When: September 2009 Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and @@ -407,21 +405,6 @@ Who: Jean Delvare <khali@linux-fr.org> ---------------------------- -What: xt_connlimit rev 0 -When: 2012 -Who: Jan Engelhardt <jengelh@medozas.de> -Files: net/netfilter/xt_connlimit.c - ----------------------------- - -What: ipt_addrtype match include file -When: 2012 -Why: superseded by xt_addrtype -Who: Florian Westphal <fw@strlen.de> -Files: include/linux/netfilter_ipv4/ipt_addrtype.h - ----------------------------- - What: i2c_driver.attach_adapter i2c_driver.detach_adapter When: September 2011 @@ -442,6 +425,19 @@ Who: Hans Verkuil <hans.verkuil@cisco.com> ---------------------------- +What: CONFIG_CFG80211_WEXT +When: as soon as distributions ship new wireless tools, ie. wpa_supplicant 1.0 + and NetworkManager/connman/etc. that are able to use nl80211 +Why: Wireless extensions are deprecated, and userland tools are moving to + using nl80211. New drivers are no longer using wireless extensions, + and while there might still be old drivers, both new drivers and new + userland no longer needs them and they can't be used for an feature + developed in the past couple of years. As such, compatibility with + wireless extensions in new drivers will be removed. +Who: Johannes Berg <johannes@sipsolutions.net> + +---------------------------- + What: g_file_storage driver When: 3.8 Why: This driver has been superseded by g_mass_storage. @@ -516,14 +512,6 @@ Who: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> ---------------------------- -What: kmap_atomic(page, km_type) -When: 3.5 -Why: The old kmap_atomic() with two arguments is deprecated, we only - keep it for backward compatibility for few cycles and then drop it. -Who: Cong Wang <amwang@redhat.com> - ----------------------------- - What: get_robust_list syscall When: 2013 Why: There appear to be no production users of the get_robust_list syscall, @@ -534,6 +522,18 @@ Who: Kees Cook <keescook@chromium.org> ---------------------------- +What: Removing the pn544 raw driver. +When: 3.6 +Why: With the introduction of the NFC HCI and SHDL kernel layers, pn544.c + is being replaced by pn544_hci.c which is accessible through the netlink + and socket NFC APIs. Moreover, pn544.c is outdated and does not seem to + work properly with the latest Android stacks. + Having 2 drivers for the same hardware is confusing and as such we + should only keep the one following the kernel NFC APIs. +Who: Samuel Ortiz <sameo@linux.intel.com> + +---------------------------- + What: setitimer accepts user NULL pointer (value) When: 3.6 Why: setitimer is not returning -EFAULT if user pointer is NULL. This @@ -561,6 +561,46 @@ Who: Sylwester Nawrocki <sylvester.nawrocki@gmail.com> ---------------------------- +What: cgroup option updates via remount +When: March 2013 +Why: Remount currently allows changing bound subsystems and + release_agent. Rebinding is hardly useful as it only works + when the hierarchy is empty and release_agent itself should be + replaced with conventional fsnotify. + +---------------------------- + +What: xt_recent rev 0 +When: 2013 +Who: Pablo Neira Ayuso <pablo@netfilter.org> +Files: net/netfilter/xt_recent.c + +---------------------------- + +What: KVM debugfs statistics +When: 2013 +Why: KVM tracepoints provide mostly equivalent information in a much more + flexible fashion. + +---------------------------- + +What: at91-mci driver ("CONFIG_MMC_AT91") +When: 3.7 +Why: There are two mci drivers: at91-mci and atmel-mci. The PDC support + was added to atmel-mci as a first step to support more chips. + Then at91-mci was kept only for old IP versions (on at91rm9200 and + at91sam9261). The support of these IP versions has just been added + to atmel-mci, so atmel-mci can be used for all chips. +Who: Ludovic Desroches <ludovic.desroches@atmel.com> + +---------------------------- + +What: net/wanrouter/ +When: June 2013 +Why: Unsupported/unmaintained/unused since 2.6 + +---------------------------- + What: V4L2 selections API target rectangle and flags unification, the following definitions will be removed: V4L2_SEL_TGT_CROP_ACTIVE, V4L2_SEL_TGT_COMPOSE_ACTIVE, V4L2_SUBDEV_SEL_*, V4L2_SUBDEV_SEL_FLAG_* @@ -590,3 +630,5 @@ Why: New drivers should use new V4L2_CAP_VIDEO_M2M capability flag devices is ambiguous and may lead, for example, to identifying a M2M device as a video capture or output device. Who: Sylwester Nawrocki <s.nawrocki@samsung.com> + +---------------------------- diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 4fca82e..e0cce2a 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -9,7 +9,7 @@ be able to use diff(1). --------------------------- dentry_operations -------------------------- prototypes: - int (*d_revalidate)(struct dentry *, struct nameidata *); + int (*d_revalidate)(struct dentry *, unsigned int); int (*d_hash)(const struct dentry *, const struct inode *, struct qstr *); int (*d_compare)(const struct dentry *, const struct inode *, @@ -37,9 +37,8 @@ d_manage: no no yes (ref-walk) maybe --------------------------- inode_operations --------------------------- prototypes: - int (*create) (struct inode *,struct dentry *,umode_t, struct nameidata *); - struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameid -ata *); + int (*create) (struct inode *,struct dentry *,umode_t, bool); + struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int); int (*link) (struct dentry *,struct inode *,struct dentry *); int (*unlink) (struct inode *,struct dentry *); int (*symlink) (struct inode *,struct dentry *,const char *); @@ -60,8 +59,11 @@ ata *); ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t); ssize_t (*listxattr) (struct dentry *, char *, size_t); int (*removexattr) (struct dentry *, const char *); - void (*truncate_range)(struct inode *, loff_t, loff_t); int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len); + void (*update_time)(struct inode *, struct timespec *, int); + int (*atomic_open)(struct inode *, struct dentry *, + struct file *, unsigned open_flag, + umode_t create_mode, int *opened); locking rules: all may block @@ -87,8 +89,10 @@ setxattr: yes getxattr: no listxattr: no removexattr: yes -truncate_range: yes fiemap: no +update_time: no +atomic_open: yes + Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on victim. cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem. diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index b100adc..293855e 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt @@ -59,9 +59,9 @@ commit=nrsec (*) Ext3 can be told to sync all its data and metadata Setting it to very large values will improve performance. -barrier=<0(*)|1> This enables/disables the use of write barriers in -barrier the jbd code. barrier=0 disables, barrier=1 enables. -nobarrier (*) This also requires an IO stack which can support +barrier=<0|1(*)> This enables/disables the use of write barriers in +barrier (*) the jbd code. barrier=0 disables, barrier=1 enables. +nobarrier This also requires an IO stack which can support barriers, and if jbd gets an error on a barrier write, it will disable again with a warning. Write barriers enforce proper on-disk ordering diff --git a/Documentation/filesystems/gfs2-glocks.txt b/Documentation/filesystems/gfs2-glocks.txt index 0494f78..fcc7995 100644 --- a/Documentation/filesystems/gfs2-glocks.txt +++ b/Documentation/filesystems/gfs2-glocks.txt @@ -61,7 +61,9 @@ go_unlock | Called on the final local unlock of a lock go_dump | Called to print content of object for debugfs file, or on | error to dump glock to the log. go_type | The type of the glock, LM_TYPE_..... -go_min_hold_time | The minimum hold time +go_callback | Called if the DLM sends a callback to drop this lock +go_flags | GLOF_ASPACE is set, if the glock has an address space + | associated with it The minimum hold time for each lock is the time after a remote lock grant for which we ignore remote demote requests. This is in order to @@ -89,6 +91,7 @@ go_demote_ok | Sometimes | Yes go_lock | Yes | No go_unlock | Yes | No go_dump | Sometimes | Yes +go_callback | Sometimes (N/A) | Yes N.B. Operations must not drop either the bit lock or the spinlock if its held on entry. go_dump and do_demote_ok must never block. @@ -111,4 +114,118 @@ itself (locking order as above), and the other, known as the iopen glock is used in conjunction with the i_nlink field in the inode to determine the lifetime of the inode in question. Locking of inodes is on a per-inode basis. Locking of rgrps is on a per rgrp basis. +In general we prefer to lock local locks prior to cluster locks. + + Glock Statistics + ------------------ + +The stats are divided into two sets: those relating to the +super block and those relating to an individual glock. The +super block stats are done on a per cpu basis in order to +try and reduce the overhead of gathering them. They are also +further divided by glock type. All timings are in nanoseconds. + +In the case of both the super block and glock statistics, +the same information is gathered in each case. The super +block timing statistics are used to provide default values for +the glock timing statistics, so that newly created glocks +should have, as far as possible, a sensible starting point. +The per-glock counters are initialised to zero when the +glock is created. The per-glock statistics are lost when +the glock is ejected from memory. + +The statistics are divided into three pairs of mean and +variance, plus two counters. The mean/variance pairs are +smoothed exponential estimates and the algorithm used is +one which will be very familiar to those used to calculation +of round trip times in network code. See "TCP/IP Illustrated, +Volume 1", W. Richard Stevens, sect 21.3, "Round-Trip Time Measurement", +p. 299 and onwards. Also, Volume 2, Sect. 25.10, p. 838 and onwards. +Unlike the TCP/IP Illustrated case, the mean and variance are +not scaled, but are in units of integer nanoseconds. + +The three pairs of mean/variance measure the following +things: + + 1. DLM lock time (non-blocking requests) + 2. DLM lock time (blocking requests) + 3. Inter-request time (again to the DLM) + +A non-blocking request is one which will complete right +away, whatever the state of the DLM lock in question. That +currently means any requests when (a) the current state of +the lock is exclusive, i.e. a lock demotion (b) the requested +state is either null or unlocked (again, a demotion) or (c) the +"try lock" flag is set. A blocking request covers all the other +lock requests. + +There are two counters. The first is there primarily to show +how many lock requests have been made, and thus how much data +has gone into the mean/variance calculations. The other counter +is counting queuing of holders at the top layer of the glock +code. Hopefully that number will be a lot larger than the number +of dlm lock requests issued. + +So why gather these statistics? There are several reasons +we'd like to get a better idea of these timings: + +1. To be able to better set the glock "min hold time" +2. To spot performance issues more easily +3. To improve the algorithm for selecting resource groups for +allocation (to base it on lock wait time, rather than blindly +using a "try lock") + +Due to the smoothing action of the updates, a step change in +some input quantity being sampled will only fully be taken +into account after 8 samples (or 4 for the variance) and this +needs to be carefully considered when interpreting the +results. + +Knowing both the time it takes a lock request to complete and +the average time between lock requests for a glock means we +can compute the total percentage of the time for which the +node is able to use a glock vs. time that the rest of the +cluster has its share. That will be very useful when setting +the lock min hold time. + +Great care has been taken to ensure that we +measure exactly the quantities that we want, as accurately +as possible. There are always inaccuracies in any +measuring system, but I hope this is as accurate as we +can reasonably make it. + +Per sb stats can be found here: +/sys/kernel/debug/gfs2/<fsname>/sbstats +Per glock stats can be found here: +/sys/kernel/debug/gfs2/<fsname>/glstats + +Assuming that debugfs is mounted on /sys/kernel/debug and also +that <fsname> is replaced with the name of the gfs2 filesystem +in question. + +The abbreviations used in the output as are follows: + +srtt - Smoothed round trip time for non-blocking dlm requests +srttvar - Variance estimate for srtt +srttb - Smoothed round trip time for (potentially) blocking dlm requests +srttvarb - Variance estimate for srttb +sirt - Smoothed inter-request time (for dlm requests) +sirtvar - Variance estimate for sirt +dlm - Number of dlm requests made (dcnt in glstats file) +queue - Number of glock requests queued (qcnt in glstats file) + +The sbstats file contains a set of these stats for each glock type (so 8 lines +for each type) and for each cpu (one column per cpu). The glstats file contains +a set of these stats for each glock in a similar format to the glocks file, but +using the format mean/variance for each of the timing stats. + +The gfs2_glock_lock_time tracepoint prints out the current values of the stats +for the glock in question, along with some addition information on each dlm +reply that is received: + +status - The status of the dlm request +flags - The dlm request flags +tdiff - The time taken by this specific request +(remaining fields as per above list) + diff --git a/Documentation/filesystems/gfs2.txt b/Documentation/filesystems/gfs2.txt index 4cda926..cc4f230 100644 --- a/Documentation/filesystems/gfs2.txt +++ b/Documentation/filesystems/gfs2.txt @@ -1,7 +1,7 @@ Global File System ------------------ -http://sources.redhat.com/cluster/wiki/ +https://fedorahosted.org/cluster/wiki/HomePage GFS is a cluster file system. It allows a cluster of computers to simultaneously use a block device that is shared between them (with FC, @@ -30,7 +30,8 @@ needed, simply: If you are using Fedora, you need to install the gfs2-utils package and, for lock_dlm, you will also need to install the cman package -and write a cluster.conf as per the documentation. +and write a cluster.conf as per the documentation. For F17 and above +cman has been replaced by the dlm package. GFS2 is not on-disk compatible with previous versions of GFS, but it is pretty close. @@ -39,8 +40,6 @@ The following man pages can be found at the URL above: fsck.gfs2 to repair a filesystem gfs2_grow to expand a filesystem online gfs2_jadd to add journals to a filesystem online - gfs2_tool to manipulate, examine and tune a filesystem - gfs2_quota to examine and change quota values in a filesystem + tunegfs2 to manipulate, examine and tune a filesystem gfs2_convert to convert a gfs filesystem to gfs2 in-place - mount.gfs2 to help mount(8) mount a filesystem mkfs.gfs2 to make a filesystem diff --git a/Documentation/filesystems/nfs/pnfs.txt b/Documentation/filesystems/nfs/pnfs.txt index c7919c6..52ae07f 100644 --- a/Documentation/filesystems/nfs/pnfs.txt +++ b/Documentation/filesystems/nfs/pnfs.txt @@ -93,7 +93,7 @@ The API to the login script is as follows: (allways exists) (More protocols can be defined in the future. The client does not interpret this string it is - passed unchanged as recieved from the Server) + passed unchanged as received from the Server) -o osdname of the requested target OSD (Might be empty) (A string which denotes the OSD name, there is a diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index 74acd96..2bef2b3 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -297,7 +297,8 @@ in the beginning of ->setattr unconditionally. 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(). +been for ->delete_inode(). 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 @@ -306,14 +307,11 @@ updated appropriately. generic_delete_inode() is also alive and it consists simply of return 1. Note that all actual eviction work is done by caller after ->drop_inode() returns. - clear_inode() is gone; use end_writeback() instead. As before, it must -be called exactly once on each call of ->evict_inode() (as it used to be for -each call of ->delete_inode()). Unlike before, if you are using inode-associated -metadata buffers (i.e. mark_buffer_dirty_inode()), it's your responsibility to -call invalidate_inode_buffers() before end_writeback(). - No async writeback (and thus no calls of ->write_inode()) will happen -after end_writeback() returns, so actions that should not overlap with ->write_inode() -(e.g. freeing on-disk inode if i_nlink is 0) ought to be done after that call. + As before, clear_inode() must be called exactly once on each call of +->evict_inode() (as it used to be for each call of ->delete_inode()). Unlike +before, if you are using inode-associated metadata buffers (i.e. +mark_buffer_dirty_inode()), it's your responsibility to call +invalidate_inode_buffers() before clear_inode(). NOTE: checking i_nlink in the beginning of ->write_inode() and bailing out if it's zero is not *and* *never* *had* *been* enough. Final unlink() and iput() @@ -357,12 +355,10 @@ protects *all* the dcache state of a given dentry. via rcu-walk path walk (basically, if the file can have had a path name in the vfs namespace). - i_dentry and i_rcu share storage in a union, and the vfs expects -i_dentry to be reinitialized before it is freed, so an: - - INIT_LIST_HEAD(&inode->i_dentry); - -must be done in the RCU callback. + Even though i_dentry and i_rcu share storage in a union, we will +initialize the former in inode_init_always(), so just leave it alone in +the callback. It used to be necessary to clean it there, but not anymore +(starting at 3.2). -- [recommended] @@ -435,3 +431,14 @@ release it yourself. d_alloc_root() is gone, along with a lot of bugs caused by code misusing it. Replacement: d_make_root(inode). The difference is, d_make_root() drops the reference to inode if dentry allocation fails. + +-- +[mandatory] + The witch is dead! Well, 2/3 of it, anyway. ->d_revalidate() and +->lookup() do *not* take struct nameidata anymore; just the flags. +-- +[mandatory] + ->create() doesn't take struct nameidata *; unlike the previous +two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that +local filesystems can ignore tha argument - they are guaranteed that the +object doesn't exist. It's remote/distributed ones that might care... diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index b7413cb..fb0a6ae 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -40,6 +40,7 @@ Table of Contents 3.4 /proc/<pid>/coredump_filter - Core dump filtering settings 3.5 /proc/<pid>/mountinfo - Information about mounts 3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm + 3.7 /proc/<pid>/task/<tid>/children - Information about task children 4 Configuring procfs 4.1 Mount options @@ -310,6 +311,11 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7) start_data address above which program data+bss is placed end_data address below which program data+bss is placed start_brk address above which program heap can be expanded with brk() + arg_start address above which program command line is placed + arg_end address below which program command line is placed + env_start address above which program environment is placed + env_end address below which program environment is placed + exit_code the thread's exit_code in the form reported by the waitpid system call .............................................................................. The /proc/PID/maps file containing the currently mapped memory regions and @@ -743,6 +749,7 @@ Committed_AS: 100056 kB VmallocTotal: 112216 kB VmallocUsed: 428 kB VmallocChunk: 111088 kB +AnonHugePages: 49152 kB MemTotal: Total usable ram (i.e. physical ram minus a few reserved bits and the kernel binary code) @@ -776,6 +783,7 @@ VmallocChunk: 111088 kB Dirty: Memory which is waiting to get written back to the disk Writeback: Memory which is actively being written back to the disk AnonPages: Non-file backed pages mapped into userspace page tables +AnonHugePages: Non-file backed huge pages mapped into userspace page tables Mapped: files which have been mmaped, such as libraries Slab: in-kernel data structures cache SReclaimable: Part of Slab, that might be reclaimed, such as caches @@ -996,7 +1004,6 @@ Table 1-9: Network info in /proc/net snmp SNMP data sockstat Socket statistics tcp TCP sockets - tr_rif Token ring RIF routing table udp UDP sockets unix UNIX domain sockets wireless Wireless interface data (Wavelan etc) @@ -1577,6 +1584,23 @@ then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated comm value. +3.7 /proc/<pid>/task/<tid>/children - Information about task children +------------------------------------------------------------------------- +This file provides a fast way to retrieve first level children pids +of a task pointed by <pid>/<tid> pair. The format is a space separated +stream of pids. + +Note the "first level" here -- if a child has own children they will +not be listed here, one needs to read /proc/<children-pid>/task/<tid>/children +to obtain the descendants. + +Since this interface is intended to be fast and cheap it doesn't +guarantee to provide precise results and some children might be +skipped, especially if they've exited right after we printed their +pids, so one need to either stop or freeze processes being inspected +if precise results are needed. + + ------------------------------------------------------------------------------ Configuring procfs ------------------------------------------------------------------------------ diff --git a/Documentation/filesystems/qnx6.txt b/Documentation/filesystems/qnx6.txt index 050223e..e59f2f0 100644 --- a/Documentation/filesystems/qnx6.txt +++ b/Documentation/filesystems/qnx6.txt @@ -17,7 +17,7 @@ concepts of blocks, inodes and directories. On QNX it is possible to create little endian and big endian qnx6 filesystems. This feature makes it possible to create and use a different endianness fs for the target (QNX is used on quite a range of embedded systems) plattform -running on a different endianess. +running on a different endianness. The Linux driver handles endianness transparently. (LE and BE) Blocks @@ -26,7 +26,7 @@ Blocks The space in the device or file is split up into blocks. These are a fixed size of 512, 1024, 2048 or 4096, which is decided when the filesystem is created. -Blockpointers are 32bit, so the maximum space that can be adressed is +Blockpointers are 32bit, so the maximum space that can be addressed is 2^32 * 4096 bytes or 16TB The superblocks @@ -47,16 +47,16 @@ inactive superblock. Each superblock holds a set of root inodes for the different filesystem parts. (Inode, Bitmap and Longfilenames) Each of these root nodes holds information like total size of the stored -data and the adressing levels in that specific tree. -If the level value is 0, up to 16 direct blocks can be adressed by each +data and the addressing levels in that specific tree. +If the level value is 0, up to 16 direct blocks can be addressed by each node. -Level 1 adds an additional indirect adressing level where each indirect -adressing block holds up to blocksize / 4 bytes pointers to data blocks. -Level 2 adds an additional indirect adressig block level (so, already up -to 16 * 256 * 256 = 1048576 blocks that can be adressed by such a tree)a +Level 1 adds an additional indirect addressing level where each indirect +addressing block holds up to blocksize / 4 bytes pointers to data blocks. +Level 2 adds an additional indirect addressing block level (so, already up +to 16 * 256 * 256 = 1048576 blocks that can be addressed by such a tree). Unused block pointers are always set to ~0 - regardless of root node, -indirect adressing blocks or inodes. +indirect addressing blocks or inodes. Data leaves are always on the lowest level. So no data is stored on upper tree levels. @@ -64,7 +64,7 @@ The first Superblock is located at 0x2000. (0x2000 is the bootblock size) The Audi MMI 3G first superblock directly starts at byte 0. Second superblock position can either be calculated from the superblock information (total number of filesystem blocks) or by taking the highest -device address, zeroing the last 3 bytes and then substracting 0x1000 from +device address, zeroing the last 3 bytes and then subtracting 0x1000 from that address. 0x1000 is the size reserved for each superblock - regardless of the @@ -83,8 +83,8 @@ size, number of blocks used, access time, change time and modification time. Object mode field is POSIX format. (which makes things easier) There are also pointers to the first 16 blocks, if the object data can be -adressed with 16 direct blocks. -For more than 16 blocks an indirect adressing in form of another tree is +addressed with 16 direct blocks. +For more than 16 blocks an indirect addressing in form of another tree is used. (scheme is the same as the one used for the superblock root nodes) The filesize is stored 64bit. Inode counting starts with 1. (whilst long @@ -118,13 +118,13 @@ no block pointers and the directory file record pointing to the target file inode. Character and block special devices do not exist in QNX as those files -are handled by the QNX kernel/drivers and created in /dev independant of the +are handled by the QNX kernel/drivers and created in /dev independent of the underlaying filesystem. Long filenames -------------- -Long filenames are stored in a seperate adressing tree. The staring point +Long filenames are stored in a separate addressing tree. The staring point is the longfilename root node in the active superblock. Each data block (tree leaves) holds one long filename. That filename is limited to 510 bytes. The first two starting bytes are used as length field diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 0d04920..aa754e0 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -341,8 +341,8 @@ This describes how the VFS can manipulate an inode in your filesystem. As of kernel 2.6.22, the following members are defined: struct inode_operations { - int (*create) (struct inode *,struct dentry *, umode_t, struct nameidata *); - struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *); + int (*create) (struct inode *,struct dentry *, umode_t, bool); + struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int); int (*link) (struct dentry *,struct inode *,struct dentry *); int (*unlink) (struct inode *,struct dentry *); int (*symlink) (struct inode *,struct dentry *,const char *); @@ -363,7 +363,10 @@ struct inode_operations { ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t); ssize_t (*listxattr) (struct dentry *, char *, size_t); int (*removexattr) (struct dentry *, const char *); - void (*truncate_range)(struct inode *, loff_t, loff_t); + void (*update_time)(struct inode *, struct timespec *, int); + int (*atomic_open)(struct inode *, struct dentry *, + struct file *, unsigned open_flag, + umode_t create_mode, int *opened); }; Again, all methods are called without any locks being held, unless @@ -472,9 +475,17 @@ otherwise noted. removexattr: called by the VFS to remove an extended attribute from a file. This method is called by removexattr(2) system call. - truncate_range: a method provided by the underlying filesystem to truncate a - range of blocks , i.e. punch a hole somewhere in a file. + update_time: called by the VFS to update a specific time or the i_version of + an inode. If this is not defined the VFS will update the inode itself + and call mark_inode_dirty_sync. + atomic_open: called on the last component of an open. Using this optional + method the filesystem can look up, possibly create and open the file in + one atomic operation. If it cannot perform this (e.g. the file type + turned out to be wrong) it may signal this by returning 1 instead of + usual 0 or -ve . This method is only called if the last + component is negative or needs lookup. Cached positive dentries are + still handled by f_op->open(). The Address Space Object ======================== @@ -760,7 +771,7 @@ struct file_operations ---------------------- This describes how the VFS can manipulate an open file. As of kernel -2.6.22, the following members are defined: +3.5, the following members are defined: struct file_operations { struct module *owner; @@ -790,6 +801,8 @@ struct file_operations { int (*flock) (struct file *, int, struct file_lock *); ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned int); ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned int); + int (*setlease)(struct file *, long arg, struct file_lock **); + long (*fallocate)(struct file *, int mode, loff_t offset, loff_t len); }; Again, all methods are called without any locks being held, unless @@ -858,6 +871,11 @@ otherwise noted. splice_read: called by the VFS to splice data from file to a pipe. This method is used by the splice(2) system call + setlease: called by the VFS to set or release a file lock lease. + setlease has the file_lock_lock held and must not sleep. + + fallocate: called by the VFS to preallocate blocks or punch a hole. + Note that the file operations are implemented by the specific filesystem in which the inode resides. When opening a device node (character or block special) most filesystems will call special @@ -884,7 +902,7 @@ the VFS uses a default. As of kernel 2.6.22, the following members are defined: struct dentry_operations { - int (*d_revalidate)(struct dentry *, struct nameidata *); + int (*d_revalidate)(struct dentry *, unsigned int); int (*d_hash)(const struct dentry *, const struct inode *, struct qstr *); int (*d_compare)(const struct dentry *, const struct inode *, @@ -903,11 +921,11 @@ struct dentry_operations { dcache. Most filesystems leave this as NULL, because all their dentries in the dcache are valid - d_revalidate may be called in rcu-walk mode (nd->flags & LOOKUP_RCU). + d_revalidate may be called in rcu-walk mode (flags & LOOKUP_RCU). If in rcu-walk mode, the filesystem must revalidate the dentry without blocking or storing to the dentry, d_parent and d_inode should not be - used without care (because they can go NULL), instead nd->inode should - be used. + used without care (because they can change and, in d_inode case, even + become NULL under us). If a situation is encountered that rcu-walk cannot handle, return -ECHILD and it will be called again in ref-walk mode. diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index 620a078..e08a883 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt @@ -322,6 +322,9 @@ where 'flags' is currently defined to specify the following properties: * GPIOF_OPEN_DRAIN - gpio pin is open drain type. * GPIOF_OPEN_SOURCE - gpio pin is open source type. + * GPIOF_EXPORT_DIR_FIXED - export gpio to sysfs, keep direction + * GPIOF_EXPORT_DIR_CHANGEABLE - also export, allow changing direction + since GPIOF_INIT_* are only valid when configured as output, so group valid combinations as: diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt new file mode 100644 index 0000000..4627c42 --- /dev/null +++ b/Documentation/hid/uhid.txt @@ -0,0 +1,169 @@ + UHID - User-space I/O driver support for HID subsystem + ======================================================== + +The HID subsystem needs two kinds of drivers. In this document we call them: + + 1. The "HID I/O Driver" is the driver that performs raw data I/O to the + low-level device. Internally, they register an hid_ll_driver structure with + the HID core. They perform device setup, read raw data from the device and + push it into the HID subsystem and they provide a callback so the HID + subsystem can send data to the device. + + 2. The "HID Device Driver" is the driver that parses HID reports and reacts on + them. There are generic drivers like "generic-usb" and "generic-bluetooth" + which adhere to the HID specification and provide the standardizes features. + But there may be special drivers and quirks for each non-standard device out + there. Internally, they use the hid_driver structure. + +Historically, the USB stack was the first subsystem to provide an HID I/O +Driver. However, other standards like Bluetooth have adopted the HID specs and +may provide HID I/O Drivers, too. The UHID driver allows to implement HID I/O +Drivers in user-space and feed the data into the kernel HID-subsystem. + +This allows user-space to operate on the same level as USB-HID, Bluetooth-HID +and similar. It does not provide a way to write HID Device Drivers, though. Use +hidraw for this purpose. + +There is an example user-space application in ./samples/uhid/uhid-example.c + +The UHID API +------------ + +UHID is accessed through a character misc-device. The minor-number is allocated +dynamically so you need to rely on udev (or similar) to create the device node. +This is /dev/uhid by default. + +If a new device is detected by your HID I/O Driver and you want to register this +device with the HID subsystem, then you need to open /dev/uhid once for each +device you want to register. All further communication is done by read()'ing or +write()'ing "struct uhid_event" objects. Non-blocking operations are supported +by setting O_NONBLOCK. + +struct uhid_event { + __u32 type; + union { + struct uhid_create_req create; + struct uhid_data_req data; + ... + } u; +}; + +The "type" field contains the ID of the event. Depending on the ID different +payloads are sent. You must not split a single event across multiple read()'s or +multiple write()'s. A single event must always be sent as a whole. Furthermore, +only a single event can be sent per read() or write(). Pending data is ignored. +If you want to handle multiple events in a single syscall, then use vectored +I/O with readv()/writev(). + +The first thing you should do is sending an UHID_CREATE event. This will +register the device. UHID will respond with an UHID_START event. You can now +start sending data to and reading data from UHID. However, unless UHID sends the +UHID_OPEN event, the internally attached HID Device Driver has no user attached. +That is, you might put your device asleep unless you receive the UHID_OPEN +event. If you receive the UHID_OPEN event, you should start I/O. If the last +user closes the HID device, you will receive an UHID_CLOSE event. This may be +followed by an UHID_OPEN event again and so on. There is no need to perform +reference-counting in user-space. That is, you will never receive multiple +UHID_OPEN events without an UHID_CLOSE event. The HID subsystem performs +ref-counting for you. +You may decide to ignore UHID_OPEN/UHID_CLOSE, though. I/O is allowed even +though the device may have no users. + +If you want to send data to the HID subsystem, you send an HID_INPUT event with +your raw data payload. If the kernel wants to send data to the device, you will +read an UHID_OUTPUT or UHID_OUTPUT_EV event. + +If your device disconnects, you should send an UHID_DESTROY event. This will +unregister the device. You can now send UHID_CREATE again to register a new +device. +If you close() the fd, the device is automatically unregistered and destroyed +internally. + +write() +------- +write() allows you to modify the state of the device and feed input data into +the kernel. The following types are supported: UHID_CREATE, UHID_DESTROY and +UHID_INPUT. The kernel will parse the event immediately and if the event ID is +not supported, it will return -EOPNOTSUPP. If the payload is invalid, then +-EINVAL is returned, otherwise, the amount of data that was read is returned and +the request was handled successfully. + + UHID_CREATE: + This creates the internal HID device. No I/O is possible until you send this + event to the kernel. The payload is of type struct uhid_create_req and + contains information about your device. You can start I/O now. + + UHID_DESTROY: + This destroys the internal HID device. No further I/O will be accepted. There + may still be pending messages that you can receive with read() but no further + UHID_INPUT events can be sent to the kernel. + You can create a new device by sending UHID_CREATE again. There is no need to + reopen the character device. + + UHID_INPUT: + You must send UHID_CREATE before sending input to the kernel! This event + contains a data-payload. This is the raw data that you read from your device. + The kernel will parse the HID reports and react on it. + + UHID_FEATURE_ANSWER: + If you receive a UHID_FEATURE request you must answer with this request. You + must copy the "id" field from the request into the answer. Set the "err" field + to 0 if no error occured or to EIO if an I/O error occurred. + If "err" is 0 then you should fill the buffer of the answer with the results + of the feature request and set "size" correspondingly. + +read() +------ +read() will return a queued ouput report. These output reports can be of type +UHID_START, UHID_STOP, UHID_OPEN, UHID_CLOSE, UHID_OUTPUT or UHID_OUTPUT_EV. No +reaction is required to any of them but you should handle them according to your +needs. Only UHID_OUTPUT and UHID_OUTPUT_EV have payloads. + + UHID_START: + This is sent when the HID device is started. Consider this as an answer to + UHID_CREATE. This is always the first event that is sent. + + UHID_STOP: + This is sent when the HID device is stopped. Consider this as an answer to + UHID_DESTROY. + If the kernel HID device driver closes the device manually (that is, you + didn't send UHID_DESTROY) then you should consider this device closed and send + an UHID_DESTROY event. You may want to reregister your device, though. This is + always the last message that is sent to you unless you reopen the device with + UHID_CREATE. + + UHID_OPEN: + This is sent when the HID device is opened. That is, the data that the HID + device provides is read by some other process. You may ignore this event but + it is useful for power-management. As long as you haven't received this event + there is actually no other process that reads your data so there is no need to + send UHID_INPUT events to the kernel. + + UHID_CLOSE: + This is sent when there are no more processes which read the HID data. It is + the counterpart of UHID_OPEN and you may as well ignore this event. + + UHID_OUTPUT: + This is sent if the HID device driver wants to send raw data to the I/O + device. You should read the payload and forward it to the device. The payload + is of type "struct uhid_data_req". + This may be received even though you haven't received UHID_OPEN, yet. + + UHID_OUTPUT_EV: + Same as UHID_OUTPUT but this contains a "struct input_event" as payload. This + is called for force-feedback, LED or similar events which are received through + an input device by the HID subsystem. You should convert this into raw reports + and send them to your device similar to events of type UHID_OUTPUT. + + UHID_FEATURE: + This event is sent if the kernel driver wants to perform a feature request as + described in the HID specs. The report-type and report-number are available in + the payload. + The kernel serializes feature requests so there will never be two in parallel. + However, if you fail to respond with a UHID_FEATURE_ANSWER in a time-span of 5 + seconds, then the requests will be dropped and a new one might be sent. + Therefore, the payload also contains an "id" field that identifies every + request. + +Document by: + David Herrmann <dh.herrmann@googlemail.com> diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index 84d46c0..c86b50c 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp @@ -6,7 +6,9 @@ Supported chips: Prefix: 'coretemp' CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm), 0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm), - 0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield) + 0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield), + 0x26 (Tunnel Creek Atom), 0x27 (Medfield Atom), + 0x36 (Cedar Trail Atom) Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide http://softwarecommunity.intel.com/Wiki/Mobility/720.htm @@ -52,6 +54,17 @@ Some information comes from ark.intel.com Process Processor TjMax(C) +22nm Core i5/i7 Processors + i7 3920XM, 3820QM, 3720QM, 3667U, 3520M 105 + i5 3427U, 3360M/3320M 105 + i7 3770/3770K 105 + i5 3570/3570K, 3550, 3470/3450 105 + i7 3770S 103 + i5 3570S/3550S, 3475S/3470S/3450S 103 + i7 3770T 94 + i5 3570T 94 + i5 3470T 91 + 32nm Core i3/i5/i7 Processors i7 660UM/640/620, 640LM/620, 620M, 610E 105 i5 540UM/520/430, 540M/520/450/430 105 @@ -65,6 +78,11 @@ Process Processor TjMax(C) U3400 105 P4505/P4500 90 +32nm Atom Processors + Z2460 90 + D2700/2550/2500 100 + N2850/2800/2650/2600 100 + 45nm Xeon Processors 5400 Quad-Core X5492, X5482, X5472, X5470, X5460, X5450 85 E5472, E5462, E5450/40/30/20/10/05 85 @@ -85,6 +103,8 @@ Process Processor TjMax(C) N475/470/455/450 100 N280/270 90 330/230 125 + E680/660/640/620 90 + E680T/660T/640T/620T 110 45nm Core2 Processors Solo ULV SU3500/3300 100 diff --git a/Documentation/hwmon/da9052 b/Documentation/hwmon/da9052 new file mode 100644 index 0000000..ef89855 --- /dev/null +++ b/Documentation/hwmon/da9052 @@ -0,0 +1,61 @@ +Supported chips: + * Dialog Semiconductors DA9052-BC and DA9053-AA/Bx PMICs + Prefix: 'da9052' + Datasheet: Datasheet is not publicly available. + +Authors: David Dajun Chen <dchen@diasemi.com> + +Description +----------- + +The DA9052/53 provides an Analogue to Digital Converter (ADC) with 10 bits +resolution and track and hold circuitry combined with an analogue input +multiplexer. The analogue input multiplexer will allow conversion of up to 10 +different inputs. The track and hold circuit ensures stable input voltages at +the input of the ADC during the conversion. + +The ADC is used to measure the following inputs: +Channel 0: VDDOUT - measurement of the system voltage +Channel 1: ICH - internal battery charger current measurement +Channel 2: TBAT - output from the battery NTC +Channel 3: VBAT - measurement of the battery voltage +Channel 4: ADC_IN4 - high impedance input (0 - 2.5V) +Channel 5: ADC_IN5 - high impedance input (0 - 2.5V) +Channel 6: ADC_IN6 - high impedance input (0 - 2.5V) +Channel 7: XY - TSI interface to measure the X and Y voltage of the touch + screen resistive potentiometers +Channel 8: Internal Tjunc. - sense (internal temp. sensor) +Channel 9: VBBAT - measurement of the backup battery voltage + +By using sysfs attributes we can measure the system voltage VDDOUT, the battery +charging current ICH, battery temperature TBAT, battery junction temperature +TJUNC, battery voltage VBAT and the back up battery voltage VBBAT. + +Voltage Monitoring +------------------ + +Voltages are sampled by a 10 bit ADC. + +The battery voltage is calculated as: + Milli volt = ((ADC value * 1000) / 512) + 2500 + +The backup battery voltage is calculated as: + Milli volt = (ADC value * 2500) / 512; + +The voltages on ADC channels 4, 5 and 6 are calculated as: + Milli volt = (ADC value * 2500) / 1023 + +Temperature Monitoring +---------------------- + +Temperatures are sampled by a 10 bit ADC. Junction and battery temperatures +are monitored by the ADC channels. + +The junction temperature is calculated: + Degrees celsius = 1.708 * (TJUNC_RES - T_OFFSET) - 108.8 +The junction temperature attribute is supported by the driver. + +The battery temperature is calculated: + Degree Celcius = 1 / (t1 + 1/298)- 273 +where t1 = (1/B)* ln(( ADCval * 2.5)/(R25*ITBAT*255)) +Default values of R25, B, ITBAT are 10e3, 3380 and 50e-6 respectively. diff --git a/Documentation/hwmon/hih6130 b/Documentation/hwmon/hih6130 new file mode 100644 index 0000000..73dae91 --- /dev/null +++ b/Documentation/hwmon/hih6130 @@ -0,0 +1,37 @@ +Kernel driver hih6130 +===================== + +Supported chips: + * Honeywell HIH-6130 / HIH-6131 + Prefix: 'hih6130' + Addresses scanned: none + Datasheet: Publicly available at the Honeywell website + http://sensing.honeywell.com/index.php?ci_id=3106&la_id=1&defId=44872 + +Author: + Iain Paton <ipaton0@gmail.com> + +Description +----------- + +The HIH-6130 & HIH-6131 are humidity and temperature sensors in a SO8 package. +The difference between the two devices is that the HIH-6131 has a condensation +filter. + +The devices communicate with the I2C protocol. All sensors are set to the same +I2C address 0x27 by default, so an entry with I2C_BOARD_INFO("hih6130", 0x27) +can be used in the board setup code. + +Please see Documentation/i2c/instantiating-devices for details on how to +instantiate I2C devices. + +sysfs-Interface +--------------- + +temp1_input - temperature input +humidity1_input - humidity input + +Notes +----- + +Command mode and alarms are not currently supported. diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx new file mode 100644 index 0000000..f50a6cc --- /dev/null +++ b/Documentation/hwmon/ina2xx @@ -0,0 +1,29 @@ +Kernel driver ina2xx +==================== + +Supported chips: + * Texas Instruments INA219 + Prefix: 'ina219' + Addresses: I2C 0x40 - 0x4f + Datasheet: Publicly available at the Texas Instruments website + http://www.ti.com/ + + * Texas Instruments INA226 + Prefix: 'ina226' + Addresses: I2C 0x40 - 0x4f + Datasheet: Publicly available at the Texas Instruments website + http://www.ti.com/ + +Author: Lothar Felten <l-felten@ti.com> + +Description +----------- + +The INA219 is a high-side current shunt and power monitor with an I2C +interface. The INA219 monitors both shunt drop and supply voltage, with +programmable conversion times and filtering. + +The INA226 is a current shunt and power monitor with an I2C interface. +The INA226 monitors both a shunt voltage drop and bus supply voltage. + +The shunt value in micro-ohms can be set via platform data. diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index 23b7def..87850d8 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -30,6 +30,14 @@ Supported chips: Prefix: 'it8728' Addresses scanned: from Super I/O config space (8 I/O ports) Datasheet: Not publicly available + * IT8782F + Prefix: 'it8782' + Addresses scanned: from Super I/O config space (8 I/O ports) + Datasheet: Not publicly available + * IT8783E/F + Prefix: 'it8783' + Addresses scanned: from Super I/O config space (8 I/O ports) + Datasheet: Not publicly available * SiS950 [clone of IT8705F] Prefix: 'it87' Addresses scanned: from Super I/O config space (8 I/O ports) @@ -63,7 +71,7 @@ Module Parameters Hardware Interfaces ------------------- -All the chips suported by this driver are LPC Super-I/O chips, accessed +All the chips supported by this driver are LPC Super-I/O chips, accessed through the LPC bus (ISA-like I/O ports). The IT8712F additionally has an SMBus interface to the hardware monitoring functions. This driver no longer supports this interface though, as it is slower and less reliable @@ -75,7 +83,8 @@ Description ----------- This driver implements support for the IT8705F, IT8712F, IT8716F, -IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E and SiS950 chips. +IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8781F, 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 @@ -99,11 +108,11 @@ The IT8716F, IT8718F, IT8720F, IT8721F/IT8758E and later IT8712F revisions have support for 2 additional fans. The additional fans are supported by the driver. -The IT8716F, IT8718F, IT8720F and IT8721F/IT8758E, and late IT8712F and -IT8705F also have optional 16-bit tachometer counters for fans 1 to 3. This -is better (no more fan clock divider mess) but not compatible with the older -chips and revisions. The 16-bit tachometer mode is enabled by the driver when -one of the above chips is detected. +The IT8716F, IT8718F, IT8720F, IT8721F/IT8758E, IT8782F, IT8783E/F, and late +IT8712F and IT8705F also have optional 16-bit tachometer counters for fans 1 to +3. This is better (no more fan clock divider mess) but not compatible with the +older chips and revisions. The 16-bit tachometer mode is enabled by the driver +when one of the above chips is detected. The IT8726F is just bit enhanced IT8716F with additional hardware for AMD power sequencing. Therefore the chip will appear as IT8716F @@ -131,9 +140,10 @@ inputs can measure voltages between 0 and 4.08 volts, with a resolution of 0.016 volt (except IT8721F/IT8758E and IT8728F: 0.012 volt.) The battery voltage in8 does not have limit registers. -On the IT8721F/IT8758E, some voltage inputs are internal and scaled inside -the chip (in7, in8 and optionally in3). The driver handles this transparently -so user-space doesn't have to care. +On the IT8721F/IT8758E, IT8782F, and IT8783E/F, some voltage inputs are +internal and scaled inside the chip (in7 (optional for IT8782F and IT8783E/F), +in8 and optionally in3). The driver handles this transparently so user-space +doesn't have to care. The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value: the voltage level your processor should work with. This is hardcoded by diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches index 86f42e8..790f774 100644 --- a/Documentation/hwmon/submitting-patches +++ b/Documentation/hwmon/submitting-patches @@ -70,6 +70,9 @@ increase the chances of your change being accepted. review more difficult. It may also result in code which is more complicated than necessary. Use inline functions or just regular functions instead. +* Use devres functions whenever possible to allocate resources. For rationale + and supported functions, please see Documentation/driver-model/devres.txt. + * If the driver has a detect function, make sure it is silent. Debug messages and messages printed after a successful detection are acceptable, but it must not print messages such as "Chip XXX not found/supported". diff --git a/Documentation/hwmon/wm831x b/Documentation/hwmon/wm831x index 24f47d8..1144675 100644 --- a/Documentation/hwmon/wm831x +++ b/Documentation/hwmon/wm831x @@ -22,7 +22,7 @@ reporting of all the input values but does not provide any alarms. Voltage Monitoring ------------------ -Voltages are sampled by a 12 bit ADC. Voltages in milivolts are 1.465 +Voltages are sampled by a 12 bit ADC. Voltages in millivolts are 1.465 times the ADC value. Temperature Monitoring diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 71f55bb..615142d 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -38,9 +38,10 @@ Module Parameters Disable selected features normally supported by the device. This makes it possible to work around possible driver or hardware bugs if the feature in question doesn't work as intended for whatever reason. Bit values: - 1 disable SMBus PEC - 2 disable the block buffer - 8 disable the I2C block read functionality + 0x01 disable SMBus PEC + 0x02 disable the block buffer + 0x08 disable the I2C block read functionality + 0x10 don't use interrupts Description @@ -86,6 +87,12 @@ SMBus 2.0 Support The 82801DB (ICH4) and later chips support several SMBus 2.0 features. +Interrupt Support +----------------- + +PCI interrupt support is supported on the 82801EB (ICH5) and later chips. + + Hidden ICH SMBus ---------------- diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index 475bb4a..1e6634f 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 @@ -8,6 +8,11 @@ Supported adapters: Datasheet: Only available via NDA from ServerWorks * ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges Datasheet: Not publicly available + SB700 register reference available at: + http://support.amd.com/us/Embedded_TechDocs/43009_sb7xx_rrg_pub_1.00.pdf + * AMD SP5100 (SB700 derivative found on some server mainboards) + Datasheet: Publicly available at the AMD website + http://support.amd.com/us/Embedded_TechDocs/44413.pdf * AMD Hudson-2 Datasheet: Not publicly available * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge @@ -68,6 +73,10 @@ this driver on those mainboards. The ServerWorks Southbridges, the Intel 440MX, and the Victory66 are identical to the PIIX4 in I2C/SMBus support. +The AMD SB700 and SP5100 chipsets implement two PIIX4-compatible SMBus +controllers. If your BIOS initializes the secondary controller, it will +be detected by this driver as an "Auxiliary SMBus Host Controller". + If you own Force CPCI735 motherboard or other OSB4 based systems you may need to change the SMBus Interrupt Select register so the SMBus controller uses the SMI mode. diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality index 42c17c1..b0ff2ab 100644 --- a/Documentation/i2c/functionality +++ b/Documentation/i2c/functionality @@ -18,9 +18,9 @@ For the most up-to-date list of functionality constants, please check adapters typically can not do these) I2C_FUNC_10BIT_ADDR Handles the 10-bit address extensions I2C_FUNC_PROTOCOL_MANGLING Knows about the I2C_M_IGNORE_NAK, - I2C_M_REV_DIR_ADDR, I2C_M_NOSTART and - I2C_M_NO_RD_ACK flags (which modify the - I2C protocol!) + I2C_M_REV_DIR_ADDR and I2C_M_NO_RD_ACK + flags (which modify the I2C protocol!) + I2C_FUNC_NOSTART Can skip repeated start sequence I2C_FUNC_SMBUS_QUICK Handles the SMBus write_quick command I2C_FUNC_SMBUS_READ_BYTE Handles the SMBus read_byte command I2C_FUNC_SMBUS_WRITE_BYTE Handles the SMBus write_byte command @@ -50,6 +50,9 @@ A few combinations of the above flags are also defined for your convenience: emulated by a real I2C adapter (using the transparent emulation layer) +In kernel versions prior to 3.5 I2C_FUNC_NOSTART was implemented as +part of I2C_FUNC_PROTOCOL_MANGLING. + ADAPTER IMPLEMENTATION ---------------------- diff --git a/Documentation/i2c/i2c-protocol b/Documentation/i2c/i2c-protocol index 10518dd..0b3e62d 100644 --- a/Documentation/i2c/i2c-protocol +++ b/Documentation/i2c/i2c-protocol @@ -49,7 +49,9 @@ a byte read, followed by a byte write: Modified transactions ===================== -We have found some I2C devices that needs the following modifications: +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: Flag I2C_M_NOSTART: In a combined transaction, no 'S Addr Wr/Rd [A]' is generated at some @@ -60,6 +62,11 @@ We have found some I2C devices that needs the following modifications: we do not generate Addr, but we do generate the startbit S. This will probably confuse all other clients on your bus, so don't try this. + This is often used to gather transmits from multiple data buffers in + system memory into something that appears as a single transfer to the + I2C device but may also be used between direction changes by some + rare devices. + Flags 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 diff --git a/Documentation/i2c/muxes/gpio-i2cmux b/Documentation/i2c/muxes/i2c-mux-gpio index 811cd78..bd9b229 100644 --- a/Documentation/i2c/muxes/gpio-i2cmux +++ b/Documentation/i2c/muxes/i2c-mux-gpio @@ -1,11 +1,11 @@ -Kernel driver gpio-i2cmux +Kernel driver i2c-gpio-mux Author: Peter Korsgaard <peter.korsgaard@barco.com> Description ----------- -gpio-i2cmux is an i2c mux driver providing access to I2C bus segments +i2c-gpio-mux is an i2c mux driver providing access to I2C bus segments from a master I2C bus and a hardware MUX controlled through GPIO pins. E.G.: @@ -26,16 +26,16 @@ according to the settings of the GPIO pins 1..N. Usage ----- -gpio-i2cmux uses the platform bus, so you need to provide a struct +i2c-gpio-mux uses the platform bus, so you need to provide a struct platform_device with the platform_data pointing to a struct gpio_i2cmux_platform_data with the I2C adapter number of the master bus, the number of bus segments to create and the GPIO pins used -to control it. See include/linux/gpio-i2cmux.h for details. +to control it. See include/linux/i2c-gpio-mux.h for details. E.G. something like this for a MUX providing 4 bus segments controlled through 3 GPIO pins: -#include <linux/gpio-i2cmux.h> +#include <linux/i2c-gpio-mux.h> #include <linux/platform_device.h> static const unsigned myboard_gpiomux_gpios[] = { @@ -57,7 +57,7 @@ static struct gpio_i2cmux_platform_data myboard_i2cmux_data = { }; static struct platform_device myboard_i2cmux = { - .name = "gpio-i2cmux", + .name = "i2c-gpio-mux", .id = 0, .dev = { .platform_data = &myboard_i2cmux_data, diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 5aa5337..3a94b0e 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -245,21 +245,17 @@ static int __init foo_init(void) { return i2c_add_driver(&foo_driver); } +module_init(foo_init); static void __exit foo_cleanup(void) { i2c_del_driver(&foo_driver); } +module_exit(foo_cleanup); -/* Substitute your own name and email address */ -MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>" -MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices"); - -/* a few non-GPL license types are also allowed */ -MODULE_LICENSE("GPL"); +The module_i2c_driver() macro can be used to reduce above code. -module_init(foo_init); -module_exit(foo_cleanup); +module_i2c_driver(foo_driver); Note that some functions are marked by `__init'. These functions can be removed after kernel booting (or module loading) is completed. @@ -267,6 +263,17 @@ Likewise, functions marked by `__exit' are dropped by the compiler when the code is built into the kernel, as they would never be called. +Driver Information +================== + +/* Substitute your own name and email address */ +MODULE_AUTHOR("Frodo Looijaard <frodol@dds.nl>" +MODULE_DESCRIPTION("Driver for Barf Inc. Foo I2C devices"); + +/* a few non-GPL license types are also allowed */ +MODULE_LICENSE("GPL"); + + Power Management ================ diff --git a/Documentation/initrd.txt b/Documentation/initrd.txt index 1ba84f3..4e1839c 100644 --- a/Documentation/initrd.txt +++ b/Documentation/initrd.txt @@ -362,5 +362,5 @@ Resources http://www.almesberger.net/cv/papers/ols2k-9.ps.gz [2] newlib package (experimental), with initrd example http://sources.redhat.com/newlib/ -[3] Brouwer, Andries; "util-linux: Miscellaneous utilities for Linux" - ftp://ftp.win.tue.nl/pub/linux-local/utils/util-linux/ +[3] util-linux: Miscellaneous utilities for Linux + http://www.kernel.org/pub/linux/utils/util-linux/ diff --git a/Documentation/input/edt-ft5x06.txt b/Documentation/input/edt-ft5x06.txt new file mode 100644 index 0000000..2032f0b --- /dev/null +++ b/Documentation/input/edt-ft5x06.txt @@ -0,0 +1,54 @@ +EDT ft5x06 based Polytouch devices +---------------------------------- + +The edt-ft5x06 driver is useful for the EDT "Polytouch" family of capacitive +touch screens. Note that it is *not* suitable for other devices based on the +focaltec ft5x06 devices, since they contain vendor-specific firmware. In +particular this driver is not suitable for the Nook tablet. + +It has been tested with the following devices: + * EP0350M06 + * EP0430M06 + * EP0570M06 + * EP0700M06 + +The driver allows configuration of the touch screen via a set of sysfs files: + +/sys/class/input/eventX/device/device/threshold: + allows setting the "click"-threshold in the range from 20 to 80. + +/sys/class/input/eventX/device/device/gain: + allows setting the sensitivity in the range from 0 to 31. Note that + lower values indicate higher sensitivity. + +/sys/class/input/eventX/device/device/offset: + allows setting the edge compensation in the range from 0 to 31. + +/sys/class/input/eventX/device/device/report_rate: + allows setting the report rate in the range from 3 to 14. + + +For debugging purposes the driver provides a few files in the debug +filesystem (if available in the kernel). In /sys/kernel/debug/edt_ft5x06 +you'll find the following files: + +num_x, num_y: + (readonly) contains the number of sensor fields in X- and + Y-direction. + +mode: + allows switching the sensor between "factory mode" and "operation + mode" by writing "1" or "0" to it. In factory mode (1) it is + possible to get the raw data from the sensor. Note that in factory + mode regular events don't get delivered and the options described + above are unavailable. + +raw_data: + contains num_x * num_y big endian 16 bit values describing the raw + values for each sensor field. Note that each read() call on this + files triggers a new readout. It is recommended to provide a buffer + big enough to contain num_x * num_y * 2 bytes. + +Note that reading raw_data gives a I/O error when the device is not in factory +mode. The same happens when reading/writing to the parameter files when the +device is not in regular operation mode. diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt index 543101c..2c17961 100644 --- a/Documentation/input/multi-touch-protocol.txt +++ b/Documentation/input/multi-touch-protocol.txt @@ -162,26 +162,48 @@ are divided into categories, to allow for partial implementation. The minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which allows for multiple contacts to be tracked. If the device supports it, the ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size -of the contact area and approaching contact, respectively. +of the contact area and approaching tool, respectively. The TOUCH and WIDTH parameters have a geometrical interpretation; imagine looking through a window at someone gently holding a finger against the glass. You will see two regions, one inner region consisting of the part of the finger actually touching the glass, and one outer region formed by -the perimeter of the finger. The diameter of the inner region is the -ABS_MT_TOUCH_MAJOR, the diameter of the outer region is -ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder -against the glass. The inner region will increase, and in general, the -ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than -unity, is related to the contact pressure. For pressure-based devices, +the perimeter of the finger. The center of the touching region (a) is +ABS_MT_POSITION_X/Y and the center of the approaching finger (b) is +ABS_MT_TOOL_X/Y. The touch diameter is ABS_MT_TOUCH_MAJOR and the finger +diameter is ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger +harder against the glass. The touch region will increase, and in general, +the ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller +than unity, is related to the contact pressure. For pressure-based devices, ABS_MT_PRESSURE may be used to provide the pressure on the contact area instead. Devices capable of contact hovering can use ABS_MT_DISTANCE to indicate the distance between the contact and the surface. -In addition to the MAJOR parameters, the oval shape of the contact can be -described by adding the MINOR parameters, such that MAJOR and MINOR are the -major and minor axis of an ellipse. Finally, the orientation of the oval -shape can be describe with the ORIENTATION parameter. + + Linux MT Win8 + __________ _______________________ + / \ | | + / \ | | + / ____ \ | | + / / \ \ | | + \ \ a \ \ | a | + \ \____/ \ | | + \ \ | | + \ b \ | b | + \ \ | | + \ \ | | + \ \ | | + \ / | | + \ / | | + \ / | | + \__________/ |_______________________| + + +In addition to the MAJOR parameters, the oval shape of the touch and finger +regions can be described by adding the MINOR parameters, such that MAJOR +and MINOR are the major and minor axis of an ellipse. The orientation of +the touch ellipse can be described with the ORIENTATION parameter, and the +direction of the finger ellipse is given by the vector (a - b). For type A devices, further specification of the touch shape is possible via ABS_MT_BLOB_ID. @@ -224,7 +246,7 @@ tool. Omit if circular [4]. The above four values can be used to derive additional information about the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates the notion of pressure. The fingers of the hand and the palm all have -different characteristic widths [1]. +different characteristic widths. ABS_MT_PRESSURE @@ -240,17 +262,24 @@ the contact is hovering above the surface. ABS_MT_ORIENTATION -The orientation of the ellipse. The value should describe a signed quarter -of a revolution clockwise around the touch center. The signed value range -is arbitrary, but zero should be returned for a finger aligned along the Y -axis of the surface, a negative value when finger is turned to the left, and -a positive value when finger turned to the right. When completely aligned with -the X axis, the range max should be returned. Orientation can be omitted -if the touching object is circular, or if the information is not available -in the kernel driver. Partial orientation support is possible if the device -can distinguish between the two axis, but not (uniquely) any values in -between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1] -[4]. +The orientation of the touching ellipse. The value should describe a signed +quarter of a revolution clockwise around the touch center. The signed value +range is arbitrary, but zero should be returned for an ellipse aligned with +the Y axis of the surface, a negative value when the ellipse is turned to +the left, and a positive value when the ellipse is turned to the +right. When completely aligned with the X axis, the range max should be +returned. + +Touch ellipsis are symmetrical by default. For devices capable of true 360 +degree orientation, the reported orientation must exceed the range max to +indicate more than a quarter of a revolution. For an upside-down finger, +range max * 2 should be returned. + +Orientation can be omitted if the touch area is circular, or if the +information is not available in the kernel driver. Partial orientation +support is possible if the device can distinguish between the two axis, but +not (uniquely) any values in between. In such cases, the range of +ABS_MT_ORIENTATION should be [0, 1] [4]. ABS_MT_POSITION_X @@ -260,6 +289,23 @@ ABS_MT_POSITION_Y The surface Y coordinate of the center of the touching ellipse. +ABS_MT_TOOL_X + +The surface X coordinate of the center of the approaching tool. Omit if +the device cannot distinguish between the intended touch point and the +tool itself. + +ABS_MT_TOOL_Y + +The surface Y coordinate of the center of the approaching tool. Omit if the +device cannot distinguish between the intended touch point and the tool +itself. + +The four position values can be used to separate the position of the touch +from the position of the tool. If both positions are present, the major +tool axis points towards the touch point [1]. Otherwise, the tool axes are +aligned with the touch axes. + ABS_MT_TOOL_TYPE The type of approaching tool. A lot of kernel drivers cannot distinguish @@ -305,6 +351,28 @@ The range of ABS_MT_ORIENTATION should be set to [0, 1], to indicate that the device can distinguish between a finger along the Y axis (0) and a finger along the X axis (1). +For win8 devices with both T and C coordinates, the position mapping is + + ABS_MT_POSITION_X := T_X + ABS_MT_POSITION_Y := T_Y + ABS_MT_TOOL_X := C_X + ABS_MT_TOOL_X := C_Y + +Unfortunately, there is not enough information to specify both the touching +ellipse and the tool ellipse, so one has to resort to approximations. One +simple scheme, which is compatible with earlier usage, is: + + ABS_MT_TOUCH_MAJOR := min(X, Y) + ABS_MT_TOUCH_MINOR := <not used> + ABS_MT_ORIENTATION := <not used> + ABS_MT_WIDTH_MAJOR := min(X, Y) + distance(T, C) + ABS_MT_WIDTH_MINOR := min(X, Y) + +Rationale: We have no information about the orientation of the touching +ellipse, so approximate it with an inscribed circle instead. The tool +ellipse should align with the the vector (T - C), so the diameter must +increase with distance(T, C). Finally, assume that the touch diameter is +equal to the tool thickness, and we arrive at the formulas above. Finger Tracking --------------- @@ -338,9 +406,7 @@ subsequent events of the same type refer to different fingers. For example usage of the type A protocol, see the bcm5974 driver. For example usage of the type B protocol, see the hid-egalax driver. -[1] With the extension ABS_MT_APPROACH_X and ABS_MT_APPROACH_Y, the -difference between the contact position and the approaching tool position -could be used to derive tilt. +[1] Also, the difference (TOOL_X - POSITION_X) can be used to model tilt. [2] The list can of course be extended. [3] The mtdev project: http://bitmath.org/code/mtdev/. [4] See the section on event computation. diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index e34b531d..915f28c 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -120,6 +120,7 @@ Code Seq#(hex) Include File Comments 'G' 00-0F linux/gigaset_dev.h conflict! 'H' 00-7F linux/hiddev.h conflict! 'H' 00-0F linux/hidraw.h conflict! +'H' 01 linux/mei.h conflict! 'H' 00-0F sound/asound.h conflict! 'H' 20-40 sound/asound_fm.h conflict! 'H' 80-8F sound/sfnt_info.h conflict! diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index 68e32bb..6466704 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt @@ -50,6 +50,10 @@ LDFLAGS_MODULE -------------------------------------------------- Additional options used for $(LD) when linking modules. +LDFLAGS_vmlinux +-------------------------------------------------- +Additional options passed to final link of vmlinux. + KBUILD_VERBOSE -------------------------------------------------- Set the kbuild verbosity. Can be assigned same values as "V=...". @@ -214,3 +218,18 @@ KBUILD_BUILD_USER, KBUILD_BUILD_HOST These two variables allow to override the user@host string displayed during boot and in /proc/version. The default value is the output of the commands whoami and host, respectively. + +KBUILD_LDS +-------------------------------------------------- +The linker script with full path. Assigned by the top-level Makefile. + +KBUILD_VMLINUX_INIT +-------------------------------------------------- +All object files for the init (first) part of vmlinux. +Files specified with KBUILD_VMLINUX_INIT are linked first. + +KBUILD_VMLINUX_MAIN +-------------------------------------------------- +All object files for the main part of vmlinux. +KBUILD_VMLINUX_INIT and KBUILD_VMLINUX_MAIN together specify +all the object files used to link vmlinux. diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index 9d5f2a9..a09f1a6 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt @@ -53,15 +53,15 @@ KCONFIG_ALLCONFIG -------------------------------------------------- (partially based on lkml email from/by Rob Landley, re: miniconfig) -------------------------------------------------- -The allyesconfig/allmodconfig/allnoconfig/randconfig variants can -also use the environment variable KCONFIG_ALLCONFIG as a flag or a -filename that contains config symbols that the user requires to be -set to a specific value. If KCONFIG_ALLCONFIG is used without a -filename, "make *config" checks for a file named -"all{yes/mod/no/def/random}.config" (corresponding to the *config command -that was used) for symbol values that are to be forced. If this file -is not found, it checks for a file named "all.config" to contain forced -values. +The allyesconfig/allmodconfig/allnoconfig/randconfig variants can also +use the environment variable KCONFIG_ALLCONFIG as a flag or a filename +that contains config symbols that the user requires to be set to a +specific value. If KCONFIG_ALLCONFIG is used without a filename where +KCONFIG_ALLCONFIG == "" or KCONFIG_ALLCONFIG == "1", "make *config" +checks for a file named "all{yes/mod/no/def/random}.config" +(corresponding to the *config command that was used) for symbol values +that are to be forced. If this file is not found, it checks for a +file named "all.config" to contain forced values. This enables you to create "miniature" config (miniconfig) or custom config files containing just the config symbols that you are interested diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 506c739..13f1aa0 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -86,7 +86,7 @@ There is also a gitweb interface available at http://www.kernel.org/git/?p=utils/kernel/kexec/kexec-tools.git More information about kexec-tools can be found at -http://www.kernel.org/pub/linux/utils/kernel/kexec/README.html +http://horms.net/projects/kexec/ 3) Unpack the tarball with the tar command, as follows: diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c1601e5..ad7e2e5 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -70,7 +70,6 @@ parameter is applicable: M68k M68k architecture is enabled. These options have more detailed description inside of Documentation/m68k/kernel-options.txt. - MCA MCA bus support is enabled. MDA MDA console support is enabled. MIPS MIPS architecture is enabled. MOUSE Appropriate mouse support is enabled. @@ -110,6 +109,7 @@ parameter is applicable: USB USB support is enabled. USBHID USB Human Interface Device support is enabled. V4L Video For Linux support is enabled. + VMMIO Driver for memory mapped virtio devices is enabled. VGA The VGA console has been enabled. VT Virtual terminal support is enabled. WDT Watchdog support is enabled. @@ -335,6 +335,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. requirements as needed. This option does not override iommu=pt + amd_iommu_dump= [HW,X86-64] + Enable AMD IOMMU driver option to dump the ACPI table + for AMD IOMMU. With this option enabled, AMD IOMMU + driver will print ACPI tables for AMD IOMMU during + IOMMU initialization. + amijoy.map= [HW,JOY] Amiga joystick support Map of devices attached to JOY0DAT and JOY1DAT Format: <a>,<b> @@ -397,8 +403,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. atkbd.softrepeat= [HW] Use software keyboard repeat - autotest [IA-64] - baycom_epp= [HW,AX25] Format: <io>,<mode> @@ -508,6 +512,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 + memory allocations. For more information, see + include/linux/dma-contiguous.h + cmo_free_hint= [PPC] Format: { yes | no } Specify whether pages are marked as being inactive when they are freed. This is used in CMO environments @@ -515,6 +524,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. a hypervisor. Default: yes + coherent_pool=nn[KMG] [ARM,KNL] + Sets the size of memory pool for coherent, atomic dma + allocations, by default set to 256K. + code_bytes [X86] How many bytes of object code to print in an oops report. Range: 0 - 8192 @@ -610,7 +623,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot time. See Documentation/dynamic-debug-howto.txt for - details. + details. Deprecated, see dyndbg. debug [KNL] Enable kernel debugging (events log level). @@ -730,6 +743,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. dscc4.setup= [NET] + dyndbg[="val"] [KNL,DYNAMIC_DEBUG] + module.dyndbg[="val"] + Enable debug messages at boot time. See + Documentation/dynamic-debug-howto.txt for details. + earlycon= [KNL] Output early console device and options. uart[8250],io,<addr>[,options] uart[8250],mmio,<addr>[,options] @@ -982,6 +1000,20 @@ bytes respectively. Such letter suffixes can also be entirely omitted. i8k.restricted [HW] Allow controlling fans only if SYS_ADMIN capability is set. + i915.invert_brightness= + [DRM] Invert the sense of the variable that is used to + set the brightness of the panel backlight. Normally a + brightness value of 0 indicates backlight switched off, + and the maximum of the brightness value sets the backlight + to maximum brightness. If this parameter is set to 0 + (default) and the machine requires it, or this parameter + is set to 1, a brightness value of 0 sets the backlight + to maximum brightness, and the maximum of the brightness + value switches the backlight off. + -1 -- never invert brightness + 0 -- machine default + 1 -- force brightness inversion + icn= [HW,ISDN] Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]] @@ -1102,7 +1134,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. forcesac soft pt [x86, IA-64] - group_mf [x86, IA-64] io7= [HW] IO7 for Marvel based alpha systems @@ -1425,8 +1456,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. devices can be requested on-demand with the /dev/loop-control interface. - mcatest= [IA-64] - mce [X86-32] Machine Check Exception mce=option [X86-64] See Documentation/x86/x86_64/boot-options.txt @@ -2161,6 +2190,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. on: Turn realloc on realloc same as realloc=on noari do not use PCIe ARI. + pcie_scan_all Scan all possible PCIe devices. Otherwise we + only look for one device below a PCIe downstream + port. pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power Management. @@ -2330,18 +2362,105 @@ bytes respectively. Such letter suffixes can also be entirely omitted. ramdisk_size= [RAM] Sizes of RAM disks in kilobytes See Documentation/blockdev/ramdisk.txt. - rcupdate.blimit= [KNL,BOOT] + rcutree.blimit= [KNL,BOOT] Set maximum number of finished RCU callbacks to process in one batch. - rcupdate.qhimark= [KNL,BOOT] + rcutree.fanout_leaf= [KNL,BOOT] + Increase the number of CPUs assigned to each + leaf rcu_node structure. Useful for very large + systems. + + rcutree.qhimark= [KNL,BOOT] Set threshold of queued RCU callbacks over which batch limiting is disabled. - rcupdate.qlowmark= [KNL,BOOT] + rcutree.qlowmark= [KNL,BOOT] Set threshold of queued RCU callbacks below which batch limiting is re-enabled. + rcutree.rcu_cpu_stall_suppress= [KNL,BOOT] + Suppress RCU CPU stall warning messages. + + rcutree.rcu_cpu_stall_timeout= [KNL,BOOT] + Set timeout for RCU CPU stall warning messages. + + rcutorture.fqs_duration= [KNL,BOOT] + Set duration of force_quiescent_state bursts. + + rcutorture.fqs_holdoff= [KNL,BOOT] + Set holdoff time within force_quiescent_state bursts. + + rcutorture.fqs_stutter= [KNL,BOOT] + Set wait time between force_quiescent_state bursts. + + rcutorture.irqreader= [KNL,BOOT] + Test RCU readers from irq handlers. + + rcutorture.n_barrier_cbs= [KNL,BOOT] + Set callbacks/threads for rcu_barrier() testing. + + rcutorture.nfakewriters= [KNL,BOOT] + Set number of concurrent RCU writers. These just + stress RCU, they don't participate in the actual + test, hence the "fake". + + rcutorture.nreaders= [KNL,BOOT] + Set number of RCU readers. + + rcutorture.onoff_holdoff= [KNL,BOOT] + Set time (s) after boot for CPU-hotplug testing. + + rcutorture.onoff_interval= [KNL,BOOT] + Set time (s) between CPU-hotplug operations, or + zero to disable CPU-hotplug testing. + + rcutorture.shuffle_interval= [KNL,BOOT] + Set task-shuffle interval (s). Shuffling tasks + allows some CPUs to go into dyntick-idle mode + during the rcutorture test. + + rcutorture.shutdown_secs= [KNL,BOOT] + Set time (s) after boot system shutdown. This + is useful for hands-off automated testing. + + rcutorture.stall_cpu= [KNL,BOOT] + Duration of CPU stall (s) to test RCU CPU stall + warnings, zero to disable. + + rcutorture.stall_cpu_holdoff= [KNL,BOOT] + Time to wait (s) after boot before inducing stall. + + rcutorture.stat_interval= [KNL,BOOT] + Time (s) between statistics printk()s. + + rcutorture.stutter= [KNL,BOOT] + Time (s) to stutter testing, for example, specifying + five seconds causes the test to run for five seconds, + wait for five seconds, and so on. This tests RCU's + ability to transition abruptly to and from idle. + + rcutorture.test_boost= [KNL,BOOT] + Test RCU priority boosting? 0=no, 1=maybe, 2=yes. + "Maybe" means test if the RCU implementation + under test support RCU priority boosting. + + rcutorture.test_boost_duration= [KNL,BOOT] + Duration (s) of each individual boost test. + + rcutorture.test_boost_interval= [KNL,BOOT] + Interval (s) between each boost test. + + rcutorture.test_no_idle_hz= [KNL,BOOT] + Test RCU's dyntick-idle handling. See also the + rcutorture.shuffle_interval parameter. + + rcutorture.torture_type= [KNL,BOOT] + Specify the RCU implementation to test. + + rcutorture.verbose= [KNL,BOOT] + Enable additional printk() statements. + rdinit= [KNL] Format: <full_path> Run specified binary instead of /init from the ramdisk, @@ -2372,6 +2491,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. resume= [SWSUSP] Specify the partition device for software suspend + Format: + {/dev/<dev> | PARTUUID=<uuid> | <int>:<int> | <hex>} resume_offset= [SWSUSP] Specify the offset from the beginning of the partition @@ -2426,6 +2547,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted. sched_debug [KNL] Enables verbose scheduler debug messages. + skew_tick= [KNL] Offset the periodic timer tick per cpu to mitigate + xtime_lock contention on larger systems, and/or RCU lock + contention on all systems with CONFIG_MAXSMP set. + Format: { "0" | "1" } + 0 -- disable. (may be 1 via CONFIG_CMDLINE="skew_tick=1" + 1 -- enable. + Note: increases power consumption, thus should only be + enabled if running jitter sensitive (HPC/RT) workloads. + security= [SECURITY] Choose a security module to enable at boot. If this boot parameter is not specified, only the first security module asking for security registration will be @@ -2806,6 +2936,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. initial READ(10) command); o = CAPACITY_OK (accept the capacity reported by the device); + p = WRITE_CACHE (the device cache is ON + by default); r = IGNORE_RESIDUE (the device reports bogus residue values); s = SINGLE_LUN (the device has only one @@ -2847,6 +2979,22 @@ bytes respectively. Such letter suffixes can also be entirely omitted. video= [FB] Frame buffer configuration See Documentation/fb/modedb.txt. + virtio_mmio.device= + [VMMIO] Memory mapped virtio (platform) device. + + <size>@<baseaddr>:<irq>[:<id>] + where: + <size> := size (can use standard suffixes + like K, M and G) + <baseaddr> := physical base address + <irq> := interrupt number (as passed to + request_irq()) + <id> := (optional) platform device id + example: + virtio_mmio.device=1K@0x100b0000:48:7 + + Can be used multiple times for multiple devices. + vga= [BOOT,X86-32] Select a particular video mode See Documentation/x86/boot.txt and Documentation/svga.txt. diff --git a/Documentation/laptops/asus-laptop.txt b/Documentation/laptops/asus-laptop.txt index a1e04d6..69f9fb3 100644 --- a/Documentation/laptops/asus-laptop.txt +++ b/Documentation/laptops/asus-laptop.txt @@ -151,8 +151,7 @@ Display switching Debugging: 1) Check whether the Fn+F8 key: - a) does not lock the laptop (try disabling CONFIG_X86_UP_APIC or boot with - noapic / nolapic if it does) + a) does not lock the laptop (try a boot with noapic / nolapic if it does) b) generates events (0x6n, where n is the value corresponding to the configuration above) c) actually works diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX index 29f481d..5fefe37 100644 --- a/Documentation/leds/00-INDEX +++ b/Documentation/leds/00-INDEX @@ -6,3 +6,5 @@ leds-lp5521.txt - notes on how to use the leds-lp5521 driver. leds-lp5523.txt - notes on how to use the leds-lp5523 driver. +leds-lm3556.txt + - notes on how to use the leds-lm3556 driver. diff --git a/Documentation/leds/leds-blinkm.txt b/Documentation/leds/leds-blinkm.txt new file mode 100644 index 0000000..9dd92f4 --- /dev/null +++ b/Documentation/leds/leds-blinkm.txt @@ -0,0 +1,80 @@ +The leds-blinkm driver supports the devices of the BlinkM family. + +They are RGB-LED modules driven by a (AT)tiny microcontroller and +communicate through I2C. The default address of these modules is +0x09 but this can be changed through a command. By this you could +dasy-chain up to 127 BlinkMs on an I2C bus. + +The device accepts RGB and HSB color values through separate commands. +Also you can store blinking sequences as "scripts" in +the controller and run them. Also fading is an option. + +The interface this driver provides is 2-fold: + +a) LED class interface for use with triggers +############################################ + +The registration follows the scheme: +blinkm-<i2c-bus-nr>-<i2c-device-nr>-<color> + +$ ls -h /sys/class/leds/blinkm-6-* +/sys/class/leds/blinkm-6-9-blue: +brightness device max_brightness power subsystem trigger uevent + +/sys/class/leds/blinkm-6-9-green: +brightness device max_brightness power subsystem trigger uevent + +/sys/class/leds/blinkm-6-9-red: +brightness device max_brightness power subsystem trigger uevent + +(same is /sys/bus/i2c/devices/6-0009/leds) + +We can control the colors separated into red, green and blue and +assign triggers on each color. + +E.g.: + +$ cat blinkm-6-9-blue/brightness +05 + +$ echo 200 > blinkm-6-9-blue/brightness +$ + +$ modprobe ledtrig-heartbeat +$ echo heartbeat > blinkm-6-9-green/trigger +$ + + +b) Sysfs group to control rgb, fade, hsb, scripts ... +##################################################### + +This extended interface is available as folder blinkm +in the sysfs folder of the I2C device. +E.g. below /sys/bus/i2c/devices/6-0009/blinkm + +$ ls -h /sys/bus/i2c/devices/6-0009/blinkm/ +blue green red test + +Currently supported is just setting red, green, blue +and a test sequence. + +E.g.: + +$ cat * +00 +00 +00 +#Write into test to start test sequence!# + +$ echo 1 > test +$ + +$ echo 255 > red +$ + + + +as of 6/2012 + +dl9pf <at> gmx <dot> de + diff --git a/Documentation/leds/leds-lm3556.txt b/Documentation/leds/leds-lm3556.txt new file mode 100644 index 0000000..d9eb91b --- /dev/null +++ b/Documentation/leds/leds-lm3556.txt @@ -0,0 +1,85 @@ +Kernel driver for lm3556 +======================== + +*Texas Instrument: + 1.5 A Synchronous Boost LED Flash Driver w/ High-Side Current Source +* Datasheet: http://www.national.com/ds/LM/LM3556.pdf + +Authors: + Daniel Jeong + Contact:Daniel Jeong(daniel.jeong-at-ti.com, gshark.jeong-at-gmail.com) + +Description +----------- +There are 3 functions in LM3556, Flash, Torch and Indicator. + +FLASH MODE +In Flash Mode, the LED current source(LED) provides 16 target current levels +from 93.75 mA to 1500 mA.The Flash currents are adjusted via the CURRENT +CONTROL REGISTER(0x09).Flash mode is activated by the ENABLE REGISTER(0x0A), +or by pulling the STROBE pin HIGH. +LM3556 Flash can be controlled through sys/class/leds/flash/brightness file +* if STROBE pin is enabled, below example control brightness only, and +ON / OFF will be controlled by STROBE pin. + +Flash Example: +OFF : #echo 0 > sys/class/leds/flash/brightness +93.75 mA: #echo 1 > sys/class/leds/flash/brightness +... ..... +1500 mA: #echo 16 > sys/class/leds/flash/brightness + +TORCH MODE +In Torch Mode, the current source(LED) is programmed via the CURRENT CONTROL +REGISTER(0x09).Torch Mode is activated by the ENABLE REGISTER(0x0A) or by the +hardware TORCH input. +LM3556 torch can be controlled through sys/class/leds/torch/brightness file. +* if TORCH pin is enabled, below example control brightness only, +and ON / OFF will be controlled by TORCH pin. + +Torch Example: +OFF : #echo 0 > sys/class/leds/torch/brightness +46.88 mA: #echo 1 > sys/class/leds/torch/brightness +... ..... +375 mA : #echo 8 > sys/class/leds/torch/brightness + +INDICATOR MODE +Indicator pattern can be set through sys/class/leds/indicator/pattern file, +and 4 patterns are pre-defined in indicator_pattern array. +According to N-lank, Pulse time and N Period values, different pattern wiill +be generated.If you want new patterns for your own device, change +indicator_pattern array with your own values and INDIC_PATTERN_SIZE. +Please refer datasheet for more detail about N-Blank, Pulse time and N Period. + +Indicator pattern example: +pattern 0: #echo 0 > sys/class/leds/indicator/pattern +.... +pattern 3: #echo 3 > sys/class/leds/indicator/pattern + +Indicator brightness can be controlled through +sys/class/leds/indicator/brightness file. + +Example: +OFF : #echo 0 > sys/class/leds/indicator/brightness +5.86 mA : #echo 1 > sys/class/leds/indicator/brightness +........ +46.875mA : #echo 8 > sys/class/leds/indicator/brightness + +Notes +----- +Driver expects it is registered using the i2c_board_info mechanism. +To register the chip at address 0x63 on specific adapter, set the platform data +according to include/linux/platform_data/leds-lm3556.h, set the i2c board info + +Example: + static struct i2c_board_info __initdata board_i2c_ch4[] = { + { + I2C_BOARD_INFO(LM3556_NAME, 0x63), + .platform_data = &lm3556_pdata, + }, + }; + +and register it in the platform init function + +Example: + board_register_i2c_bus(4, 400, + board_i2c_ch4, ARRAY_SIZE(board_i2c_ch4)); diff --git a/Documentation/leds/ledtrig-oneshot.txt b/Documentation/leds/ledtrig-oneshot.txt new file mode 100644 index 0000000..07cd1fa --- /dev/null +++ b/Documentation/leds/ledtrig-oneshot.txt @@ -0,0 +1,59 @@ +One-shot LED Trigger +==================== + +This is a LED trigger useful for signaling the user of an event where there are +no clear trap points to put standard led-on and led-off settings. Using this +trigger, the application needs only to signal the trigger when an event has +happened, than the trigger turns the LED on and than keeps it off for a +specified amount of time. + +This trigger is meant to be usable both for sporadic and dense events. In the +first case, the trigger produces a clear single controlled blink for each +event, while in the latter it keeps blinking at constant rate, as to signal +that the events are arriving continuously. + +A one-shot LED only stays in a constant state when there are no events. An +additional "invert" property specifies if the LED has to stay off (normal) or +on (inverted) when not rearmed. + +The trigger can be activated from user space on led class devices as shown +below: + + echo oneshot > trigger + +This adds the following sysfs attributes to the LED: + + delay_on - specifies for how many milliseconds the LED has to stay at + LED_FULL brightness after it has been armed. + Default to 100 ms. + + delay_off - specifies for how many milliseconds the LED has to stay at + LED_OFF brightness after it has been armed. + Default to 100 ms. + + invert - reverse the blink logic. If set to 0 (default) blink on for delay_on + ms, then blink off for delay_off ms, leaving the LED normally off. If + set to 1, blink off for delay_off ms, then blink on for delay_on ms, + leaving the LED normally on. + Setting this value also immediately change the LED state. + + shot - write any non-empty string to signal an events, this starts a blink + sequence if not already running. + +Example use-case: network devices, initialization: + + echo oneshot > trigger # set trigger for this led + echo 33 > delay_on # blink at 1 / (33 + 33) Hz on continuous traffic + echo 33 > delay_off + +interface goes up: + + echo 1 > invert # set led as normally-on, turn the led on + +packet received/transmitted: + + echo 1 > shot # led starts blinking, ignored if already blinking + +interface goes down + + echo 0 > invert # set led as normally-off, turn the led off diff --git a/Documentation/leds/ledtrig-transient.txt b/Documentation/leds/ledtrig-transient.txt new file mode 100644 index 0000000..3bd38b4 --- /dev/null +++ b/Documentation/leds/ledtrig-transient.txt @@ -0,0 +1,152 @@ +LED Transient Trigger +===================== + +The leds timer trigger does not currently have an interface to activate +a one shot timer. The current support allows for setting two timers, one for +specifying how long a state to be on, and the second for how long the state +to be off. The delay_on value specifies the time period an LED should stay +in on state, followed by a delay_off value that specifies how long the LED +should stay in off state. The on and off cycle repeats until the trigger +gets deactivated. There is no provision for one time activation to implement +features that require an on or off state to be held just once and then stay in +the original state forever. + +Without one shot timer interface, user space can still use timer trigger to +set a timer to hold a state, however when user space application crashes or +goes away without deactivating the timer, the hardware will be left in that +state permanently. + +As a specific example of this use-case, let's look at vibrate feature on +phones. Vibrate function on phones is implemented using PWM pins on SoC or +PMIC. There is a need to activate one shot timer to control the vibrate +feature, to prevent user space crashes leaving the phone in vibrate mode +permanently causing the battery to drain. + +Transient trigger addresses the need for one shot timer activation. The +transient trigger can be enabled and disabled just like the other leds +triggers. + +When an led class device driver registers itself, it can specify all leds +triggers it supports and a default trigger. During registration, activation +routine for the default trigger gets called. During registration of an led +class device, the LED state does not change. + +When the driver unregisters, deactivation routine for the currently active +trigger will be called, and LED state is changed to LED_OFF. + +Driver suspend changes the LED state to LED_OFF and resume doesn't change +the state. Please note that there is no explicit interaction between the +suspend and resume actions and the currently enabled trigger. LED state +changes are suspended while the driver is in suspend state. Any timers +that are active at the time driver gets suspended, continue to run, without +being able to actually change the LED state. Once driver is resumed, triggers +start functioning again. + +LED state changes are controlled using brightness which is a common led +class device property. When brightness is set to 0 from user space via +echo 0 > brightness, it will result in deactivating the current trigger. + +Transient trigger uses standard register and unregister interfaces. During +trigger registration, for each led class device that specifies this trigger +as its default trigger, trigger activation routine will get called. During +registration, the LED state does not change, unless there is another trigger +active, in which case LED state changes to LED_OFF. + +During trigger unregistration, LED state gets changed to LED_OFF. + +Transient trigger activation routine doesn't change the LED state. It +creates its properties and does its initialization. Transient trigger +deactivation routine, will cancel any timer that is active before it cleans +up and removes the properties it created. It will restore the LED state to +non-transient state. When driver gets suspended, irrespective of the transient +state, the LED state changes to LED_OFF. + +Transient trigger can be enabled and disabled from user space on led class +devices, that support this trigger as shown below: + +echo transient > trigger +echo none > trigger + +NOTE: Add a new property trigger state to control the state. + +This trigger exports three properties, activate, state, and duration. When +transient trigger is activated these properties are set to default values. + +- duration allows setting timer value in msecs. The initial value is 0. +- activate allows activating and deactivating the timer specified by + duration as needed. The initial and default value is 0. This will allow + duration to be set after trigger activation. +- state allows user to specify a transient state to be held for the specified + duration. + + activate - one shot timer activate mechanism. + 1 when activated, 0 when deactivated. + default value is zero when transient trigger is enabled, + to allow duration to be set. + + activate state indicates a timer with a value of specified + duration running. + deactivated state indicates that there is no active timer + running. + + duration - one shot timer value. When activate is set, duration value + is used to start a timer that runs once. This value doesn't + get changed by the trigger unless user does a set via + echo new_value > duration + + state - transient state to be held. It has two values 0 or 1. 0 maps + to LED_OFF and 1 maps to LED_FULL. The specified state is + held for the duration of the one shot timer and then the + state gets changed to the non-transient state which is the + inverse of transient state. + If state = LED_FULL, when the timer runs out the state will + go back to LED_OFF. + If state = LED_OFF, when the timer runs out the state will + go back to LED_FULL. + Please note that current LED state is not checked prior to + changing the state to the specified state. + Driver could map these values to inverted depending on the + default states it defines for the LED in its brightness_set() + interface which is called from the led brightness_set() + interfaces to control the LED state. + +When timer expires activate goes back to deactivated state, duration is left +at the set value to be used when activate is set at a future time. This will +allow user app to set the time once and activate it to run it once for the +specified value as needed. When timer expires, state is restored to the +non-transient state which is the inverse of the transient state. + + echo 1 > activate - starts timer = duration when duration is not 0. + echo 0 > activate - cancels currently running timer. + echo n > duration - stores timer value to be used upon next + activate. Currently active timer if + any, continues to run for the specified time. + echo 0 > duration - stores timer value to be used upon next + activate. Currently active timer if any, + continues to run for the specified time. + echo 1 > state - stores desired transient state LED_FULL to be + held for the specified duration. + echo 0 > state - stores desired transient state LED_OFF to be + held for the specified duration. + +What is not supported: +====================== +- Timer activation is one shot and extending and/or shortening the timer + is not supported. + +Example use-case 1: + echo transient > trigger + echo n > duration + echo 1 > state +repeat the following step as needed: + echo 1 > activate - start timer = duration to run once + echo 1 > activate - start timer = duration to run once + echo none > trigger + +This trigger is intended to be used for for the following example use cases: + - Control of vibrate (phones, tablets etc.) hardware by user space app. + - Use of LED by user space app as activity indicator. + - Use of LED by user space app as a kind of watchdog indicator -- as + long as the app is alive, it can keep the LED illuminated, if it dies + the LED will be extinguished automatically. + - Use by any user space app that needs a transient GPIO output. diff --git a/Documentation/mca.txt b/Documentation/mca.txt deleted file mode 100644 index dfd130c..0000000 --- a/Documentation/mca.txt +++ /dev/null @@ -1,313 +0,0 @@ -i386 Micro Channel Architecture Support -======================================= - -MCA support is enabled using the CONFIG_MCA define. A machine with a MCA -bus will have the kernel variable MCA_bus set, assuming the BIOS feature -bits are set properly (see arch/i386/boot/setup.S for information on -how this detection is done). - -Adapter Detection -================= - -The ideal MCA adapter detection is done through the use of the -Programmable Option Select registers. Generic functions for doing -this have been added in include/linux/mca.h and arch/x86/kernel/mca_32.c. -Everything needed to detect adapters and read (and write) configuration -information is there. A number of MCA-specific drivers already use -this. The typical probe code looks like the following: - - #include <linux/mca.h> - - unsigned char pos2, pos3, pos4, pos5; - struct net_device* dev; - int slot; - - if( MCA_bus ) { - slot = mca_find_adapter( ADAPTER_ID, 0 ); - if( slot == MCA_NOTFOUND ) { - return -ENODEV; - } - /* optional - see below */ - mca_set_adapter_name( slot, "adapter name & description" ); - mca_set_adapter_procfn( slot, dev_getinfo, dev ); - - /* read the POS registers. Most devices only use 2 and 3 */ - pos2 = mca_read_stored_pos( slot, 2 ); - pos3 = mca_read_stored_pos( slot, 3 ); - pos4 = mca_read_stored_pos( slot, 4 ); - pos5 = mca_read_stored_pos( slot, 5 ); - } else { - return -ENODEV; - } - - /* extract configuration from pos[2345] and set everything up */ - -Loadable modules should modify this to test that the specified IRQ and -IO ports (plus whatever other stuff) match. See 3c523.c for example -code (actually, smc-mca.c has a slightly more complex example that can -handle a list of adapter ids). - -Keep in mind that devices should never directly access the POS registers -(via inb(), outb(), etc). While it's generally safe, there is a small -potential for blowing up hardware when it's done at the wrong time. -Furthermore, accessing a POS register disables a device temporarily. -This is usually okay during startup, but do _you_ want to rely on it? -During initial configuration, mca_init() reads all the POS registers -into memory. mca_read_stored_pos() accesses that data. mca_read_pos() -and mca_write_pos() are also available for (safer) direct POS access, -but their use is _highly_ discouraged. mca_write_pos() is particularly -dangerous, as it is possible for adapters to be put in inconsistent -states (i.e. sharing IO address, etc) and may result in crashes, toasted -hardware, and blindness. - -User level drivers (such as the AGX X server) can use /proc/mca/pos to -find adapters (see below). - -Some MCA adapters can also be detected via the usual ISA-style device -probing (many SCSI adapters, for example). This sort of thing is highly -discouraged. Perfectly good information is available telling you what's -there, so there's no excuse for messing with random IO ports. However, -we MCA people still appreciate any ISA-style driver that will work with -our hardware. You take what you can get... - -Level-Triggered Interrupts -========================== - -Because MCA uses level-triggered interrupts, a few problems arise with -what might best be described as the ISA mindset and its effects on -drivers. These sorts of problems are expected to become less common as -more people use shared IRQs on PCI machines. - -In general, an interrupt must be acknowledged not only at the ICU (which -is done automagically by the kernel), but at the device level. In -particular, IRQ 0 must be reset after a timer interrupt (now done in -arch/x86/kernel/time.c) or the first timer interrupt hangs the system. -There were also problems with the 1.3.x floppy drivers, but that seems -to have been fixed. - -IRQs are also shareable, and most MCA-specific devices should be coded -with shared IRQs in mind. - -/proc/mca -========= - -/proc/mca is a directory containing various files for adapters and -other stuff. - - /proc/mca/pos Straight listing of POS registers - /proc/mca/slot[1-8] Information on adapter in specific slot - /proc/mca/video Same for integrated video - /proc/mca/scsi Same for integrated SCSI - /proc/mca/machine Machine information - -See Appendix A for a sample. - -Device drivers can easily add their own information function for -specific slots (including integrated ones) via the -mca_set_adapter_procfn() call. Drivers that support this are ESDI, IBM -SCSI, and 3c523. If a device is also a module, make sure that the proc -function is removed in the module cleanup. This will require storing -the slot information in a private structure somewhere. See the 3c523 -driver for details. - -Your typical proc function will look something like this: - - static int - dev_getinfo( char* buf, int slot, void* d ) { - struct net_device* dev = (struct net_device*) d; - int len = 0; - - len += sprintf( buf+len, "Device: %s\n", dev->name ); - len += sprintf( buf+len, "IRQ: %d\n", dev->irq ); - len += sprintf( buf+len, "IO Port: %#lx-%#lx\n", ... ); - ... - - return len; - } - -Some of the standard MCA information will already be printed, so don't -bother repeating it. Don't try putting in more than 3K of information. - -Enable this function with: - mca_set_adapter_procfn( slot, dev_getinfo, dev ); - -Disable it with: - mca_set_adapter_procfn( slot, NULL, NULL ); - -It is also recommended that, even if you don't write a proc function, to -set the name of the adapter (i.e. "PS/2 ESDI Controller") via -mca_set_adapter_name( int slot, char* name ). - -MCA Device Drivers -================== - -Currently, there are a number of MCA-specific device drivers. - -1) PS/2 SCSI - drivers/scsi/ibmmca.c - drivers/scsi/ibmmca.h - The driver for the IBM SCSI subsystem. Includes both integrated - controllers and adapter cards. May require command-line arg - "ibmmcascsi=io_port" to force detection of an adapter. If you have a - machine with a front-panel display (i.e. model 95), you can use - "ibmmcascsi=display" to enable a drive activity indicator. - -2) 3c523 - drivers/net/3c523.c - drivers/net/3c523.h - 3Com 3c523 Etherlink/MC ethernet driver. - -3) SMC Ultra/MCA and IBM Adapter/A - drivers/net/smc-mca.c - drivers/net/smc-mca.h - Driver for the MCA version of the SMC Ultra and various other - OEM'ed and work-alike cards (Elite, Adapter/A, etc). - -4) NE/2 - driver/net/ne2.c - driver/net/ne2.h - The NE/2 is the MCA version of the NE2000. This may not work - with clones that have a different adapter id than the original - NE/2. - -5) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Adapter/A and - Reply Sound Blaster/SCSI (SCSI part) - Better support for these cards than the driver for ISA. - Supports multiple cards with IRQ sharing. - -Also added boot time option of scsi-probe, which can do reordering of -SCSI host adapters. This will direct the kernel on the order which -SCSI adapter should be detected. Example: - scsi-probe=ibmmca,fd_mcs,adaptec1542,buslogic - -The serial drivers were modified to support the extended IO port range -of the typical MCA system (also #ifdef CONFIG_MCA). - -The following devices work with existing drivers: -1) Token-ring -2) Future Domain SCSI (MCS-600, MCS-700, not MCS-350, OEM'ed IBM SCSI) -3) Adaptec 1640 SCSI (using the aha1542 driver) -4) Bustek/Buslogic SCSI (various) -5) Probably all Arcnet cards. -6) Some, possibly all, MCA IDE controllers. -7) 3Com 3c529 (MCA version of 3c509) (patched) - -8) Intel EtherExpressMC (patched version) - You need to have CONFIG_MCA defined to have EtherExpressMC support. -9) Reply Sound Blaster/SCSI (SB part) (patched version) - -Bugs & Other Weirdness -====================== - -NMIs tend to occur with MCA machines because of various hardware -weirdness, bus timeouts, and many other non-critical things. Some basic -code to handle them (inspired by the NetBSD MCA code) has been added to -detect the guilty device, but it's pretty incomplete. If NMIs are a -persistent problem (on some model 70 or 80s, they occur every couple -shell commands), the CONFIG_IGNORE_NMI flag will take care of that. - -Various Pentium machines have had serious problems with the FPU test in -bugs.h. Basically, the machine hangs after the HLT test. This occurs, -as far as we know, on the Pentium-equipped 85s, 95s, and some PC Servers. -The PCI/MCA PC 750s are fine as far as I can tell. The ``mca-pentium'' -boot-prompt flag will disable the FPU bug check if this is a problem -with your machine. - -The model 80 has a raft of problems that are just too weird and unique -to get into here. Some people have no trouble while others have nothing -but problems. I'd suspect some problems are related to the age of the -average 80 and accompanying hardware deterioration, although others -are definitely design problems with the hardware. Among the problems -include SCSI controller problems, ESDI controller problems, and serious -screw-ups in the floppy controller. Oh, and the parallel port is also -pretty flaky. There were about 5 or 6 different model 80 motherboards -produced to fix various obscure problems. As far as I know, it's pretty -much impossible to tell which bugs a particular model 80 has (other than -triggering them, that is). - -Drivers are required for some MCA memory adapters. If you're suddenly -short a few megs of RAM, this might be the reason. The (I think) Enhanced -Memory Adapter commonly found on the model 70 is one. There's a very -alpha driver floating around, but it's pretty ugly (disassembled from -the DOS driver, actually). See the MCA Linux web page (URL below) -for more current memory info. - -The Thinkpad 700 and 720 will work, but various components are either -non-functional, flaky, or we don't know anything about them. The -graphics controller is supposed to be some WD, but we can't get things -working properly. The PCMCIA slots don't seem to work. Ditto for APM. -The serial ports work, but detection seems to be flaky. - -Credits -======= -A whole pile of people have contributed to the MCA code. I'd include -their names here, but I don't have a list handy. Check the MCA Linux -home page (URL below) for a perpetually out-of-date list. - -===================================================================== -MCA Linux Home Page: http://www.dgmicro.com/mca/ - -Christophe Beauregard -chrisb@truespectra.com -cpbeaure@calum.csclub.uwaterloo.ca - -===================================================================== -Appendix A: Sample /proc/mca - -This is from my model 8595. Slot 1 contains the standard IBM SCSI -adapter, slot 3 is an Adaptec AHA-1640, slot 5 is a XGA-1 video adapter, -and slot 7 is the 3c523 Etherlink/MC. - -/proc/mca/machine: -Model Id: 0xf8 -Submodel Id: 0x14 -BIOS Revision: 0x5 - -/proc/mca/pos: -Slot 1: ff 8e f1 fc a0 ff ff ff IBM SCSI Adapter w/Cache -Slot 2: ff ff ff ff ff ff ff ff -Slot 3: 1f 0f 81 3b bf b6 ff ff -Slot 4: ff ff ff ff ff ff ff ff -Slot 5: db 8f 1d 5e fd c0 00 00 -Slot 6: ff ff ff ff ff ff ff ff -Slot 7: 42 60 ff 08 ff ff ff ff 3Com 3c523 Etherlink/MC -Slot 8: ff ff ff ff ff ff ff ff -Video : ff ff ff ff ff ff ff ff -SCSI : ff ff ff ff ff ff ff ff - -/proc/mca/slot1: -Slot: 1 -Adapter Name: IBM SCSI Adapter w/Cache -Id: 8eff -Enabled: Yes -POS: ff 8e f1 fc a0 ff ff ff -Subsystem PUN: 7 -Detected at boot: Yes - -/proc/mca/slot3: -Slot: 3 -Adapter Name: Unknown -Id: 0f1f -Enabled: Yes -POS: 1f 0f 81 3b bf b6 ff ff - -/proc/mca/slot5: -Slot: 5 -Adapter Name: Unknown -Id: 8fdb -Enabled: Yes -POS: db 8f 1d 5e fd c0 00 00 - -/proc/mca/slot7: -Slot: 7 -Adapter Name: 3Com 3c523 Etherlink/MC -Id: 6042 -Enabled: Yes -POS: 42 60 ff 08 ff ff ff ff -Revision: 0xe -IRQ: 9 -IO Address: 0x3300-0x3308 -Memory: 0xd8000-0xdbfff -Transceiver: External -Device: eth0 -Hardware Address: 02 60 8c 45 c4 2a diff --git a/Documentation/memory-devices/ti-emif.txt b/Documentation/memory-devices/ti-emif.txt new file mode 100644 index 0000000..f4ad9a7 --- /dev/null +++ b/Documentation/memory-devices/ti-emif.txt @@ -0,0 +1,57 @@ +TI EMIF SDRAM Controller Driver: + +Author +======== +Aneesh V <aneesh@ti.com> + +Location +============ +driver/memory/emif.c + +Supported SoCs: +=================== +TI OMAP44xx +TI OMAP54xx + +Menuconfig option: +========================== +Device Drivers + Memory devices + Texas Instruments EMIF driver + +Description +=========== +This driver is for the EMIF module available in Texas Instruments +SoCs. EMIF is an SDRAM controller that, based on its revision, +supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols. +This driver takes care of only LPDDR2 memories presently. The +functions of the driver includes re-configuring AC timing +parameters and other settings during frequency, voltage and +temperature changes + +Platform Data (see include/linux/platform_data/emif_plat.h): +===================================================================== +DDR device details and other board dependent and SoC dependent +information can be passed through platform data (struct emif_platform_data) +- DDR device details: 'struct ddr_device_info' +- Device AC timings: 'struct lpddr2_timings' and 'struct lpddr2_min_tck' +- Custom configurations: customizable policy options through + 'struct emif_custom_configs' +- IP revision +- PHY type + +Interface to the external world: +================================ +EMIF driver registers notifiers for voltage and frequency changes +affecting EMIF and takes appropriate actions when these are invoked. +- freq_pre_notify_handling() +- freq_post_notify_handling() +- volt_notify_handling() + +Debugfs +======== +The driver creates two debugfs entries per device. +- regcache_dump : dump of register values calculated and saved for all + frequencies used so far. +- mr4 : last polled value of MR4 register in the LPDDR2 device. MR4 + indicates the current temperature level of the device. diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index 8f485d7..6d0c251 100644 --- a/Documentation/memory-hotplug.txt +++ b/Documentation/memory-hotplug.txt @@ -341,7 +341,7 @@ Need more implementation yet.... -------------------------------- 8. Memory hotplug event notifier -------------------------------- -Memory hotplug has event notifer. There are 6 types of notification. +Memory hotplug has event notifier. There are 6 types of notification. MEMORY_GOING_ONLINE Generated before new memory becomes available in order to be able to diff --git a/Documentation/misc-devices/mei/.gitignore b/Documentation/misc-devices/mei/.gitignore new file mode 100644 index 0000000..f356b81 --- /dev/null +++ b/Documentation/misc-devices/mei/.gitignore @@ -0,0 +1 @@ +mei-amt-version diff --git a/Documentation/misc-devices/mei/Makefile b/Documentation/misc-devices/mei/Makefile new file mode 100644 index 0000000..00e8c3e --- /dev/null +++ b/Documentation/misc-devices/mei/Makefile @@ -0,0 +1,8 @@ +# kbuild trick to avoid linker error. Can be omitted if a module is built. +obj- := dummy.o + +# List of programs to build +hostprogs-y := mei-amt-version +HOSTCFLAGS_mei-amt-version.o += -I$(objtree)/usr/include +# Tell kbuild to always build the programs +always := $(hostprogs-y) diff --git a/Documentation/misc-devices/mei/TODO b/Documentation/misc-devices/mei/TODO new file mode 100644 index 0000000..6b3625d --- /dev/null +++ b/Documentation/misc-devices/mei/TODO @@ -0,0 +1,2 @@ +TODO: + - Cleanup and split the timer function diff --git a/Documentation/misc-devices/mei/mei-amt-version.c b/Documentation/misc-devices/mei/mei-amt-version.c new file mode 100644 index 0000000..01804f2 --- /dev/null +++ b/Documentation/misc-devices/mei/mei-amt-version.c @@ -0,0 +1,481 @@ +/****************************************************************************** + * Intel Management Engine Interface (Intel MEI) Linux driver + * Intel MEI Interface Header + * + * This file is provided under a dual BSD/GPLv2 license. When using or + * redistributing this file, you may do so under either license. + * + * GPL LICENSE SUMMARY + * + * Copyright(c) 2012 Intel Corporation. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + * + * 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., 51 Franklin Street, Fifth Floor, Boston, MA 02110, + * USA + * + * The full GNU General Public License is included in this distribution + * in the file called LICENSE.GPL. + * + * Contact Information: + * Intel Corporation. + * linux-mei@linux.intel.com + * http://www.intel.com + * + * BSD LICENSE + * + * Copyright(c) 2003 - 2012 Intel Corporation. All rights reserved. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name Intel Corporation nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + *****************************************************************************/ + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <fcntl.h> +#include <sys/ioctl.h> +#include <unistd.h> +#include <errno.h> +#include <stdint.h> +#include <stdbool.h> +#include <bits/wordsize.h> +#include <linux/mei.h> + +/***************************************************************************** + * Intel Management Engine Interface + *****************************************************************************/ + +#define mei_msg(_me, fmt, ARGS...) do { \ + if (_me->verbose) \ + fprintf(stderr, fmt, ##ARGS); \ +} while (0) + +#define mei_err(_me, fmt, ARGS...) do { \ + fprintf(stderr, "Error: " fmt, ##ARGS); \ +} while (0) + +struct mei { + uuid_le guid; + bool initialized; + bool verbose; + unsigned int buf_size; + unsigned char prot_ver; + int fd; +}; + +static void mei_deinit(struct mei *cl) +{ + if (cl->fd != -1) + close(cl->fd); + cl->fd = -1; + cl->buf_size = 0; + cl->prot_ver = 0; + cl->initialized = false; +} + +static bool mei_init(struct mei *me, const uuid_le *guid, + unsigned char req_protocol_version, bool verbose) +{ + int result; + struct mei_client *cl; + struct mei_connect_client_data data; + + mei_deinit(me); + + me->verbose = verbose; + + me->fd = open("/dev/mei", O_RDWR); + if (me->fd == -1) { + mei_err(me, "Cannot establish a handle to the Intel MEI driver\n"); + goto err; + } + memcpy(&me->guid, guid, sizeof(*guid)); + memset(&data, 0, sizeof(data)); + me->initialized = true; + + memcpy(&data.in_client_uuid, &me->guid, sizeof(me->guid)); + result = ioctl(me->fd, IOCTL_MEI_CONNECT_CLIENT, &data); + if (result) { + mei_err(me, "IOCTL_MEI_CONNECT_CLIENT receive message. err=%d\n", result); + goto err; + } + cl = &data.out_client_properties; + mei_msg(me, "max_message_length %d\n", cl->max_msg_length); + mei_msg(me, "protocol_version %d\n", cl->protocol_version); + + if ((req_protocol_version > 0) && + (cl->protocol_version != req_protocol_version)) { + mei_err(me, "Intel MEI protocol version not supported\n"); + goto err; + } + + me->buf_size = cl->max_msg_length; + me->prot_ver = cl->protocol_version; + + return true; +err: + mei_deinit(me); + return false; +} + +static ssize_t mei_recv_msg(struct mei *me, unsigned char *buffer, + ssize_t len, unsigned long timeout) +{ + ssize_t rc; + + mei_msg(me, "call read length = %zd\n", len); + + rc = read(me->fd, buffer, len); + if (rc < 0) { + mei_err(me, "read failed with status %zd %s\n", + rc, strerror(errno)); + mei_deinit(me); + } else { + mei_msg(me, "read succeeded with result %zd\n", rc); + } + return rc; +} + +static ssize_t mei_send_msg(struct mei *me, const unsigned char *buffer, + ssize_t len, unsigned long timeout) +{ + struct timeval tv; + ssize_t written; + ssize_t rc; + fd_set set; + + tv.tv_sec = timeout / 1000; + tv.tv_usec = (timeout % 1000) * 1000000; + + mei_msg(me, "call write length = %zd\n", len); + + written = write(me->fd, buffer, len); + if (written < 0) { + rc = -errno; + mei_err(me, "write failed with status %zd %s\n", + written, strerror(errno)); + goto out; + } + + FD_ZERO(&set); + FD_SET(me->fd, &set); + rc = select(me->fd + 1 , &set, NULL, NULL, &tv); + if (rc > 0 && FD_ISSET(me->fd, &set)) { + mei_msg(me, "write success\n"); + } else if (rc == 0) { + mei_err(me, "write failed on timeout with status\n"); + goto out; + } else { /* rc < 0 */ + mei_err(me, "write failed on select with status %zd\n", rc); + goto out; + } + + rc = written; +out: + if (rc < 0) + mei_deinit(me); + + return rc; +} + +/*************************************************************************** + * Intel Advanced Management Technolgy ME Client + ***************************************************************************/ + +#define AMT_MAJOR_VERSION 1 +#define AMT_MINOR_VERSION 1 + +#define AMT_STATUS_SUCCESS 0x0 +#define AMT_STATUS_INTERNAL_ERROR 0x1 +#define AMT_STATUS_NOT_READY 0x2 +#define AMT_STATUS_INVALID_AMT_MODE 0x3 +#define AMT_STATUS_INVALID_MESSAGE_LENGTH 0x4 + +#define AMT_STATUS_HOST_IF_EMPTY_RESPONSE 0x4000 +#define AMT_STATUS_SDK_RESOURCES 0x1004 + + +#define AMT_BIOS_VERSION_LEN 65 +#define AMT_VERSIONS_NUMBER 50 +#define AMT_UNICODE_STRING_LEN 20 + +struct amt_unicode_string { + uint16_t length; + char string[AMT_UNICODE_STRING_LEN]; +} __attribute__((packed)); + +struct amt_version_type { + struct amt_unicode_string description; + struct amt_unicode_string version; +} __attribute__((packed)); + +struct amt_version { + uint8_t major; + uint8_t minor; +} __attribute__((packed)); + +struct amt_code_versions { + uint8_t bios[AMT_BIOS_VERSION_LEN]; + uint32_t count; + struct amt_version_type versions[AMT_VERSIONS_NUMBER]; +} __attribute__((packed)); + +/*************************************************************************** + * Intel Advanced Management Technolgy Host Interface + ***************************************************************************/ + +struct amt_host_if_msg_header { + struct amt_version version; + uint16_t _reserved; + uint32_t command; + uint32_t length; +} __attribute__((packed)); + +struct amt_host_if_resp_header { + struct amt_host_if_msg_header header; + uint32_t status; + unsigned char data[0]; +} __attribute__((packed)); + +const uuid_le MEI_IAMTHIF = UUID_LE(0x12f80028, 0xb4b7, 0x4b2d, \ + 0xac, 0xa8, 0x46, 0xe0, 0xff, 0x65, 0x81, 0x4c); + +#define AMT_HOST_IF_CODE_VERSIONS_REQUEST 0x0400001A +#define AMT_HOST_IF_CODE_VERSIONS_RESPONSE 0x0480001A + +const struct amt_host_if_msg_header CODE_VERSION_REQ = { + .version = {AMT_MAJOR_VERSION, AMT_MINOR_VERSION}, + ._reserved = 0, + .command = AMT_HOST_IF_CODE_VERSIONS_REQUEST, + .length = 0 +}; + + +struct amt_host_if { + struct mei mei_cl; + unsigned long send_timeout; + bool initialized; +}; + + +static bool amt_host_if_init(struct amt_host_if *acmd, + unsigned long send_timeout, bool verbose) +{ + acmd->send_timeout = (send_timeout) ? send_timeout : 20000; + acmd->initialized = mei_init(&acmd->mei_cl, &MEI_IAMTHIF, 0, verbose); + return acmd->initialized; +} + +static void amt_host_if_deinit(struct amt_host_if *acmd) +{ + mei_deinit(&acmd->mei_cl); + acmd->initialized = false; +} + +static uint32_t amt_verify_code_versions(const struct amt_host_if_resp_header *resp) +{ + uint32_t status = AMT_STATUS_SUCCESS; + struct amt_code_versions *code_ver; + size_t code_ver_len; + uint32_t ver_type_cnt; + uint32_t len; + uint32_t i; + + code_ver = (struct amt_code_versions *)resp->data; + /* length - sizeof(status) */ + code_ver_len = resp->header.length - sizeof(uint32_t); + ver_type_cnt = code_ver_len - + sizeof(code_ver->bios) - + sizeof(code_ver->count); + if (code_ver->count != ver_type_cnt / sizeof(struct amt_version_type)) { + status = AMT_STATUS_INTERNAL_ERROR; + goto out; + } + + for (i = 0; i < code_ver->count; i++) { + len = code_ver->versions[i].description.length; + + if (len > AMT_UNICODE_STRING_LEN) { + status = AMT_STATUS_INTERNAL_ERROR; + goto out; + } + + len = code_ver->versions[i].version.length; + if (code_ver->versions[i].version.string[len] != '\0' || + len != strlen(code_ver->versions[i].version.string)) { + status = AMT_STATUS_INTERNAL_ERROR; + goto out; + } + } +out: + return status; +} + +static uint32_t amt_verify_response_header(uint32_t command, + const struct amt_host_if_msg_header *resp_hdr, + uint32_t response_size) +{ + if (response_size < sizeof(struct amt_host_if_resp_header)) { + return AMT_STATUS_INTERNAL_ERROR; + } else if (response_size != (resp_hdr->length + + sizeof(struct amt_host_if_msg_header))) { + return AMT_STATUS_INTERNAL_ERROR; + } else if (resp_hdr->command != command) { + return AMT_STATUS_INTERNAL_ERROR; + } else if (resp_hdr->_reserved != 0) { + return AMT_STATUS_INTERNAL_ERROR; + } else if (resp_hdr->version.major != AMT_MAJOR_VERSION || + resp_hdr->version.minor < AMT_MINOR_VERSION) { + return AMT_STATUS_INTERNAL_ERROR; + } + return AMT_STATUS_SUCCESS; +} + +static uint32_t amt_host_if_call(struct amt_host_if *acmd, + const unsigned char *command, ssize_t command_sz, + uint8_t **read_buf, uint32_t rcmd, + unsigned int expected_sz) +{ + uint32_t in_buf_sz; + uint32_t out_buf_sz; + ssize_t written; + uint32_t status; + struct amt_host_if_resp_header *msg_hdr; + + in_buf_sz = acmd->mei_cl.buf_size; + *read_buf = (uint8_t *)malloc(sizeof(uint8_t) * in_buf_sz); + if (*read_buf == NULL) + return AMT_STATUS_SDK_RESOURCES; + memset(*read_buf, 0, in_buf_sz); + msg_hdr = (struct amt_host_if_resp_header *)*read_buf; + + written = mei_send_msg(&acmd->mei_cl, + command, command_sz, acmd->send_timeout); + if (written != command_sz) + return AMT_STATUS_INTERNAL_ERROR; + + out_buf_sz = mei_recv_msg(&acmd->mei_cl, *read_buf, in_buf_sz, 2000); + if (out_buf_sz <= 0) + return AMT_STATUS_HOST_IF_EMPTY_RESPONSE; + + status = msg_hdr->status; + if (status != AMT_STATUS_SUCCESS) + return status; + + status = amt_verify_response_header(rcmd, + &msg_hdr->header, out_buf_sz); + if (status != AMT_STATUS_SUCCESS) + return status; + + if (expected_sz && expected_sz != out_buf_sz) + return AMT_STATUS_INTERNAL_ERROR; + + return AMT_STATUS_SUCCESS; +} + + +static uint32_t amt_get_code_versions(struct amt_host_if *cmd, + struct amt_code_versions *versions) +{ + struct amt_host_if_resp_header *response = NULL; + uint32_t status; + + status = amt_host_if_call(cmd, + (const unsigned char *)&CODE_VERSION_REQ, + sizeof(CODE_VERSION_REQ), + (uint8_t **)&response, + AMT_HOST_IF_CODE_VERSIONS_RESPONSE, 0); + + if (status != AMT_STATUS_SUCCESS) + goto out; + + status = amt_verify_code_versions(response); + if (status != AMT_STATUS_SUCCESS) + goto out; + + memcpy(versions, response->data, sizeof(struct amt_code_versions)); +out: + if (response != NULL) + free(response); + + return status; +} + +/************************** end of amt_host_if_command ***********************/ +int main(int argc, char **argv) +{ + struct amt_code_versions ver; + struct amt_host_if acmd; + unsigned int i; + uint32_t status; + int ret; + bool verbose; + + verbose = (argc > 1 && strcmp(argv[1], "-v") == 0); + + if (!amt_host_if_init(&acmd, 5000, verbose)) { + ret = 1; + goto out; + } + + status = amt_get_code_versions(&acmd, &ver); + + amt_host_if_deinit(&acmd); + + switch (status) { + case AMT_STATUS_HOST_IF_EMPTY_RESPONSE: + printf("Intel AMT: DISABLED\n"); + ret = 0; + break; + case AMT_STATUS_SUCCESS: + printf("Intel AMT: ENABLED\n"); + for (i = 0; i < ver.count; i++) { + printf("%s:\t%s\n", ver.versions[i].description.string, + ver.versions[i].version.string); + } + ret = 0; + break; + default: + printf("An error has occurred\n"); + ret = 1; + break; + } + +out: + return ret; +} diff --git a/Documentation/misc-devices/mei/mei.txt b/Documentation/misc-devices/mei/mei.txt new file mode 100644 index 0000000..6ec7029 --- /dev/null +++ b/Documentation/misc-devices/mei/mei.txt @@ -0,0 +1,215 @@ +Intel(R) Management Engine Interface (Intel(R) MEI) +======================= + +Introduction +======================= + +The Intel Management Engine (Intel ME) is an isolated and protected computing +resource (Co-processor) residing inside certain Intel chipsets. The Intel ME +provides support for computer/IT management features. The feature set +depends on the Intel chipset SKU. + +The Intel Management Engine Interface (Intel MEI, previously known as HECI) +is the interface between the Host and Intel ME. This interface is exposed +to the host as a PCI device. The Intel MEI Driver is in charge of the +communication channel between a host application and the Intel ME feature. + +Each Intel ME feature (Intel ME Client) is addressed by a GUID/UUID and +each client has its own protocol. The protocol is message-based with a +header and payload up to 512 bytes. + +Prominent usage of the Intel ME Interface is to communicate with Intel(R) +Active Management Technology (Intel AMT)implemented in firmware running on +the Intel ME. + +Intel AMT provides the ability to manage a host remotely out-of-band (OOB) +even when the operating system running on the host processor has crashed or +is in a sleep state. + +Some examples of Intel AMT usage are: + - Monitoring hardware state and platform components + - Remote power off/on (useful for green computing or overnight IT + maintenance) + - OS updates + - Storage of useful platform information such as software assets + - Built-in hardware KVM + - Selective network isolation of Ethernet and IP protocol flows based + on policies set by a remote management console + - IDE device redirection from remote management console + +Intel AMT (OOB) communication is based on SOAP (deprecated +starting with Release 6.0) over HTTP/S or WS-Management protocol over +HTTP/S that are received from a remote management console application. + +For more information about Intel AMT: +http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + +Intel MEI Driver +======================= + +The driver exposes a misc device called /dev/mei. + +An application maintains communication with an Intel ME feature while +/dev/mei is open. The binding to a specific feature is performed by calling +MEI_CONNECT_CLIENT_IOCTL, which passes the desired UUID. +The number of instances of an Intel ME feature that can be opened +at the same time depends on the Intel ME feature, but most of the +features allow only a single instance. + +The Intel AMT Host Interface (Intel AMTHI) feature supports multiple +simultaneous user connected applications. The Intel MEI driver +handles this internally by maintaining request queues for the applications. + +The driver is transparent to data that are passed between firmware feature +and host application. + +Because some of the Intel ME features can change the system +configuration, the driver by default allows only a privileged +user to access it. + +A code snippet for an application communicating with Intel AMTHI client: + + struct mei_connect_client_data data; + fd = open(MEI_DEVICE); + + data.d.in_client_uuid = AMTHI_UUID; + + ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &data); + + printf("Ver=%d, MaxLen=%ld\n", + data.d.in_client_uuid.protocol_version, + data.d.in_client_uuid.max_msg_length); + + [...] + + write(fd, amthi_req_data, amthi_req_data_len); + + [...] + + read(fd, &amthi_res_data, amthi_res_data_len); + + [...] + close(fd); + +IOCTL: +====== +The Intel MEI Driver supports the following IOCTL command: + IOCTL_MEI_CONNECT_CLIENT Connect to firmware Feature (client). + + usage: + struct mei_connect_client_data clientData; + ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &clientData); + + inputs: + mei_connect_client_data struct contain the following + input field: + + in_client_uuid - UUID of the FW Feature that needs + to connect to. + outputs: + out_client_properties - Client Properties: MTU and Protocol Version. + + error returns: + EINVAL Wrong IOCTL Number + ENODEV Device or Connection is not initialized or ready. + (e.g. Wrong UUID) + ENOMEM Unable to allocate memory to client internal data. + EFAULT Fatal Error (e.g. Unable to access user input data) + EBUSY Connection Already Open + + Notes: + max_msg_length (MTU) in client properties describes the maximum + data that can be sent or received. (e.g. if MTU=2K, can send + requests up to bytes 2k and received responses upto 2k bytes). + +Intel ME Applications: +============== + +1) Intel Local Management Service (Intel LMS) + + Applications running locally on the platform communicate with Intel AMT Release + 2.0 and later releases in the same way that network applications do via SOAP + over HTTP (deprecated starting with Release 6.0) or with WS-Management over + SOAP over HTTP. This means that some Intel AMT features can be accessed from a + local application using the same network interface as a remote application + communicating with Intel AMT over the network. + + When a local application sends a message addressed to the local Intel AMT host + name, the Intel LMS, which listens for traffic directed to the host name, + intercepts the message and routes it to the Intel MEI. + For more information: + http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + Under "About Intel AMT" => "Local Access" + + For downloading Intel LMS: + http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ + + The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS + firmware feature using a defined UUID and then communicates with the feature + using a protocol called Intel AMT Port Forwarding Protocol(Intel APF protocol). + The protocol is used to maintain multiple sessions with Intel AMT from a + single application. + + See the protocol specification in the Intel AMT Software Development Kit(SDK) + http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + Under "SDK Resources" => "Intel(R) vPro(TM) Gateway(MPS)" + => "Information for Intel(R) vPro(TM) Gateway Developers" + => "Description of the Intel AMT Port Forwarding (APF)Protocol" + + 2) Intel AMT Remote configuration using a Local Agent + A Local Agent enables IT personnel to configure Intel AMT out-of-the-box + without requiring installing additional data to enable setup. The remote + configuration process may involve an ISV-developed remote configuration + agent that runs on the host. + For more information: + http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + Under "Setup and Configuration of Intel AMT" => + "SDK Tools Supporting Setup and Configuration" => + "Using the Local Agent Sample" + + An open source Intel AMT configuration utility, implementing a local agent + that accesses the Intel MEI driver, can be found here: + http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ + + +Intel AMT OS Health Watchdog: +============================= +The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog. +Whenever the OS hangs or crashes, Intel AMT will send an event +to any subscriber to this event. This mechanism means that +IT knows when a platform crashes even when there is a hard failure on the host. + +The Intel AMT Watchdog is composed of two parts: + 1) Firmware feature - receives the heartbeats + and sends an event when the heartbeats stop. + 2) Intel MEI driver - connects to the watchdog feature, configures the + watchdog and sends the heartbeats. + +The Intel MEI driver uses the kernel watchdog API to configure the Intel AMT +Watchdog and to send heartbeats to it. The default timeout of the +watchdog is 120 seconds. + +If the Intel AMT Watchdog feature does not exist (i.e. the connection failed), +the Intel MEI driver will disable the sending of heartbeats. + +Supported Chipsets: +================== +7 Series Chipset Family +6 Series Chipset Family +5 Series Chipset Family +4 Series Chipset Family +Mobile 4 Series Chipset Family +ICH9 +82946GZ/GL +82G35 Express +82Q963/Q965 +82P965/G965 +Mobile PM965/GM965 +Mobile GME965/GLE960 +82Q35 Express +82G33/G31/P35/P31 Express +82Q33 Express +82X38/X48 Express + +--- +linux-mei@linux.intel.com diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 9ad9dde..2cc3c77 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -1,7 +1,5 @@ 00-INDEX - this file -3c359.txt - - information on the 3Com TokenLink Velocity XL (3c5359) driver. 3c505.txt - information on the 3Com EtherLink Plus (3c505) driver. 3c509.txt @@ -142,8 +140,6 @@ netif-msg.txt - Design of the network interface message level setting (NETIF_MSG_*). nfc.txt - The Linux Near Field Communication (NFS) subsystem. -olympic.txt - - IBM PCI Pit/Pit-Phy/Olympic Token Ring driver info. openvswitch.txt - Open vSwitch developer documentation. operstates.txt @@ -184,8 +180,6 @@ skfp.txt - SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info. smc9.txt - the driver for SMC's 9000 series of Ethernet cards -smctr.txt - - SMC TokenCard TokenRing Linux driver info. spider-net.txt - README for the Spidernet Driver (as found in PS3 / Cell BE). stmmac.txt @@ -200,8 +194,6 @@ tcp-thin.txt - kernel tuning options for low rate 'thin' TCP streams. tlan.txt - ThunderLAN (Compaq Netelligent 10/100, Olicom OC-2xxx) driver info. -tms380tr.txt - - SysKonnect Token Ring ISA/PCI adapter driver info. tproxy.txt - Transparent proxy support user guide. tuntap.txt diff --git a/Documentation/networking/3c359.txt b/Documentation/networking/3c359.txt deleted file mode 100644 index dadfe81..0000000 --- a/Documentation/networking/3c359.txt +++ /dev/null @@ -1,58 +0,0 @@ - -3COM PCI TOKEN LINK VELOCITY XL TOKEN RING CARDS README - -Release 0.9.0 - Release - Jul 17th 2000 Mike Phillips - - 1.2.0 - Final - Feb 17th 2002 Mike Phillips - Updated for submission to the 2.4.x kernel. - -Thanks: - Terry Murphy from 3Com for tech docs and support, - Adam D. Ligas for testing the driver. - -Note: - This driver will NOT work with the 3C339 Token Ring cards, you need -to use the tms380 driver instead. - -Options: - -The driver accepts three options: ringspeed, pkt_buf_sz and message_level. - -These options can be specified differently for each card found. - -ringspeed: Has one of three settings 0 (default), 4 or 16. 0 will -make the card autosense the ringspeed and join at the appropriate speed, -this will be the default option for most people. 4 or 16 allow you to -explicitly force the card to operate at a certain speed. The card will fail -if you try to insert it at the wrong speed. (Although some hubs will allow -this so be *very* careful). The main purpose for explicitly setting the ring -speed is for when the card is first on the ring. In autosense mode, if the card -cannot detect any active monitors on the ring it will open at the same speed as -its last opening. This can be hazardous if this speed does not match the speed -you want the ring to operate at. - -pkt_buf_sz: This is this initial receive buffer allocation size. This will -default to 4096 if no value is entered. You may increase performance of the -driver by setting this to a value larger than the network packet size, although -the driver now re-sizes buffers based on MTU settings as well. - -message_level: Controls level of messages created by the driver. Defaults to 0: -which only displays start-up and critical messages. Presently any non-zero -value will display all soft messages as well. NB This does not turn -debugging messages on, that must be done by modified the source code. - -Variable MTU size: - -The driver can handle a MTU size up to either 4500 or 18000 depending upon -ring speed. The driver also changes the size of the receive buffers as part -of the mtu re-sizing, so if you set mtu = 18000, you will need to be able -to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring -position = 296,000 bytes of memory space, plus of course anything -necessary for the tx sk_buff's. Remember this is per card, so if you are -building routers, gateway's etc, you could start to use a lot of memory -real fast. - -2/17/02 Mike Phillips - diff --git a/Documentation/networking/3c509.txt b/Documentation/networking/3c509.txt index dcc9eaf..fbf722e 100644 --- a/Documentation/networking/3c509.txt +++ b/Documentation/networking/3c509.txt @@ -25,7 +25,6 @@ models: 3c509B (later revision of the ISA card; supports full-duplex) 3c589 (PCMCIA) 3c589B (later revision of the 3c589; supports full-duplex) - 3c529 (MCA) 3c579 (EISA) Large portions of this documentation were heavily borrowed from the guide diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt index 221ad0c..8f3ae4a 100644 --- a/Documentation/networking/batman-adv.txt +++ b/Documentation/networking/batman-adv.txt @@ -1,5 +1,3 @@ -[state: 21-08-2011] - BATMAN-ADV ---------- @@ -67,18 +65,19 @@ To deactivate an interface you have to write "none" into its All mesh wide settings can be found in batman's own interface folder: -# ls /sys/class/net/bat0/mesh/ -# aggregated_ogms fragmentation gw_sel_class vis_mode -# ap_isolation gw_bandwidth hop_penalty -# bonding gw_mode orig_interval +# ls /sys/class/net/bat0/mesh/ +# aggregated_ogms gw_bandwidth log_level +# ap_isolation gw_mode orig_interval +# bonding gw_sel_class routing_algo +# bridge_loop_avoidance hop_penalty vis_mode +# fragmentation There is a special folder for debugging information: # ls /sys/kernel/debug/batman_adv/bat0/ -# gateways socket transtable_global vis_data -# originators softif_neigh transtable_local - +# bla_claim_table log socket transtable_local +# gateways originators transtable_global vis_data Some of the files contain all sort of status information regard- ing the mesh network. For example, you can view the table of @@ -202,15 +201,21 @@ abled during run time. Following log_levels are defined: 1 - Enable messages related to routing / flooding / broadcasting 2 - Enable messages related to route added / changed / deleted 4 - Enable messages related to translation table operations -7 - Enable all messages +8 - Enable messages related to bridge loop avoidance +15 - enable all messages The debug output can be changed at runtime using the file /sys/class/net/bat0/mesh/log_level. e.g. -# echo 2 > /sys/class/net/bat0/mesh/log_level +# echo 6 > /sys/class/net/bat0/mesh/log_level will enable debug messages for when routes change. +Counters for different types of packets entering and leaving the +batman-adv module are available through ethtool: + +# ethtool --statistics bat0 + BATCTL ------ diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index bfea8a3..6b1c711 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -1210,7 +1210,7 @@ options, you may wish to use the "max_bonds" module parameter, documented above. To create multiple bonding devices with differing options, it is -preferrable to use bonding parameters exported by sysfs, documented in the +preferable to use bonding parameters exported by sysfs, documented in the section below. For versions of bonding without sysfs support, the only means to @@ -1950,7 +1950,7 @@ access to fail over to. Additionally, the bonding load balance modes support link monitoring of their members, so if individual links fail, the load will be rebalanced across the remaining devices. - See Section 13, "Configuring Bonding for Maximum Throughput" + See Section 12, "Configuring Bonding for Maximum Throughput" for information on configuring bonding with one peer device. 11.2 High Availability in a Multiple Switch Topology @@ -2620,7 +2620,7 @@ be found at: https://lists.sourceforge.net/lists/listinfo/bonding-devel - Discussions regarding the developpement of the bonding driver take place + Discussions regarding the development of the bonding driver take place on the main Linux network mailing list, hosted at vger.kernel.org. The list address is: diff --git a/Documentation/networking/bridge.txt b/Documentation/networking/bridge.txt index a7ba5e4..a27cb62 100644 --- a/Documentation/networking/bridge.txt +++ b/Documentation/networking/bridge.txt @@ -1,7 +1,14 @@ In order to use the Ethernet bridging functionality, you'll need the -userspace tools. These programs and documentation are available -at http://www.linuxfoundation.org/en/Net:Bridge. The download page is -http://prdownloads.sourceforge.net/bridge. +userspace tools. + +Documentation for Linux bridging is on: + http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge + +The bridge-utilities are maintained at: + git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git + +Additionally, the iproute2 utilities can be used to configure +bridge devices. If you still have questions, don't hesitate to post to the mailing list (more info https://lists.linux-foundation.org/mailman/listinfo/bridge). diff --git a/Documentation/networking/caif/Linux-CAIF.txt b/Documentation/networking/caif/Linux-CAIF.txt index e52fd62..0aa4bd3 100644 --- a/Documentation/networking/caif/Linux-CAIF.txt +++ b/Documentation/networking/caif/Linux-CAIF.txt @@ -19,60 +19,36 @@ and host. Currently, UART and Loopback are available for Linux. Architecture: ------------ The implementation of CAIF is divided into: -* CAIF Socket Layer, Kernel API, and Net Device. +* CAIF Socket Layer and GPRS IP Interface. * CAIF Core Protocol Implementation * CAIF Link Layer, implemented as NET devices. RTNL ! - ! +------+ +------+ +------+ - ! +------+! +------+! +------+! - ! ! Sock !! !Kernel!! ! Net !! - ! ! API !+ ! API !+ ! Dev !+ <- CAIF Client APIs - ! +------+ +------! +------+ - ! ! ! ! - ! +----------!----------+ - ! +------+ <- CAIF Protocol Implementation - +-------> ! CAIF ! - ! Core ! - +------+ - +--------!--------+ - ! ! - +------+ +-----+ - ! ! ! TTY ! <- Link Layer (Net Devices) - +------+ +-----+ - - -Using the Kernel API ----------------------- -The Kernel API is used for accessing CAIF channels from the -kernel. -The user of the API has to implement two callbacks for receive -and control. -The receive callback gives a CAIF packet as a SKB. The control -callback will -notify of channel initialization complete, and flow-on/flow- -off. - - - struct caif_device caif_dev = { - .caif_config = { - .name = "MYDEV" - .type = CAIF_CHTY_AT - } - .receive_cb = my_receive, - .control_cb = my_control, - }; - caif_add_device(&caif_dev); - caif_transmit(&caif_dev, skb); - -See the caif_kernel.h for details about the CAIF kernel API. + ! +------+ +------+ + ! +------+! +------+! + ! ! IP !! !Socket!! + +-------> !interf!+ ! API !+ <- CAIF Client APIs + ! +------+ +------! + ! ! ! + ! +-----------+ + ! ! + ! +------+ <- CAIF Core Protocol + ! ! CAIF ! + ! ! Core ! + ! +------+ + ! +----------!---------+ + ! ! ! ! + ! +------+ +-----+ +------+ + +--> ! HSI ! ! TTY ! ! USB ! <- Link Layer (Net Devices) + +------+ +-----+ +------+ + I M P L E M E N T A T I O N =========================== -=========================== + CAIF Core Protocol Layer ========================================= @@ -88,17 +64,13 @@ The Core CAIF implementation contains: - Simple implementation of CAIF. - Layered architecture (a la Streams), each layer in the CAIF specification is implemented in a separate c-file. - - Clients must implement PHY layer to access physical HW - with receive and transmit functions. - Clients must call configuration function to add PHY layer. - Clients must implement CAIF layer to consume/produce CAIF payload with receive and transmit functions. - Clients must call configuration function to add and connect the Client layer. - When receiving / transmitting CAIF Packets (cfpkt), ownership is passed - to the called function (except for framing layers' receive functions - or if a transmit function returns an error, in which case the caller - must free the packet). + to the called function (except for framing layers' receive function) Layered Architecture -------------------- @@ -109,11 +81,6 @@ Implementation. The support functions include: CAIF Packet has functions for creating, destroying and adding content and for adding/extracting header and trailers to protocol packets. - - CFLST CAIF list implementation. - - - CFGLUE CAIF Glue. Contains OS Specifics, such as memory - allocation, endianness, etc. - The CAIF Protocol implementation contains: - CFCNFG CAIF Configuration layer. Configures the CAIF Protocol @@ -128,7 +95,7 @@ The CAIF Protocol implementation contains: control and remote shutdown requests. - CFVEI CAIF VEI layer. Handles CAIF AT Channels on VEI (Virtual - External Interface). This layer encodes/decodes VEI frames. + External Interface). This layer encodes/decodes VEI frames. - CFDGML CAIF Datagram layer. Handles CAIF Datagram layer (IP traffic), encodes/decodes Datagram frames. @@ -170,7 +137,7 @@ The CAIF Protocol implementation contains: +---------+ +---------+ ! ! +---------+ +---------+ - | | | Serial | + | | | Serial | | | | CFSERL | +---------+ +---------+ @@ -186,24 +153,20 @@ In this layered approach the following "rules" apply. layer->dn->transmit(layer->dn, packet); -Linux Driver Implementation +CAIF Socket and IP interface =========================== -Linux GPRS Net Device and CAIF socket are implemented on top of the -CAIF Core protocol. The Net device and CAIF socket have an instance of +The IP interface and CAIF socket API are implemented on top of the +CAIF Core protocol. The IP Interface and CAIF socket have an instance of 'struct cflayer', just like the CAIF Core protocol stack. Net device and Socket implement the 'receive()' function defined by 'struct cflayer', just like the rest of the CAIF stack. In this way, transmit and receive of packets is handled as by the rest of the layers: the 'dn->transmit()' function is called in order to transmit data. -The layer on top of the CAIF Core implementation is -sometimes referred to as the "Client layer". - - Configuration of Link Layer --------------------------- -The Link Layer is implemented as Linux net devices (struct net_device). +The Link Layer is implemented as Linux network devices (struct net_device). Payload handling and registration is done using standard Linux mechanisms. The CAIF Protocol relies on a loss-less link layer without implementing diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 56ca3b7..820f553 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -22,7 +22,8 @@ This file contains 4.1.2 RAW socket option CAN_RAW_ERR_FILTER 4.1.3 RAW socket option CAN_RAW_LOOPBACK 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS - 4.1.5 RAW socket returned message flags + 4.1.5 RAW socket option CAN_RAW_FD_FRAMES + 4.1.6 RAW socket returned message flags 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) 4.3 connected transport protocols (SOCK_SEQPACKET) 4.4 unconnected transport protocols (SOCK_DGRAM) @@ -41,7 +42,8 @@ This file contains 6.5.1 Netlink interface to set/get devices properties 6.5.2 Setting the CAN bit-timing 6.5.3 Starting and stopping the CAN network device - 6.6 supported CAN hardware + 6.6 CAN FD (flexible data rate) driver support + 6.7 supported CAN hardware 7 Socket CAN resources @@ -232,16 +234,16 @@ solution for a couple of reasons: arbitration problems and error frames caused by the different ECUs. The occurrence of detected errors are important for diagnosis and have to be logged together with the exact timestamp. For this - reason the CAN interface driver can generate so called Error Frames - that can optionally be passed to the user application in the same - way as other CAN frames. Whenever an error on the physical layer + reason the CAN interface driver can generate so called Error Message + Frames that can optionally be passed to the user application in the + same way as other CAN frames. Whenever an error on the physical layer or the MAC layer is detected (e.g. by the CAN controller) the driver - creates an appropriate error frame. Error frames can be requested by - the user application using the common CAN filter mechanisms. Inside - this filter definition the (interested) type of errors may be - selected. The reception of error frames is disabled by default. - The format of the CAN error frame is briefly described in the Linux - header file "include/linux/can/error.h". + creates an appropriate error message frame. Error messages frames can + be requested by the user application using the common CAN filter + mechanisms. Inside this filter definition the (interested) type of + errors may be selected. The reception of error messages is disabled + by default. The format of the CAN error message frame is briefly + described in the Linux header file "include/linux/can/error.h". 4. How to use Socket CAN ------------------------ @@ -273,7 +275,7 @@ solution for a couple of reasons: struct can_frame { canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */ - __u8 can_dlc; /* data length code: 0 .. 8 */ + __u8 can_dlc; /* frame payload length in byte (0 .. 8) */ __u8 data[8] __attribute__((aligned(8))); }; @@ -375,6 +377,51 @@ solution for a couple of reasons: nbytes = sendto(s, &frame, sizeof(struct can_frame), 0, (struct sockaddr*)&addr, sizeof(addr)); + Remark about CAN FD (flexible data rate) support: + + Generally the handling of CAN FD is very similar to the formerly described + examples. The new CAN FD capable CAN controllers support two different + bitrates for the arbitration phase and the payload phase of the CAN FD frame + and up to 64 bytes of payload. This extended payload length breaks all the + kernel interfaces (ABI) which heavily rely on the CAN frame with fixed eight + bytes of payload (struct can_frame) like the CAN_RAW socket. Therefore e.g. + the CAN_RAW socket supports a new socket option CAN_RAW_FD_FRAMES that + switches the socket into a mode that allows the handling of CAN FD frames + and (legacy) CAN frames simultaneously (see section 4.1.5). + + The struct canfd_frame is defined in include/linux/can.h: + + struct canfd_frame { + canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */ + __u8 len; /* frame payload length in byte (0 .. 64) */ + __u8 flags; /* additional flags for CAN FD */ + __u8 __res0; /* reserved / padding */ + __u8 __res1; /* reserved / padding */ + __u8 data[64] __attribute__((aligned(8))); + }; + + The struct canfd_frame and the existing struct can_frame have the can_id, + the payload length and the payload data at the same offset inside their + structures. This allows to handle the different structures very similar. + When the content of a struct can_frame is copied into a struct canfd_frame + all structure elements can be used as-is - only the data[] becomes extended. + + When introducing the struct canfd_frame it turned out that the data length + code (DLC) of the struct can_frame was used as a length information as the + length and the DLC has a 1:1 mapping in the range of 0 .. 8. To preserve + the easy handling of the length information the canfd_frame.len element + contains a plain length value from 0 .. 64. So both canfd_frame.len and + can_frame.can_dlc are equal and contain a length information and no DLC. + For details about the distinction of CAN and CAN FD capable devices and + the mapping to the bus-relevant data length code (DLC), see chapter 6.6. + + The length of the two CAN(FD) frame structures define the maximum transfer + unit (MTU) of the CAN(FD) network interface and skbuff data length. Two + definitions are specified for CAN specific MTUs in include/linux/can.h : + + #define CAN_MTU (sizeof(struct can_frame)) == 16 => 'legacy' CAN frame + #define CANFD_MTU (sizeof(struct canfd_frame)) == 72 => CAN FD frame + 4.1 RAW protocol sockets with can_filters (SOCK_RAW) Using CAN_RAW sockets is extensively comparable to the commonly @@ -383,7 +430,7 @@ solution for a couple of reasons: defaults are set at RAW socket binding time: - The filters are set to exactly one filter receiving everything - - The socket only receives valid data frames (=> no error frames) + - The socket only receives valid data frames (=> no error message frames) - The loopback of sent CAN frames is enabled (see chapter 3.2) - The socket does not receive its own sent frames (in loopback mode) @@ -434,7 +481,7 @@ solution for a couple of reasons: 4.1.2 RAW socket option CAN_RAW_ERR_FILTER As described in chapter 3.4 the CAN interface driver can generate so - called Error Frames that can optionally be passed to the user + called Error Message Frames that can optionally be passed to the user application in the same way as other CAN frames. The possible errors are divided into different error classes that may be filtered using the appropriate error mask. To register for every possible @@ -472,7 +519,69 @@ solution for a couple of reasons: setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS, &recv_own_msgs, sizeof(recv_own_msgs)); - 4.1.5 RAW socket returned message flags + 4.1.5 RAW socket option CAN_RAW_FD_FRAMES + + CAN FD support in CAN_RAW sockets can be enabled with a new socket option + CAN_RAW_FD_FRAMES which is off by default. When the new socket option is + not supported by the CAN_RAW socket (e.g. on older kernels), switching the + CAN_RAW_FD_FRAMES option returns the error -ENOPROTOOPT. + + Once CAN_RAW_FD_FRAMES is enabled the application can send both CAN frames + and CAN FD frames. OTOH the application has to handle CAN and CAN FD frames + when reading from the socket. + + CAN_RAW_FD_FRAMES enabled: CAN_MTU and CANFD_MTU are allowed + CAN_RAW_FD_FRAMES disabled: only CAN_MTU is allowed (default) + + Example: + [ remember: CANFD_MTU == sizeof(struct canfd_frame) ] + + struct canfd_frame cfd; + + nbytes = read(s, &cfd, CANFD_MTU); + + if (nbytes == CANFD_MTU) { + printf("got CAN FD frame with length %d\n", cfd.len); + /* cfd.flags contains valid data */ + } else if (nbytes == CAN_MTU) { + printf("got legacy CAN frame with length %d\n", cfd.len); + /* cfd.flags is undefined */ + } else { + fprintf(stderr, "read: invalid CAN(FD) frame\n"); + return 1; + } + + /* the content can be handled independently from the received MTU size */ + + printf("can_id: %X data length: %d data: ", cfd.can_id, cfd.len); + for (i = 0; i < cfd.len; i++) + printf("%02X ", cfd.data[i]); + + When reading with size CANFD_MTU only returns CAN_MTU bytes that have + been received from the socket a legacy CAN frame has been read into the + provided CAN FD structure. Note that the canfd_frame.flags data field is + not specified in the struct can_frame and therefore it is only valid in + CANFD_MTU sized CAN FD frames. + + As long as the payload length is <=8 the received CAN frames from CAN FD + capable CAN devices can be received and read by legacy sockets too. When + user-generated CAN FD frames have a payload length <=8 these can be send + by legacy CAN network interfaces too. Sending CAN FD frames with payload + length > 8 to a legacy CAN network interface returns an -EMSGSIZE error. + + Implementation hint for new CAN applications: + + To build a CAN FD aware application use struct canfd_frame as basic CAN + data structure for CAN_RAW based applications. When the application is + executed on an older Linux kernel and switching the CAN_RAW_FD_FRAMES + socket option returns an error: No problem. You'll get legacy CAN frames + or CAN FD frames and can process them the same way. + + When sending to CAN devices make sure that the device is capable to handle + CAN FD frames by checking if the device maximum transfer unit is CANFD_MTU. + The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall. + + 4.1.6 RAW socket returned message flags When using recvmsg() call, the msg->msg_flags may contain following flags: @@ -527,7 +636,7 @@ solution for a couple of reasons: rcvlist_all - list for unfiltered entries (no filter operations) rcvlist_eff - list for single extended frame (EFF) entries - rcvlist_err - list for error frames masks + rcvlist_err - list for error message frames masks rcvlist_fil - list for mask/value filters rcvlist_inv - list for mask/value filters (inverse semantic) rcvlist_sff - list for single standard frame (SFF) entries @@ -573,10 +682,13 @@ solution for a couple of reasons: dev->type = ARPHRD_CAN; /* the netdevice hardware type */ dev->flags = IFF_NOARP; /* CAN has no arp */ - dev->mtu = sizeof(struct can_frame); + dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> legacy CAN interface */ - The struct can_frame is the payload of each socket buffer in the - protocol family PF_CAN. + or alternative, when the controller supports CAN with flexible data rate: + dev->mtu = CANFD_MTU; /* sizeof(struct canfd_frame) -> CAN FD interface */ + + The struct can_frame or struct canfd_frame is the payload of each socket + buffer (skbuff) in the protocol family PF_CAN. 6.2 local loopback of sent frames @@ -649,7 +761,7 @@ solution for a couple of reasons: The CAN device must be configured via netlink interface. The supported netlink message types are defined and briefly described in "include/linux/can/netlink.h". CAN link support for the program "ip" - of the IPROUTE2 utility suite is avaiable and it can be used as shown + of the IPROUTE2 utility suite is available and it can be used as shown below: - Setting CAN device properties: @@ -784,15 +896,41 @@ solution for a couple of reasons: $ ip link set canX type can restart-ms 100 Alternatively, the application may realize the "bus-off" condition - by monitoring CAN error frames and do a restart when appropriate with - the command: + by monitoring CAN error message frames and do a restart when + appropriate with the command: $ ip link set canX type can restart - Note that a restart will also create a CAN error frame (see also - chapter 3.4). + Note that a restart will also create a CAN error message frame (see + also chapter 3.4). + + 6.6 CAN FD (flexible data rate) driver support + + CAN FD capable CAN controllers support two different bitrates for the + arbitration phase and the payload phase of the CAN FD frame. Therefore a + second bittiming has to be specified in order to enable the CAN FD bitrate. + + Additionally CAN FD capable CAN controllers support up to 64 bytes of + payload. The representation of this length in can_frame.can_dlc and + canfd_frame.len for userspace applications and inside the Linux network + layer is a plain value from 0 .. 64 instead of the CAN 'data length code'. + The data length code was a 1:1 mapping to the payload length in the legacy + CAN frames anyway. The payload length to the bus-relevant DLC mapping is + only performed inside the CAN drivers, preferably with the helper + functions can_dlc2len() and can_len2dlc(). + + The CAN netdevice driver capabilities can be distinguished by the network + devices maximum transfer unit (MTU): + + MTU = 16 (CAN_MTU) => sizeof(struct can_frame) => 'legacy' CAN device + MTU = 72 (CANFD_MTU) => sizeof(struct canfd_frame) => CAN FD capable device + + The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall. + N.B. CAN FD capable devices can also handle and send legacy CAN frames. + + FIXME: Add details about the CAN FD controller configuration when available. - 6.6 Supported CAN hardware + 6.7 Supported CAN hardware Please check the "Kconfig" file in "drivers/net/can" to get an actual list of the support CAN hardware. On the Socket CAN project website diff --git a/Documentation/networking/fore200e.txt b/Documentation/networking/fore200e.txt index f648eb2..d52af53 100644 --- a/Documentation/networking/fore200e.txt +++ b/Documentation/networking/fore200e.txt @@ -11,12 +11,10 @@ i386, alpha (untested), powerpc, sparc and sparc64 archs. The intent is to enable the use of different models of FORE adapters at the same time, by hosts that have several bus interfaces (such as PCI+SBUS, -PCI+MCA or PCI+EISA). +or PCI+EISA). Only PCI and SBUS devices are currently supported by the driver, but support -for other bus interfaces such as EISA should not be too hard to add (this may -be more tricky for the MCA bus, though, as FORE made some MCA-specific -modifications to the adapter's AALI interface). +for other bus interfaces such as EISA should not be too hard to add. Firmware Copyright Notice diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt index 1dc1c24..703cf43 100644 --- a/Documentation/networking/ieee802154.txt +++ b/Documentation/networking/ieee802154.txt @@ -4,15 +4,22 @@ Introduction ============ +The IEEE 802.15.4 working group focuses on standartization of bottom +two layers: Medium Accsess Control (MAC) and Physical (PHY). And there +are mainly two options available for upper layers: + - ZigBee - proprietary protocol from ZigBee Alliance + - 6LowPAN - IPv6 networking over low rate personal area networks The Linux-ZigBee project goal is to provide complete implementation -of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack +of IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack of protocols for organizing Low-Rate Wireless Personal Area Networks. -Currently only IEEE 802.15.4 layer is implemented. We have chosen -to use plain Berkeley socket API, the generic Linux networking stack -to transfer IEEE 802.15.4 messages and a special protocol over genetlink -for configuration/management +The stack is composed of three main parts: + - IEEE 802.15.4 layer; We have chosen to use plain Berkeley socket API, + the generic Linux networking stack to transfer IEEE 802.15.4 messages + and a special protocol over genetlink for configuration/management + - MAC - provides access to shared channel and reliable data delivery + - PHY - represents device drivers Socket API @@ -29,15 +36,6 @@ or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee). One can use SOCK_RAW for passing raw data towards device xmit function. YMMV. -MLME - MAC Level Management -============================ - -Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands. -See the include/net/nl802154.h header. Our userspace tools package -(see above) provides CLI configuration utility for radio interfaces and simple -coordinator for IEEE 802.15.4 networks as an example users of MLME protocol. - - Kernel side ============= @@ -51,6 +49,15 @@ Like with WiFi, there are several types of devices implementing IEEE 802.15.4. Those types of devices require different approach to be hooked into Linux kernel. +MLME - MAC Level Management +============================ + +Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands. +See the include/net/nl802154.h header. Our userspace tools package +(see above) provides CLI configuration utility for radio interfaces and simple +coordinator for IEEE 802.15.4 networks as an example users of MLME protocol. + + HardMAC ======= @@ -73,11 +80,47 @@ We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c SoftMAC ======= -We are going to provide intermediate layer implementing IEEE 802.15.4 MAC -in software. This is currently WIP. +The MAC is the middle layer in the IEEE 802.15.4 Linux stack. This moment it +provides interface for drivers registration and management of slave interfaces. + +NOTE: Currently the only monitor device type is supported - it's IEEE 802.15.4 +stack interface for network sniffers (e.g. WireShark). + +This layer is going to be extended soon. See header include/net/mac802154.h and several drivers in drivers/ieee802154/. + +Device drivers API +================== + +The include/net/mac802154.h defines following functions: + - struct ieee802154_dev *ieee802154_alloc_device + (size_t priv_size, struct ieee802154_ops *ops): + allocation of IEEE 802.15.4 compatible device + + - void ieee802154_free_device(struct ieee802154_dev *dev): + freeing allocated device + + - int ieee802154_register_device(struct ieee802154_dev *dev): + register PHY in the system + + - void ieee802154_unregister_device(struct ieee802154_dev *dev): + freeing registered PHY + +Moreover IEEE 802.15.4 device operations structure should be filled. + +Fake drivers +============ + +In addition there are two drivers available which simulate real devices with +HardMAC (fakehard) and SoftMAC (fakelb - IEEE 802.15.4 loopback driver) +interfaces. This option provides possibility to test and debug stack without +usage of real hardware. + +See sources in drivers/ieee802154 folder for more details. + + 6LoWPAN Linux implementation ============================ diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 1619a8c..ca447b3 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -48,12 +48,6 @@ min_adv_mss - INTEGER The advertised MSS depends on the first hop route MTU, but will never be lower than this setting. -rt_cache_rebuild_count - INTEGER - The per net-namespace route cache emergency rebuild threshold. - Any net-namespace having its route cache rebuilt due to - a hash bucket chain being too long more than this many times - will have its route caching disabled - IP Fragmentation: ipfrag_high_thresh - INTEGER @@ -190,6 +184,20 @@ tcp_cookie_size - INTEGER tcp_dsack - BOOLEAN Allows TCP to send "duplicate" SACKs. +tcp_early_retrans - INTEGER + Enable Early Retransmit (ER), per RFC 5827. ER lowers the threshold + for triggering fast retransmit when the amount of outstanding data is + small and when no previously unsent data can be transmitted (such + that limited transmit could be used). + Possible values: + 0 disables ER + 1 enables ER + 2 enables ER but delays fast recovery and fast retransmit + by a fourth of RTT. This mitigates connection falsely + recovers when network has a small degree of reordering + (less than 3 packets). + Default: 2 + tcp_ecn - INTEGER Enable Explicit Congestion Notification (ECN) in TCP. ECN is only used when both ends of the TCP flow support it. It is useful to @@ -454,6 +462,19 @@ tcp_syncookies - BOOLEAN SYN flood warnings in logs not being really flooded, your server is seriously misconfigured. +tcp_fastopen - INTEGER + Enable TCP Fast Open feature (draft-ietf-tcpm-fastopen) to send data + in the opening SYN packet. To use this feature, the client application + must not use connect(). Instead, it should use sendmsg() or sendto() + with MSG_FASTOPEN flag which performs a TCP handshake automatically. + + The values (bitmap) are: + 1: Enables sending data in the opening SYN on the client + 5: Enables sending data in the opening SYN on the client regardless + of cookie availability. + + Default: 0 + tcp_syn_retries - INTEGER Number of times initial SYNs for an active TCP connection attempt will be retransmitted. Should not be higher than 255. Default value @@ -537,6 +558,25 @@ tcp_thin_dupack - BOOLEAN Documentation/networking/tcp-thin.txt Default: 0 +tcp_limit_output_bytes - INTEGER + Controls TCP Small Queue limit per tcp socket. + TCP bulk sender tends to increase packets in flight until it + gets losses notifications. With SNDBUF autotuning, this can + result in a large amount of packets queued in qdisc/device + on the local machine, hurting latency of other flows, for + typical pfifo_fast qdiscs. + tcp_limit_output_bytes limits the number of bytes on qdisc + or device to reduce artificial RTT/cwnd and reduce bufferbloat. + Note: For GSO/TSO enabled flows, we try to have at least two + packets in flight. Reducing tcp_limit_output_bytes might also + reduce the size of individual GSO packet (64KB being the max) + Default: 131072 + +tcp_challenge_ack_limit - INTEGER + Limits number of Challenge ACK sent per second, as recommended + in RFC 5961 (Improving TCP's Robustness to Blind In-Window Attacks) + Default: 100 + UDP variables: udp_mem - vector of 3 INTEGERs: min, pressure, max @@ -843,9 +883,19 @@ accept_source_route - BOOLEAN FALSE (host) accept_local - BOOLEAN - Accept packets with local source addresses. In combination with - suitable routing, this can be used to direct packets between two - local interfaces over the wire and have them accepted properly. + Accept packets with local source addresses. In combination + with suitable routing, this can be used to direct packets + between two local interfaces over the wire and have them + accepted properly. + + rp_filter must be set to a non-zero value in order for + accept_local to have an effect. + + default FALSE + +route_localnet - BOOLEAN + Do not consider loopback addresses as martian source or destination + while routing. This enables the use of 127/8 for local routing purposes. default FALSE rp_filter - INTEGER @@ -1287,13 +1337,22 @@ bridge-nf-call-ip6tables - BOOLEAN bridge-nf-filter-vlan-tagged - BOOLEAN 1 : pass bridged vlan-tagged ARP/IP/IPv6 traffic to {arp,ip,ip6}tables. 0 : disable this. - Default: 1 + Default: 0 bridge-nf-filter-pppoe-tagged - BOOLEAN 1 : pass bridged pppoe-tagged IP/IPv6 traffic to {ip,ip6}tables. 0 : disable this. - Default: 1 + Default: 0 +bridge-nf-pass-vlan-input-dev - BOOLEAN + 1: if bridge-nf-filter-vlan-tagged is enabled, try to find a vlan + interface on the bridge and set the netfilter input device to the vlan. + This allows use of e.g. "iptables -i br0.1" and makes the REDIRECT + target work with vlan-on-top-of-bridge interfaces. When no matching + vlan interface is found, or this switch is off, the input device is + set to the bridge interface. + 0: disable bridge netfilter vlan interface lookup. + Default: 0 proc/sys/net/sctp/* Variables: @@ -1375,6 +1434,20 @@ path_max_retrans - INTEGER Default: 5 +pf_retrans - INTEGER + The number of retransmissions that will be attempted on a given path + before traffic is redirected to an alternate transport (should one + exist). Note this is distinct from path_max_retrans, as a path that + passes the pf_retrans threshold can still be used. Its only + deprioritized when a transmission path is selected by the stack. This + setting is primarily used to enable fast failover mechanisms without + having to reduce path_max_retrans to a very low value. See: + http://www.ietf.org/id/draft-nishida-tsvwg-sctp-failover-05.txt + for details. Note also that a value of pf_retrans > path_max_retrans + disables this feature + + Default: 0 + rto_initial - INTEGER The initial round trip timeout value in milliseconds that will be used in calculating round trip times. This is the initial time interval @@ -1484,11 +1557,8 @@ addr_scope_policy - INTEGER /proc/sys/net/core/* -dev_weight - INTEGER - The maximum number of packets that kernel can handle on a NAPI - interrupt, it's a Per-CPU variable. + Please see: Documentation/sysctl/net.txt for descriptions of these entries. - Default: 64 /proc/sys/net/unix/* max_dgram_qlen - INTEGER diff --git a/Documentation/networking/mac80211-auth-assoc-deauth.txt b/Documentation/networking/mac80211-auth-assoc-deauth.txt index e0a2aa58..d7a15fe 100644 --- a/Documentation/networking/mac80211-auth-assoc-deauth.txt +++ b/Documentation/networking/mac80211-auth-assoc-deauth.txt @@ -23,7 +23,7 @@ BA session stop & deauth/disassoc frames end note end -mac80211->driver: config(channel, non-HT) +mac80211->driver: config(channel, channel type) mac80211->driver: bss_info_changed(set BSSID, basic rate bitmap) mac80211->driver: sta_state(AP, exists) @@ -51,7 +51,7 @@ note over mac80211,driver: cleanup like for authenticate end alt not previously authenticated (FT) -mac80211->driver: config(channel, non-HT) +mac80211->driver: config(channel, channel type) mac80211->driver: bss_info_changed(set BSSID, basic rate bitmap) mac80211->driver: sta_state(AP, exists) mac80211->driver: sta_state(AP, authenticated) @@ -67,10 +67,6 @@ end mac80211->driver: set up QoS parameters -alt is HT channel -mac80211->driver: config(channel, HT params) -end - mac80211->driver: bss_info_changed(QoS, HT, associated with AID) mac80211->userspace: associated @@ -95,5 +91,5 @@ mac80211->driver: sta_state(AP,exists) mac80211->driver: sta_state(AP,not-exists) mac80211->driver: turn off powersave mac80211->driver: bss_info_changed(clear BSSID, not associated, no QoS, ...) -mac80211->driver: config(non-HT channel type) +mac80211->driver: config(channel type to non-HT) mac80211->userspace: disconnected diff --git a/Documentation/networking/olympic.txt b/Documentation/networking/olympic.txt deleted file mode 100644 index b95b5bf..0000000 --- a/Documentation/networking/olympic.txt +++ /dev/null @@ -1,79 +0,0 @@ - -IBM PCI Pit/Pit-Phy/Olympic CHIPSET BASED TOKEN RING CARDS README - -Release 0.2.0 - Release - June 8th 1999 Peter De Schrijver & Mike Phillips -Release 0.9.C - Release - April 18th 2001 Mike Phillips - -Thanks: -Erik De Cock, Adrian Bridgett and Frank Fiene for their -patience and testing. -Donald Champion for the cardbus support -Kyle Lucke for the dma api changes. -Jonathon Bitner for hardware support. -Everybody on linux-tr for their continued support. - -Options: - -The driver accepts four options: ringspeed, pkt_buf_sz, -message_level and network_monitor. - -These options can be specified differently for each card found. - -ringspeed: Has one of three settings 0 (default), 4 or 16. 0 will -make the card autosense the ringspeed and join at the appropriate speed, -this will be the default option for most people. 4 or 16 allow you to -explicitly force the card to operate at a certain speed. The card will fail -if you try to insert it at the wrong speed. (Although some hubs will allow -this so be *very* careful). The main purpose for explicitly setting the ring -speed is for when the card is first on the ring. In autosense mode, if the card -cannot detect any active monitors on the ring it will not open, so you must -re-init the card at the appropriate speed. Unfortunately at present the only -way of doing this is rmmod and insmod which is a bit tough if it is compiled -in the kernel. - -pkt_buf_sz: This is this initial receive buffer allocation size. This will -default to 4096 if no value is entered. You may increase performance of the -driver by setting this to a value larger than the network packet size, although -the driver now re-sizes buffers based on MTU settings as well. - -message_level: Controls level of messages created by the driver. Defaults to 0: -which only displays start-up and critical messages. Presently any non-zero -value will display all soft messages as well. NB This does not turn -debugging messages on, that must be done by modified the source code. - -network_monitor: Any non-zero value will provide a quasi network monitoring -mode. All unexpected MAC frames (beaconing etc.) will be received -by the driver and the source and destination addresses printed. -Also an entry will be added in /proc/net called olympic_tr%d, where tr%d -is the registered device name, i.e tr0, tr1, etc. This displays low -level information about the configuration of the ring and the adapter. -This feature has been designed for network administrators to assist in -the diagnosis of network / ring problems. (This used to OLYMPIC_NETWORK_MONITOR, -but has now changed to allow each adapter to be configured differently and -to alleviate the necessity to re-compile olympic to turn the option on). - -Multi-card: - -The driver will detect multiple cards and will work with shared interrupts, -each card is assigned the next token ring device, i.e. tr0 , tr1, tr2. The -driver should also happily reside in the system with other drivers. It has -been tested with ibmtr.c running, and I personally have had one Olicom PCI -card and two IBM olympic cards (all on the same interrupt), all running -together. - -Variable MTU size: - -The driver can handle a MTU size up to either 4500 or 18000 depending upon -ring speed. The driver also changes the size of the receive buffers as part -of the mtu re-sizing, so if you set mtu = 18000, you will need to be able -to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring -position = 296,000 bytes of memory space, plus of course anything -necessary for the tx sk_buff's. Remember this is per card, so if you are -building routers, gateway's etc, you could start to use a lot of memory -real fast. - - -6/8/99 Peter De Schrijver and Mike Phillips - diff --git a/Documentation/networking/openvswitch.txt b/Documentation/networking/openvswitch.txt index b8a048b..8fa2dd1 100644 --- a/Documentation/networking/openvswitch.txt +++ b/Documentation/networking/openvswitch.txt @@ -118,7 +118,7 @@ essentially like this, ignoring metadata: Naively, to add VLAN support, it makes sense to add a new "vlan" flow key attribute to contain the VLAN tag, then continue to decode the encapsulated headers beyond the VLAN tag using the existing field -definitions. With this change, an TCP packet in VLAN 10 would have a +definitions. With this change, a TCP packet in VLAN 10 would have a flow key much like this: eth(...), vlan(vid=10, pcp=0), eth_type(0x0800), ip(proto=6, ...), tcp(...) diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt index 4be0c03..d2a9f43 100644 --- a/Documentation/networking/s2io.txt +++ b/Documentation/networking/s2io.txt @@ -136,16 +136,6 @@ For more information, please review the AMD8131 errata at http://vip.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/ 26310_AMD-8131_HyperTransport_PCI-X_Tunnel_Revision_Guide_rev_3_18.pdf -6. Available Downloads -Neterion "s2io" driver in Red Hat and Suse 2.6-based distributions is kept up -to date, also the latest "s2io" code (including support for 2.4 kernels) is -available via "Support" link on the Neterion site: http://www.neterion.com. - -For Xframe User Guide (Programming manual), visit ftp site ns1.s2io.com, -user: linuxdocs password: HALdocs - -7. Support +6. Support For further support please contact either your 10GbE Xframe NIC vendor (IBM, -HP, SGI etc.) or click on the "Support" link on the Neterion site: -http://www.neterion.com. - +HP, SGI etc.) diff --git a/Documentation/networking/smctr.txt b/Documentation/networking/smctr.txt deleted file mode 100644 index 9af25b8..0000000 --- a/Documentation/networking/smctr.txt +++ /dev/null @@ -1,66 +0,0 @@ -Text File for the SMC TokenCard TokenRing Linux driver (smctr.c). - By Jay Schulist <jschlst@samba.org> - -The Linux SMC Token Ring driver works with the SMC TokenCard Elite (8115T) -ISA and SMC TokenCard Elite/A (8115T/A) MCA adapters. - -Latest information on this driver can be obtained on the Linux-SNA WWW site. -Please point your browser to: http://www.linux-sna.org - -This driver is rather simple to use. Select Y to Token Ring adapter support -in the kernel configuration. A choice for SMC Token Ring adapters will -appear. This drives supports all SMC ISA/MCA adapters. Choose this -option. I personally recommend compiling the driver as a module (M), but if you -you would like to compile it statically answer Y instead. - -This driver supports multiple adapters without the need to load multiple copies -of the driver. You should be able to load up to 7 adapters without any kernel -modifications, if you are in need of more please contact the maintainer of this -driver. - -Load the driver either by lilo/loadlin or as a module. When a module using the -following command will suffice for most: - -# modprobe smctr -smctr.c: v1.00 12/6/99 by jschlst@samba.org -tr0: SMC TokenCard 8115T at Io 0x300, Irq 10, Rom 0xd8000, Ram 0xcc000. - -Now just setup the device via ifconfig and set and routes you may have. After -this you are ready to start sending some tokens. - -Errata: -1). For anyone wondering where to pick up the SMC adapters please browse - to http://www.smc.com - -2). If you are the first/only Token Ring Client on a Token Ring LAN, please - specify the ringspeed with the ringspeed=[4/16] module option. If no - ringspeed is specified the driver will attempt to autodetect the ring - speed and/or if the adapter is the first/only station on the ring take - the appropriate actions. - - NOTE: Default ring speed is 16MB UTP. - -3). PnP support for this adapter sucks. I recommend hard setting the - IO/MEM/IRQ by the jumpers on the adapter. If this is not possible - load the module with the following io=[ioaddr] mem=[mem_addr] - irq=[irq_num]. - - The following IRQ, IO, and MEM settings are supported. - - IO ports: - 0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0, 0x300, - 0x320, 0x340, 0x360, 0x380. - - IRQs: - 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15 - - Memory addresses: - 0xA0000, 0xA4000, 0xA8000, 0xAC000, 0xB0000, 0xB4000, - 0xB8000, 0xBC000, 0xC0000, 0xC4000, 0xC8000, 0xCC000, - 0xD0000, 0xD4000, 0xD8000, 0xDC000, 0xE0000, 0xE4000, - 0xE8000, 0xEC000, 0xF0000, 0xF4000, 0xF8000, 0xFC000 - -This driver is under the GNU General Public License. Its Firmware image is -included as an initialized C-array and is licensed by SMC to the Linux -users of this driver. However no warranty about its fitness is expressed or -implied by SMC. diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt index d0aeead..c676b9c 100644 --- a/Documentation/networking/stmmac.txt +++ b/Documentation/networking/stmmac.txt @@ -10,8 +10,8 @@ Currently this network device driver is for all STM embedded MAC/GMAC (i.e. 7xxx/5xxx SoCs), SPEAr (arm), Loongson1B (mips) and XLINX XC2V3000 FF1152AMT0221 D1215994A VIRTEX FPGA board. -DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether MAC 10/100 -Universal version 4.0 have been used for developing this driver. +DWC Ether MAC 10/100/1000 Universal version 3.60a (and older) and DWC Ether +MAC 10/100 Universal version 4.0 have been used for developing this driver. This driver supports both the platform bus and PCI. @@ -54,27 +54,27 @@ net_device structure enabling the scatter/gather feature. When one or more packets are received, an interrupt happens. The interrupts are not queued so the driver has to scan all the descriptors in the ring during the receive process. -This is based on NAPI so the interrupt handler signals only if there is work to be -done, and it exits. +This is based on NAPI so the interrupt handler signals only if there is work +to be done, and it exits. Then the poll method will be scheduled at some future point. The incoming packets are stored, by the DMA, in a list of pre-allocated socket buffers in order to avoid the memcpy (Zero-copy). 4.3) Timer-Driver Interrupt -Instead of having the device that asynchronously notifies the frame receptions, the -driver configures a timer to generate an interrupt at regular intervals. -Based on the granularity of the timer, the frames that are received by the device -will experience different levels of latency. Some NICs have dedicated timer -device to perform this task. STMMAC can use either the RTC device or the TMU -channel 2 on STLinux platforms. +Instead of having the device that asynchronously notifies the frame receptions, +the driver configures a timer to generate an interrupt at regular intervals. +Based on the granularity of the timer, the frames that are received by the +device will experience different levels of latency. Some NICs have dedicated +timer device to perform this task. STMMAC can use either the RTC device or the +TMU channel 2 on STLinux platforms. The timers frequency can be passed to the driver as parameter; when change it, take care of both hardware capability and network stability/performance impact. -Several performance tests on STM platforms showed this optimisation allows to spare -the CPU while having the maximum throughput. +Several performance tests on STM platforms showed this optimisation allows to +spare the CPU while having the maximum throughput. 4.4) WOL -Wake up on Lan feature through Magic and Unicast frames are supported for the GMAC -core. +Wake up on Lan feature through Magic and Unicast frames are supported for the +GMAC core. 4.5) DMA descriptors Driver handles both normal and enhanced descriptors. The latter has been only @@ -106,16 +106,18 @@ Several driver's information can be passed through the platform These are included in the include/linux/stmmac.h header file and detailed below as well: - struct plat_stmmacenet_data { +struct plat_stmmacenet_data { + char *phy_bus_name; int bus_id; int phy_addr; int interface; struct stmmac_mdio_bus_data *mdio_bus_data; - int pbl; + struct stmmac_dma_cfg *dma_cfg; int clk_csr; int has_gmac; int enh_desc; int tx_coe; + int rx_coe; int bugged_jumbo; int pmt; int force_sf_dma_mode; @@ -123,23 +125,30 @@ and detailed below as well: void (*bus_setup)(void __iomem *ioaddr); int (*init)(struct platform_device *pdev); void (*exit)(struct platform_device *pdev); + void *custom_cfg; + void *custom_data; void *bsp_priv; }; Where: + o phy_bus_name: phy bus name to attach to the stmmac. o bus_id: bus identifier. o phy_addr: the physical address can be passed from the platform. If it is set to -1 the driver will automatically detect it at run-time by probing all the 32 addresses. o interface: PHY device's interface. o mdio_bus_data: specific platform fields for the MDIO bus. - o pbl: the Programmable Burst Length is maximum number of beats to + o dma_cfg: internal DMA parameters + o pbl: the Programmable Burst Length is maximum number of beats to be transferred in one DMA transaction. GMAC also enables the 4xPBL by default. - o clk_csr: CSR Clock range selection. + o fixed_burst/mixed_burst/burst_len + o clk_csr: fixed CSR Clock range selection. o has_gmac: uses the GMAC core. o enh_desc: if sets the MAC will use the enhanced descriptor structure. o tx_coe: core is able to perform the tx csum in HW. + o rx_coe: the supports three check sum offloading engine types: + type_1, type_2 (full csum) and no RX coe. o bugged_jumbo: some HWs are not able to perform the csum in HW for over-sized frames due to limited buffer sizes. Setting this flag the csum will be done in SW on @@ -157,10 +166,11 @@ Where: this is sometime necessary on some platforms (e.g. ST boxes) where the HW needs to have set some PIO lines or system cfg registers. - o custom_cfg: this is a custom configuration that can be passed while - initialising the resources. + o custom_cfg/custom_data: this is a custom configuration that can be passed + while initialising the resources. + o bsp_priv: another private poiter. -The we have: +For MDIO bus The we have: struct stmmac_mdio_bus_data { int bus_id; @@ -177,10 +187,27 @@ Where: o irqs: list of IRQs, one per PHY. o probed_phy_irq: if irqs is NULL, use this for probed PHY. +For DMA engine we have the following internal fields that should be +tuned according to the HW capabilities. + +struct stmmac_dma_cfg { + int pbl; + int fixed_burst; + int burst_len_supported; +}; + +Where: + o pbl: Programmable Burst Length + o fixed_burst: program the DMA to use the fixed burst mode + o burst_len: this is the value we put in the register + supported values are provided as macros in + linux/stmmac.h header file. + +--- + Below an example how the structures above are using on ST platforms. static struct plat_stmmacenet_data stxYYY_ethernet_platform_data = { - .pbl = 32, .has_gmac = 0, .enh_desc = 0, .fix_mac_speed = stxYYY_ethernet_fix_mac_speed, @@ -230,9 +257,11 @@ reset procedure etc). o Makefile o stmmac_main.c: main network device driver; o stmmac_mdio.c: mdio functions; + o stmmac_pci: PCI driver; + o stmmac_platform.c: platform driver o stmmac_ethtool.c: ethtool support; o stmmac_timer.[ch]: timer code used for mitigating the driver dma interrupts - Only tested on ST40 platforms based. + (only tested on ST40 platforms based); o stmmac.h: private driver structure; o common.h: common definitions and VFTs; o descs.h: descriptor structure definitions; @@ -242,9 +271,11 @@ reset procedure etc). o dwmac100_core: MAC 100 core and dma code; o dwmac100_dma.c: dma funtions for the MAC chip; o dwmac1000.h: specific header file for the MAC; - o dwmac_lib.c: generic DMA functions shared among chips - o enh_desc.c: functions for handling enhanced descriptors - o norm_desc.c: functions for handling normal descriptors + o dwmac_lib.c: generic DMA functions shared among chips; + o enh_desc.c: functions for handling enhanced descriptors; + o norm_desc.c: functions for handling normal descriptors; + o chain_mode.c/ring_mode.c:: functions to manage RING/CHAINED modes; + o mmc_core.c/mmc.h: Management MAC Counters; 5) Debug Information @@ -277,7 +308,27 @@ All these are only useful during the developing stage and should never enabled inside the code for general usage. In fact, these can generate an huge amount of debug messages. -6) TODO: +6) Energy Efficient Ethernet + +Energy Efficient Ethernet(EEE) enables IEEE 802.3 MAC sublayer along +with a family of Physical layer to operate in the Low power Idle(LPI) +mode. The EEE mode supports the IEEE 802.3 MAC operation at 100Mbps, +1000Mbps & 10Gbps. + +The LPI mode allows power saving by switching off parts of the +communication device functionality when there is no data to be +transmitted & received. The system on both the side of the link can +disable some functionalities & save power during the period of low-link +utilization. The MAC controls whether the system should enter or exit +the LPI mode & communicate this to PHY. + +As soon as the interface is opened, the driver verifies if the EEE can +be supported. This is done by looking at both the DMA HW capability +register and the PHY devices MCD registers. +To enter in Tx LPI mode the driver needs to have a software timer +that enable and disable the LPI mode when there is nothing to be +transmitted. + +7) TODO: o XGMAC is not supported. - o Add the EEE - Energy Efficient Ethernet o Add the PTP - precision time protocol diff --git a/Documentation/networking/tms380tr.txt b/Documentation/networking/tms380tr.txt deleted file mode 100644 index 1f73e13..0000000 --- a/Documentation/networking/tms380tr.txt +++ /dev/null @@ -1,147 +0,0 @@ -Text file for the Linux SysKonnect Token Ring ISA/PCI Adapter Driver. - Text file by: Jay Schulist <jschlst@samba.org> - -The Linux SysKonnect Token Ring driver works with the SysKonnect TR4/16(+) ISA, -SysKonnect TR4/16(+) PCI, SysKonnect TR4/16 PCI, and older revisions of the -SK NET TR4/16 ISA card. - -Latest information on this driver can be obtained on the Linux-SNA WWW site. -Please point your browser to: -http://www.linux-sna.org - -Many thanks to Christoph Goos for his excellent work on this driver and -SysKonnect for donating the adapters to Linux-SNA for the testing and -maintenance of this device driver. - -Important information to be noted: -1. Adapters can be slow to open (~20 secs) and close (~5 secs), please be - patient. -2. This driver works very well when autoprobing for adapters. Why even - think about those nasty io/int/dma settings of modprobe when the driver - will do it all for you! - -This driver is rather simple to use. Select Y to Token Ring adapter support -in the kernel configuration. A choice for SysKonnect Token Ring adapters will -appear. This drives supports all SysKonnect ISA and PCI adapters. Choose this -option. I personally recommend compiling the driver as a module (M), but if you -you would like to compile it statically answer Y instead. - -This driver supports multiple adapters without the need to load multiple copies -of the driver. You should be able to load up to 7 adapters without any kernel -modifications, if you are in need of more please contact the maintainer of this -driver. - -Load the driver either by lilo/loadlin or as a module. When a module using the -following command will suffice for most: - -# modprobe sktr - -This will produce output similar to the following: (Output is user specific) - -sktr.c: v1.01 08/29/97 by Christoph Goos -tr0: SK NET TR 4/16 PCI found at 0x6100, using IRQ 17. -tr1: SK NET TR 4/16 PCI found at 0x6200, using IRQ 16. -tr2: SK NET TR 4/16 ISA found at 0xa20, using IRQ 10 and DMA 5. - -Now just setup the device via ifconfig and set and routes you may have. After -this you are ready to start sending some tokens. - -Errata: -For anyone wondering where to pick up the SysKonnect adapters please browse -to http://www.syskonnect.com - -This driver is under the GNU General Public License. Its Firmware image is -included as an initialized C-array and is licensed by SysKonnect to the Linux -users of this driver. However no warranty about its fitness is expressed or -implied by SysKonnect. - -Below find attached the setting for the SK NET TR 4/16 ISA adapters -------------------------------------------------------------------- - - *************************** - *** C O N T E N T S *** - *************************** - - 1) Location of DIP-Switch W1 - 2) Default settings - 3) DIP-Switch W1 description - - - ============================================================== - CHAPTER 1 LOCATION OF DIP-SWITCH - ============================================================== - -UÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ -þUÄÄÄÄÄÄ¿ UÄÄÄÄÄ¿ UÄÄÄ¿ þ -þAÄÄÄÄÄÄU W1 AÄÄÄÄÄU UÄÄÄÄ¿ þ þ þ -þUÄÄÄÄÄÄ¿ þ þ þ þ UÄÄÅ¿ -þAÄÄÄÄÄÄU UÄÄÄÄÄÄÄÄÄÄÄ¿ AÄÄÄÄU þ þ þ þþ -þUÄÄÄÄÄÄ¿ þ þ UÄÄÄ¿ AÄÄÄU AÄÄÅU -þAÄÄÄÄÄÄU þ TMS380C26 þ þ þ þ -þUÄÄÄÄÄÄ¿ þ þ AÄÄÄU AÄ¿ -þAÄÄÄÄÄÄU þ þ þ þ -þ AÄÄÄÄÄÄÄÄÄÄÄU þ þ -þ þ þ -þ AÄU -þ þ -þ þ -þ þ -þ þ -AÄÄÄÄÄÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄAÄÄAÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄAÄÄÄÄÄÄÄÄÄU - AÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄU AÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄU - - ============================================================== - CHAPTER 2 DEFAULT SETTINGS - ============================================================== - - W1 1 2 3 4 5 6 7 8 - +------------------------------+ - | ON X | - | OFF X X X X X X X | - +------------------------------+ - - W1.1 = ON Adapter drives address lines SA17..19 - W1.2 - 1.5 = OFF BootROM disabled - W1.6 - 1.8 = OFF I/O address 0A20h - - ============================================================== - CHAPTER 3 DIP SWITCH W1 DESCRIPTION - ============================================================== - - UÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄ¿ ON - þ 1 þ 2 þ 3 þ 4 þ 5 þ 6 þ 7 þ 8 þ - AÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄAÄÄÄU OFF - |AD | BootROM Addr. | I/O | - +-+-+-------+-------+-----+-----+ - | | | - | | +------ 6 7 8 - | | ON ON ON 1900h - | | ON ON OFF 0900h - | | ON OFF ON 1980h - | | ON OFF OFF 0980h - | | OFF ON ON 1b20h - | | OFF ON OFF 0b20h - | | OFF OFF ON 1a20h - | | OFF OFF OFF 0a20h (+) - | | - | | - | +-------- 2 3 4 5 - | OFF x x x disabled (+) - | ON ON ON ON C0000 - | ON ON ON OFF C4000 - | ON ON OFF ON C8000 - | ON ON OFF OFF CC000 - | ON OFF ON ON D0000 - | ON OFF ON OFF D4000 - | ON OFF OFF ON D8000 - | ON OFF OFF OFF DC000 - | - | - +----- 1 - OFF adapter does NOT drive SA<17..19> - ON adapter drives SA<17..19> (+) - - - (+) means default setting - - ******************************** diff --git a/Documentation/networking/vxge.txt b/Documentation/networking/vxge.txt index d2e2997..bb76c66 100644 --- a/Documentation/networking/vxge.txt +++ b/Documentation/networking/vxge.txt @@ -91,10 +91,3 @@ v) addr_learn_en virtualization environment. Valid range: 0,1 (disabled, enabled respectively) Default: 0 - -4) Troubleshooting: -------------------- - -To resolve an issue with the source code or X3100 series adapter, please collect -the statistics, register dumps using ethool, relevant logs and email them to -support@neterion.com. diff --git a/Documentation/nfc/nfc-hci.txt b/Documentation/nfc/nfc-hci.txt new file mode 100644 index 0000000..89a339c --- /dev/null +++ b/Documentation/nfc/nfc-hci.txt @@ -0,0 +1,213 @@ +HCI backend for NFC Core + +Author: Eric Lapuyade, Samuel Ortiz +Contact: eric.lapuyade@intel.com, samuel.ortiz@intel.com + +General +------- + +The HCI layer implements much of the ETSI TS 102 622 V10.2.0 specification. It +enables easy writing of HCI-based NFC drivers. The HCI layer runs as an NFC Core +backend, implementing an abstract nfc device and translating NFC Core API +to HCI commands and events. + +HCI +--- + +HCI registers as an nfc device with NFC Core. Requests coming from userspace are +routed through netlink sockets to NFC Core and then to HCI. From this point, +they are translated in a sequence of HCI commands sent to the HCI layer in the +host controller (the chip). The sending context blocks while waiting for the +response to arrive. +HCI events can also be received from the host controller. They will be handled +and a translation will be forwarded to NFC Core as needed. +HCI uses 2 execution contexts: +- one for executing commands : nfc_hci_msg_tx_work(). Only one command +can be executing at any given moment. +- one for dispatching received events and commands : nfc_hci_msg_rx_work(). + +HCI Session initialization: +--------------------------- + +The Session initialization is an HCI standard which must unfortunately +support proprietary gates. This is the reason why the driver will pass a list +of proprietary gates that must be part of the session. HCI will ensure all +those gates have pipes connected when the hci device is set up. + +HCI Gates and Pipes +------------------- + +A gate defines the 'port' where some service can be found. In order to access +a service, one must create a pipe to that gate and open it. In this +implementation, pipes are totally hidden. The public API only knows gates. +This is consistent with the driver need to send commands to proprietary gates +without knowing the pipe connected to it. + +Driver interface +---------------- + +A driver would normally register itself with HCI and provide the following +entry points: + +struct nfc_hci_ops { + int (*open)(struct nfc_hci_dev *hdev); + void (*close)(struct nfc_hci_dev *hdev); + int (*hci_ready) (struct nfc_hci_dev *hdev); + int (*xmit)(struct nfc_hci_dev *hdev, struct sk_buff *skb); + int (*start_poll)(struct nfc_hci_dev *hdev, u32 protocols); + int (*target_from_gate)(struct nfc_hci_dev *hdev, u8 gate, + struct nfc_target *target); + int (*complete_target_discovered) (struct nfc_hci_dev *hdev, u8 gate, + struct nfc_target *target); + int (*data_exchange) (struct nfc_hci_dev *hdev, + struct nfc_target *target, + struct sk_buff *skb, struct sk_buff **res_skb); + int (*check_presence)(struct nfc_hci_dev *hdev, + struct nfc_target *target); +}; + +- open() and close() shall turn the hardware on and off. +- hci_ready() is an optional entry point that is called right after the hci +session has been set up. The driver can use it to do additional initialization +that must be performed using HCI commands. +- xmit() shall simply write a frame to the chip. +- start_poll() is an optional entrypoint that shall set the hardware in polling +mode. This must be implemented only if the hardware uses proprietary gates or a +mechanism slightly different from the HCI standard. +- target_from_gate() is an optional entrypoint to return the nfc protocols +corresponding to a proprietary gate. +- complete_target_discovered() is an optional entry point to let the driver +perform additional proprietary processing necessary to auto activate the +discovered target. +- data_exchange() must be implemented by the driver if proprietary HCI commands +are required to send data to the tag. Some tag types will require custom +commands, others can be written to using the standard HCI commands. The driver +can check the tag type and either do proprietary processing, or return 1 to ask +for standard processing. +- check_presence() is an optional entry point that will be called regularly +by the core to check that an activated tag is still in the field. If this is +not implemented, the core will not be able to push tag_lost events to the user +space + +On the rx path, the driver is responsible to push incoming HCP frames to HCI +using nfc_hci_recv_frame(). HCI will take care of re-aggregation and handling +This must be done from a context that can sleep. + +SHDLC +----- + +Most chips use shdlc to ensure integrity and delivery ordering of the HCP +frames between the host controller (the chip) and hosts (entities connected +to the chip, like the cpu). In order to simplify writing the driver, an shdlc +layer is available for use by the driver. +When used, the driver actually registers with shdlc, and shdlc will register +with HCI. HCI sees shdlc as the driver and thus send its HCP frames +through shdlc->xmit. +SHDLC adds a new execution context (nfc_shdlc_sm_work()) to run its state +machine and handle both its rx and tx path. + +Included Drivers +---------------- + +An HCI based driver for an NXP PN544, connected through I2C bus, and using +shdlc is included. + +Execution Contexts +------------------ + +The execution contexts are the following: +- IRQ handler (IRQH): +fast, cannot sleep. stores incoming frames into an shdlc rx queue + +- SHDLC State Machine worker (SMW) +handles shdlc rx & tx queues. Dispatches HCI cmd responses. + +- HCI Tx Cmd worker (MSGTXWQ) +Serializes execution of HCI commands. Completes execution in case of response +timeout. + +- HCI Rx worker (MSGRXWQ) +Dispatches incoming HCI commands or events. + +- Syscall context from a userspace call (SYSCALL) +Any entrypoint in HCI called from NFC Core + +Workflow executing an HCI command (using shdlc) +----------------------------------------------- + +Executing an HCI command can easily be performed synchronously using the +following API: + +int nfc_hci_send_cmd (struct nfc_hci_dev *hdev, u8 gate, u8 cmd, + const u8 *param, size_t param_len, struct sk_buff **skb) + +The API must be invoked from a context that can sleep. Most of the time, this +will be the syscall context. skb will return the result that was received in +the response. + +Internally, execution is asynchronous. So all this API does is to enqueue the +HCI command, setup a local wait queue on stack, and wait_event() for completion. +The wait is not interruptible because it is guaranteed that the command will +complete after some short timeout anyway. + +MSGTXWQ context will then be scheduled and invoke nfc_hci_msg_tx_work(). +This function will dequeue the next pending command and send its HCP fragments +to the lower layer which happens to be shdlc. It will then start a timer to be +able to complete the command with a timeout error if no response arrive. + +SMW context gets scheduled and invokes nfc_shdlc_sm_work(). This function +handles shdlc framing in and out. It uses the driver xmit to send frames and +receives incoming frames in an skb queue filled from the driver IRQ handler. +SHDLC I(nformation) frames payload are HCP fragments. They are aggregated to +form complete HCI frames, which can be a response, command, or event. + +HCI Responses are dispatched immediately from this context to unblock +waiting command execution. Response processing involves invoking the completion +callback that was provided by nfc_hci_msg_tx_work() when it sent the command. +The completion callback will then wake the syscall context. + +Workflow receiving an HCI event or command +------------------------------------------ + +HCI commands or events are not dispatched from SMW context. Instead, they are +queued to HCI rx_queue and will be dispatched from HCI rx worker +context (MSGRXWQ). This is done this way to allow a cmd or event handler +to also execute other commands (for example, handling the +NFC_HCI_EVT_TARGET_DISCOVERED event from PN544 requires to issue an +ANY_GET_PARAMETER to the reader A gate to get information on the target +that was discovered). + +Typically, such an event will be propagated to NFC Core from MSGRXWQ context. + +Error management +---------------- + +Errors that occur synchronously with the execution of an NFC Core request are +simply returned as the execution result of the request. These are easy. + +Errors that occur asynchronously (e.g. in a background protocol handling thread) +must be reported such that upper layers don't stay ignorant that something +went wrong below and know that expected events will probably never happen. +Handling of these errors is done as follows: + +- driver (pn544) fails to deliver an incoming frame: it stores the error such +that any subsequent call to the driver will result in this error. Then it calls +the standard nfc_shdlc_recv_frame() with a NULL argument to report the problem +above. shdlc stores a EREMOTEIO sticky status, which will trigger SMW to +report above in turn. + +- SMW is basically a background thread to handle incoming and outgoing shdlc +frames. This thread will also check the shdlc sticky status and report to HCI +when it discovers it is not able to run anymore because of an unrecoverable +error that happened within shdlc or below. If the problem occurs during shdlc +connection, the error is reported through the connect completion. + +- HCI: if an internal HCI error happens (frame is lost), or HCI is reported an +error from a lower layer, HCI will either complete the currently executing +command with that error, or notify NFC Core directly if no command is executing. + +- NFC Core: when NFC Core is notified of an error from below and polling is +active, it will send a tag discovered event with an empty tag list to the user +space to let it know that the poll operation will never be able to detect a tag. +If polling is not active and the error was sticky, lower levels will return it +at next invocation. diff --git a/Documentation/parisc/debugging b/Documentation/parisc/debugging index d728594..7d75223 100644 --- a/Documentation/parisc/debugging +++ b/Documentation/parisc/debugging @@ -34,6 +34,6 @@ registers interruption handlers read to find out where the machine was interrupted - so if you get an interruption between the instruction that clears the Q bit and the RFI that sets it again you don't know where exactly it happened. If you're lucky the IAOQ will point to the -instrucion that cleared the Q bit, if you're not it points anywhere +instruction that cleared the Q bit, if you're not it points anywhere at all. Usually Q bit problems will show themselves in unexplainable system hangs or running off the end of physical memory. diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index d97bccf..e40f4b4 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -152,11 +152,9 @@ static const struct foo_group foo_groups[] = { }; -static int foo_list_groups(struct pinctrl_dev *pctldev, unsigned selector) +static int foo_get_groups_count(struct pinctrl_dev *pctldev) { - if (selector >= ARRAY_SIZE(foo_groups)) - return -EINVAL; - return 0; + return ARRAY_SIZE(foo_groups); } static const char *foo_get_group_name(struct pinctrl_dev *pctldev, @@ -175,7 +173,7 @@ static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector, } static struct pinctrl_ops foo_pctrl_ops = { - .list_groups = foo_list_groups, + .get_groups_count = foo_get_groups_count, .get_group_name = foo_get_group_name, .get_group_pins = foo_get_group_pins, }; @@ -186,13 +184,12 @@ static struct pinctrl_desc foo_desc = { .pctlops = &foo_pctrl_ops, }; -The pin control subsystem will call the .list_groups() function repeatedly -beginning on 0 until it returns non-zero to determine legal selectors, then -it will call the other functions to retrieve the name and pins of the group. -Maintaining the data structure of the groups is up to the driver, this is -just a simple example - in practice you may need more entries in your group -structure, for example specific register ranges associated with each group -and so on. +The pin control subsystem will call the .get_groups_count() function to +determine total number of legal selectors, then it will call the other functions +to retrieve the name and pins of the group. Maintaining the data structure of +the groups is up to the driver, this is just a simple example - in practice you +may need more entries in your group structure, for example specific register +ranges associated with each group and so on. Pin configuration @@ -606,11 +603,9 @@ static const struct foo_group foo_groups[] = { }; -static int foo_list_groups(struct pinctrl_dev *pctldev, unsigned selector) +static int foo_get_groups_count(struct pinctrl_dev *pctldev) { - if (selector >= ARRAY_SIZE(foo_groups)) - return -EINVAL; - return 0; + return ARRAY_SIZE(foo_groups); } static const char *foo_get_group_name(struct pinctrl_dev *pctldev, @@ -629,7 +624,7 @@ static int foo_get_group_pins(struct pinctrl_dev *pctldev, unsigned selector, } static struct pinctrl_ops foo_pctrl_ops = { - .list_groups = foo_list_groups, + .get_groups_count = foo_get_groups_count, .get_group_name = foo_get_group_name, .get_group_pins = foo_get_group_pins, }; @@ -640,7 +635,7 @@ struct foo_pmx_func { const unsigned num_groups; }; -static const char * const spi0_groups[] = { "spi0_1_grp" }; +static const char * const spi0_groups[] = { "spi0_0_grp", "spi0_1_grp" }; static const char * const i2c0_groups[] = { "i2c0_grp" }; static const char * const mmc0_groups[] = { "mmc0_1_grp", "mmc0_2_grp", "mmc0_3_grp" }; @@ -663,11 +658,9 @@ static const struct foo_pmx_func foo_functions[] = { }, }; -int foo_list_funcs(struct pinctrl_dev *pctldev, unsigned selector) +int foo_get_functions_count(struct pinctrl_dev *pctldev) { - if (selector >= ARRAY_SIZE(foo_functions)) - return -EINVAL; - return 0; + return ARRAY_SIZE(foo_functions); } const char *foo_get_fname(struct pinctrl_dev *pctldev, unsigned selector) @@ -703,7 +696,7 @@ void foo_disable(struct pinctrl_dev *pctldev, unsigned selector, } struct pinmux_ops foo_pmxops = { - .list_functions = foo_list_funcs, + .get_functions_count = foo_get_functions_count, .get_function_name = foo_get_fname, .get_function_groups = foo_get_groups, .enable = foo_enable, @@ -786,7 +779,7 @@ and spi on the second function mapping: #include <linux/pinctrl/machine.h> -static const struct pinctrl_map __initdata mapping[] = { +static const struct pinctrl_map mapping[] __initconst = { { .dev_name = "foo-spi.0", .name = PINCTRL_STATE_DEFAULT, @@ -952,13 +945,13 @@ case), we define a mapping like this: The result of grabbing this mapping from the device with something like this (see next paragraph): - p = pinctrl_get(dev); + p = devm_pinctrl_get(dev); s = pinctrl_lookup_state(p, "8bit"); ret = pinctrl_select_state(p, s); or more simply: - p = pinctrl_get_select(dev, "8bit"); + p = devm_pinctrl_get_select(dev, "8bit"); Will be that you activate all the three bottom records in the mapping at once. Since they share the same name, pin controller device, function and @@ -992,7 +985,7 @@ foo_probe() /* Allocate a state holder named "foo" etc */ struct foo_state *foo = ...; - foo->p = pinctrl_get(&device); + foo->p = devm_pinctrl_get(&device); if (IS_ERR(foo->p)) { /* FIXME: clean up "foo" here */ return PTR_ERR(foo->p); @@ -1000,24 +993,17 @@ foo_probe() foo->s = pinctrl_lookup_state(foo->p, PINCTRL_STATE_DEFAULT); if (IS_ERR(foo->s)) { - pinctrl_put(foo->p); /* FIXME: clean up "foo" here */ return PTR_ERR(s); } ret = pinctrl_select_state(foo->s); if (ret < 0) { - pinctrl_put(foo->p); /* FIXME: clean up "foo" here */ return ret; } } -foo_remove() -{ - pinctrl_put(state->p); -} - This get/lookup/select/put sequence can just as well be handled by bus drivers if you don't want each and every driver to handle it and you know the arrangement on your bus. @@ -1029,6 +1015,11 @@ The semantics of the pinctrl APIs are: kernel memory to hold the pinmux state. All mapping table parsing or similar slow operations take place within this API. +- devm_pinctrl_get() is a variant of pinctrl_get() that causes pinctrl_put() + to be called automatically on the retrieved pointer when the associated + device is removed. It is recommended to use this function over plain + pinctrl_get(). + - pinctrl_lookup_state() is called in process context to obtain a handle to a specific state for a the client device. This operation may be slow too. @@ -1041,14 +1032,30 @@ The semantics of the pinctrl APIs are: - pinctrl_put() frees all information associated with a pinctrl handle. +- devm_pinctrl_put() is a variant of pinctrl_put() that may be used to + explicitly destroy a pinctrl object returned by devm_pinctrl_get(). + However, use of this function will be rare, due to the automatic cleanup + that will occur even without calling it. + + pinctrl_get() must be paired with a plain pinctrl_put(). + pinctrl_get() may not be paired with devm_pinctrl_put(). + devm_pinctrl_get() can optionally be paired with devm_pinctrl_put(). + devm_pinctrl_get() may not be paired with plain pinctrl_put(). + Usually the pin control core handled the get/put pair and call out to the device drivers bookkeeping operations, like checking available functions and the associated pins, whereas the enable/disable pass on to the pin controller driver which takes care of activating and/or deactivating the mux setting by quickly poking some registers. -The pins are allocated for your device when you issue the pinctrl_get() call, -after this you should be able to see this in the debugfs listing of all pins. +The pins are allocated for your device when you issue the devm_pinctrl_get() +call, after this you should be able to see this in the debugfs listing of all +pins. + +NOTE: the pinctrl system will return -EPROBE_DEFER if it cannot find the +requested pinctrl handles, for example if the pinctrl driver has not yet +registered. Thus make sure that the error path in your driver gracefully +cleans up and is ready to retry the probing later in the startup process. System pin control hogging @@ -1094,13 +1101,13 @@ it, disables and releases it, and muxes it in on the pins defined by group B: #include <linux/pinctrl/consumer.h> -foo_switch() -{ - struct pinctrl *p; - struct pinctrl_state *s1, *s2; +struct pinctrl *p; +struct pinctrl_state *s1, *s2; +foo_probe() +{ /* Setup */ - p = pinctrl_get(&device); + p = devm_pinctrl_get(&device); if (IS_ERR(p)) ... @@ -1111,7 +1118,10 @@ foo_switch() s2 = pinctrl_lookup_state(foo->p, "pos-B"); if (IS_ERR(s2)) ... +} +foo_switch() +{ /* Enable on position A */ ret = pinctrl_select_state(s1); if (ret < 0) @@ -1125,8 +1135,6 @@ foo_switch() ... ... - - pinctrl_put(p); } The above has to be done from process context. diff --git a/Documentation/power/charger-manager.txt b/Documentation/power/charger-manager.txt index fdcca99..b4f7f4b 100644 --- a/Documentation/power/charger-manager.txt +++ b/Documentation/power/charger-manager.txt @@ -44,6 +44,16 @@ Charger Manager supports the following: Normally, the platform will need to resume and suspend some devices that are used by Charger Manager. +* Support for premature full-battery event handling + If the battery voltage drops by "fullbatt_vchkdrop_uV" after + "fullbatt_vchkdrop_ms" from the full-battery event, the framework + restarts charging. This check is also performed while suspended by + setting wakeup time accordingly and using suspend_again. + +* Support for uevent-notify + With the charger-related events, the device sends + notification to users with UEVENT. + 2. Global Charger-Manager Data related with suspend_again ======================================================== In order to setup Charger Manager with suspend-again feature @@ -55,7 +65,7 @@ if there are multiple batteries. If there are multiple batteries, the multiple instances of Charger Manager share the same charger_global_desc and it will manage in-suspend monitoring for all instances of Charger Manager. -The user needs to provide all the two entries properly in order to activate +The user needs to provide all the three entries properly in order to activate in-suspend monitoring: struct charger_global_desc { @@ -74,6 +84,11 @@ bool (*rtc_only_wakeup)(void); same struct. If there is any other wakeup source triggered the wakeup, it should return false. If the "rtc" is the only wakeup reason, it should return true. + +bool assume_timer_stops_in_suspend; + : if true, Charger Manager assumes that + the timer (CM uses jiffies as timer) stops during suspend. Then, CM + assumes that the suspend-duration is same as the alarm length. }; 3. How to setup suspend_again @@ -111,6 +126,16 @@ enum polling_modes polling_mode; CM_POLL_CHARGING_ONLY: poll this battery if and only if the battery is being charged. +unsigned int fullbatt_vchkdrop_ms; +unsigned int fullbatt_vchkdrop_uV; + : If both have non-zero values, Charger Manager will check the + battery voltage drop fullbatt_vchkdrop_ms after the battery is fully + charged. If the voltage drop is over fullbatt_vchkdrop_uV, Charger + Manager will try to recharge the battery by disabling and enabling + chargers. Recharge with voltage drop condition only (without delay + condition) is needed to be implemented with hardware interrupts from + fuel gauges or charger devices/chips. + unsigned int fullbatt_uV; : If specified with a non-zero value, Charger Manager assumes that the battery is full (capacity = 100) if the battery is not being @@ -122,6 +147,8 @@ unsigned int polling_interval_ms; this battery every polling_interval_ms or more frequently. enum data_source battery_present; + : CM_BATTERY_PRESENT: assume that the battery exists. + CM_NO_BATTERY: assume that the battery does not exists. CM_FUEL_GAUGE: get battery presence information from fuel gauge. CM_CHARGER_STAT: get battery presence from chargers. @@ -151,7 +178,17 @@ bool measure_battery_temp; the value of measure_battery_temp. }; -5. Other Considerations +5. Notify Charger-Manager of charger events: cm_notify_event() +========================================================= +If there is an charger event is required to notify +Charger Manager, a charger device driver that triggers the event can call +cm_notify_event(psy, type, msg) to notify the corresponding Charger Manager. +In the function, psy is the charger driver's power_supply pointer, which is +associated with Charger-Manager. The parameter "type" +is the same as irq's type (enum cm_event_types). The event message "msg" is +optional and is effective only if the event type is "UNDESCRIBED" or "OTHERS". + +6. Other Considerations ======================= At the charger/battery-related events such as battery-pulled-out, diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 872815c..504dfe4 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -583,9 +583,10 @@ for the given device during all power transitions, instead of the respective subsystem-level callbacks. Specifically, if a device's pm_domain pointer is not NULL, the ->suspend() callback from the object pointed to by it will be executed instead of its subsystem's (e.g. bus type's) ->suspend() callback and -anlogously for all of the remaining callbacks. In other words, power management -domain callbacks, if defined for the given device, always take precedence over -the callbacks provided by the device's subsystem (e.g. bus type). +analogously for all of the remaining callbacks. In other words, power +management domain callbacks, if defined for the given device, always take +precedence over the callbacks provided by the device's subsystem (e.g. bus +type). The support for device power management domains is only relevant to platforms needing to use the same device driver power management callbacks in many @@ -598,7 +599,7 @@ it into account in any way. Device Low Power (suspend) States --------------------------------- Device low-power states aren't standard. One device might only handle -"on" and "off, while another might support a dozen different versions of +"on" and "off", while another might support a dozen different versions of "on" (how many engines are active?), plus a state that gets back to "on" faster than from a full "off". diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt index 9f16c51..2f0ddc1 100644 --- a/Documentation/power/power_supply_class.txt +++ b/Documentation/power/power_supply_class.txt @@ -84,6 +84,8 @@ are already charged or discharging, 'n/a' can be displayed (or HEALTH - represents health of the battery, values corresponds to POWER_SUPPLY_HEALTH_*, defined in battery.h. +VOLTAGE_OCV - open circuit voltage of the battery. + VOLTAGE_MAX_DESIGN, VOLTAGE_MIN_DESIGN - design values for maximal and minimal power supply voltages. Maximal/minimal means values of voltages when battery considered "full"/"empty" at normal conditions. Yes, there is @@ -110,14 +112,24 @@ CHARGE_COUNTER - the current charge counter (in µAh). This could easily be negative; there is no empty or full value. It is only useful for relative, time-based measurements. +CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger. + +CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger. + ENERGY_FULL, ENERGY_EMPTY - same as above but for energy. CAPACITY - capacity in percents. +CAPACITY_ALERT_MIN - minimum capacity alert value in percents. +CAPACITY_ALERT_MAX - maximum capacity alert value in percents. CAPACITY_LEVEL - capacity level. This corresponds to POWER_SUPPLY_CAPACITY_LEVEL_*. TEMP - temperature of the power supply. +TEMP_ALERT_MIN - minimum battery temperature alert value in milli centigrade. +TEMP_ALERT_MAX - maximum battery temperature alert value in milli centigrade. TEMP_AMBIENT - ambient temperature. +TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert value in milli centigrade. +TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert value in milli centigrade. TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e. while battery powers a load) diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt index e272d99..1390277 100644 --- a/Documentation/power/regulator/regulator.txt +++ b/Documentation/power/regulator/regulator.txt @@ -11,8 +11,7 @@ Registration Drivers can register a regulator by calling :- struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc, - struct device *dev, struct regulator_init_data *init_data, - void *driver_data, struct device_node *of_node); + const struct regulator_config *config); This will register the regulators capabilities and operations to the regulator core. diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.txt index f28f9a6..e13dafc 100644 --- a/Documentation/power/suspend-and-cpuhotplug.txt +++ b/Documentation/power/suspend-and-cpuhotplug.txt @@ -29,7 +29,7 @@ More details follow: Write 'mem' to /sys/power/state - syfs file + sysfs file | v Acquire pm_mutex lock diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index ac190cf..92341b8 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt @@ -33,6 +33,11 @@ echo shutdown > /sys/power/disk; echo disk > /sys/power/state echo platform > /sys/power/disk; echo disk > /sys/power/state +. If you would like to write hibernation image to swap and then suspend +to RAM (provided your platform supports it), you can try + +echo suspend > /sys/power/disk; echo disk > /sys/power/state + . If you have SATA disks, you'll need recent kernels with SATA suspend support. For suspend and resume to work, make sure your disk drivers are built into kernel -- not modules. [There's way to make diff --git a/Documentation/prctl/no_new_privs.txt b/Documentation/prctl/no_new_privs.txt new file mode 100644 index 0000000..f7be84f --- /dev/null +++ b/Documentation/prctl/no_new_privs.txt @@ -0,0 +1,57 @@ +The execve system call can grant a newly-started program privileges that +its parent did not have. The most obvious examples are setuid/setgid +programs and file capabilities. To prevent the parent program from +gaining these privileges as well, the kernel and user code must be +careful to prevent the parent from doing anything that could subvert the +child. For example: + + - The dynamic loader handles LD_* environment variables differently if + a program is setuid. + + - chroot is disallowed to unprivileged processes, since it would allow + /etc/passwd to be replaced from the point of view of a process that + inherited chroot. + + - The exec code has special handling for ptrace. + +These are all ad-hoc fixes. The no_new_privs bit (since Linux 3.5) is a +new, generic mechanism to make it safe for a process to modify its +execution environment in a manner that persists across execve. Any task +can set no_new_privs. Once the bit is set, it is inherited across fork, +clone, and execve and cannot be unset. With no_new_privs set, execve +promises not to grant the privilege to do anything that could not have +been done without the execve call. For example, the setuid and setgid +bits will no longer change the uid or gid; file capabilities will not +add to the permitted set, and LSMs will not relax constraints after +execve. + +To set no_new_privs, use prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0). + +Be careful, though: LSMs might also not tighten constraints on exec +in no_new_privs mode. (This means that setting up a general-purpose +service launcher to set no_new_privs before execing daemons may +interfere with LSM-based sandboxing.) + +Note that no_new_privs does not prevent privilege changes that do not +involve execve. An appropriately privileged task can still call +setuid(2) and receive SCM_RIGHTS datagrams. + +There are two main use cases for no_new_privs so far: + + - Filters installed for the seccomp mode 2 sandbox persist across + execve and can change the behavior of newly-executed programs. + Unprivileged users are therefore only allowed to install such filters + if no_new_privs is set. + + - By itself, no_new_privs can be used to reduce the attack surface + available to an unprivileged user. If everything running with a + given uid has no_new_privs set, then that uid will be unable to + escalate its privileges by directly attacking setuid, setgid, and + fcap-using binaries; it will need to compromise something without the + no_new_privs bit set first. + +In the future, other potentially dangerous kernel features could become +available to unprivileged tasks if no_new_privs is set. In principle, +several options to unshare(2) and clone(2) would be safe when +no_new_privs is set, and no_new_privs + chroot is considerable less +dangerous than chroot by itself. diff --git a/Documentation/prctl/seccomp_filter.txt b/Documentation/prctl/seccomp_filter.txt new file mode 100644 index 0000000..597c3c5 --- /dev/null +++ b/Documentation/prctl/seccomp_filter.txt @@ -0,0 +1,163 @@ + SECure COMPuting with filters + ============================= + +Introduction +------------ + +A large number of system calls are exposed to every userland process +with many of them going unused for the entire lifetime of the process. +As system calls change and mature, bugs are found and eradicated. A +certain subset of userland applications benefit by having a reduced set +of available system calls. The resulting set reduces the total kernel +surface exposed to the application. System call filtering is meant for +use with those applications. + +Seccomp filtering provides a means for a process to specify a filter for +incoming system calls. The filter is expressed as a Berkeley Packet +Filter (BPF) program, as with socket filters, except that the data +operated on is related to the system call being made: system call +number and the system call arguments. This allows for expressive +filtering of system calls using a filter program language with a long +history of being exposed to userland and a straightforward data set. + +Additionally, BPF makes it impossible for users of seccomp to fall prey +to time-of-check-time-of-use (TOCTOU) attacks that are common in system +call interposition frameworks. BPF programs may not dereference +pointers which constrains all filters to solely evaluating the system +call arguments directly. + +What it isn't +------------- + +System call filtering isn't a sandbox. It provides a clearly defined +mechanism for minimizing the exposed kernel surface. It is meant to be +a tool for sandbox developers to use. Beyond that, policy for logical +behavior and information flow should be managed with a combination of +other system hardening techniques and, potentially, an LSM of your +choosing. Expressive, dynamic filters provide further options down this +path (avoiding pathological sizes or selecting which of the multiplexed +system calls in socketcall() is allowed, for instance) which could be +construed, incorrectly, as a more complete sandboxing solution. + +Usage +----- + +An additional seccomp mode is added and is enabled using the same +prctl(2) call as the strict seccomp. If the architecture has +CONFIG_HAVE_ARCH_SECCOMP_FILTER, then filters may be added as below: + +PR_SET_SECCOMP: + Now takes an additional argument which specifies a new filter + using a BPF program. + The BPF program will be executed over struct seccomp_data + reflecting the system call number, arguments, and other + metadata. The BPF program must then return one of the + acceptable values to inform the kernel which action should be + taken. + + Usage: + prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, prog); + + The 'prog' argument is a pointer to a struct sock_fprog which + will contain the filter program. If the program is invalid, the + call will return -1 and set errno to EINVAL. + + If fork/clone and execve are allowed by @prog, any child + processes will be constrained to the same filters and system + call ABI as the parent. + + Prior to use, the task must call prctl(PR_SET_NO_NEW_PRIVS, 1) or + run with CAP_SYS_ADMIN privileges in its namespace. If these are not + true, -EACCES will be returned. This requirement ensures that filter + programs cannot be applied to child processes with greater privileges + than the task that installed them. + + Additionally, if prctl(2) is allowed by the attached filter, + additional filters may be layered on which will increase evaluation + time, but allow for further decreasing the attack surface during + execution of a process. + +The above call returns 0 on success and non-zero on error. + +Return values +------------- +A seccomp filter may return any of the following values. If multiple +filters exist, the return value for the evaluation of a given system +call will always use the highest precedent value. (For example, +SECCOMP_RET_KILL will always take precedence.) + +In precedence order, they are: + +SECCOMP_RET_KILL: + Results in the task exiting immediately without executing the + system call. The exit status of the task (status & 0x7f) will + be SIGSYS, not SIGKILL. + +SECCOMP_RET_TRAP: + Results in the kernel sending a SIGSYS signal to the triggering + task without executing the system call. The kernel will + rollback the register state to just before the system call + entry such that a signal handler in the task will be able to + inspect the ucontext_t->uc_mcontext registers and emulate + system call success or failure upon return from the signal + handler. + + The SECCOMP_RET_DATA portion of the return value will be passed + as si_errno. + + SIGSYS triggered by seccomp will have a si_code of SYS_SECCOMP. + +SECCOMP_RET_ERRNO: + Results in the lower 16-bits of the return value being passed + to userland as the errno without executing the system call. + +SECCOMP_RET_TRACE: + When returned, this value will cause the kernel to attempt to + notify a ptrace()-based tracer prior to executing the system + call. If there is no tracer present, -ENOSYS is returned to + userland and the system call is not executed. + + A tracer will be notified if it requests PTRACE_O_TRACESECCOMP + using ptrace(PTRACE_SETOPTIONS). The tracer will be notified + of a PTRACE_EVENT_SECCOMP and the SECCOMP_RET_DATA portion of + the BPF program return value will be available to the tracer + via PTRACE_GETEVENTMSG. + +SECCOMP_RET_ALLOW: + Results in the system call being executed. + +If multiple filters exist, the return value for the evaluation of a +given system call will always use the highest precedent value. + +Precedence is only determined using the SECCOMP_RET_ACTION mask. When +multiple filters return values of the same precedence, only the +SECCOMP_RET_DATA from the most recently installed filter will be +returned. + +Pitfalls +-------- + +The biggest pitfall to avoid during use is filtering on system call +number without checking the architecture value. Why? On any +architecture that supports multiple system call invocation conventions, +the system call numbers may vary based on the specific invocation. If +the numbers in the different calling conventions overlap, then checks in +the filters may be abused. Always check the arch value! + +Example +------- + +The samples/seccomp/ directory contains both an x86-specific example +and a more generic example of a higher level macro interface for BPF +program generation. + + + +Adding architecture support +----------------------- + +See arch/Kconfig for the authoritative requirements. In general, if an +architecture supports both ptrace_event and seccomp, it will be able to +support seccomp filter with minor fixup: SIGSYS support and seccomp return +value checking. Then it must just add CONFIG_HAVE_ARCH_SECCOMP_FILTER +to its arch-specific Kconfig. diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 5df176e..7561d7e 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt @@ -53,9 +53,20 @@ Struct Resources: For printing struct resources. The 'R' and 'r' specifiers result in a printed resource with ('R') or without ('r') a decoded flags member. +Raw buffer as a hex string: + %*ph 00 01 02 ... 3f + %*phC 00:01:02: ... :3f + %*phD 00-01-02- ... -3f + %*phN 000102 ... 3f + + For printing a small buffers (up to 64 bytes long) as a hex string with + certain separator. For the larger buffers consider to use + print_hex_dump(). + MAC/FDDI addresses: %pM 00:01:02:03:04:05 + %pMR 05:04:03:02:01:00 %pMF 00-01-02-03-04-05 %pm 000102030405 @@ -67,6 +78,10 @@ MAC/FDDI addresses: the 'M' specifier to use dash ('-') separators instead of the default separator. + For Bluetooth addresses the 'R' specifier shall be used after the 'M' + specifier to use reversed byte order suitable for visual interpretation + of Bluetooth addresses which are in the little endian order. + IPv4 addresses: %pI4 1.2.3.4 diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt new file mode 100644 index 0000000..554290e --- /dev/null +++ b/Documentation/pwm.txt @@ -0,0 +1,76 @@ +Pulse Width Modulation (PWM) interface + +This provides an overview about the Linux PWM interface + +PWMs are commonly used for controlling LEDs, fans or vibrators in +cell phones. PWMs with a fixed purpose have no need implementing +the Linux PWM API (although they could). However, PWMs are often +found as discrete devices on SoCs which have no fixed purpose. It's +up to the board designer to connect them to LEDs or fans. To provide +this kind of flexibility the generic PWM API exists. + +Identifying PWMs +---------------- + +Users of the legacy PWM API use unique IDs to refer to PWM devices. + +Instead of referring to a PWM device via its unique ID, board setup code +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), + }; + + static void __init board_init(void) + { + ... + pwm_add_table(board_pwm_lookup, ARRAY_SIZE(board_pwm_lookup)); + ... + } + +Using PWMs +---------- + +Legacy users can request a PWM device using pwm_request() and free it +after usage with pwm_free(). + +New users should use the pwm_get() function and pass to it the consumer +device or a consumer name. pwm_put() is used to free the PWM device. + +After being requested a PWM has to be configured using: + +int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns); + +To start/stop toggling the PWM output use pwm_enable()/pwm_disable(). + +Implementing a PWM driver +------------------------- + +Currently there are two ways to implement pwm drivers. Traditionally +there only has been the barebone API meaning that each driver has +to implement the pwm_*() functions itself. This means that it's impossible +to have multiple PWM drivers in the system. For this reason it's mandatory +for new drivers to use the generic PWM framework. + +A new PWM controller/chip can be added using pwmchip_add() and removed +again with pwmchip_remove(). pwmchip_add() takes a filled in struct +pwm_chip as argument which provides a description of the PWM chip, the +number of PWM devices provider by the chip and the chip-specific +implementation of the supported PWM operations to the framework. + +Locking +------- + +The PWM core list manipulations are protected by a mutex, so pwm_request() +and pwm_free() may not be called from an atomic context. Currently the +PWM core does not enforce any locking to pwm_enable(), pwm_disable() and +pwm_config(), so the calling context is currently driver specific. This +is an issue derived from the former barebone API and should be fixed soon. + +Helpers +------- + +Currently a PWM can only be configured with period_ns and duty_ns. For several +use cases freq_hz and duty_percent might be better. Instead of calculating +this in your driver please consider adding appropriate helpers to the framework. diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt index 8fb1ba7..197ad59 100644 --- a/Documentation/ramoops.txt +++ b/Documentation/ramoops.txt @@ -3,7 +3,7 @@ Ramoops oops/panic logger Sergiu Iordache <sergiu@chromium.org> -Updated: 8 August 2011 +Updated: 17 November 2011 0. Introduction @@ -30,15 +30,26 @@ variable while setting 0 in that variable dumps only the panics. The module uses a counter to record multiple dumps but the counter gets reset on restart (i.e. new dumps after the restart will overwrite old ones). +Ramoops also supports software ECC protection of persistent memory regions. +This might be useful when a hardware reset was used to bring the machine back +to life (i.e. a watchdog triggered). In such cases, RAM may be somewhat +corrupt, but usually it is restorable. + 2. Setting the parameters Setting the ramoops parameters can be done in 2 different manners: 1. Use the module parameters (which have the names of the variables described as before). + For quick debugging, you can also reserve parts of memory during boot + and then use the reserved memory for ramoops. For example, assuming a machine + with > 128 MB of memory, the following kernel command line will tell the + kernel to use only the first 128 MB of memory, and place ECC-protected ramoops + region at 128 MB boundary: + "mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1" 2. Use a platform device and set the platform data. The parameters can then be set through that platform data. An example of doing that is: -#include <linux/ramoops.h> +#include <linux/pstore_ram.h> [...] static struct ramoops_platform_data ramoops_data = { @@ -46,6 +57,7 @@ static struct ramoops_platform_data ramoops_data = { .mem_address = <...>, .record_size = <...>, .dump_oops = <...>, + .ecc = <...>, }; static struct platform_device ramoops_dev = { @@ -64,6 +76,14 @@ if (ret) { return ret; } +You can specify either RAM memory or peripheral devices' memory. However, when +specifying RAM, be sure to reserve the memory by issuing memblock_reserve() +very early in the architecture code, e.g.: + +#include <linux/memblock.h> + +memblock_reserve(ramoops_data.mem_address, ramoops_data.mem_size); + 3. Dump format The data dump begins with a header, currently defined as "====" followed by a @@ -71,6 +91,31 @@ timestamp and a new line. The dump then continues with the actual data. 4. Reading the data -The dump data can be read from memory (through /dev/mem or other means). -Getting the module parameters, which are needed in order to parse the data, can -be done through /sys/module/ramoops/parameters/* . +The dump data can be read from the pstore filesystem. The format for these +files is "dmesg-ramoops-N", where N is the record number in memory. To delete +a stored record from RAM, simply unlink the respective pstore file. + +5. Persistent function tracing + +Persistent function tracing might be useful for debugging software or hardware +related hangs. The functions call chain log is stored in a "ftrace-ramoops" +file. Here is an example of usage: + + # mount -t debugfs debugfs /sys/kernel/debug/ + # cd /sys/kernel/debug/tracing + # echo function > current_tracer + # echo 1 > options/func_pstore + # reboot -f + [...] + # mount -t pstore pstore /mnt/ + # tail /mnt/ftrace-ramoops + 0 ffffffff8101ea64 ffffffff8101bcda native_apic_mem_read <- disconnect_bsp_APIC+0x6a/0xc0 + 0 ffffffff8101ea44 ffffffff8101bcf6 native_apic_mem_write <- disconnect_bsp_APIC+0x86/0xc0 + 0 ffffffff81020084 ffffffff8101a4b5 hpet_disable <- native_machine_shutdown+0x75/0x90 + 0 ffffffff81005f94 ffffffff8101a4bb iommu_shutdown_noop <- native_machine_shutdown+0x7b/0x90 + 0 ffffffff8101a6a1 ffffffff8101a437 native_machine_emergency_restart <- native_machine_restart+0x37/0x40 + 0 ffffffff811f9876 ffffffff8101a73a acpi_reboot <- native_machine_emergency_restart+0xaa/0x1e0 + 0 ffffffff8101a514 ffffffff8101a772 mach_reboot_fixups <- native_machine_emergency_restart+0xe2/0x1e0 + 0 ffffffff811d9c54 ffffffff8101a7a0 __const_udelay <- native_machine_emergency_restart+0x110/0x1e0 + 0 ffffffff811d9c34 ffffffff811d9c80 __delay <- __const_udelay+0x30/0x40 + 0 ffffffff811d9d14 ffffffff811d9c3f delay_tsc <- __delay+0xf/0x20 diff --git a/Documentation/remoteproc.txt b/Documentation/remoteproc.txt index 70a048c..23a09b8 100644 --- a/Documentation/remoteproc.txt +++ b/Documentation/remoteproc.txt @@ -36,8 +36,7 @@ cost. Note: to use this function you should already have a valid rproc handle. There are several ways to achieve that cleanly (devres, pdata, the way remoteproc_rpmsg.c does this, or, if this becomes prevalent, we - might also consider using dev_archdata for this). See also - rproc_get_by_name() below. + might also consider using dev_archdata for this). void rproc_shutdown(struct rproc *rproc) - Power off a remote processor (previously booted with rproc_boot()). @@ -51,30 +50,6 @@ cost. which means that the @rproc handle stays valid even after rproc_shutdown() returns, and users can still use it with a subsequent rproc_boot(), if needed. - - don't call rproc_shutdown() to unroll rproc_get_by_name(), exactly - because rproc_shutdown() _does not_ decrement the refcount of @rproc. - To decrement the refcount of @rproc, use rproc_put() (but _only_ if - you acquired @rproc using rproc_get_by_name()). - - struct rproc *rproc_get_by_name(const char *name) - - Find an rproc handle using the remote processor's name, and then - boot it. If it's already powered on, then just immediately return - (successfully). Returns the rproc handle on success, and NULL on failure. - This function increments the remote processor's refcount, so always - use rproc_put() to decrement it back once rproc isn't needed anymore. - Note: currently rproc_get_by_name() and rproc_put() are not used anymore - by the rpmsg bus and its drivers. We need to scrutinize the use cases - that still need them, and see if we can migrate them to use the non - name-based boot/shutdown interface. - - void rproc_put(struct rproc *rproc) - - Decrement @rproc's power refcount and shut it down if it reaches zero - (essentially by just calling rproc_shutdown), and then decrement @rproc's - validity refcount too. - After this function returns, @rproc may _not_ be used anymore, and its - handle should be considered invalid. - This function should be called _iff_ the @rproc handle was grabbed by - calling rproc_get_by_name(). 3. Typical usage @@ -115,21 +90,21 @@ int dummy_rproc_example(struct rproc *my_rproc) This function should be used by rproc implementations during initialization of the remote processor. After creating an rproc handle using this function, and when ready, - implementations should then call rproc_register() to complete + implementations should then call rproc_add() to complete the registration of the remote processor. On success, the new rproc is returned, and on failure, NULL. Note: _never_ directly deallocate @rproc, even if it was not registered - yet. Instead, if you just need to unroll rproc_alloc(), use rproc_free(). + yet. Instead, when you need to unroll rproc_alloc(), use rproc_put(). - void rproc_free(struct rproc *rproc) + void rproc_put(struct rproc *rproc) - Free an rproc handle that was allocated by rproc_alloc. - This function should _only_ be used if @rproc was only allocated, - but not registered yet. - If @rproc was already successfully registered (by calling - rproc_register()), then use rproc_unregister() instead. + This function essentially unrolls rproc_alloc(), by decrementing the + rproc's refcount. It doesn't directly free rproc; that would happen + only if there are no other references to rproc and its refcount now + dropped to zero. - int rproc_register(struct rproc *rproc) + int rproc_add(struct rproc *rproc) - Register @rproc with the remoteproc framework, after it has been allocated with rproc_alloc(). This is called by the platform-specific rproc implementation, whenever @@ -142,20 +117,15 @@ int dummy_rproc_example(struct rproc *my_rproc) of registering this remote processor, additional virtio drivers might get probed. - int rproc_unregister(struct rproc *rproc) - - Unregister a remote processor, and decrement its refcount. - If its refcount drops to zero, then @rproc will be freed. If not, - it will be freed later once the last reference is dropped. - + int rproc_del(struct rproc *rproc) + - Unroll rproc_add(). This function should be called when the platform specific rproc implementation decides to remove the rproc device. it should - _only_ be called if a previous invocation of rproc_register() + _only_ be called if a previous invocation of rproc_add() has completed successfully. - After rproc_unregister() returns, @rproc is _not_ valid anymore and - it shouldn't be used. More specifically, don't call rproc_free() - or try to directly free @rproc after rproc_unregister() returns; - none of these are needed, and calling them is a bug. + After rproc_del() returns, @rproc is still valid, and its + last refcount should be decremented by calling rproc_put(). Returns 0 on success and -EINVAL if @rproc isn't valid. diff --git a/Documentation/scheduler/sched-design-CFS.txt b/Documentation/scheduler/sched-design-CFS.txt index 91ecff0..d529e02d 100644 --- a/Documentation/scheduler/sched-design-CFS.txt +++ b/Documentation/scheduler/sched-design-CFS.txt @@ -130,7 +130,7 @@ CFS implements three scheduling policies: idle timer scheduler in order to avoid to get into priority inversion problems which would deadlock the machine. -SCHED_FIFO/_RR are implemented in sched_rt.c and are as specified by +SCHED_FIFO/_RR are implemented in sched/rt.c and are as specified by POSIX. The command chrt from util-linux-ng 2.13.1.1 can set all of these except @@ -145,9 +145,9 @@ Classes," an extensible hierarchy of scheduler modules. These modules encapsulate scheduling policy details and are handled by the scheduler core without the core code assuming too much about them. -sched_fair.c implements the CFS scheduler described above. +sched/fair.c implements the CFS scheduler described above. -sched_rt.c implements SCHED_FIFO and SCHED_RR semantics, in a simpler way than +sched/rt.c implements SCHED_FIFO and SCHED_RR semantics, in a simpler way than the previous vanilla scheduler did. It uses 100 runqueues (for all 100 RT priority levels, instead of 140 in the previous scheduler) and it needs no expired array. diff --git a/Documentation/scheduler/sched-domains.txt b/Documentation/scheduler/sched-domains.txt index b7ee379..443f0c7 100644 --- a/Documentation/scheduler/sched-domains.txt +++ b/Documentation/scheduler/sched-domains.txt @@ -61,10 +61,6 @@ The implementor should read comments in include/linux/sched.h: struct sched_domain fields, SD_FLAG_*, SD_*_INIT to get an idea of the specifics and what to tune. -For SMT, the architecture must define CONFIG_SCHED_SMT and provide a -cpumask_t cpu_sibling_map[NR_CPUS], where cpu_sibling_map[i] is the mask of -all "i"'s siblings as well as "i" itself. - Architectures may retain the regular override the default SD_*_INIT flags while using the generic domain builder in kernel/sched.c if they wish to retain the traditional SMT->SMP->NUMA topology (or some subset of that). This diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX index b7dd650..9b0787f 100644 --- a/Documentation/scsi/00-INDEX +++ b/Documentation/scsi/00-INDEX @@ -56,8 +56,6 @@ g_NCR5380.txt - info on driver for NCR5380 and NCR53c400 based adapters hptiop.txt - HIGHPOINT ROCKETRAID 3xxx RAID DRIVER -ibmmca.txt - - info on driver for IBM adapters with MCA bus in2000.txt - info on in2000 driver libsas.txt diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 83f8ea8..80441ab 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,11 @@ +Release Date : Mon. Mar 19, 2012 17:00:00 PST 2012 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 00.00.06.15-rc1 +Old Version : 00.00.06.14-rc1 + 1. Optimize HostMSIxVectors setting. + 2. Add fpRead/WriteCapable, fpRead/WriteAcrossStripe checks. +------------------------------------------------------------------------------- Release Date : Fri. Jan 6, 2012 17:00:00 PST 2010 - (emaild-id:megaraidlinux@lsi.com) Adam Radford diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt deleted file mode 100644 index ac41a9f..0000000 --- a/Documentation/scsi/ibmmca.txt +++ /dev/null @@ -1,1402 +0,0 @@ - - -=< The IBM Microchannel SCSI-Subsystem >=- - - for the IBM PS/2 series - - Low Level Software-Driver for Linux - - Copyright (c) 1995 Strom Systems, Inc. under the terms of the GNU - General Public License. Originally written by Martin Kolinek, December 1995. - Officially modified and maintained by Michael Lang since January 1999. - - Version 4.0a - - Last update: January 3, 2001 - - Before you Start - ---------------- - This is the common README.ibmmca file for all driver releases of the - IBM MCA SCSI driver for Linux. Please note, that driver releases 4.0 - or newer do not work with kernel versions older than 2.4.0, while driver - versions older than 4.0 do not work with kernels 2.4.0 or later! If you - try to compile your kernel with the wrong driver source, the - compilation is aborted and you get a corresponding error message. This is - no bug in the driver; it prevents you from using the wrong source code - with the wrong kernel version. - - Authors of this Driver - ---------------------- - - Chris Beauregard (improvement of the SCSI-device mapping by the driver) - - Martin Kolinek (origin, first release of this driver) - - Klaus Kudielka (multiple SCSI-host management/detection, adaption to - Linux Kernel 2.1.x, module support) - - Michael Lang (assigning original pun/lun mapping, dynamical ldn - assignment, rewritten adapter detection, this file, - patches, official driver maintenance and subsequent - debugging, related with the driver) - - Table of Contents - ----------------- - 1 Abstract - 2 Driver Description - 2.1 IBM SCSI-Subsystem Detection - 2.2 Physical Units, Logical Units, and Logical Devices - 2.3 SCSI-Device Recognition and dynamical ldn Assignment - 2.4 SCSI-Device Order - 2.5 Regular SCSI-Command-Processing - 2.6 Abort & Reset Commands - 2.7 Disk Geometry - 2.8 Kernel Boot Option - 2.9 Driver Module Support - 2.10 Multiple Hostadapter Support - 2.11 /proc/scsi-Filesystem Information - 2.12 /proc/mca-Filesystem Information - 2.13 Supported IBM SCSI-Subsystems - 2.14 Linux Kernel Versions - 3 Code History - 4 To do - 5 Users' Manual - 5.1 Commandline Parameters - 5.2 Troubleshooting - 5.3 Bug reports - 5.4 Support WWW-page - 6 References - 7 Credits to - 7.1 People - 7.2 Sponsors & Supporters - 8 Trademarks - 9 Disclaimer - - * * * - - 1 Abstract - ---------- - This README-file describes the IBM SCSI-subsystem low level driver for - Linux. The descriptions which were formerly kept in the source code have - been taken out of this file to simplify the codes readability. The driver - description has been updated, as most of the former description was already - quite outdated. The history of the driver development is also kept inside - here. Multiple historical developments have been summarized to shorten the - text size a bit. At the end of this file you can find a small manual for - this driver and hints to get it running on your machine. - - 2 Driver Description - -------------------- - 2.1 IBM SCSI-Subsystem Detection - -------------------------------- - This is done in the ibmmca_detect() function. It first checks, if the - Microchannel-bus support is enabled, as the IBM SCSI-subsystem needs the - Microchannel. In a next step, a free interrupt is chosen and the main - interrupt handler is connected to it to handle answers of the SCSI- - subsystem(s). If the F/W SCSI-adapter is forced by the BIOS to use IRQ11 - instead of IRQ14, IRQ11 is used for the IBM SCSI-2 F/W adapter. In a - further step it is checked, if the adapter gets detected by force from - the kernel commandline, where the I/O port and the SCSI-subsystem id can - be specified. The next step checks if there is an integrated SCSI-subsystem - installed. This register area is fixed through all IBM PS/2 MCA-machines - and appears as something like a virtual slot 10 of the MCA-bus. On most - PS/2 machines, the POS registers of slot 10 are set to 0xff or 0x00 if not - integrated SCSI-controller is available. But on certain PS/2s, like model - 9595, this slot 10 is used to store other information which at earlier - stage confused the driver and resulted in the detection of some ghost-SCSI. - If POS-register 2 and 3 are not 0x00 and not 0xff, but all other POS - registers are either 0xff or 0x00, there must be an integrated SCSI- - subsystem present and it will be registered as IBM Integrated SCSI- - Subsystem. The next step checks, if there is a slot-adapter installed on - the MCA-bus. To get this, the first two POS-registers, that represent the - adapter ID are checked. If they fit to one of the ids, stored in the - adapter list, a SCSI-subsystem is assumed to be found in a slot and will be - registered. This check is done through all possible MCA-bus slots to allow - more than one SCSI-adapter to be present in the PS/2-system and this is - already the first point of problems. Looking into the technical reference - manual for the IBM PS/2 common interfaces, the POS2 register must have - different interpretation of its single bits to avoid overlapping I/O - regions. While one can assume, that the integrated subsystem has a fix - I/O-address at 0x3540 - 0x3547, further installed IBM SCSI-adapters must - use a different I/O-address. This is expressed by bit 1 to 3 of POS2 - (multiplied by 8 + 0x3540). Bits 2 and 3 are reserved for the integrated - subsystem, but not for the adapters! The following list shows, how the - bits of POS2 and POS3 should be interpreted. - - The POS2-register of all PS/2 models' integrated SCSI-subsystems has the - following interpretation of bits: - Bit 7 - 4 : Chip Revision ID (Release) - Bit 3 - 2 : Reserved - Bit 1 : 8k NVRAM Disabled - Bit 0 : Chip Enable (EN-Signal) - The POS3-register is interpreted as follows (for most IBM SCSI-subsys.): - Bit 7 - 5 : SCSI ID - Bit 4 - 0 : Reserved = 0 - The slot-adapters have different interpretation of these bits. The IBM SCSI - adapter (w/Cache) and the IBM SCSI-2 F/W adapter use the following - interpretation of the POS2 register: - Bit 7 - 4 : ROM Segment Address Select - Bit 3 - 1 : Adapter I/O Address Select (*8+0x3540) - Bit 0 : Adapter Enable (EN-Signal) - and for the POS3 register: - Bit 7 - 5 : SCSI ID - Bit 4 : Fairness Enable (SCSI ID3 f. F/W) - Bit 3 - 0 : Arbitration Level - The most modern product of the series is the IBM SCSI-2 F/W adapter, it - allows dual-bus SCSI and SCSI-wide addressing, which means, PUNs may be - between 0 and 15. Here, Bit 4 is the high-order bit of the 4-bit wide - adapter PUN expression. In short words, this means, that IBM PS/2 machines - can only support 1 single integrated subsystem by default. Additional - slot-adapters get ports assigned by the automatic configuration tool. - - One day I found a patch in ibmmca_detect(), forcing the I/O-address to be - 0x3540 for integrated SCSI-subsystems, there was a remark placed, that on - integrated IBM SCSI-subsystems of model 56, the POS2 register was showing 5. - This means, that really for these models, POS2 has to be interpreted - sticking to the technical reference guide. In this case, the bit 2 (4) is - a reserved bit and may not be interpreted. These differences between the - adapters and the integrated controllers are taken into account by the - detection routine of the driver on from version >3.0g. - - Every time, a SCSI-subsystem is discovered, the ibmmca_register() function - is called. This function checks first, if the requested area for the I/O- - address of this SCSI-subsystem is still available and assigns this I/O- - area to the SCSI-subsystem. There are always 8 sequential I/O-addresses - taken for each individual SCSI-subsystem found, which are: - - Offset Type Permissions - 0 Command Interface Register 1 Read/Write - 1 Command Interface Register 2 Read/Write - 2 Command Interface Register 3 Read/Write - 3 Command Interface Register 4 Read/Write - 4 Attention Register Read/Write - 5 Basic Control Register Read/Write - 6 Interrupt Status Register Read - 7 Basic Status Register Read - - After the I/O-address range is assigned, the host-adapter is assigned - to a local structure which keeps all adapter information needed for the - driver itself and the mid- and higher-level SCSI-drivers. The SCSI pun/lun - and the adapters' ldn tables are initialized and get probed afterwards by - the check_devices() function. If no further adapters are found, - ibmmca_detect() quits. - - 2.2 Physical Units, Logical Units, and Logical Devices - ------------------------------------------------------ - There can be up to 56 devices on the SCSI bus (besides the adapter): - there are up to 7 "physical units" (each identified by physical unit - number or pun, also called the scsi id, this is the number you select - with hardware jumpers), and each physical unit can have up to 8 - "logical units" (each identified by logical unit number, or lun, - between 0 and 7). The IBM SCSI-2 F/W adapter offers this on up to two - busses and provides support for 30 logical devices at the same time, where - in wide-addressing mode you can have 16 puns with 32 luns on each device. - This section describes the handling of devices on non-F/W adapters. - Just imagine, that you can have 16 * 32 = 512 devices on a F/W adapter - which means a lot of possible devices for such a small machine. - - Typically the adapter has pun=7, so puns of other physical units - are between 0 and 6(15). On a wide-adapter a pun higher than 7 is - possible, but is normally not used. Almost all physical units have only - one logical unit, with lun=0. A CD-ROM jukebox would be an example of a - physical unit with more than one logical unit. - - The embedded microprocessor of the IBM SCSI-subsystem hides the complex - two-dimensional (pun,lun) organization from the operating system. - When the machine is powered-up (or rebooted), the embedded microprocessor - checks, on its own, all 56 possible (pun,lun) combinations, and the first - 15 devices found are assigned into a one-dimensional array of so-called - "logical devices", identified by "logical device numbers" or ldn. The last - ldn=15 is reserved for the subsystem itself. Wide adapters may have - to check up to 15 * 8 = 120 pun/lun combinations. - - 2.3 SCSI-Device Recognition and Dynamical ldn Assignment - -------------------------------------------------------- - One consequence of information hiding is that the real (pun,lun) - numbers are also hidden. The two possibilities to get around this problem - are to offer fake pun/lun combinations to the operating system or to - delete the whole mapping of the adapter and to reassign the ldns, using - the immediate assign command of the SCSI-subsystem for probing through - all possible pun/lun combinations. An ldn is a "logical device number" - which is used by IBM SCSI-subsystems to access some valid SCSI-device. - At the beginning of the development of this driver, the following approach - was used: - - First, the driver checked the ldn's (0 to 6) to find out which ldn's - have devices assigned. This was done by the functions check_devices() and - device_exists(). The interrupt handler has a special paragraph of code - (see local_checking_phase_flag) to assist in the checking. Assume, for - example, that three logical devices were found assigned at ldn 0, 1, 2. - These are presented to the upper layer of Linux SCSI driver - as devices with bogus (pun, lun) equal to (0,0), (1,0), (2,0). - On the other hand, if the upper layer issues a command to device - say (4,0), this driver returns DID_NO_CONNECT error. - - In a second step of the driver development, the following improvement has - been applied: The first approach limited the number of devices to 7, far - fewer than the 15 that it could use, then it just mapped ldn -> - (ldn/8,ldn%8) for pun,lun. We ended up with a real mishmash of puns - and luns, but it all seemed to work. - - The latest development, which is implemented from the driver version 3.0 - and later, realizes the device recognition in the following way: - The physical SCSI-devices on the SCSI-bus are probed via immediate_assign- - and device_inquiry-commands, that is all implemented in a completely new - made check_devices() subroutine. This delivers an exact map of the physical - SCSI-world that is now stored in the get_scsi[][]-array. This means, - that the once hidden pun,lun assignment is now known to this driver. - It no longer believes in default-settings of the subsystem and maps all - ldns to existing pun,lun "by foot". This assures full control of the ldn - mapping and allows dynamical remapping of ldns to different pun,lun, if - there are more SCSI-devices installed than ldns available (n>15). The - ldns from 0 to 6 get 'hardwired' by this driver to puns 0 to 7 at lun=0, - excluding the pun of the subsystem. This assures, that at least simple - SCSI-installations have optimum access-speed and are not touched by - dynamical remapping. The ldns 7 to 14 are put to existing devices with - lun>0 or to non-existing devices, in order to satisfy the subsystem, if - there are less than 15 SCSI-devices connected. In the case of more than 15 - devices, the dynamical mapping goes active. If the get_scsi[][] reports a - device to be existent, but it has no ldn assigned, it gets an ldn out of 7 - to 14. The numbers are assigned in cyclic order, therefore it takes 8 - dynamical reassignments on the SCSI-devices until a certain device - loses its ldn again. This assures that dynamical remapping is avoided - during intense I/O between up to 15 SCSI-devices (means pun,lun - combinations). A further advantage of this method is that people who - build their kernel without probing on all luns will get what they expect, - because the driver just won't assign everything with lun>0 when - multiple lun probing is inactive. - - 2.4 SCSI-Device Order - --------------------- - Because of the now correct recognition of physical pun,lun, and - their report to mid-level- and higher-level-drivers, the new reported puns - can be different from the old, faked puns. Therefore, Linux will eventually - change /dev/sdXXX assignments and prompt you for corrupted superblock - repair on boottime. In this case DO NOT PANIC, YOUR DISKS ARE STILL OK!!! - You have to reboot (CTRL-D) with an old kernel and set the /etc/fstab-file - entries right. After that, the system should come up as errorfree as before. - If your boot-partition is not coming up, also edit the /etc/lilo.conf-file - in a Linux session booted on old kernel and run lilo before reboot. Check - lilo.conf anyway to get boot on other partitions with foreign OSes right - again. But there exists a feature of this driver that allows you to change - the assignment order of the SCSI-devices by flipping the PUN-assignment. - See the next paragraph for a description. - - The problem for this is, that Linux does not assign the SCSI-devices in the - way as described in the ANSI-SCSI-standard. Linux assigns /dev/sda to - the device with at minimum id 0. But the first drive should be at id 6, - because for historical reasons, drive at id 6 has, by hardware, the highest - priority and a drive at id 0 the lowest. IBM was one of the rare producers, - where the BIOS assigns drives belonging to the ANSI-SCSI-standard. Most - other producers' BIOS does not (I think even Adaptec-BIOS). The - IBMMCA_SCSI_ORDER_STANDARD flag, which you set while configuring the - kernel enables to choose the preferred way of SCSI-device-assignment. - Defining this flag would result in Linux determining the devices in the - same order as DOS and OS/2 does on your MCA-machine. This is also standard - on most industrial computers and OSes, like e.g. OS-9. Leaving this flag - undefined will get your devices ordered in the default way of Linux. See - also the remarks of Chris Beauregard from Dec 15, 1997 and the followups - in section 3. - - 2.5 Regular SCSI-Command-Processing - ----------------------------------- - Only three functions get involved: ibmmca_queuecommand(), issue_cmd(), - and interrupt_handler(). - - The upper layer issues a scsi command by calling function - ibmmca_queuecommand(). This function fills a "subsystem control block" - (scb) and calls a local function issue_cmd(), which writes a scb - command into subsystem I/O ports. Once the scb command is carried out, - the interrupt_handler() is invoked. If a device is determined to be - existent and it has not assigned any ldn, it gets one dynamically. - For this, the whole stuff is done in ibmmca_queuecommand(). - - 2.6 Abort & Reset Commands - -------------------------- - These are implemented with busy waiting for interrupt to arrive. - ibmmca_reset() and ibmmca_abort() do not work sufficiently well - up to now and need still a lot of development work. This seems - to be a problem with other low-level SCSI drivers too, however - this should be no excuse. - - 2.7 Disk Geometry - ----------------- - The ibmmca_biosparams() function should return the same disk geometry - as the bios. This is needed for fdisk, etc. The returned geometry is - certainly correct for disks smaller than 1 gigabyte. In the meantime, - it has been proved, that this works fine even with disks larger than - 1 gigabyte. - - 2.8 Kernel Boot Option - ---------------------- - The function ibmmca_scsi_setup() is called if option ibmmcascsi=n - is passed to the kernel. See file linux/init/main.c for details. - - 2.9 Driver Module Support - ------------------------- - Is implemented and tested by K. Kudielka. This could probably not work - on kernels <2.1.0. - - 2.10 Multiple Hostadapter Support - --------------------------------- - This driver supports up to eight interfaces of type IBM-SCSI-Subsystem. - Integrated-, and MCA-adapters are automatically recognized. Unrecognizable - IBM-SCSI-Subsystem interfaces can be specified as kernel-parameters. - - 2.11 /proc/scsi-Filesystem Information - -------------------------------------- - Information about the driver condition is given in - /proc/scsi/ibmmca/<host_no>. ibmmca_proc_info() provides this information. - - This table is quite informative for interested users. It shows the load - of commands on the subsystem and whether you are running the bypassed - (software) or integrated (hardware) SCSI-command set (see below). The - amount of accesses is shown. Read, write, modeselect is shown separately - in order to help debugging problems with CD-ROMs or tapedrives. - - The following table shows the list of 15 logical device numbers, that are - used by the SCSI-subsystem. The load on each ldn is shown in the table, - again, read and write commands are split. The last column shows the amount - of reassignments, that have been applied to the ldns, if you have more than - 15 pun/lun combinations available on the SCSI-bus. - - The last two tables show the pun/lun map and the positions of the ldns - on this pun/lun map. This may change during operation, when a ldn is - reassigned to another pun/lun combination. If the necessity for dynamical - assignments is set to 'no', the ldn structure keeps static. - - 2.12 /proc/mca-Filesystem Information - ------------------------------------- - The slot-file contains all default entries and in addition chip and I/O- - address information of the SCSI-subsystem. This information is provided - by ibmmca_getinfo(). - - 2.13 Supported IBM SCSI-Subsystems - ---------------------------------- - The following IBM SCSI-subsystems are supported by this driver: - - - IBM Fast/Wide SCSI-2 Adapter - - IBM 7568 Industrial Computer SCSI Adapter w/Cache - - IBM Expansion Unit SCSI Controller - - IBM SCSI Adapter w/Cache - - IBM SCSI Adapter - - IBM Integrated SCSI Controller - - All clones, 100% compatible with the chipset and subsystem command - system of IBM SCSI-adapters (forced detection) - - 2.14 Linux Kernel Versions - -------------------------- - The IBM SCSI-subsystem low level driver is prepared to be used with - all versions of Linux between 2.0.x and 2.4.x. The compatibility checks - are fully implemented up from version 3.1e of the driver. This means, that - you just need the latest ibmmca.h and ibmmca.c file and copy it in the - linux/drivers/scsi directory. The code is automatically adapted during - kernel compilation. This is different from kernel 2.4.0! Here version - 4.0 or later of the driver must be used for kernel 2.4.0 or later. Version - 4.0 or later does not work together with older kernels! Driver versions - older than 4.0 do not work together with kernel 2.4.0 or later. They work - on all older kernels. - - 3 Code History - -------------- - Jan 15 1996: First public release. - - Martin Kolinek - - Jan 23 1996: Scrapped code which reassigned scsi devices to logical - device numbers. Instead, the existing assignment (created - when the machine is powered-up or rebooted) is used. - A side effect is that the upper layer of Linux SCSI - device driver gets bogus scsi ids (this is benign), - and also the hard disks are ordered under Linux the - same way as they are under dos (i.e., C: disk is sda, - D: disk is sdb, etc.). - - Martin Kolinek - - I think that the CD-ROM is now detected only if a CD is - inside CD_ROM while Linux boots. This can be fixed later, - once the driver works on all types of PS/2's. - - Martin Kolinek - - Feb 7 1996: Modified biosparam function. Fixed the CD-ROM detection. - For now, devices other than harddisk and CD_ROM are - ignored. Temporarily modified abort() function - to behave like reset(). - - Martin Kolinek - - Mar 31 1996: The integrated scsi subsystem is correctly found - in PS/2 models 56,57, but not in model 76. Therefore - the ibmmca_scsi_setup() function has been added today. - This function allows the user to force detection of - scsi subsystem. The kernel option has format - ibmmcascsi=n - where n is the scsi_id (pun) of the subsystem. Most likely, n is 7. - - Martin Kolinek - - Aug 21 1996: Modified the code which maps ldns to (pun,0). It was - insufficient for those of us with CD-ROM changers. - - Chris Beauregard - - Dec 14 1996: More improvements to the ldn mapping. See check_devices - for details. Did more fiddling with the integrated SCSI detection, - but I think it's ultimately hopeless without actually testing the - model of the machine. The 56, 57, 76 and 95 (ultimedia) all have - different integrated SCSI register configurations. However, the 56 - and 57 are the only ones that have problems with forced detection. - - Chris Beauregard - - Mar 8-16 1997: Modified driver to run as a module and to support - multiple adapters. A structure, called ibmmca_hostdata, is now - present, containing all the variables, that were once only - available for one single adapter. The find_subsystem-routine has vanished. - The hardware recognition is now done in ibmmca_detect directly. - This routine checks for presence of MCA-bus, checks the interrupt - level and continues with checking the installed hardware. - Certain PS/2-models do not recognize a SCSI-subsystem automatically. - Hence, the setup defined by command-line-parameters is checked first. - Thereafter, the routine probes for an integrated SCSI-subsystem. - Finally, adapters are checked. This method has the advantage to cover all - possible combinations of multiple SCSI-subsystems on one MCA-board. Up to - eight SCSI-subsystems can be recognized and announced to the upper-level - drivers with this improvement. A set of defines made changes to other - routines as small as possible. - - Klaus Kudielka - - May 30 1997: (v1.5b) - 1) SCSI-command capability enlarged by the recognition of MODE_SELECT. - This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which - allows data to be written from the system to the device. It is a - necessary step to be allowed to set blocksize of SCSI-tape-drives and - the tape-speed, without confusing the SCSI-Subsystem. - 2) The recognition of a tape is included in the check_devices routine. - This is done by checking for TYPE_TAPE, that is already defined in - the kernel-scsi-environment. The markup of a tape is done in the - global ldn_is_tape[] array. If the entry on index ldn - is 1, there is a tapedrive connected. - 3) The ldn_is_tape[] array is necessary to distinguish between tape- and - other devices. Fixed blocklength devices should not cause a problem - with the SCB-command for read and write in the ibmmca_queuecommand - subroutine. Therefore, I only derivate the READ_XX, WRITE_XX for - the tape-devices, as recommended by IBM in this Technical Reference, - mentioned below. (IBM recommends to avoid using the read/write of the - subsystem, but the fact was, that read/write causes a command error from - the subsystem and this causes kernel-panic.) - 4) In addition, I propose to use the ldn instead of a fix char for the - display of PS2_DISK_LED_ON(). On 95, one can distinguish between the - devices that are accessed. It shows activity and easyfies debugging. - The tape-support has been tested with a SONY SDT-5200 and a HP DDS-2 - (I do not know yet the type). Optimization and CD-ROM audio-support, - I am working on ... - - Michael Lang - - June 19 1997: (v1.6b) - 1) Submitting the extra-array ldn_is_tape[] -> to the local ld[] - device-array. - 2) CD-ROM Audio-Play seems to work now. - 3) When using DDS-2 (120M) DAT-Tapes, mtst shows still density-code - 0x13 for ordinary DDS (61000 BPM) instead 0x24 for DDS-2. This appears - also on Adaptec 2940 adaptor in a PCI-System. Therefore, I assume that - the problem is independent of the low-level-driver/bus-architecture. - 4) Hexadecimal ldn on PS/2-95 LED-display. - 5) Fixing of the PS/2-LED on/off that it works right with tapedrives and - does not confuse the disk_rw_in_progress counter. - - Michael Lang - - June 21 1997: (v1.7b) - 1) Adding of a proc_info routine to inform in /proc/scsi/ibmmca/<host> the - outer-world about operational load statistics on the different ldns, - seen by the driver. Everybody that has more than one IBM-SCSI should - test this, because I only have one and cannot see what happens with more - than one IBM-SCSI hosts. - 2) Definition of a driver version-number to have a better recognition of - the source when there are existing too much releases that may confuse - the user, when reading about release-specific problems. Up to know, - I calculated the version-number to be 1.7. Because we are in BETA-test - yet, it is today 1.7b. - 3) Sorry for the heavy bug I programmed on June 19 1997! After that, the - CD-ROM did not work any more! The C7-command was a fake impression - I got while programming. Now, the READ and WRITE commands for CD-ROM are - no longer running over the subsystem, but just over - IM_OTHER_SCSI_CMD_CMD. On my observations (PS/2-95), now CD-ROM mounts - much faster(!) and hopefully all fancy multimedia-functions, like direct - digital recording from audio-CDs also work. (I tried it with cdda2wav - from the cdwtools-package and it filled up the harddisk immediately :-).) - To easify boolean logics, a further local device-type in ld[], called - is_cdrom has been included. - 4) If one uses a SCSI-device of unsupported type/commands, one - immediately runs into a kernel-panic caused by Command Error. To better - understand which SCSI-command caused the problem, I extended this - specific panic-message slightly. - - Michael Lang - - June 25 1997: (v1.8b) - 1) Some cosmetic changes for the handling of SCSI-device-types. - Now, also CD-Burners / WORMs and SCSI-scanners should work. For - MO-drives I have no experience, therefore not yet supported. - In logical_devices I changed from different type-variables to one - called 'device_type' where the values, corresponding to scsi.h, - of a SCSI-device are stored. - 2) There existed a small bug, that maps a device, coming after a SCSI-tape - wrong. Therefore, e.g. a CD-ROM changer would have been mapped wrong - -> problem removed. - 3) Extension of the logical_device structure. Now it contains also device, - vendor and revision-level of a SCSI-device for internal usage. - - Michael Lang - - June 26-29 1997: (v2.0b) - 1) The release number 2.0b is necessary because of the completely new done - recognition and handling of SCSI-devices with the adapter. As I got - from Chris the hint, that the subsystem can reassign ldns dynamically, - I remembered this immediate_assign-command, I found once in the handbook. - Now, the driver first kills all ldn assignments that are set by default - on the SCSI-subsystem. After that, it probes on all puns and luns for - devices by going through all combinations with immediate_assign and - probing for devices, using device_inquiry. The found physical(!) pun,lun - structure is stored in get_scsi[][] as device types. This is followed - by the assignment of all ldns to existing SCSI-devices. If more ldns - than devices are available, they are assigned to non existing pun,lun - combinations to satisfy the adapter. With this, the dynamical mapping - was possible to implement. (For further info see the text in the - source code and in the description below. Read the description - below BEFORE installing this driver on your system!) - 2) Changed the name IBMMCA_DRIVER_VERSION to IBMMCA_SCSI_DRIVER_VERSION. - 3) The LED-display shows on PS/2-95 no longer the ldn, but the SCSI-ID - (pun) of the accessed SCSI-device. This is now senseful, because the - pun known within the driver is exactly the pun of the physical device - and no longer a fake one. - 4) The /proc/scsi/ibmmca/<host_no> consists now of the first part, where - hit-statistics of ldns is shown and a second part, where the maps of - physical and logical SCSI-devices are displayed. This could be very - interesting, when one is using more than 15 SCSI-devices in order to - follow the dynamical remapping of ldns. - - Michael Lang - - June 26-29 1997: (v2.0b-1) - 1) I forgot to switch the local_checking_phase_flag to 1 and back to 0 - in the dynamical remapping part in ibmmca_queuecommand for the - device_exist routine. Sorry. - - Michael Lang - - July 1-13 1997: (v3.0b,c) - 1) Merging of the driver-developments of Klaus Kudielka and Michael Lang - in order to get a optimum and unified driver-release for the - IBM-SCSI-Subsystem-Adapter(s). - For people, using the Kernel-release >=2.1.0, module-support should - be no problem. For users, running under <2.1.0, module-support may not - work, because the methods have changed between 2.0.x and 2.1.x. - 2) Added some more effective statistics for /proc-output. - 3) Change typecasting at necessary points from (unsigned long) to - virt_to_bus(). - 4) Included #if... at special points to have specific adaption of the - driver to kernel 2.0.x and 2.1.x. It should therefore also run with - later releases. - 5) Magneto-Optical drives and medium-changers are also recognized, now. - Therefore, we have a completely gapfree recognition of all SCSI- - device-types, that are known by Linux up to kernel 2.1.31. - 6) The flag SCSI_IBMMCA_DEV_RESET has been inserted. If it is set within - the configuration, each connected SCSI-device will get a reset command - during boottime. This can be necessary for some special SCSI-devices. - This flag should be included in Config.in. - (See also the new Config.in file.) - Probable next improvement: bad disk handler. - - Michael Lang - - Sept 14 1997: (v3.0c) - 1) Some debugging and speed optimization applied. - - Michael Lang - - Dec 15, 1997 - - chrisb@truespectra.com - - made the front panel display thingy optional, specified from the - command-line via ibmmcascsi=display. Along the lines of the /LED - option for the OS/2 driver. - - fixed small bug in the LED display that would hang some machines. - - reversed ordering of the drives (using the - IBMMCA_SCSI_ORDER_STANDARD define). This is necessary for two main - reasons: - - users who've already installed Linux won't be screwed. Keep - in mind that not everyone is a kernel hacker. - - be consistent with the BIOS ordering of the drives. In the - BIOS, id 6 is C:, id 0 might be D:. With this scheme, they'd be - backwards. This confuses the crap out of those heathens who've - got a impure Linux installation (which, <wince>, I'm one of). - This whole problem arises because IBM is actually non-standard with - the id to BIOS mappings. You'll find, in fdomain.c, a similar - comment about a few FD BIOS revisions. The Linux (and apparently - industry) standard is that C: maps to scsi id (0,0). Let's stick - with that standard. - - Since this is technically a branch of my own, I changed the - version number to 3.0e-cpb. - - Jan 17, 1998: (v3.0f) - 1) Addition of some statistical info for /proc in proc_info. - 2) Taking care of the SCSI-assignment problem, dealed by Chris at Dec 15 - 1997. In fact, IBM is right, concerning the assignment of SCSI-devices - to driveletters. It is conform to the ANSI-definition of the SCSI- - standard to assign drive C: to SCSI-id 6, because it is the highest - hardware priority after the hostadapter (that has still today by - default everywhere id 7). Also realtime-operating systems that I use, - like LynxOS and OS9, which are quite industrial systems use top-down - numbering of the harddisks, that is also starting at id 6. Now, one - sits a bit between two chairs. On one hand side, using the define - IBMMCA_SCSI_ORDER_STANDARD makes Linux assigning disks conform to - the IBM- and ANSI-SCSI-standard and keeps this driver downward - compatible to older releases, on the other hand side, people is quite - habituated in believing that C: is assigned to (0,0) and much other - SCSI-BIOS do so. Therefore, I moved the IBMMCA_SCSI_ORDER_STANDARD - define out of the driver and put it into Config.in as subitem of - 'IBM SCSI support'. A help, added to Documentation/Configure.help - explains the differences between saying 'y' or 'n' to the user, when - IBMMCA_SCSI_ORDER_STANDARD prompts, so the ordinary user is enabled to - choose the way of assignment, depending on his own situation and gusto. - 3) Adapted SCSI_IBMMCA_DEV_RESET to the local naming convention, so it is - now called IBMMCA_SCSI_DEV_RESET. - 4) Optimization of proc_info and its subroutines. - 5) Added more in-source-comments and extended the driver description by - some explanation about the SCSI-device-assignment problem. - - Michael Lang - - Jan 18, 1998: (v3.0g) - 1) Correcting names to be absolutely conform to the later 2.1.x releases. - This is necessary for - IBMMCA_SCSI_DEV_RESET -> CONFIG_IBMMCA_SCSI_DEV_RESET - IBMMCA_SCSI_ORDER_STANDARD -> CONFIG_IBMMCA_SCSI_ORDER_STANDARD - - Michael Lang - - Jan 18, 1999: (v3.1 MCA-team internal) - 1) The multiple hosts structure is accessed from every subroutine, so there - is no longer the address of the device structure passed from function - to function, but only the hostindex. A call by value, nothing more. This - should really be understood by the compiler and the subsystem should get - the right values and addresses. - 2) The SCSI-subsystem detection was not complete and quite hugely buggy up - to now, compared to the technical manual. The interpretation of the pos2 - register is not as assumed by people before, therefore, I dropped a note - in the ibmmca_detect function to show the registers' interpretation. - The pos-registers of integrated SCSI-subsystems do not contain any - information concerning the IO-port offset, really. Instead, they contain - some info about the adapter, the chip, the NVRAM .... The I/O-port is - fixed to 0x3540 - 0x3547. There can be more than one adapters in the - slots and they get an offset for the I/O area in order to get their own - I/O-address area. See chapter 2 for detailed description. At least, the - detection should now work right, even on models other than 95. The 95ers - came happily around the bug, as their pos2 register contains always 0 - in the critical area. Reserved bits are not allowed to be interpreted, - therefore, IBM is allowed to set those bits as they like and they may - really vary between different PS/2 models. So, now, no interpretation - of reserved bits - hopefully no trouble here anymore. - 3) The command error, which you may get on models 55, 56, 57, 70, 77 and - P70 may have been caused by the fact, that adapters of older design do - not like sending commands to non-existing SCSI-devices and will react - with a command error as a sign of protest. While this error is not - present on IBM SCSI Adapter w/cache, it appears on IBM Integrated SCSI - Adapters. Therefore, I implemented a workaround to forgive those - adapters their protests, but it is marked up in the statistics, so - after a successful boot, you can see in /proc/scsi/ibmmca/<host_number> - how often the command errors have been forgiven to the SCSI-subsystem. - If the number is bigger than 0, you have a SCSI subsystem of older - design, what should no longer matter. - 4) ibmmca_getinfo() has been adapted very carefully, so it shows in the - slotn file really, what is senseful to be presented. - 5) ibmmca_register() has been extended in its parameter list in order to - pass the right name of the SCSI-adapter to Linux. - - Michael Lang - - Feb 6, 1999: (v3.1) - 1) Finally, after some 3.1Beta-releases, the 3.1 release. Sorry, for - the delayed release, but it was not finished with the release of - Kernel 2.2.0. - - Michael Lang - - Feb 10, 1999 (v3.1) - 1) Added a new commandline parameter called 'bypass' in order to bypass - every integrated subsystem SCSI-command consequently in case of - troubles. - 2) Concatenated read_capacity requests to the harddisks. It gave a lot - of troubles with some controllers and after I wanted to apply some - extensions, it jumped out in the same situation, on my w/cache, as like - on D. Weinehalls' Model 56, having integrated SCSI. This gave me the - decisive hint to move the code-part out and declare it global. Now - it seems to work far better and more stable. Let us see what - the world thinks of it... - 3) By the way, only Sony DAT-drives seem to show density code 0x13. A - test with a HP drive gave right results, so the problem is vendor- - specific and not a problem of the OS or the driver. - - Michael Lang - - Feb 18, 1999 (v3.1d) - 1) The abort command and the reset function have been checked for - inconsistencies. From the logical point of thinking, they work - at their optimum, now, but as the subsystem does not answer with an - interrupt, abort never finishes, sigh... - 2) Everything, that is accessed by a busmaster request from the adapter - is now declared as global variable, even the return-buffer in the - local checking phase. This assures, that no accesses to undefined memory - areas are performed. - 3) In ibmmca.h, the line unchecked_isa_dma is added with 1 in order to - avoid memory-pointers for the areas higher than 16MByte in order to - be sure, it also works on 16-Bit Microchannel bus systems. - 4) A lot of small things have been found, but nothing that endangered the - driver operations. Just it should be more stable, now. - - Michael Lang - - Feb 20, 1999 (v3.1e) - 1) I took the warning from the Linux Kernel Hackers Guide serious and - checked the cmd->result return value to the done-function very carefully. - It is obvious, that the IBM SCSI only delivers the tsb.dev_status, if - some error appeared, else it is undefined. Now, this is fixed. Before - any SCB command gets queued, the tsb.dev_status is set to 0, so the - cmd->result won't screw up Linux higher level drivers. - 2) The reset-function has slightly improved. This is still planned for - abort. During the abort and the reset function, no interrupts are - allowed. This is however quite hard to cope with, so the INT-status - register is read. When the interrupt gets queued, one can find its - status immediately on that register and is enabled to continue in the - reset function. I had no chance to test this really, only in a bogus - situation, I got this function running, but the situation was too much - worse for Linux :-(, so tests will continue. - 3) Buffers got now consistent. No open address mapping, as before and - therefore no further troubles with the unassigned memory segmentation - faults that scrambled probes on 95XX series and even on 85XX series, - when the kernel is done in a not so perfectly fitting way. - 4) Spontaneous interrupts from the subsystem, appearing without any - command previously queued are answered with a DID_BAD_INTR result. - 5) Taken into account ZP Gus' proposals to reverse the SCSI-device - scan order. As it does not work on Kernel 2.1.x or 2.2.x, as proposed - by him, I implemented it in a slightly derived way, which offers in - addition more flexibility. - - Michael Lang - - Apr 23, 2000 (v3.2pre1) - 1) During a very long time, I collected a huge amount of bug reports from - various people, trying really quite different things on their SCSI- - PS/2s. Today, all these bug reports are taken into account and should be - mostly solved. The major topics were: - - Driver crashes during boottime by no obvious reason. - - Driver panics while the midlevel-SCSI-driver is trying to inquire - the SCSI-device properties, even though hardware is in perfect state. - - Displayed info for the various slot-cards is interpreted wrong. - The main reasons for the crashes were two: - 1) The commands to check for device information like INQUIRY, - TEST_UNIT_READY, REQUEST_SENSE and MODE_SENSE cause the devices - to deliver information of up to 255 bytes. Midlevel drivers offer - 1024 bytes of space for the answer, but the IBM-SCSI-adapters do - not accept this, as they stick quite near to ANSI-SCSI and report - a COMMAND_ERROR message which causes the driver to panic. The main - problem was located around the INQUIRY command. Now, for all the - mentioned commands, the buffersize sent to the adapter is at - maximum 255 which seems to be a quite reasonable solution. - TEST_UNIT_READY gets a buffersize of 0 to make sure that no - data is transferred in order to avoid any possible command failure. - 2) On unsuccessful TEST_UNIT_READY, the mid-level driver has to send - a REQUEST_SENSE in order to see where the problem is located. This - REQUEST_SENSE may have various length in its answer-buffer. IBM - SCSI-subsystems report a command failure if the returned buffersize - is different from the sent buffersize, but this can be suppressed by - a special bit, which is now done and problems seem to be solved. - 2) Code adaption to all kernel-releases. Now, the 3.2 code compiles on - 2.0.x, 2.1.x, 2.2.x and 2.3.x kernel releases without any code-changes. - 3) Commandline-parameters are recognized again, even under Kernel 2.3.x or - higher. - - Michael Lang - - April 27, 2000 (v3.2pre2) - 1) Bypassed commands get read by the adapter by one cycle instead of two. - This increases SCSI-performance. - 2) Synchronous datatransfer is provided for sure to be 5 MHz on older - SCSI and 10 MHz on internal F/W SCSI-adapter. - 3) New commandline parameters allow to force the adapter to slow down while - in synchronous transfer. Could be helpful for very old devices. - - Michael Lang - - June 2, 2000 (v3.2pre5) - 1) Added Jim Shorney's contribution to make the activity indicator - flashing in addition to the LED-alphanumeric display-panel on - models 95A. To be enabled to choose this feature freely, a new - commandline parameter is added, called 'activity'. - 2) Added the READ_CONTROL bit for test_unit_ready SCSI-command. - 3) Added some suppress_exception bits to read_device_capacity and - all device_inquiry occurrences in the driver code. - 4) Complaints about the various KERNEL_VERSION implementations are - taken into account. Every local_LinuxKernelVersion occurrence is - now replaced by KERNEL_VERSION, defined in linux/version.h. - Corresponding changes were applied to ibmmca.h, too. This was a - contribution to all kernel-parts by Philipp Hahn. - - Michael Lang - - July 17, 2000 (v3.2pre8) - A long period of collecting bug reports from all corners of the world - now lead to the following corrections to the code: - 1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this - was that it is possible to disable Fast-SCSI for the external bus. - The feature-control command, where this crash appeared regularly, tried - to set the maximum speed of 10MHz synchronous transfer speed and that - reports a COMMAND ERROR if external bus Fast-SCSI is disabled. Now, - the feature-command probes down from maximum speed until the adapter - stops to complain, which is at the same time the maximum possible - speed selected in the reference program. So, F/W external can run at - 5 MHz (slow-) or 10 MHz (fast-SCSI). During feature probing, the - COMMAND ERROR message is used to detect if the adapter does not complain. - 2) Up to now, only combined busmode is supported, if you use external - SCSI-devices, attached to the F/W-controller. If dual bus is selected, - only the internal SCSI-devices get accessed by Linux. For most - applications, this should do fine. - 3) Wide-SCSI-addressing (16-Bit) is now possible for the internal F/W - bus on the F/W adapter. If F/W adapter is detected, the driver - automatically uses the extended PUN/LUN <-> LDN mapping tables, which - are now new from 3.2pre8. This allows PUNs between 0 and 15 and should - provide more fun with the F/W adapter. - 4) Several machines use the SCSI: POS registers for internal/undocumented - storage of system relevant info. This confused the driver, mainly on - models 9595, as it expected no onboard SCSI only, if all POS in - the integrated SCSI-area are set to 0x00 or 0xff. Now, the mechanism - to check for integrated SCSI is much more restrictive and these problems - should be history. - - Michael Lang - - July 18, 2000 (v3.2pre9) - This develop rather quickly at the moment. Two major things were still - missing in 3.2pre8: - 1) The adapter PUN for F/W adapters has 4-bits, while all other adapters - have 3-bits. This is now taken into account for F/W. - 2) When you select CONFIG_IBMMCA_SCSI_ORDER_STANDARD, you should - normally get the inverse probing order of your devices on the SCSI-bus. - The ANSI device order gets scrambled in version 3.2pre8!! Now, a new - and tested algorithm inverts the device-order on the SCSI-bus and - automatically avoids accidental access to whatever SCSI PUN the adapter - is set and works with SCSI- and Wide-SCSI-addressing. - - Michael Lang - - July 23, 2000 (v3.2pre10 unpublished) - 1) LED panel display supports wide-addressing in ibmmca=display mode. - 2) Adapter-information and autoadaption to address-space is done. - 3) Auto-probing for maximum synchronous SCSI transfer rate is working. - 4) Optimization to some embedded function calls is applied. - 5) Added some comment for the user to wait for SCSI-devices being probed. - 6) Finished version 3.2 for Kernel 2.4.0. It least, I thought it is but... - - Michael Lang - - July 26, 2000 (v3.2pre11) - 1) I passed a horrible weekend getting mad with NMIs on kernel 2.2.14 and - a model 9595. Asking around in the community, nobody except of me has - seen such errors. Weird, but I am trying to recompile everything on - the model 9595. Maybe, as I use a specially modified gcc, that could - cause problems. But, it was not the reason. The true background was, - that the kernel was compiled for i386 and the 9595 has a 486DX-2. - Normally, no troubles should appear, but for this special machine, - only the right processor support is working fine! - 2) Previous problems with synchronous speed, slowing down from one adapter - to the next during probing are corrected. Now, local variables store - the synchronous bitmask for every single adapter found on the MCA bus. - 3) LED alphanumeric panel support for XX95 systems is now showing some - alive rotator during boottime. This makes sense, when no monitor is - connected to the system. You can get rid of all display activity, if - you do not use any parameter or just ibmmcascsi=activity, for the - harddrive activity LED, existent on all PS/2, except models 8595-XXX. - If no monitor is available, please use ibmmcascsi=display, which works - fine together with the linuxinfo utility for the LED-panel. - - Michael Lang - - July 29, 2000 (v3.2) - 1) Submission of this driver for kernel 2.4test-XX and 2.2.17. - - Michael Lang - - December 28, 2000 (v3.2d / v4.0) - 1) The interrupt handler had some wrong statement to wait for. This - was done due to experimental reasons during 3.2 development but it - has shown that this is not stable enough. Going back to wait for the - adapter to be not busy is best. - 2) Inquiry requests can be shorter than 255 bytes of return buffer. Due - to a bug in the ibmmca_queuecommand routine, this buffer was forced - to 255 at minimum. If the memory address, this return buffer is pointing - to does not offer more space, invalid memory accesses destabilized the - kernel. - 3) version 4.0 is only valid for kernel 2.4.0 or later. This is necessary - to remove old kernel version dependent waste from the driver. 3.2d is - only distributed with older kernels but keeps compatibility with older - kernel versions. 4.0 and higher versions cannot be used with older - kernels anymore!! You must have at least kernel 2.4.0!! - 4) The commandline argument 'bypass' and all its functionality got removed - in version 4.0. This was never really necessary, as all troubles were - based on non-command related reasons up to now, so bypassing commands - did not help to avoid any bugs. It is kept in 3.2X for debugging reasons. - 5) Dynamic reassignment of ldns was again verified and analyzed to be - completely inoperational. This is corrected and should work now. - 6) All commands that get sent to the SCSI adapter were verified and - completed in such a way, that they are now completely conform to the - demands in the technical description of IBM. Main candidates were the - DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must - be transferred by bypassing the internal command buffer of the adapter - or else the response can be a random result. GET_POS_INFO would be more - safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this - is not allowed by the technical references of IBM. (Sorry, folks, the - model 80 problem is still a task to be solved in a different way.) - 7) v3.2d is still hold back for some days for testing, while 4.0 is - released. - - Michael Lang - - January 3, 2001 (v4.0a) - 1) A lot of complains after the 2.4.0-prerelease kernel came in about - the impossibility to compile the driver as a module. This problem is - solved. In combination with that problem, some unprecise declaration - of the function option_setup() gave some warnings during compilation. - This is solved, too by a forward declaration in ibmmca.c. - 2) #ifdef argument concerning CONFIG_SCSI_IBMMCA is no longer needed and - was entirely removed. - 3) Some switch statements got optimized in code, as some minor variables - in internal SCSI-command handlers. - - Michael Lang - - 4 To do - ------- - - IBM SCSI-2 F/W external SCSI bus support in separate mode! - - It seems that the handling of bad disks is really bad - - non-existent, in fact. However, a low-level driver cannot help - much, if such things happen. - - 5 Users' Manual - --------------- - 5.1 Commandline Parameters - -------------------------- - There exist several features for the IBM SCSI-subsystem driver. - The commandline parameter format is: - - ibmmcascsi=<command1>,<command2>,<command3>,... - - where commandN can be one of the following: - - display Owners of a model 95 or other PS/2 systems with an - alphanumeric LED display may set this to have their - display showing the following output of the 8 digits: - - ------DA - - where '-' stays dark, 'D' shows the SCSI-device id - and 'A' shows the SCSI hostindex, being currently - accessed. During boottime, this will give the message - - SCSIini* - - on the LED-panel, where the * represents a rotator, - showing the activity during the probing phase of the - driver which can take up to two minutes per SCSI-adapter. - adisplay This works like display, but gives more optical overview - of the activities on the SCSI-bus. The display will have - the following output: - - 6543210A - - where the numbers 0 to 6 light up at the shown position, - when the SCSI-device is accessed. 'A' shows again the SCSI - hostindex. If display nor adisplay is set, the internal - PS/2 harddisk LED is used for media-activities. So, if - you really do not have a system with a LED-display, you - should not set display or adisplay. Keep in mind, that - display and adisplay can only be used alternatively. It - is not recommended to use this option, if you have some - wide-addressed devices e.g. at the SCSI-2 F/W adapter in - your system. In addition, the usage of the display for - other tasks in parallel, like the linuxinfo-utility makes - no sense with this option. - activity This enables the PS/2 harddisk LED activity indicator. - Most PS/2 have no alphanumeric LED display, but some - indicator. So you should use this parameter to activate it. - If you own model 9595 (Server95), you can have both, the - LED panel and the activity indicator in parallel. However, - some PS/2s, like the 8595 do not have any harddisk LED - activity indicator, which means, that you must use the - alphanumeric LED display if you want to monitor SCSI- - activity. - bypass This is obsolete from driver version 4.0, as the adapters - got that far understood, that the selection between - integrated and bypassed commands should now work completely - correct! For historical reasons, the old description is - kept here: - This commandline parameter forces the driver never to use - SCSI-subsystems' integrated SCSI-command set. Except of - the immediate assign, which is of vital importance for - every IBM SCSI-subsystem to set its ldns right. Instead, - the ordinary ANSI-SCSI-commands are used and passed by the - controller to the SCSI-devices, therefore 'bypass'. The - effort, done by the subsystem is quite bogus and at a - minimum and therefore it should work everywhere. This - could maybe solve troubles with old or integrated SCSI- - controllers and nasty harddisks. Keep in mind, that using - this flag will slow-down SCSI-accesses slightly, as the - software generated commands are always slower than the - hardware. Non-harddisk devices always get read/write- - commands in bypass mode. On the most recent releases of - the Linux IBM-SCSI-driver, the bypass command should be - no longer a necessary thing, if you are sure about your - SCSI-hardware! - normal This is the parameter, introduced on the 2.0.x development - rail by ZP Gu. This parameter defines the SCSI-device - scan order in the new industry standard. This means, that - the first SCSI-device is the one with the lowest pun. - E.g. harddisk at pun=0 is scanned before harddisk at - pun=6, which means, that harddisk at pun=0 gets sda - and the one at pun=6 gets sdb. - ansi The ANSI-standard for the right scan order, as done by - IBM, Microware and Microsoft, scans SCSI-devices starting - at the highest pun, which means, that e.g. harddisk at - pun=6 gets sda and a harddisk at pun=0 gets sdb. If you - like to have the same SCSI-device order, as in DOS, OS-9 - or OS/2, just use this parameter. - fast SCSI-I/O in synchronous mode is done at 5 MHz for IBM- - SCSI-devices. SCSI-2 Fast/Wide Adapter/A external bus - should then run at 10 MHz if Fast-SCSI is enabled, - and at 5 MHz if Fast-SCSI is disabled on the external - bus. This is the default setting when nothing is - specified here. - medium Synchronous rate is at 50% approximately, which means - 2.5 MHz for IBM SCSI-adapters and 5.0 MHz for F/W ext. - SCSI-bus (when Fast-SCSI speed enabled on external bus). - slow The slowest possible synchronous transfer rate is set. - This means 1.82 MHz for IBM SCSI-adapters and 2.0 MHz - for F/W external bus at Fast-SCSI speed on the external - bus. - - A further option is that you can force the SCSI-driver to accept a SCSI- - subsystem at a certain I/O-address with a predefined adapter PUN. This - is done by entering - - commandN = I/O-base - commandN+1 = adapter PUN - - e.g. ibmmcascsi=0x3540,7 will force the driver to detect a SCSI-subsystem - at I/O-address 0x3540 with adapter PUN 7. Please only use this method, if - the driver does really not recognize your SCSI-adapter! With driver version - 3.2, this recognition of various adapters was hugely improved and you - should try first to remove your commandline arguments of such type with a - newer driver. I bet, it will be recognized correctly. Even multiple and - different types of IBM SCSI-adapters should be recognized correctly, too. - Use the forced detection method only as last solution! - - Examples: - - ibmmcascsi=adisplay - - This will use the advanced display mode for the model 95 LED alphanumeric - display. - - ibmmcascsi=display,0x3558,7 - - This will activate the default display mode for the model 95 LED display - and will force the driver to accept a SCSI-subsystem at I/O-base 0x3558 - with adapter PUN 7. - - 5.2 Troubleshooting - ------------------- - The following FAQs should help you to solve some major problems with this - driver. - - Q: "Reset SCSI-devices at boottime" halts the system at boottime, why? - A: This is only tested with the IBM SCSI Adapter w/cache. It is not - yet proven to run on other adapters, however you may be lucky. - In version 3.1d this has been hugely improved and should work better, - now. Normally you really won't need to activate this flag in the - kernel configuration, as all post 1989 SCSI-devices should accept - the reset-signal, when the computer is switched on. The SCSI- - subsystem generates this reset while being initialized. This flag - is really reserved for users with very old, very strange or self-made - SCSI-devices. - Q: Why is the SCSI-order of my drives mirrored to the device-order - seen from OS/2 or DOS ? - A: It depends on the operating system, if it looks at the devices in - ANSI-SCSI-standard (starting from pun 6 and going down to pun 0) or - if it just starts at pun 0 and counts up. If you want to be conform - with OS/2 and DOS, you have to activate this flag in the kernel - configuration or you should set 'ansi' as parameter for the kernel. - The parameter 'normal' sets the new industry standard, starting - from pun 0, scanning up to pun 6. This allows you to change your - opinion still after having already compiled the kernel. - Q: Why can't I find IBM MCA SCSI support in the config menu? - A: You have to activate MCA bus support, first. - Q: Where can I find the latest info about this driver? - A: See the file MAINTAINERS for the current WWW-address, which offers - updates, info and Q/A lists. At this file's origin, the webaddress - was: http://www.staff.uni-mainz.de/mlang/linux.html - Q: My SCSI-adapter is not recognized by the driver, what can I do? - A: Just force it to be recognized by kernel parameters. See section 5.1. - If this really happens, do also send e-mail to the maintainer, as - forced detection should be never necessary. Forced detection is in - principal some flaw of the driver adapter detection and goes into - bug reports. - Q: The driver screws up, if it starts to probe SCSI-devices, is there - some way out of it? - A: Yes, that was some recognition problem of the correct SCSI-adapter - and its I/O base addresses. Upgrade your driver to the latest release - and it should be fine again. - Q: I get a message: panic IBM MCA SCSI: command error .... , what can - I do against this? - A: Previously, I followed the way by ignoring command errors by using - ibmmcascsi=forgiveall, but this command no longer exists and is - obsolete. If such a problem appears, it is caused by some segmentation - fault of the driver, which maps to some unallowed area. The latest - version of the driver should be ok, as most bugs have been solved. - Q: There are still kernel panics, even after having set - ibmmcascsi=forgiveall. Are there other possibilities to prevent - such panics? - A: No, get just the latest release of the driver and it should work - better and better with increasing version number. Forget about this - ibmmcascsi=forgiveall, as also ignorecmd are obsolete.! - Q: Linux panics or stops without any comment, but it is probable, that my - harddisk(s) have bad blocks. - A: Sorry, the bad-block handling is still a feeble point of this driver, - but is on the schedule for development in the near future. - Q: Linux panics while dynamically assigning SCSI-ids or ldns. - A: If you disconnect a SCSI-device from the machine, while Linux is up - and the driver uses dynamical reassignment of logical device numbers - (ldn), it really gets "angry" if it won't find devices, that were still - present at boottime and stops Linux. - Q: The system does not recover after an abort-command has been generated. - A: This is regrettably true, as it is not yet understood, why the - SCSI-adapter does really NOT generate any interrupt at the end of - the abort-command. As no interrupt is generated, the abort command - cannot get finished and the system hangs, sorry, but checks are - running to hunt down this problem. If there is a real pending command, - the interrupt MUST get generated after abort. In this case, it - should finish well. - Q: The system gets in bad shape after a SCSI-reset, is this known? - A: Yes, as there are a lot of prescriptions (see the Linux Hackers' - Guide) what has to be done for reset, we still share the bad shape of - the reset functions with all other low level SCSI-drivers. - Astonishingly, reset works in most cases quite ok, but the harddisks - won't run in synchronous mode anymore after a reset, until you reboot. - Q: Why does my XXX w/Cache adapter not use read-prefetch? - A: Ok, that is not completely possible. If a cache is present, the - adapter tries to use it internally. Explicitly, one can use the cache - with a read prefetch command, maybe in future, but this requires - some major overhead of SCSI-commands that risks the performance to - go down more than it gets improved. Tests with that are running. - Q: I have a IBM SCSI-2 Fast/Wide adapter, it boots in some way and hangs. - A: Yes, that is understood, as for sure, your SCSI-2 Fast/Wide adapter - was in such a case recognized as integrated SCSI-adapter or something - else, but not as the correct adapter. As the I/O-ports get assigned - wrongly by that reason, the system should crash in most cases. You - should upgrade to the latest release of the SCSI-driver. The - recommended version is 3.2 or later. Here, the F/W support is in - a stable and reliable condition. Wide-addressing is in addition - supported. - Q: I get an Oops message and something like "killing interrupt". - A: The reason for this is that the IBM SCSI-subsystem only sends a - termination status back, if some error appeared. In former releases - of the driver, it was not checked, if the termination status block - is NULL. From version 3.2, it is taken care of this. - Q: I have a F/W adapter and the driver sees my internal SCSI-devices, - but ignores the external ones. - A: Select combined busmode in the IBM config-program and check for that - no SCSI-id on the external devices appears on internal devices. - Reboot afterwards. Dual busmode is supported, but works only for the - internal bus, yet. External bus is still ignored. Take care for your - SCSI-ids. If combined bus-mode is activated, on some adapters, - the wide-addressing is not possible, so devices with ids between 8 - and 15 get ignored by the driver & adapter! - Q: I have a 9595 and I get a NMI during heavy SCSI I/O e.g. during fsck. - A COMMAND ERROR is reported and characters on the screen are missing. - Warm reboot is not possible. Things look like quite weird. - A: Check the processor type of your 9595. If you have an 80486 or 486DX-2 - processor complex on your mainboard and you compiled a kernel that - supports 80386 processors, it is possible, that the kernel cannot - keep track of the PS/2 interrupt handling and stops on an NMI. Just - compile a kernel for the correct processor type of your PS/2 and - everything should be fine. This is necessary even if one assumes, - that some 80486 system should be downward compatible to 80386 - software. - Q: Some commands hang and interrupts block the machine. After some - timeout, the syslog reports that it tries to call abort, but the - machine is frozen. - A: This can be a busy wait bug in the interrupt handler of driver - version 3.2. You should at least upgrade to 3.2c if you use - kernel < 2.4.0 and driver version 4.0 if you use kernel 2.4.0 or - later (including all test releases). - Q: I have a PS/2 model 80 and more than 16 MBytes of RAM. The driver - completely refuses to work, reports NMIs, COMMAND ERRORs or other - ambiguous stuff. When reducing the RAM size down below 16 MB, - everything is running smoothly. - A: No real answer, yet. In any case, one should force the kernel to - present SCBs only below the 16 MBytes barrier. Maybe this solves the - problem. Not yet tried, but guessing that it could work. To get this, - set unchecked_isa_dma argument of ibmmca.h from 0 to 1. - - 5.3 Bug reports - -------------- - If you really find bugs in the source code or the driver will successfully - refuse to work on your machine, you should send a bug report to me. The - best for this is to follow the instructions on the WWW-page for this - driver. Fill out the bug-report form, placed on the WWW-page and ship it, - so the bugs can be taken into account with maximum efforts. But, please - do not send bug reports about this driver to Linus Torvalds or Leonard - Zubkoff, as Linus is buried in E-Mail and Leonard is supervising all - SCSI-drivers and won't have the time left to look inside every single - driver to fix a bug and especially DO NOT send modified code to Linus - Torvalds or Alan J. Cox which has not been checked here!!! They are both - quite buried in E-mail (as me, sometimes, too) and one should first check - for problems on my local teststand. Recently, I got a lot of - bug reports for errors in the ibmmca.c code, which I could not imagine, but - a look inside some Linux-distribution showed me quite often some modified - code, which did no longer work on most other machines than the one of the - modifier. Ok, so now that there is maintenance service available for this - driver, please use this address first in order to keep the level of - confusion low. Thank you! - - When you get a SCSI-error message that panics your system, a list of - register-entries of the SCSI-subsystem is shown (from Version 3.1d). With - this list, it is very easy for the maintainer to localize the problem in - the driver or in the configuration of the user. Please write down all the - values from this report and send them to the maintainer. This would really - help a lot and makes life easier concerning misunderstandings. - - Use the bug-report form (see 5.4 for its address) to send all the bug- - stuff to the maintainer or write e-mail with the values from the table. - - 5.4 Support WWW-page - -------------------- - The address of the IBM SCSI-subsystem supporting WWW-page is: - - http://www.staff.uni-mainz.de/mlang/linux.html - - Here you can find info about the background of this driver, patches, - troubleshooting support, news and a bugreport form. Please check that - WWW-page regularly for latest hints. If ever this URL changes, please - refer to the MAINTAINERS file in order to get the latest address. - - For the bugreport, please fill out the formular on the corresponding - WWW-page. Read the dedicated instructions and write as much as you - know about your problem. If you do not like such formulars, please send - some e-mail directly, but at least with the same information as required by - the formular. - - If you have extensive bug reports, including Oops messages and - screen-shots, please feel free to send it directly to the address - of the maintainer, too. The current address of the maintainer is: - - Michael Lang <langa2@kph.uni-mainz.de> - - 6 References - ------------ - IBM Corp., "Update for the PS/2 Hardware Interface Technical Reference, - Common Interfaces", Armonk, September 1991, PN 04G3281, - (available in the U.S. for $21.75 at 1-800-IBM-PCTB or in Germany for - around 40,-DM at "Hallo IBM"). - - IBM Corp., "Personal System/2 Micro Channel SCSI - Adapter with Cache Technical Reference", Armonk, March 1990, PN 68X2365. - - IBM Corp., "Personal System/2 Micro Channel SCSI - Adapter Technical Reference", Armonk, March 1990, PN 68X2397. - - IBM Corp., "SCSI-2 Fast/Wide Adapter/A Technical Reference - Dual Bus", - Armonk, March 1994, PN 83G7545. - - Friedhelm Schmidt, "SCSI-Bus und IDE-Schnittstelle - Moderne Peripherie- - Schnittstellen: Hardware, Protokollbeschreibung und Anwendung", 2. Aufl. - Addison Wesley, 1996. - - Michael K. Johnson, "The Linux Kernel Hackers' Guide", Version 0.6, Chapel - Hill - North Carolina, 1995 - - Andreas Kaiser, "SCSI TAPE BACKUP for OS/2 2.0", Version 2.12, Stuttgart - 1993 - - Helmut Rompel, "IBM Computerwelt GUIDE", What is what bei IBM., Systeme * - Programme * Begriffe, IWT-Verlag GmbH - Muenchen, 1988 - - 7 Credits to - ------------ - 7.1 People - ---------- - Klaus Grimm - who already a long time ago gave me the old code from the - SCSI-driver in order to get it running for some old machine - in our institute. - Martin Kolinek - who wrote the first release of the IBM SCSI-subsystem driver. - Chris Beauregard - who for a long time maintained MCA-Linux and the SCSI-driver - in the beginning. Chris, wherever you are: Cheers to you! - Klaus Kudielka - with whom in the 2.1.x times, I had a quite fruitful - cooperation to get the driver running as a module and to get - it running with multiple SCSI-adapters. - David Weinehall - for his excellent maintenance of the MCA-stuff and the quite - detailed bug reports and ideas for this driver (and his - patience ;-)). - Alan J. Cox - for his bug reports and his bold activities in cross-checking - the driver-code with his teststand. - - 7.2 Sponsors & Supporters - ------------------------- - "Hallo IBM", - IBM-Deutschland GmbH - the service of IBM-Deutschland for customers. Their E-Mail - service is unbeatable. Whatever old stuff I asked for, I - always got some helpful answers. - Karl-Otto Reimers, - IBM Klub - Sparte IBM Geschichte, Sindelfingen - for sending me a copy of the w/Cache manual from the - IBM-Deutschland archives. - Harald Staiger - for his extensive hardware donations which allows me today - still to test the driver in various constellations. - Erich Fritscher - for his very kind sponsoring. - Louis Ohland, - Charles Lasitter - for support by shipping me an IBM SCSI-2 Fast/Wide manual. - In addition, the contribution of various hardware is quite - decessive and will make it possible to add FWSR (RAID) - adapter support to the driver in the near future! So, - complaints about no RAID support won't remain forever. - Yes, folks, that is no joke, RAID support is going to rise! - Erik Weber - for the great deal we made about a model 9595 and the nice - surrounding equipment and the cool trip to Mannheim - second-hand computer market. In addition, I would like - to thank him for his exhaustive SCSI-driver testing on his - 95er PS/2 park. - Anthony Hogbin - for his direct shipment of a SCSI F/W adapter, which allowed - me immediately on the first stage to try it on model 8557 - together with onboard SCSI adapter and some SCSI w/Cache. - Andreas Hotz - for his support by memory and an IBM SCSI-adapter. Collecting - all this together now allows me to try really things with - the driver at maximum load and variety on various models in - a very quick and efficient way. - Peter Jennewein - for his model 30, which serves me as part of my teststand - and his cool remark about how you make an ordinary diskette - drive working and how to connect it to an IBM-diskette port. - Johannes Gutenberg-Universitaet, Mainz & - Institut fuer Kernphysik, Mainz Microtron (MAMI) - for the offered space, the link, placed on the central - homepage and the space to store and offer the driver and - related material and the free working times, which allow - me to answer all your e-mail. - - 8 Trademarks - ------------ - IBM, PS/2, OS/2, Microchannel are registered trademarks of International - Business Machines Corporation - - MS-DOS is a registered trademark of Microsoft Corporation - - Microware, OS-9 are registered trademarks of Microware Systems - - 9 Disclaimer - ------------ - Beside the GNU General Public License and the dependent disclaimers and disclaimers - concerning the Linux-kernel in special, this SCSI-driver comes without any - warranty. Its functionality is tested as good as possible on certain - machines and combinations of computer hardware, which does not exclude, - that data loss or severe damage of hardware is possible while using this - part of software on some arbitrary computer hardware or in combination - with other software packages. It is highly recommended to make backup - copies of your data before using this software. Furthermore, personal - injuries by hardware defects, that could be caused by this SCSI-driver are - not excluded and it is highly recommended to handle this driver with a - maximum of carefulness. - - This driver supports hardware, produced by International Business Machines - Corporation (IBM). - ------- -Michael Lang -(langa2@kph.uni-mainz.de) diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt index 21e5798..2bfd6f6 100644 --- a/Documentation/scsi/scsi-parameters.txt +++ b/Documentation/scsi/scsi-parameters.txt @@ -37,9 +37,6 @@ parameters may be changed at runtime by the command eata= [HW,SCSI] - fd_mcs= [HW,SCSI] - See header of drivers/scsi/fd_mcs.c. - fdomain= [HW,SCSI] See header of drivers/scsi/fdomain.c. @@ -48,9 +45,6 @@ parameters may be changed at runtime by the command gvp11= [HW,SCSI] - ibmmcascsi= [HW,MCA,SCSI] IBM MicroChannel SCSI adapter - See Documentation/mca.txt. - in2000= [HW,SCSI] See header of drivers/scsi/in2000.c. diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt index a340b18..2b06aba 100644 --- a/Documentation/scsi/scsi_mid_low_api.txt +++ b/Documentation/scsi/scsi_mid_low_api.txt @@ -30,7 +30,7 @@ the motherboard (or both). Some aic7xxx based HBAs are dual controllers and thus represent two hosts. Like most modern HBAs, each aic7xxx host has its own PCI device address. [The one-to-one correspondence between a SCSI host and a PCI device is common but not required (e.g. with -ISA or MCA adapters).] +ISA adapters).] The SCSI mid level isolates an LLD from other layers such as the SCSI upper layer drivers and the block layer. diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt index d2f72ae..a416479 100644 --- a/Documentation/security/Smack.txt +++ b/Documentation/security/Smack.txt @@ -15,7 +15,7 @@ at hand. Smack consists of three major components: - The kernel - - A start-up script and a few modified applications + - Basic utilities, which are helpful but not required - Configuration data The kernel component of Smack is implemented as a Linux @@ -23,37 +23,28 @@ Security Modules (LSM) module. It requires netlabel and works best with file systems that support extended attributes, although xattr support is not strictly required. It is safe to run a Smack kernel under a "vanilla" distribution. + Smack kernels use the CIPSO IP option. Some network configurations are intolerant of IP options and can impede access to systems that use them as Smack does. -The startup script etc-init.d-smack should be installed -in /etc/init.d/smack and should be invoked early in the -start-up process. On Fedora rc5.d/S02smack is recommended. -This script ensures that certain devices have the correct -Smack attributes and loads the Smack configuration if -any is defined. This script invokes two programs that -ensure configuration data is properly formatted. These -programs are /usr/sbin/smackload and /usr/sin/smackcipso. -The system will run just fine without these programs, -but it will be difficult to set access rules properly. - -A version of "ls" that provides a "-M" option to display -Smack labels on long listing is available. +The current git repositories for Smack user space are: -A hacked version of sshd that allows network logins by users -with specific Smack labels is available. This version does -not work for scp. You must set the /etc/ssh/sshd_config -line: - UsePrivilegeSeparation no + git@gitorious.org:meego-platform-security/smackutil.git + git@gitorious.org:meego-platform-security/libsmack.git -The format of /etc/smack/usr is: +These should make and install on most modern distributions. +There are three commands included in smackutil: - username smack +smackload - properly formats data for writing to /smack/load +smackcipso - properly formats data for writing to /smack/cipso +chsmack - display or set Smack extended attribute values In keeping with the intent of Smack, configuration data is minimal and not strictly required. The most important configuration step is mounting the smackfs pseudo filesystem. +If smackutil is installed the startup script will take care +of this, but it can be manually as well. Add this line to /etc/fstab: @@ -61,19 +52,148 @@ Add this line to /etc/fstab: and create the /smack directory for mounting. -Smack uses extended attributes (xattrs) to store file labels. -The command to set a Smack label on a file is: +Smack uses extended attributes (xattrs) to store labels on filesystem +objects. The attributes are stored in the extended attribute security +name space. A process must have CAP_MAC_ADMIN to change any of these +attributes. + +The extended attributes that Smack uses are: + +SMACK64 + Used to make access control decisions. In almost all cases + the label given to a new filesystem object will be the label + of the process that created it. +SMACK64EXEC + The Smack label of a process that execs a program file with + this attribute set will run with this attribute's value. +SMACK64MMAP + Don't allow the file to be mmapped by a process whose Smack + label does not allow all of the access permitted to a process + with the label contained in this attribute. This is a very + specific use case for shared libraries. +SMACK64TRANSMUTE + Can only have the value "TRUE". If this attribute is present + on a directory when an object is created in the directory and + the Smack rule (more below) that permitted the write access + to the directory includes the transmute ("t") mode the object + gets the label of the directory instead of the label of the + creating process. If the object being created is a directory + the SMACK64TRANSMUTE attribute is set as well. +SMACK64IPIN + This attribute is only available on file descriptors for sockets. + Use the Smack label in this attribute for access control + decisions on packets being delivered to this socket. +SMACK64IPOUT + This attribute is only available on file descriptors for sockets. + Use the Smack label in this attribute for access control + decisions on packets coming from this socket. + +There are multiple ways to set a Smack label on a file: # attr -S -s SMACK64 -V "value" path + # chsmack -a value path -NOTE: Smack labels are limited to 23 characters. The attr command - does not enforce this restriction and can be used to set - invalid Smack labels on files. - -If you don't do anything special all users will get the floor ("_") -label when they log in. If you do want to log in via the hacked ssh -at other labels use the attr command to set the smack value on the -home directory and its contents. +A process can see the smack label it is running with by +reading /proc/self/attr/current. A process with CAP_MAC_ADMIN +can set the process smack by writing there. + +Most Smack configuration is accomplished by writing to files +in the smackfs filesystem. This pseudo-filesystem is usually +mounted on /smack. + +access + This interface reports whether a subject with the specified + Smack label has a particular access to an object with a + specified Smack label. Write a fixed format access rule to + this file. The next read will indicate whether the access + would be permitted. The text will be either "1" indicating + access, or "0" indicating denial. +access2 + This interface reports whether a subject with the specified + Smack label has a particular access to an object with a + specified Smack label. Write a long format access rule to + this file. The next read will indicate whether the access + would be permitted. The text will be either "1" indicating + access, or "0" indicating denial. +ambient + This contains the Smack label applied to unlabeled network + packets. +cipso + This interface allows a specific CIPSO header to be assigned + to a Smack label. The format accepted on write is: + "%24s%4d%4d"["%4d"]... + The first string is a fixed Smack label. The first number is + the level to use. The second number is the number of categories. + The following numbers are the categories. + "level-3-cats-5-19 3 2 5 19" +cipso2 + This interface allows a specific CIPSO header to be assigned + to a Smack label. The format accepted on write is: + "%s%4d%4d"["%4d"]... + The first string is a long Smack label. The first number is + the level to use. The second number is the number of categories. + The following numbers are the categories. + "level-3-cats-5-19 3 2 5 19" +direct + This contains the CIPSO level used for Smack direct label + representation in network packets. +doi + This contains the CIPSO domain of interpretation used in + network packets. +load + This interface allows access control rules in addition to + the system defined rules to be specified. The format accepted + on write is: + "%24s%24s%5s" + where the first string is the subject label, the second the + object label, and the third the requested access. The access + string may contain only the characters "rwxat-", and specifies + which sort of access is allowed. The "-" is a placeholder for + permissions that are not allowed. The string "r-x--" would + specify read and execute access. Labels are limited to 23 + characters in length. +load2 + This interface allows access control rules in addition to + the system defined rules to be specified. The format accepted + on write is: + "%s %s %s" + where the first string is the subject label, the second the + object label, and the third the requested access. The access + string may contain only the characters "rwxat-", and specifies + which sort of access is allowed. The "-" is a placeholder for + permissions that are not allowed. The string "r-x--" would + specify read and execute access. +load-self + This interface allows process specific access rules to be + defined. These rules are only consulted if access would + otherwise be permitted, and are intended to provide additional + restrictions on the process. The format is the same as for + the load interface. +load-self2 + This interface allows process specific access rules to be + defined. These rules are only consulted if access would + otherwise be permitted, and are intended to provide additional + restrictions on the process. The format is the same as for + the load2 interface. +logging + This contains the Smack logging state. +mapped + This contains the CIPSO level used for Smack mapped label + representation in network packets. +netlabel + This interface allows specific internet addresses to be + treated as single label hosts. Packets are sent to single + label hosts without CIPSO headers, but only from processes + that have Smack write access to the host label. All packets + received from single label hosts are given the specified + label. The format accepted on write is: + "%d.%d.%d.%d label" or "%d.%d.%d.%d/%d label". +onlycap + This contains the label processes must have for CAP_MAC_ADMIN + and CAP_MAC_OVERRIDE to be effective. If this file is empty + 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. You can add access rules in /etc/smack/accesses. They take the form: @@ -83,10 +203,6 @@ access is a combination of the letters rwxa which specify the kind of access permitted a subject with subjectlabel on an object with objectlabel. If there is no rule no access is allowed. -A process can see the smack label it is running with by -reading /proc/self/attr/current. A privileged process can -set the process smack by writing there. - Look for additional programs on http://schaufler-ca.com From the Smack Whitepaper: @@ -186,7 +302,7 @@ team. Smack labels are unstructured, case sensitive, and the only operation ever performed on them is comparison for equality. Smack labels cannot contain unprintable characters, the "/" (slash), the "\" (backslash), the "'" (quote) and '"' (double-quote) characters. -Smack labels cannot begin with a '-', which is reserved for special options. +Smack labels cannot begin with a '-'. This is reserved for special options. There are some predefined labels: @@ -194,7 +310,7 @@ There are some predefined labels: ^ Pronounced "hat", a single circumflex character. * Pronounced "star", a single asterisk character. ? Pronounced "huh", a single question mark character. - @ Pronounced "Internet", a single at sign character. + @ Pronounced "web", a single at sign character. Every task on a Smack system is assigned a label. System tasks, such as init(8) and systems daemons, are run with the floor ("_") label. User tasks @@ -246,13 +362,14 @@ The format of an access rule is: Where subject-label is the Smack label of the task, object-label is the Smack label of the thing being accessed, and access is a string specifying the sort -of access allowed. The Smack labels are limited to 23 characters. The access -specification is searched for letters that describe access modes: +of access allowed. The access specification is searched for letters that +describe access modes: a: indicates that append access should be granted. r: indicates that read access should be granted. w: indicates that write access should be granted. x: indicates that execute access should be granted. + t: indicates that the rule requests transmutation. Uppercase values for the specification letters are allowed as well. Access mode specifications can be in any order. Examples of acceptable rules @@ -273,7 +390,7 @@ Examples of unacceptable rules are: Spaces are not allowed in labels. Since a subject always has access to files with the same label specifying a rule for that case is pointless. Only -valid letters (rwxaRWXA) and the dash ('-') character are allowed in +valid letters (rwxatRWXAT) and the dash ('-') character are allowed in access specifications. The dash is a placeholder, so "a-r" is the same as "ar". A lone dash is used to specify that no access should be allowed. @@ -297,6 +414,13 @@ but not any of its attributes by the circumstance of having read access to the containing directory but not to the differently labeled file. This is an artifact of the file name being data in the directory, not a part of the file. +If a directory is marked as transmuting (SMACK64TRANSMUTE=TRUE) and the +access rule that allows a process to create an object in that directory +includes 't' access the label assigned to the new object will be that +of the directory, not the creating process. This makes it much easier +for two processes with different labels to share data without granting +access to all of their files. + IPC objects, message queues, semaphore sets, and memory segments exist in flat namespaces and access requests are only required to match the object in question. diff --git a/Documentation/security/Yama.txt b/Documentation/security/Yama.txt index a9511f1..e369de2 100644 --- a/Documentation/security/Yama.txt +++ b/Documentation/security/Yama.txt @@ -34,7 +34,7 @@ parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID" still work as root). -For software that has defined application-specific relationships +In mode 1, software that has defined application-specific relationships between a debugging process and its inferior (crash handlers, etc), prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which other process (and its descendents) are allowed to call PTRACE_ATTACH @@ -46,6 +46,8 @@ restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...) so that any otherwise allowed process (even those in external pid namespaces) may attach. +These restrictions do not change how ptrace via PTRACE_TRACEME operates. + The sysctl settings are: 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other @@ -60,6 +62,12 @@ The sysctl settings are: inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare an allowed debugger PID to call PTRACE_ATTACH on the inferior. +2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace + with PTRACE_ATTACH. + +3 - no attach: no processes may use ptrace with PTRACE_ATTACH. Once set, + this sysctl cannot be changed to a lower value. + The original children-only logic was based on the restrictions in grsecurity. ============================================================== diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt index d389acd..aa0dbd7 100644 --- a/Documentation/security/keys.txt +++ b/Documentation/security/keys.txt @@ -805,6 +805,23 @@ The keyctl syscall functions are: kernel and resumes executing userspace. + (*) Invalidate a key. + + long keyctl(KEYCTL_INVALIDATE, key_serial_t key); + + This function marks a key as being invalidated and then wakes up the + garbage collector. The garbage collector immediately removes invalidated + keys from all keyrings and deletes the key when its reference count + reaches zero. + + Keys that are marked invalidated become invisible to normal key operations + immediately, though they are still visible in /proc/keys until deleted + (they're marked with an 'i' flag). + + A process must have search permission on the key for this function to be + successful. + + =============== KERNEL SERVICES =============== diff --git a/Documentation/serial/stallion.txt b/Documentation/serial/stallion.txt index 5509091..4d798c0 100644 --- a/Documentation/serial/stallion.txt +++ b/Documentation/serial/stallion.txt @@ -20,10 +20,10 @@ There are two drivers that work with the different families of Stallion multiport serial boards. One is for the Stallion smart boards - that is EasyIO, EasyConnection 8/32 and EasyConnection 8/64-PCI, the other for the true Stallion intelligent multiport boards - EasyConnection 8/64 -(ISA, EISA, MCA), EasyConnection/RA-PCI, ONboard and Brumby. +(ISA, EISA), EasyConnection/RA-PCI, ONboard and Brumby. If you are using any of the Stallion intelligent multiport boards (Brumby, -ONboard, EasyConnection 8/64 (ISA, EISA, MCA), EasyConnection/RA-PCI) with +ONboard, EasyConnection 8/64 (ISA, EISA), EasyConnection/RA-PCI) with Linux you will need to get the driver utility package. This contains a firmware loader and the firmware images necessary to make the devices operate. @@ -40,7 +40,7 @@ If you are using the EasyIO, EasyConnection 8/32 or EasyConnection 8/64-PCI boards then you don't need this package, although it does have a serial stats display program. -If you require DIP switch settings, EISA or MCA configuration files, or any +If you require DIP switch settings, or EISA configuration files, or any other information related to Stallion boards then have a look at Stallion's web pages at http://www.stallion.com. @@ -51,13 +51,13 @@ web pages at http://www.stallion.com. The drivers can be used as loadable modules or compiled into the kernel. You can choose which when doing a "config" on the kernel. -All ISA, EISA and MCA boards that you want to use need to be configured into +All ISA, and EISA boards that you want to use need to be configured into the driver(s). All PCI boards will be automatically detected when you load the driver - so they do not need to be entered into the driver(s) configuration structure. Note that kernel PCI support is required to use PCI boards. -There are two methods of configuring ISA, EISA and MCA boards into the drivers. +There are two methods of configuring ISA and EISA boards into the drivers. If using the driver as a loadable module then the simplest method is to pass the driver configuration as module arguments. The other method is to modify the driver source to add configuration lines for each board in use. @@ -71,12 +71,12 @@ That makes things pretty simple to get going. 2.1 MODULE DRIVER CONFIGURATION: The simplest configuration for modules is to use the module load arguments -to configure any ISA, EISA or MCA boards. PCI boards are automatically +to configure any ISA or EISA boards. PCI boards are automatically detected, so do not need any additional configuration at all. -If using EasyIO, EasyConnection 8/32 ISA or MCA, or EasyConnection 8/63-PCI +If using EasyIO, EasyConnection 8/32 ISA, or EasyConnection 8/63-PCI boards then use the "stallion" driver module, Otherwise if you are using -an EasyConnection 8/64 ISA, EISA or MCA, EasyConnection/RA-PCI, ONboard, +an EasyConnection 8/64 ISA or EISA, EasyConnection/RA-PCI, ONboard, Brumby or original Stallion board then use the "istallion" driver module. Typically to load up the smart board driver use: @@ -146,7 +146,7 @@ on each system boot. Typically configuration files are put in the 2.2 STATIC DRIVER CONFIGURATION: For static driver configuration you need to modify the driver source code. -Entering ISA, EISA and MCA boards into the driver(s) configuration structure +Entering ISA and EISA boards into the driver(s) configuration structure involves editing the driver(s) source file. It's pretty easy if you follow the instructions below. Both drivers can support up to 4 boards. The smart card driver (the stallion.c driver) supports any combination of EasyIO and @@ -157,7 +157,7 @@ supports any combination of ONboards, Brumbys, Stallions and EasyConnection To set up the driver(s) for the boards that you want to use you need to edit the appropriate driver file and add configuration entries. -If using EasyIO or EasyConnection 8/32 ISA or MCA boards, +If using EasyIO or EasyConnection 8/32 ISA boards, In drivers/char/stallion.c: - find the definition of the stl_brdconf array (of structures) near the top of the file @@ -243,7 +243,7 @@ change it on the board. On EasyIO and EasyConnection 8/32 boards the IRQ is software programmable, so if there is a conflict you may need to change the IRQ used for a board. There are no interrupts to worry about for ONboard, Brumby or EasyConnection 8/64 -(ISA, EISA and MCA) boards. The memory region on EasyConnection 8/64 and +(ISA and EISA) boards. The memory region on EasyConnection 8/64 and ONboard boards is software programmable, but not on the Brumby boards. diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 8c16d50..4e4d0bc 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -875,8 +875,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. setup before initializing the codecs. This option is available only when CONFIG_SND_HDA_PATCH_LOADER=y is set. See HD-Audio.txt for details. - beep_mode - Selects the beep registration mode (0=off, 1=on, 2= - dynamic registration via mute switch on/off); the default + beep_mode - Selects the beep registration mode (0=off, 1=on); default value is set via CONFIG_SND_HDA_INPUT_BEEP_MODE kconfig. [Single (global) options] @@ -1545,7 +1544,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module for sound cards based on the C-Media CMI8786/8787/8788 chip: * Asound A-8788 - * Asus Xonar DG + * Asus Xonar DG/DGX * AuzenTech X-Meridian * AuzenTech X-Meridian 2G * Bgears b-Enspirer diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 03f7897..7456360 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -15,19 +15,24 @@ ALC260 ALC262 ====== - N/A + inv-dmic Inverted internal mic workaround ALC267/268 ========== - N/A + inv-dmic Inverted internal mic workaround -ALC269 +ALC269/270/275/276/280/282 ====== laptop-amic Laptops with analog-mic input laptop-dmic Laptops with digital-mic input + alc269-dmic Enable ALC269(VA) digital mic workaround + alc271-dmic Enable ALC271X digital mic workaround + inv-dmic Inverted internal mic workaround + lenovo-dock Enables docking station I/O for some Lenovos ALC662/663/272 ============== + mario Chromebook mario model fixup asus-mode1 ASUS asus-mode2 ASUS asus-mode3 ASUS @@ -36,6 +41,7 @@ ALC662/663/272 asus-mode6 ASUS asus-mode7 ASUS asus-mode8 ASUS + inv-dmic Inverted internal mic workaround ALC680 ====== @@ -46,6 +52,7 @@ ALC882/883/885/888/889 acer-aspire-4930g Acer Aspire 4930G/5930G/6530G/6930G/7730G acer-aspire-8930g Acer Aspire 8330G/6935G acer-aspire Acer Aspire others + inv-dmic Inverted internal mic workaround ALC861/660 ========== diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt index c83a835..90e9b3a 100644 --- a/Documentation/sound/alsa/compress_offload.txt +++ b/Documentation/sound/alsa/compress_offload.txt @@ -18,7 +18,7 @@ processing. Support for such hardware has not been very good in Linux, mostly because of a lack of a generic API available in the mainline kernel. -Rather than requiring a compability break with an API change of the +Rather than requiring a compatibility break with an API change of the ALSA PCM interface, a new 'Compressed Data' API is introduced to provide a control and data-streaming interface for audio DSPs. diff --git a/Documentation/sound/oss/ALS b/Documentation/sound/oss/ALS index d01ffbf..bf10bed 100644 --- a/Documentation/sound/oss/ALS +++ b/Documentation/sound/oss/ALS @@ -57,10 +57,10 @@ The resulting sound driver will provide the following capabilities: DSP/PCM/audio out (L&R), FM (L&R) and Mic in (mono). Jonathan Woithe -jwoithe@physics.adelaide.edu.au +jwoithe@just42.net 30 March 1998 Modified 2000-02-26 by Dave Forrest, drf5n@virginia.edu to add ALS100/ALS200 Modified 2000-04-10 by Paul Laufer, pelaufer@csupomona.edu to add ISAPnP info. -Modified 2000-11-19 by Jonathan Woithe, jwoithe@physics.adelaide.edu.au +Modified 2000-11-19 by Jonathan Woithe, jwoithe@just42.net - updated information for kernel 2.4.x. diff --git a/Documentation/sparc/README-2.5 b/Documentation/sparc/README-2.5 deleted file mode 100644 index 806fe49..0000000 --- a/Documentation/sparc/README-2.5 +++ /dev/null @@ -1,46 +0,0 @@ -BTFIXUP -------- - -To build new kernels you have to issue "make image". The ready kernel -in ELF format is placed in arch/sparc/boot/image. Explanation is below. - -BTFIXUP is a unique feature of Linux/sparc among other architectures, -developed by Jakub Jelinek (I think... Obviously David S. Miller took -part, too). It allows to boot the same kernel at different -sub-architectures, such as sun4c, sun4m, sun4d, where SunOS uses -different kernels. This feature is convinient for people who you move -disks between boxes and for distrution builders. - -To function, BTFIXUP must link the kernel "in the draft" first, -analyze the result, write a special stub code based on that, and -build the final kernel with the stub (btfix.o). - -Kai Germaschewski improved the build system of the kernel in the 2.5 series -significantly. Unfortunately, the traditional way of running the draft -linking from architecture specific Makefile before the actual linking -by generic Makefile is nearly impossible to support properly in the -new build system. Therefore, the way we integrate BTFIXUP with the -build system was changed in 2.5.40. Now, generic Makefile performs -the draft linking and stores the result in file vmlinux. Architecture -specific post-processing invokes BTFIXUP machinery and final linking -in the same way as other architectures do bootstraps. - -Implications of that change are as follows. - -1. Hackers must type "make image" now, instead of just "make", in the same - way as s390 people do now. It is analogous to "make bzImage" on i386. - This does NOT affect sparc64, you continue to use "make" to build sparc64 - kernels. - -2. vmlinux is not the final kernel, so RPM builders have to adjust - their spec files (if they delivered vmlinux for debugging). - System.map generated for vmlinux is still valid. - -3. Scripts that produce a.out images have to be changed. First, if they - invoke make, they have to use "make image". Second, they have to pick up - the new kernel in arch/sparc/boot/image instead of vmlinux. - -4. Since we are compliant with Kai's build system now, make -j is permitted. - --- Pete Zaitcev -zaitcev@yahoo.com diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index f0ab5cf..b0714d8 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -1,4 +1,4 @@ -Everything you ever wanted to know about Linux 2.6 -stable releases. +Everything you ever wanted to know about Linux -stable releases. Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree: @@ -12,6 +12,12 @@ Rules on what kind of patches are accepted, and which ones are not, into the marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical. + - Serious issues as reported by a user of a distribution kernel may also + be considered if they fix a notable performance or interactivity issue. + As these fixes are not as obvious and have a higher risk of a subtle + regression they should only be submitted by a distribution kernel + maintainer and include an addendum linking to a bugzilla entry if it + exists and additional information on the user-visible impact. - New device IDs and quirks are also accepted. - No "theoretical race condition" issues, unless an explanation of how the race can be exploited is also provided. @@ -36,10 +42,10 @@ Procedure for submitting patches to the -stable tree: cherry-picked than this can be specified in the following format in the sign-off area: - Cc: <stable@vger.kernel.org> # .32.x: a1f84a3: sched: Check for idle - Cc: <stable@vger.kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle - Cc: <stable@vger.kernel.org> # .32.x: fd21073: sched: Fix affinity logic - Cc: <stable@vger.kernel.org> # .32.x + Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle + Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle + Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic + Cc: <stable@vger.kernel.org> # 3.3.x Signed-off-by: Ingo Molnar <mingo@elte.hu> The tag sequence has the meaning of: @@ -73,6 +79,15 @@ Review cycle: security kernel team, and not go through the normal review cycle. Contact the kernel security team for more details on this procedure. +Trees: + + - The queues of patches, for both completed versions and in progress + versions can be found at: + http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git + - The finalized and tagged releases of all stable kernels can be found + in separate branches per version at: + http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git + Review committee: diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt index d93f3c0..9f5263d 100644 --- a/Documentation/static-keys.txt +++ b/Documentation/static-keys.txt @@ -235,7 +235,7 @@ label case adds: 6 (mov) + 2 (test) + 2 (jne) = 10 - 5 (5 byte jump 0) = 5 addition bytes. If we then include the padding bytes, the jump label code saves, 16 total bytes -of instruction memory for this small fucntion. In this case the non-jump label +of instruction memory for this small function. In this case the non-jump label function is 80 bytes long. Thus, we have have saved 20% of the instruction footprint. We can in fact improve this even further, since the 5-byte no-op really can be a 2-byte no-op since we can reach the branch with a 2-byte jmp. diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt index 88fd7f5..8c235b6 100644 --- a/Documentation/sysctl/fs.txt +++ b/Documentation/sysctl/fs.txt @@ -163,16 +163,22 @@ This value can be used to query and set the core dump mode for setuid or otherwise protected/tainted binaries. The modes are 0 - (default) - traditional behaviour. Any process which has changed - privilege levels or is execute only will not be dumped + privilege levels or is execute only will not be dumped. 1 - (debug) - all processes dump core when possible. The core dump is owned by the current user and no security is applied. This is intended for system debugging situations only. Ptrace is unchecked. + This is insecure as it allows regular users to examine the memory + contents of privileged processes. 2 - (suidsafe) - any binary which normally would not be dumped is dumped - readable by root only. This allows the end user to remove - such a dump but not access it directly. For security reasons - core dumps in this mode will not overwrite one another or - other files. This mode is appropriate when administrators are - attempting to debug problems in a normal environment. + anyway, but only if the "core_pattern" kernel sysctl is set to + either a pipe handler or a fully qualified path. (For more details + on this limitation, see CVE-2006-2451.) This mode is appropriate + when administrators are attempting to debug problems in a normal + environment, and either have a core dump pipe handler that knows + to treat privileged core dumps with care, or specific directory + defined for catching core dumps. If a core dump happens without + a pipe handler or fully qualifid path, a message will be emitted + to syslog warning about the lack of a correct setting. ============================================================== @@ -225,6 +231,13 @@ a queue must be less or equal then msg_max. maximum message size value (it is every message queue's attribute set during its creation). +/proc/sys/fs/mqueue/msg_default is a read/write file for setting/getting the +default number of messages in a queue value if attr parameter of mq_open(2) is +NULL. If it exceed msg_max, the default value is initialized msg_max. + +/proc/sys/fs/mqueue/msgsize_default is a read/write file for setting/getting +the default message size value if attr parameter of mq_open(2) is NULL. If it +exceed msgsize_max, the default value is initialized msgsize_max. 4. /proc/sys/fs/epoll - Configuration options for the epoll interface -------------------------------------------------------- diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index 3201a70..98335b7 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -43,6 +43,13 @@ Values : 1 - enable the JIT 2 - enable the JIT and ask the compiler to emit traces on kernel log. +dev_weight +-------------- + +The maximum number of packets that kernel can handle on a NAPI interrupt, +it's a Per-CPU variable. +Default: 64 + rmem_default ------------ diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index 1733ab9..c087dbc 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -32,7 +32,8 @@ temperature) and throttle appropriate devices. 1.1 thermal zone device interface 1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *name, - int trips, void *devdata, struct thermal_zone_device_ops *ops) + int trips, int mask, void *devdata, + struct thermal_zone_device_ops *ops) This interface function adds a new thermal zone device (sensor) to /sys/class/thermal folder as thermal_zone[0-*]. It tries to bind all the @@ -40,16 +41,17 @@ temperature) and throttle appropriate devices. name: the thermal zone name. trips: the total number of trip points this thermal zone supports. + mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable. devdata: device private data ops: thermal zone device call-backs. .bind: bind the thermal zone device with a thermal cooling device. .unbind: unbind the thermal zone device with a thermal cooling device. .get_temp: get the current temperature of the thermal zone. - .get_mode: get the current mode (user/kernel) of the thermal zone. - - "kernel" means thermal management is done in kernel. - - "user" will prevent kernel thermal driver actions upon trip points + .get_mode: get the current mode (enabled/disabled) of the thermal zone. + - "enabled" means the kernel thermal management is enabled. + - "disabled" will prevent kernel thermal driver action upon trip points so that user applications can take charge of thermal management. - .set_mode: set the mode (user/kernel) of the thermal zone. + .set_mode: set the mode (enabled/disabled) of the thermal zone. .get_trip_type: get the type of certain trip point. .get_trip_temp: get the temperature above which the certain trip point will be fired. @@ -119,6 +121,7 @@ Thermal zone device sys I/F, created once it's registered: |---mode: Working mode of the thermal zone |---trip_point_[0-*]_temp: Trip point temperature |---trip_point_[0-*]_type: Trip point type + |---trip_point_[0-*]_hyst: Hysteresis value for this trip point Thermal cooling device sys I/F, created once it's registered: /sys/class/thermal/cooling_device[0-*]: @@ -167,14 +170,14 @@ temp RO, Required mode - One of the predefined values in [kernel, user]. + One of the predefined values in [enabled, disabled]. This file gives information about the algorithm that is currently managing the thermal zone. It can be either default kernel based algorithm or user space application. - kernel = Thermal management in kernel thermal zone driver. - user = Preventing kernel thermal zone driver actions upon - trip points so that user application can take full - charge of the thermal management. + enabled = enable Kernel Thermal management. + disabled = Preventing kernel thermal zone driver actions upon + trip points so that user application can take full + charge of the thermal management. RW, Optional trip_point_[0-*]_temp @@ -188,6 +191,11 @@ trip_point_[0-*]_type thermal zone. RO, Optional +trip_point_[0-*]_hyst + The hysteresis value for a trip point, represented as an integer + Unit: Celsius + RW, Optional + cdev[0-*] Sysfs link to the thermal cooling device node where the sys I/F for cooling device throttling control represents. @@ -248,7 +256,7 @@ method, the sys I/F structure will be built like this: |thermal_zone1: |---type: acpitz |---temp: 37000 - |---mode: kernel + |---mode: enabled |---trip_point_0_temp: 100000 |---trip_point_0_type: critical |---trip_point_1_temp: 80000 diff --git a/Documentation/trace/uprobetracer.txt b/Documentation/trace/uprobetracer.txt new file mode 100644 index 0000000..24ce682 --- /dev/null +++ b/Documentation/trace/uprobetracer.txt @@ -0,0 +1,113 @@ + Uprobe-tracer: Uprobe-based Event Tracing + ========================================= + Documentation written by Srikar Dronamraju + +Overview +-------- +Uprobe based trace events are similar to kprobe based trace events. +To enable this feature, build your kernel with CONFIG_UPROBE_EVENT=y. + +Similar to the kprobe-event tracer, this doesn't need to be activated via +current_tracer. Instead of that, add probe points via +/sys/kernel/debug/tracing/uprobe_events, and enable it via +/sys/kernel/debug/tracing/events/uprobes/<EVENT>/enabled. + +However unlike kprobe-event tracer, the uprobe event interface expects the +user to calculate the offset of the probepoint in the object + +Synopsis of uprobe_tracer +------------------------- + p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a probe + + GRP : Group name. If omitted, use "uprobes" for it. + EVENT : Event name. If omitted, the event name is generated + based on SYMBOL+offs. + PATH : path to an executable or a library. + SYMBOL[+offs] : Symbol+offset where the probe is inserted. + + FETCHARGS : Arguments. Each probe can have up to 128 args. + %REG : Fetch register REG + +Event Profiling +--------------- + You can check the total number of probe hits and probe miss-hits via +/sys/kernel/debug/tracing/uprobe_profile. + The first column is event name, the second is the number of probe hits, +the third is the number of probe miss-hits. + +Usage examples +-------------- +To add a probe as a new event, write a new definition to uprobe_events +as below. + + echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events + + This sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash + + echo > /sys/kernel/debug/tracing/uprobe_events + + This clears all probe points. + +The following example shows how to dump the instruction pointer and %ax +a register at the probed text address. Here we are trying to probe +function zfree in /bin/zsh + + # cd /sys/kernel/debug/tracing/ + # cat /proc/`pgrep zsh`/maps | grep /bin/zsh | grep r-xp + 00400000-0048a000 r-xp 00000000 08:03 130904 /bin/zsh + # objdump -T /bin/zsh | grep -w zfree + 0000000000446420 g DF .text 0000000000000012 Base zfree + +0x46420 is the offset of zfree in object /bin/zsh that is loaded at +0x00400000. Hence the command to probe would be : + + # echo 'p /bin/zsh:0x46420 %ip %ax' > uprobe_events + +Please note: User has to explicitly calculate the offset of the probepoint +in the object. We can see the events that are registered by looking at the +uprobe_events file. + + # cat uprobe_events + p:uprobes/p_zsh_0x46420 /bin/zsh:0x00046420 arg1=%ip arg2=%ax + +The format of events can be seen by viewing the file events/uprobes/p_zsh_0x46420/format + + # cat events/uprobes/p_zsh_0x46420/format + name: p_zsh_0x46420 + ID: 922 + format: + field:unsigned short common_type; offset:0; size:2; signed:0; + field:unsigned char common_flags; offset:2; size:1; signed:0; + field:unsigned char common_preempt_count; offset:3; size:1; signed:0; + field:int common_pid; offset:4; size:4; signed:1; + field:int common_padding; offset:8; size:4; signed:1; + + field:unsigned long __probe_ip; offset:12; size:4; signed:0; + field:u32 arg1; offset:16; size:4; signed:0; + field:u32 arg2; offset:20; size:4; signed:0; + + print fmt: "(%lx) arg1=%lx arg2=%lx", REC->__probe_ip, REC->arg1, REC->arg2 + +Right after definition, each event is disabled by default. For tracing these +events, you need to enable it by: + + # echo 1 > events/uprobes/enable + +Lets disable the event after sleeping for some time. + # sleep 20 + # echo 0 > events/uprobes/enable + +And you can see the traced information via /sys/kernel/debug/tracing/trace. + + # cat trace + # tracer: nop + # + # TASK-PID CPU# TIMESTAMP FUNCTION + # | | | | | + zsh-24842 [006] 258544.995456: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79 + zsh-24842 [007] 258545.000270: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79 + zsh-24842 [002] 258545.043929: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79 + zsh-24842 [004] 258547.046129: p_zsh_0x46420: (0x446420) arg1=446421 arg2=79 + +Each line shows us probes were triggered for a pid 24842 with ip being +0x446421 and contents of ax register being 79. diff --git a/Documentation/usb/dwc3.txt b/Documentation/usb/dwc3.txt index 7b590ed..1d02c01 100644 --- a/Documentation/usb/dwc3.txt +++ b/Documentation/usb/dwc3.txt @@ -28,7 +28,7 @@ Please pick something while reading :) none - primary handler of the EP-interrupt - reads the event and tries to process it. Everything that requries + reads the event and tries to process it. Everything that requires sleeping is handed over to the Thread. The event is saved in an per-endpoint data-structure. We probably have to pay attention not to process events once we diff --git a/Documentation/usb/functionfs.txt b/Documentation/usb/functionfs.txt new file mode 100644 index 0000000..eaaaea0 --- /dev/null +++ b/Documentation/usb/functionfs.txt @@ -0,0 +1,67 @@ +*How FunctionFS works* + +From kernel point of view it is just a composite function with some +unique behaviour. It may be added to an USB configuration only after +the user space driver has registered by writing descriptors and +strings (the user space program has to provide the same information +that kernel level composite functions provide when they are added to +the configuration). + +This in particular means that the composite initialisation functions +may not be in init section (ie. may not use the __init tag). + +From user space point of view it is a file system which when +mounted provides an "ep0" file. User space driver need to +write descriptors and strings to that file. It does not need +to worry about endpoints, interfaces or strings numbers but +simply provide descriptors such as if the function was the +only one (endpoints and strings numbers starting from one and +interface numbers starting from zero). The FunctionFS changes +them as needed also handling situation when numbers differ in +different configurations. + +When descriptors and strings are written "ep#" files appear +(one for each declared endpoint) which handle communication on +a single endpoint. Again, FunctionFS takes care of the real +numbers and changing of the configuration (which means that +"ep1" file may be really mapped to (say) endpoint 3 (and when +configuration changes to (say) endpoint 2)). "ep0" is used +for receiving events and handling setup requests. + +When all files are closed the function disables itself. + +What I also want to mention is that the FunctionFS is designed in such +a way that it is possible to mount it several times so in the end +a gadget could use several FunctionFS functions. The idea is that +each FunctionFS instance is identified by the device name used +when mounting. + +One can imagine a gadget that has an Ethernet, MTP and HID interfaces +where the last two are implemented via FunctionFS. On user space +level it would look like this: + +$ insmod g_ffs.ko idVendor=<ID> iSerialNumber=<string> functions=mtp,hid +$ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp +$ ( cd /dev/ffs-mtp && mtp-daemon ) & +$ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid +$ ( cd /dev/ffs-hid && hid-daemon ) & + +On kernel level the gadget checks ffs_data->dev_name to identify +whether it's FunctionFS designed for MTP ("mtp") or HID ("hid"). + +If no "functions" module parameters is supplied, the driver accepts +just one function with any name. + +When "functions" module parameter is supplied, only functions +with listed names are accepted. In particular, if the "functions" +parameter's value is just a one-element list, then the behaviour +is similar to when there is no "functions" at all; however, +only a function with the specified name is accepted. + +The gadget is registered only after all the declared function +filesystems have been mounted and USB descriptors of all functions +have been written to their ep0's. + +Conversely, the gadget is unregistered after the first USB function +closes its endpoints. + diff --git a/Documentation/usb/mass-storage.txt b/Documentation/usb/mass-storage.txt new file mode 100644 index 0000000..e9b9334 --- /dev/null +++ b/Documentation/usb/mass-storage.txt @@ -0,0 +1,226 @@ +* Overview + + Mass Storage Gadget (or MSG) acts as a USB Mass Storage device, + appearing to the host as a disk or a CD-ROM drive. It supports + multiple logical units (LUNs). Backing storage for each LUN is + provided by a regular file or a block device, access can be limited + to read-only, and gadget can indicate that it is removable and/or + CD-ROM (the latter implies read-only access). + + Its requirements are modest; only a bulk-in and a bulk-out endpoint + are needed. The memory requirement amounts to two 16K buffers. + Support is included for full-speed, high-speed and SuperSpeed + operation. + + Note that the driver is slightly non-portable in that it assumes + a single memory/DMA buffer will be useable for bulk-in and bulk-out + endpoints. With most device controllers this is not an issue, but + there may be some with hardware restrictions that prevent a buffer + from being used by more than one endpoint. + + This document describes how to use the gadget from user space, its + relation to mass storage function (or MSF) and different gadgets + using it, and how it differs from File Storage Gadget (or FSG). It + will talk only briefly about how to use MSF within composite + gadgets. + +* Module parameters + + The mass storage gadget accepts the following mass storage specific + module parameters: + + - file=filename[,filename...] + + This parameter lists paths to files or block devices used for + backing storage for each logical unit. There may be at most + FSG_MAX_LUNS (8) LUNs set. If more files are specified, they will + be silently ignored. See also “luns” parameter. + + *BEWARE* that if a file is used as a backing storage, it may not + be modified by any other process. This is because the host + assumes the data does not change without its knowledge. It may be + read, but (if the logical unit is writable) due to buffering on + the host side, the contents are not well defined. + + The size of the logical unit will be rounded down to a full + logical block. The logical block size is 2048 bytes for LUNs + simulating CD-ROM, block size of the device if the backing file is + a block device, or 512 bytes otherwise. + + - removable=b[,b...] + + This parameter specifies whether each logical unit should be + removable. “b” here is either “y”, “Y” or “1” for true or “n”, + “N” or “0” for false. + + If this option is set for a logical unit, gadget will accept an + “eject” SCSI request (Start/Stop Unit). When it is sent, the + backing file will be closed to simulate ejection and the logical + unit will not be mountable by the host until a new backing file is + specified by userspace on the device (see “sysfs entries” + section). + + If a logical unit is not removable (the default), a backing file + must be specified for it with the “file” parameter as the module + is loaded. The same applies if the module is built in, no + exceptions. + + The default value of the flag is false, *HOWEVER* it used to be + true. This has been changed to better match File Storage Gadget + and because it seems like a saner default after all. Thus to + maintain compatibility with older kernels, it's best to specify + the default values. Also, if one relied on old default, explicit + “n” needs to be specified now. + + Note that “removable” means the logical unit's media can be + ejected or removed (as is true for a CD-ROM drive or a card + reader). It does *not* mean that the entire gadget can be + unplugged from the host; the proper term for that is + “hot-unpluggable”. + + - cdrom=b[,b...] + + This parameter specifies whether each logical unit should simulate + CD-ROM. The default is false. + + - ro=b[,b...] + + This parameter specifies whether each logical unit should be + reported as read only. This will prevent host from modifying the + backing files. + + Note that if this flag for given logical unit is false but the + backing file could not be opened in read/write mode, the gadget + will fall back to read only mode anyway. + + The default value for non-CD-ROM logical units is false; for + logical units simulating CD-ROM it is forced to true. + + - nofua=b[,b...] + + This parameter specifies whether FUA flag should be ignored in SCSI + Write10 and Write12 commands sent to given logical units. + + MS Windows mounts removable storage in “Removal optimised mode” by + default. All the writes to the media are synchronous, which is + achieved by setting the FUA (Force Unit Access) bit in SCSI + Write(10,12) commands. This forces each write to wait until the + data has actually been written out and prevents I/O requests + aggregation in block layer dramatically decreasing performance. + + Note that this may mean that if the device is powered from USB and + the user unplugs the device without unmounting it first (which at + least some Windows users do), the data may be lost. + + The default value is false. + + - luns=N + + This parameter specifies number of logical units the gadget will + have. It is limited by FSG_MAX_LUNS (8) and higher value will be + capped. + + If this parameter is provided, and the number of files specified + in “file” argument is greater then the value of “luns”, all excess + files will be ignored. + + If this parameter is not present, the number of logical units will + be deduced from the number of files specified in the “file” + parameter. If the file parameter is missing as well, one is + assumed. + + - stall=b + + Specifies whether the gadget is allowed to halt bulk endpoints. + The default is determined according to the type of USB device + controller, but usually true. + + In addition to the above, the gadget also accepts the following + parameters defined by the composite framework (they are common to + all composite gadgets so just a quick listing): + + - idVendor -- USB Vendor ID (16 bit integer) + - idProduct -- USB Product ID (16 bit integer) + - bcdDevice -- USB Device version (BCD) (16 bit integer) + - iManufacturer -- USB Manufacturer string (string) + - iProduct -- USB Product string (string) + - iSerialNumber -- SerialNumber string (sting) + +* sysfs entries + + For each logical unit, the gadget creates a directory in the sysfs + hierarchy. Inside of it the following three files are created: + + - file + + When read it returns the path to the backing file for the given + logical unit. If there is no backing file (possible only if the + logical unit is removable), the content is empty. + + When written into, it changes the backing file for given logical + unit. This change can be performed even if given logical unit is + not specified as removable (but that may look strange to the + host). It may fail, however, if host disallowed medium removal + with the Prevent-Allow Medium Removal SCSI command. + + - ro + + Reflects the state of ro flag for the given logical unit. It can + be read any time, and written to when there is no backing file + open for given logical unit. + + - nofua + + Reflects the state of nofua flag for given logical unit. It can + be read and written. + + Other then those, as usual, the values of module parameters can be + read from /sys/module/g_mass_storage/parameters/* files. + +* Other gadgets using mass storage function + + The Mass Storage Gadget uses the Mass Storage Function to handle + mass storage protocol. As a composite function, MSF may be used by + other gadgets as well (eg. g_multi and acm_ms). + + All of the information in previous sections are valid for other + gadgets using MSF, except that support for mass storage related + module parameters may be missing, or the parameters may have + a prefix. To figure out whether any of this is true one needs to + consult the gadget's documentation or its source code. + + For examples of how to include mass storage function in gadgets, one + may take a look at mass_storage.c, acm_ms.c and multi.c (sorted by + complexity). + +* Relation to file storage gadget + + The Mass Storage Function and thus the Mass Storage Gadget has been + based on the File Storage Gadget. The difference between the two is + that MSG is a composite gadget (ie. uses the composite framework) + while file storage gadget is a traditional gadget. From userspace + point of view this distinction does not really matter, but from + kernel hacker's point of view, this means that (i) MSG does not + duplicate code needed for handling basic USB protocol commands and + (ii) MSF can be used in any other composite gadget. + + Because of that, File Storage Gadget has been deprecated and + scheduled to be removed in Linux 3.8. All users need to transition + to the Mass Storage Gadget by that time. The two gadgets behave + mostly the same from the outside except: + + 1. In FSG the “removable” and “cdrom” module parameters set the flag + for all logical units whereas in MSG they accept a list of y/n + values for each logical unit. If one uses only a single logical + unit this does not matter, but if there are more, the y/n value + needs to be repeated for each logical unit. + + 2. FSG's “serial”, “vendor”, “product” and “release” module + parameters are handled in MSG by the composite layer's parameters + named respectively: “iSerialnumber”, “idVendor”, “idProduct” and + “bcdDevice”. + + 3. MSG does not support FSG's test mode, thus “transport”, + “protocol” and “buflen” FSG's module parameters are not + supported. MSG always uses SCSI protocol with bulk only + transport mode and 16 KiB buffers. diff --git a/Documentation/usb/wusb-cbaf b/Documentation/usb/wusb-cbaf index 426ddaa..8b3d43e 100644 --- a/Documentation/usb/wusb-cbaf +++ b/Documentation/usb/wusb-cbaf @@ -36,7 +36,7 @@ COMMAND/ARGS are get-cdid DEVICE - Get the device ID associated to the HOST-CHDI we sent with + Get the device ID associated to the HOST-CHID we sent with 'set-chid'. We might not know about it. set-cc DEVICE diff --git a/Documentation/video4linux/README.cpia2 b/Documentation/video4linux/README.cpia2 index ce8213d..38e742f 100644 --- a/Documentation/video4linux/README.cpia2 +++ b/Documentation/video4linux/README.cpia2 @@ -12,7 +12,7 @@ gqcam application to view this stream. The driver is implemented as two kernel modules. The cpia2 module contains the camera functions and the V4L interface. The cpia2_usb module contains usb specific functions. The main reason for this was the size of the -module was getting out of hand, so I separted them. It is not likely that +module was getting out of hand, so I separated them. It is not likely that there will be a parallel port version. FEATURES: diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 6386f8c..bf33aaa 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2,6 +2,7 @@ The Definitive KVM (Kernel-based Virtual Machine) API Documentation =================================================================== 1. General description +---------------------- The kvm API is a set of ioctls that are issued to control various aspects of a virtual machine. The ioctls belong to three classes @@ -23,7 +24,9 @@ of a virtual machine. The ioctls belong to three classes Only run vcpu ioctls from the same thread that was used to create the vcpu. + 2. File descriptors +------------------- The kvm API is centered around file descriptors. An initial open("/dev/kvm") obtains a handle to the kvm subsystem; this handle @@ -41,7 +44,9 @@ not cause harm to the host, their actual behavior is not guaranteed by the API. The only supported use is one virtual machine per process, and one vcpu per thread. + 3. Extensions +------------- As of Linux 2.6.22, the KVM ABI has been stabilized: no backward incompatible change are allowed. However, there is an extension @@ -53,7 +58,9 @@ Instead, kvm defines extension identifiers and a facility to query whether a particular extension identifier is available. If it is, a set of ioctls is available for application use. + 4. API description +------------------ This section describes ioctls that can be used to control kvm guests. For each ioctl, the following information is provided along with a @@ -75,6 +82,7 @@ description: Returns: the return value. General error numbers (EBADF, ENOMEM, EINVAL) are not detailed, but errors with specific meanings are. + 4.1 KVM_GET_API_VERSION Capability: basic @@ -90,6 +98,7 @@ supported. Applications should refuse to run if KVM_GET_API_VERSION returns a value other than 12. If this check passes, all ioctls described as 'basic' will be available. + 4.2 KVM_CREATE_VM Capability: basic @@ -109,6 +118,7 @@ In order to create user controlled virtual machines on S390, check KVM_CAP_S390_UCONTROL and use the flag KVM_VM_S390_UCONTROL as privileged user (CAP_SYS_ADMIN). + 4.3 KVM_GET_MSR_INDEX_LIST Capability: basic @@ -135,6 +145,7 @@ Note: if kvm indicates supports MCE (KVM_CAP_MCE), then the MCE bank MSRs are not returned in the MSR list, as different vcpus can have a different number of banks, as set via the KVM_X86_SETUP_MCE ioctl. + 4.4 KVM_CHECK_EXTENSION Capability: basic @@ -149,6 +160,7 @@ receives an integer that describes the extension availability. Generally 0 means no and 1 means yes, but some extensions may report additional information in the integer return value. + 4.5 KVM_GET_VCPU_MMAP_SIZE Capability: basic @@ -161,6 +173,7 @@ The KVM_RUN ioctl (cf.) communicates with userspace via a shared memory region. This ioctl returns the size of that region. See the KVM_RUN documentation for details. + 4.6 KVM_SET_MEMORY_REGION Capability: basic @@ -171,6 +184,7 @@ Returns: 0 on success, -1 on error This ioctl is obsolete and has been removed. + 4.7 KVM_CREATE_VCPU Capability: basic @@ -223,6 +237,7 @@ machines, the resulting vcpu fd can be memory mapped at page offset KVM_S390_SIE_PAGE_OFFSET in order to obtain a memory map of the virtual cpu's hardware control block. + 4.8 KVM_GET_DIRTY_LOG (vm ioctl) Capability: basic @@ -246,6 +261,7 @@ since the last call to this ioctl. Bit 0 is the first page in the memory slot. Ensure the entire structure is cleared to avoid padding issues. + 4.9 KVM_SET_MEMORY_ALIAS Capability: basic @@ -256,6 +272,7 @@ Returns: 0 (success), -1 (error) This ioctl is obsolete and has been removed. + 4.10 KVM_RUN Capability: basic @@ -272,6 +289,7 @@ obtained by mmap()ing the vcpu fd at offset 0, with the size given by KVM_GET_VCPU_MMAP_SIZE. The parameter block is formatted as a 'struct kvm_run' (see below). + 4.11 KVM_GET_REGS Capability: basic @@ -292,6 +310,7 @@ struct kvm_regs { __u64 rip, rflags; }; + 4.12 KVM_SET_REGS Capability: basic @@ -304,6 +323,7 @@ Writes the general purpose registers into the vcpu. See KVM_GET_REGS for the data structure. + 4.13 KVM_GET_SREGS Capability: basic @@ -331,6 +351,7 @@ interrupt_bitmap is a bitmap of pending external interrupts. At most one bit may be set. This interrupt has been acknowledged by the APIC but not yet injected into the cpu core. + 4.14 KVM_SET_SREGS Capability: basic @@ -342,6 +363,7 @@ Returns: 0 on success, -1 on error Writes special registers into the vcpu. See KVM_GET_SREGS for the data structures. + 4.15 KVM_TRANSLATE Capability: basic @@ -365,6 +387,7 @@ struct kvm_translation { __u8 pad[5]; }; + 4.16 KVM_INTERRUPT Capability: basic @@ -413,6 +436,7 @@ c) KVM_INTERRUPT_SET_LEVEL Note that any value for 'irq' other than the ones stated above is invalid and incurs unexpected behavior. + 4.17 KVM_DEBUG_GUEST Capability: basic @@ -423,6 +447,7 @@ Returns: -1 on error Support for this has been removed. Use KVM_SET_GUEST_DEBUG instead. + 4.18 KVM_GET_MSRS Capability: basic @@ -451,6 +476,7 @@ Application code should set the 'nmsrs' member (which indicates the size of the entries array) and the 'index' member of each array entry. kvm will fill in the 'data' member. + 4.19 KVM_SET_MSRS Capability: basic @@ -466,6 +492,7 @@ Application code should set the 'nmsrs' member (which indicates the size of the entries array), and the 'index' and 'data' members of each array entry. + 4.20 KVM_SET_CPUID Capability: basic @@ -494,6 +521,7 @@ struct kvm_cpuid { struct kvm_cpuid_entry entries[0]; }; + 4.21 KVM_SET_SIGNAL_MASK Capability: basic @@ -516,6 +544,7 @@ struct kvm_signal_mask { __u8 sigset[0]; }; + 4.22 KVM_GET_FPU Capability: basic @@ -541,6 +570,7 @@ struct kvm_fpu { __u32 pad2; }; + 4.23 KVM_SET_FPU Capability: basic @@ -566,6 +596,7 @@ struct kvm_fpu { __u32 pad2; }; + 4.24 KVM_CREATE_IRQCHIP Capability: KVM_CAP_IRQCHIP @@ -579,6 +610,7 @@ ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23 only go to the IOAPIC. On ia64, a IOSAPIC is created. + 4.25 KVM_IRQ_LINE Capability: KVM_CAP_IRQCHIP @@ -600,6 +632,7 @@ struct kvm_irq_level { __u32 level; /* 0 or 1 */ }; + 4.26 KVM_GET_IRQCHIP Capability: KVM_CAP_IRQCHIP @@ -621,6 +654,7 @@ struct kvm_irqchip { } chip; }; + 4.27 KVM_SET_IRQCHIP Capability: KVM_CAP_IRQCHIP @@ -642,6 +676,7 @@ struct kvm_irqchip { } chip; }; + 4.28 KVM_XEN_HVM_CONFIG Capability: KVM_CAP_XEN_HVM @@ -666,6 +701,7 @@ struct kvm_xen_hvm_config { __u8 pad2[30]; }; + 4.29 KVM_GET_CLOCK Capability: KVM_CAP_ADJUST_CLOCK @@ -684,6 +720,7 @@ struct kvm_clock_data { __u32 pad[9]; }; + 4.30 KVM_SET_CLOCK Capability: KVM_CAP_ADJUST_CLOCK @@ -702,6 +739,7 @@ struct kvm_clock_data { __u32 pad[9]; }; + 4.31 KVM_GET_VCPU_EVENTS Capability: KVM_CAP_VCPU_EVENTS @@ -741,6 +779,7 @@ struct kvm_vcpu_events { KVM_VCPUEVENT_VALID_SHADOW may be set in the flags field to signal that interrupt.shadow contains a valid state. Otherwise, this field is undefined. + 4.32 KVM_SET_VCPU_EVENTS Capability: KVM_CAP_VCPU_EVENTS @@ -767,6 +806,7 @@ If KVM_CAP_INTR_SHADOW is available, KVM_VCPUEVENT_VALID_SHADOW can be set in the flags field to signal that interrupt.shadow contains a valid state and shall be written into the VCPU. + 4.33 KVM_GET_DEBUGREGS Capability: KVM_CAP_DEBUGREGS @@ -785,6 +825,7 @@ struct kvm_debugregs { __u64 reserved[9]; }; + 4.34 KVM_SET_DEBUGREGS Capability: KVM_CAP_DEBUGREGS @@ -798,6 +839,7 @@ Writes debug registers into the vcpu. See KVM_GET_DEBUGREGS for the data structure. The flags field is unused yet and must be cleared on entry. + 4.35 KVM_SET_USER_MEMORY_REGION Capability: KVM_CAP_USER_MEM @@ -844,6 +886,7 @@ It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl. The KVM_SET_MEMORY_REGION does not allow fine grained control over memory allocation and is deprecated. + 4.36 KVM_SET_TSS_ADDR Capability: KVM_CAP_SET_TSS_ADDR @@ -862,6 +905,7 @@ This ioctl is required on Intel-based hosts. This is needed on Intel hardware because of a quirk in the virtualization implementation (see the internals documentation when it pops into existence). + 4.37 KVM_ENABLE_CAP Capability: KVM_CAP_ENABLE_CAP @@ -897,6 +941,7 @@ function properly, this is the place to put them. __u8 pad[64]; }; + 4.38 KVM_GET_MP_STATE Capability: KVM_CAP_MP_STATE @@ -927,6 +972,7 @@ Possible values are: This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel irqchip, the multiprocessing state must be maintained by userspace. + 4.39 KVM_SET_MP_STATE Capability: KVM_CAP_MP_STATE @@ -941,6 +987,7 @@ arguments. This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel irqchip, the multiprocessing state must be maintained by userspace. + 4.40 KVM_SET_IDENTITY_MAP_ADDR Capability: KVM_CAP_SET_IDENTITY_MAP_ADDR @@ -959,6 +1006,7 @@ This ioctl is required on Intel-based hosts. This is needed on Intel hardware because of a quirk in the virtualization implementation (see the internals documentation when it pops into existence). + 4.41 KVM_SET_BOOT_CPU_ID Capability: KVM_CAP_SET_BOOT_CPU_ID @@ -971,6 +1019,7 @@ Define which vcpu is the Bootstrap Processor (BSP). Values are the same as the vcpu id in KVM_CREATE_VCPU. If this ioctl is not called, the default is vcpu 0. + 4.42 KVM_GET_XSAVE Capability: KVM_CAP_XSAVE @@ -985,6 +1034,7 @@ struct kvm_xsave { This ioctl would copy current vcpu's xsave struct to the userspace. + 4.43 KVM_SET_XSAVE Capability: KVM_CAP_XSAVE @@ -999,6 +1049,7 @@ struct kvm_xsave { This ioctl would copy userspace's xsave struct to the kernel. + 4.44 KVM_GET_XCRS Capability: KVM_CAP_XCRS @@ -1022,6 +1073,7 @@ struct kvm_xcrs { This ioctl would copy current vcpu's xcrs to the userspace. + 4.45 KVM_SET_XCRS Capability: KVM_CAP_XCRS @@ -1045,6 +1097,7 @@ struct kvm_xcrs { This ioctl would set vcpu's xcr to the value userspace specified. + 4.46 KVM_GET_SUPPORTED_CPUID Capability: KVM_CAP_EXT_CPUID @@ -1119,6 +1172,7 @@ support. Instead it is reported via if that returns true and you use KVM_CREATE_IRQCHIP, or if you emulate the feature in userspace, then you can enable the feature for KVM_SET_CPUID2. + 4.47 KVM_PPC_GET_PVINFO Capability: KVM_CAP_PPC_GET_PVINFO @@ -1142,6 +1196,7 @@ of 4 instructions that make up a hypercall. If any additional field gets added to this structure later on, a bit for that additional piece of information will be set in the flags bitmap. + 4.48 KVM_ASSIGN_PCI_DEVICE Capability: KVM_CAP_DEVICE_ASSIGNMENT @@ -1185,6 +1240,7 @@ Only PCI header type 0 devices with PCI BAR resources are supported by device assignment. The user requesting this ioctl must have read/write access to the PCI sysfs resource files associated with the device. + 4.49 KVM_DEASSIGN_PCI_DEVICE Capability: KVM_CAP_DEVICE_DEASSIGNMENT @@ -1198,6 +1254,7 @@ Ends PCI device assignment, releasing all associated resources. See KVM_CAP_DEVICE_ASSIGNMENT for the data structure. Only assigned_dev_id is used in kvm_assigned_pci_dev to identify the device. + 4.50 KVM_ASSIGN_DEV_IRQ Capability: KVM_CAP_ASSIGN_DEV_IRQ @@ -1231,6 +1288,7 @@ The following flags are defined: It is not valid to specify multiple types per host or guest IRQ. However, the IRQ type of host and guest can differ or can even be null. + 4.51 KVM_DEASSIGN_DEV_IRQ Capability: KVM_CAP_ASSIGN_DEV_IRQ @@ -1245,6 +1303,7 @@ See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified by assigned_dev_id, flags must correspond to the IRQ type specified on KVM_ASSIGN_DEV_IRQ. Partial deassignment of host or guest IRQ is allowed. + 4.52 KVM_SET_GSI_ROUTING Capability: KVM_CAP_IRQ_ROUTING @@ -1293,6 +1352,7 @@ struct kvm_irq_routing_msi { __u32 pad; }; + 4.53 KVM_ASSIGN_SET_MSIX_NR Capability: KVM_CAP_DEVICE_MSIX @@ -1314,6 +1374,7 @@ struct kvm_assigned_msix_nr { #define KVM_MAX_MSIX_PER_DEV 256 + 4.54 KVM_ASSIGN_SET_MSIX_ENTRY Capability: KVM_CAP_DEVICE_MSIX @@ -1332,7 +1393,8 @@ struct kvm_assigned_msix_entry { __u16 padding[3]; }; -4.54 KVM_SET_TSC_KHZ + +4.55 KVM_SET_TSC_KHZ Capability: KVM_CAP_TSC_CONTROL Architectures: x86 @@ -1343,7 +1405,8 @@ Returns: 0 on success, -1 on error Specifies the tsc frequency for the virtual machine. The unit of the frequency is KHz. -4.55 KVM_GET_TSC_KHZ + +4.56 KVM_GET_TSC_KHZ Capability: KVM_CAP_GET_TSC_KHZ Architectures: x86 @@ -1355,7 +1418,8 @@ Returns the tsc frequency of the guest. The unit of the return value is KHz. If the host has unstable tsc this ioctl returns -EIO instead as an error. -4.56 KVM_GET_LAPIC + +4.57 KVM_GET_LAPIC Capability: KVM_CAP_IRQCHIP Architectures: x86 @@ -1371,7 +1435,8 @@ struct kvm_lapic_state { Reads the Local APIC registers and copies them into the input argument. The data format and layout are the same as documented in the architecture manual. -4.57 KVM_SET_LAPIC + +4.58 KVM_SET_LAPIC Capability: KVM_CAP_IRQCHIP Architectures: x86 @@ -1387,7 +1452,8 @@ struct kvm_lapic_state { Copies the input argument into the the Local APIC registers. The data format and layout are the same as documented in the architecture manual. -4.58 KVM_IOEVENTFD + +4.59 KVM_IOEVENTFD Capability: KVM_CAP_IOEVENTFD Architectures: all @@ -1417,7 +1483,8 @@ The following flags are defined: If datamatch flag is set, the event will be signaled only if the written value to the registered address is equal to datamatch in struct kvm_ioeventfd. -4.59 KVM_DIRTY_TLB + +4.60 KVM_DIRTY_TLB Capability: KVM_CAP_SW_TLB Architectures: ppc @@ -1449,7 +1516,8 @@ The "num_dirty" field is a performance hint for KVM to determine whether it should skip processing the bitmap and just invalidate everything. It must be set to the number of set bits in the bitmap. -4.60 KVM_ASSIGN_SET_INTX_MASK + +4.61 KVM_ASSIGN_SET_INTX_MASK Capability: KVM_CAP_PCI_2_3 Architectures: x86 @@ -1482,6 +1550,7 @@ See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified by assigned_dev_id. In the flags field, only KVM_DEV_ASSIGN_MASK_INTX is evaluated. + 4.62 KVM_CREATE_SPAPR_TCE Capability: KVM_CAP_SPAPR_TCE @@ -1517,6 +1586,7 @@ the entries written by kernel-handled H_PUT_TCE calls, and also lets userspace update the TCE table directly which is useful in some circumstances. + 4.63 KVM_ALLOCATE_RMA Capability: KVM_CAP_PPC_RMA @@ -1549,6 +1619,7 @@ is supported; 2 if the processor requires all virtual machines to have an RMA, or 1 if the processor can use an RMA but doesn't require it, because it supports the Virtual RMA (VRMA) facility. + 4.64 KVM_NMI Capability: KVM_CAP_USER_NMI @@ -1574,6 +1645,7 @@ following algorithm: Some guests configure the LINT1 NMI input to cause a panic, aiding in debugging. + 4.65 KVM_S390_UCAS_MAP Capability: KVM_CAP_S390_UCONTROL @@ -1593,6 +1665,7 @@ This ioctl maps the memory at "user_addr" with the length "length" to the vcpu's address space starting at "vcpu_addr". All parameters need to be alligned by 1 megabyte. + 4.66 KVM_S390_UCAS_UNMAP Capability: KVM_CAP_S390_UCONTROL @@ -1612,6 +1685,7 @@ This ioctl unmaps the memory in the vcpu's address space starting at "vcpu_addr" with the length "length". The field "user_addr" is ignored. All parameters need to be alligned by 1 megabyte. + 4.67 KVM_S390_VCPU_FAULT Capability: KVM_CAP_S390_UCONTROL @@ -1628,6 +1702,7 @@ table upfront. This is useful to handle validity intercepts for user controlled virtual machines to fault in the virtual cpu's lowcore pages prior to calling the KVM_RUN ioctl. + 4.68 KVM_SET_ONE_REG Capability: KVM_CAP_ONE_REG @@ -1653,6 +1728,7 @@ registers, find a list below: | | PPC | KVM_REG_PPC_HIOR | 64 + 4.69 KVM_GET_ONE_REG Capability: KVM_CAP_ONE_REG @@ -1669,7 +1745,244 @@ at the memory location pointed to by "addr". The list of registers accessible using this interface is identical to the list in 4.64. + +4.70 KVM_KVMCLOCK_CTRL + +Capability: KVM_CAP_KVMCLOCK_CTRL +Architectures: Any that implement pvclocks (currently x86 only) +Type: vcpu ioctl +Parameters: None +Returns: 0 on success, -1 on error + +This signals to the host kernel that the specified guest is being paused by +userspace. The host will set a flag in the pvclock structure that is checked +from the soft lockup watchdog. The flag is part of the pvclock structure that +is shared between guest and host, specifically the second bit of the flags +field of the pvclock_vcpu_time_info structure. It will be set exclusively by +the host and read/cleared exclusively by the guest. The guest operation of +checking and clearing the flag must an atomic operation so +load-link/store-conditional, or equivalent must be used. There are two cases +where the guest will clear the flag: when the soft lockup watchdog timer resets +itself or when a soft lockup is detected. This ioctl can be called any time +after pausing the vcpu, but before it is resumed. + + +4.71 KVM_SIGNAL_MSI + +Capability: KVM_CAP_SIGNAL_MSI +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_msi (in) +Returns: >0 on delivery, 0 if guest blocked the MSI, and -1 on error + +Directly inject a MSI message. Only valid with in-kernel irqchip that handles +MSI messages. + +struct kvm_msi { + __u32 address_lo; + __u32 address_hi; + __u32 data; + __u32 flags; + __u8 pad[16]; +}; + +No flags are defined so far. The corresponding field must be 0. + + +4.71 KVM_CREATE_PIT2 + +Capability: KVM_CAP_PIT2 +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_pit_config (in) +Returns: 0 on success, -1 on error + +Creates an in-kernel device model for the i8254 PIT. This call is only valid +after enabling in-kernel irqchip support via KVM_CREATE_IRQCHIP. The following +parameters have to be passed: + +struct kvm_pit_config { + __u32 flags; + __u32 pad[15]; +}; + +Valid flags are: + +#define KVM_PIT_SPEAKER_DUMMY 1 /* emulate speaker port stub */ + +PIT timer interrupts may use a per-VM kernel thread for injection. If it +exists, this thread will have a name of the following pattern: + +kvm-pit/<owner-process-pid> + +When running a guest with elevated priorities, the scheduling parameters of +this thread may have to be adjusted accordingly. + +This IOCTL replaces the obsolete KVM_CREATE_PIT. + + +4.72 KVM_GET_PIT2 + +Capability: KVM_CAP_PIT_STATE2 +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_pit_state2 (out) +Returns: 0 on success, -1 on error + +Retrieves the state of the in-kernel PIT model. Only valid after +KVM_CREATE_PIT2. The state is returned in the following structure: + +struct kvm_pit_state2 { + struct kvm_pit_channel_state channels[3]; + __u32 flags; + __u32 reserved[9]; +}; + +Valid flags are: + +/* disable PIT in HPET legacy mode */ +#define KVM_PIT_FLAGS_HPET_LEGACY 0x00000001 + +This IOCTL replaces the obsolete KVM_GET_PIT. + + +4.73 KVM_SET_PIT2 + +Capability: KVM_CAP_PIT_STATE2 +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_pit_state2 (in) +Returns: 0 on success, -1 on error + +Sets the state of the in-kernel PIT model. Only valid after KVM_CREATE_PIT2. +See KVM_GET_PIT2 for details on struct kvm_pit_state2. + +This IOCTL replaces the obsolete KVM_SET_PIT. + + +4.74 KVM_PPC_GET_SMMU_INFO + +Capability: KVM_CAP_PPC_GET_SMMU_INFO +Architectures: powerpc +Type: vm ioctl +Parameters: None +Returns: 0 on success, -1 on error + +This populates and returns a structure describing the features of +the "Server" class MMU emulation supported by KVM. +This can in turn be used by userspace to generate the appropariate +device-tree properties for the guest operating system. + +The structure contains some global informations, followed by an +array of supported segment page sizes: + + struct kvm_ppc_smmu_info { + __u64 flags; + __u32 slb_size; + __u32 pad; + struct kvm_ppc_one_seg_page_size sps[KVM_PPC_PAGE_SIZES_MAX_SZ]; + }; + +The supported flags are: + + - KVM_PPC_PAGE_SIZES_REAL: + When that flag is set, guest page sizes must "fit" the backing + store page sizes. When not set, any page size in the list can + be used regardless of how they are backed by userspace. + + - KVM_PPC_1T_SEGMENTS + The emulated MMU supports 1T segments in addition to the + standard 256M ones. + +The "slb_size" field indicates how many SLB entries are supported + +The "sps" array contains 8 entries indicating the supported base +page sizes for a segment in increasing order. Each entry is defined +as follow: + + struct kvm_ppc_one_seg_page_size { + __u32 page_shift; /* Base page shift of segment (or 0) */ + __u32 slb_enc; /* SLB encoding for BookS */ + struct kvm_ppc_one_page_size enc[KVM_PPC_PAGE_SIZES_MAX_SZ]; + }; + +An entry with a "page_shift" of 0 is unused. Because the array is +organized in increasing order, a lookup can stop when encoutering +such an entry. + +The "slb_enc" field provides the encoding to use in the SLB for the +page size. The bits are in positions such as the value can directly +be OR'ed into the "vsid" argument of the slbmte instruction. + +The "enc" array is a list which for each of those segment base page +size provides the list of supported actual page sizes (which can be +only larger or equal to the base page size), along with the +corresponding encoding in the hash PTE. Similarily, the array is +8 entries sorted by increasing sizes and an entry with a "0" shift +is an empty entry and a terminator: + + struct kvm_ppc_one_page_size { + __u32 page_shift; /* Page shift (or 0) */ + __u32 pte_enc; /* Encoding in the HPTE (>>12) */ + }; + +The "pte_enc" field provides a value that can OR'ed into the hash +PTE's RPN field (ie, it needs to be shifted left by 12 to OR it +into the hash PTE second double word). + +4.75 KVM_IRQFD + +Capability: KVM_CAP_IRQFD +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_irqfd (in) +Returns: 0 on success, -1 on error + +Allows setting an eventfd to directly trigger a guest interrupt. +kvm_irqfd.fd specifies the file descriptor to use as the eventfd and +kvm_irqfd.gsi specifies the irqchip pin toggled by this event. When +an event is tiggered on the eventfd, an interrupt is injected into +the guest using the specified gsi pin. The irqfd is removed using +the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd +and kvm_irqfd.gsi. + +4.76 KVM_PPC_ALLOCATE_HTAB + +Capability: KVM_CAP_PPC_ALLOC_HTAB +Architectures: powerpc +Type: vm ioctl +Parameters: Pointer to u32 containing hash table order (in/out) +Returns: 0 on success, -1 on error + +This requests the host kernel to allocate an MMU hash table for a +guest using the PAPR paravirtualization interface. This only does +anything if the kernel is configured to use the Book 3S HV style of +virtualization. Otherwise the capability doesn't exist and the ioctl +returns an ENOTTY error. The rest of this description assumes Book 3S +HV. + +There must be no vcpus running when this ioctl is called; if there +are, it will do nothing and return an EBUSY error. + +The parameter is a pointer to a 32-bit unsigned integer variable +containing the order (log base 2) of the desired size of the hash +table, which must be between 18 and 46. On successful return from the +ioctl, it will have been updated with the order of the hash table that +was allocated. + +If no hash table has been allocated when any vcpu is asked to run +(with the KVM_RUN ioctl), the host kernel will allocate a +default-sized hash table (16 MB). + +If this ioctl is called when a hash table has already been allocated, +the kernel will clear out the existing hash table (zero all HPTEs) and +return the hash table order in the parameter. (If the guest is using +the virtualized real-mode area (VRMA) facility, the kernel will +re-create the VMRA HPTEs on the next KVM_RUN of any vcpu.) + + 5. The kvm_run structure +------------------------ Application code obtains a pointer to the kvm_run structure by mmap()ing a vcpu fd. From that point, application code can control @@ -1910,7 +2223,9 @@ and usually define the validity of a groups of registers. (e.g. one bit }; + 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 @@ -1926,6 +2241,7 @@ The following information is provided along with the description: Returns: the return value. General error numbers (EBADF, ENOMEM, EINVAL) are not detailed, but errors with specific meanings are. + 6.1 KVM_CAP_PPC_OSI Architectures: ppc @@ -1939,6 +2255,7 @@ between the guest and the host. When this capability is enabled, KVM_EXIT_OSI can occur. + 6.2 KVM_CAP_PPC_PAPR Architectures: ppc @@ -1957,6 +2274,7 @@ HTAB invisible to the guest. When this capability is enabled, KVM_EXIT_PAPR_HCALL can occur. + 6.3 KVM_CAP_SW_TLB Architectures: ppc diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt index 8820685..83afe65 100644 --- a/Documentation/virtual/kvm/cpuid.txt +++ b/Documentation/virtual/kvm/cpuid.txt @@ -10,11 +10,15 @@ a guest. KVM cpuid functions are: function: KVM_CPUID_SIGNATURE (0x40000000) -returns : eax = 0, +returns : eax = 0x40000001, ebx = 0x4b4d564b, ecx = 0x564b4d56, edx = 0x4d. Note that this value in ebx, ecx and edx corresponds to the string "KVMKVMKVM". +The value in eax corresponds to the maximum cpuid function present in this leaf, +and will be updated if more functions are added in the future. +Note also that old hosts set eax value to 0x0. This should +be interpreted as if the value was 0x40000001. This function queries the presence of KVM cpuid leafs. diff --git a/Documentation/virtual/kvm/locking.txt b/Documentation/virtual/kvm/locking.txt index 3b4cd3b..41b7ac9 100644 --- a/Documentation/virtual/kvm/locking.txt +++ b/Documentation/virtual/kvm/locking.txt @@ -6,7 +6,129 @@ KVM Lock Overview (to be written) -2. Reference +2: Exception +------------ + +Fast page fault: + +Fast page fault is the fast path which fixes the guest page fault out of +the mmu-lock on x86. Currently, the page fault can be fast only if the +shadow page table is present and it is caused by write-protect, that means +we just need change the W bit of the spte. + +What we use to avoid all the race is the SPTE_HOST_WRITEABLE bit and +SPTE_MMU_WRITEABLE bit on the spte: +- SPTE_HOST_WRITEABLE means the gfn is writable on host. +- SPTE_MMU_WRITEABLE means the gfn is writable on mmu. The bit is set when + the gfn is writable on guest mmu and it is not write-protected by shadow + page write-protection. + +On fast page fault path, we will use cmpxchg to atomically set the spte W +bit if spte.SPTE_HOST_WRITEABLE = 1 and spte.SPTE_WRITE_PROTECT = 1, this +is safe because whenever changing these bits can be detected by cmpxchg. + +But we need carefully check these cases: +1): The mapping from gfn to pfn +The mapping from gfn to pfn may be changed since we can only ensure the pfn +is not changed during cmpxchg. This is a ABA problem, for example, below case +will happen: + +At the beginning: +gpte = gfn1 +gfn1 is mapped to pfn1 on host +spte is the shadow page table entry corresponding with gpte and +spte = pfn1 + + VCPU 0 VCPU0 +on fast page fault path: + + old_spte = *spte; + pfn1 is swapped out: + spte = 0; + + pfn1 is re-alloced for gfn2. + + gpte is changed to point to + gfn2 by the guest: + spte = pfn1; + + if (cmpxchg(spte, old_spte, old_spte+W) + mark_page_dirty(vcpu->kvm, gfn1) + OOPS!!! + +We dirty-log for gfn1, that means gfn2 is lost in dirty-bitmap. + +For direct sp, we can easily avoid it since the spte of direct sp is fixed +to gfn. For indirect sp, before we do cmpxchg, we call gfn_to_pfn_atomic() +to pin gfn to pfn, because after gfn_to_pfn_atomic(): +- We have held the refcount of pfn that means the pfn can not be freed and + be reused for another gfn. +- The pfn is writable that means it can not be shared between different gfns + by KSM. + +Then, we can ensure the dirty bitmaps is correctly set for a gfn. + +Currently, to simplify the whole things, we disable fast page fault for +indirect shadow page. + +2): Dirty bit tracking +In the origin code, the spte can be fast updated (non-atomically) if the +spte is read-only and the Accessed bit has already been set since the +Accessed bit and Dirty bit can not be lost. + +But it is not true after fast page fault since the spte can be marked +writable between reading spte and updating spte. Like below case: + +At the beginning: +spte.W = 0 +spte.Accessed = 1 + + VCPU 0 VCPU0 +In mmu_spte_clear_track_bits(): + + old_spte = *spte; + + /* 'if' condition is satisfied. */ + if (old_spte.Accssed == 1 && + old_spte.W == 0) + spte = 0ull; + on fast page fault path: + spte.W = 1 + memory write on the spte: + spte.Dirty = 1 + + + else + old_spte = xchg(spte, 0ull) + + + if (old_spte.Accssed == 1) + kvm_set_pfn_accessed(spte.pfn); + if (old_spte.Dirty == 1) + kvm_set_pfn_dirty(spte.pfn); + OOPS!!! + +The Dirty bit is lost in this case. + +In order to avoid this kind of issue, we always treat the spte as "volatile" +if it can be updated out of mmu-lock, see spte_has_volatile_bits(), it means, +the spte is always atomicly updated in this case. + +3): flush tlbs due to spte updated +If the spte is updated from writable to readonly, we should flush all TLBs, +otherwise rmap_write_protect will find a read-only spte, even though the +writable spte might be cached on a CPU's TLB. + +As mentioned before, the spte can be updated to writable out of mmu-lock on +fast page fault path, in order to easily audit the path, we see if TLBs need +be flushed caused by this reason in mmu_spte_update() since this is a common +function to update spte (present -> present). + +Since the spte is "volatile" if it can be updated out of mmu-lock, we always +atomicly update the spte, the race caused by fast page fault can be avoided, +See the comments in spte_has_volatile_bits() and mmu_spte_update(). + +3. Reference ------------ Name: kvm_lock @@ -23,3 +145,9 @@ Arch: x86 Protects: - kvm_arch::{last_tsc_write,last_tsc_nsec,last_tsc_offset} - tsc offset in vmcb Comment: 'raw' because updating the tsc offsets must not be preempted. + +Name: kvm->mmu_lock +Type: spinlock_t +Arch: any +Protects: -shadow page/shadow tlb entry +Comment: it is a spinlock since it is used in mmu notifier. diff --git a/Documentation/virtual/kvm/msr.txt b/Documentation/virtual/kvm/msr.txt index 5031780..7304710 100644 --- a/Documentation/virtual/kvm/msr.txt +++ b/Documentation/virtual/kvm/msr.txt @@ -109,6 +109,10 @@ MSR_KVM_SYSTEM_TIME_NEW: 0x4b564d01 0 | 24 | multiple cpus are guaranteed to | | be monotonic ------------------------------------------------------------- + | | guest vcpu has been paused by + 1 | N/A | the host + | | See 4.70 in api.txt + ------------------------------------------------------------- Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid leaf prior to usage. @@ -219,3 +223,36 @@ MSR_KVM_STEAL_TIME: 0x4b564d03 steal: the amount of time in which this vCPU did not run, in nanoseconds. Time during which the vcpu is idle, will not be reported as steal time. + +MSR_KVM_EOI_EN: 0x4b564d04 + data: Bit 0 is 1 when PV end of interrupt is enabled on the vcpu; 0 + when disabled. Bit 1 is reserved and must be zero. When PV end of + interrupt is enabled (bit 0 set), bits 63-2 hold a 4-byte aligned + physical address of a 4 byte memory area which must be in guest RAM and + must be zeroed. + + The first, least significant bit of 4 byte memory location will be + written to by the hypervisor, typically at the time of interrupt + injection. Value of 1 means that guest can skip writing EOI to the apic + (using MSR or MMIO write); instead, it is sufficient to signal + EOI by clearing the bit in guest memory - this location will + later be polled by the hypervisor. + Value of 0 means that the EOI write is required. + + It is always safe for the guest to ignore the optimization and perform + the APIC EOI write anyway. + + Hypervisor is guaranteed to only modify this least + significant bit while in the current VCPU context, this means that + guest does not need to use either lock prefix or memory ordering + primitives to synchronise with the hypervisor. + + However, hypervisor can set and clear this memory bit at any time: + therefore to make sure hypervisor does not interrupt the + guest and clear the least significant bit in the memory area + in the window between guest testing it to detect + whether it can skip EOI apic write and between guest + clearing it to signal EOI to the hypervisor, + guest must both read the least significant bit in the memory area and + clear it using a single CPU instruction, such as test and clear, or + compare and exchange. diff --git a/Documentation/virtual/kvm/ppc-pv.txt b/Documentation/virtual/kvm/ppc-pv.txt index 6e7c370..4911cf9 100644 --- a/Documentation/virtual/kvm/ppc-pv.txt +++ b/Documentation/virtual/kvm/ppc-pv.txt @@ -109,8 +109,6 @@ The following bits are safe to be set inside the guest: MSR_EE MSR_RI - MSR_CR - MSR_ME If any other bit changes in the MSR, please still use mtmsr(d). diff --git a/Documentation/virtual/virtio-spec.txt b/Documentation/virtual/virtio-spec.txt index da09473..0d6ec85 100644 --- a/Documentation/virtual/virtio-spec.txt +++ b/Documentation/virtual/virtio-spec.txt @@ -1,11 +1,11 @@ [Generated file: see http://ozlabs.org/~rusty/virtio-spec/] Virtio PCI Card Specification -v0.9.1 DRAFT +v0.9.5 DRAFT - -Rusty Russell <rusty@rustcorp.com.au>IBM Corporation (Editor) +Rusty Russell <rusty@rustcorp.com.au> IBM Corporation (Editor) -2011 August 1. +2012 May 7. Purpose and Description @@ -68,11 +68,11 @@ and consists of three parts: +-------------------+-----------------------------------+-----------+ -When the driver wants to send buffers to the device, it puts them -in one or more slots in the descriptor table, and writes the -descriptor indices into the available ring. It then notifies the -device. When the device has finished with the buffers, it writes -the descriptors into the used ring, and sends an interrupt. +When the driver wants to send a buffer to the device, it fills in +a slot in the descriptor table (or chains several together), and +writes the descriptor index into the available ring. It then +notifies the device. When the device has finished a buffer, it +writes the descriptor into the used ring, and sends an interrupt. Specification @@ -106,8 +106,14 @@ for informational purposes by the guest). +----------------------+--------------------+---------------+ | 6 | ioMemory | - | +----------------------+--------------------+---------------+ +| 7 | rpmsg | Appendix H | ++----------------------+--------------------+---------------+ +| 8 | SCSI host | Appendix I | ++----------------------+--------------------+---------------+ | 9 | 9P transport | - | +----------------------+--------------------+---------------+ +| 10 | mac80211 wlan | - | ++----------------------+--------------------+---------------+ Device Configuration @@ -127,7 +133,7 @@ Note that this is possible because while the virtio header is PCI the native endian of the guest (where such distinction is applicable). - Device Initialization Sequence + Device Initialization Sequence<sub:Device-Initialization-Sequence> We start with an overview of device initialization, then expand on the details of the device and how each step is preformed. @@ -177,7 +183,10 @@ The virtio header looks as follows: If MSI-X is enabled for the device, two additional fields -immediately follow this header: +immediately follow this header:[footnote: +ie. once you enable MSI-X on the device, the other fields move. +If you turn it off again, they move back! +] +------------++----------------+--------+ @@ -191,20 +200,6 @@ immediately follow this header: +------------++----------------+--------+ -Finally, if feature bits (VIRTIO_F_FEATURES_HI) this is -immediately followed by two additional fields: - - -+------------++----------------------+---------------------- -| Bits || 32 | 32 -+------------++----------------------+---------------------- -| Read/Write || R | R+W -+------------++----------------------+---------------------- -| Purpose || Device | Guest -| || Features bits 32:63 | Features bits 32:63 -+------------++----------------------+---------------------- - - Immediately following these general headers, there may be device-specific headers: @@ -238,31 +233,25 @@ at least one bit should be set: may be a significant (or infinite) delay before setting this bit. - DRIVER_OK (3) Indicates that the driver is set up and ready to + DRIVER_OK (4) Indicates that the driver is set up and ready to drive the device. - FAILED (8) Indicates that something went wrong in the guest, + FAILED (128) Indicates that something went wrong in the guest, and it has given up on the device. This could be an internal error, or the driver didn't like the device for some reason, or even a fatal error during device operation. The device must be reset before attempting to re-initialize. - Feature Bits + Feature Bits<sub:Feature-Bits> -The least significant 31 bits of the first configuration field -indicates the features that the device supports (the high bit is -reserved, and will be used to indicate the presence of future -feature bits elsewhere). If more than 31 feature bits are -supported, the device indicates so by setting feature bit 31 (see -[cha:Reserved-Feature-Bits]). The bits are allocated as follows: +Thefirst configuration field indicates the features that the +device supports. The bits are allocated as follows: 0 to 23 Feature bits for the specific device type - 24 to 40 Feature bits reserved for extensions to the queue and + 24 to 32 Feature bits reserved for extensions to the queue and feature negotiation mechanisms - 41 to 63 Feature bits reserved for future extensions - For example, feature bit 0 for a network device (i.e. Subsystem Device ID 1) indicates that the device supports checksumming of packets. @@ -286,10 +275,6 @@ will not see that feature bit in the Device Features field and can go into backwards compatibility mode (or, for poor implementations, set the FAILED Device Status bit). -Access to feature bits 32 to 63 is enabled by Guest by setting -feature bit 31. If this bit is unset, Device must assume that all -feature bits > 31 are unset. - Configuration/Queue Vectors When MSI-X capability is present and enabled in the device @@ -324,7 +309,7 @@ success, the previously written value is returned, and on failure, NO_VECTOR is returned. If a mapping failure is detected, the driver can retry mapping with fewervectors, or disable MSI-X. - Virtqueue Configuration + Virtqueue Configuration<sec:Virtqueue-Configuration> As a device can have zero or more virtqueues for bulk data transport (for example, the network driver has two), the driver @@ -587,7 +572,7 @@ and Red Hat under the (3-clause) BSD license so that it can be freely used by all other projects, and is reproduced (with slight variation to remove Linux assumptions) in Appendix A. - Device Operation + Device Operation<sec:Device-Operation> There are two parts to device operation: supplying new buffers to the device, and processing used buffers from the device. As an @@ -813,7 +798,7 @@ vring.used->ring[vq->last_seen_used%vsz]; } - Dealing With Configuration Changes + Dealing With Configuration Changes<sub:Dealing-With-Configuration> Some virtio PCI devices can change the device configuration state, as reflected in the virtio header in the PCI configuration @@ -1260,18 +1245,6 @@ Currently there are five device-independent feature bits defined: driver should ignore the used_event field; the device should ignore the avail_event field; the flags field is used - VIRTIO_F_BAD_FEATURE(30) This feature should never be - negotiated by the guest; doing so is an indication that the - guest is faulty[footnote: -An experimental virtio PCI driver contained in Linux version -2.6.25 had this problem, and this feature bit can be used to -detect it. -] - - VIRTIO_F_FEATURES_HIGH(31) This feature indicates that the - device supports feature bits 32:63. If unset, feature bits - 32:63 are unset. - Appendix C: Network Device The virtio network device is a virtual ethernet card, and is the @@ -1335,11 +1308,17 @@ were required. VIRTIO_NET_F_CTRL_VLAN (19) Control channel VLAN filtering. + VIRTIO_NET_F_GUEST_ANNOUNCE(21) Guest can send gratuitous + packets. + Device configuration layout Two configuration fields are currently defined. The mac address field always exists (though is only valid if VIRTIO_NET_F_MAC is set), and the status field - only exists if VIRTIO_NET_F_STATUS is set. Only one bit is - currently defined for the status field: VIRTIO_NET_S_LINK_UP. #define VIRTIO_NET_S_LINK_UP 1 + only exists if VIRTIO_NET_F_STATUS is set. Two read-only bits + are currently defined for the status field: + VIRTIO_NET_S_LINK_UP and VIRTIO_NET_S_ANNOUNCE. #define VIRTIO_NET_S_LINK_UP 1 + +#define VIRTIO_NET_S_ANNOUNCE 2 @@ -1377,12 +1356,19 @@ struct virtio_net_config { packets by negotating the VIRTIO_NET_F_CSUM feature. This “ checksum offload” is a common feature on modern network cards. - If that feature is negotiated, a driver can use TCP or UDP - segmentation offload by negotiating the VIRTIO_NET_F_HOST_TSO4 - (IPv4 TCP), VIRTIO_NET_F_HOST_TSO6 (IPv6 TCP) and - VIRTIO_NET_F_HOST_UFO (UDP fragmentation) features. It should - not send TCP packets requiring segmentation offload which have - the Explicit Congestion Notification bit set, unless the + If that feature is negotiated[footnote: +ie. VIRTIO_NET_F_HOST_TSO* and VIRTIO_NET_F_HOST_UFO are +dependent on VIRTIO_NET_F_CSUM; a dvice which offers the offload +features must offer the checksum feature, and a driver which +accepts the offload features must accept the checksum feature. +Similar logic applies to the VIRTIO_NET_F_GUEST_TSO4 features +depending on VIRTIO_NET_F_GUEST_CSUM. +], a driver can use TCP or UDP segmentation offload by + negotiating the VIRTIO_NET_F_HOST_TSO4 (IPv4 TCP), + VIRTIO_NET_F_HOST_TSO6 (IPv6 TCP) and VIRTIO_NET_F_HOST_UFO + (UDP fragmentation) features. It should not send TCP packets + requiring segmentation offload which have the Explicit + Congestion Notification bit set, unless the VIRTIO_NET_F_HOST_ECN feature is negotiated.[footnote: This is a common restriction in real, older network cards. ] @@ -1403,7 +1389,7 @@ segmentation, if both guests are amenable. Packets are transmitted by placing them in the transmitq, and buffers for incoming packets are placed in the receiveq. In each -case, the packet itself is preceded by a header: +case, the packet itself is preceeded by a header: struct virtio_net_hdr { @@ -1462,9 +1448,10 @@ It will have a 14 byte ethernet header and 20 byte IP header followed by the TCP header (with the TCP checksum field 16 bytes into that header). csum_start will be 14+20 = 34 (the TCP checksum includes the header), and csum_offset will be 16. The -value in the TCP checksum field will be the sum of the TCP pseudo -header, so that replacing it by the ones' complement checksum of -the TCP header and body will give the correct result. +value in the TCP checksum field should be initialized to the sum +of the TCP pseudo header, so that replacing it by the ones' +complement checksum of the TCP header and body will give the +correct result. ] <enu:If-the-driver>If the driver negotiated @@ -1483,8 +1470,8 @@ Due to various bugs in implementations, this field is not useful as a guarantee of the transport header size. ] - gso_size is the size of the packet beyond that header (ie. - MSS). + gso_size is the maximum size of each packet beyond that header + (ie. MSS). If the driver negotiated the VIRTIO_NET_F_HOST_ECN feature, the VIRTIO_NET_HDR_GSO_ECN bit may be set in “gso_type” as well, @@ -1567,7 +1554,9 @@ Processing packet involves: If the VIRTIO_NET_F_GUEST_TSO4, TSO6 or UFO options were negotiated, then the “gso_type” may be something other than VIRTIO_NET_HDR_GSO_NONE, and the “gso_size” field indicates the - desired MSS (see [enu:If-the-driver]).Control Virtqueue + desired MSS (see [enu:If-the-driver]). + + Control Virtqueue The driver uses the control virtqueue (if VIRTIO_NET_F_VTRL_VQ is negotiated) to send commands to manipulate various features of @@ -1642,7 +1631,7 @@ struct virtio_net_ctrl_mac { The device can filter incoming packets by any number of destination MAC addresses.[footnote: -Since there are no guarantees, it can use a hash filter +Since there are no guarentees, it can use a hash filter orsilently switch to allmulti or promiscuous mode if it is given too many addresses. ] This table is set using the class VIRTIO_NET_CTRL_MAC and the @@ -1665,6 +1654,38 @@ can control a VLAN filter table in the device. Both the VIRTIO_NET_CTRL_VLAN_ADD and VIRTIO_NET_CTRL_VLAN_DEL command take a 16-bit VLAN id as the command-specific-data. + Gratuitous Packet Sending + +If the driver negotiates the VIRTIO_NET_F_GUEST_ANNOUNCE (depends +on VIRTIO_NET_F_CTRL_VQ), it can ask the guest to send gratuitous +packets; this is usually done after the guest has been physically +migrated, and needs to announce its presence on the new network +links. (As hypervisor does not have the knowledge of guest +network configuration (eg. tagged vlan) it is simplest to prod +the guest in this way). + +#define VIRTIO_NET_CTRL_ANNOUNCE 3 + + #define VIRTIO_NET_CTRL_ANNOUNCE_ACK 0 + +The Guest needs to check VIRTIO_NET_S_ANNOUNCE bit in status +field when it notices the changes of device configuration. The +command VIRTIO_NET_CTRL_ANNOUNCE_ACK is used to indicate that +driver has recevied the notification and device would clear the +VIRTIO_NET_S_ANNOUNCE bit in the status filed after it received +this command. + +Processing this notification involves: + + Sending the gratuitous packets or marking there are pending + gratuitous packets to be sent and letting deferred routine to + send them. + + Sending VIRTIO_NET_CTRL_ANNOUNCE_ACK command through control + vq. + + . + Appendix D: Block Device The virtio block device is a simple virtual block device (ie. @@ -1699,8 +1720,6 @@ device except where noted. VIRTIO_BLK_F_FLUSH (9) Cache flush command support. - - Device configuration layout The capacity of the device (expressed in 512-byte sectors) is always present. The availability of the others all depend on various feature bits @@ -1743,8 +1762,6 @@ device except where noted. If the VIRTIO_BLK_F_RO feature is set by the device, any write requests will fail. - - Device Operation The driver queues requests to the virtqueue, and they are used by @@ -1805,7 +1822,7 @@ the FLUSH and FLUSH_OUT types are equivalent, the device does not distinguish between them ]). If the device has VIRTIO_BLK_F_BARRIER feature the high bit (VIRTIO_BLK_T_BARRIER) indicates that this request acts as a -barrier and that all preceding requests must be complete before +barrier and that all preceeding requests must be complete before this one, and all following requests must not be started until this is complete. Note that a barrier does not flush caches in the underlying backend device in host, and thus does not serve as @@ -2118,7 +2135,7 @@ This is historical, and independent of the guest page size Otherwise, the guest may begin to re-use pages previously given to the balloon before the device has acknowledged their - withdrawal. [footnote: + withdrawl. [footnote: In this case, deflation advice is merely a courtesy ] @@ -2198,3 +2215,996 @@ as follows: VIRTIO_BALLOON_S_MEMTOT The total amount of memory available (in bytes). +Appendix H: Rpmsg: Remote Processor Messaging + +Virtio rpmsg devices represent remote processors on the system +which run in asymmetric multi-processing (AMP) configuration, and +which are usually used to offload cpu-intensive tasks from the +main application processor (a typical SoC methodology). + +Virtio is being used to communicate with those remote processors; +empty buffers are placed in one virtqueue for receiving messages, +and non-empty buffers, containing outbound messages, are enqueued +in a second virtqueue for transmission. + +Numerous communication channels can be multiplexed over those two +virtqueues, so different entities, running on the application and +remote processor, can directly communicate in a point-to-point +fashion. + + Configuration + + Subsystem Device ID 7 + + Virtqueues 0:receiveq. 1:transmitq. + + Feature bits + + VIRTIO_RPMSG_F_NS (0) Device sends (and capable of receiving) + name service messages announcing the creation (or + destruction) of a channel:/** + + * struct rpmsg_ns_msg - dynamic name service announcement +message + + * @name: name of remote service that is published + + * @addr: address of remote service that is published + + * @flags: indicates whether service is created or destroyed + + * + + * This message is sent across to publish a new service (or +announce + + * about its removal). When we receives these messages, an +appropriate + + * rpmsg channel (i.e device) is created/destroyed. + + */ + +struct rpmsg_ns_msgoon_config { + + char name[RPMSG_NAME_SIZE]; + + u32 addr; + + u32 flags; + +} __packed; + + + +/** + + * enum rpmsg_ns_flags - dynamic name service announcement flags + + * + + * @RPMSG_NS_CREATE: a new remote service was just created + + * @RPMSG_NS_DESTROY: a remote service was just destroyed + + */ + +enum rpmsg_ns_flags { + + RPMSG_NS_CREATE = 0, + + RPMSG_NS_DESTROY = 1, + +}; + + Device configuration layout + +At his point none currently defined. + + Device Initialization + + The initialization routine should identify the receive and + transmission virtqueues. + + The receive virtqueue should be filled with receive buffers. + + Device Operation + +Messages are transmitted by placing them in the transmitq, and +buffers for inbound messages are placed in the receiveq. In any +case, messages are always preceded by the following header: /** + + * struct rpmsg_hdr - common header for all rpmsg messages + + * @src: source address + + * @dst: destination address + + * @reserved: reserved for future use + + * @len: length of payload (in bytes) + + * @flags: message flags + + * @data: @len bytes of message payload data + + * + + * Every message sent(/received) on the rpmsg bus begins with +this header. + + */ + +struct rpmsg_hdr { + + u32 src; + + u32 dst; + + u32 reserved; + + u16 len; + + u16 flags; + + u8 data[0]; + +} __packed; + +Appendix I: SCSI Host Device + +The virtio SCSI host device groups together one or more virtual +logical units (such as disks), and allows communicating to them +using the SCSI protocol. An instance of the device represents a +SCSI host to which many targets and LUNs are attached. + +The virtio SCSI device services two kinds of requests: + + command requests for a logical unit; + + task management functions related to a logical unit, target or + command. + +The device is also able to send out notifications about added and +removed logical units. Together, these capabilities provide a +SCSI transport protocol that uses virtqueues as the transfer +medium. In the transport protocol, the virtio driver acts as the +initiator, while the virtio SCSI host provides one or more +targets that receive and process the requests. + + Configuration + + Subsystem Device ID 8 + + Virtqueues 0:controlq; 1:eventq; 2..n:request queues. + + Feature bits + + VIRTIO_SCSI_F_INOUT (0) A single request can include both + read-only and write-only data buffers. + + VIRTIO_SCSI_F_HOTPLUG (1) The host should enable + hot-plug/hot-unplug of new LUNs and targets on the SCSI bus. + + Device configuration layout All fields of this configuration + are always available. sense_size and cdb_size are writable by + the guest.struct virtio_scsi_config { + + u32 num_queues; + + u32 seg_max; + + u32 max_sectors; + + u32 cmd_per_lun; + + u32 event_info_size; + + u32 sense_size; + + u32 cdb_size; + + u16 max_channel; + + u16 max_target; + + u32 max_lun; + +}; + + num_queues is the total number of request virtqueues exposed by + the device. The driver is free to use only one request queue, + or it can use more to achieve better performance. + + seg_max is the maximum number of segments that can be in a + command. A bidirectional command can include seg_max input + segments and seg_max output segments. + + max_sectors is a hint to the guest about the maximum transfer + size it should use. + + cmd_per_lun is a hint to the guest about the maximum number of + linked commands it should send to one LUN. The actual value + to be used is the minimum of cmd_per_lun and the virtqueue + size. + + event_info_size is the maximum size that the device will fill + for buffers that the driver places in the eventq. The driver + should always put buffers at least of this size. It is + written by the device depending on the set of negotated + features. + + sense_size is the maximum size of the sense data that the + device will write. The default value is written by the device + and will always be 96, but the driver can modify it. It is + restored to the default when the device is reset. + + cdb_size is the maximum size of the CDB that the driver will + write. The default value is written by the device and will + always be 32, but the driver can likewise modify it. It is + restored to the default when the device is reset. + + max_channel, max_target and max_lun can be used by the driver + as hints to constrain scanning the logical units on the + host.h + + Device Initialization + +The initialization routine should first of all discover the +device's virtqueues. + +If the driver uses the eventq, it should then place at least a +buffer in the eventq. + +The driver can immediately issue requests (for example, INQUIRY +or REPORT LUNS) or task management functions (for example, I_T +RESET). + + Device Operation: request queues + +The driver queues requests to an arbitrary request queue, and +they are used by the device on that same queue. It is the +responsibility of the driver to ensure strict request ordering +for commands placed on different queues, because they will be +consumed with no order constraints. + +Requests have the following format: + +struct virtio_scsi_req_cmd { + + // Read-only + + u8 lun[8]; + + u64 id; + + u8 task_attr; + + u8 prio; + + u8 crn; + + char cdb[cdb_size]; + + char dataout[]; + + // Write-only part + + u32 sense_len; + + u32 residual; + + u16 status_qualifier; + + u8 status; + + u8 response; + + u8 sense[sense_size]; + + char datain[]; + +}; + + + +/* command-specific response values */ + +#define VIRTIO_SCSI_S_OK 0 + +#define VIRTIO_SCSI_S_OVERRUN 1 + +#define VIRTIO_SCSI_S_ABORTED 2 + +#define VIRTIO_SCSI_S_BAD_TARGET 3 + +#define VIRTIO_SCSI_S_RESET 4 + +#define VIRTIO_SCSI_S_BUSY 5 + +#define VIRTIO_SCSI_S_TRANSPORT_FAILURE 6 + +#define VIRTIO_SCSI_S_TARGET_FAILURE 7 + +#define VIRTIO_SCSI_S_NEXUS_FAILURE 8 + +#define VIRTIO_SCSI_S_FAILURE 9 + + + +/* task_attr */ + +#define VIRTIO_SCSI_S_SIMPLE 0 + +#define VIRTIO_SCSI_S_ORDERED 1 + +#define VIRTIO_SCSI_S_HEAD 2 + +#define VIRTIO_SCSI_S_ACA 3 + +The lun field addresses a target and logical unit in the +virtio-scsi device's SCSI domain. The only supported format for +the LUN field is: first byte set to 1, second byte set to target, +third and fourth byte representing a single level LUN structure, +followed by four zero bytes. With this representation, a +virtio-scsi device can serve up to 256 targets and 16384 LUNs per +target. + +The id field is the command identifier (“tag”). + +task_attr, prio and crn should be left to zero. task_attr defines +the task attribute as in the table above, but all task attributes +may be mapped to SIMPLE by the device; crn may also be provided +by clients, but is generally expected to be 0. The maximum CRN +value defined by the protocol is 255, since CRN is stored in an +8-bit integer. + +All of these fields are defined in SAM. They are always +read-only, as are the cdb and dataout field. The cdb_size is +taken from the configuration space. + +sense and subsequent fields are always write-only. The sense_len +field indicates the number of bytes actually written to the sense +buffer. The residual field indicates the residual size, +calculated as “data_length - number_of_transferred_bytes”, for +read or write operations. For bidirectional commands, the +number_of_transferred_bytes includes both read and written bytes. +A residual field that is less than the size of datain means that +the dataout field was processed entirely. A residual field that +exceeds the size of datain means that the dataout field was +processed partially and the datain field was not processed at +all. + +The status byte is written by the device to be the status code as +defined in SAM. + +The response byte is written by the device to be one of the +following: + + VIRTIO_SCSI_S_OK when the request was completed and the status + byte is filled with a SCSI status code (not necessarily + "GOOD"). + + VIRTIO_SCSI_S_OVERRUN if the content of the CDB requires + transferring more data than is available in the data buffers. + + VIRTIO_SCSI_S_ABORTED if the request was cancelled due to an + ABORT TASK or ABORT TASK SET task management function. + + VIRTIO_SCSI_S_BAD_TARGET if the request was never processed + because the target indicated by the lun field does not exist. + + VIRTIO_SCSI_S_RESET if the request was cancelled due to a bus + or device reset (including a task management function). + + VIRTIO_SCSI_S_TRANSPORT_FAILURE if the request failed due to a + problem in the connection between the host and the target + (severed link). + + VIRTIO_SCSI_S_TARGET_FAILURE if the target is suffering a + failure and the guest should not retry on other paths. + + VIRTIO_SCSI_S_NEXUS_FAILURE if the nexus is suffering a failure + but retrying on other paths might yield a different result. + + VIRTIO_SCSI_S_BUSY if the request failed but retrying on the + same path should work. + + VIRTIO_SCSI_S_FAILURE for other host or guest error. In + particular, if neither dataout nor datain is empty, and the + VIRTIO_SCSI_F_INOUT feature has not been negotiated, the + request will be immediately returned with a response equal to + VIRTIO_SCSI_S_FAILURE. + + Device Operation: controlq + +The controlq is used for other SCSI transport operations. +Requests have the following format: + +struct virtio_scsi_ctrl { + + u32 type; + + ... + + u8 response; + +}; + + + +/* response values valid for all commands */ + +#define VIRTIO_SCSI_S_OK 0 + +#define VIRTIO_SCSI_S_BAD_TARGET 3 + +#define VIRTIO_SCSI_S_BUSY 5 + +#define VIRTIO_SCSI_S_TRANSPORT_FAILURE 6 + +#define VIRTIO_SCSI_S_TARGET_FAILURE 7 + +#define VIRTIO_SCSI_S_NEXUS_FAILURE 8 + +#define VIRTIO_SCSI_S_FAILURE 9 + +#define VIRTIO_SCSI_S_INCORRECT_LUN 12 + +The type identifies the remaining fields. + +The following commands are defined: + + Task management function +#define VIRTIO_SCSI_T_TMF 0 + + + +#define VIRTIO_SCSI_T_TMF_ABORT_TASK 0 + +#define VIRTIO_SCSI_T_TMF_ABORT_TASK_SET 1 + +#define VIRTIO_SCSI_T_TMF_CLEAR_ACA 2 + +#define VIRTIO_SCSI_T_TMF_CLEAR_TASK_SET 3 + +#define VIRTIO_SCSI_T_TMF_I_T_NEXUS_RESET 4 + +#define VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET 5 + +#define VIRTIO_SCSI_T_TMF_QUERY_TASK 6 + +#define VIRTIO_SCSI_T_TMF_QUERY_TASK_SET 7 + + + +struct virtio_scsi_ctrl_tmf + +{ + + // Read-only part + + u32 type; + + u32 subtype; + + u8 lun[8]; + + u64 id; + + // Write-only part + + u8 response; + +} + + + +/* command-specific response values */ + +#define VIRTIO_SCSI_S_FUNCTION_COMPLETE 0 + +#define VIRTIO_SCSI_S_FUNCTION_SUCCEEDED 10 + +#define VIRTIO_SCSI_S_FUNCTION_REJECTED 11 + + The type is VIRTIO_SCSI_T_TMF; the subtype field defines. All + fields except response are filled by the driver. The subtype + field must always be specified and identifies the requested + task management function. + + Other fields may be irrelevant for the requested TMF; if so, + they are ignored but they should still be present. The lun + field is in the same format specified for request queues; the + single level LUN is ignored when the task management function + addresses a whole I_T nexus. When relevant, the value of the id + field is matched against the id values passed on the requestq. + + The outcome of the task management function is written by the + device in the response field. The command-specific response + values map 1-to-1 with those defined in SAM. + + Asynchronous notification query +#define VIRTIO_SCSI_T_AN_QUERY 1 + + + +struct virtio_scsi_ctrl_an { + + // Read-only part + + u32 type; + + u8 lun[8]; + + u32 event_requested; + + // Write-only part + + u32 event_actual; + + u8 response; + +} + + + +#define VIRTIO_SCSI_EVT_ASYNC_OPERATIONAL_CHANGE 2 + +#define VIRTIO_SCSI_EVT_ASYNC_POWER_MGMT 4 + +#define VIRTIO_SCSI_EVT_ASYNC_EXTERNAL_REQUEST 8 + +#define VIRTIO_SCSI_EVT_ASYNC_MEDIA_CHANGE 16 + +#define VIRTIO_SCSI_EVT_ASYNC_MULTI_HOST 32 + +#define VIRTIO_SCSI_EVT_ASYNC_DEVICE_BUSY 64 + + By sending this command, the driver asks the device which + events the given LUN can report, as described in paragraphs 6.6 + and A.6 of the SCSI MMC specification. The driver writes the + events it is interested in into the event_requested; the device + responds by writing the events that it supports into + event_actual. + + The type is VIRTIO_SCSI_T_AN_QUERY. The lun and event_requested + fields are written by the driver. The event_actual and response + fields are written by the device. + + No command-specific values are defined for the response byte. + + Asynchronous notification subscription +#define VIRTIO_SCSI_T_AN_SUBSCRIBE 2 + + + +struct virtio_scsi_ctrl_an { + + // Read-only part + + u32 type; + + u8 lun[8]; + + u32 event_requested; + + // Write-only part + + u32 event_actual; + + u8 response; + +} + + By sending this command, the driver asks the specified LUN to + report events for its physical interface, again as described in + the SCSI MMC specification. The driver writes the events it is + interested in into the event_requested; the device responds by + writing the events that it supports into event_actual. + + Event types are the same as for the asynchronous notification + query message. + + The type is VIRTIO_SCSI_T_AN_SUBSCRIBE. The lun and + event_requested fields are written by the driver. The + event_actual and response fields are written by the device. + + No command-specific values are defined for the response byte. + + Device Operation: eventq + +The eventq is used by the device to report information on logical +units that are attached to it. The driver should always leave a +few buffers ready in the eventq. In general, the device will not +queue events to cope with an empty eventq, and will end up +dropping events if it finds no buffer ready. However, when +reporting events for many LUNs (e.g. when a whole target +disappears), the device can throttle events to avoid dropping +them. For this reason, placing 10-15 buffers on the event queue +should be enough. + +Buffers are placed in the eventq and filled by the device when +interesting events occur. The buffers should be strictly +write-only (device-filled) and the size of the buffers should be +at least the value given in the device's configuration +information. + +Buffers returned by the device on the eventq will be referred to +as "events" in the rest of this section. Events have the +following format: + +#define VIRTIO_SCSI_T_EVENTS_MISSED 0x80000000 + + + +struct virtio_scsi_event { + + // Write-only part + + u32 event; + + ... + +} + +If bit 31 is set in the event field, the device failed to report +an event due to missing buffers. In this case, the driver should +poll the logical units for unit attention conditions, and/or do +whatever form of bus scan is appropriate for the guest operating +system. + +Other data that the device writes to the buffer depends on the +contents of the event field. The following events are defined: + + No event +#define VIRTIO_SCSI_T_NO_EVENT 0 + + This event is fired in the following cases: + + When the device detects in the eventq a buffer that is shorter + than what is indicated in the configuration field, it might + use it immediately and put this dummy value in the event + field. A well-written driver will never observe this + situation. + + When events are dropped, the device may signal this event as + soon as the drivers makes a buffer available, in order to + request action from the driver. In this case, of course, this + event will be reported with the VIRTIO_SCSI_T_EVENTS_MISSED + flag. + + Transport reset +#define VIRTIO_SCSI_T_TRANSPORT_RESET 1 + + + +struct virtio_scsi_event_reset { + + // Write-only part + + u32 event; + + u8 lun[8]; + + u32 reason; + +} + + + +#define VIRTIO_SCSI_EVT_RESET_HARD 0 + +#define VIRTIO_SCSI_EVT_RESET_RESCAN 1 + +#define VIRTIO_SCSI_EVT_RESET_REMOVED 2 + + By sending this event, the device signals that a logical unit + on a target has been reset, including the case of a new device + appearing or disappearing on the bus.The device fills in all + fields. The event field is set to + VIRTIO_SCSI_T_TRANSPORT_RESET. The lun field addresses a + logical unit in the SCSI host. + + The reason value is one of the three #define values appearing + above: + + VIRTIO_SCSI_EVT_RESET_REMOVED (“LUN/target removed”) is used if + the target or logical unit is no longer able to receive + commands. + + VIRTIO_SCSI_EVT_RESET_HARD (“LUN hard reset”) is used if the + logical unit has been reset, but is still present. + + VIRTIO_SCSI_EVT_RESET_RESCAN (“rescan LUN/target”) is used if a + target or logical unit has just appeared on the device. + + The “removed” and “rescan” events, when sent for LUN 0, may + apply to the entire target. After receiving them the driver + should ask the initiator to rescan the target, in order to + detect the case when an entire target has appeared or + disappeared. These two events will never be reported unless the + VIRTIO_SCSI_F_HOTPLUG feature was negotiated between the host + and the guest. + + Events will also be reported via sense codes (this obviously + does not apply to newly appeared buses or targets, since the + application has never discovered them): + + “LUN/target removed” maps to sense key ILLEGAL REQUEST, asc + 0x25, ascq 0x00 (LOGICAL UNIT NOT SUPPORTED) + + “LUN hard reset” maps to sense key UNIT ATTENTION, asc 0x29 + (POWER ON, RESET OR BUS DEVICE RESET OCCURRED) + + “rescan LUN/target” maps to sense key UNIT ATTENTION, asc 0x3f, + ascq 0x0e (REPORTED LUNS DATA HAS CHANGED) + + The preferred way to detect transport reset is always to use + events, because sense codes are only seen by the driver when it + sends a SCSI command to the logical unit or target. However, in + case events are dropped, the initiator will still be able to + synchronize with the actual state of the controller if the + driver asks the initiator to rescan of the SCSI bus. During the + rescan, the initiator will be able to observe the above sense + codes, and it will process them as if it the driver had + received the equivalent event. + + Asynchronous notification +#define VIRTIO_SCSI_T_ASYNC_NOTIFY 2 + + + +struct virtio_scsi_event_an { + + // Write-only part + + u32 event; + + u8 lun[8]; + + u32 reason; + +} + + By sending this event, the device signals that an asynchronous + event was fired from a physical interface. + + All fields are written by the device. The event field is set to + VIRTIO_SCSI_T_ASYNC_NOTIFY. The lun field addresses a logical + unit in the SCSI host. The reason field is a subset of the + events that the driver has subscribed to via the "Asynchronous + notification subscription" command. + + When dropped events are reported, the driver should poll for + asynchronous events manually using SCSI commands. + +Appendix X: virtio-mmio + +Virtual environments without PCI support (a common situation in +embedded devices models) might use simple memory mapped device (“ +virtio-mmio”) instead of the PCI device. + +The memory mapped virtio device behaviour is based on the PCI +device specification. Therefore most of operations like device +initialization, queues configuration and buffer transfers are +nearly identical. Existing differences are described in the +following sections. + + Device Initialization + +Instead of using the PCI IO space for virtio header, the “ +virtio-mmio” device provides a set of memory mapped control +registers, all 32 bits wide, followed by device-specific +configuration space. The following list presents their layout: + + Offset from the device base address | Direction | Name + Description + + 0x000 | R | MagicValue + “virt” string. + + 0x004 | R | Version + Device version number. Currently must be 1. + + 0x008 | R | DeviceID + Virtio Subsystem Device ID (ie. 1 for network card). + + 0x00c | R | VendorID + Virtio Subsystem Vendor ID. + + 0x010 | R | HostFeatures + Flags representing features the device supports. + Reading from this register returns 32 consecutive flag bits, + first bit depending on the last value written to + HostFeaturesSel register. Access to this register returns bits HostFeaturesSel*32 + + to (HostFeaturesSel*32)+31 +, eg. feature bits 0 to 31 if + HostFeaturesSel is set to 0 and features bits 32 to 63 if + HostFeaturesSel is set to 1. Also see [sub:Feature-Bits] + + 0x014 | W | HostFeaturesSel + Device (Host) features word selection. + Writing to this register selects a set of 32 device feature bits + accessible by reading from HostFeatures register. Device driver + must write a value to the HostFeaturesSel register before + reading from the HostFeatures register. + + 0x020 | W | GuestFeatures + Flags representing device features understood and activated by + the driver. + Writing to this register sets 32 consecutive flag bits, first + bit depending on the last value written to GuestFeaturesSel + register. Access to this register sets bits GuestFeaturesSel*32 + + to (GuestFeaturesSel*32)+31 +, eg. feature bits 0 to 31 if + GuestFeaturesSel is set to 0 and features bits 32 to 63 if + GuestFeaturesSel is set to 1. Also see [sub:Feature-Bits] + + 0x024 | W | GuestFeaturesSel + Activated (Guest) features word selection. + Writing to this register selects a set of 32 activated feature + bits accessible by writing to the GuestFeatures register. + Device driver must write a value to the GuestFeaturesSel + register before writing to the GuestFeatures register. + + 0x028 | W | GuestPageSize + Guest page size. + Device driver must write the guest page size in bytes to the + register during initialization, before any queues are used. + This value must be a power of 2 and is used by the Host to + calculate Guest address of the first queue page (see QueuePFN). + + 0x030 | W | QueueSel + Virtual queue index (first queue is 0). + Writing to this register selects the virtual queue that the + following operations on QueueNum, QueueAlign and QueuePFN apply + to. + + 0x034 | R | QueueNumMax + Maximum virtual queue size. + Reading from the register returns the maximum size of the queue + the Host is ready to process or zero (0x0) if the queue is not + available. This applies to the queue selected by writing to + QueueSel and is allowed only when QueuePFN is set to zero + (0x0), so when the queue is not actively used. + + 0x038 | W | QueueNum + Virtual queue size. + Queue size is a number of elements in the queue, therefore size + of the descriptor table and both available and used rings. + Writing to this register notifies the Host what size of the + queue the Guest will use. This applies to the queue selected by + writing to QueueSel. + + 0x03c | W | QueueAlign + Used Ring alignment in the virtual queue. + Writing to this register notifies the Host about alignment + boundary of the Used Ring in bytes. This value must be a power + of 2 and applies to the queue selected by writing to QueueSel. + + 0x040 | RW | QueuePFN + Guest physical page number of the virtual queue. + Writing to this register notifies the host about location of the + virtual queue in the Guest's physical address space. This value + is the index number of a page starting with the queue + Descriptor Table. Value zero (0x0) means physical address zero + (0x00000000) and is illegal. When the Guest stops using the + queue it must write zero (0x0) to this register. + Reading from this register returns the currently used page + number of the queue, therefore a value other than zero (0x0) + means that the queue is in use. + Both read and write accesses apply to the queue selected by + writing to QueueSel. + + 0x050 | W | QueueNotify + Queue notifier. + Writing a queue index to this register notifies the Host that + there are new buffers to process in the queue. + + 0x60 | R | InterruptStatus +Interrupt status. +Reading from this register returns a bit mask of interrupts + asserted by the device. An interrupt is asserted if the + corresponding bit is set, ie. equals one (1). + + Bit 0 | Used Ring Update +This interrupt is asserted when the Host has updated the Used + Ring in at least one of the active virtual queues. + + Bit 1 | Configuration change +This interrupt is asserted when configuration of the device has + changed. + + 0x064 | W | InterruptACK + Interrupt acknowledge. + Writing to this register notifies the Host that the Guest + finished handling interrupts. Set bits in the value clear the + corresponding bits of the InterruptStatus register. + + 0x070 | RW | Status + Device status. + Reading from this register returns the current device status + flags. + Writing non-zero values to this register sets the status flags, + indicating the Guest progress. Writing zero (0x0) to this + register triggers a device reset. + Also see [sub:Device-Initialization-Sequence] + + 0x100+ | RW | Config + Device-specific configuration space starts at an offset 0x100 + and is accessed with byte alignment. Its meaning and size + depends on the device and the driver. + +Virtual queue size is a number of elements in the queue, +therefore size of the descriptor table and both available and +used rings. + +The endianness of the registers follows the native endianness of +the Guest. Writing to registers described as “R” and reading from +registers described as “W” is not permitted and can cause +undefined behavior. + +The device initialization is performed as described in [sub:Device-Initialization-Sequence] + with one exception: the Guest must notify the Host about its +page size, writing the size in bytes to GuestPageSize register +before the initialization is finished. + +The memory mapped virtio devices generate single interrupt only, +therefore no special configuration is required. + + Virtqueue Configuration + +The virtual queue configuration is performed in a similar way to +the one described in [sec:Virtqueue-Configuration] with a few +additional operations: + + Select the queue writing its index (first queue is 0) to the + QueueSel register. + + Check if the queue is not already in use: read QueuePFN + register, returned value should be zero (0x0). + + Read maximum queue size (number of elements) from the + QueueNumMax register. If the returned value is zero (0x0) the + queue is not available. + + Allocate and zero the queue pages in contiguous virtual memory, + aligning the Used Ring to an optimal boundary (usually page + size). Size of the allocated queue may be smaller than or equal + to the maximum size returned by the Host. + + Notify the Host about the queue size by writing the size to + QueueNum register. + + Notify the Host about the used alignment by writing its value + in bytes to QueueAlign register. + + Write the physical number of the first page of the queue to the + QueuePFN register. + +The queue and the device are ready to begin normal operations +now. + + Device Operation + +The memory mapped virtio device behaves in the same way as +described in [sec:Device-Operation], with the following +exceptions: + + The device is notified about new buffers available in a queue + by writing the queue index to register QueueNum instead of the + virtio header in PCI I/O space ([sub:Notifying-The-Device]). + + The memory mapped virtio device is using single, dedicated + interrupt signal, which is raised when at least one of the + interrupts described in the InterruptStatus register + description is asserted. After receiving an interrupt, the + driver must read the InterruptStatus register to check what + caused the interrupt (see the register description). After the + interrupt is handled, the driver must acknowledge it by writing + a bit mask corresponding to the serviced interrupt to the + InterruptACK register. + diff --git a/Documentation/vm/frontswap.txt b/Documentation/vm/frontswap.txt new file mode 100644 index 0000000..5ef2d13 --- /dev/null +++ b/Documentation/vm/frontswap.txt @@ -0,0 +1,278 @@ +Frontswap provides a "transcendent memory" interface for swap pages. +In some environments, dramatic performance savings may be obtained because +swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk. + +(Note, frontswap -- and cleancache (merged at 3.0) -- are the "frontends" +and the only necessary changes to the core kernel for transcendent memory; +all other supporting code -- the "backends" -- is implemented as drivers. +See the LWN.net article "Transcendent memory in a nutshell" for a detailed +overview of frontswap and related kernel parts: +https://lwn.net/Articles/454795/ ) + +Frontswap is so named because it can be thought of as the opposite of +a "backing" store for a swap device. The storage is assumed to be +a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming +to the requirements of transcendent memory (such as Xen's "tmem", or +in-kernel compressed memory, aka "zcache", or future RAM-like devices); +this pseudo-RAM device is not directly accessible or addressable by the +kernel and is of unknown and possibly time-varying size. The driver +links itself to frontswap by calling frontswap_register_ops to set the +frontswap_ops funcs appropriately and the functions it provides must +conform to certain policies as follows: + +An "init" prepares the device to receive frontswap pages associated +with the specified swap device number (aka "type"). A "store" will +copy the page to transcendent memory and associate it with the type and +offset associated with the page. A "load" will copy the page, if found, +from transcendent memory into kernel memory, but will NOT remove the page +from transcendent memory. An "invalidate_page" will remove the page +from transcendent memory and an "invalidate_area" will remove ALL pages +associated with the swap type (e.g., like swapoff) and notify the "device" +to refuse further stores with that swap type. + +Once a page is successfully stored, a matching load on the page will normally +succeed. So when the kernel finds itself in a situation where it needs +to swap out a page, it first attempts to use frontswap. If the store returns +success, the data has been successfully saved to transcendent memory and +a disk write and, if the data is later read back, a disk read are avoided. +If a store returns failure, transcendent memory has rejected the data, and the +page can be written to swap as usual. + +If a backend chooses, frontswap can be configured as a "writethrough +cache" by calling frontswap_writethrough(). In this mode, the reduction +in swap device writes is lost (and also a non-trivial performance advantage) +in order to allow the backend to arbitrarily "reclaim" space used to +store frontswap pages to more completely manage its memory usage. + +Note that if a page is stored and the page already exists in transcendent memory +(a "duplicate" store), either the store succeeds and the data is overwritten, +or the store fails AND the page is invalidated. This ensures stale data may +never be obtained from frontswap. + +If properly configured, monitoring of frontswap is done via debugfs in +the /sys/kernel/debug/frontswap directory. The effectiveness of +frontswap can be measured (across all swap devices) with: + +failed_stores - how many store attempts have failed +loads - how many loads were attempted (all should succeed) +succ_stores - how many store attempts have succeeded +invalidates - how many invalidates were attempted + +A backend implementation may provide additional metrics. + +FAQ + +1) Where's the value? + +When a workload starts swapping, performance falls through the floor. +Frontswap significantly increases performance in many such workloads by +providing a clean, dynamic interface to read and write swap pages to +"transcendent memory" that is otherwise not directly addressable to the kernel. +This interface is ideal when data is transformed to a different form +and size (such as with compression) or secretly moved (as might be +useful for write-balancing for some RAM-like devices). Swap pages (and +evicted page-cache pages) are a great use for this kind of slower-than-RAM- +but-much-faster-than-disk "pseudo-RAM device" and the frontswap (and +cleancache) interface to transcendent memory provides a nice way to read +and write -- and indirectly "name" -- the pages. + +Frontswap -- and cleancache -- with a fairly small impact on the kernel, +provides a huge amount of flexibility for more dynamic, flexible RAM +utilization in various system configurations: + +In the single kernel case, aka "zcache", pages are compressed and +stored in local memory, thus increasing the total anonymous pages +that can be safely kept in RAM. Zcache essentially trades off CPU +cycles used in compression/decompression for better memory utilization. +Benchmarks have shown little or no impact when memory pressure is +low while providing a significant performance improvement (25%+) +on some workloads under high memory pressure. + +"RAMster" builds on zcache by adding "peer-to-peer" transcendent memory +support for clustered systems. Frontswap pages are locally compressed +as in zcache, but then "remotified" to another system's RAM. This +allows RAM to be dynamically load-balanced back-and-forth as needed, +i.e. when system A is overcommitted, it can swap to system B, and +vice versa. RAMster can also be configured as a memory server so +many servers in a cluster can swap, dynamically as needed, to a single +server configured with a large amount of RAM... without pre-configuring +how much of the RAM is available for each of the clients! + +In the virtual case, the whole point of virtualization is to statistically +multiplex physical resources across the varying demands of multiple +virtual machines. This is really hard to do with RAM and efforts to do +it well with no kernel changes have essentially failed (except in some +well-publicized special-case workloads). +Specifically, the Xen Transcendent Memory backend allows otherwise +"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple +virtual machines, but the pages can be compressed and deduplicated to +optimize RAM utilization. And when guest OS's are induced to surrender +underutilized RAM (e.g. with "selfballooning"), sudden unexpected +memory pressure may result in swapping; frontswap allows those pages +to be swapped to and from hypervisor RAM (if overall host system memory +conditions allow), thus mitigating the potentially awful performance impact +of unplanned swapping. + +A KVM implementation is underway and has been RFC'ed to lkml. And, +using frontswap, investigation is also underway on the use of NVM as +a memory extension technology. + +2) Sure there may be performance advantages in some situations, but + what's the space/time overhead of frontswap? + +If CONFIG_FRONTSWAP is disabled, every frontswap hook compiles into +nothingness and the only overhead is a few extra bytes per swapon'ed +swap device. If CONFIG_FRONTSWAP is enabled but no frontswap "backend" +registers, there is one extra global variable compared to zero for +every swap page read or written. If CONFIG_FRONTSWAP is enabled +AND a frontswap backend registers AND the backend fails every "store" +request (i.e. provides no memory despite claiming it might), +CPU overhead is still negligible -- and since every frontswap fail +precedes a swap page write-to-disk, the system is highly likely +to be I/O bound and using a small fraction of a percent of a CPU +will be irrelevant anyway. + +As for space, if CONFIG_FRONTSWAP is enabled AND a frontswap backend +registers, one bit is allocated for every swap page for every swap +device that is swapon'd. This is added to the EIGHT bits (which +was sixteen until about 2.6.34) that the kernel already allocates +for every swap page for every swap device that is swapon'd. (Hugh +Dickins has observed that frontswap could probably steal one of +the existing eight bits, but let's worry about that minor optimization +later.) For very large swap disks (which are rare) on a standard +4K pagesize, this is 1MB per 32GB swap. + +When swap pages are stored in transcendent memory instead of written +out to disk, there is a side effect that this may create more memory +pressure that can potentially outweigh the other advantages. A +backend, such as zcache, must implement policies to carefully (but +dynamically) manage memory limits to ensure this doesn't happen. + +3) OK, how about a quick overview of what this frontswap patch does + in terms that a kernel hacker can grok? + +Let's assume that a frontswap "backend" has registered during +kernel initialization; this registration indicates that this +frontswap backend has access to some "memory" that is not directly +accessible by the kernel. Exactly how much memory it provides is +entirely dynamic and random. + +Whenever a swap-device is swapon'd frontswap_init() is called, +passing the swap device number (aka "type") as a parameter. +This notifies frontswap to expect attempts to "store" swap pages +associated with that number. + +Whenever the swap subsystem is readying a page to write to a swap +device (c.f swap_writepage()), frontswap_store is called. Frontswap +consults with the frontswap backend and if the backend says it does NOT +have room, frontswap_store returns -1 and the kernel swaps the page +to the swap device as normal. Note that the response from the frontswap +backend is unpredictable to the kernel; it may choose to never accept a +page, it could accept every ninth page, or it might accept every +page. But if the backend does accept a page, the data from the page +has already been copied and associated with the type and offset, +and the backend guarantees the persistence of the data. In this case, +frontswap sets a bit in the "frontswap_map" for the swap device +corresponding to the page offset on the swap device to which it would +otherwise have written the data. + +When the swap subsystem needs to swap-in a page (swap_readpage()), +it first calls frontswap_load() which checks the frontswap_map to +see if the page was earlier accepted by the frontswap backend. If +it was, the page of data is filled from the frontswap backend and +the swap-in is complete. If not, the normal swap-in code is +executed to obtain the page of data from the real swap device. + +So every time the frontswap backend accepts a page, a swap device read +and (potentially) a swap device write are replaced by a "frontswap backend +store" and (possibly) a "frontswap backend loads", which are presumably much +faster. + +4) Can't frontswap be configured as a "special" swap device that is + just higher priority than any real swap device (e.g. like zswap, + or maybe swap-over-nbd/NFS)? + +No. First, the existing swap subsystem doesn't allow for any kind of +swap hierarchy. Perhaps it could be rewritten to accomodate a hierarchy, +but this would require fairly drastic changes. Even if it were +rewritten, the existing swap subsystem uses the block I/O layer which +assumes a swap device is fixed size and any page in it is linearly +addressable. Frontswap barely touches the existing swap subsystem, +and works around the constraints of the block I/O subsystem to provide +a great deal of flexibility and dynamicity. + +For example, the acceptance of any swap page by the frontswap backend is +entirely unpredictable. This is critical to the definition of frontswap +backends because it grants completely dynamic discretion to the +backend. In zcache, one cannot know a priori how compressible a page is. +"Poorly" compressible pages can be rejected, and "poorly" can itself be +defined dynamically depending on current memory constraints. + +Further, frontswap is entirely synchronous whereas a real swap +device is, by definition, asynchronous and uses block I/O. The +block I/O layer is not only unnecessary, but may perform "optimizations" +that are inappropriate for a RAM-oriented device including delaying +the write of some pages for a significant amount of time. Synchrony is +required to ensure the dynamicity of the backend and to avoid thorny race +conditions that would unnecessarily and greatly complicate frontswap +and/or the block I/O subsystem. That said, only the initial "store" +and "load" operations need be synchronous. A separate asynchronous thread +is free to manipulate the pages stored by frontswap. For example, +the "remotification" thread in RAMster uses standard asynchronous +kernel sockets to move compressed frontswap pages to a remote machine. +Similarly, a KVM guest-side implementation could do in-guest compression +and use "batched" hypercalls. + +In a virtualized environment, the dynamicity allows the hypervisor +(or host OS) to do "intelligent overcommit". For example, it can +choose to accept pages only until host-swapping might be imminent, +then force guests to do their own swapping. + +There is a downside to the transcendent memory specifications for +frontswap: Since any "store" might fail, there must always be a real +slot on a real swap device to swap the page. Thus frontswap must be +implemented as a "shadow" to every swapon'd device with the potential +capability of holding every page that the swap device might have held +and the possibility that it might hold no pages at all. This means +that frontswap cannot contain more pages than the total of swapon'd +swap devices. For example, if NO swap device is configured on some +installation, frontswap is useless. Swapless portable devices +can still use frontswap but a backend for such devices must configure +some kind of "ghost" swap device and ensure that it is never used. + +5) Why this weird definition about "duplicate stores"? If a page + has been previously successfully stored, can't it always be + successfully overwritten? + +Nearly always it can, but no, sometimes it cannot. Consider an example +where data is compressed and the original 4K page has been compressed +to 1K. Now an attempt is made to overwrite the page with data that +is non-compressible and so would take the entire 4K. But the backend +has no more space. In this case, the store must be rejected. Whenever +frontswap rejects a store that would overwrite, it also must invalidate +the old data and ensure that it is no longer accessible. Since the +swap subsystem then writes the new data to the read swap device, +this is the correct course of action to ensure coherency. + +6) What is frontswap_shrink for? + +When the (non-frontswap) swap subsystem swaps out a page to a real +swap device, that page is only taking up low-value pre-allocated disk +space. But if frontswap has placed a page in transcendent memory, that +page may be taking up valuable real estate. The frontswap_shrink +routine allows code outside of the swap subsystem to force pages out +of the memory managed by frontswap and back into kernel-addressable memory. +For example, in RAMster, a "suction driver" thread will attempt +to "repatriate" pages sent to a remote machine back to the local machine; +this is driven using the frontswap_shrink mechanism when memory pressure +subsides. + +7) Why does the frontswap patch create the new include file swapfile.h? + +The frontswap code depends on some swap-subsystem-internal data +structures that have, over the years, moved back and forth between +static and global. This seemed a reasonable compromise: Define +them as global but declare them in a new include file that isn't +included by the large number of source files that include swap.h. + +Dan Magenheimer, last updated April 9, 2012 diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt index 4600cbe..7587493 100644 --- a/Documentation/vm/pagemap.txt +++ b/Documentation/vm/pagemap.txt @@ -16,7 +16,7 @@ There are three components to pagemap: * Bits 0-4 swap type if swapped * Bits 5-54 swap offset if swapped * Bits 55-60 page shift (page size = 1<<page shift) - * Bit 61 reserved for future use + * Bit 61 page is file-page or shared-anon * Bit 62 page swapped * Bit 63 page present diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt index 6752870..b0c6d1b 100644 --- a/Documentation/vm/slub.txt +++ b/Documentation/vm/slub.txt @@ -17,7 +17,7 @@ data and perform operation on the slabs. By default slabinfo only lists slabs that have data in them. See "slabinfo -h" for more options when running the command. slabinfo can be compiled with -gcc -o slabinfo tools/slub/slabinfo.c +gcc -o slabinfo tools/vm/slabinfo.c Some of the modes of operation of slabinfo require that slub debugging be enabled on the command line. F.e. no tracking information will be diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt index 29bdf62..f734bb2 100644 --- a/Documentation/vm/transhuge.txt +++ b/Documentation/vm/transhuge.txt @@ -166,6 +166,68 @@ behavior. So to make them effective you need to restart any application that could have been using hugepages. This also applies to the regions registered in khugepaged. +== Monitoring usage == + +The number of transparent huge pages currently used by the system is +available by reading the AnonHugePages field in /proc/meminfo. To +identify what applications are using transparent huge pages, it is +necessary to read /proc/PID/smaps and count the AnonHugePages fields +for each mapping. Note that reading the smaps file is expensive and +reading it frequently will incur overhead. + +There are a number of counters in /proc/vmstat that may be used to +monitor how successfully the system is providing huge pages for use. + +thp_fault_alloc is incremented every time a huge page is successfully + allocated to handle a page fault. This applies to both the + first time a page is faulted and for COW faults. + +thp_collapse_alloc is incremented by khugepaged when it has found + a range of pages to collapse into one huge page and has + successfully allocated a new huge page to store the data. + +thp_fault_fallback is incremented if a page fault fails to allocate + a huge page and instead falls back to using small pages. + +thp_collapse_alloc_failed is incremented if khugepaged found a range + of pages that should be collapsed into one huge page but failed + the allocation. + +thp_split is incremented every time a huge page is split into base + pages. This can happen for a variety of reasons but a common + reason is that a huge page is old and is being reclaimed. + +As the system ages, allocating huge pages may be expensive as the +system uses memory compaction to copy data around memory to free a +huge page for use. There are some counters in /proc/vmstat to help +monitor this overhead. + +compact_stall is incremented every time a process stalls to run + memory compaction so that a huge page is free for use. + +compact_success is incremented if the system compacted memory and + freed a huge page for use. + +compact_fail is incremented if the system tries to compact memory + but failed. + +compact_pages_moved is incremented each time a page is moved. If + this value is increasing rapidly, it implies that the system + is copying a lot of data to satisfy the huge page allocation. + It is possible that the cost of copying exceeds any savings + from reduced TLB misses. + +compact_pagemigrate_failed is incremented when the underlying mechanism + for moving a page failed. + +compact_blocks_moved is incremented each time memory compaction examines + a huge page aligned range of pages. + +It is possible to establish how long the stalls were using the function +tracer to record how long was spent in __alloc_pages_nodemask and +using the mm_page_alloc tracepoint to identify which allocations were +for huge pages. + == get_user_pages and follow_page == get_user_pages and follow_page if run on a hugepage, will return the diff --git a/Documentation/vme_api.txt b/Documentation/vme_api.txt new file mode 100644 index 0000000..856efa3 --- /dev/null +++ b/Documentation/vme_api.txt @@ -0,0 +1,396 @@ + VME Device Driver API + ===================== + +Driver registration +=================== + +As with other subsystems within the Linux kernel, VME device drivers register +with the VME subsystem, typically called from the devices init routine. This is +achieved via a call to the following function: + + int vme_register_driver (struct vme_driver *driver); + +If driver registration is successful this function returns zero, if an error +occurred a negative error code will be returned. + +A pointer to a structure of type 'vme_driver' must be provided to the +registration function. The structure is as follows: + + struct vme_driver { + struct list_head node; + const char *name; + int (*match)(struct vme_dev *); + int (*probe)(struct vme_dev *); + int (*remove)(struct vme_dev *); + void (*shutdown)(void); + struct device_driver driver; + struct list_head devices; + unsigned int ndev; + }; + +At the minimum, the '.name', '.match' and '.probe' elements of this structure +should be correctly set. The '.name' element is a pointer to a string holding +the device driver's name. + +The '.match' function allows controlling the number of devices that need to +be registered. The match function should return 1 if a device should be +probed and 0 otherwise. This example match function (from vme_user.c) limits +the number of devices probed to one: + + #define USER_BUS_MAX 1 + ... + static int vme_user_match(struct vme_dev *vdev) + { + if (vdev->id.num >= USER_BUS_MAX) + return 0; + return 1; + } + +The '.probe' element should contain a pointer to the probe routine. The +probe routine is passed a 'struct vme_dev' pointer as an argument. The +'struct vme_dev' structure looks like the following: + + struct vme_dev { + int num; + struct vme_bridge *bridge; + struct device dev; + struct list_head drv_list; + struct list_head bridge_list; + }; + +Here, the 'num' field refers to the sequential device ID for this specific +driver. The bridge number (or bus number) can be accessed using +dev->bridge->num. + +A function is also provided to unregister the driver from the VME core and is +usually called from the device driver's exit routine: + + void vme_unregister_driver (struct vme_driver *driver); + + +Resource management +=================== + +Once a driver has registered with the VME core the provided match routine will +be called the number of times specified during the registration. If a match +succeeds, a non-zero value should be returned. A zero return value indicates +failure. For all successful matches, the probe routine of the corresponding +driver is called. The probe routine is passed a pointer to the devices +device structure. This pointer should be saved, it will be required for +requesting VME resources. + +The driver can request ownership of one or more master windows, slave windows +and/or dma channels. Rather than allowing the device driver to request a +specific window or DMA channel (which may be used by a different driver) this +driver allows a resource to be assigned based on the required attributes of the +driver in question: + + struct vme_resource * vme_master_request(struct vme_dev *dev, + u32 aspace, u32 cycle, u32 width); + + struct vme_resource * vme_slave_request(struct vme_dev *dev, u32 aspace, + u32 cycle); + + struct vme_resource *vme_dma_request(struct vme_dev *dev, u32 route); + +For slave windows these attributes are split into the VME address spaces that +need to be accessed in 'aspace' and VME bus cycle types required in 'cycle'. +Master windows add a further set of attributes in 'width' specifying the +required data transfer widths. These attributes are defined as bitmasks and as +such any combination of the attributes can be requested for a single window, +the core will assign a window that meets the requirements, returning a pointer +of type vme_resource that should be used to identify the allocated resource +when it is used. For DMA controllers, the request function requires the +potential direction of any transfers to be provided in the route attributes. +This is typically VME-to-MEM and/or MEM-to-VME, though some hardware can +support VME-to-VME and MEM-to-MEM transfers as well as test pattern generation. +If an unallocated window fitting the requirements can not be found a NULL +pointer will be returned. + +Functions are also provided to free window allocations once they are no longer +required. These functions should be passed the pointer to the resource provided +during resource allocation: + + void vme_master_free(struct vme_resource *res); + + void vme_slave_free(struct vme_resource *res); + + void vme_dma_free(struct vme_resource *res); + + +Master windows +============== + +Master windows provide access from the local processor[s] out onto the VME bus. +The number of windows available and the available access modes is dependent on +the underlying chipset. A window must be configured before it can be used. + + +Master window configuration +--------------------------- + +Once a master window has been assigned the following functions can be used to +configure it and retrieve the current settings: + + int vme_master_set (struct vme_resource *res, int enabled, + unsigned long long base, unsigned long long size, u32 aspace, + u32 cycle, u32 width); + + int vme_master_get (struct vme_resource *res, int *enabled, + unsigned long long *base, unsigned long long *size, u32 *aspace, + u32 *cycle, u32 *width); + +The address spaces, transfer widths and cycle types are the same as described +under resource management, however some of the options are mutually exclusive. +For example, only one address space may be specified. + +These functions return 0 on success or an error code should the call fail. + + +Master window access +-------------------- + +The following functions can be used to read from and write to configured master +windows. These functions return the number of bytes copied: + + ssize_t vme_master_read(struct vme_resource *res, void *buf, + size_t count, loff_t offset); + + ssize_t vme_master_write(struct vme_resource *res, void *buf, + size_t count, loff_t offset); + +In addition to simple reads and writes, a function is provided to do a +read-modify-write transaction. This function returns the original value of the +VME bus location : + + unsigned int vme_master_rmw (struct vme_resource *res, + unsigned int mask, unsigned int compare, unsigned int swap, + loff_t offset); + +This functions by reading the offset, applying the mask. If the bits selected in +the mask match with the values of the corresponding bits in the compare field, +the value of swap is written the specified offset. + + +Slave windows +============= + +Slave windows provide devices on the VME bus access into mapped portions of the +local memory. The number of windows available and the access modes that can be +used is dependent on the underlying chipset. A window must be configured before +it can be used. + + +Slave window configuration +-------------------------- + +Once a slave window has been assigned the following functions can be used to +configure it and retrieve the current settings: + + int vme_slave_set (struct vme_resource *res, int enabled, + unsigned long long base, unsigned long long size, + dma_addr_t mem, u32 aspace, u32 cycle); + + int vme_slave_get (struct vme_resource *res, int *enabled, + unsigned long long *base, unsigned long long *size, + dma_addr_t *mem, u32 *aspace, u32 *cycle); + +The address spaces, transfer widths and cycle types are the same as described +under resource management, however some of the options are mutually exclusive. +For example, only one address space may be specified. + +These functions return 0 on success or an error code should the call fail. + + +Slave window buffer allocation +------------------------------ + +Functions are provided to allow the user to allocate and free a contiguous +buffers which will be accessible by the VME bridge. These functions do not have +to be used, other methods can be used to allocate a buffer, though care must be +taken to ensure that they are contiguous and accessible by the VME bridge: + + void * vme_alloc_consistent(struct vme_resource *res, size_t size, + dma_addr_t *mem); + + void vme_free_consistent(struct vme_resource *res, size_t size, + void *virt, dma_addr_t mem); + + +Slave window access +------------------- + +Slave windows map local memory onto the VME bus, the standard methods for +accessing memory should be used. + + +DMA channels +============ + +The VME DMA transfer provides the ability to run link-list DMA transfers. The +API introduces the concept of DMA lists. Each DMA list is a link-list which can +be passed to a DMA controller. Multiple lists can be created, extended, +executed, reused and destroyed. + + +List Management +--------------- + +The following functions are provided to create and destroy DMA lists. Execution +of a list will not automatically destroy the list, thus enabling a list to be +reused for repetitive tasks: + + struct vme_dma_list *vme_new_dma_list(struct vme_resource *res); + + int vme_dma_list_free(struct vme_dma_list *list); + + +List Population +--------------- + +An item can be added to a list using the following function ( the source and +destination attributes need to be created before calling this function, this is +covered under "Transfer Attributes"): + + int vme_dma_list_add(struct vme_dma_list *list, + struct vme_dma_attr *src, struct vme_dma_attr *dest, + size_t count); + +NOTE: The detailed attributes of the transfers source and destination + are not checked until an entry is added to a DMA list, the request + for a DMA channel purely checks the directions in which the + controller is expected to transfer data. As a result it is + possible for this call to return an error, for example if the + source or destination is in an unsupported VME address space. + +Transfer Attributes +------------------- + +The attributes for the source and destination are handled separately from adding +an item to a list. This is due to the diverse attributes required for each type +of source and destination. There are functions to create attributes for PCI, VME +and pattern sources and destinations (where appropriate): + +Pattern source: + + struct vme_dma_attr *vme_dma_pattern_attribute(u32 pattern, u32 type); + +PCI source or destination: + + struct vme_dma_attr *vme_dma_pci_attribute(dma_addr_t mem); + +VME source or destination: + + struct vme_dma_attr *vme_dma_vme_attribute(unsigned long long base, + u32 aspace, u32 cycle, u32 width); + +The following function should be used to free an attribute: + + void vme_dma_free_attribute(struct vme_dma_attr *attr); + + +List Execution +-------------- + +The following function queues a list for execution. The function will return +once the list has been executed: + + int vme_dma_list_exec(struct vme_dma_list *list); + + +Interrupts +========== + +The VME API provides functions to attach and detach callbacks to specific VME +level and status ID combinations and for the generation of VME interrupts with +specific VME level and status IDs. + + +Attaching Interrupt Handlers +---------------------------- + +The following functions can be used to attach and free a specific VME level and +status ID combination. Any given combination can only be assigned a single +callback function. A void pointer parameter is provided, the value of which is +passed to the callback function, the use of this pointer is user undefined: + + int vme_irq_request(struct vme_dev *dev, int level, int statid, + void (*callback)(int, int, void *), void *priv); + + void vme_irq_free(struct vme_dev *dev, int level, int statid); + +The callback parameters are as follows. Care must be taken in writing a callback +function, callback functions run in interrupt context: + + void callback(int level, int statid, void *priv); + + +Interrupt Generation +-------------------- + +The following function can be used to generate a VME interrupt at a given VME +level and VME status ID: + + int vme_irq_generate(struct vme_dev *dev, int level, int statid); + + +Location monitors +================= + +The VME API provides the following functionality to configure the location +monitor. + + +Location Monitor Management +--------------------------- + +The following functions are provided to request the use of a block of location +monitors and to free them after they are no longer required: + + struct vme_resource * vme_lm_request(struct vme_dev *dev); + + void vme_lm_free(struct vme_resource * res); + +Each block may provide a number of location monitors, monitoring adjacent +locations. The following function can be used to determine how many locations +are provided: + + int vme_lm_count(struct vme_resource * res); + + +Location Monitor Configuration +------------------------------ + +Once a bank of location monitors has been allocated, the following functions +are provided to configure the location and mode of the location monitor: + + int vme_lm_set(struct vme_resource *res, unsigned long long base, + u32 aspace, u32 cycle); + + int vme_lm_get(struct vme_resource *res, unsigned long long *base, + u32 *aspace, u32 *cycle); + + +Location Monitor Use +-------------------- + +The following functions allow a callback to be attached and detached from each +location monitor location. Each location monitor can monitor a number of +adjacent locations: + + int vme_lm_attach(struct vme_resource *res, int num, + void (*callback)(int)); + + int vme_lm_detach(struct vme_resource *res, int num); + +The callback function is declared as follows. + + void callback(int num); + + +Slot Detection +============== + +This function returns the slot ID of the provided bridge. + + int vme_slot_get(struct vme_dev *dev); diff --git a/Documentation/w1/slaves/w1_ds28e04 b/Documentation/w1/slaves/w1_ds28e04 new file mode 100644 index 0000000..85bc9a7 --- /dev/null +++ b/Documentation/w1/slaves/w1_ds28e04 @@ -0,0 +1,36 @@ +Kernel driver w1_ds28e04 +======================== + +Supported chips: + * Maxim DS28E04-100 4096-Bit Addressable 1-Wire EEPROM with PIO + +supported family codes: + W1_FAMILY_DS28E04 0x1C + +Author: Markus Franke, <franke.m@sebakmt.com> <franm@hrz.tu-chemnitz.de> + +Description +----------- + +Support is provided through the sysfs files "eeprom" and "pio". CRC checking +during memory accesses can optionally be enabled/disabled via the device +attribute "crccheck". The strong pull-up can optionally be enabled/disabled +via the module parameter "w1_strong_pullup". + +Memory Access + + A read operation on the "eeprom" file reads the given amount of bytes + from the EEPROM of the DS28E04. + + A write operation on the "eeprom" file writes the given byte sequence + to the EEPROM of the DS28E04. If CRC checking mode is enabled only + fully alligned blocks of 32 bytes with valid CRC16 values (in bytes 30 + and 31) are allowed to be written. + +PIO Access + + The 2 PIOs of the DS28E04-100 are accessible via the "pio" sysfs file. + + The current status of the PIO's is returned as an 8 bit value. Bit 0/1 + represent the state of PIO_0/PIO_1. Bits 2..7 do not care. The PIO's are + driven low-active, i.e. the driver delivers/expects low-active values. diff --git a/Documentation/watchdog/src/watchdog-test.c b/Documentation/watchdog/src/watchdog-test.c index 63fdc34..73ff5cc 100644 --- a/Documentation/watchdog/src/watchdog-test.c +++ b/Documentation/watchdog/src/watchdog-test.c @@ -7,6 +7,7 @@ #include <string.h> #include <unistd.h> #include <fcntl.h> +#include <signal.h> #include <sys/ioctl.h> #include <linux/types.h> #include <linux/watchdog.h> @@ -29,6 +30,14 @@ static void keep_alive(void) * The main program. Run the program with "-d" to disable the card, * or "-e" to enable the card. */ + +void term(int sig) +{ + close(fd); + fprintf(stderr, "Stopping watchdog ticks...\n"); + exit(0); +} + int main(int argc, char *argv[]) { int flags; @@ -47,26 +56,31 @@ int main(int argc, char *argv[]) ioctl(fd, WDIOC_SETOPTIONS, &flags); fprintf(stderr, "Watchdog card disabled.\n"); fflush(stderr); - exit(0); + goto end; } else if (!strncasecmp(argv[1], "-e", 2)) { flags = WDIOS_ENABLECARD; ioctl(fd, WDIOC_SETOPTIONS, &flags); fprintf(stderr, "Watchdog card enabled.\n"); fflush(stderr); - exit(0); + goto end; } else { fprintf(stderr, "-d to disable, -e to enable.\n"); fprintf(stderr, "run by itself to tick the card.\n"); fflush(stderr); - exit(0); + goto end; } } else { fprintf(stderr, "Watchdog Ticking Away!\n"); fflush(stderr); } + signal(SIGINT, term); + while(1) { keep_alive(); sleep(1); } +end: + close(fd); + return 0; } diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt index 227f6cd..086638f 100644 --- a/Documentation/watchdog/watchdog-kernel-api.txt +++ b/Documentation/watchdog/watchdog-kernel-api.txt @@ -1,6 +1,6 @@ The Linux WatchDog Timer Driver Core kernel API. =============================================== -Last reviewed: 16-Mar-2012 +Last reviewed: 22-May-2012 Wim Van Sebroeck <wim@iguana.be> @@ -39,6 +39,10 @@ watchdog_device structure. The watchdog device structure looks like this: struct watchdog_device { + int id; + struct cdev cdev; + struct device *dev; + struct device *parent; const struct watchdog_info *info; const struct watchdog_ops *ops; unsigned int bootstatus; @@ -46,10 +50,20 @@ struct watchdog_device { unsigned int min_timeout; unsigned int max_timeout; void *driver_data; + struct mutex lock; unsigned long status; }; It contains following fields: +* id: set by watchdog_register_device, id 0 is special. It has both a + /dev/watchdog0 cdev (dynamic major, minor 0) as well as the old + /dev/watchdog miscdev. The id is set automatically when calling + watchdog_register_device. +* cdev: cdev for the dynamic /dev/watchdog<id> device nodes. This + field is also populated by watchdog_register_device. +* dev: device under the watchdog class (created by watchdog_register_device). +* parent: set this to the parent device (or NULL) before calling + watchdog_register_device. * info: a pointer to a watchdog_info structure. This structure gives some additional information about the watchdog timer itself. (Like it's unique name) * ops: a pointer to the list of watchdog operations that the watchdog supports. @@ -59,8 +73,9 @@ It contains following fields: * bootstatus: status of the device after booting (reported with watchdog WDIOF_* status bits). * driver_data: a pointer to the drivers private data of a watchdog device. - This data should only be accessed via the watchdog_set_drvadata and + This data should only be accessed via the watchdog_set_drvdata and watchdog_get_drvdata routines. +* lock: Mutex for WatchDog Timer Driver Core internal use only. * status: this field contains a number of status bits that give extra information about the status of the device (Like: is the watchdog timer running/active, is the nowayout bit set, is the device opened via @@ -78,6 +93,8 @@ struct watchdog_ops { unsigned int (*status)(struct watchdog_device *); int (*set_timeout)(struct watchdog_device *, unsigned int); unsigned int (*get_timeleft)(struct watchdog_device *); + void (*ref)(struct watchdog_device *); + void (*unref)(struct watchdog_device *); long (*ioctl)(struct watchdog_device *, unsigned int, unsigned long); }; @@ -85,6 +102,21 @@ It is important that you first define the module owner of the watchdog timer driver's operations. This module owner will be used to lock the module when the watchdog is active. (This to avoid a system crash when you unload the module and /dev/watchdog is still open). + +If the watchdog_device struct is dynamically allocated, just locking the module +is not enough and a driver also needs to define the ref and unref operations to +ensure the structure holding the watchdog_device does not go away. + +The simplest (and usually sufficient) implementation of this is to: +1) Add a kref struct to the same structure which is holding the watchdog_device +2) Define a release callback for the kref which frees the struct holding both +3) Call kref_init on this kref *before* calling watchdog_register_device() +4) Define a ref operation calling kref_get on this kref +5) Define a unref operation calling kref_put on this kref +6) When it is time to cleanup: + * Do not kfree() the struct holding both, the last kref_put will do this! + * *After* calling watchdog_unregister_device() call kref_put on the kref + Some operations are mandatory and some are optional. The mandatory operations are: * start: this is a pointer to the routine that starts the watchdog timer @@ -125,6 +157,10 @@ they are supported. These optional routines/operations are: (Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the watchdog's info structure). * get_timeleft: this routines returns the time that's left before a reset. +* ref: the operation that calls kref_get on the kref of a dynamically + allocated watchdog_device struct. +* unref: the operation that calls kref_put on the kref of a dynamically + allocated watchdog_device struct. * ioctl: if this routine is present then it will be called first before we do our own internal ioctl call handling. This routine should return -ENOIOCTLCMD if a command is not supported. The parameters that are passed to the ioctl @@ -144,6 +180,11 @@ bit-operations. The status bits that are defined are: (This bit should only be used by the WatchDog Timer Driver Core). * WDOG_NO_WAY_OUT: this bit stores the nowayout setting for the watchdog. If this bit is set then the watchdog timer will not be able to stop. +* WDOG_UNREGISTERED: this bit gets set by the WatchDog Timer Driver Core + after calling watchdog_unregister_device, and then checked before calling + any watchdog_ops, so that you can be sure that no operations (other then + unref) will get called after unregister, even if userspace still holds a + reference to /dev/watchdog To set the WDOG_NO_WAY_OUT status bit (before registering your watchdog timer device) you can either: diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt index 17ddd82..04fddbac 100644 --- a/Documentation/watchdog/watchdog-parameters.txt +++ b/Documentation/watchdog/watchdog-parameters.txt @@ -78,6 +78,11 @@ wd0_timeout: Default watchdog0 timeout in 1/10secs wd1_timeout: Default watchdog1 timeout in 1/10secs wd2_timeout: Default watchdog2 timeout in 1/10secs ------------------------------------------------- +da9052wdt: +timeout: Watchdog timeout in seconds. 2<= timeout <=131, default=2.048s +nowayout: Watchdog cannot be stopped once started + (default=kernel config parameter) +------------------------------------------------- davinci_wdt: heartbeat: Watchdog heartbeat period in seconds from 1 to 600, default 60 ------------------------------------------------- diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt index a0b577d..a6ab4b6 100644 --- a/Documentation/workqueue.txt +++ b/Documentation/workqueue.txt @@ -89,25 +89,28 @@ called thread-pools. The cmwq design differentiates between the user-facing workqueues that subsystems and drivers queue work items on and the backend mechanism -which manages thread-pool and processes the queued work items. +which manages thread-pools and processes the queued work items. The backend is called gcwq. There is one gcwq for each possible CPU -and one gcwq to serve work items queued on unbound workqueues. +and one gcwq to serve work items queued on unbound workqueues. Each +gcwq has two thread-pools - one for normal work items and the other +for high priority ones. Subsystems and drivers can create and queue work items through special workqueue API functions as they see fit. They can influence some aspects of the way the work items are executed by setting flags on the workqueue they are putting the work item on. These flags include -things like CPU locality, reentrancy, concurrency limits and more. To -get a detailed overview refer to the API description of +things like CPU locality, reentrancy, concurrency limits, priority and +more. To get a detailed overview refer to the API description of alloc_workqueue() below. -When a work item is queued to a workqueue, the target gcwq is -determined according to the queue parameters and workqueue attributes -and appended on the shared worklist of the gcwq. For example, unless -specifically overridden, a work item of a bound workqueue will be -queued on the worklist of exactly that gcwq that is associated to the -CPU the issuer is running on. +When a work item is queued to a workqueue, the target gcwq and +thread-pool is determined according to the queue parameters and +workqueue attributes and appended on the shared worklist of the +thread-pool. For example, unless specifically overridden, a work item +of a bound workqueue will be queued on the worklist of either normal +or highpri thread-pool of the gcwq that is associated to the CPU the +issuer is running on. For any worker pool implementation, managing the concurrency level (how many execution contexts are active) is an important issue. cmwq @@ -115,26 +118,26 @@ tries to keep the concurrency at a minimal but sufficient level. Minimal to save resources and sufficient in that the system is used at its full capacity. -Each gcwq bound to an actual CPU implements concurrency management by -hooking into the scheduler. The gcwq is notified whenever an active -worker wakes up or sleeps and keeps track of the number of the -currently runnable workers. Generally, work items are not expected to -hog a CPU and consume many cycles. That means maintaining just enough -concurrency to prevent work processing from stalling should be -optimal. As long as there are one or more runnable workers on the -CPU, the gcwq doesn't start execution of a new work, but, when the -last running worker goes to sleep, it immediately schedules a new -worker so that the CPU doesn't sit idle while there are pending work -items. This allows using a minimal number of workers without losing -execution bandwidth. +Each thread-pool bound to an actual CPU implements concurrency +management by hooking into the scheduler. The thread-pool is notified +whenever an active worker wakes up or sleeps and keeps track of the +number of the currently runnable workers. Generally, work items are +not expected to hog a CPU and consume many cycles. That means +maintaining just enough concurrency to prevent work processing from +stalling should be optimal. As long as there are one or more runnable +workers on the CPU, the thread-pool doesn't start execution of a new +work, but, when the last running worker goes to sleep, it immediately +schedules a new worker so that the CPU doesn't sit idle while there +are pending work items. This allows using a minimal number of workers +without losing execution bandwidth. Keeping idle workers around doesn't cost other than the memory space for kthreads, so cmwq holds onto idle ones for a while before killing them. For an unbound wq, the above concurrency management doesn't apply and -the gcwq for the pseudo unbound CPU tries to start executing all work -items as soon as possible. The responsibility of regulating +the thread-pools for the pseudo unbound CPU try to start executing all +work items as soon as possible. The responsibility of regulating concurrency level is on the users. There is also a flag to mark a bound wq to ignore the concurrency management. Please refer to the API section for details. @@ -205,31 +208,22 @@ resources, scheduled and executed. WQ_HIGHPRI - Work items of a highpri wq are queued at the head of the - worklist of the target gcwq and start execution regardless of - the current concurrency level. In other words, highpri work - items will always start execution as soon as execution - resource is available. + Work items of a highpri wq are queued to the highpri + thread-pool of the target gcwq. Highpri thread-pools are + served by worker threads with elevated nice level. - Ordering among highpri work items is preserved - a highpri - work item queued after another highpri work item will start - execution after the earlier highpri work item starts. - - Although highpri work items are not held back by other - runnable work items, they still contribute to the concurrency - level. Highpri work items in runnable state will prevent - non-highpri work items from starting execution. - - This flag is meaningless for unbound wq. + Note that normal and highpri thread-pools don't interact with + each other. Each maintain its separate pool of workers and + implements concurrency management among its workers. WQ_CPU_INTENSIVE Work items of a CPU intensive wq do not contribute to the concurrency level. In other words, runnable CPU intensive - work items will not prevent other work items from starting - execution. This is useful for bound work items which are - expected to hog CPU cycles so that their execution is - regulated by the system scheduler. + work items will not prevent other work items in the same + thread-pool from starting execution. This is useful for bound + work items which are expected to hog CPU cycles so that their + execution is regulated by the system scheduler. Although CPU intensive work items don't contribute to the concurrency level, start of their executions is still @@ -239,14 +233,6 @@ resources, scheduled and executed. This flag is meaningless for unbound wq. - WQ_HIGHPRI | WQ_CPU_INTENSIVE - - This combination makes the wq avoid interaction with - concurrency management completely and behave as a simple - per-CPU execution context provider. Work items queued on a - highpri CPU-intensive wq start execution as soon as resources - are available and don't affect execution of other work items. - @max_active: @max_active determines the maximum number of execution contexts per @@ -328,20 +314,7 @@ If @max_active == 2, 35 w2 wakes up and finishes Now, let's assume w1 and w2 are queued to a different wq q1 which has -WQ_HIGHPRI set, - - TIME IN MSECS EVENT - 0 w1 and w2 start and burn CPU - 5 w1 sleeps - 10 w2 sleeps - 10 w0 starts and burns CPU - 15 w0 sleeps - 15 w1 wakes up and finishes - 20 w2 wakes up and finishes - 25 w0 wakes up and burns CPU - 30 w0 finishes - -If q1 has WQ_CPU_INTENSIVE set, +WQ_CPU_INTENSIVE set, TIME IN MSECS EVENT 0 w0 starts and burns CPU diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt index 7c3a880..9efceff 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt @@ -54,6 +54,9 @@ Protocol 2.10: (Kernel 2.6.31) Added a protocol for relaxed alignment beyond the kernel_alignment added, new init_size and pref_address fields. Added extended boot loader IDs. +Protocol 2.11: (Kernel 3.6) Added a field for offset of EFI handover + protocol entry point. + **** MEMORY LAYOUT The traditional memory map for the kernel loader, used for Image or @@ -189,6 +192,7 @@ Offset Proto Name Meaning of struct setup_data 0258/8 2.10+ pref_address Preferred loading address 0260/4 2.10+ init_size Linear memory required during initialization +0264/4 2.11+ handover_offset Offset of handover entry point (1) For backwards compatibility, if the setup_sects field contains 0, the real value is 4. @@ -363,7 +367,8 @@ Protocol: 2.00+ ext_loader_type <- 0x05 ext_loader_ver <- 0x23 - Assigned boot loader ids: + Assigned boot loader ids (hexadecimal): + 0 LILO (0x00 reserved for pre-2.00 bootloader) 1 Loadlin 2 bootsect-loader (0x20, all other values reserved) @@ -378,6 +383,8 @@ Protocol: 2.00+ C Arcturus Networks uCbootloader E Extended (see ext_loader_type) F Special (0xFF = undefined) + 10 Reserved + 11 Minimal Linux Bootloader <http://sebastian-plotz.blogspot.de> Please contact <hpa@zytor.com> if you need a bootloader ID value assigned. @@ -690,6 +697,16 @@ Offset/size: 0x260/4 else runtime_start = pref_address +Field name: handover_offset +Type: read +Offset/size: 0x264/4 + + This field is the offset from the beginning of the kernel image to + the EFI handover protocol entry point. Boot loaders using the EFI + handover protocol to boot the kernel should jump to this offset. + + See EFI HANDOVER PROTOCOL below for more details. + **** THE IMAGE CHECKSUM @@ -1010,3 +1027,30 @@ segment; __BOOS_CS must have execute/read permission, and __BOOT_DS must have read/write permission; CS must be __BOOT_CS and DS, ES, SS must be __BOOT_DS; interrupt must be disabled; %esi must hold the base address of the struct boot_params; %ebp, %edi and %ebx must be zero. + +**** EFI HANDOVER PROTOCOL + +This protocol allows boot loaders to defer initialisation to the EFI +boot stub. The boot loader is required to load the kernel/initrd(s) +from the boot media and jump to the EFI handover protocol entry point +which is hdr->handover_offset bytes from the beginning of +startup_{32,64}. + +The function prototype for the handover entry point looks like this, + + efi_main(void *handle, efi_system_table_t *table, struct boot_params *bp) + +'handle' is the EFI image handle passed to the boot loader by the EFI +firmware, 'table' is the EFI system table - these are the first two +arguments of the "handoff state" as described in section 2.3 of the +UEFI specification. 'bp' is the boot loader-allocated boot params. + +The boot loader *must* fill out the following fields in bp, + + o hdr.code32_start + o hdr.cmd_line_ptr + o hdr.cmdline_size + o hdr.ramdisk_image (if applicable) + o hdr.ramdisk_size (if applicable) + +All other fields should be zero. diff --git a/Documentation/x86/efi-stub.txt b/Documentation/x86/efi-stub.txt new file mode 100644 index 0000000..44e6bb6 --- /dev/null +++ b/Documentation/x86/efi-stub.txt @@ -0,0 +1,65 @@ + 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 +arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c, +respectively. + +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 +elilo. Since the EFI boot stub performs the jobs of a boot loader, in +a certain sense it *IS* the boot loader. + +The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option. + + +**** How to install bzImage.efi + +The bzImage located in arch/x86/boot/bzImage must be copied to the EFI +System Partiion (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. + + +**** Passing kernel parameters from the EFI shell + +Arguments to the kernel can be passed after bzImage.efi, e.g. + + fs0:> bzImage.efi console=ttyS0 root=/dev/sda4 + + +**** The "initrd=" option + +Like most boot loaders, the EFI stub allows the user to specify +multiple initrd files using the "initrd=" option. This is the only EFI +stub-specific command line parameter, everything else is passed to the +kernel when it boots. + +The path to the initrd file must be an absolute path from the +beginning of the ESP, relative path names do not work. Also, the path +is an EFI-style path and directory elements must be separated with +backslashes (\). For example, given the following directory layout, + +fs0:> + Kernels\ + bzImage.efi + initrd-large.img + + Ramdisks\ + initrd-small.img + initrd-medium.img + +to boot with the initrd-large.img file if the current working +directory is fs0:\Kernels, the following command must be used, + + fs0:\Kernels> bzImage.efi initrd=\Kernels\initrd-large.img + +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. diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt index f606ba8..4263022 100644 --- a/Documentation/zh_CN/magic-number.txt +++ b/Documentation/zh_CN/magic-number.txt @@ -160,7 +160,7 @@ QUEUE_MAGIC_USED 0xf7e1cc33 queue_entry drivers/scsi/arm/queue.c HTB_CMAGIC 0xFEFAFEF1 htb_class net/sched/sch_htb.c NMI_MAGIC 0x48414d4d455201 nmi_s arch/mips/include/asm/sn/nmi.h -请注意，在声音记忆管理中仍然有每一些被定义的驱动魔术值。查看include/sound/sndmagic.h来获取他们完整的列表信息。很多OSS声音驱动拥有自己从声卡PCI ID构建的魔术值-他们也没有被列在这里。 +请注意，在声音记忆管理中仍然有一些特殊的为每个驱动定义的魔术值。查看include/sound/sndmagic.h来获取他们完整的列表信息。很多OSS声音驱动拥有自己从声卡PCI ID构建的魔术值-他们也没有被列在这里。 IrDA子系统也使用了大量的自己的魔术值，查看include/net/irda/irda.h来获取他们完整的信息。 |
