diff options
Diffstat (limited to 'Documentation')
147 files changed, 11157 insertions, 2777 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 2214f123a976..49c051380daf 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 000000000000..3243613bc2d2 --- /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/testing/debugfs-pfo-nx-crypto b/Documentation/ABI/testing/debugfs-pfo-nx-crypto new file mode 100644 index 000000000000..685d5a448423 --- /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 000000000000..281ecc5f9709 --- /dev/null +++ b/Documentation/ABI/testing/dev-kmsg @@ -0,0 +1,90 @@ +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. + The values are separated by a ','. Future extensions might + add more comma separated values before the terminating ';'. + Unknown 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 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 + +Users: dmesg(1), userspace kernel log consumers diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio new file mode 100644 index 000000000000..5bc8a476c15e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -0,0 +1,737 @@ +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 datardy 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 Celsuis. + +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) Data converted by application of offset then scale to + radians per second. 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/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/in_capacitance_scale_available +KernelVersion: 2.635 +Contact: linux-iio@vger.kernel.org +Description: + If a discrete set of scale values are 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 +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. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY&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 +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 + 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 +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 +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. Clearing returns to + normal operation. Y may be suppressed if all outputs are + controlled together. + +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 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/.../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-in_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 a64 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-usb b/Documentation/ABI/testing/sysfs-bus-usb index 7c22a532fdfb..6df4e6f57560 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,7 @@ 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. diff --git a/Documentation/ABI/testing/sysfs-class-extcon b/Documentation/ABI/testing/sysfs-class-extcon new file mode 100644 index 000000000000..20ab361bd8c6 --- /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-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh index b218e0f8bdb3..c81fe89c4c46 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-power b/Documentation/ABI/testing/sysfs-devices-power index 840f7d64d483..45000f0db4d4 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 e7be75b96e4b..5dab36448b44 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-driver-wacom b/Documentation/ABI/testing/sysfs-driver-wacom index 0130d6683c14..56c54558c8a4 100644 --- a/Documentation/ABI/testing/sysfs-driver-wacom +++ b/Documentation/ABI/testing/sysfs-driver-wacom @@ -9,6 +9,14 @@ 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 diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index b464d12761ba..31725ffeeb3a 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -172,3 +172,62 @@ 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. diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index c5ac6929c41c..f3e214f9e256 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -516,7 +516,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 66725a3d30dc..bc3d9f8c0a90 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 7160652a8736..00687ee9d363 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 07a9c48de5a2..eee71426ecb8 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 31df1aa00710..deb71baed328 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 467ccac6ec50..000000000000 --- 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 89941329290e..676bc46f9c52 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -2097,7 +2097,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> @@ -2257,7 +2257,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.". @@ -2270,7 +2270,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/HOWTO b/Documentation/HOWTO index f7ade3b3b40d..59c080f084ef 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 30b656ece7aa..31d302bc5863 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/RCU/torture.txt b/Documentation/RCU/torture.txt index 375d3fb71437..4ddf3913fd8c 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 @@ -188,7 +198,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 +240,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/arm/00-INDEX b/Documentation/arm/00-INDEX index 91c24a1e8a9e..36420e116c90 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 68d21d92a30b..000000000000 --- 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/SPEAr/overview.txt b/Documentation/arm/SPEAr/overview.txt index 253a35c6f782..28a9af953b9d 100644 --- a/Documentation/arm/SPEAr/overview.txt +++ b/Documentation/arm/SPEAr/overview.txt @@ -17,14 +17,14 @@ Introduction 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) @@ -51,10 +51,11 @@ Introduction 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. + 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.kumar@st.com>, (c) 2010-2012 ST Microelectronics diff --git a/Documentation/blackfin/bfin-gpio-notes.txt b/Documentation/blackfin/bfin-gpio-notes.txt index d36b01f778b9..d245f39c3d01 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/resource_counter.txt b/Documentation/cgroups/resource_counter.txt index 95b24d766eab..f3c4ec3626a2 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) diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 00383186d8fb..47a154f30290 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 diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt new file mode 100644 index 000000000000..52478c83d0cc --- /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/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt new file mode 100644 index 000000000000..c63097d6afeb --- /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/lpc32xx-mic.txt b/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt new file mode 100644 index 000000000000..539adca19e8f --- /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 000000000000..56ec8ddc4a3b --- /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 000000000000..80b9a94d9a23 --- /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 d8de933e9d81..117d741a2e4f 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 000000000000..9a6e251462e7 --- /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/spear.txt b/Documentation/devicetree/bindings/arm/spear.txt index f8e54f092328..aa5f355cc947 100644 --- a/Documentation/devicetree/bindings/arm/spear.txt +++ b/Documentation/devicetree/bindings/arm/spear.txt @@ -6,3 +6,21 @@ 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"; + +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"; 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 000000000000..c25a0a55151d --- /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: + mc { + 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 000000000000..e47e73f612f4 --- /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: + mc { + compatible = "nvidia,tegra30-mc"; + reg = <0x7000f000 0x010 + 0x7000f03c 0x1b4 + 0x7000f200 0x028 + 0x7000f284 0x17c>; + interrupts = <0 77 0x04>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-nmk.txt b/Documentation/devicetree/bindings/gpio/gpio-nmk.txt new file mode 100644 index 000000000000..ee87467ad8d6 --- /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; + supports-sleepmode; + gpio-bank = <1>; + }; diff --git a/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt b/Documentation/devicetree/bindings/gpio/mrvl-gpio.txt index 1e34cfe5ebea..05428f39d9ac 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/i2c/mrvl-i2c.txt b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt index 071eb3caae91..b891ee218354 100644 --- a/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt +++ b/Documentation/devicetree/bindings/i2c/mrvl-i2c.txt @@ -3,34 +3,31 @@ 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>; }; diff --git a/Documentation/devicetree/bindings/i2c/pnx.txt b/Documentation/devicetree/bindings/i2c/pnx.txt new file mode 100644 index 000000000000..fe98ada33ee4 --- /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/misc/bmp085.txt b/Documentation/devicetree/bindings/misc/bmp085.txt new file mode 100644 index 000000000000..91dfda2e4e11 --- /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/mtd/orion-nand.txt b/Documentation/devicetree/bindings/mtd/orion-nand.txt new file mode 100644 index 000000000000..b2356b7d2fa4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/orion-nand.txt @@ -0,0 +1,50 @@ +NAND support for Marvell Orion SoC platforms + +Required properties: +- compatible : "mrvl,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 = "mrvl,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/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt index 1ad80d5865a9..f31b686d4556 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: diff --git a/Documentation/devicetree/bindings/net/lpc-eth.txt b/Documentation/devicetree/bindings/net/lpc-eth.txt new file mode 100644 index 000000000000..585021acd178 --- /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 000000000000..79384113c2b0 --- /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 000000000000..f65606f8d632 --- /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/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt new file mode 100644 index 000000000000..ab19e6bc7d3b --- /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 000000000000..b96fa4c31745 --- /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 000000000000..ca85ca432ef0 --- /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 000000000000..82b43f915857 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6q-pinctrl.txt @@ -0,0 +1,1628 @@ +* 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 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 000000000000..f7e8e8f4d9a3 --- /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 000000000000..c8e578263ce2 --- /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 000000000000..c275b70349c1 --- /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 000000000000..c95ea8278f87 --- /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_spear.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl_spear.txt new file mode 100644 index 000000000000..3664d37e6799 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl_spear.txt @@ -0,0 +1,108 @@ +ST Microelectronics, SPEAr pinmux controller + +Required properties: +- compatible : "st,spear300-pinmux" + : "st,spear310-pinmux" + : "st,spear320-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" + +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" diff --git a/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt b/Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt deleted file mode 100644 index 36f82dbdd14d..000000000000 --- 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/regulator/fixed-regulator.txt b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt index 9cf57fd042d2..2f5b6b1ba15f 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt @@ -8,6 +8,8 @@ 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. Any property defined as part of the core regulator binding, defined in regulator.txt, can also be used. @@ -25,5 +27,6 @@ Example: gpio = <&gpio1 16 0>; startup-delay-us = <70000>; enable-active-high; - regulator-boot-on + regulator-boot-on; + gpio-open-drain; }; diff --git a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt new file mode 100644 index 000000000000..c8ca6b8f6582 --- /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/tps6586x.txt b/Documentation/devicetree/bindings/regulator/tps6586x.txt new file mode 100644 index 000000000000..0fcabaa3baa3 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/tps6586x.txt @@ -0,0 +1,97 @@ +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 be named + after their hardware counterparts: sm[0-2], ldo[0-9] and ldo_rtc + +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; + + regulators { + sm0_reg: sm0 { + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + regulator-always-on; + }; + + sm1_reg: sm1 { + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + regulator-always-on; + }; + + sm2_reg: sm2 { + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <4550000>; + regulator-boot-on; + regulator-always-on; + }; + + ldo0_reg: ldo0 { + regulator-name = "PCIE CLK"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + ldo1_reg: ldo1 { + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + }; + + ldo2_reg: ldo2 { + regulator-min-microvolt = < 725000>; + regulator-max-microvolt = <1500000>; + }; + + ldo3_reg: ldo3 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo4_reg: ldo4 { + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <2475000>; + }; + + ldo5_reg: ldo5 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo6_reg: ldo6 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo7_reg: ldo7 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo8_reg: ldo8 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + + ldo9_reg: ldo9 { + regulator-min-microvolt = <1250000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; 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 000000000000..e4acdd891e49 --- /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 000000000000..601c518eddaa --- /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 000000000000..c37ba6143d9b --- /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/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt new file mode 100644 index 000000000000..1ac7b1642186 --- /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 000000000000..dfa6c037124a --- /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/tegra-audio-trimslice.txt b/Documentation/devicetree/bindings/sound/tegra-audio-trimslice.txt new file mode 100644 index 000000000000..04b14cfb1f16 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/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/tegra-audio-wm8753.txt b/Documentation/devicetree/bindings/sound/tegra-audio-wm8753.txt new file mode 100644 index 000000000000..c4dd39ce6165 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/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/staging/iio/adc/lpc32xx-adc.txt b/Documentation/devicetree/bindings/staging/iio/adc/lpc32xx-adc.txt new file mode 100644 index 000000000000..b3629d3a9adf --- /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 000000000000..02ea23a63f20 --- /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/usb/isp1301.txt b/Documentation/devicetree/bindings/usb/isp1301.txt new file mode 100644 index 000000000000..5405d99d9aaa --- /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 000000000000..29f12a533f66 --- /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/ohci-nxp.txt b/Documentation/devicetree/bindings/usb/ohci-nxp.txt new file mode 100644 index 000000000000..71e28c1017ed --- /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 000000000000..f8a464a25653 --- /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 82ac057a24a9..107d8addf0e4 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -8,6 +8,7 @@ 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. diff --git a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt new file mode 100644 index 000000000000..7c7f6887c796 --- /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/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 2a596a4fc23e..950856bd2e39 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 93e784c2607b..fb6683188ef7 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 74e6c7782678..6e1684981da2 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 fdcc49fad8e1..03df2b020332 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt @@ -734,7 +734,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 38cf0c7b559f..a55e4910924e 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 000000000000..eb0fa5f4fe88 --- /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/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 09701afc031a..c59f6e59fc1e 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> --------------------------- @@ -558,3 +565,14 @@ Why: The V4L2_CID_VCENTER, V4L2_CID_HCENTER controls have been deprecated There are newer controls (V4L2_CID_PAN*, V4L2_CID_TILT*) that provide similar functionality. 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. + +---------------------------- diff --git a/Documentation/filesystems/gfs2-glocks.txt b/Documentation/filesystems/gfs2-glocks.txt index 0494f78d87e4..fcc79957be63 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 4cda926628aa..cc4f2306609e 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 c7919c6e3bea..52ae07f5f578 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/proc.txt b/Documentation/filesystems/proc.txt index b7413cb46dcb..ef088e55ab2e 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -996,7 +996,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) diff --git a/Documentation/filesystems/qnx6.txt b/Documentation/filesystems/qnx6.txt index 050223ea03c7..e59f2f09f56e 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/hwmon/ina2xx b/Documentation/hwmon/ina2xx new file mode 100644 index 000000000000..f50a6cc27616 --- /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 23b7def21ba8..87850d86c559 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/wm831x b/Documentation/hwmon/wm831x index 24f47d8f6a42..11446757c8c8 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/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index e34b531dc316..915f28c470e9 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/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c1601e5a8b71..5b6e58492229 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. @@ -610,7 +610,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 +730,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] @@ -2161,6 +2166,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 +2338,100 @@ 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.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 +2462,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 @@ -2847,6 +2939,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/mca.txt b/Documentation/mca.txt deleted file mode 100644 index dfd130c2207d..000000000000 --- 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 000000000000..f4ad9a7d0f4b --- /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 8f485d72cf25..6d0c2519cf47 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 000000000000..f356b81ca1ec --- /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 000000000000..00e8c3e836ff --- /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 000000000000..6b3625d3058c --- /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 000000000000..01804f216312 --- /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 000000000000..2785697da59d --- /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 features 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 applications. Therefore, the Intel MEI driver handles +this internally by maintaining request queues for the applications. + +The driver is oblivious to data that is 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 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 9ad9ddeb384c..2cc3c7733a2f 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 dadfe8147ab8..000000000000 --- 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 dcc9eaf59395..fbf722e15ac3 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 221ad0cdf11f..75a592365af9 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,12 +201,13 @@ 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. diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 56ca3b75376e..ac295399f0d4 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -649,7 +649,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: diff --git a/Documentation/networking/fore200e.txt b/Documentation/networking/fore200e.txt index f648eb265188..d52af53efdc5 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 1dc1c24a7547..703cf4370c79 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 1619a8c80873..6f896b94abdc 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -190,6 +190,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 @@ -1287,13 +1301,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: @@ -1484,11 +1507,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 e0a2aa585ca3..d7a15fe91bf7 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 b95b5bf96751..000000000000 --- 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/smctr.txt b/Documentation/networking/smctr.txt deleted file mode 100644 index 9af25b810c1f..000000000000 --- 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 d0aeeadd264b..ab1e8d7004c5 100644 --- a/Documentation/networking/stmmac.txt +++ b/Documentation/networking/stmmac.txt @@ -111,11 +111,12 @@ and detailed below as well: 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; @@ -136,10 +137,12 @@ Where: 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 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 @@ -160,7 +163,7 @@ Where: o custom_cfg: this is a custom configuration that can be passed while initialising the resources. -The we have: +For MDIO bus The we have: struct stmmac_mdio_bus_data { int bus_id; @@ -177,10 +180,28 @@ 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, diff --git a/Documentation/networking/tms380tr.txt b/Documentation/networking/tms380tr.txt deleted file mode 100644 index 1f73e13058df..000000000000 --- 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/nfc/nfc-hci.txt b/Documentation/nfc/nfc-hci.txt new file mode 100644 index 000000000000..216b7254fcc3 --- /dev/null +++ b/Documentation/nfc/nfc-hci.txt @@ -0,0 +1,155 @@ +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 if for executing commands : nfc_hci_msg_tx_work(). Only one command +can be executing at any given moment. +- one if for dispatching received events and responses : 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 (*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); +}; + +open() and close() shall turn the hardware on and off. 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 another optional entrypoint to return the protocols +corresponding to a proprietary gate. + +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) +Serialize execution of HCI commands. Complete execution in case of resp 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 agregated 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. Reponse 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. diff --git a/Documentation/parisc/debugging b/Documentation/parisc/debugging index d728594058e5..7d75223fa18d 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 d97bccf46147..e40f4b4e1977 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/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt index e272d9909e39..13902778ae44 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 f28f9a6f0347..e13dafc8e8f1 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/prctl/seccomp_filter.txt b/Documentation/prctl/seccomp_filter.txt new file mode 100644 index 000000000000..597c3c581375 --- /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/ramoops.txt b/Documentation/ramoops.txt index 8fb1ba7fe7bf..4ba7db231cb2 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,6 +30,11 @@ 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: @@ -38,7 +43,7 @@ Setting the ramoops parameters can be done in 2 different manners: 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 +51,7 @@ static struct ramoops_platform_data ramoops_data = { .mem_address = <...>, .record_size = <...>, .dump_oops = <...>, + .ecc = <...>, }; static struct platform_device ramoops_dev = { @@ -71,6 +77,6 @@ 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. diff --git a/Documentation/scheduler/sched-design-CFS.txt b/Documentation/scheduler/sched-design-CFS.txt index 91ecff07cede..d529e02d928d 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 b7ee379b651b..443f0c76bab4 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 b7dd6502bec5..9b0787f965e9 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 83f8ea8b79eb..80441ab608e4 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 ac41a9fcac77..000000000000 --- 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 21e5798526ee..2bfd6f6d2d3d 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 a340b18cd4eb..2b06aba4fa0f 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 d2f72ae66432..a416479b8a1c 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 a9511f179069..e369de2d48cd 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 d389acd31e19..aa0dbd74b71b 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 55090914a9c5..4d798c0cb5cb 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 8c16d50f6cb6..221b81016dba 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -1545,7 +1545,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/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt index c83a835350f0..90e9b3a11abc 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 d01ffbfd5808..bf10bed4574b 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 806fe490a56d..000000000000 --- 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/static-keys.txt b/Documentation/static-keys.txt index d93f3c00f245..9f5263d3152c 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/net.txt b/Documentation/sysctl/net.txt index 3201a7097e4d..98335b7a5337 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/usb/dwc3.txt b/Documentation/usb/dwc3.txt index 7b590edae145..1d02c01d1c7c 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 000000000000..eaaaea019fc7 --- /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/wusb-cbaf b/Documentation/usb/wusb-cbaf index 426ddaaef96f..8b3d43efce90 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 ce8213d28b67..38e742fd0df7 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/virtio-spec.txt b/Documentation/virtual/virtio-spec.txt index da094737e2f8..0d6ec85481cb 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/vme_api.txt b/Documentation/vme_api.txt new file mode 100644 index 000000000000..856efa35f6e3 --- /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/watchdog/src/watchdog-test.c b/Documentation/watchdog/src/watchdog-test.c index 63fdc34ceb98..73ff5cc93e05 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 227f6cd0e5fa..25fe4304f2fc 100644 --- a/Documentation/watchdog/watchdog-kernel-api.txt +++ b/Documentation/watchdog/watchdog-kernel-api.txt @@ -59,7 +59,7 @@ 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. * status: this field contains a number of status bits that give extra information about the status of the device (Like: is the watchdog timer diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt index f606ba8598cf..4263022f5002 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来获取他们完整的信息。 |
