diff options
Diffstat (limited to 'Documentation')
180 files changed, 7375 insertions, 2285 deletions
diff --git a/Documentation/ABI/README b/Documentation/ABI/README index 10069828568..1fafc4b0753 100644 --- a/Documentation/ABI/README +++ b/Documentation/ABI/README @@ -72,3 +72,16 @@ kernel tree without going through the obsolete state first. It's up to the developer to place their interfaces in the category they wish for it to start out in. + + +Notable bits of non-ABI, which should not under any circumstances be considered +stable: + +- Kconfig. Userspace should not rely on the presence or absence of any + particular Kconfig symbol, in /proc/config.gz, in the copy of .config + commonly installed to /boot, or in any invocation of the kernel build + process. + +- Kernel-internal symbols. Do not rely on the presence, absence, location, or + type of any kernel symbol, either in System.map files or the kernel binary + itself. See Documentation/stable_api_nonsense.txt. diff --git a/Documentation/ABI/stable/sysfs-bus-usb b/Documentation/ABI/stable/sysfs-bus-usb index 2be603c52a2..a6b68572474 100644 --- a/Documentation/ABI/stable/sysfs-bus-usb +++ b/Documentation/ABI/stable/sysfs-bus-usb @@ -37,8 +37,8 @@ Description: that the USB device has been connected to the machine. This file is read-only. Users: - PowerTOP <power@bughost.org> - http://www.lesswatts.org/projects/powertop/ + PowerTOP <powertop@lists.01.org> + https://01.org/powertop/ What: /sys/bus/usb/device/.../power/active_duration Date: January 2008 @@ -57,8 +57,8 @@ Description: will give an integer percentage. Note that this does not account for counter wrap. Users: - PowerTOP <power@bughost.org> - http://www.lesswatts.org/projects/powertop/ + PowerTOP <powertop@lists.01.org> + https://01.org/powertop/ What: /sys/bus/usb/devices/<busnum>-<port[.port]>...:<config num>-<interface num>/supports_autosuspend Date: January 2008 diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage new file mode 100644 index 00000000000..ad72a37ee9f --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage @@ -0,0 +1,31 @@ +What: /config/usb-gadget/gadget/functions/mass_storage.name +Date: Oct 2013 +KenelVersion: 3.13 +Description: + The attributes: + + stall - Set to permit function to halt bulk endpoints. + Disabled on some USB devices known not to work + correctly. You should set it to true. + num_buffers - Number of pipeline buffers. Valid numbers + are 2..4. Available only if + CONFIG_USB_GADGET_DEBUG_FILES is set. + +What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.name +Date: Oct 2013 +KenelVersion: 3.13 +Description: + The attributes: + + file - The path to the backing file for the LUN. + Required if LUN is not marked as removable. + ro - Flag specifying access to the LUN shall be + read-only. This is implied if CD-ROM emulation + is enabled as well as when it was impossible + to open "filename" in R/W mode. + removable - Flag specifying that LUN shall be indicated as + being removable. + cdrom - Flag specifying that LUN shall be reported as + being a CD-ROM. + nofua - Flag specifying that FUA flag + in SCSI WRITE(10,12) diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 39c8de0e53d..b20e829d350 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -79,7 +79,7 @@ Description: 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. + application of scale and offset are millivolts. What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_raw KernelVersion: 2.6.35 @@ -90,7 +90,7 @@ Description: 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. + of scale and offset are millivolts. What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw KernelVersion: 3.2 @@ -537,6 +537,62 @@ Description: 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_hysteresis +What: /sys/.../events/in_accel_x_thresh_falling_hysteresis +What: /sys/.../events/in_accel_x_thresh_either_hysteresis +What: /sys/.../events/in_accel_y_thresh_rising_hysteresis +What: /sys/.../events/in_accel_y_thresh_falling_hysteresis +What: /sys/.../events/in_accel_y_thresh_either_hysteresis +What: /sys/.../events/in_accel_z_thresh_rising_hysteresis +What: /sys/.../events/in_accel_z_thresh_falling_hysteresis +What: /sys/.../events/in_accel_z_thresh_either_hysteresis +What: /sys/.../events/in_anglvel_x_thresh_rising_hysteresis +What: /sys/.../events/in_anglvel_x_thresh_falling_hysteresis +What: /sys/.../events/in_anglvel_x_thresh_either_hysteresis +What: /sys/.../events/in_anglvel_y_thresh_rising_hysteresis +What: /sys/.../events/in_anglvel_y_thresh_falling_hysteresis +What: /sys/.../events/in_anglvel_y_thresh_either_hysteresis +What: /sys/.../events/in_anglvel_z_thresh_rising_hysteresis +What: /sys/.../events/in_anglvel_z_thresh_falling_hysteresis +What: /sys/.../events/in_anglvel_z_thresh_either_hysteresis +What: /sys/.../events/in_magn_x_thresh_rising_hysteresis +What: /sys/.../events/in_magn_x_thresh_falling_hysteresis +What: /sys/.../events/in_magn_x_thresh_either_hysteresis +What: /sys/.../events/in_magn_y_thresh_rising_hysteresis +What: /sys/.../events/in_magn_y_thresh_falling_hysteresis +What: /sys/.../events/in_magn_y_thresh_either_hysteresis +What: /sys/.../events/in_magn_z_thresh_rising_hysteresis +What: /sys/.../events/in_magn_z_thresh_falling_hysteresis +What: /sys/.../events/in_magn_z_thresh_either_hysteresis +What: /sys/.../events/in_voltageY_thresh_rising_hysteresis +What: /sys/.../events/in_voltageY_thresh_falling_hysteresis +What: /sys/.../events/in_voltageY_thresh_either_hysteresis +What: /sys/.../events/in_tempY_thresh_rising_hysteresis +What: /sys/.../events/in_tempY_thresh_falling_hysteresis +What: /sys/.../events/in_tempY_thresh_either_hysteresis +What: /sys/.../events/in_illuminance0_thresh_falling_hysteresis +what: /sys/.../events/in_illuminance0_thresh_rising_hysteresis +what: /sys/.../events/in_illuminance0_thresh_either_hysteresis +what: /sys/.../events/in_proximity0_thresh_falling_hysteresis +what: /sys/.../events/in_proximity0_thresh_rising_hysteresis +what: /sys/.../events/in_proximity0_thresh_either_hysteresis +KernelVersion: 3.13 +Contact: linux-iio@vger.kernel.org +Description: + Specifies the hysteresis of threshold that the device is comparing + against for the events enabled by + <type>Y[_name]_thresh[_(rising|falling)]_hysteresis. + If separate attributes exist for the two directions, but + direction is not specified for this attribute, then a single + hysteresis value applies to both directions. + For falling events the hysteresis is added to the _value attribute for + this event to get the upper threshold for when the event goes back to + normal, for rising events the hysteresis is subtracted from the _value + attribute. E.g. if in_voltage0_raw_thresh_rising_value is set to 1200 + and in_voltage0_raw_thresh_rising_hysteresis is set to 50. The event + will get activated once in_voltage0_raw goes above 1200 and will become + deactived again once the value falls below 1150. + 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 @@ -811,3 +867,14 @@ Description: Writing '1' stores the current device configuration into on-chip EEPROM. After power-up or chip reset the device will automatically load the saved configuration. + +What: /sys/.../iio:deviceX/in_intensity_red_integration_time +What: /sys/.../iio:deviceX/in_intensity_green_integration_time +What: /sys/.../iio:deviceX/in_intensity_blue_integration_time +What: /sys/.../iio:deviceX/in_intensity_clear_integration_time +What: /sys/.../iio:deviceX/in_illuminance_integration_time +KernelVersion: 3.12 +Contact: linux-iio@vger.kernel.org +Description: + This attribute is used to get/set the integration time in + seconds. diff --git a/Documentation/ABI/testing/sysfs-class-mic.txt b/Documentation/ABI/testing/sysfs-class-mic.txt new file mode 100644 index 00000000000..13f48afc534 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-mic.txt @@ -0,0 +1,157 @@ +What: /sys/class/mic/ +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + The mic class directory belongs to Intel MIC devices and + provides information per MIC device. An Intel MIC device is a + PCIe form factor add-in Coprocessor card based on the Intel Many + Integrated Core (MIC) architecture that runs a Linux OS. + +What: /sys/class/mic/mic(x) +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + The directories /sys/class/mic/mic0, /sys/class/mic/mic1 etc., + represent MIC devices (0,1,..etc). Each directory has + information specific to that MIC device. + +What: /sys/class/mic/mic(x)/family +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + Provides information about the Coprocessor family for an Intel + MIC device. For example - "x100" + +What: /sys/class/mic/mic(x)/stepping +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + Provides information about the silicon stepping for an Intel + MIC device. For example - "A0" or "B0" + +What: /sys/class/mic/mic(x)/state +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + When read, this entry provides the current state of an Intel + MIC device in the context of the card OS. Possible values that + will be read are: + "offline" - The MIC device is ready to boot the card OS. On + reading this entry after an OSPM resume, a "boot" has to be + written to this entry if the card was previously shutdown + during OSPM suspend. + "online" - The MIC device has initiated booting a card OS. + "shutting_down" - The card OS is shutting down. + "reset_failed" - The MIC device has failed to reset. + "suspending" - The MIC device is currently being prepared for + suspend. On reading this entry, a "suspend" has to be written + to the state sysfs entry to ensure the card is shutdown during + OSPM suspend. + "suspended" - The MIC device has been suspended. + + When written, this sysfs entry triggers different state change + operations depending upon the current state of the card OS. + Acceptable values are: + "boot" - Boot the card OS image specified by the combination + of firmware, ramdisk, cmdline and bootmode + sysfs entries. + "reset" - Initiates device reset. + "shutdown" - Initiates card OS shutdown. + "suspend" - Initiates card OS shutdown and also marks the card + as suspended. + +What: /sys/class/mic/mic(x)/shutdown_status +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + An Intel MIC device runs a Linux OS during its operation. This + OS can shutdown because of various reasons. When read, this + entry provides the status on why the card OS was shutdown. + Possible values are: + "nop" - shutdown status is not applicable, when the card OS is + "online" + "crashed" - Shutdown because of a HW or SW crash. + "halted" - Shutdown because of a halt command. + "poweroff" - Shutdown because of a poweroff command. + "restart" - Shutdown because of a restart command. + +What: /sys/class/mic/mic(x)/cmdline +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + An Intel MIC device runs a Linux OS during its operation. Before + booting this card OS, it is possible to pass kernel command line + options to configure various features in it, similar to + self-bootable machines. When read, this entry provides + information about the current kernel command line options set to + boot the card OS. This entry can be written to change the + existing kernel command line options. Typically, the user would + want to read the current command line options, append new ones + or modify existing ones and then write the whole kernel command + line back to this entry. + +What: /sys/class/mic/mic(x)/firmware +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + When read, this sysfs entry provides the path name under + /lib/firmware/ where the firmware image to be booted on the + card can be found. The entry can be written to change the + firmware image location under /lib/firmware/. + +What: /sys/class/mic/mic(x)/ramdisk +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + When read, this sysfs entry provides the path name under + /lib/firmware/ where the ramdisk image to be used during card + OS boot can be found. The entry can be written to change + the ramdisk image location under /lib/firmware/. + +What: /sys/class/mic/mic(x)/bootmode +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + When read, this sysfs entry provides the current bootmode for + the card. This sysfs entry can be written with the following + valid strings: + a) linux - Boot a Linux image. + b) elf - Boot an elf image for flash updates. + +What: /sys/class/mic/mic(x)/log_buf_addr +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + An Intel MIC device runs a Linux OS during its operation. For + debugging purpose and early kernel boot messages, the user can + access the card OS log buffer via debugfs. When read, this entry + provides the kernel virtual address of the buffer where the card + OS log buffer can be read. This entry is written by the host + configuration daemon to set the log buffer address. The correct + log buffer address to be written can be found in the System.map + file of the card OS. + +What: /sys/class/mic/mic(x)/log_buf_len +Date: October 2013 +KernelVersion: 3.13 +Contact: Sudeep Dutt <sudeep.dutt@intel.com> +Description: + An Intel MIC device runs a Linux OS during its operation. For + debugging purpose and early kernel boot messages, the user can + access the card OS log buffer via debugfs. When read, this entry + provides the kernel virtual address where the card OS log buffer + length can be read. This entry is written by host configuration + daemon to set the log buffer length address. The correct log + buffer length address to be written can be found in the + System.map file of the card OS. diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd index bfd119ace6a..1399bb2da3e 100644 --- a/Documentation/ABI/testing/sysfs-class-mtd +++ b/Documentation/ABI/testing/sysfs-class-mtd @@ -104,7 +104,7 @@ Description: One of the following ASCII strings, representing the device type: - absent, ram, rom, nor, nand, dataflash, ubi, unknown + absent, ram, rom, nor, nand, mlc-nand, dataflash, ubi, unknown What: /sys/class/mtd/mtdX/writesize Date: April 2009 diff --git a/Documentation/ABI/testing/sysfs-class-net-batman-adv b/Documentation/ABI/testing/sysfs-class-net-batman-adv index bdc00707c75..7f34a95bb96 100644 --- a/Documentation/ABI/testing/sysfs-class-net-batman-adv +++ b/Documentation/ABI/testing/sysfs-class-net-batman-adv @@ -1,13 +1,13 @@ What: /sys/class/net/<iface>/batman-adv/iface_status Date: May 2010 -Contact: Marek Lindner <lindner_marek@yahoo.de> +Contact: Marek Lindner <mareklindner@neomailbox.ch> Description: Indicates the status of <iface> as it is seen by batman. What: /sys/class/net/<iface>/batman-adv/mesh_iface Date: May 2010 -Contact: Marek Lindner <lindner_marek@yahoo.de> +Contact: Marek Lindner <mareklindner@neomailbox.ch> Description: The /sys/class/net/<iface>/batman-adv/mesh_iface file displays the batman mesh interface this <iface> diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh index bdcd8b4e38f..0baa657b18c 100644 --- a/Documentation/ABI/testing/sysfs-class-net-mesh +++ b/Documentation/ABI/testing/sysfs-class-net-mesh @@ -1,22 +1,23 @@ What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms Date: May 2010 -Contact: Marek Lindner <lindner_marek@yahoo.de> +Contact: Marek Lindner <mareklindner@neomailbox.ch> Description: Indicates whether the batman protocol messages of the mesh <mesh_iface> shall be aggregated or not. -What: /sys/class/net/<mesh_iface>/mesh/ap_isolation +What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation Date: May 2011 -Contact: Antonio Quartulli <ordex@autistici.org> +Contact: Antonio Quartulli <antonio@meshcoding.com> Description: Indicates whether the data traffic going from a wireless client to another wireless client will be - silently dropped. + silently dropped. <vlan_subdir> is empty when referring + to the untagged lan. What: /sys/class/net/<mesh_iface>/mesh/bonding Date: June 2010 -Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> +Contact: Simon Wunderlich <sw@simonwunderlich.de> Description: Indicates whether the data traffic going through the mesh will be sent using multiple interfaces at the @@ -24,7 +25,7 @@ Description: What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance Date: November 2011 -Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> +Contact: Simon Wunderlich <sw@simonwunderlich.de> Description: Indicates whether the bridge loop avoidance feature is enabled. This feature detects and avoids loops @@ -41,21 +42,21 @@ Description: What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth Date: October 2010 -Contact: Marek Lindner <lindner_marek@yahoo.de> +Contact: Marek Lindner <mareklindner@neomailbox.ch> Description: Defines the bandwidth which is propagated by this node if gw_mode was set to 'server'. What: /sys/class/net/<mesh_iface>/mesh/gw_mode Date: October 2010 -Contact: Marek Lindner <lindner_marek@yahoo.de> +Contact: Marek Lindner <mareklindner@neomailbox.ch> Description: Defines the state of the gateway features. Can be either 'off', 'client' or 'server'. What: /sys/class/net/<mesh_iface>/mesh/gw_sel_class Date: October 2010 -Contact: Marek Lindner <lindner_marek@yahoo.de> +Contact: Marek Lindner <mareklindner@neomailbox.ch> Description: Defines the selection criteria this node will use to choose a gateway if gw_mode was set to 'client'. @@ -77,25 +78,14 @@ Description: What: /sys/class/net/<mesh_iface>/mesh/orig_interval Date: May 2010 -Contact: Marek Lindner <lindner_marek@yahoo.de> +Contact: Marek Lindner <mareklindner@neomailbox.ch> Description: Defines the interval in milliseconds in which batman sends its protocol messages. What: /sys/class/net/<mesh_iface>/mesh/routing_algo Date: Dec 2011 -Contact: Marek Lindner <lindner_marek@yahoo.de> +Contact: Marek Lindner <mareklindner@neomailbox.ch> Description: Defines the routing procotol this mesh instance uses to find the optimal paths through the mesh. - -What: /sys/class/net/<mesh_iface>/mesh/vis_mode -Date: May 2010 -Contact: Marek Lindner <lindner_marek@yahoo.de> -Description: - Each batman node only maintains information about its - own local neighborhood, therefore generating graphs - showing the topology of the entire mesh is not easily - feasible without having a central instance to collect - the local topologies from all nodes. This file allows - to activate the collecting (server) mode. diff --git a/Documentation/ABI/testing/sysfs-class-powercap b/Documentation/ABI/testing/sysfs-class-powercap new file mode 100644 index 00000000000..db3b3ff70d8 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-powercap @@ -0,0 +1,152 @@ +What: /sys/class/powercap/ +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + The powercap/ class sub directory belongs to the power cap + subsystem. Refer to + Documentation/power/powercap/powercap.txt for details. + +What: /sys/class/powercap/<control type> +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + A <control type> is a unique name under /sys/class/powercap. + Here <control type> determines how the power is going to be + controlled. A <control type> can contain multiple power zones. + +What: /sys/class/powercap/<control type>/enabled +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + This allows to enable/disable power capping for a "control type". + This status affects every power zone using this "control_type. + +What: /sys/class/powercap/<control type>/<power zone> +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + A power zone is a single or a collection of devices, which can + be independently monitored and controlled. A power zone sysfs + entry is qualified with the name of the <control type>. + E.g. intel-rapl:0:1:1. + +What: /sys/class/powercap/<control type>/<power zone>/<child power zone> +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Power zones may be organized in a hierarchy in which child + power zones provide monitoring and control for a subset of + devices under the parent. For example, if there is a parent + power zone for a whole CPU package, each CPU core in it can + be a child power zone. + +What: /sys/class/powercap/.../<power zone>/name +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Specifies the name of this power zone. + +What: /sys/class/powercap/.../<power zone>/energy_uj +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Current energy counter in micro-joules. Write "0" to reset. + If the counter can not be reset, then this attribute is + read-only. + +What: /sys/class/powercap/.../<power zone>/max_energy_range_uj +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Range of the above energy counter in micro-joules. + + +What: /sys/class/powercap/.../<power zone>/power_uw +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Current power in micro-watts. + +What: /sys/class/powercap/.../<power zone>/max_power_range_uw +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Range of the above power value in micro-watts. + +What: /sys/class/powercap/.../<power zone>/constraint_X_name +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Each power zone can define one or more constraints. Each + constraint can have an optional name. Here "X" can have values + from 0 to max integer. + +What: /sys/class/powercap/.../<power zone>/constraint_X_power_limit_uw +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Power limit in micro-watts should be applicable for + the time window specified by "constraint_X_time_window_us". + Here "X" can have values from 0 to max integer. + +What: /sys/class/powercap/.../<power zone>/constraint_X_time_window_us +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Time window in micro seconds. This is used along with + constraint_X_power_limit_uw to define a power constraint. + Here "X" can have values from 0 to max integer. + + +What: /sys/class/powercap/<control type>/.../constraint_X_max_power_uw +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Maximum allowed power in micro watts for this constraint. + Here "X" can have values from 0 to max integer. + +What: /sys/class/powercap/<control type>/.../constraint_X_min_power_uw +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Minimum allowed power in micro watts for this constraint. + Here "X" can have values from 0 to max integer. + +What: /sys/class/powercap/.../<power zone>/constraint_X_max_time_window_us +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Maximum allowed time window in micro seconds for this + constraint. Here "X" can have values from 0 to max integer. + +What: /sys/class/powercap/.../<power zone>/constraint_X_min_time_window_us +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description: + Minimum allowed time window in micro seconds for this + constraint. Here "X" can have values from 0 to max integer. + +What: /sys/class/powercap/.../<power zone>/enabled +Date: September 2013 +KernelVersion: 3.13 +Contact: linux-pm@vger.kernel.org +Description + This allows to enable/disable power capping at power zone level. + This applies to current power zone and its children. diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 9d43e767084..efe449bdf81 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -1,6 +1,6 @@ What: /sys/devices/.../power/ Date: January 2009 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../power directory contains attributes allowing the user space to check and modify some power @@ -8,7 +8,7 @@ Description: What: /sys/devices/.../power/wakeup Date: January 2009 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../power/wakeup attribute allows the user space to check if the device is enabled to wake up the system @@ -34,7 +34,7 @@ Description: What: /sys/devices/.../power/control Date: January 2009 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../power/control attribute allows the user space to control the run-time power management of the device. @@ -53,7 +53,7 @@ Description: What: /sys/devices/.../power/async Date: January 2009 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../async attribute allows the user space to enable or diasble the device's suspend and resume callbacks to @@ -79,7 +79,7 @@ Description: What: /sys/devices/.../power/wakeup_count Date: September 2010 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../wakeup_count attribute contains the number of signaled wakeup events associated with the device. This @@ -88,7 +88,7 @@ Description: What: /sys/devices/.../power/wakeup_active_count Date: September 2010 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../wakeup_active_count attribute contains the number of times the processing of wakeup events associated with @@ -98,7 +98,7 @@ Description: What: /sys/devices/.../power/wakeup_abort_count Date: February 2012 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../wakeup_abort_count attribute contains the number of times the processing of a wakeup event associated with @@ -109,7 +109,7 @@ Description: What: /sys/devices/.../power/wakeup_expire_count Date: February 2012 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../wakeup_expire_count attribute contains the number of times a wakeup event associated with the device has @@ -119,7 +119,7 @@ Description: What: /sys/devices/.../power/wakeup_active Date: September 2010 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../wakeup_active attribute contains either 1, or 0, depending on whether or not a wakeup event associated with @@ -129,7 +129,7 @@ Description: What: /sys/devices/.../power/wakeup_total_time_ms Date: September 2010 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../wakeup_total_time_ms attribute contains the total time of processing wakeup events associated with the @@ -139,7 +139,7 @@ Description: What: /sys/devices/.../power/wakeup_max_time_ms Date: September 2010 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../wakeup_max_time_ms attribute contains the maximum time of processing a single wakeup event associated @@ -149,7 +149,7 @@ Description: What: /sys/devices/.../power/wakeup_last_time_ms Date: September 2010 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../wakeup_last_time_ms attribute contains the value of the monotonic clock corresponding to the time of @@ -160,7 +160,7 @@ Description: What: /sys/devices/.../power/wakeup_prevent_sleep_time_ms Date: February 2012 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute contains the total time the device has been preventing @@ -189,7 +189,7 @@ Description: What: /sys/devices/.../power/pm_qos_latency_us Date: March 2012 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../power/pm_qos_resume_latency_us attribute contains the PM QoS resume latency limit for the given device, @@ -207,7 +207,7 @@ Description: What: /sys/devices/.../power/pm_qos_no_power_off Date: September 2012 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../power/pm_qos_no_power_off attribute is used for manipulating the PM QoS "no power off" flag. If @@ -222,7 +222,7 @@ Description: What: /sys/devices/.../power/pm_qos_remote_wakeup Date: September 2012 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../power/pm_qos_remote_wakeup attribute is used for manipulating the PM QoS "remote wakeup required" diff --git a/Documentation/ABI/testing/sysfs-driver-sunxi-sid b/Documentation/ABI/testing/sysfs-driver-sunxi-sid new file mode 100644 index 00000000000..ffb9536f6ec --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-sunxi-sid @@ -0,0 +1,22 @@ +What: /sys/devices/*/<our-device>/eeprom +Date: August 2013 +Contact: Oliver Schinagl <oliver@schinagl.nl> +Description: read-only access to the SID (Security-ID) on current + A-series SoC's from Allwinner. Currently supports A10, A10s, A13 + and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes, + whereas the newer A20 SoC exposes 512 bytes split into sections. + Besides the 16 bytes of SID, there's also an SJTAG area, + HDMI-HDCP key and some custom keys. Below a quick overview, for + details see the user manual: + 0x000 128 bit root-key (sun[457]i) + 0x010 128 bit boot-key (sun7i) + 0x020 64 bit security-jtag-key (sun7i) + 0x028 16 bit key configuration (sun7i) + 0x02b 16 bit custom-vendor-key (sun7i) + 0x02c 320 bit low general key (sun7i) + 0x040 32 bit read-control access (sun7i) + 0x064 224 bit low general key (sun7i) + 0x080 2304 bit HDCP-key (sun7i) + 0x1a0 768 bit high general key (sun7i) +Users: any user space application which wants to read the SID on + Allwinner's A-series of CPU's. diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index 217772615d0..205a7387844 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -1,6 +1,6 @@ What: /sys/power/ Date: August 2006 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power directory will contain files that will provide a unified interface to the power management @@ -8,7 +8,7 @@ Description: What: /sys/power/state Date: August 2006 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power/state file controls the system power state. Reading from this file returns what states are supported, @@ -22,7 +22,7 @@ Description: What: /sys/power/disk Date: September 2006 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power/disk file controls the operating mode of the suspend-to-disk mechanism. Reading from this file returns @@ -67,7 +67,7 @@ Description: What: /sys/power/image_size Date: August 2006 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power/image_size file controls the size of the image created by the suspend-to-disk mechanism. It can be written a @@ -84,7 +84,7 @@ Description: What: /sys/power/pm_trace Date: August 2006 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power/pm_trace file controls the code which saves the last PM event point in the RTC across reboots, so that you can @@ -133,7 +133,7 @@ Description: What: /sys/power/pm_async Date: January 2009 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power/pm_async file controls the switch allowing the user space to enable or disable asynchronous suspend and resume @@ -146,7 +146,7 @@ Description: What: /sys/power/wakeup_count Date: July 2010 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power/wakeup_count file allows user space to put the system into a sleep state while taking into account the @@ -161,7 +161,7 @@ Description: What: /sys/power/reserved_size Date: May 2011 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power/reserved_size file allows user space to control the amount of memory reserved for allocations made by device @@ -175,7 +175,7 @@ Description: What: /sys/power/autosleep Date: April 2012 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power/autosleep file can be written one of the strings returned by reads from /sys/power/state. If that happens, a @@ -192,7 +192,7 @@ Description: What: /sys/power/wake_lock Date: February 2012 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power/wake_lock file allows user space to create wakeup source objects and activate them on demand (if one of @@ -219,7 +219,7 @@ Description: What: /sys/power/wake_unlock Date: February 2012 -Contact: Rafael J. Wysocki <rjw@sisk.pl> +Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/power/wake_unlock file allows user space to deactivate wakeup sources created with the help of /sys/power/wake_lock. diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 14129f149a7..5e983031cc1 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -101,14 +101,23 @@ style to do this even if your device holds the default setting, because this shows that you did think about these issues wrt. your device. -The query is performed via a call to dma_set_mask(): +The query is performed via a call to dma_set_mask_and_coherent(): - int dma_set_mask(struct device *dev, u64 mask); + int dma_set_mask_and_coherent(struct device *dev, u64 mask); -The query for consistent allocations is performed via a call to -dma_set_coherent_mask(): +which will query the mask for both streaming and coherent APIs together. +If you have some special requirements, then the following two separate +queries can be used instead: - int dma_set_coherent_mask(struct device *dev, u64 mask); + The query for streaming mappings is performed via a call to + dma_set_mask(): + + int dma_set_mask(struct device *dev, u64 mask); + + The query for consistent allocations is performed via a call + to dma_set_coherent_mask(): + + int dma_set_coherent_mask(struct device *dev, u64 mask); Here, dev is a pointer to the device struct of your device, and mask is a bit mask describing which bits of an address your device @@ -137,7 +146,7 @@ exactly why. The standard 32-bit addressing device would do something like this: - if (dma_set_mask(dev, DMA_BIT_MASK(32))) { + if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) { printk(KERN_WARNING "mydev: No suitable DMA available.\n"); goto ignore_this_device; @@ -171,22 +180,20 @@ the case would look like this: int using_dac, consistent_using_dac; - if (!dma_set_mask(dev, DMA_BIT_MASK(64))) { + if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) { using_dac = 1; consistent_using_dac = 1; - dma_set_coherent_mask(dev, DMA_BIT_MASK(64)); - } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) { + } else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) { using_dac = 0; consistent_using_dac = 0; - dma_set_coherent_mask(dev, DMA_BIT_MASK(32)); } else { printk(KERN_WARNING "mydev: No suitable DMA available.\n"); goto ignore_this_device; } -dma_set_coherent_mask() will always be able to set the same or a -smaller mask as dma_set_mask(). However for the rare case that a +The coherent coherent mask will always be able to set the same or a +smaller mask as the streaming mask. However for the rare case that a device driver only uses consistent allocations, one would have to check the return value from dma_set_coherent_mask(). @@ -199,9 +206,9 @@ address you might do something like: goto ignore_this_device; } -When dma_set_mask() is successful, and returns zero, the kernel saves -away this mask you have provided. The kernel will use this -information later when you make DMA mappings. +When dma_set_mask() or dma_set_mask_and_coherent() is successful, and +returns zero, the kernel saves away this mask you have provided. The +kernel will use this information later when you make DMA mappings. There is a case which we are aware of at this time, which is worth mentioning in this documentation. If your device supports multiple diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 78a6c569d20..e865279cec5 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -142,6 +142,14 @@ internal API for use by the platform than an external API for use by driver writers. int +dma_set_mask_and_coherent(struct device *dev, u64 mask) + +Checks to see if the mask is possible and updates the device +streaming and coherent DMA mask parameters if it is. + +Returns: 0 if successful and a negative error if not. + +int dma_set_mask(struct device *dev, u64 mask) Checks to see if the mask is possible and updates the device diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index f403ec3c5c9..46ad6faee9a 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -152,8 +152,8 @@ !Finclude/net/cfg80211.h cfg80211_scan_request !Finclude/net/cfg80211.h cfg80211_scan_done !Finclude/net/cfg80211.h cfg80211_bss -!Finclude/net/cfg80211.h cfg80211_inform_bss_frame -!Finclude/net/cfg80211.h cfg80211_inform_bss +!Finclude/net/cfg80211.h cfg80211_inform_bss_width_frame +!Finclude/net/cfg80211.h cfg80211_inform_bss_width !Finclude/net/cfg80211.h cfg80211_unlink_bss !Finclude/net/cfg80211.h cfg80211_find_ie !Finclude/net/cfg80211.h ieee80211_bss_get_ie diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index fe397f90a34..6c9d9d37c83 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -87,7 +87,10 @@ X!Iinclude/linux/kobject.h !Ekernel/printk/printk.c !Ekernel/panic.c !Ekernel/sys.c -!Ekernel/rcupdate.c +!Ekernel/rcu/srcu.c +!Ekernel/rcu/tree.c +!Ekernel/rcu/tree_plugin.h +!Ekernel/rcu/update.c </sect1> <sect1><title>Device Resource Management</title> diff --git a/Documentation/DocBook/filesystems.tmpl b/Documentation/DocBook/filesystems.tmpl index 25b58efd955..4f676838da0 100644 --- a/Documentation/DocBook/filesystems.tmpl +++ b/Documentation/DocBook/filesystems.tmpl @@ -91,7 +91,6 @@ <title>The Filesystem for Exporting Kernel Objects</title> !Efs/sysfs/file.c !Efs/sysfs/symlink.c -!Efs/sysfs/bin.c </chapter> <chapter id="debugfs"> diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl index d16d21b7a3b..46347f60335 100644 --- a/Documentation/DocBook/genericirq.tmpl +++ b/Documentation/DocBook/genericirq.tmpl @@ -87,7 +87,7 @@ <chapter id="rationale"> <title>Rationale</title> <para> - The original implementation of interrupt handling in Linux is using + The original implementation of interrupt handling in Linux uses the __do_IRQ() super-handler, which is able to deal with every type of interrupt logic. </para> @@ -111,19 +111,19 @@ </itemizedlist> </para> <para> - This split implementation of highlevel IRQ handlers allows us to + This split implementation of high-level IRQ handlers allows us to optimize the flow of the interrupt handling for each specific - interrupt type. This reduces complexity in that particular codepath + interrupt type. This reduces complexity in that particular code path and allows the optimized handling of a given type. </para> <para> The original general IRQ implementation used hw_interrupt_type structures and their ->ack(), ->end() [etc.] callbacks to differentiate the flow control in the super-handler. This leads to - a mix of flow logic and lowlevel hardware logic, and it also leads - to unnecessary code duplication: for example in i386, there is a - ioapic_level_irq and a ioapic_edge_irq irq-type which share many - of the lowlevel details but have different flow handling. + a mix of flow logic and low-level hardware logic, and it also leads + to unnecessary code duplication: for example in i386, there is an + ioapic_level_irq and an ioapic_edge_irq IRQ-type which share many + of the low-level details but have different flow handling. </para> <para> A more natural abstraction is the clean separation of the @@ -132,23 +132,23 @@ <para> Analysing a couple of architecture's IRQ subsystem implementations reveals that most of them can use a generic set of 'irq flow' - methods and only need to add the chip level specific code. + methods and only need to add the chip-level specific code. The separation is also valuable for (sub)architectures - which need specific quirks in the irq flow itself but not in the - chip-details - and thus provides a more transparent IRQ subsystem + which need specific quirks in the IRQ flow itself but not in the + chip details - and thus provides a more transparent IRQ subsystem design. </para> <para> - Each interrupt descriptor is assigned its own highlevel flow + Each interrupt descriptor is assigned its own high-level flow handler, which is normally one of the generic - implementations. (This highlevel flow handler implementation also + implementations. (This high-level flow handler implementation also makes it simple to provide demultiplexing handlers which can be found in embedded platforms on various architectures.) </para> <para> The separation makes the generic interrupt handling layer more flexible and extensible. For example, an (sub)architecture can - use a generic irq-flow implementation for 'level type' interrupts + use a generic IRQ-flow implementation for 'level type' interrupts and add a (sub)architecture specific 'edge type' implementation. </para> <para> @@ -172,9 +172,9 @@ <para> There are three main levels of abstraction in the interrupt code: <orderedlist> - <listitem><para>Highlevel driver API</para></listitem> - <listitem><para>Highlevel IRQ flow handlers</para></listitem> - <listitem><para>Chiplevel hardware encapsulation</para></listitem> + <listitem><para>High-level driver API</para></listitem> + <listitem><para>High-level IRQ flow handlers</para></listitem> + <listitem><para>Chip-level hardware encapsulation</para></listitem> </orderedlist> </para> <sect1 id="Interrupt_control_flow"> @@ -189,16 +189,16 @@ which are assigned to this interrupt. </para> <para> - Whenever an interrupt triggers, the lowlevel arch code calls into - the generic interrupt code by calling desc->handle_irq(). - This highlevel IRQ handling function only uses desc->irq_data.chip + Whenever an interrupt triggers, the low-level architecture code calls + into the generic interrupt code by calling desc->handle_irq(). + This high-level IRQ handling function only uses desc->irq_data.chip primitives referenced by the assigned chip descriptor structure. </para> </sect1> <sect1 id="Highlevel_Driver_API"> - <title>Highlevel Driver API</title> + <title>High-level Driver API</title> <para> - The highlevel Driver API consists of following functions: + The high-level Driver API consists of following functions: <itemizedlist> <listitem><para>request_irq()</para></listitem> <listitem><para>free_irq()</para></listitem> @@ -216,7 +216,7 @@ </para> </sect1> <sect1 id="Highlevel_IRQ_flow_handlers"> - <title>Highlevel IRQ flow handlers</title> + <title>High-level IRQ flow handlers</title> <para> The generic layer provides a set of pre-defined irq-flow methods: <itemizedlist> @@ -228,7 +228,7 @@ <listitem><para>handle_edge_eoi_irq</para></listitem> <listitem><para>handle_bad_irq</para></listitem> </itemizedlist> - The interrupt flow handlers (either predefined or architecture + The interrupt flow handlers (either pre-defined or architecture specific) are assigned to specific interrupts by the architecture either during bootup or during device initialization. </para> @@ -297,7 +297,7 @@ desc->irq_data.chip->irq_unmask(); <para> handle_fasteoi_irq provides a generic implementation for interrupts, which only need an EOI at the end of - the handler + the handler. </para> <para> The following control flow is implemented (simplified excerpt): @@ -394,7 +394,7 @@ if (desc->irq_data.chip->irq_eoi) The generic functions are intended for 'clean' architectures and chips, which have no platform-specific IRQ handling quirks. If an architecture needs to implement quirks on the 'flow' level then it can do so by - overriding the highlevel irq-flow handler. + overriding the high-level irq-flow handler. </para> </sect2> <sect2 id="Delayed_interrupt_disable"> @@ -419,9 +419,9 @@ if (desc->irq_data.chip->irq_eoi) </sect2> </sect1> <sect1 id="Chiplevel_hardware_encapsulation"> - <title>Chiplevel hardware encapsulation</title> + <title>Chip-level hardware encapsulation</title> <para> - The chip level hardware descriptor structure irq_chip + The chip-level hardware descriptor structure irq_chip contains all the direct chip relevant functions, which can be utilized by the irq flow implementations. <itemizedlist> @@ -429,14 +429,14 @@ if (desc->irq_data.chip->irq_eoi) <listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem> <listitem><para>irq_mask()</para></listitem> <listitem><para>irq_unmask()</para></listitem> - <listitem><para>irq_eoi() - Optional, required for eoi flow handlers</para></listitem> + <listitem><para>irq_eoi() - Optional, required for EOI flow handlers</para></listitem> <listitem><para>irq_retrigger() - Optional</para></listitem> <listitem><para>irq_set_type() - Optional</para></listitem> <listitem><para>irq_set_wake() - Optional</para></listitem> </itemizedlist> These primitives are strictly intended to mean what they say: ack means ACK, masking means masking of an IRQ line, etc. It is up to the flow - handler(s) to use these basic units of lowlevel functionality. + handler(s) to use these basic units of low-level functionality. </para> </sect1> </chapter> @@ -445,7 +445,7 @@ if (desc->irq_data.chip->irq_eoi) <title>__do_IRQ entry point</title> <para> The original implementation __do_IRQ() was an alternative entry - point for all types of interrupts. It not longer exists. + point for all types of interrupts. It no longer exists. </para> <para> This handler turned out to be not suitable for all @@ -468,11 +468,11 @@ if (desc->irq_data.chip->irq_eoi) <chapter id="genericchip"> <title>Generic interrupt chip</title> <para> - To avoid copies of identical implementations of irq chips the + To avoid copies of identical implementations of IRQ chips the core provides a configurable generic interrupt chip implementation. Developers should check carefuly whether the generic chip fits their needs before implementing the same - functionality slightly different themself. + functionality slightly differently themselves. </para> !Ekernel/irq/generic-chip.c </chapter> diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index a248f42a121..cd11926e07c 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -1222,8 +1222,6 @@ in this page</entry> #define NAND_BBT_VERSION 0x00000100 /* Create a bbt if none axists */ #define NAND_BBT_CREATE 0x00000200 -/* Search good / bad pattern through all pages of a block */ -#define NAND_BBT_SCANALLPAGES 0x00000400 /* Write bbt if neccecary */ #define NAND_BBT_WRITE 0x00001000 /* Read and write back block contents when writing bbt */ diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt index bccf602a87f..6f458564d62 100644 --- a/Documentation/PCI/pci.txt +++ b/Documentation/PCI/pci.txt @@ -525,8 +525,9 @@ corresponding register block for you. 6. Other interesting functions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -pci_find_slot() Find pci_dev corresponding to given bus and - slot numbers. +pci_get_domain_bus_and_slot() Find pci_dev corresponding to given domain, + bus and slot and number. If the device is + found, its reference count is increased. pci_set_power_state() Set PCI Power Management state (0=D0 ... 3=D3) pci_find_capability() Find specified capability in device's capability list. @@ -582,7 +583,8 @@ having sane locking. pci_find_device() Superseded by pci_get_device() pci_find_subsys() Superseded by pci_get_subsys() -pci_find_slot() Superseded by pci_get_slot() +pci_find_slot() Superseded by pci_get_domain_bus_and_slot() +pci_get_slot() Superseded by pci_get_domain_bus_and_slot() The alternative is the traditional PCI device driver that walks PCI diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 7703ec73a9b..91266193b8f 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -202,8 +202,8 @@ over a rather long period of time, but improvements are always welcome! updater uses call_rcu_sched() or synchronize_sched(), then the corresponding readers must disable preemption, possibly by calling rcu_read_lock_sched() and rcu_read_unlock_sched(). - If the updater uses synchronize_srcu() or call_srcu(), - the the corresponding readers must use srcu_read_lock() and + If the updater uses synchronize_srcu() or call_srcu(), then + the corresponding readers must use srcu_read_lock() and srcu_read_unlock(), and with the same srcu_struct. The rules for the expedited primitives are the same as for their non-expedited counterparts. Mixing things up will result in confusion and diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt index 8e9359de1d2..6f3a0057548 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.txt @@ -12,12 +12,12 @@ CONFIG_RCU_CPU_STALL_TIMEOUT This kernel configuration parameter defines the period of time that RCU will wait from the beginning of a grace period until it issues an RCU CPU stall warning. This time period is normally - sixty seconds. + 21 seconds. This configuration parameter may be changed at runtime via the /sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however this parameter is checked only at the beginning of a cycle. - So if you are 30 seconds into a 70-second stall, setting this + So if you are 10 seconds into a 40-second stall, setting this sysfs parameter to (say) five will shorten the timeout for the -next- stall, or the following warning for the current stall (assuming the stall lasts long enough). It will not affect the @@ -32,7 +32,7 @@ CONFIG_RCU_CPU_STALL_VERBOSE also dump the stacks of any tasks that are blocking the current RCU-preempt grace period. -RCU_CPU_STALL_INFO +CONFIG_RCU_CPU_STALL_INFO This kernel configuration parameter causes the stall warning to print out additional per-CPU diagnostic information, including @@ -43,7 +43,8 @@ RCU_STALL_DELAY_DELTA Although the lockdep facility is extremely useful, it does add some overhead. Therefore, under CONFIG_PROVE_RCU, the RCU_STALL_DELAY_DELTA macro allows five extra seconds before - giving an RCU CPU stall warning message. + giving an RCU CPU stall warning message. (This is a cpp + macro, not a kernel configuration parameter.) RCU_STALL_RAT_DELAY @@ -52,7 +53,8 @@ RCU_STALL_RAT_DELAY However, if the offending CPU does not detect its own stall in the number of jiffies specified by RCU_STALL_RAT_DELAY, then some other CPU will complain. This delay is normally set to - two jiffies. + two jiffies. (This is a cpp macro, not a kernel configuration + parameter.) When a CPU detects that it is stalling, it will print a message similar to the following: @@ -86,7 +88,12 @@ printing, there will be a spurious stall-warning message: INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffies) -This is rare, but does happen from time to time in real life. +This is rare, but does happen from time to time in real life. It is also +possible for a zero-jiffy stall to be flagged in this case, depending +on how the stall warning and the grace-period initialization happen to +interact. Please note that it is not possible to entirely eliminate this +sort of false positive without resorting to things like stop_machine(), +which is overkill for this sort of problem. If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set, more information is printed with the stall-warning message, for example: @@ -216,4 +223,5 @@ that portion of the stack which remains the same from trace to trace. If you can reliably trigger the stall, ftrace can be quite helpful. RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE -and with RCU's event tracing. +and with RCU's event tracing. For information on RCU's event tracing, +see include/trace/events/rcu.h. diff --git a/Documentation/acpi/dsdt-override.txt b/Documentation/acpi/dsdt-override.txt index febbb1ba4d2..784841caa6e 100644 --- a/Documentation/acpi/dsdt-override.txt +++ b/Documentation/acpi/dsdt-override.txt @@ -4,4 +4,4 @@ CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel. When to use this method is described in detail on the Linux/ACPI home page: -http://www.lesswatts.org/projects/acpi/overridingDSDT.php +https://01.org/linux-acpi/documentation/overriding-dsdt diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index aca4e69121b..b994bcb32b9 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -295,10 +295,6 @@ These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0" specifies the path to the controller. In order to use these GPIOs in Linux we need to translate them to the Linux GPIO numbers. -The driver can do this by including <linux/acpi_gpio.h> and then calling -acpi_get_gpio(path, gpio). This will return the Linux GPIO number or -negative errno if there was no translation found. - In a simple case of just getting the Linux GPIO number from device resources one can use acpi_get_gpio_by_index() helper function. It takes pointer to the device and index of the GpioIo/GpioInt descriptor in the @@ -322,3 +318,25 @@ suitable to the gpiolib before passing them. In case of GpioInt resource an additional call to gpio_to_irq() must be done before calling request_irq(). + +Note that the above API is ACPI specific and not recommended for drivers +that need to support non-ACPI systems. The recommended way is to use +the descriptor based GPIO interfaces. The above example looks like this +when converted to the GPIO desc: + + #include <linux/gpio/consumer.h> + ... + + struct gpio_desc *irq_desc, *power_desc; + + irq_desc = gpiod_get_index(dev, NULL, 1); + if (IS_ERR(irq_desc)) + /* handle error */ + + power_desc = gpiod_get_index(dev, NULL, 0); + if (IS_ERR(power_desc)) + /* handle error */ + + /* Now we can use the GPIO descriptors */ + +See also Documentation/gpio.txt. diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README index 8f08a86e03b..da0151db996 100644 --- a/Documentation/arm/Marvell/README +++ b/Documentation/arm/Marvell/README @@ -88,6 +88,7 @@ EBU Armada family MV78230 MV78260 MV78460 + NOTE: not to be confused with the non-SMP 78xx0 SoCs Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf No public datasheet available. diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README index e3f93fb9224..7945238453e 100644 --- a/Documentation/arm/sunxi/README +++ b/Documentation/arm/sunxi/README @@ -10,6 +10,10 @@ SunXi family Linux kernel mach directory: arch/arm/mach-sunxi Flavors: + * ARM926 based SoCs + - Allwinner F20 (sun3i) + + Not Supported + * ARM Cortex-A8 based SoCs - Allwinner A10 (sun4i) + Datasheet @@ -25,4 +29,24 @@ SunXi family + Datasheet http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf + User Manual - http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-08-08%29.pdf + http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-01-08%29.pdf + + * Dual ARM Cortex-A7 based SoCs + - Allwinner A20 (sun7i) + + User Manual + http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf + + - Allwinner A23 + + Not Supported + + * Quad ARM Cortex-A7 based SoCs + - Allwinner A31 (sun6i) + + Datasheet + http://dl.linux-sunxi.org/A31/A31%20Datasheet%20-%20v1.00%20(2012-12-24).pdf + + - Allwinner A31s (sun6i) + + Not Supported + + * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs + - Allwinner A80 + + Not Supported
\ No newline at end of file diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index 98df4a03807..a9691cc48fe 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -115,9 +115,10 @@ Before jumping into the kernel, the following conditions must be met: External caches (if present) must be configured and disabled. - Architected timers - CNTFRQ must be programmed with the timer frequency. - If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) - set where available. + CNTFRQ must be programmed with the timer frequency and CNTVOFF must + be programmed with a consistent value on all CPUs. If entering the + kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where + available. - Coherency All CPUs to be booted by the kernel must be part of the same coherency @@ -130,30 +131,46 @@ Before jumping into the kernel, the following conditions must be met: the kernel image will be entered must be initialised by software at a higher exception level to prevent execution in an UNKNOWN state. +The requirements described above for CPU mode, caches, MMUs, architected +timers, coherency and system registers apply to all CPUs. All CPUs must +enter the kernel in the same exception level. + The boot loader is expected to enter the kernel on each CPU in the following manner: - The primary CPU must jump directly to the first instruction of the kernel image. The device tree blob passed by this CPU must contain - for each CPU node: - - 1. An 'enable-method' property. Currently, the only supported value - for this field is the string "spin-table". - - 2. A 'cpu-release-addr' property identifying a 64-bit, - zero-initialised memory location. + an 'enable-method' property for each cpu node. The supported + enable-methods are described below. It is expected that the bootloader will generate these device tree properties and insert them into the blob prior to kernel entry. -- Any secondary CPUs must spin outside of the kernel in a reserved area - of memory (communicated to the kernel by a /memreserve/ region in the +- CPUs with a "spin-table" enable-method must have a 'cpu-release-addr' + property in their cpu node. This property identifies a + naturally-aligned 64-bit zero-initalised memory location. + + These CPUs should spin outside of the kernel in a reserved area of + memory (communicated to the kernel by a /memreserve/ region in the device tree) polling their cpu-release-addr location, which must be contained in the reserved region. A wfe instruction may be inserted to reduce the overhead of the busy-loop and a sev will be issued by the primary CPU. When a read of the location pointed to by the - cpu-release-addr returns a non-zero value, the CPU must jump directly - to this value. + cpu-release-addr returns a non-zero value, the CPU must jump to this + value. The value will be written as a single 64-bit little-endian + value, so CPUs must convert the read value to their native endianness + before jumping to it. + +- CPUs with a "psci" enable method should remain outside of + the kernel (i.e. outside of the regions of memory described to the + kernel in the memory node, or in a reserved area of memory described + to the kernel by a /memreserve/ region in the device tree). The + kernel will issue CPU_ON calls as described in ARM document number ARM + DEN 0022A ("Power State Coordination Interface System Software on ARM + processors") to bring CPUs into the kernel. + + The device tree should contain a 'psci' node, as described in + Documentation/devicetree/bindings/arm/psci.txt. - Secondary CPU general-purpose register settings x0 = 0 (reserved for future use) diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt index 78a377124ef..5e054bfe4dd 100644 --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -21,7 +21,7 @@ The swapper_pgd_dir address is written to TTBR1 and never written to TTBR0. -AArch64 Linux memory layout: +AArch64 Linux memory layout with 4KB pages: Start End Size Use ----------------------------------------------------------------------- @@ -39,13 +39,38 @@ ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space -ffffffbbffff0000 ffffffbcffffffff ~2MB [guard] +ffffffbffbe10000 ffffffbcffffffff ~2MB [guard] ffffffbffc000000 ffffffbfffffffff 64MB modules ffffffc000000000 ffffffffffffffff 256GB kernel logical memory map +AArch64 Linux memory layout with 64KB pages: + +Start End Size Use +----------------------------------------------------------------------- +0000000000000000 000003ffffffffff 4TB user + +fffffc0000000000 fffffdfbfffeffff ~2TB vmalloc + +fffffdfbffff0000 fffffdfbffffffff 64KB [guard page] + +fffffdfc00000000 fffffdfdffffffff 8GB vmemmap + +fffffdfe00000000 fffffdfffbbfffff ~8GB [guard, future vmmemap] + +fffffdfffbc00000 fffffdfffbdfffff 2MB earlyprintk device + +fffffdfffbe00000 fffffdfffbe0ffff 64KB PCI I/O space + +fffffdfffbe10000 fffffdfffbffffff ~2MB [guard] + +fffffdfffc000000 fffffdffffffffff 64MB modules + +fffffe0000000000 ffffffffffffffff 2TB kernel logical memory map + + Translation table lookup with 4KB pages: +--------+--------+--------+--------+--------+--------+--------+--------+ diff --git a/Documentation/backlight/lp855x-driver.txt b/Documentation/backlight/lp855x-driver.txt index 1c732f0c675..01bce243d3d 100644 --- a/Documentation/backlight/lp855x-driver.txt +++ b/Documentation/backlight/lp855x-driver.txt @@ -4,7 +4,8 @@ Kernel driver lp855x Backlight driver for LP855x ICs Supported chips: - Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557 + Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and + LP8557 Author: Milo(Woogyom) Kim <milo.kim@ti.com> @@ -24,7 +25,7 @@ Value : pwm based or register based 2) chip_id The lp855x chip id. -Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557 +Value : lp8550/lp8551/lp8552/lp8553/lp8555/lp8556/lp8557 Platform data for lp855x ------------------------ diff --git a/Documentation/blockdev/floppy.txt b/Documentation/blockdev/floppy.txt index 470fe4b5e37..e2240f5ab64 100644 --- a/Documentation/blockdev/floppy.txt +++ b/Documentation/blockdev/floppy.txt @@ -39,15 +39,15 @@ Module configuration options ============================ If you use the floppy driver as a module, use the following syntax: -modprobe floppy <options> +modprobe floppy floppy="<options>" Example: - modprobe floppy omnibook messages + modprobe floppy floppy="omnibook messages" If you need certain options enabled every time you load the floppy driver, you can put: - options floppy omnibook messages + options floppy floppy="omnibook messages" in a configuration file in /etc/modprobe.d/. diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 8af4ad12182..e2bc132608f 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -573,15 +573,19 @@ an memcg since the pages are allowed to be allocated from any physical node. One of the use cases is evaluating application performance by combining this information with the application's CPU allocation. -We export "total", "file", "anon" and "unevictable" pages per-node for -each memcg. The ouput format of memory.numa_stat is: +Each memcg's numa_stat file includes "total", "file", "anon" and "unevictable" +per-node page counts including "hierarchical_<counter>" which sums up all +hierarchical children's values in addition to the memcg's own value. + +The ouput format of memory.numa_stat is: total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ... file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ... anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ... unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ... +hierarchical_<counter>=<counter pages> N0=<node 0 pages> N1=<node 1 pages> ... -And we have total = file + anon + unevictable. +The "total" count is sum of file + anon + unevictable. 6. Hierarchy support diff --git a/Documentation/connector/ucon.c b/Documentation/connector/ucon.c index 4848db8c71f..8a4da64e02a 100644 --- a/Documentation/connector/ucon.c +++ b/Documentation/connector/ucon.c @@ -71,7 +71,7 @@ static int netlink_send(int s, struct cn_msg *msg) nlh->nlmsg_seq = seq++; nlh->nlmsg_pid = getpid(); nlh->nlmsg_type = NLMSG_DONE; - nlh->nlmsg_len = NLMSG_LENGTH(size - sizeof(*nlh)); + nlh->nlmsg_len = size; nlh->nlmsg_flags = 0; m = NLMSG_DATA(nlh); diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index 40282e61791..8b1a4451422 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -23,8 +23,8 @@ Contents: 1.1 Initialization 1.2 Per-CPU Initialization 1.3 verify -1.4 target or setpolicy? -1.5 target +1.4 target/target_index or setpolicy? +1.5 target/target_index 1.6 setpolicy 2. Frequency Table Helpers @@ -56,7 +56,8 @@ cpufreq_driver.init - A pointer to the per-CPU initialization cpufreq_driver.verify - A pointer to a "verification" function. cpufreq_driver.setpolicy _or_ -cpufreq_driver.target - See below on the differences. +cpufreq_driver.target/ +target_index - See below on the differences. And optionally @@ -66,7 +67,7 @@ cpufreq_driver.resume - A pointer to a per-CPU resume function which is called with interrupts disabled and _before_ the pre-suspend frequency and/or policy is restored by a call to - ->target or ->setpolicy. + ->target/target_index or ->setpolicy. cpufreq_driver.attr - A pointer to a NULL-terminated list of "struct freq_attr" which allow to @@ -103,8 +104,8 @@ policy->governor must contain the "default policy" for this CPU. A few moments later, cpufreq_driver.verify and either cpufreq_driver.setpolicy or - cpufreq_driver.target is called with - these values. + cpufreq_driver.target/target_index is called + with these values. For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the frequency table helpers might be helpful. See the section 2 for more information @@ -133,20 +134,28 @@ range) is within policy->min and policy->max. If necessary, increase policy->max first, and only if this is no solution, decrease policy->min. -1.4 target or setpolicy? +1.4 target/target_index or setpolicy? ---------------------------- Most cpufreq drivers or even most cpu frequency scaling algorithms only allow the CPU to be set to one frequency. For these, you use the -->target call. +->target/target_index call. Some cpufreq-capable processors switch the frequency between certain limits on their own. These shall use the ->setpolicy call -1.4. target +1.4. target/target_index ------------- +The target_index call has two arguments: struct cpufreq_policy *policy, +and unsigned int index (into the exposed frequency table). + +The CPUfreq driver must set the new frequency when called here. The +actual frequency must be determined by freq_table[index].frequency. + +Deprecated: +---------- The target call has three arguments: struct cpufreq_policy *policy, unsigned int target_frequency, unsigned int relation. diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index 219970ba54b..77ec21574fb 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt @@ -40,7 +40,7 @@ Most cpufreq drivers (in fact, all except one, longrun) or even most cpu frequency scaling algorithms only offer the CPU to be set to one frequency. In order to offer dynamic frequency scaling, the cpufreq core must be able to tell these drivers of a "target frequency". So -these specific drivers will be transformed to offer a "->target" +these specific drivers will be transformed to offer a "->target/target_index" call instead of the existing "->setpolicy" call. For "longrun", all stays the same, though. @@ -71,7 +71,7 @@ CPU can be set to switch independently | CPU can only be set / the limits of policy->{min,max} / \ / \ - Using the ->setpolicy call, Using the ->target call, + Using the ->setpolicy call, Using the ->target/target_index call, the limits and the the frequency closest "policy" is set. to target_freq is set. It is assured that it diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index 786dc82f98c..8cb9938cc47 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -5,7 +5,7 @@ Rusty Russell <rusty@rustcorp.com.au> Srivatsa Vaddagiri <vatsa@in.ibm.com> i386: - Zwane Mwaikambo <zwane@arm.linux.org.uk> + Zwane Mwaikambo <zwanem@gmail.com> ppc64: Nathan Lynch <nathanl@austin.ibm.com> Joel Schopp <jschopp@austin.ibm.com> diff --git a/Documentation/device-mapper/cache-policies.txt b/Documentation/device-mapper/cache-policies.txt index d7c440b444c..df52a849957 100644 --- a/Documentation/device-mapper/cache-policies.txt +++ b/Documentation/device-mapper/cache-policies.txt @@ -30,8 +30,10 @@ multiqueue This policy is the default. -The multiqueue policy has two sets of 16 queues: one set for entries -waiting for the cache and another one for those in the cache. +The multiqueue policy has three sets of 16 queues: one set for entries +waiting for the cache and another two for those in the cache (a set for +clean entries and a set for dirty entries). + Cache entries in the queues are aged based on logical time. Entry into the cache is based on variable thresholds and queue selection is based on hit count on entry. The policy aims to take different cache miss diff --git a/Documentation/device-mapper/cache.txt b/Documentation/device-mapper/cache.txt index 33d45ee0b73..274752f8bdf 100644 --- a/Documentation/device-mapper/cache.txt +++ b/Documentation/device-mapper/cache.txt @@ -68,10 +68,11 @@ So large block sizes are bad because they waste cache space. And small block sizes are bad because they increase the amount of metadata (both in core and on disk). -Writeback/writethrough ----------------------- +Cache operating modes +--------------------- -The cache has two modes, writeback and writethrough. +The cache has three operating modes: writeback, writethrough and +passthrough. If writeback, the default, is selected then a write to a block that is cached will go only to the cache and the block will be marked dirty in @@ -81,8 +82,31 @@ If writethrough is selected then a write to a cached block will not complete until it has hit both the origin and cache devices. Clean blocks should remain clean. +If passthrough is selected, useful when the cache contents are not known +to be coherent with the origin device, then all reads are served from +the origin device (all reads miss the cache) and all writes are +forwarded to the origin device; additionally, write hits cause cache +block invalidates. To enable passthrough mode the cache must be clean. +Passthrough mode allows a cache device to be activated without having to +worry about coherency. Coherency that exists is maintained, although +the cache will gradually cool as writes take place. If the coherency of +the cache can later be verified, or established through use of the +"invalidate_cblocks" message, the cache device can be transitioned to +writethrough or writeback mode while still warm. Otherwise, the cache +contents can be discarded prior to transitioning to the desired +operating mode. + A simple cleaner policy is provided, which will clean (write back) all -dirty blocks in a cache. Useful for decommissioning a cache. +dirty blocks in a cache. Useful for decommissioning a cache or when +shrinking a cache. Shrinking the cache's fast device requires all cache +blocks, in the area of the cache being removed, to be clean. If the +area being removed from the cache still contains dirty blocks the resize +will fail. Care must be taken to never reduce the volume used for the +cache's fast device until the cache is clean. This is of particular +importance if writeback mode is used. Writethrough and passthrough +modes already maintain a clean cache. Future support to partially clean +the cache, above a specified threshold, will allow for keeping the cache +warm and in writeback mode during resize. Migration throttling -------------------- @@ -161,7 +185,7 @@ Constructor block size : cache unit size in sectors #feature args : number of feature arguments passed - feature args : writethrough. (The default is writeback.) + feature args : writethrough or passthrough (The default is writeback.) policy : the replacement policy to use #policy args : an even number of arguments corresponding to @@ -177,6 +201,13 @@ Optional feature arguments are: back cache block contents later for performance reasons, so they may differ from the corresponding origin blocks. + passthrough : a degraded mode useful for various cache coherency + situations (e.g., rolling back snapshots of + underlying storage). Reads and writes always go to + the origin. If a write goes to a cached origin + block, then the cache block is invalidated. + To enable passthrough mode the cache must be clean. + A policy called 'default' is always registered. This is an alias for the policy we currently think is giving best all round performance. @@ -231,12 +262,26 @@ The message format is: E.g. dmsetup message my_cache 0 sequential_threshold 1024 + +Invalidation is removing an entry from the cache without writing it +back. Cache blocks can be invalidated via the invalidate_cblocks +message, which takes an arbitrary number of cblock ranges. Each cblock +must be expressed as a decimal value, in the future a variant message +that takes cblock ranges expressed in hexidecimal may be needed to +better support efficient invalidation of larger caches. The cache must +be in passthrough mode when invalidate_cblocks is used. + + invalidate_cblocks [<cblock>|<cblock begin>-<cblock end>]* + +E.g. + dmsetup message my_cache 0 invalidate_cblocks 2345 3456-4567 5678-6789 + Examples ======== The test suite can be found here: -https://github.com/jthornber/thinp-test-suite +https://github.com/jthornber/device-mapper-test-suite dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \ /dev/mapper/ssd /dev/mapper/origin 512 1 writeback default 0' diff --git a/Documentation/device-mapper/dm-crypt.txt b/Documentation/device-mapper/dm-crypt.txt index 2c656ae43ba..c81839b52c4 100644 --- a/Documentation/device-mapper/dm-crypt.txt +++ b/Documentation/device-mapper/dm-crypt.txt @@ -4,12 +4,15 @@ dm-crypt Device-Mapper's "crypt" target provides transparent encryption of block devices using the kernel crypto API. +For a more detailed description of supported parameters see: +http://code.google.com/p/cryptsetup/wiki/DMCrypt + Parameters: <cipher> <key> <iv_offset> <device path> \ <offset> [<#opt_params> <opt_params>] <cipher> Encryption cipher and an optional IV generation mode. - (In format cipher[:keycount]-chainmode-ivopts:ivmode). + (In format cipher[:keycount]-chainmode-ivmode[:ivopts]). Examples: des aes-cbc-essiv:sha256 @@ -19,7 +22,11 @@ Parameters: <cipher> <key> <iv_offset> <device path> \ <key> Key used for encryption. It is encoded as a hexadecimal number. - You can only use key sizes that are valid for the selected cipher. + You can only use key sizes that are valid for the selected cipher + in combination with the selected iv mode. + Note that for some iv modes the key string can contain additional + keys (for example IV seed) so the key contains more parts concatenated + into a single string. <keycount> Multi-key compatibility mode. You can define <keycount> keys and diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 23721d3be3e..80b72419ffd 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -414,6 +414,7 @@ Your cooperation is appreciated. 200 = /dev/net/tun TAP/TUN network device 201 = /dev/button/gulpb Transmeta GULP-B buttons 202 = /dev/emd/ctl Enhanced Metadisk RAID (EMD) control + 203 = /dev/cuse Cuse (character device in user-space) 204 = /dev/video/em8300 EM8300 DVD decoder control 205 = /dev/video/em8300_mv EM8300 DVD decoder video 206 = /dev/video/em8300_ma EM8300 DVD decoder audio diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards index db5858e32d3..5fac246a953 100644 --- a/Documentation/devicetree/bindings/arm/arm-boards +++ b/Documentation/devicetree/bindings/arm/arm-boards @@ -9,9 +9,53 @@ Required properties (in root node): FPGA type interrupt controllers, see the versatile-fpga-irq binding doc. -In the root node the Integrator/CP must have a /cpcon node pointing -to the CP control registers, and the Integrator/AP must have a -/syscon node pointing to the Integrator/AP system controller. +Required nodes: + +- core-module: the root node to the Integrator platforms must have + a core-module with regs and the compatible string + "arm,core-module-integrator" + + Required properties for the core module: + - regs: the location and size of the core module registers, one + range of 0x200 bytes. + +- syscon: the root node of the Integrator platforms must have a + system controller node pointong to the control registers, + with the compatible string + "arm,integrator-ap-syscon" + "arm,integrator-cp-syscon" + respectively. + + Required properties for the system controller: + - regs: the location and size of the system controller registers, + one range of 0x100 bytes. + + Required properties for the AP system controller: + - interrupts: the AP syscon node must include the logical module + interrupts, stated in order of module instance <module 0>, + <module 1>, <module 2> ... for the CP system controller this + is not required not of any use. + +/dts-v1/; +/include/ "integrator.dtsi" + +/ { + model = "ARM Integrator/AP"; + compatible = "arm,integrator-ap"; + + core-module@10000000 { + compatible = "arm,core-module-integrator"; + reg = <0x10000000 0x200>; + }; + + syscon { + compatible = "arm,integrator-ap-syscon"; + reg = <0x11000000 0x100>; + interrupt-parent = <&pic>; + /* These are the logic module IRQs */ + interrupts = <9>, <10>, <11>, <12>; + }; +}; ARM Versatile Application and Platform Baseboards diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt index 61df564c0d2..d74091a8a3b 100644 --- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt +++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt @@ -4,6 +4,8 @@ Marvell Armada 370 and Armada XP Interrupt Controller Required properties: - compatible: Should be "marvell,mpic" - interrupt-controller: Identifies the node as an interrupt controller. +- msi-controller: Identifies the node as an PCI Message Signaled + Interrupt controller. - #interrupt-cells: The number of cells to define the interrupts. Should be 1. The cell is the IRQ number @@ -24,6 +26,7 @@ Example: #address-cells = <1>; #size-cells = <1>; interrupt-controller; + msi-controller; reg = <0xd0020a00 0x1d0>, <0xd0021070 0x58>; }; diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt index 723c205cb10..d1061469f63 100644 --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt +++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt @@ -7,7 +7,6 @@ Required properties: - interrupts: Should contain the IRQ line for the ADC - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this device - - 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-vref: Reference voltage in millivolts for the conversions @@ -24,6 +23,13 @@ Optional properties: resolution will be used. - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds + - atmel,adc-ts-wires: Number of touch screen wires. Should be 4 or 5. If this + value is set, then adc driver will enable touch screen + support. + NOTE: when adc touch screen enabled, the adc hardware trigger will be + disabled. Since touch screen will occupied the trigger register. + - atmel,adc-ts-pressure-threshold: a pressure threshold for touchscreen. It + make touch detect more precision. Optional trigger Nodes: - Required properties: diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt index 92d36e2aa87..f28d82bbbc5 100644 --- a/Documentation/devicetree/bindings/arm/cci.txt +++ b/Documentation/devicetree/bindings/arm/cci.txt @@ -36,14 +36,18 @@ specific to ARM. - reg Usage: required - Value type: <prop-encoded-array> + Value type: Integer cells. A register entry, expressed as a pair + of cells, containing base and size. Definition: A standard property. Specifies base physical address of CCI control registers common to all interfaces. - ranges: Usage: required - Value type: <prop-encoded-array> + Value type: Integer cells. An array of range entries, expressed + as a tuple of cells, containing child address, + parent address and the size of the region in the + child address space. Definition: A standard property. Follow rules in the ePAPR for hierarchical bus addressing. CCI interfaces addresses refer to the parent node addressing @@ -74,11 +78,49 @@ specific to ARM. - reg: Usage: required - Value type: <prop-encoded-array> + Value type: Integer cells. A register entry, expressed + as a pair of cells, containing base and + size. Definition: the base address and size of the corresponding interface programming registers. + - CCI PMU node + + Parent node must be CCI interconnect node. + + A CCI pmu node must contain the following properties: + + - compatible + Usage: required + Value type: <string> + Definition: must be "arm,cci-400-pmu" + + - reg: + Usage: required + Value type: Integer cells. A register entry, expressed + as a pair of cells, containing base and + size. + Definition: the base address and size of the + corresponding interface programming + registers. + + - interrupts: + Usage: required + Value type: Integer cells. Array of interrupt specifier + entries, as defined in + ../interrupt-controller/interrupts.txt. + Definition: list of counter overflow interrupts, one per + counter. The interrupts must be specified + starting with the cycle counter overflow + interrupt, followed by counter0 overflow + interrupt, counter1 overflow interrupt,... + ,counterN overflow interrupt. + + The CCI PMU has an interrupt signal for each + counter. The number of interrupts must be + equal to the number of counters. + * CCI interconnect bus masters Description: masters in the device tree connected to a CCI port @@ -144,7 +186,7 @@ Example: #address-cells = <1>; #size-cells = <1>; reg = <0x0 0x2c090000 0 0x1000>; - ranges = <0x0 0x0 0x2c090000 0x6000>; + ranges = <0x0 0x0 0x2c090000 0x10000>; cci_control0: slave-if@1000 { compatible = "arm,cci-400-ctrl-if"; @@ -163,6 +205,16 @@ Example: interface-type = "ace"; reg = <0x5000 0x1000>; }; + + pmu@9000 { + compatible = "arm,cci-400-pmu"; + reg = <0x9000 0x5000>; + interrupts = <0 101 4>, + <0 102 4>, + <0 103 4>, + <0 104 4>, + <0 105 4>; + }; }; This CCI node corresponds to a CCI component whose control registers sits diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index f32494dbfe1..91304353eea 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -1,77 +1,384 @@ -* ARM CPUs binding description +================= +ARM CPUs bindings +================= The device tree allows to describe the layout of CPUs in a system through the "cpus" node, which in turn contains a number of subnodes (ie "cpu") defining properties for every cpu. -Bindings for CPU nodes follow the ePAPR standard, available from: - -http://devicetree.org - -For the ARM architecture every CPU node must contain the following properties: - -- device_type: must be "cpu" -- reg: property matching the CPU MPIDR[23:0] register bits - reg[31:24] bits must be set to 0 -- compatible: should be one of: - "arm,arm1020" - "arm,arm1020e" - "arm,arm1022" - "arm,arm1026" - "arm,arm720" - "arm,arm740" - "arm,arm7tdmi" - "arm,arm920" - "arm,arm922" - "arm,arm925" - "arm,arm926" - "arm,arm940" - "arm,arm946" - "arm,arm9tdmi" - "arm,cortex-a5" - "arm,cortex-a7" - "arm,cortex-a8" - "arm,cortex-a9" - "arm,cortex-a15" - "arm,arm1136" - "arm,arm1156" - "arm,arm1176" - "arm,arm11mpcore" - "faraday,fa526" - "intel,sa110" - "intel,sa1100" - "marvell,feroceon" - "marvell,mohawk" - "marvell,xsc3" - "marvell,xscale" - -Example: +Bindings for CPU nodes follow the ePAPR v1.1 standard, available from: + +https://www.power.org/documentation/epapr-version-1-1/ + +with updates for 32-bit and 64-bit ARM systems provided in this document. + +================================ +Convention used in this document +================================ + +This document follows the conventions described in the ePAPR v1.1, with +the addition: + +- square brackets define bitfields, eg reg[7:0] value of the bitfield in + the reg property contained in bits 7 down to 0 + +===================================== +cpus and cpu node bindings definition +===================================== + +The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu +nodes to be present and contain the properties described below. + +- cpus node + + Description: Container of cpu nodes + + The node name must be "cpus". + + A cpus node must define the following properties: + + - #address-cells + Usage: required + Value type: <u32> + + Definition depends on ARM architecture version and + configuration: + + # On uniprocessor ARM architectures previous to v7 + value must be 1, to enable a simple enumeration + scheme for processors that do not have a HW CPU + identification register. + # On 32-bit ARM 11 MPcore, ARM v7 or later systems + value must be 1, that corresponds to CPUID/MPIDR + registers sizes. + # On ARM v8 64-bit systems value should be set to 2, + that corresponds to the MPIDR_EL1 register size. + If MPIDR_EL1[63:32] value is equal to 0 on all CPUs + in the system, #address-cells can be set to 1, since + MPIDR_EL1[63:32] bits are not used for CPUs + identification. + - #size-cells + Usage: required + Value type: <u32> + Definition: must be set to 0 + +- cpu node + + Description: Describes a CPU in an ARM based system + + PROPERTIES + + - device_type + Usage: required + Value type: <string> + Definition: must be "cpu" + - reg + Usage and definition depend on ARM architecture version and + configuration: + + # On uniprocessor ARM architectures previous to v7 + this property is required and must be set to 0. + + # On ARM 11 MPcore based systems this property is + required and matches the CPUID[11:0] register bits. + + Bits [11:0] in the reg cell must be set to + bits [11:0] in CPU ID register. + + All other bits in the reg cell must be set to 0. + + # On 32-bit ARM v7 or later systems this property is + required and matches the CPU MPIDR[23:0] register + bits. + + Bits [23:0] in the reg cell must be set to + bits [23:0] in MPIDR. + + All other bits in the reg cell must be set to 0. + + # On ARM v8 64-bit systems this property is required + and matches the MPIDR_EL1 register affinity bits. + + * If cpus node's #address-cells property is set to 2 + + The first reg cell bits [7:0] must be set to + bits [39:32] of MPIDR_EL1. + + The second reg cell bits [23:0] must be set to + bits [23:0] of MPIDR_EL1. + + * If cpus node's #address-cells property is set to 1 + + The reg cell bits [23:0] must be set to bits [23:0] + of MPIDR_EL1. + + All other bits in the reg cells must be set to 0. + + - compatible: + Usage: required + Value type: <string> + Definition: should be one of: + "arm,arm710t" + "arm,arm720t" + "arm,arm740t" + "arm,arm7ej-s" + "arm,arm7tdmi" + "arm,arm7tdmi-s" + "arm,arm9es" + "arm,arm9ej-s" + "arm,arm920t" + "arm,arm922t" + "arm,arm925" + "arm,arm926e-s" + "arm,arm926ej-s" + "arm,arm940t" + "arm,arm946e-s" + "arm,arm966e-s" + "arm,arm968e-s" + "arm,arm9tdmi" + "arm,arm1020e" + "arm,arm1020t" + "arm,arm1022e" + "arm,arm1026ej-s" + "arm,arm1136j-s" + "arm,arm1136jf-s" + "arm,arm1156t2-s" + "arm,arm1156t2f-s" + "arm,arm1176jzf" + "arm,arm1176jz-s" + "arm,arm1176jzf-s" + "arm,arm11mpcore" + "arm,cortex-a5" + "arm,cortex-a7" + "arm,cortex-a8" + "arm,cortex-a9" + "arm,cortex-a15" + "arm,cortex-a53" + "arm,cortex-a57" + "arm,cortex-m0" + "arm,cortex-m0+" + "arm,cortex-m1" + "arm,cortex-m3" + "arm,cortex-m4" + "arm,cortex-r4" + "arm,cortex-r5" + "arm,cortex-r7" + "faraday,fa526" + "intel,sa110" + "intel,sa1100" + "marvell,feroceon" + "marvell,mohawk" + "marvell,pj4a" + "marvell,pj4b" + "marvell,sheeva-v5" + "qcom,krait" + "qcom,scorpion" + - enable-method + Value type: <stringlist> + Usage and definition depend on ARM architecture version. + # On ARM v8 64-bit this property is required and must + be one of: + "spin-table" + "psci" + # On ARM 32-bit systems this property is optional. + + - cpu-release-addr + Usage: required for systems that have an "enable-method" + property value of "spin-table". + Value type: <prop-encoded-array> + Definition: + # On ARM v8 64-bit systems must be a two cell + property identifying a 64-bit zero-initialised + memory location. + +Example 1 (dual-cluster big.LITTLE system 32-bit): cpus { #size-cells = <0>; #address-cells = <1>; - CPU0: cpu@0 { + cpu@0 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; }; - CPU1: cpu@1 { + cpu@1 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x1>; }; - CPU2: cpu@100 { + cpu@100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; }; - CPU3: cpu@101 { + cpu@101 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x101>; }; }; + +Example 2 (Cortex-A8 uniprocessor 32-bit system): + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a8"; + reg = <0x0>; + }; + }; + +Example 3 (ARM 926EJ-S uniprocessor 32-bit system): + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,arm926ej-s"; + reg = <0x0>; + }; + }; + +Example 4 (ARM Cortex-A57 64-bit system): + +cpus { + #size-cells = <0>; + #address-cells = <2>; + + cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x0>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x1>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@10000 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10000>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@10001 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10001>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@10100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@10101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@100000000 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x0>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@100000001 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x1>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@100000100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@100000101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@100010000 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10000>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@100010001 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10001>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@100010100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + cpu@100010101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; +}; diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index 91b7049affa..808c1543b0f 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -21,7 +21,8 @@ Required properties: Optional properties: - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module during suspend. - +- ti,no-reset-on-init: When present, the module should not be reset at init +- ti,no-idle-on-init: When present, the module should not be idled at init Example: diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt new file mode 100644 index 00000000000..4aa20e7a424 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/topology.txt @@ -0,0 +1,474 @@ +=========================================== +ARM topology binding description +=========================================== + +=========================================== +1 - Introduction +=========================================== + +In an ARM system, the hierarchy of CPUs is defined through three entities that +are used to describe the layout of physical CPUs in the system: + +- cluster +- core +- thread + +The cpu nodes (bindings defined in [1]) represent the devices that +correspond to physical CPUs and are to be mapped to the hierarchy levels. + +The bottom hierarchy level sits at core or thread level depending on whether +symmetric multi-threading (SMT) is supported or not. + +For instance in a system where CPUs support SMT, "cpu" nodes represent all +threads existing in the system and map to the hierarchy level "thread" above. +In systems where SMT is not supported "cpu" nodes represent all cores present +in the system and map to the hierarchy level "core" above. + +ARM topology bindings allow one to associate cpu nodes with hierarchical groups +corresponding to the system hierarchy; syntactically they are defined as device +tree nodes. + +The remainder of this document provides the topology bindings for ARM, based +on the ePAPR standard, available from: + +http://www.power.org/documentation/epapr-version-1-1/ + +If not stated otherwise, whenever a reference to a cpu node phandle is made its +value must point to a cpu node compliant with the cpu node bindings as +documented in [1]. +A topology description containing phandles to cpu nodes that are not compliant +with bindings standardized in [1] is therefore considered invalid. + +=========================================== +2 - cpu-map node +=========================================== + +The ARM CPU topology is defined within the cpu-map node, which is a direct +child of the cpus node and provides a container where the actual topology +nodes are listed. + +- cpu-map node + + Usage: Optional - On ARM SMP systems provide CPUs topology to the OS. + ARM uniprocessor systems do not require a topology + description and therefore should not define a + cpu-map node. + + Description: The cpu-map node is just a container node where its + subnodes describe the CPU topology. + + Node name must be "cpu-map". + + The cpu-map node's parent node must be the cpus node. + + The cpu-map node's child nodes can be: + + - one or more cluster nodes + + Any other configuration is considered invalid. + +The cpu-map node can only contain three types of child nodes: + +- cluster node +- core node +- thread node + +whose bindings are described in paragraph 3. + +The nodes describing the CPU topology (cluster/core/thread) can only be +defined within the cpu-map node. +Any other configuration is consider invalid and therefore must be ignored. + +=========================================== +2.1 - cpu-map child nodes naming convention +=========================================== + +cpu-map child nodes must follow a naming convention where the node name +must be "clusterN", "coreN", "threadN" depending on the node type (ie +cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which +are siblings within a single common parent node must be given a unique and +sequential N value, starting from 0). +cpu-map child nodes which do not share a common parent node can have the same +name (ie same number N as other cpu-map child nodes at different device tree +levels) since name uniqueness will be guaranteed by the device tree hierarchy. + +=========================================== +3 - cluster/core/thread node bindings +=========================================== + +Bindings for cluster/cpu/thread nodes are defined as follows: + +- cluster node + + Description: must be declared within a cpu-map node, one node + per cluster. A system can contain several layers of + clustering and cluster nodes can be contained in parent + cluster nodes. + + The cluster node name must be "clusterN" as described in 2.1 above. + A cluster node can not be a leaf node. + + A cluster node's child nodes must be: + + - one or more cluster nodes; or + - one or more core nodes + + Any other configuration is considered invalid. + +- core node + + Description: must be declared in a cluster node, one node per core in + the cluster. If the system does not support SMT, core + nodes are leaf nodes, otherwise they become containers of + thread nodes. + + The core node name must be "coreN" as described in 2.1 above. + + A core node must be a leaf node if SMT is not supported. + + Properties for core nodes that are leaf nodes: + + - cpu + Usage: required + Value type: <phandle> + Definition: a phandle to the cpu node that corresponds to the + core node. + + If a core node is not a leaf node (CPUs supporting SMT) a core node's + child nodes can be: + + - one or more thread nodes + + Any other configuration is considered invalid. + +- thread node + + Description: must be declared in a core node, one node per thread + in the core if the system supports SMT. Thread nodes are + always leaf nodes in the device tree. + + The thread node name must be "threadN" as described in 2.1 above. + + A thread node must be a leaf node. + + A thread node must contain the following property: + + - cpu + Usage: required + Value type: <phandle> + Definition: a phandle to the cpu node that corresponds to + the thread node. + +=========================================== +4 - Example dts +=========================================== + +Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters): + +cpus { + #size-cells = <0>; + #address-cells = <2>; + + cpu-map { + cluster0 { + cluster0 { + core0 { + thread0 { + cpu = <&CPU0>; + }; + thread1 { + cpu = <&CPU1>; + }; + }; + + core1 { + thread0 { + cpu = <&CPU2>; + }; + thread1 { + cpu = <&CPU3>; + }; + }; + }; + + cluster1 { + core0 { + thread0 { + cpu = <&CPU4>; + }; + thread1 { + cpu = <&CPU5>; + }; + }; + + core1 { + thread0 { + cpu = <&CPU6>; + }; + thread1 { + cpu = <&CPU7>; + }; + }; + }; + }; + + cluster1 { + cluster0 { + core0 { + thread0 { + cpu = <&CPU8>; + }; + thread1 { + cpu = <&CPU9>; + }; + }; + core1 { + thread0 { + cpu = <&CPU10>; + }; + thread1 { + cpu = <&CPU11>; + }; + }; + }; + + cluster1 { + core0 { + thread0 { + cpu = <&CPU12>; + }; + thread1 { + cpu = <&CPU13>; + }; + }; + core1 { + thread0 { + cpu = <&CPU14>; + }; + thread1 { + cpu = <&CPU15>; + }; + }; + }; + }; + }; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x0>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x1>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU2: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU3: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU4: cpu@10000 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10000>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU5: cpu@10001 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10001>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU6: cpu@10100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU7: cpu@10101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x0 0x10101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU8: cpu@100000000 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x0>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU9: cpu@100000001 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x1>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU10: cpu@100000100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU11: cpu@100000101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU12: cpu@100010000 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10000>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU13: cpu@100010001 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10001>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU14: cpu@100010100 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10100>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; + + CPU15: cpu@100010101 { + device_type = "cpu"; + compatible = "arm,cortex-a57"; + reg = <0x1 0x10101>; + enable-method = "spin-table"; + cpu-release-addr = <0 0x20000000>; + }; +}; + +Example 2 (ARM 32-bit, dual-cluster, 8-cpu system, no SMT): + +cpus { + #size-cells = <0>; + #address-cells = <1>; + + cpu-map { + cluster0 { + core0 { + cpu = <&CPU0>; + }; + core1 { + cpu = <&CPU1>; + }; + core2 { + cpu = <&CPU2>; + }; + core3 { + cpu = <&CPU3>; + }; + }; + + cluster1 { + core0 { + cpu = <&CPU4>; + }; + core1 { + cpu = <&CPU5>; + }; + core2 { + cpu = <&CPU6>; + }; + core3 { + cpu = <&CPU7>; + }; + }; + }; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x0>; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x1>; + }; + + CPU2: cpu@2 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x2>; + }; + + CPU3: cpu@3 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + reg = <0x3>; + }; + + CPU4: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x100>; + }; + + CPU5: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x101>; + }; + + CPU6: cpu@102 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x102>; + }; + + CPU7: cpu@103 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + reg = <0x103>; + }; +}; + +=============================================================================== +[1] ARM Linux kernel documentation + Documentation/devicetree/bindings/arm/cpus.txt diff --git a/Documentation/devicetree/bindings/arm/vic.txt b/Documentation/devicetree/bindings/arm/vic.txt index 266716b2343..dd527216c5f 100644 --- a/Documentation/devicetree/bindings/arm/vic.txt +++ b/Documentation/devicetree/bindings/arm/vic.txt @@ -18,6 +18,15 @@ Required properties: Optional properties: - interrupts : Interrupt source for parent controllers if the VIC is nested. +- valid-mask : A one cell big bit mask of valid interrupt sources. Each bit + represents single interrupt source, starting from source 0 at LSb and ending + at source 31 at MSb. A bit that is set means that the source is wired and + clear means otherwise. If unspecified, defaults to all valid. +- valid-wakeup-mask : A one cell big bit mask of interrupt sources that can be + configured as wake up source for the system. Order of bits is the same as for + valid-mask property. A set bit means that this interrupt source can be + configured as a wake up source for the system. If unspecied, defaults to all + interrupt sources configurable as wake up sources. Example: @@ -26,4 +35,7 @@ Example: interrupt-controller; #interrupt-cells = <1>; reg = <0x60000 0x1000>; + + valid-mask = <0xffffff7f>; + valid-wakeup-mask = <0x0000ff7f>; }; diff --git a/Documentation/devicetree/bindings/clock/efm32-clock.txt b/Documentation/devicetree/bindings/clock/efm32-clock.txt new file mode 100644 index 00000000000..263d293f6a1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/efm32-clock.txt @@ -0,0 +1,11 @@ +* Clock bindings for Energy Micro efm32 Giant Gecko's Clock Management Unit + +Required properties: +- compatible: Should be "efm32gg,cmu" +- reg: Base address and length of the register set +- interrupts: Interrupt used by the CMU +- #clock-cells: Should be <1> + +The clock consumer should specify the desired clock by having the clock ID in +its "clocks" phandle cell. The header efm32-clk.h contains a list of available +IDs. diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index 5a90a724b52..6aab72bf67e 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt @@ -215,6 +215,11 @@ clocks and IDs. cko2 200 cko 201 vdoa 202 + pll4_audio_div 203 + lvds1_sel 204 + lvds2_sel 205 + lvds1_gate 206 + lvds2_gate 207 Examples: diff --git a/Documentation/devicetree/bindings/clock/keystone-gate.txt b/Documentation/devicetree/bindings/clock/keystone-gate.txt new file mode 100644 index 00000000000..c5aa187026e --- /dev/null +++ b/Documentation/devicetree/bindings/clock/keystone-gate.txt @@ -0,0 +1,29 @@ +Status: Unstable - ABI compatibility may be broken in the future + +Binding for Keystone gate control driver which uses PSC controller IP. + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be "ti,keystone,psc-clock". +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : parent clock phandle +- reg : psc control and domain address address space +- reg-names : psc control and domain registers +- domain-id : psc domain id needed to check the transition state register + +Optional properties: +- clock-output-names : From common clock binding to override the + default output clock name +Example: + clkusb: clkusb { + #clock-cells = <0>; + compatible = "ti,keystone,psc-clock"; + clocks = <&chipclk16>; + clock-output-names = "usb"; + reg = <0x02350008 0xb00>, <0x02350000 0x400>; + reg-names = "control", "domain"; + domain-id = <0>; + }; diff --git a/Documentation/devicetree/bindings/clock/keystone-pll.txt b/Documentation/devicetree/bindings/clock/keystone-pll.txt new file mode 100644 index 00000000000..12bd72605a3 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/keystone-pll.txt @@ -0,0 +1,84 @@ +Status: Unstable - ABI compatibility may be broken in the future + +Binding for keystone PLLs. The main PLL IP typically has a multiplier, +a divider and a post divider. The additional PLL IPs like ARMPLL, DDRPLL +and PAPLL are controlled by the memory mapped register where as the Main +PLL is controlled by a PLL controller registers along with memory mapped +registers. + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- #clock-cells : from common clock binding; shall be set to 0. +- compatible : shall be "ti,keystone,main-pll-clock" or "ti,keystone,pll-clock" +- clocks : parent clock phandle +- reg - pll control0 and pll multipler registers +- reg-names : control and multiplier. The multiplier is applicable only for + main pll clock +- fixed-postdiv : fixed post divider value + +Example: + mainpllclk: mainpllclk@2310110 { + #clock-cells = <0>; + compatible = "ti,keystone,main-pll-clock"; + clocks = <&refclkmain>; + reg = <0x02620350 4>, <0x02310110 4>; + reg-names = "control", "multiplier"; + fixed-postdiv = <2>; + }; + + papllclk: papllclk@2620358 { + #clock-cells = <0>; + compatible = "ti,keystone,pll-clock"; + clocks = <&refclkmain>; + clock-output-names = "pa-pll-clk"; + reg = <0x02620358 4>; + reg-names = "control"; + fixed-postdiv = <6>; + }; + +Required properties: +- #clock-cells : from common clock binding; shall be set to 0. +- compatible : shall be "ti,keystone,pll-mux-clock" +- clocks : link phandles of parent clocks +- reg - pll mux register +- bit-shift : number of bits to shift the bit-mask +- bit-mask : arbitrary bitmask for programming the mux + +Optional properties: +- clock-output-names : From common clock binding. + +Example: + mainmuxclk: mainmuxclk@2310108 { + #clock-cells = <0>; + compatible = "ti,keystone,pll-mux-clock"; + clocks = <&mainpllclk>, <&refclkmain>; + reg = <0x02310108 4>; + bit-shift = <23>; + bit-mask = <1>; + clock-output-names = "mainmuxclk"; + }; + +Required properties: +- #clock-cells : from common clock binding; shall be set to 0. +- compatible : shall be "ti,keystone,pll-divider-clock" +- clocks : parent clock phandle +- reg - pll mux register +- bit-shift : number of bits to shift the bit-mask +- bit-mask : arbitrary bitmask for programming the divider + +Optional properties: +- clock-output-names : From common clock binding. + +Example: + gemtraceclk: gemtraceclk@2310120 { + #clock-cells = <0>; + compatible = "ti,keystone,pll-divider-clock"; + clocks = <&mainmuxclk>; + reg = <0x02310120 4>; + bit-shift = <0>; + bit-mask = <8>; + clock-output-names = "gemtraceclk"; + }; diff --git a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt new file mode 100644 index 00000000000..c62391fc0e3 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt @@ -0,0 +1,19 @@ +* Core Divider Clock bindings for Marvell MVEBU SoCs + +The following is a list of provided IDs and clock names on Armada 370/XP: + 0 = nand (NAND clock) + +Required properties: +- compatible : must be "marvell,armada-370-corediv-clock" +- reg : must be the register address of Core Divider control register +- #clock-cells : from common clock binding; shall be set to 1 +- clocks : must be set to the parent's phandle + +Example: + +corediv_clk: corediv-clocks@18740 { + compatible = "marvell,armada-370-corediv-clock"; + reg = <0x18740 0xc>; + #clock-cells = <1>; + clocks = <&pll>; +}; diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt index cffc93d97f5..fc2910fa7e4 100644 --- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt +++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt @@ -1,10 +1,10 @@ -* Gated Clock bindings for Marvell Orion SoCs +* Gated Clock bindings for Marvell EBU SoCs -Marvell Dove and Kirkwood allow some peripheral clocks to be gated to save -some power. The clock consumer should specify the desired clock by having -the clock ID in its "clocks" phandle cell. The clock ID is directly mapped to -the corresponding clock gating control bit in HW to ease manual clock lookup -in datasheet. +Marvell Armada 370/XP, Dove and Kirkwood allow some peripheral clocks to be +gated to save some power. The clock consumer should specify the desired clock +by having the clock ID in its "clocks" phandle cell. The clock ID is directly +mapped to the corresponding clock gating control bit in HW to ease manual clock +lookup in datasheet. The following is a list of provided IDs for Armada 370: ID Clock Peripheral @@ -94,6 +94,8 @@ ID Clock Peripheral Required properties: - compatible : shall be one of the following: + "marvell,armada-370-gating-clock" - for Armada 370 SoC clock gating + "marvell,armada-xp-gating-clock" - for Armada XP SoC clock gating "marvell,dove-gating-clock" - for Dove SoC clock gating "marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating - reg : shall be the register address of the Clock Gating Control register diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index 00a5c26454e..91a748fed13 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -45,8 +45,8 @@ Additionally, "allwinner,*-gates-clk" clocks require: Clock consumers should specify the desired clocks they use with a "clocks" phandle cell. Consumers that are using a gated clock should -provide an additional ID in their clock property. The values of this -ID are documented in sunxi/<soc>-gates.txt. +provide an additional ID in their clock property. This ID is the +offset of the bit controlling this particular gate in the register. For example: diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt deleted file mode 100644 index 6a03475bbfe..00000000000 --- a/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt +++ /dev/null @@ -1,93 +0,0 @@ -Gate clock outputs ------------------- - - * AXI gates ("allwinner,sun4i-axi-gates-clk") - - DRAM 0 - - * AHB gates ("allwinner,sun4i-ahb-gates-clk") - - USB0 0 - EHCI0 1 - OHCI0 2* - EHCI1 3 - OHCI1 4* - SS 5 - DMA 6 - BIST 7 - MMC0 8 - MMC1 9 - MMC2 10 - MMC3 11 - MS 12** - NAND 13 - SDRAM 14 - - ACE 16 - EMAC 17 - TS 18 - - SPI0 20 - SPI1 21 - SPI2 22 - SPI3 23 - PATA 24 - SATA 25** - GPS 26* - - VE 32 - TVD 33 - TVE0 34 - TVE1 35 - LCD0 36 - LCD1 37 - - CSI0 40 - CSI1 41 - - HDMI 43 - DE_BE0 44 - DE_BE1 45 - DE_FE1 46 - DE_FE1 47 - - MP 50 - - MALI400 52 - - * APB0 gates ("allwinner,sun4i-apb0-gates-clk") - - CODEC 0 - SPDIF 1* - AC97 2 - IIS 3 - - PIO 5 - IR0 6 - IR1 7 - - KEYPAD 10 - - * APB1 gates ("allwinner,sun4i-apb1-gates-clk") - - I2C0 0 - I2C1 1 - I2C2 2 - - CAN 4 - SCR 5 - PS20 6 - PS21 7 - - UART0 16 - UART1 17 - UART2 18 - UART3 19 - UART4 20 - UART5 21 - UART6 22 - UART7 23 - -Notation: - [*]: The datasheet didn't mention these, but they are present on AW code - [**]: The datasheet had this marked as "NC" but they are used on AW code diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun5i-a10s-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a10s-gates.txt deleted file mode 100644 index d24279fe142..00000000000 --- a/Documentation/devicetree/bindings/clock/sunxi/sun5i-a10s-gates.txt +++ /dev/null @@ -1,75 +0,0 @@ -Gate clock outputs ------------------- - - * AXI gates ("allwinner,sun4i-axi-gates-clk") - - DRAM 0 - - * AHB gates ("allwinner,sun5i-a10s-ahb-gates-clk") - - USB0 0 - EHCI0 1 - OHCI0 2 - - SS 5 - DMA 6 - BIST 7 - MMC0 8 - MMC1 9 - MMC2 10 - - NAND 13 - SDRAM 14 - - EMAC 17 - TS 18 - - SPI0 20 - SPI1 21 - SPI2 22 - - GPS 26 - - HSTIMER 28 - - VE 32 - - TVE 34 - - LCD 36 - - CSI 40 - - HDMI 43 - DE_BE 44 - - DE_FE 46 - - IEP 51 - MALI400 52 - - * APB0 gates ("allwinner,sun5i-a10s-apb0-gates-clk") - - CODEC 0 - - IIS 3 - - PIO 5 - IR 6 - - KEYPAD 10 - - * APB1 gates ("allwinner,sun5i-a10s-apb1-gates-clk") - - I2C0 0 - I2C1 1 - I2C2 2 - - UART0 16 - UART1 17 - UART2 18 - UART3 19 - -Notation: - [*]: The datasheet didn't mention these, but they are present on AW code - [**]: The datasheet had this marked as "NC" but they are used on AW code diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt deleted file mode 100644 index 006b6dfc470..00000000000 --- a/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt +++ /dev/null @@ -1,58 +0,0 @@ -Gate clock outputs ------------------- - - * AXI gates ("allwinner,sun4i-axi-gates-clk") - - DRAM 0 - - * AHB gates ("allwinner,sun5i-a13-ahb-gates-clk") - - USBOTG 0 - EHCI 1 - OHCI 2 - - SS 5 - DMA 6 - BIST 7 - MMC0 8 - MMC1 9 - MMC2 10 - - NAND 13 - SDRAM 14 - - SPI0 20 - SPI1 21 - SPI2 22 - - STIMER 28 - - VE 32 - - LCD 36 - - CSI 40 - - DE_BE 44 - - DE_FE 46 - - IEP 51 - MALI400 52 - - * APB0 gates ("allwinner,sun5i-a13-apb0-gates-clk") - - CODEC 0 - - PIO 5 - IR 6 - - * APB1 gates ("allwinner,sun5i-a13-apb1-gates-clk") - - I2C0 0 - I2C1 1 - I2C2 2 - - UART1 17 - - UART3 19 diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt deleted file mode 100644 index fe44932b5c6..00000000000 --- a/Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt +++ /dev/null @@ -1,83 +0,0 @@ -Gate clock outputs ------------------- - - * AHB1 gates ("allwinner,sun6i-a31-ahb1-gates-clk") - - MIPI DSI 1 - - SS 5 - DMA 6 - - MMC0 8 - MMC1 9 - MMC2 10 - MMC3 11 - - NAND1 12 - NAND0 13 - SDRAM 14 - - GMAC 17 - TS 18 - HSTIMER 19 - SPI0 20 - SPI1 21 - SPI2 22 - SPI3 23 - USB_OTG 24 - - EHCI0 26 - EHCI1 27 - - OHCI0 29 - OHCI1 30 - OHCI2 31 - VE 32 - - LCD0 36 - LCD1 37 - - CSI 40 - - HDMI 43 - DE_BE0 44 - DE_BE1 45 - DE_FE1 46 - DE_FE1 47 - - MP 50 - - GPU 52 - - DEU0 55 - DEU1 56 - DRC0 57 - DRC1 58 - - * APB1 gates ("allwinner,sun6i-a31-apb1-gates-clk") - - CODEC 0 - - DIGITAL MIC 4 - PIO 5 - - DAUDIO0 12 - DAUDIO1 13 - - * APB2 gates ("allwinner,sun6i-a31-apb2-gates-clk") - - I2C0 0 - I2C1 1 - I2C2 2 - I2C3 3 - - UART0 16 - UART1 17 - UART2 18 - UART3 19 - UART4 20 - UART5 21 - -Notation: - [*]: The datasheet didn't mention these, but they are present on AW code - [**]: The datasheet had this marked as "NC" but they are used on AW code diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun7i-a20-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun7i-a20-gates.txt deleted file mode 100644 index 357f4fdc02e..00000000000 --- a/Documentation/devicetree/bindings/clock/sunxi/sun7i-a20-gates.txt +++ /dev/null @@ -1,98 +0,0 @@ -Gate clock outputs ------------------- - - * AXI gates ("allwinner,sun4i-axi-gates-clk") - - DRAM 0 - - * AHB gates ("allwinner,sun7i-a20-ahb-gates-clk") - - USB0 0 - EHCI0 1 - OHCI0 2 - EHCI1 3 - OHCI1 4 - SS 5 - DMA 6 - BIST 7 - MMC0 8 - MMC1 9 - MMC2 10 - MMC3 11 - MS 12 - NAND 13 - SDRAM 14 - - ACE 16 - EMAC 17 - TS 18 - - SPI0 20 - SPI1 21 - SPI2 22 - SPI3 23 - - SATA 25 - - HSTIMER 28 - - VE 32 - TVD 33 - TVE0 34 - TVE1 35 - LCD0 36 - LCD1 37 - - CSI0 40 - CSI1 41 - - HDMI1 42 - HDMI0 43 - DE_BE0 44 - DE_BE1 45 - DE_FE1 46 - DE_FE1 47 - - GMAC 49 - MP 50 - - MALI400 52 - - * APB0 gates ("allwinner,sun7i-a20-apb0-gates-clk") - - CODEC 0 - SPDIF 1 - AC97 2 - IIS0 3 - IIS1 4 - PIO 5 - IR0 6 - IR1 7 - IIS2 8 - - KEYPAD 10 - - * APB1 gates ("allwinner,sun7i-a20-apb1-gates-clk") - - I2C0 0 - I2C1 1 - I2C2 2 - I2C3 3 - CAN 4 - SCR 5 - PS20 6 - PS21 7 - - I2C4 15 - UART0 16 - UART1 17 - UART2 18 - UART3 19 - UART4 20 - UART5 21 - UART6 22 - UART7 23 - -Notation: - [*]: The datasheet didn't mention these, but they are present on AW code - [**]: The datasheet had this marked as "NC" but they are used on AW code diff --git a/Documentation/devicetree/bindings/clock/xgene.txt b/Documentation/devicetree/bindings/clock/xgene.txt new file mode 100644 index 00000000000..1c4ef773fee --- /dev/null +++ b/Documentation/devicetree/bindings/clock/xgene.txt @@ -0,0 +1,111 @@ +Device Tree Clock bindings for APM X-Gene + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be one of the following: + "apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock + "apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock + "apm,xgene-device-clock" - for a X-Gene device clock + +Required properties for SoC or PCP PLL clocks: +- reg : shall be the physical PLL register address for the pll clock. +- clocks : shall be the input parent clock phandle for the clock. This should + be the reference clock. +- #clock-cells : shall be set to 1. +- clock-output-names : shall be the name of the PLL referenced by derive + clock. +Optional properties for PLL clocks: +- clock-names : shall be the name of the PLL. If missing, use the device name. + +Required properties for device clocks: +- reg : shall be a list of address and length pairs describing the CSR + reset and/or the divider. Either may be omitted, but at least + one must be present. + - reg-names : shall be a string list describing the reg resource. This + may include "csr-reg" and/or "div-reg". If this property + is not present, the reg property is assumed to describe + only "csr-reg". +- clocks : shall be the input parent clock phandle for the clock. +- #clock-cells : shall be set to 1. +- clock-output-names : shall be the name of the device referenced. +Optional properties for device clocks: +- clock-names : shall be the name of the device clock. If missing, use the + device name. +- csr-offset : Offset to the CSR reset register from the reset address base. + Default is 0. +- csr-mask : CSR reset mask bit. Default is 0xF. +- enable-offset : Offset to the enable register from the reset address base. + Default is 0x8. +- enable-mask : CSR enable mask bit. Default is 0xF. +- divider-offset : Offset to the divider CSR register from the divider base. + Default is 0x0. +- divider-width : Width of the divider register. Default is 0. +- divider-shift : Bit shift of the divider register. Default is 0. + +For example: + + pcppll: pcppll@17000100 { + compatible = "apm,xgene-pcppll-clock"; + #clock-cells = <1>; + clocks = <&refclk 0>; + clock-names = "pcppll"; + reg = <0x0 0x17000100 0x0 0x1000>; + clock-output-names = "pcppll"; + type = <0>; + }; + + socpll: socpll@17000120 { + compatible = "apm,xgene-socpll-clock"; + #clock-cells = <1>; + clocks = <&refclk 0>; + clock-names = "socpll"; + reg = <0x0 0x17000120 0x0 0x1000>; + clock-output-names = "socpll"; + type = <1>; + }; + + qmlclk: qmlclk { + compatible = "apm,xgene-device-clock"; + #clock-cells = <1>; + clocks = <&socplldiv2 0>; + clock-names = "qmlclk"; + reg = <0x0 0x1703C000 0x0 0x1000>; + reg-name = "csr-reg"; + clock-output-names = "qmlclk"; + }; + + ethclk: ethclk { + compatible = "apm,xgene-device-clock"; + #clock-cells = <1>; + clocks = <&socplldiv2 0>; + clock-names = "ethclk"; + reg = <0x0 0x17000000 0x0 0x1000>; + reg-names = "div-reg"; + divider-offset = <0x238>; + divider-width = <0x9>; + divider-shift = <0x0>; + clock-output-names = "ethclk"; + }; + + apbclk: apbclk { + compatible = "apm,xgene-device-clock"; + #clock-cells = <1>; + clocks = <&ahbclk 0>; + clock-names = "apbclk"; + reg = <0x0 0x1F2AC000 0x0 0x1000 + 0x0 0x1F2AC000 0x0 0x1000>; + reg-names = "csr-reg", "div-reg"; + csr-offset = <0x0>; + csr-mask = <0x200>; + enable-offset = <0x8>; + enable-mask = <0x200>; + divider-offset = <0x10>; + divider-width = <0x2>; + divider-shift = <0x0>; + flags = <0x8>; + clock-output-names = "apbclk"; + }; + diff --git a/Documentation/devicetree/bindings/crypto/omap-aes.txt b/Documentation/devicetree/bindings/crypto/omap-aes.txt new file mode 100644 index 00000000000..fd9717653cb --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/omap-aes.txt @@ -0,0 +1,31 @@ +OMAP SoC AES crypto Module + +Required properties: + +- compatible : Should contain entries for this and backward compatible + AES versions: + - "ti,omap2-aes" for OMAP2. + - "ti,omap3-aes" for OMAP3. + - "ti,omap4-aes" for OMAP4 and AM33XX. + Note that the OMAP2 and 3 versions are compatible (OMAP3 supports + more algorithms) but they are incompatible with OMAP4. +- ti,hwmods: Name of the hwmod associated with the AES module +- reg : Offset and length of the register set for the module +- interrupts : the interrupt-specifier for the AES module. + +Optional properties: +- dmas: DMA specifiers for tx and rx dma. See the DMA client binding, + Documentation/devicetree/bindings/dma/dma.txt +- dma-names: DMA request names should include "tx" and "rx" if present. + +Example: + /* AM335x */ + aes: aes@53500000 { + compatible = "ti,omap4-aes"; + ti,hwmods = "aes"; + reg = <0x53500000 0xa0>; + interrupts = <102>; + dmas = <&edma 6>, + <&edma 5>; + dma-names = "tx", "rx"; + }; diff --git a/Documentation/devicetree/bindings/crypto/omap-sham.txt b/Documentation/devicetree/bindings/crypto/omap-sham.txt new file mode 100644 index 00000000000..f839acd6f0e --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/omap-sham.txt @@ -0,0 +1,28 @@ +OMAP SoC SHA crypto Module + +Required properties: + +- compatible : Should contain entries for this and backward compatible + SHAM versions: + - "ti,omap2-sham" for OMAP2 & OMAP3. + - "ti,omap4-sham" for OMAP4 and AM33XX. + Note that these two versions are incompatible. +- ti,hwmods: Name of the hwmod associated with the SHAM module +- reg : Offset and length of the register set for the module +- interrupts : the interrupt-specifier for the SHAM module. + +Optional properties: +- dmas: DMA specifiers for the rx dma. See the DMA client binding, + Documentation/devicetree/bindings/dma/dma.txt +- dma-names: DMA request name. Should be "rx" if a dma is present. + +Example: + /* AM335x */ + sham: sham@53100000 { + compatible = "ti,omap4-sham"; + ti,hwmods = "sham"; + reg = <0x53100000 0x200>; + interrupts = <109>; + dmas = <&edma 36>; + dma-names = "rx"; + }; diff --git a/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt b/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt new file mode 100644 index 00000000000..00611aceed3 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt @@ -0,0 +1,36 @@ +* Abilis TB10x GPIO controller + +Required Properties: +- compatible: Should be "abilis,tb10x-gpio" +- reg: Address and length of the register set for the device +- gpio-controller: Marks the device node as a gpio controller. +- #gpio-cells: Should be <2>. The first cell is the pin number and the + second cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted). +- abilis,ngpio: the number of GPIO pins this driver controls. + +Optional Properties: +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be <1>. Interrupts are triggered on both edges. +- interrupts: Defines the interrupt line connecting this GPIO controller to + its parent interrupt controller. +- interrupt-parent: Defines the parent interrupt controller. + +GPIO ranges are specified as described in +Documentation/devicetree/bindings/gpio/gpio.txt + +Example: + + gpioa: gpio@FF140000 { + compatible = "abilis,tb10x-gpio"; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&tb10x_ictl>; + interrupts = <27 2>; + reg = <0xFF140000 0x1000>; + gpio-controller; + #gpio-cells = <2>; + abilis,ngpio = <3>; + gpio-ranges = <&iomux 0 0 0>; + gpio-ranges-group-names = "gpioa_pins"; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt new file mode 100644 index 00000000000..4a63bc96b68 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt @@ -0,0 +1,52 @@ +Broadcom Kona Family GPIO +========================= + +This GPIO driver is used in the following Broadcom SoCs: + BCM11130, BCM11140, BCM11351, BCM28145, BCM28155 + +The Broadcom GPIO Controller IP can be configured prior to synthesis to +support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The +GPIO controller only supports edge, not level, triggering of interrupts. + +Required properties +------------------- + +- compatible: "brcm,bcm11351-gpio", "brcm,kona-gpio" +- reg: Physical base address and length of the controller's registers. +- interrupts: The interrupt outputs from the controller. There is one GPIO + interrupt per GPIO bank. The number of interrupts listed depends on the + number of GPIO banks on the SoC. The interrupts must be ordered by bank, + starting with bank 0. There is always a 1:1 mapping between banks and + IRQs. +- #gpio-cells: Should be <2>. The first cell is the pin number, the second + cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted) + See also "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt. +- #interrupt-cells: Should be <2>. The first cell is the GPIO number. The + second cell is used to specify flags. The following subset of flags is + supported: + - trigger type (bits[1:0]): + 1 = low-to-high edge triggered. + 2 = high-to-low edge triggered. + 3 = low-to-high or high-to-low edge triggered + Valid values are 1, 2, 3 + See also .../devicetree/bindings/interrupt-controller/interrupts.txt. +- gpio-controller: Marks the device node as a GPIO controller. +- interrupt-controller: Marks the device node as an interrupt controller. + +Example: + gpio: gpio@35003000 { + compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio"; + reg = <0x35003000 0x800>; + interrupts = + <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH + GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH + GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH + GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH + GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH + GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>; + #gpio-cells = <2>; + #interrupt-cells = <2>; + gpio-controller; + interrupt-controller; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt new file mode 100644 index 00000000000..d63194a2c84 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt @@ -0,0 +1,71 @@ +* PCF857x-compatible I/O expanders + +The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be +driven high by a pull-up current source or driven low to ground. This combines +the direction and output level into a single bit per line, which can't be read +back. We can't actually know at initialization time whether a line is configured +(a) as output and driving the signal low/high, or (b) as input and reporting a +low/high value, without knowing the last value written since the chip came out +of reset (if any). The only reliable solution for setting up line direction is +thus to do it explicitly. + +Required Properties: + + - compatible: should be one of the following. + - "maxim,max7328": For the Maxim MAX7378 + - "maxim,max7329": For the Maxim MAX7329 + - "nxp,pca8574": For the NXP PCA8574 + - "nxp,pca8575": For the NXP PCA8575 + - "nxp,pca9670": For the NXP PCA9670 + - "nxp,pca9671": For the NXP PCA9671 + - "nxp,pca9672": For the NXP PCA9672 + - "nxp,pca9673": For the NXP PCA9673 + - "nxp,pca9674": For the NXP PCA9674 + - "nxp,pca9675": For the NXP PCA9675 + - "nxp,pcf8574": For the NXP PCF8574 + - "nxp,pcf8574a": For the NXP PCF8574A + - "nxp,pcf8575": For the NXP PCF8575 + - "ti,tca9554": For the TI TCA9554 + + - reg: I2C slave address. + + - gpio-controller: Marks the device node as a gpio controller. + - #gpio-cells: Should be 2. The first cell is the GPIO number and the second + cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the + GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. + +Optional Properties: + + - lines-initial-states: Bitmask that specifies the initial state of each + line. When a bit is set to zero, the corresponding line will be initialized to + the input (pulled-up) state. When the bit is set to one, the line will be + initialized the the low-level output state. If the property is not specified + all lines will be initialized to the input state. + + The I/O expander can detect input state changes, and thus optionally act as + an interrupt controller. When the expander interrupt line is connected all the + following properties must be set. For more information please see the + interrupt controller device tree bindings documentation available at + Documentation/devicetree/bindings/interrupt-controller/interrupts.txt. + + - interrupt-controller: Identifies the node as an interrupt controller. + - #interrupt-cells: Number of cells to encode an interrupt source, shall be 2. + - interrupt-parent: phandle of the parent interrupt controller. + - interrupts: Interrupt specifier for the controllers interrupt. + + +Please refer to gpio.txt in this directory for details of the common GPIO +bindings used by client devices. + +Example: PCF8575 I/O expander node + + pcf8575: gpio@20 { + compatible = "nxp,pcf8575"; + reg = <0x20>; + interrupt-parent = <&irqpin2>; + interrupts = <3 0>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index 6cec6ff20d2..0c85bb6e3a8 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -87,8 +87,10 @@ controllers. The gpio-ranges property described below represents this, and contains information structures as follows: gpio-range-list ::= <single-gpio-range> [gpio-range-list] - single-gpio-range ::= + single-gpio-range ::= <numeric-gpio-range> | <named-gpio-range> + numeric-gpio-range ::= <pinctrl-phandle> <gpio-base> <pinctrl-base> <count> + named-gpio-range ::= <pinctrl-phandle> <gpio-base> '<0 0>' gpio-phandle : phandle to pin controller node. gpio-base : Base GPIO ID in the GPIO controller pinctrl-base : Base pinctrl pin ID in the pin controller @@ -97,6 +99,19 @@ contains information structures as follows: The "pin controller node" mentioned above must conform to the bindings described in ../pinctrl/pinctrl-bindings.txt. +In case named gpio ranges are used (ranges with both <pinctrl-base> and +<count> set to 0), the property gpio-ranges-group-names contains one string +for every single-gpio-range in gpio-ranges: + gpiorange-names-list ::= <gpiorange-name> [gpiorange-names-list] + gpiorange-name : Name of the pingroup associated to the GPIO range in + the respective pin controller. + +Elements of gpiorange-names-list corresponding to numeric ranges contain +the empty string. Elements of gpiorange-names-list corresponding to named +ranges contain the name of a pin group defined in the respective pin +controller. The number of pins/GPIOs in the range is the number of pins in +that pin group. + Previous versions of this binding required all pin controller nodes that were referenced by any gpio-ranges property to contain a property named #gpio-range-cells with value <3>. This requirement is now deprecated. @@ -104,7 +119,7 @@ However, that property may still exist in older device trees for compatibility reasons, and would still be required even in new device trees that need to be compatible with older software. -Example: +Example 1: qe_pio_e: gpio-controller@1460 { #gpio-cells = <2>; @@ -117,3 +132,24 @@ Example: Here, a single GPIO controller has GPIOs 0..9 routed to pin controller pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's pins 50..59. + +Example 2: + + gpio_pio_i: gpio-controller@14B0 { + #gpio-cells = <2>; + compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank"; + reg = <0x1480 0x18>; + gpio-controller; + gpio-ranges = <&pinctrl1 0 20 10>, + <&pinctrl2 10 0 0>, + <&pinctrl1 15 0 10>, + <&pinctrl2 25 0 0>; + gpio-ranges-group-names = "", + "foo", + "", + "bar"; + }; + +Here, three GPIO ranges are defined wrt. two pin controllers. pinctrl1 GPIO +ranges are defined using pin numbers whereas the GPIO ranges wrt. pinctrl2 +are named "foo" and "bar". diff --git a/Documentation/devicetree/bindings/hwrng/omap_rng.txt b/Documentation/devicetree/bindings/hwrng/omap_rng.txt new file mode 100644 index 00000000000..6a62acd8695 --- /dev/null +++ b/Documentation/devicetree/bindings/hwrng/omap_rng.txt @@ -0,0 +1,22 @@ +OMAP SoC HWRNG Module + +Required properties: + +- compatible : Should contain entries for this and backward compatible + RNG versions: + - "ti,omap2-rng" for OMAP2. + - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX. + Note that these two versions are incompatible. +- ti,hwmods: Name of the hwmod associated with the RNG module +- reg : Offset and length of the register set for the module +- interrupts : the interrupt number for the RNG module. + Only used for "ti,omap4-rng". + +Example: +/* AM335x */ +rng: rng@48310000 { + compatible = "ti,omap4-rng"; + ti,hwmods = "rng"; + reg = <0x48310000 0x2000>; + interrupts = <111>; +}; diff --git a/Documentation/devicetree/bindings/iio/light/cm36651.txt b/Documentation/devicetree/bindings/iio/light/cm36651.txt new file mode 100644 index 00000000000..c03e19db455 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/cm36651.txt @@ -0,0 +1,26 @@ +* Capella CM36651 I2C Proximity and Color Light sensor + +Required properties: +- compatible: must be "capella,cm36651" +- reg: the I2C address of the device +- interrupts: interrupt-specifier for the sole interrupt + generated by the device +- vled-supply: regulator for the IR LED. IR_LED is a part + of the cm36651 for proximity detection. + As covered in ../../regulator/regulator.txt + +Example: + + i2c_cm36651: i2c-gpio { + /* ... */ + + cm36651@18 { + compatible = "capella,cm36651"; + reg = <0x18>; + interrupt-parent = <&gpx0>; + interrupts = <2 0>; + vled-supply = <&ps_als_reg>; + }; + + /* ... */ + }; diff --git a/Documentation/devicetree/bindings/iio/light/gp2ap020a00f.txt b/Documentation/devicetree/bindings/iio/light/gp2ap020a00f.txt new file mode 100644 index 00000000000..9231c82317a --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/gp2ap020a00f.txt @@ -0,0 +1,21 @@ +* Sharp GP2AP020A00F I2C Proximity/ALS sensor + +The proximity detector sensor requires power supply +for its built-in led. It is also defined by this binding. + +Required properties: + + - compatible : should be "sharp,gp2ap020a00f" + - reg : the I2C slave address of the light sensor + - interrupts : interrupt specifier for the sole interrupt generated + by the device + - vled-supply : VLED power supply, as covered in ../regulator/regulator.txt + +Example: + +gp2ap020a00f@39 { + compatible = "sharp,gp2ap020a00f"; + reg = <0x39>; + interrupts = <2 0>; + vled-supply = <...>; +}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt index 57edb30dbbc..3d3b2b91e33 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt @@ -8,9 +8,6 @@ Required properties: - #interrupt-cells : Specifies the number of cells needed to encode an interrupt source. The value shall be 1. -For the valid interrupt sources for your SoC, see the documentation in -sunxi/<soc>.txt - Example: intc: interrupt-controller { diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt index 72a06c0ab1d..1486497a24c 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt @@ -4,16 +4,33 @@ Specifying interrupt information for devices 1) Interrupt client nodes ------------------------- -Nodes that describe devices which generate interrupts must contain an -"interrupts" property. This property must contain a list of interrupt -specifiers, one per output interrupt. The format of the interrupt specifier is -determined by the interrupt controller to which the interrupts are routed; see -section 2 below for details. +Nodes that describe devices which generate interrupts must contain an either an +"interrupts" property or an "interrupts-extended" property. These properties +contain a list of interrupt specifiers, one per output interrupt. The format of +the interrupt specifier is determined by the interrupt controller to which the +interrupts are routed; see section 2 below for details. + + Example: + interrupt-parent = <&intc1>; + interrupts = <5 0>, <6 0>; The "interrupt-parent" property is used to specify the controller to which interrupts are routed and contains a single phandle referring to the interrupt controller node. This property is inherited, so it may be specified in an -interrupt client node or in any of its parent nodes. +interrupt client node or in any of its parent nodes. Interrupts listed in the +"interrupts" property are always in reference to the node's interrupt parent. + +The "interrupts-extended" property is a special form for use when a node needs +to reference multiple interrupt parents. Each entry in this property contains +both the parent phandle and the interrupt specifier. "interrupts-extended" +should only be used when a device has multiple interrupt parents. + + Example: + interrupts-extended = <&intc1 5 1>, <&intc2 1 0>; + +A device node may contain either "interrupts" or "interrupts-extended", but not +both. If both properties are present, then the operating system should log an +error and use only the data in "interrupts". 2) Interrupt controller nodes ----------------------------- diff --git a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt deleted file mode 100644 index 76b98c83449..00000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt +++ /dev/null @@ -1,89 +0,0 @@ -Allwinner A10 (sun4i) interrupt sources ---------------------------------------- - -The interrupt sources available for the Allwinner A10 SoC are the -following one: - -0: ENMI -1: UART0 -2: UART1 -3: UART2 -4: UART3 -5: IR0 -6: IR1 -7: I2C0 -8: I2C1 -9: I2C2 -10: SPI0 -11: SPI1 -12: SPI2 -13: SPDIF -14: AC97 -15: TS -16: I2S -17: UART4 -18: UART5 -19: UART6 -20: UART7 -21: KEYPAD -22: TIMER0 -23: TIMER1 -24: TIMER2 -25: TIMER3 -26: CAN -27: DMA -28: PIO -29: TOUCH_PANEL -30: AUDIO_CODEC -31: LRADC -32: MMC0 -33: MMC1 -34: MMC2 -35: MMC3 -36: MEMSTICK -37: NAND -38: USB0 -39: USB1 -40: USB2 -41: SCR -42: CSI0 -43: CSI1 -44: LCDCTRL0 -45: LCDCTRL1 -46: MP -47: DEFEBE0 -48: DEFEBE1 -49: PMU -50: SPI3 -51: TZASC -52: PATA -53: VE -54: SS -55: EMAC -56: SATA -57: GPS -58: HDMI -59: TVE -60: ACE -61: TVD -62: PS2_0 -63: PS2_1 -64: USB3 -65: USB4 -66: PLE_PFM -67: TIMER4 -68: TIMER5 -69: GPU_GP -70: GPU_GPMMU -71: GPU_PP0 -72: GPU_PPMMU0 -73: GPU_PMU -74: GPU_RSV0 -75: GPU_RSV1 -76: GPU_RSV2 -77: GPU_RSV3 -78: GPU_RSV4 -79: GPU_RSV5 -80: GPU_RSV6 -82: SYNC_TIMER0 -83: SYNC_TIMER1 diff --git a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt deleted file mode 100644 index 2ec3b5ce1a0..00000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt +++ /dev/null @@ -1,55 +0,0 @@ -Allwinner A13 (sun5i) interrupt sources ---------------------------------------- - -The interrupt sources available for the Allwinner A13 SoC are the -following one: - -0: ENMI -2: UART1 -4: UART3 -5: IR -7: I2C0 -8: I2C1 -9: I2C2 -10: SPI0 -11: SPI1 -12: SPI2 -22: TIMER0 -23: TIMER1 -24: TIMER2 -25: TIMER3 -27: DMA -28: PIO -29: TOUCH_PANEL -30: AUDIO_CODEC -31: LRADC -32: MMC0 -33: MMC1 -34: MMC2 -37: NAND -38: USB OTG -39: USB EHCI -40: USB OHCI -42: CSI -44: LCDCTRL -47: DEFEBE -49: PMU -53: VE -54: SS -66: PLE_PFM -67: TIMER4 -68: TIMER5 -69: GPU_GP -70: GPU_GPMMU -71: GPU_PP0 -72: GPU_PPMMU0 -73: GPU_PMU -74: GPU_RSV0 -75: GPU_RSV1 -76: GPU_RSV2 -77: GPU_RSV3 -78: GPU_RSV4 -79: GPU_RSV5 -80: GPU_RSV6 -82: SYNC_TIMER0 -83: SYNC_TIMER1 diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt index a61727f9a6d..c55b8c016a9 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt @@ -10,6 +10,7 @@ Each child has own specific current settings - max-cur: Maximun current at each led channel. Optional properties: +- enable-gpio: GPIO attached to the chip's enable pin - label: Used for naming LEDs - pwr-sel: LP8501 specific property. Power selection for output channels. 0: D1~9 are connected to VDD @@ -17,12 +18,15 @@ Optional properties: 2: D1~6 with VOUT, D7~9 with VDD 3: D1~9 are connected to VOUT -Alternatively, each child can have specific channel name -- chan-name: Name of each channel name +Alternatively, each child can have a specific channel name and trigger: +- chan-name (optional): name of channel +- linux,default-trigger (optional): see + Documentation/devicetree/bindings/leds/common.txt example 1) LP5521 3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0', -'lp5521_pri:channel1' and 'lp5521_pri:channel2' +'lp5521_pri:channel1' and 'lp5521_pri:channel2', with a heartbeat trigger +on channel 0. lp5521@32 { compatible = "national,lp5521"; @@ -33,6 +37,7 @@ lp5521@32 { chan0 { led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; + linux,default-trigger = "heartbeat"; }; chan1 { diff --git a/Documentation/devicetree/bindings/memory.txt b/Documentation/devicetree/bindings/memory.txt deleted file mode 100644 index eb246936559..00000000000 --- a/Documentation/devicetree/bindings/memory.txt +++ /dev/null @@ -1,168 +0,0 @@ -*** Memory binding *** - -The /memory node provides basic information about the address and size -of the physical memory. This node is usually filled or updated by the -bootloader, depending on the actual memory configuration of the given -hardware. - -The memory layout is described by the following node: - -/ { - #address-cells = <(n)>; - #size-cells = <(m)>; - memory { - device_type = "memory"; - reg = <(baseaddr1) (size1) - (baseaddr2) (size2) - ... - (baseaddrN) (sizeN)>; - }; - ... -}; - -A memory node follows the typical device tree rules for "reg" property: -n: number of cells used to store base address value -m: number of cells used to store size value -baseaddrX: defines a base address of the defined memory bank -sizeX: the size of the defined memory bank - - -More than one memory bank can be defined. - - -*** Reserved memory regions *** - -In /memory/reserved-memory node one can create child nodes describing -particular reserved (excluded from normal use) memory regions. Such -memory regions are usually designed for the special usage by various -device drivers. A good example are contiguous memory allocations or -memory sharing with other operating system on the same hardware board. -Those special memory regions might depend on the board configuration and -devices used on the target system. - -Parameters for each memory region can be encoded into the device tree -with the following convention: - -[(label):] (name) { - compatible = "linux,contiguous-memory-region", "reserved-memory-region"; - reg = <(address) (size)>; - (linux,default-contiguous-region); -}; - -compatible: one or more of: - - "linux,contiguous-memory-region" - enables binding of this - region to Contiguous Memory Allocator (special region for - contiguous memory allocations, shared with movable system - memory, Linux kernel-specific). - - "reserved-memory-region" - compatibility is defined, given - region is assigned for exclusive usage for by the respective - devices. - -reg: standard property defining the base address and size of - the memory region - -linux,default-contiguous-region: property indicating that the region - is the default region for all contiguous memory - allocations, Linux specific (optional) - -It is optional to specify the base address, so if one wants to use -autoconfiguration of the base address, '0' can be specified as a base -address in the 'reg' property. - -The /memory/reserved-memory node must contain the same #address-cells -and #size-cells value as the root node. - - -*** Device node's properties *** - -Once regions in the /memory/reserved-memory node have been defined, they -may be referenced by other device nodes. Bindings that wish to reference -memory regions should explicitly document their use of the following -property: - -memory-region = <&phandle_to_defined_region>; - -This property indicates that the device driver should use the memory -region pointed by the given phandle. - - -*** Example *** - -This example defines a memory consisting of 4 memory banks. 3 contiguous -regions are defined for Linux kernel, one default of all device drivers -(named contig_mem, placed at 0x72000000, 64MiB), one dedicated to the -framebuffer device (labelled display_mem, placed at 0x78000000, 8MiB) -and one for multimedia processing (labelled multimedia_mem, placed at -0x77000000, 64MiB). 'display_mem' region is then assigned to fb@12300000 -device for DMA memory allocations (Linux kernel drivers will use CMA is -available or dma-exclusive usage otherwise). 'multimedia_mem' is -assigned to scaler@12500000 and codec@12600000 devices for contiguous -memory allocations when CMA driver is enabled. - -The reason for creating a separate region for framebuffer device is to -match the framebuffer base address to the one configured by bootloader, -so once Linux kernel drivers starts no glitches on the displayed boot -logo appears. Scaller and codec drivers should share the memory -allocations. - -/ { - #address-cells = <1>; - #size-cells = <1>; - - /* ... */ - - memory { - reg = <0x40000000 0x10000000 - 0x50000000 0x10000000 - 0x60000000 0x10000000 - 0x70000000 0x10000000>; - - reserved-memory { - #address-cells = <1>; - #size-cells = <1>; - - /* - * global autoconfigured region for contiguous allocations - * (used only with Contiguous Memory Allocator) - */ - contig_region@0 { - compatible = "linux,contiguous-memory-region"; - reg = <0x0 0x4000000>; - linux,default-contiguous-region; - }; - - /* - * special region for framebuffer - */ - display_region: region@78000000 { - compatible = "linux,contiguous-memory-region", "reserved-memory-region"; - reg = <0x78000000 0x800000>; - }; - - /* - * special region for multimedia processing devices - */ - multimedia_region: region@77000000 { - compatible = "linux,contiguous-memory-region"; - reg = <0x77000000 0x4000000>; - }; - }; - }; - - /* ... */ - - fb0: fb@12300000 { - status = "okay"; - memory-region = <&display_region>; - }; - - scaler: scaler@12500000 { - status = "okay"; - memory-region = <&multimedia_region>; - }; - - codec: codec@12600000 { - status = "okay"; - memory-region = <&multimedia_region>; - }; -}; diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt new file mode 100644 index 00000000000..68ba3729556 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt @@ -0,0 +1,17 @@ +Allwinner sunxi-sid + +Required properties: +- compatible: "allwinner,sun4i-sid" or "allwinner,sun7i-a20-sid". +- reg: Should contain registers location and length + +Example for sun4i: + sid@01c23800 { + compatible = "allwinner,sun4i-sid"; + reg = <0x01c23800 0x10> + }; + +Example for sun7i: + sid@01c23800 { + compatible = "allwinner,sun7i-a20-sid"; + reg = <0x01c23800 0x200> + }; diff --git a/Documentation/devicetree/bindings/misc/ti,dac7512.txt b/Documentation/devicetree/bindings/misc/ti,dac7512.txt new file mode 100644 index 00000000000..1db45939dac --- /dev/null +++ b/Documentation/devicetree/bindings/misc/ti,dac7512.txt @@ -0,0 +1,20 @@ +TI DAC7512 DEVICETREE BINDINGS + +Required properties: + + - "compatible" Must be set to "ti,dac7512" + +Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt +apply. In particular, "reg" and "spi-max-frequency" properties must be given. + + +Example: + + spi_master { + dac7512: dac7512@0 { + compatible = "ti,dac7512"; + reg = <0>; /* CS0 */ + spi-max-frequency = <1000000>; + }; + }; + diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index ed271fc255b..8c8908ab84b 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -20,8 +20,29 @@ ti,dual-volt: boolean, supports dual voltage cards ti,non-removable: non-removable slot (like eMMC) ti,needs-special-reset: Requires a special softreset sequence ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed +dmas: List of DMA specifiers with the controller specific format +as described in the generic DMA client binding. A tx and rx +specifier is required. +dma-names: List of DMA request names. These strings correspond +1:1 with the DMA specifiers listed in dmas. The string naming is +to be "rx" and "tx" for RX and TX DMA requests, respectively. + +Examples: + +[hwmod populated DMA resources] + + mmc1: mmc@0x4809c000 { + compatible = "ti,omap4-hsmmc"; + reg = <0x4809c000 0x400>; + ti,hwmods = "mmc1"; + ti,dual-volt; + bus-width = <4>; + vmmc-supply = <&vmmc>; /* phandle to regulator node */ + ti,non-removable; + }; + +[generic DMA request binding] -Example: mmc1: mmc@0x4809c000 { compatible = "ti,omap4-hsmmc"; reg = <0x4809c000 0x400>; @@ -30,4 +51,7 @@ Example: bus-width = <4>; vmmc-supply = <&vmmc>; /* phandle to regulator node */ ti,non-removable; + dmas = <&edma 24 + &edma 25>; + dma-names = "tx", "rx"; }; diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index df338cb5059..5e1f31b5ff7 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -22,10 +22,10 @@ Optional properties: width of 8 is assumed. - ti,nand-ecc-opt: A string setting the ECC layout to use. One of: - - "sw" Software method (default) - "hw" Hardware method - "hw-romcode" gpmc hamming mode method & romcode layout + "sw" <deprecated> use "ham1" instead + "hw" <deprecated> use "ham1" instead + "hw-romcode" <deprecated> use "ham1" instead + "ham1" 1-bit Hamming ecc code "bch4" 4-bit BCH ecc code "bch8" 8-bit BCH ecc code @@ -36,8 +36,12 @@ Optional properties: "prefetch-dma" Prefetch enabled sDMA mode "prefetch-irq" Prefetch enabled irq mode - - elm_id: Specifies elm device node. This is required to support BCH - error correction using ELM module. + - elm_id: <deprecated> use "ti,elm-id" instead + - ti,elm-id: Specifies phandle of the ELM devicetree node. + ELM is an on-chip hardware engine on TI SoC which is used for + locating ECC errors for BCHx algorithms. SoC devices which have + ELM hardware engines should specify this device node in .dtsi + Using ELM for ECC error correction frees some CPU cycles. For inline partiton table parsing (optional): diff --git a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt new file mode 100644 index 00000000000..7ff57a119f8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt @@ -0,0 +1,28 @@ +TI CPSW Phy mode Selection Device Tree Bindings +----------------------------------------------- + +Required properties: +- compatible : Should be "ti,am3352-cpsw-phy-sel" +- reg : physical base address and size of the cpsw + registers map +- reg-names : names of the register map given in "reg" node + +Optional properties: +-rmii-clock-ext : If present, the driver will configure the RMII + interface to external clock usage + +Examples: + + phy_sel: cpsw-phy-sel@44e10650 { + compatible = "ti,am3352-cpsw-phy-sel"; + reg= <0x44e10650 0x4>; + reg-names = "gmii-sel"; + }; + +(or) + phy_sel: cpsw-phy-sel@44e10650 { + compatible = "ti,am3352-cpsw-phy-sel"; + reg= <0x44e10650 0x4>; + reg-names = "gmii-sel"; + rmii-clock-ext; + }; diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index e216af35684..d5d26d44369 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -3,7 +3,7 @@ Required properties: - compatible: should contain "snps,dw-pcie" to identify the core, plus an identifier for the specific instance, such - as "samsung,exynos5440-pcie". + as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie". - reg: base addresses and lengths of the pcie controller, the phy controller, additional register for the phy controller. - interrupts: interrupt values for level interrupt, @@ -21,6 +21,11 @@ Required properties: - num-lanes: number of lanes to use - reset-gpio: gpio pin number of power good signal +Optional properties for fsl,imx6q-pcie +- power-on-gpio: gpio pin number of power-enable signal +- wake-up-gpio: gpio pin number of incoming wakeup signal +- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal + Example: SoC specific DT Entry: diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt index 9556e2fedf6..08c716b2c6b 100644 --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt @@ -5,6 +5,7 @@ Mandatory properties: - compatible: one of the following values: marvell,armada-370-pcie marvell,armada-xp-pcie + marvell,dove-pcie marvell,kirkwood-pcie - #address-cells, set to <3> - #size-cells, set to <2> @@ -14,6 +15,8 @@ Mandatory properties: - ranges: ranges describing the MMIO registers to control the PCIe interfaces, and ranges describing the MBus windows needed to access the memory and I/O regions of each PCIe interface. +- msi-parent: Link to the hardware entity that serves as the Message + Signaled Interrupt controller for this PCI controller. The ranges describing the MMIO registers have the following layout: @@ -74,6 +77,8 @@ and the following optional properties: - marvell,pcie-lane: the physical PCIe lane number, for ports having multiple lanes. If this property is not found, we assume that the value is 0. +- reset-gpios: optional gpio to PERST# +- reset-delay-us: delay in us to wait after reset de-assertion Example: @@ -86,6 +91,7 @@ pcie-controller { #size-cells = <2>; bus-range = <0x00 0xff>; + msi-parent = <&mpic>; ranges = <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */ @@ -135,6 +141,10 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 58>; marvell,pcie-port = <0>; marvell,pcie-lane = <0>; + /* low-active PERST# reset on GPIO 25 */ + reset-gpios = <&gpio0 25 1>; + /* wait 20ms for device settle after reset deassertion */ + reset-delay-us = <20000>; clocks = <&gateclk 5>; status = "disabled"; }; diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt new file mode 100644 index 00000000000..8ae844fc0c6 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt @@ -0,0 +1,66 @@ +This document explains only the device tree data binding. For general +information about PHY subsystem refer to Documentation/phy.txt + +PHY device node +=============== + +Required Properties: +#phy-cells: Number of cells in a PHY specifier; The meaning of all those + cells is defined by the binding for the phy node. The PHY + provider can use the values in cells to find the appropriate + PHY. + +For example: + +phys: phy { + compatible = "xxx"; + reg = <...>; + . + . + #phy-cells = <1>; + . + . +}; + +That node describes an IP block (PHY provider) that implements 2 different PHYs. +In order to differentiate between these 2 PHYs, an additonal specifier should be +given while trying to get a reference to it. + +PHY user node +============= + +Required Properties: +phys : the phandle for the PHY device (used by the PHY subsystem) +phy-names : the names of the PHY corresponding to the PHYs present in the + *phys* phandle + +Example 1: +usb1: usb_otg_ss@xxx { + compatible = "xxx"; + reg = <xxx>; + . + . + phys = <&usb2_phy>, <&usb3_phy>; + phy-names = "usb2phy", "usb3phy"; + . + . +}; + +This node represents a controller that uses two PHYs, one for usb2 and one for +usb3. + +Example 2: +usb2: usb_otg_ss@xxx { + compatible = "xxx"; + reg = <xxx>; + . + . + phys = <&phys 1>; + phy-names = "usbphy"; + . + . +}; + +This node represents a controller that uses one of the PHYs of the PHY provider +device defined previously. Note that the phy handle has an additional specifier +"1" to differentiate between the two PHYs. diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt new file mode 100644 index 00000000000..c0fccaa1671 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -0,0 +1,22 @@ +Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY +------------------------------------------------- + +Required properties: +- compatible : should be "samsung,s5pv210-mipi-video-phy"; +- reg : offset and length of the MIPI DPHY register set; +- #phy-cells : from the generic phy bindings, must be 1; + +For "samsung,s5pv210-mipi-video-phy" compatible PHYs the second cell in +the PHY specifier identifies the PHY and its meaning is as follows: + 0 - MIPI CSIS 0, + 1 - MIPI DSIM 0, + 2 - MIPI CSIS 1, + 3 - MIPI DSIM 1. + +Samsung EXYNOS SoC series Display Port PHY +------------------------------------------------- + +Required properties: +- compatible : should be "samsung,exynos5250-dp-video-phy"; +- reg : offset and length of the Display Port PHY register set; +- #phy-cells : from the generic PHY bindings, must be 0; diff --git a/Documentation/devicetree/bindings/pinctrl/abilis,tb10x-iomux.txt b/Documentation/devicetree/bindings/pinctrl/abilis,tb10x-iomux.txt new file mode 100644 index 00000000000..2c11866221c --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/abilis,tb10x-iomux.txt @@ -0,0 +1,80 @@ +Abilis Systems TB10x pin controller +=================================== + +Required properties +------------------- + +- compatible: should be "abilis,tb10x-iomux"; +- reg: should contain the physical address and size of the pin controller's + register range. + + +Function definitions +-------------------- + +Functions are defined (and referenced) by sub-nodes of the pin controller. +Every sub-node defines exactly one function (implying a set of pins). +Every function is associated to one named pin group inside the pin controller +driver and these names are used to associate pin group predefinitions to pin +controller sub-nodes. + +Required function definition subnode properties: + - abilis,function: should be set to the name of the function's pin group. + +The following pin groups are available: + - GPIO ports: gpioa, gpiob, gpioc, gpiod, gpioe, gpiof, gpiog, + gpioh, gpioi, gpioj, gpiok, gpiol, gpiom, gpion + - Serial TS input ports: mis0, mis1, mis2, mis3, mis4, mis5, mis6, mis7 + - Parallel TS input ports: mip1, mip3, mip5, mip7 + - Serial TS output ports: mos0, mos1, mos2, mos3 + - Parallel TS output port: mop + - CI+ port: ciplus + - CableCard (Mcard) port: mcard + - Smart card ports: stc0, stc1 + - UART ports: uart0, uart1 + - SPI ports: spi1, spi3 + - JTAG: jtag + +All other ports of the chip are not multiplexed and thus not managed by this +driver. + + +GPIO ranges definition +---------------------- + +The named pin groups of GPIO ports can be used to define GPIO ranges as +explained in Documentation/devicetree/bindings/gpio/gpio.txt. + + +Example +------- + +iomux: iomux@FF10601c { + compatible = "abilis,tb10x-iomux"; + reg = <0xFF10601c 0x4>; + pctl_gpio_a: pctl-gpio-a { + abilis,function = "gpioa"; + }; + pctl_uart0: pctl-uart0 { + abilis,function = "uart0"; + }; +}; +uart@FF100000 { + compatible = "snps,dw-apb-uart"; + reg = <0xFF100000 0x100>; + clock-frequency = <166666666>; + interrupts = <25 1>; + reg-shift = <2>; + reg-io-width = <4>; + pinctrl-names = "default"; + pinctrl-0 = <&pctl_uart0>; +}; +gpioa: gpio@FF140000 { + compatible = "abilis,tb10x-gpio"; + reg = <0xFF140000 0x1000>; + gpio-controller; + #gpio-cells = <2>; + ngpio = <3>; + gpio-ranges = <&iomux 0 0>; + gpio-ranges-group-names = "gpioa"; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt index 7ccae490ff6..02ab5ab198a 100644 --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt @@ -18,7 +18,7 @@ mode) this pin can work on and the 'config' configures various pad settings such as pull-up, multi drive, etc. Required properties for iomux controller: -- compatible: "atmel,at91rm9200-pinctrl" +- compatible: "atmel,at91rm9200-pinctrl" or "atmel,at91sam9x5-pinctrl" - atmel,mux-mask: array of mask (periph per bank) to describe if a pin can be configured in this periph mode. All the periph and bank need to be describe. diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt index 3a7caf7a744..9fde25f1401 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt @@ -22,11 +22,12 @@ Required properties for iomux controller: 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, which consists of a tuple of - <mux_reg conf_reg input_reg mux_val input_val>. CONFIG is the pad setting - value like pull-up on this pin. +- fsl,pins: each entry consists of 6 integers and represents the mux and config + setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val + input_val> are specified using a PIN_FUNC_ID macro, which can be found in + imx*-pinfunc.h under device tree source folder. The last integer CONFIG is + the pad setting value like pull-up on this pin. And that's why fsl,pins entry + looks like <PIN_FUNC_ID CONFIG> in the example below. Bits used for CONFIG: NO_PAD_CTL(1 << 31): indicate this pin does not need config. @@ -72,17 +73,18 @@ iomuxc@020e0000 { /* 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 */ - }; + fsl,pins = < + MX6QDL_PAD_SD4_CMD__SD4_CMD 0x17059 + MX6QDL_PAD_SD4_CLK__SD4_CLK 0x10059 + MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059 + MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059 + MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059 + MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059 + MX6QDL_PAD_SD4_DAT4__SD4_DATA4 0x17059 + MX6QDL_PAD_SD4_DAT5__SD4_DATA5 0x17059 + MX6QDL_PAD_SD4_DAT6__SD4_DATA6 0x17059 + MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059 + >; }; .... }; @@ -90,6 +92,3 @@ 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,imx27-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt new file mode 100644 index 00000000000..353eca0efbf --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt @@ -0,0 +1,99 @@ +* Freescale IMX27 IOMUX Controller + +Required properties: +- compatible: "fsl,imx27-iomuxc" + +The iomuxc driver node should define subnodes containing of pinctrl configuration subnodes. + +Required properties for pin configuration node: +- fsl,pins: three integers array, represents a group of pins mux and config + setting. The format is fsl,pins = <PIN MUX_ID CONFIG>. + + PIN is an integer between 0 and 0xbf. imx27 has 6 ports with 32 configurable + configurable pins each. PIN is PORT * 32 + PORT_PIN, PORT_PIN is the pin + number on the specific port (between 0 and 31). + + MUX_ID is + function + (direction << 2) + (gpio_oconf << 4) + (gpio_iconfa << 8) + (gpio_iconfb << 10) + + function value is used to select the pin function. + Possible values: + 0 - Primary function + 1 - Alternate function + 2 - GPIO + Registers: GIUS (GPIO In Use), GPR (General Purpose Register) + + direction defines the data direction of the pin. + Possible values: + 0 - Input + 1 - Output + Register: DDIR + + gpio_oconf configures the gpio submodule output signal. This does not + have any effect unless GPIO function is selected. A/B/C_IN are output + signals of function blocks A,B and C. Specific function blocks are + described in the reference manual. + Possible values: + 0 - A_IN + 1 - B_IN + 2 - C_IN + 3 - Data Register + Registers: OCR1, OCR2 + + gpio_iconfa/b configures the gpio submodule input to functionblocks A and + B. GPIO function should be selected if this is configured. + Possible values: + 0 - GPIO_IN + 1 - Interrupt Status Register + 2 - Pulldown + 3 - Pullup + Registers ICONFA1, ICONFA2, ICONFB1 and ICONFB2 + + CONFIG can be 0 or 1, meaning Pullup disable/enable. + + + +Example: + +iomuxc: iomuxc@10015000 { + compatible = "fsl,imx27-iomuxc"; + reg = <0x10015000 0x600>; + + uart { + pinctrl_uart1: uart-1 { + fsl,pins = < + 0x8c 0x004 0x0 /* UART1_TXD__UART1_TXD */ + 0x8d 0x000 0x0 /* UART1_RXD__UART1_RXD */ + 0x8e 0x004 0x0 /* UART1_CTS__UART1_CTS */ + 0x8f 0x000 0x0 /* UART1_RTS__UART1_RTS */ + >; + }; + + ... + }; +}; + + +For convenience there are macros defined in imx27-pinfunc.h which provide PIN +and MUX_ID. They are structured as MX27_PAD_<Pad name>__<Signal name>. The names +are defined in the i.MX27 reference manual. + +The above example using macros: + +iomuxc: iomuxc@10015000 { + compatible = "fsl,imx27-iomuxc"; + reg = <0x10015000 0x600>; + + uart { + pinctrl_uart1: uart-1 { + fsl,pins = < + MX27_PAD_UART1_TXD__UART1_TXD 0x0 + MX27_PAD_UART1_RXD__UART1_RXD 0x0 + MX27_PAD_UART1_CTS__UART1_CTS 0x0 + MX27_PAD_UART1_RTS__UART1_RTS 0x0 + >; + }; + + ... + }; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt index 3077370c89a..1e70a8aff26 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt @@ -59,16 +59,16 @@ Required subnode-properties: Optional subnode-properties: - fsl,drive-strength: Integer. - 0: 4 mA - 1: 8 mA - 2: 12 mA - 3: 16 mA + 0: MXS_DRIVE_4mA + 1: MXS_DRIVE_8mA + 2: MXS_DRIVE_12mA + 3: MXS_DRIVE_16mA - fsl,voltage: Integer. - 0: 1.8 V - 1: 3.3 V + 0: MXS_VOLTAGE_LOW - 1.8 V + 1: MXS_VOLTAGE_HIGH - 3.3 V - fsl,pull-up: Integer. - 0: Disable the internal pull-up - 1: Enable the internal pull-up + 0: MXS_PULL_DISABLE - Disable the internal pull-up + 1: MXS_PULL_ENABLE - Enable the internal pull-up Note that when enabling the pull-up, the internal pad keeper gets disabled. Also, some pins doesn't have a pull up, in that case, setting the fsl,pull-up @@ -85,23 +85,32 @@ pinctrl@80018000 { 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>; + MX28_PAD_SSP0_DATA0__SSP0_D0 + MX28_PAD_SSP0_DATA1__SSP0_D1 + MX28_PAD_SSP0_DATA2__SSP0_D2 + MX28_PAD_SSP0_DATA3__SSP0_D3 + MX28_PAD_SSP0_DATA4__SSP0_D4 + MX28_PAD_SSP0_DATA5__SSP0_D5 + MX28_PAD_SSP0_DATA6__SSP0_D6 + MX28_PAD_SSP0_DATA7__SSP0_D7 + MX28_PAD_SSP0_CMD__SSP0_CMD + MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT + MX28_PAD_SSP0_SCK__SSP0_SCK + >; + fsl,drive-strength = <MXS_DRIVE_4mA>; + fsl,voltage = <MXS_VOLTAGE_HIGH>; + fsl,pull-up = <MXS_PULL_ENABLE>; }; mmc_cd_cfg: mmc-cd-cfg { - fsl,pinmux-ids = <0x2090>; - fsl,pull-up = <0>; + fsl,pinmux-ids = <MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT>; + fsl,pull-up = <MXS_PULL_DISABLE>; }; mmc_sck_cfg: mmc-sck-cfg { - fsl,pinmux-ids = <0x20a0>; - fsl,drive-strength = <2>; - fsl,pull-up = <0>; + fsl,pinmux-ids = <MX28_PAD_SSP0_SCK__SSP0_SCK>; + fsl,drive-strength = <MXS_DRIVE_12mA>; + fsl,pull-up = <MXS_PULL_DISABLE>; }; }; @@ -112,811 +121,7 @@ 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 +Valid values for i.MX28/i.MX23 pinmux-id are defined in +arch/arm/boot/dts/imx28-pinfunc.h and arch/arm/boot/dts/imx23-pinfunc.h. +The definitions for the padconfig properties can be found in +arch/arm/boot/dts/mxs-pinfunc.h. diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt index 734d9b04d53..caf297bee1f 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt @@ -41,7 +41,7 @@ pinctrl-bindings.txt: Required: pins Options: function, bias-disable, bias-pull-up, bias-pull-down, - bias-pin-default, drive-open-drain. + drive-open-drain. Note that many of these properties are only valid for certain specific pins. See the Palmas device datasheet for complete details regarding which pins diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt index 5a02e30dd26..7069a0b84e3 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt @@ -72,6 +72,13 @@ Optional properties: /* pin base, nr pins & gpio function */ pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>; +- interrupt-controller : standard interrupt controller binding if using + interrupts for wake-up events for example. In this case pinctrl-single + is set up as a chained interrupt controller and the wake-up interrupts + can be requested by the drivers using request_irq(). + +- #interrupt-cells : standard interrupt binding if using interrupts + This driver assumes that there is only one register for each pin (unless the pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as specified in the pinctrl-bindings.txt document in this directory. @@ -121,6 +128,8 @@ pmx_core: pinmux@4a100040 { reg = <0x4a100040 0x0196>; #address-cells = <1>; #size-cells = <0>; + #interrupt-cells = <1>; + interrupt-controller; pinctrl-single,register-width = <16>; pinctrl-single,function-mask = <0xffff>; }; @@ -131,6 +140,8 @@ pmx_wkup: pinmux@4a31e040 { reg = <0x4a31e040 0x0038>; #address-cells = <1>; #size-cells = <0>; + #interrupt-cells = <1>; + interrupt-controller; pinctrl-single,register-width = <16>; pinctrl-single,function-mask = <0xffff>; }; diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt index b0fb1018d7a..f378d342aae 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt @@ -21,10 +21,13 @@ defined as gpio sub-nodes of the pinmux controller. Required properties for iomux controller: - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl" "rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl" + - reg: first element is the general register space of the iomux controller + second element is the separate pull register space of the rk3188 Required properties for gpio sub nodes: - - compatible: "rockchip,gpio-bank" + - compatible: "rockchip,gpio-bank", "rockchip,rk3188-gpio-bank0" - reg: register of the gpio bank (different than the iomux registerset) + second element: separate pull register for rk3188 bank0 - interrupts: base interrupt of the gpio bank in the interrupt controller - clocks: clock that drives this bank - gpio-controller: identifies the node as a gpio controller and pin bank. @@ -95,3 +98,44 @@ uart2: serial@20064000 { pinctrl-names = "default"; pinctrl-0 = <&uart2_xfer>; }; + +Example for rk3188: + + pinctrl@20008000 { + compatible = "rockchip,rk3188-pinctrl"; + reg = <0x20008000 0xa0>, + <0x20008164 0x1a0>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + gpio0: gpio0@0x2000a000 { + compatible = "rockchip,rk3188-gpio-bank0"; + reg = <0x2000a000 0x100>, + <0x20004064 0x8>; + interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk_gates8 9>; + + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio1: gpio1@0x2003c000 { + compatible = "rockchip,gpio-bank"; + reg = <0x2003c000 0x100>; + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk_gates8 10>; + + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + ... + + }; diff --git a/Documentation/devicetree/bindings/regulator/as3722-regulator.txt b/Documentation/devicetree/bindings/regulator/as3722-regulator.txt new file mode 100644 index 00000000000..caad0c8a258 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/as3722-regulator.txt @@ -0,0 +1,91 @@ +Regulator of AMS AS3722 PMIC. +Name of the regulator subnode must be "regulators". + +Optional properties: +-------------------- +The input supply of regulators are the optional properties on the +regulator node. The AS3722 is having 7 DCDC step-down regulators as +sd[0-6], 10 LDOs as ldo[0-7], ldo[9-11]. The input supply of these +regulators are provided through following properties: +vsup-sd2-supply: Input supply for SD2. +vsup-sd3-supply: Input supply for SD3. +vsup-sd4-supply: Input supply for SD4. +vsup-sd5-supply: Input supply for SD5. +vin-ldo0-supply: Input supply for LDO0. +vin-ldo1-6-supply: Input supply for LDO1 and LDO6. +vin-ldo2-5-7-supply: Input supply for LDO2, LDO5 and LDO7. +vin-ldo3-4-supply: Input supply for LDO3 and LDO4. +vin-ldo9-10-supply: Input supply for LDO9 and LDO10. +vin-ldo11-supply: Input supply for LDO11. + +Optional nodes: +-------------- +- regulators : Must contain a sub-node per regulator from the list below. + Each sub-node should contain the constraints and initialization + information for that regulator. See regulator.txt for a + description of standard properties for these sub-nodes. + Additional custom properties are listed below. + sd[0-6], ldo[0-7], ldo[9-11]. + + Optional sub-node properties: + ---------------------------- + ams,ext-control: External control of the rail. The option of + this properties will tell which external input is + controlling this rail. Valid values are 0, 1, 2 ad 3. + 0: There is no external control of this rail. + 1: Rail is controlled by ENABLE1 input pin. + 2: Rail is controlled by ENABLE2 input pin. + 3: Rail is controlled by ENABLE3 input pin. + ams,enable-tracking: Enable tracking with SD1, only supported + by LDO3. + +Example: +------- + ams3722: ams3722 { + compatible = "ams,as3722"; + reg = <0x40>; + ... + + regulators { + vsup-sd2-supply = <...>; + ... + + sd0 { + regulator-name = "vdd_cpu"; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <1400000>; + regulator-always-on; + ams,ext-control = <2>; + }; + + sd1 { + regulator-name = "vdd_core"; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <1400000>; + regulator-always-on; + ams,ext-control = <1>; + }; + + sd2 { + regulator-name = "vddio_ddr"; + regulator-min-microvolt = <1350000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + }; + + sd4 { + regulator-name = "avdd-hdmi-pex"; + regulator-min-microvolt = <1050000>; + regulator-max-microvolt = <1050000>; + regulator-always-on; + }; + + sd5 { + regulator-name = "vdd-1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + }; + .... + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/da9210.txt b/Documentation/devicetree/bindings/regulator/da9210.txt new file mode 100644 index 00000000000..f120f229d67 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/da9210.txt @@ -0,0 +1,21 @@ +* Dialog Semiconductor DA9210 Voltage Regulator + +Required properties: + +- compatible: must be "diasemi,da9210" +- reg: the i2c slave address of the regulator. It should be 0x68. + +Any standard regulator properties can be used to configure the single da9210 +DCDC. + +Example: + + da9210@68 { + compatible = "diasemi,da9210"; + reg = <0x68>; + + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <1000000>; + regulator-boot-on; + regulator-always-on; + }; diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index 875639ae060..42e6b6bc48f 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -26,11 +26,17 @@ Optional nodes: For ti,palmas-pmic - smps12, smps123, smps3 depending on OTP, smps45, smps457, smps7 depending on variant, smps6, smps[8-9], - smps10_out2, smps10_out1, do[1-9], ldoln, ldousb. + smps10_out2, smps10_out1, ldo[1-9], ldoln, ldousb. Optional sub-node properties: ti,warm-reset - maintain voltage during warm reset(boolean) - ti,roof-floor - control voltage selection by pin(boolean) + ti,roof-floor - This takes as optional argument on platform supporting + the rail from desired external control. If there is no argument then + it will be assume that it is controlled by NSLEEP pin. + The valid value for external pins are: + ENABLE1 then 1, + ENABLE2 then 2 or + NSLEEP then 3. ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto, 2 - eco, 3 - forced pwm ti,smps-range - OTP has the wrong range set for the hardware so override @@ -61,7 +67,7 @@ pmic { regulator-always-on; regulator-boot-on; ti,warm-reset; - ti,roof-floor; + ti,roof-floor = <1>; /* ENABLE1 control */ ti,mode-sleep = <0>; ti,smps-range = <1>; }; diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index 2bd8f097876..e2c7f1e7251 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -14,6 +14,11 @@ Optional properties: - regulator-ramp-delay: ramp delay for regulator(in uV/uS) For hardwares which support disabling ramp rate, it should be explicitly intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay. +- regulator-enable-ramp-delay: The time taken, in microseconds, for the supply + rail to reach the target voltage, plus/minus whatever tolerance the board + design requires. This property describes the total system ramp time + required due to the combination of internal ramping of the regulator itself, + and board design issues such as trace capacitance and load on the supply. Deprecated properties: - regulator-compatible: If a regulator chip contains multiple diff --git a/Documentation/devicetree/bindings/sound/cs42l73.txt b/Documentation/devicetree/bindings/sound/cs42l73.txt new file mode 100644 index 00000000000..80ae910dbf6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cs42l73.txt @@ -0,0 +1,22 @@ +CS42L73 audio CODEC + +Required properties: + + - compatible : "cirrus,cs42l73" + + - reg : the I2C address of the device for I2C + +Optional properties: + + - reset_gpio : a GPIO spec for the reset pin. + - chgfreq : Charge Pump Frequency values 0x00-0x0F + + +Example: + +codec: cs42l73@4a { + compatible = "cirrus,cs42l73"; + reg = <0x4a>; + reset_gpio = <&gpio 10 0>; + chgfreq = <0x05>; +};
\ No newline at end of file diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt new file mode 100644 index 00000000000..865178d5cdf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt @@ -0,0 +1,42 @@ +* Texas Instruments SoC audio setups with TLV320AIC3X Codec + +Required properties: +- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx +- ti,model : The user-visible name of this sound complex. +- ti,audio-codec : The phandle of the TLV320AIC3x audio codec +- ti,mcasp-controller : The phandle of the McASP controller +- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec +- ti,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 codec's pins, and the jacks on the board: + + Board connectors: + + * Headphone Jack + * Line Out + * Mic Jack + * Line In + + +Example: + +sound { + compatible = "ti,da830-evm-audio"; + ti,model = "DA830 EVM"; + ti,audio-codec = <&tlv320aic3x>; + ti,mcasp-controller = <&mcasp1>; + ti,codec-clock-rate = <12000000>; + ti,audio-routing = + "Headphone Jack", "HPLOUT", + "Headphone Jack", "HPROUT", + "Line Out", "LLOUT", + "Line Out", "RLOUT", + "MIC3L", "Mic Bias 2V", + "MIC3R", "Mic Bias 2V", + "Mic Bias 2V", "Mic Jack", + "LINE1L", "Line In", + "LINE2L", "Line In", + "LINE1R", "Line In", + "LINE2R", "Line In"; +}; diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt index 374e145c2ef..ed785b3f67b 100644 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt @@ -4,17 +4,25 @@ Required properties: - compatible : "ti,dm646x-mcasp-audio" : for DM646x platforms "ti,da830-mcasp-audio" : for both DA830 & DA850 platforms - "ti,omap2-mcasp-audio" : for OMAP2 platforms (TI81xx, AM33xx) - -- reg : Should contain McASP registers offset and length -- interrupts : Interrupt number for McASP -- op-mode : I2S/DIT ops mode. -- tdm-slots : Slots for TDM operation. -- num-serializer : Serializers used by McASP. -- serial-dir : A list of serializer pin mode. The list number should be equal - to "num-serializer" parameter. Each entry is a number indication - serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX) + "ti,am33xx-mcasp-audio" : for AM33xx platforms (AM33xx, TI81xx) +- reg : Should contain reg specifiers for the entries in the reg-names property. +- reg-names : Should contain: + * "mpu" for the main registers (required). For compatibility with + existing software, it is recommended this is the first entry. + * "dat" for separate data port register access (optional). +- op-mode : I2S/DIT ops mode. 0 for I2S mode. 1 for DIT mode used for S/PDIF, + IEC60958-1, and AES-3 formats. +- tdm-slots : Slots for TDM operation. Indicates number of channels transmitted + or received over one serializer. +- serial-dir : A list of serializer configuration. Each entry is a number + indication for serializer pin direction. + (0 - INACTIVE, 1 - TX, 2 - RX) +- dmas: two element list of DMA controller phandles and DMA request line + ordered pairs. +- dma-names: identifier string for each DMA request line in the dmas property. + These strings correspond 1:1 with the ordered pairs in dmas. The dma + identifiers must be "rx" and "tx". Optional properties: @@ -23,18 +31,23 @@ Optional properties: - rx-num-evt : FIFO levels. - sram-size-playback : size of sram to be allocated during playback - sram-size-capture : size of sram to be allocated during capture +- interrupts : Interrupt numbers for McASP, currently not used by the driver +- interrupt-names : Known interrupt names are "tx" and "rx" +- pinctrl-0: Should specify pin control group used for this controller. +- pinctrl-names: Should contain only one value - "default", for more details + please refer to pinctrl-bindings.txt + Example: mcasp0: mcasp0@1d00000 { compatible = "ti,da830-mcasp-audio"; - #address-cells = <1>; - #size-cells = <0>; reg = <0x100000 0x3000>; - interrupts = <82 83>; + reg-names "mpu"; + interrupts = <82>, <83>; + interrupts-names = "tx", "rx"; op-mode = <0>; /* MCASP_IIS_MODE */ tdm-slots = <2>; - num-serializer = <16>; serial-dir = < 0 0 0 0 /* 0: INACTIVE, 1: TX, 2: RX */ 0 0 0 0 diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt index 705a6b156c6..5e6040c2c2e 100644 --- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt +++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt @@ -24,10 +24,36 @@ Optional properties: 3 - MICBIAS output is connected to AVDD, If this node is not mentioned or if the value is incorrect, then MicBias is powered down. +- AVDD-supply, IOVDD-supply, DRVDD-supply, DVDD-supply : power supplies for the + device as covered in Documentation/devicetree/bindings/regulator/regulator.txt + +CODEC output pins: + * LLOUT + * RLOUT + * MONO_LOUT + * HPLOUT + * HPROUT + * HPLCOM + * HPRCOM + +CODEC input pins: + * MIC3L + * MIC3R + * LINE1L + * LINE2L + * LINE1R + * LINE2R + +The pins can be used in referring sound node's audio-routing property. Example: tlv320aic3x: tlv320aic3x@1b { compatible = "ti,tlv320aic3x"; reg = <0x1b>; + + AVDD-supply = <®ulator>; + IOVDD-supply = <®ulator>; + DRVDD-supply = <®ulator>; + DVDD-supply = <®ulator>; }; diff --git a/Documentation/devicetree/bindings/sound/tpa6130a2.txt b/Documentation/devicetree/bindings/sound/tpa6130a2.txt new file mode 100644 index 00000000000..6dfa740e4b2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tpa6130a2.txt @@ -0,0 +1,27 @@ +Texas Instruments - tpa6130a2 Codec module + +The tpa6130a2 serial control bus communicates through I2C protocols + +Required properties: + +- compatible - "string" - One of: + "ti,tpa6130a2" - TPA6130A2 + "ti,tpa6140a2" - TPA6140A2 + + +- reg - <int> - I2C slave address + +- Vdd-supply - <phandle> - power supply regulator + +Optional properties: + +- power-gpio - gpio pin to power the device + +Example: + +tpa6130a2: tpa6130a2@60 { + compatible = "ti,tpa6130a2"; + reg = <0x60>; + Vdd-supply = <&vmmc2>; + power-gpio = <&gpio4 2 GPIO_ACTIVE_HIGH>; +}; diff --git a/Documentation/devicetree/bindings/spi/sh-hspi.txt b/Documentation/devicetree/bindings/spi/sh-hspi.txt new file mode 100644 index 00000000000..30b57b1c8a1 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/sh-hspi.txt @@ -0,0 +1,7 @@ +Renesas HSPI. + +Required properties: +- compatible : "renesas,hspi" +- reg : Offset and length of the register set for the device +- interrupts : interrupt line used by HSPI + diff --git a/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt b/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt index 46882058b59..ee05dc39069 100644 --- a/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt +++ b/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt @@ -1,7 +1,8 @@ * Freescale i.MX28 LRADC device driver Required properties: -- compatible: Should be "fsl,imx28-lradc" +- compatible: Should be "fsl,imx23-lradc" for i.MX23 SoC and "fsl,imx28-lradc" + for i.MX28 SoC - reg: Address and length of the register set for the device - interrupts: Should contain the LRADC interrupts @@ -9,13 +10,38 @@ Optional properties: - fsl,lradc-touchscreen-wires: Number of wires used to connect the touchscreen to LRADC. Valid value is either 4 or 5. If this property is not present, then the touchscreen is - disabled. + disabled. 5 wires is valid for i.MX28 SoC only. +- fsl,ave-ctrl: number of samples per direction to calculate an average value. + Allowed value is 1 ... 31, default is 4 +- fsl,ave-delay: delay between consecutive samples. Allowed value is + 1 ... 2047. It is used if 'fsl,ave-ctrl' > 1, counts at + 2 kHz and its default is 2 (= 1 ms) +- fsl,settling: delay between plate switch to next sample. Allowed value is + 1 ... 2047. It counts at 2 kHz and its default is + 10 (= 5 ms) -Examples: +Example for i.MX23 SoC: + + lradc@80050000 { + compatible = "fsl,imx23-lradc"; + reg = <0x80050000 0x2000>; + interrupts = <36 37 38 39 40 41 42 43 44>; + status = "okay"; + fsl,lradc-touchscreen-wires = <4>; + fsl,ave-ctrl = <4>; + fsl,ave-delay = <2>; + fsl,settling = <10>; + }; + +Example for i.MX28 SoC: lradc@80050000 { compatible = "fsl,imx28-lradc"; reg = <0x80050000 0x2000>; - interrupts = <10 14 15 16 17 18 19 - 20 21 22 23 24 25>; + interrupts = <10 14 15 16 17 18 19 20 21 22 23 24 25>; + status = "okay"; + fsl,lradc-touchscreen-wires = <5>; + fsl,ave-ctrl = <4>; + fsl,ave-delay = <2>; + fsl,settling = <10>; }; diff --git a/Documentation/devicetree/bindings/timer/efm32,timer.txt b/Documentation/devicetree/bindings/timer/efm32,timer.txt new file mode 100644 index 00000000000..97a568f696c --- /dev/null +++ b/Documentation/devicetree/bindings/timer/efm32,timer.txt @@ -0,0 +1,23 @@ +* EFM32 timer hardware + +The efm32 Giant Gecko SoCs come with four 16 bit timers. Two counters can be +connected to form a 32 bit counter. Each timer has three Compare/Capture +channels and can be used as PWM or Quadrature Decoder. Available clock sources +are the cpu's HFPERCLK (with a 10-bit prescaler) or an external pin. + +Required properties: +- compatible : Should be efm32,timer +- reg : Address and length of the register set +- clocks : Should contain a reference to the HFPERCLK + +Optional properties: +- interrupts : Reference to the timer interrupt + +Example: + +timer@40010c00 { + compatible = "efm32,timer"; + reg = <0x40010c00 0x400>; + interrupts = <14>; + clocks = <&cmu clk_HFPERCLKTIMER3>; +}; diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt new file mode 100644 index 00000000000..5ea26c631e3 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt @@ -0,0 +1,17 @@ +MSM SoC HSUSB controllers + +EHCI + +Required properties: +- compatible: Should contain "qcom,ehci-host" +- regs: offset and length of the register set in the memory map +- usb-phy: phandle for the PHY device + +Example EHCI controller device node: + + ehci: ehci@f9a55000 { + compatible = "qcom,ehci-host"; + reg = <0xf9a55000 0x400>; + usb-phy = <&usb_otg>; + }; + diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt index 9088ab09e20..090e5e22bd2 100644 --- a/Documentation/devicetree/bindings/usb/omap-usb.txt +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt @@ -3,9 +3,6 @@ OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS OMAP MUSB GLUE - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb" - ti,hwmods : must be "usb_otg_hs" - - ti,has-mailbox : to specify that omap uses an external mailbox - (in control module) to communicate with the musb core during device connect - and disconnect. - multipoint : Should be "1" indicating the musb controller supports multipoint. This is a MUSB configuration-specific setting. - num-eps : Specifies the number of endpoints. This is also a @@ -19,6 +16,9 @@ OMAP MUSB GLUE - power : Should be "50". This signifies the controller can supply up to 100mA when operating in host mode. - usb-phy : the phandle for the PHY device + - phys : the phandle for the PHY device (used by generic PHY framework) + - phy-names : the names of the PHY corresponding to the PHYs present in the + *phy* phandle. Optional properties: - ctrl-module : phandle of the control module this glue uses to write to @@ -28,11 +28,12 @@ SOC specific device node entry usb_otg_hs: usb_otg_hs@4a0ab000 { compatible = "ti,omap4-musb"; ti,hwmods = "usb_otg_hs"; - ti,has-mailbox; multipoint = <1>; num-eps = <16>; ram-bits = <12>; ctrl-module = <&omap_control_usb>; + phys = <&usb2_phy>; + phy-names = "usb2-phy"; }; Board specific device node entry @@ -78,22 +79,22 @@ omap_dwc3 { OMAP CONTROL USB Required properties: - - compatible: Should be "ti,omap-control-usb" + - compatible: Should be one of + "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4. + "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register + e.g. USB2_PHY on OMAP5. + "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control + e.g. USB3 PHY and SATA PHY on OMAP5. + "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on + DRA7 platform. - reg : Address and length of the register set for the device. It contains - the address of "control_dev_conf" and "otghs_control" or "phy_power_usb" - depending upon omap4 or omap5. - - reg-names: The names of the register addresses corresponding to the registers - filled in "reg". - - ti,type: This is used to differentiate whether the control module has - usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to - notify events to the musb core and omap5 has usb3 phy power register to - power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3 - phy power. + the address of "otghs_control" for control-phy-otghs or "power" register + for other types. + - reg-names: should be "otghs_control" control-phy-otghs and "power" for + other types. omap_control_usb: omap-control-usb@4a002300 { - compatible = "ti,omap-control-usb"; - reg = <0x4a002300 0x4>, - <0x4a00233c 0x4>; - reg-names = "control_dev_conf", "otghs_control"; - ti,type = <1>; + compatible = "ti,control-phy-otghs"; + reg = <0x4a00233c 0x4>; + reg-names = "otghs_control"; }; diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt index d7e272671c7..1bd37faba05 100644 --- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt @@ -15,7 +15,7 @@ Optional properties: - vcc-supply: phandle to the regulator that provides RESET to the PHY. -- reset-supply: phandle to the regulator that provides power to the PHY. +- reset-gpios: Should specify the GPIO for reset. Example: @@ -25,10 +25,9 @@ Example: clocks = <&osc 0>; clock-names = "main_clk"; vcc-supply = <&hsusb1_vcc_regulator>; - reset-supply = <&hsusb1_reset_regulator>; + reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; }; hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator and expects that clock to be configured to 19.2MHz by the NOP PHY driver. -hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator -controls RESET. +hsusb1_vcc_regulator provides power to the PHY and GPIO 7 controls RESET. diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt index 61496f5cb09..c0245c88898 100644 --- a/Documentation/devicetree/bindings/usb/usb-phy.txt +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt @@ -5,6 +5,8 @@ OMAP USB2 PHY Required properties: - compatible: Should be "ti,omap-usb2" - reg : Address and length of the register set for the device. + - #phy-cells: determine the number of cells that should be given in the + phandle while referencing this phy. Optional properties: - ctrl-module : phandle of the control module used by PHY driver to power on @@ -16,6 +18,7 @@ usb2phy@4a0ad080 { compatible = "ti,omap-usb2"; reg = <0x4a0ad080 0x58>; ctrl-module = <&omap_control_usb>; + #phy-cells = <0>; }; OMAP USB3 PHY @@ -25,6 +28,8 @@ Required properties: - reg : Address and length of the register set for the device. - reg-names: The names of the register addresses corresponding to the registers filled in "reg". + - #phy-cells: determine the number of cells that should be given in the + phandle while referencing this phy. Optional properties: - ctrl-module : phandle of the control module used by PHY driver to power on @@ -39,4 +44,5 @@ usb3phy@4a084400 { <0x4a084c00 0x40>; reg-names = "phy_rx", "phy_tx", "pll_ctrl"; ctrl-module = <&omap_control_usb>; + #phy-cells = <0>; }; diff --git a/Documentation/devicetree/bindings/usb/ux500-usb.txt b/Documentation/devicetree/bindings/usb/ux500-usb.txt index 330d6ec1540..439a41c79af 100644 --- a/Documentation/devicetree/bindings/usb/ux500-usb.txt +++ b/Documentation/devicetree/bindings/usb/ux500-usb.txt @@ -15,7 +15,7 @@ Optional properties: Example: usb_per5@a03e0000 { - compatible = "stericsson,db8500-musb", "mentor,musb"; + compatible = "stericsson,db8500-musb"; reg = <0xa03e0000 0x10000>; interrupts = <0 23 0x4>; interrupt-names = "mc"; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 2956800f024..ce95ed1c6d3 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -12,11 +12,15 @@ amcc Applied Micro Circuits Corporation (APM, formally AMCC) apm Applied Micro Circuits Corporation (APM) arm ARM Ltd. atmel Atmel Corporation +auo AU Optronics Corporation avago Avago Technologies bosch Bosch Sensortec GmbH brcm Broadcom Corporation +capella Capella Microsystems, Inc cavium Cavium, Inc. +cdns Cadence Design Systems Inc. chrp Common Hardware Reference Platform +chunghwa Chunghwa Picture Tubes Ltd. cirrus Cirrus Logic, Inc. cortina Cortina Systems, Inc. dallas Maxim Integrated Products (formerly Dallas Semiconductor) @@ -45,6 +49,8 @@ nintendo Nintendo nvidia NVIDIA nxp NXP Semiconductors onnn ON Semiconductor Corp. +panasonic Panasonic Corporation +phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd powervr PowerVR (deprecated, use img) qca Qualcomm Atheros, Inc. @@ -64,12 +70,12 @@ snps Synopsys, Inc. st STMicroelectronics ste ST-Ericsson stericsson ST-Ericsson -toumaz Toumaz ti Texas Instruments toshiba Toshiba Corporation +toumaz Toumaz v3 V3 Semiconductor via VIA Technologies, Inc. +winbond Winbond Electronics corp. wlf Wolfson Microelectronics wm Wondermedia Technologies, Inc. -winbond Winbond Electronics corp. xlnx Xilinx diff --git a/Documentation/devicetree/bindings/video/backlight/lp855x.txt b/Documentation/devicetree/bindings/video/backlight/lp855x.txt index 1482103d288..96e83a56048 100644 --- a/Documentation/devicetree/bindings/video/backlight/lp855x.txt +++ b/Documentation/devicetree/bindings/video/backlight/lp855x.txt @@ -2,7 +2,7 @@ lp855x bindings Required properties: - compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553", - "ti,lp8556", "ti,lp8557" + "ti,lp8555", "ti,lp8556", "ti,lp8557" - reg: I2C slave address (u8) - dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device. @@ -15,6 +15,33 @@ Optional properties: Example: + /* LP8555 */ + backlight@2c { + compatible = "ti,lp8555"; + reg = <0x2c>; + + dev-ctrl = /bits/ 8 <0x00>; + pwm-period = <10000>; + + /* 4V OV, 4 output LED0 string enabled */ + rom_14h { + rom-addr = /bits/ 8 <0x14>; + rom-val = /bits/ 8 <0xcf>; + }; + + /* Heavy smoothing, 24ms ramp time step */ + rom_15h { + rom-addr = /bits/ 8 <0x15>; + rom-val = /bits/ 8 <0xc7>; + }; + + /* 4 output LED1 string enabled */ + rom_19h { + rom-addr = /bits/ 8 <0x19>; + rom-val = /bits/ 8 <0x0f>; + }; + }; + /* LP8556 */ backlight@2c { compatible = "ti,lp8556"; diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt index 84f10c16cb3..3289d76a21d 100644 --- a/Documentation/devicetree/bindings/video/exynos_dp.txt +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt @@ -6,10 +6,10 @@ We use two nodes: -dptx-phy node(defined inside dp-controller node) For the DP-PHY initialization, we use the dptx-phy node. -Required properties for dptx-phy: - -reg: +Required properties for dptx-phy: deprecated, use phys and phy-names + -reg: deprecated Base address of DP PHY register. - -samsung,enable-mask: + -samsung,enable-mask: deprecated The bit-mask used to enable/disable DP PHY. For the Panel initialization, we read data from dp-controller node. @@ -27,6 +27,10 @@ Required properties for dp-controller: from common clock binding: Shall be "dp". -interrupt-parent: phandle to Interrupt combiner node. + -phys: + from general PHY binding: the phandle for the PHY device. + -phy-names: + from general PHY binding: Should be "dp". -samsung,color-space: input video data format. COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2 @@ -68,11 +72,8 @@ SOC specific portion: clocks = <&clock 342>; clock-names = "dp"; - dptx-phy { - reg = <0x10040720>; - samsung,enable-mask = <1>; - }; - + phys = <&dp_phy>; + phy-names = "dp"; }; Board Specific portion: diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index 323983be3c3..50decf8e1b9 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -12,7 +12,19 @@ Required properties: a) phandle of the gpio controller node. b) pin number within the gpio controller. c) optional flags and pull up/down. - +- clocks: list of clock IDs from SoC clock driver. + a) hdmi: Gate of HDMI IP bus clock. + b) sclk_hdmi: Gate of HDMI special clock. + c) sclk_pixel: Pixel special clock, one of the two possible inputs of + HDMI clock mux. + d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of + HDMI clock mux. + e) mout_hdmi: It is required by the driver to switch between the 2 + parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable + after configuration, parent is set to sclk_hdmiphy else + sclk_pixel. +- clock-names: aliases as per driver requirements for above clock IDs: + "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi". Example: hdmi { diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt b/Documentation/devicetree/bindings/video/exynos_mixer.txt index 3334b0a8e34..7bfde9c9d65 100644 --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt @@ -10,6 +10,10 @@ Required properties: - reg: physical base address of the mixer and length of memory mapped region. - interrupts: interrupt number to the cpu. +- clocks: list of clock IDs from SoC clock driver. + a) mixer: Gate of Mixer IP bus clock. + b) sclk_hdmi: HDMI Special clock, one of the two possible inputs of + mixer mux. Example: diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index fcb34a5697e..5bdc8cb5fc2 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -283,6 +283,7 @@ REGULATOR devm_regulator_get() devm_regulator_put() devm_regulator_bulk_get() + devm_regulator_register() CLOCK devm_clk_get() @@ -302,3 +303,6 @@ PHY SLAVE DMA ENGINE devm_acpi_dma_controller_register() + +SPI + devm_spi_register_master() diff --git a/Documentation/x86/efi-stub.txt b/Documentation/efi-stub.txt index 44e6bb6ead1..44e6bb6ead1 100644 --- a/Documentation/x86/efi-stub.txt +++ b/Documentation/efi-stub.txt diff --git a/Documentation/extcon/porting-android-switch-class b/Documentation/extcon/porting-android-switch-class index eb0fa5f4fe8..5377f631796 100644 --- a/Documentation/extcon/porting-android-switch-class +++ b/Documentation/extcon/porting-android-switch-class @@ -25,8 +25,10 @@ MyungJoo Ham <myungjoo.ham@samsung.com> @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) + => extcon_dev_register(edev) + : type change (sdev->edev) + : remove second param('dev'). if edev has parent device, should store + 'dev' to 'edev.dev.parent' before registering extcon device - switch_dev_unregister(sdev) => extcon_dev_unregister(edev) : no change but type change (sdev->edev) diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt index 11a0a40ce44..aed6b94160b 100644 --- a/Documentation/filesystems/caching/netfs-api.txt +++ b/Documentation/filesystems/caching/netfs-api.txt @@ -29,15 +29,16 @@ This document contains the following sections: (6) Index registration (7) Data file registration (8) Miscellaneous object registration - (9) Setting the data file size + (9) Setting the data file size (10) Page alloc/read/write (11) Page uncaching (12) Index and data file consistency - (13) Miscellaneous cookie operations - (14) Cookie unregistration - (15) Index invalidation - (16) Data file invalidation - (17) FS-Cache specific page flags. + (13) Cookie enablement + (14) Miscellaneous cookie operations + (15) Cookie unregistration + (16) Index invalidation + (17) Data file invalidation + (18) FS-Cache specific page flags. ============================= @@ -334,7 +335,8 @@ the path to the file: struct fscache_cookie * fscache_acquire_cookie(struct fscache_cookie *parent, const struct fscache_object_def *def, - void *netfs_data); + void *netfs_data, + bool enable); This function creates an index entry in the index represented by parent, filling in the index entry by calling the operations pointed to by def. @@ -350,6 +352,10 @@ object needs to be created somewhere down the hierarchy. Furthermore, an index may be created in several different caches independently at different times. This is all handled transparently, and the netfs doesn't see any of it. +A cookie will be created in the disabled state if enabled is false. A cookie +must be enabled to do anything with it. A disabled cookie can be enabled by +calling fscache_enable_cookie() (see below). + For example, with AFS, a cell would be added to the primary index. This index entry would have a dependent inode containing a volume location index for the volume mappings within this cell: @@ -357,7 +363,7 @@ volume mappings within this cell: cell->cache = fscache_acquire_cookie(afs_cache_netfs.primary_index, &afs_cell_cache_index_def, - cell); + cell, true); Then when a volume location was accessed, it would be entered into the cell's index and an inode would be allocated that acts as a volume type and hash chain @@ -366,7 +372,7 @@ combination: vlocation->cache = fscache_acquire_cookie(cell->cache, &afs_vlocation_cache_index_def, - vlocation); + vlocation, true); And then a particular flavour of volume (R/O for example) could be added to that index, creating another index for vnodes (AFS inode equivalents): @@ -374,7 +380,7 @@ that index, creating another index for vnodes (AFS inode equivalents): volume->cache = fscache_acquire_cookie(vlocation->cache, &afs_volume_cache_index_def, - volume); + volume, true); ====================== @@ -388,7 +394,7 @@ the object definition should be something other than index type. vnode->cache = fscache_acquire_cookie(volume->cache, &afs_vnode_cache_object_def, - vnode); + vnode, true); ================================= @@ -404,7 +410,7 @@ it would be some other type of object such as a data file. xattr->cache = fscache_acquire_cookie(vnode->cache, &afs_xattr_cache_object_def, - xattr); + xattr, true); Miscellaneous objects might be used to store extended attributes or directory entries for example. @@ -733,6 +739,47 @@ Note that partial updates may happen automatically at other times, such as when data blocks are added to a data file object. +================= +COOKIE ENABLEMENT +================= + +Cookies exist in one of two states: enabled and disabled. If a cookie is +disabled, it ignores all attempts to acquire child cookies; check, update or +invalidate its state; allocate, read or write backing pages - though it is +still possible to uncache pages and relinquish the cookie. + +The initial enablement state is set by fscache_acquire_cookie(), but the cookie +can be enabled or disabled later. To disable a cookie, call: + + void fscache_disable_cookie(struct fscache_cookie *cookie, + bool invalidate); + +If the cookie is not already disabled, this locks the cookie against other +enable and disable ops, marks the cookie as being disabled, discards or +invalidates any backing objects and waits for cessation of activity on any +associated object before unlocking the cookie. + +All possible failures are handled internally. The caller should consider +calling fscache_uncache_all_inode_pages() afterwards to make sure all page +markings are cleared up. + +Cookies can be enabled or reenabled with: + + void fscache_enable_cookie(struct fscache_cookie *cookie, + bool (*can_enable)(void *data), + void *data) + +If the cookie is not already enabled, this locks the cookie against other +enable and disable ops, invokes can_enable() and, if the cookie is not an index +cookie, will begin the procedure of acquiring backing objects. + +The optional can_enable() function is passed the data argument and returns a +ruling as to whether or not enablement should actually be permitted to begin. + +All possible failures are handled internally. The cookie will only be marked +as enabled if provisional backing objects are allocated. + + =============================== MISCELLANEOUS COOKIE OPERATIONS =============================== @@ -778,7 +825,7 @@ COOKIE UNREGISTRATION To get rid of a cookie, this function should be called. void fscache_relinquish_cookie(struct fscache_cookie *cookie, - int retire); + bool retire); If retire is non-zero, then the object will be marked for recycling, and all copies of it will be removed from all active caches in which it is present. diff --git a/Documentation/filesystems/directory-locking b/Documentation/filesystems/directory-locking index ff7b611abf3..09bbf9a54f8 100644 --- a/Documentation/filesystems/directory-locking +++ b/Documentation/filesystems/directory-locking @@ -2,6 +2,10 @@ kinds of locks - per-inode (->i_mutex) and per-filesystem (->s_vfs_rename_mutex). + When taking the i_mutex on multiple non-directory objects, we +always acquire the locks in order by increasing address. We'll call +that "inode pointer" order in the following. + For our purposes all operations fall in 5 classes: 1) read access. Locking rules: caller locks directory we are accessing. @@ -12,8 +16,9 @@ kinds of locks - per-inode (->i_mutex) and per-filesystem locks victim and calls the method. 4) rename() that is _not_ cross-directory. Locking rules: caller locks -the parent, finds source and target, if target already exists - locks it -and then calls the method. +the parent and finds source and target. If target already exists, lock +it. If source is a non-directory, lock it. If that means we need to +lock both, lock them in inode pointer order. 5) link creation. Locking rules: * lock parent @@ -30,7 +35,9 @@ rules: fail with -ENOTEMPTY * if new parent is equal to or is a descendent of source fail with -ELOOP - * if target exists - lock it. + * If target exists, lock it. If source is a non-directory, lock + it. In case that means we need to lock both source and target, + do so in inode pointer order. * call the method. @@ -56,9 +63,11 @@ objects - A < B iff A is an ancestor of B. renames will be blocked on filesystem lock and we don't start changing the order until we had acquired all locks). -(3) any operation holds at most one lock on non-directory object and - that lock is acquired after all other locks. (Proof: see descriptions - of operations). +(3) locks on non-directory objects are acquired only after locks on + directory objects, and are acquired in inode pointer order. + (Proof: all operations but renames take lock on at most one + non-directory object, except renames, which take locks on source and + target in inode pointer order in the case they are not directories.) Now consider the minimal deadlock. Each process is blocked on attempt to acquire some lock and already holds at least one lock. Let's @@ -66,9 +75,13 @@ consider the set of contended locks. First of all, filesystem lock is not contended, since any process blocked on it is not holding any locks. Thus all processes are blocked on ->i_mutex. - Non-directory objects are not contended due to (3). Thus link -creation can't be a part of deadlock - it can't be blocked on source -and it means that it doesn't hold any locks. + By (3), any process holding a non-directory lock can only be +waiting on another non-directory lock with a larger address. Therefore +the process holding the "largest" such lock can always make progress, and +non-directory objects are not included in the set of contended locks. + + Thus link creation can't be a part of deadlock - it can't be +blocked on source and it means that it doesn't hold any locks. Any contended object is either held by cross-directory rename or has a child that is also contended. Indeed, suppose that it is held by diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index 3cd27bed634..a3fe811bbdb 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -119,6 +119,7 @@ active_logs=%u Support configuring the number of active logs. In the Default number is 6. disable_ext_identify Disable the extension list configured by mkfs, so f2fs does not aware of cold files such as media files. +inline_xattr Enable the inline xattrs feature. ================================================================================ DEBUGFS ENTRIES @@ -164,6 +165,12 @@ Files in /sys/fs/f2fs/<devname> gc_idle = 1 will select the Cost Benefit approach & setting gc_idle = 2 will select the greedy aproach. + reclaim_segments This parameter controls the number of prefree + segments to be reclaimed. If the number of prefree + segments is larger than this number, f2fs tries to + conduct checkpoint to reclaim the prefree segments + to free segments. By default, 100 segments, 200MB. + ================================================================================ USAGE ================================================================================ diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index f0890581f7f..fe2b7ae6f96 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -455,3 +455,11 @@ in your dentry operations instead. vfs_follow_link has been removed. Filesystems must use nd_set_link from ->follow_link for normal symlinks, or nd_jump_link for magic /proc/<pid> style links. +-- +[mandatory] + iget5_locked()/ilookup5()/ilookup5_nowait() test() callback used to be + called with both ->i_lock and inode_hash_lock held; the former is *not* + taken anymore, so verify that your callbacks do not rely on it (none + of the in-tree instances did). inode_hash_lock is still held, + of course, so they are still serialized wrt removal from inode hash, + as well as wrt set() callback of iget5_locked(). diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 823c95faebd..22d89aa3721 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -460,6 +460,7 @@ manner. The codes are the following: nl - non-linear mapping ar - architecture specific flag dd - do not include area into core dump + sd - soft-dirty flag mm - mixed map area hg - huge page advise flag nh - no-huge page advise flag diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt index aa1f459fa6c..4a93e98b290 100644 --- a/Documentation/filesystems/vfat.txt +++ b/Documentation/filesystems/vfat.txt @@ -307,7 +307,7 @@ the following: <proceeding files...> <slot #3, id = 0x43, characters = "h is long"> - <slot #2, id = 0x02, characters = "xtension which"> + <slot #2, id = 0x02, characters = "xtension whic"> <slot #1, id = 0x01, characters = "My Big File.E"> <directory entry, name = "MYBIGFIL.EXT"> diff --git a/Documentation/gcov.txt b/Documentation/gcov.txt index e7ca6478cd9..7b727783db7 100644 --- a/Documentation/gcov.txt +++ b/Documentation/gcov.txt @@ -50,6 +50,10 @@ Configure the kernel with: CONFIG_DEBUG_FS=y CONFIG_GCOV_KERNEL=y +select the gcc's gcov format, default is autodetect based on gcc version: + + CONFIG_GCOV_FORMAT_AUTODETECT=y + and to get coverage data for the entire kernel: CONFIG_GCOV_PROFILE_ALL=y diff --git a/Documentation/hwmon/lm25066 b/Documentation/hwmon/lm25066 index c1b57d72efc..b34c3de5c1b 100644 --- a/Documentation/hwmon/lm25066 +++ b/Documentation/hwmon/lm25066 @@ -8,6 +8,11 @@ Supported chips: Datasheets: http://www.ti.com/lit/gpn/lm25056 http://www.ti.com/lit/gpn/lm25056a + * TI LM25063 + Prefix: 'lm25063' + Addresses scanned: - + Datasheet: + To be announced * National Semiconductor LM25066 Prefix: 'lm25066' Addresses scanned: - @@ -32,7 +37,7 @@ Description ----------- This driver supports hardware montoring for National Semiconductor / TI LM25056, -LM25066, LM5064, and LM5064 Power Management, Monitoring, Control, and +LM25063, LM25066, LM5064, and LM5066 Power Management, Monitoring, Control, and Protection ICs. The driver is a client driver to the core PMBus driver. Please see @@ -64,8 +69,12 @@ in1_input Measured input voltage. in1_average Average measured input voltage. in1_min Minimum input voltage. in1_max Maximum input voltage. +in1_crit Critical high input voltage (LM25063 only). +in1_lcrit Critical low input voltage (LM25063 only). in1_min_alarm Input voltage low alarm. in1_max_alarm Input voltage high alarm. +in1_lcrit_alarm Input voltage critical low alarm (LM25063 only). +in1_crit_alarm Input voltage critical high alarm. (LM25063 only). in2_label "vmon" in2_input Measured voltage on VAUX pin @@ -80,12 +89,16 @@ in3_input Measured output voltage. in3_average Average measured output voltage. in3_min Minimum output voltage. in3_min_alarm Output voltage low alarm. +in3_highest Historical minimum output voltage (LM25063 only). +in3_lowest Historical maximum output voltage (LM25063 only). curr1_label "iin" curr1_input Measured input current. curr1_average Average measured input current. curr1_max Maximum input current. +curr1_crit Critical input current (LM25063 only). curr1_max_alarm Input current high alarm. +curr1_crit_alarm Input current critical high alarm (LM25063 only). power1_label "pin" power1_input Measured input power. @@ -95,6 +108,11 @@ power1_alarm Input power alarm power1_input_highest Historical maximum power. power1_reset_history Write any value to reset maximum power history. +power2_label "pout". LM25063 only. +power2_input Measured output power. +power2_max Maximum output power limit. +power2_crit Critical output power limit. + temp1_input Measured temperature. temp1_max Maximum temperature. temp1_crit Critical high temperature. diff --git a/Documentation/hwmon/ltc2978 b/Documentation/hwmon/ltc2978 index dc0d08c6130..a0546fc4227 100644 --- a/Documentation/hwmon/ltc2978 +++ b/Documentation/hwmon/ltc2978 @@ -6,10 +6,15 @@ Supported chips: Prefix: 'ltc2974' Addresses scanned: - Datasheet: http://www.linear.com/product/ltc2974 - * Linear Technology LTC2978 + * Linear Technology LTC2977 + Prefix: 'ltc2977' + Addresses scanned: - + Datasheet: http://www.linear.com/product/ltc2977 + * Linear Technology LTC2978, LTC2978A Prefix: 'ltc2978' Addresses scanned: - Datasheet: http://www.linear.com/product/ltc2978 + http://www.linear.com/product/ltc2978a * Linear Technology LTC3880 Prefix: 'ltc3880' Addresses scanned: - @@ -26,8 +31,9 @@ Description ----------- LTC2974 is a quad digital power supply manager. LTC2978 is an octal power supply -monitor. LTC3880 is a dual output poly-phase step-down DC/DC controller. LTC3883 -is a single phase step-down DC/DC controller. +monitor. LTC2977 is a pin compatible replacement for LTC2978. LTC3880 is a dual +output poly-phase step-down DC/DC controller. LTC3883 is a single phase +step-down DC/DC controller. Usage Notes @@ -49,21 +55,25 @@ Sysfs attributes in1_label "vin" in1_input Measured input voltage. in1_min Minimum input voltage. -in1_max Maximum input voltage. LTC2974 and LTC2978 only. -in1_lcrit Critical minimum input voltage. LTC2974 and LTC2978 - only. +in1_max Maximum input voltage. + LTC2974, LTC2977, and LTC2978 only. +in1_lcrit Critical minimum input voltage. + LTC2974, LTC2977, and LTC2978 only. in1_crit Critical maximum input voltage. in1_min_alarm Input voltage low alarm. -in1_max_alarm Input voltage high alarm. LTC2974 and LTC2978 only. -in1_lcrit_alarm Input voltage critical low alarm. LTC2974 and LTC2978 - only. +in1_max_alarm Input voltage high alarm. + LTC2974, LTC2977, and LTC2978 only. +in1_lcrit_alarm Input voltage critical low alarm. + LTC2974, LTC2977, and LTC2978 only. in1_crit_alarm Input voltage critical high alarm. -in1_lowest Lowest input voltage. LTC2974 and LTC2978 only. +in1_lowest Lowest input voltage. + LTC2974, LTC2977, and LTC2978 only. in1_highest Highest input voltage. in1_reset_history Reset input voltage history. in[N]_label "vout[1-8]". LTC2974: N=2-5 + LTC2977: N=2-9 LTC2978: N=2-9 LTC3880: N=2-3 LTC3883: N=2 @@ -83,21 +93,23 @@ in[N]_reset_history Reset output voltage history. temp[N]_input Measured temperature. On LTC2974, temp[1-4] report external temperatures, and temp5 reports the chip temperature. - On LTC2978, only one temperature measurement is - supported and reports the chip temperature. + On LTC2977 and LTC2978, only one temperature measurement + is supported and reports the chip temperature. On LTC3880, temp1 and temp2 report external temperatures, and temp3 reports the chip temperature. On LTC3883, temp1 reports an external temperature, and temp2 reports the chip temperature. -temp[N]_min Mimimum temperature. LTC2974 and LTC2978 only. +temp[N]_min Mimimum temperature. LTC2974, LCT2977, and LTC2978 only. temp[N]_max Maximum temperature. temp[N]_lcrit Critical low temperature. temp[N]_crit Critical high temperature. -temp[N]_min_alarm Temperature low alarm. LTC2974 and LTC2978 only. +temp[N]_min_alarm Temperature low alarm. + LTC2974, LTC2977, and LTC2978 only. temp[N]_max_alarm Temperature high alarm. temp[N]_lcrit_alarm Temperature critical low alarm. temp[N]_crit_alarm Temperature critical high alarm. -temp[N]_lowest Lowest measured temperature. LTC2974 and LTC2978 only. +temp[N]_lowest Lowest measured temperature. + LTC2974, LTC2977, and LTC2978 only. Not supported for chip temperature sensor on LTC2974. temp[N]_highest Highest measured temperature. Not supported for chip temperature sensor on LTC2974. @@ -109,6 +121,7 @@ power1_input Measured input power. power[N]_label "pout[1-4]". LTC2974: N=1-4 + LTC2977: Not supported LTC2978: Not supported LTC3880: N=1-2 LTC3883: N=2 @@ -123,6 +136,7 @@ curr1_reset_history Reset input current history. LTC3883 only. curr[N]_label "iout[1-4]". LTC2974: N=1-4 + LTC2977: not supported LTC2978: not supported LTC3880: N=2-3 LTC3883: N=2 diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 2a5f0e14efa..7cbfa3c4fc3 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -138,6 +138,7 @@ Code Seq#(hex) Include File Comments 'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict! 'H' C0-DF net/bluetooth/bnep/bnep.h conflict! 'H' F1 linux/hid-roccat.h <mailto:erazor_de@users.sourceforge.net> +'H' F8-FA sound/firewire.h 'I' all linux/isdn.h conflict! 'I' 00-0F drivers/isdn/divert/isdn_divert.h conflict! 'I' 40-4F linux/mISDNif.h conflict! diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index fcbb736d55f..9ca3e74a10e 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -847,6 +847,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. earlyprintk= [X86,SH,BLACKFIN,ARM] earlyprintk=vga + earlyprintk=efi earlyprintk=xen earlyprintk=serial[,ttySn[,baudrate]] earlyprintk=serial[,0x...[,baudrate]] @@ -860,7 +861,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Append ",keep" to not disable it when the real console takes over. - Only vga or serial or usb debug port at a time. + Only one of vga, efi, serial, or usb debug port can + be used at a time. Currently only ttyS0 and ttyS1 may be specified by name. Other I/O ports may be explicitly specified @@ -874,8 +876,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Interaction with the standard serial driver is not very good. - The VGA output is eventually overwritten by the real - console. + The VGA and EFI output is eventually overwritten by + the real console. The xen output can only be used by Xen PV guests. @@ -1068,6 +1070,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. VIA, nVidia) verbose: show contents of HPET registers during setup + hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET + registers. Default set by CONFIG_HPET_MMAP_DEFAULT. + hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot. hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages. On x86-64 and powerpc, this option can be specified @@ -1773,6 +1778,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. that the amount of memory usable for all allocations is not too small. + movable_node [KNL,X86] Boot-time switch to enable the effects + of CONFIG_MOVABLE_NODE=y. See mm/Kconfig for details. + MTD_Partition= [MTD] Format: <name>,<region-number>,<size>,<offset> @@ -2599,7 +2607,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. ramdisk_size= [RAM] Sizes of RAM disks in kilobytes See Documentation/blockdev/ramdisk.txt. - rcu_nocbs= [KNL,BOOT] + rcu_nocbs= [KNL] In kernels built with CONFIG_RCU_NOCB_CPU=y, set the specified list of CPUs to be no-callback CPUs. Invocation of these CPUs' RCU callbacks will @@ -2612,7 +2620,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. real-time workloads. It can also improve energy efficiency for asymmetric multiprocessors. - rcu_nocb_poll [KNL,BOOT] + rcu_nocb_poll [KNL] Rather than requiring that offloaded CPUs (specified by rcu_nocbs= above) explicitly awaken the corresponding "rcuoN" kthreads, @@ -2623,126 +2631,145 @@ bytes respectively. Such letter suffixes can also be entirely omitted. energy efficiency by requiring that the kthreads periodically wake up to do the polling. - rcutree.blimit= [KNL,BOOT] + rcutree.blimit= [KNL] Set maximum number of finished RCU callbacks to process in one batch. - rcutree.fanout_leaf= [KNL,BOOT] + rcutree.rcu_fanout_leaf= [KNL] Increase the number of CPUs assigned to each leaf rcu_node structure. Useful for very large systems. - rcutree.jiffies_till_first_fqs= [KNL,BOOT] + rcutree.jiffies_till_first_fqs= [KNL] Set delay from grace-period initialization to first attempt to force quiescent states. Units are jiffies, minimum value is zero, and maximum value is HZ. - rcutree.jiffies_till_next_fqs= [KNL,BOOT] + rcutree.jiffies_till_next_fqs= [KNL] Set delay between subsequent attempts to force quiescent states. Units are jiffies, minimum value is one, and maximum value is HZ. - rcutree.qhimark= [KNL,BOOT] + rcutree.qhimark= [KNL] Set threshold of queued RCU callbacks over which batch limiting is disabled. - rcutree.qlowmark= [KNL,BOOT] + rcutree.qlowmark= [KNL] 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. - - rcutree.rcu_idle_gp_delay= [KNL,BOOT] + rcutree.rcu_idle_gp_delay= [KNL] Set wakeup interval for idle CPUs that have RCU callbacks (RCU_FAST_NO_HZ=y). - rcutree.rcu_idle_lazy_gp_delay= [KNL,BOOT] + rcutree.rcu_idle_lazy_gp_delay= [KNL] Set wakeup interval for idle CPUs that have only "lazy" RCU callbacks (RCU_FAST_NO_HZ=y). Lazy RCU callbacks are those which RCU can prove do nothing more than free memory. - rcutorture.fqs_duration= [KNL,BOOT] + rcutorture.fqs_duration= [KNL] Set duration of force_quiescent_state bursts. - rcutorture.fqs_holdoff= [KNL,BOOT] + rcutorture.fqs_holdoff= [KNL] Set holdoff time within force_quiescent_state bursts. - rcutorture.fqs_stutter= [KNL,BOOT] + rcutorture.fqs_stutter= [KNL] Set wait time between force_quiescent_state bursts. - rcutorture.irqreader= [KNL,BOOT] - Test RCU readers from irq handlers. + rcutorture.gp_exp= [KNL] + Use expedited update-side primitives. + + rcutorture.gp_normal= [KNL] + Use normal (non-expedited) update-side primitives. + If both gp_exp and gp_normal are set, do both. + If neither gp_exp nor gp_normal are set, still + do both. - rcutorture.n_barrier_cbs= [KNL,BOOT] + rcutorture.n_barrier_cbs= [KNL] Set callbacks/threads for rcu_barrier() testing. - rcutorture.nfakewriters= [KNL,BOOT] + rcutorture.nfakewriters= [KNL] 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] + rcutorture.nreaders= [KNL] Set number of RCU readers. - rcutorture.onoff_holdoff= [KNL,BOOT] + rcutorture.object_debug= [KNL] + Enable debug-object double-call_rcu() testing. + + rcutorture.onoff_holdoff= [KNL] Set time (s) after boot for CPU-hotplug testing. - rcutorture.onoff_interval= [KNL,BOOT] + rcutorture.onoff_interval= [KNL] Set time (s) between CPU-hotplug operations, or zero to disable CPU-hotplug testing. - rcutorture.shuffle_interval= [KNL,BOOT] + rcutorture.rcutorture_runnable= [BOOT] + Start rcutorture running at boot time. + + rcutorture.shuffle_interval= [KNL] 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] + rcutorture.shutdown_secs= [KNL] Set time (s) after boot system shutdown. This is useful for hands-off automated testing. - rcutorture.stall_cpu= [KNL,BOOT] + rcutorture.stall_cpu= [KNL] Duration of CPU stall (s) to test RCU CPU stall warnings, zero to disable. - rcutorture.stall_cpu_holdoff= [KNL,BOOT] + rcutorture.stall_cpu_holdoff= [KNL] Time to wait (s) after boot before inducing stall. - rcutorture.stat_interval= [KNL,BOOT] + rcutorture.stat_interval= [KNL] Time (s) between statistics printk()s. - rcutorture.stutter= [KNL,BOOT] + rcutorture.stutter= [KNL] 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] + rcutorture.test_boost= [KNL] 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] + rcutorture.test_boost_duration= [KNL] Duration (s) of each individual boost test. - rcutorture.test_boost_interval= [KNL,BOOT] + rcutorture.test_boost_interval= [KNL] Interval (s) between each boost test. - rcutorture.test_no_idle_hz= [KNL,BOOT] + rcutorture.test_no_idle_hz= [KNL] Test RCU's dyntick-idle handling. See also the rcutorture.shuffle_interval parameter. - rcutorture.torture_type= [KNL,BOOT] + rcutorture.torture_type= [KNL] Specify the RCU implementation to test. - rcutorture.verbose= [KNL,BOOT] + rcutorture.verbose= [KNL] Enable additional printk() statements. + rcupdate.rcu_expedited= [KNL] + Use expedited grace-period primitives, for + example, synchronize_rcu_expedited() instead + of synchronize_rcu(). This reduces latency, + but can increase CPU utilization, degrade + real-time latency, and degrade energy efficiency. + + rcupdate.rcu_cpu_stall_suppress= [KNL] + Suppress RCU CPU stall warning messages. + + rcupdate.rcu_cpu_stall_timeout= [KNL] + Set timeout for RCU CPU stall warning messages. + rdinit= [KNL] Format: <full_path> Run specified binary instead of /init from the ramdisk, @@ -3471,11 +3498,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. default x2apic cluster mode on platforms supporting x2apic. - x86_mrst_timer= [X86-32,APBT] - Choose timer option for x86 Moorestown MID platform. + x86_intel_mid_timer= [X86-32,APBT] + Choose timer option for x86 Intel MID platform. Two valid options are apbt timer only and lapic timer plus one apbt timer for broadcast timer. - x86_mrst_timer=apbt_only | lapic_and_apbt + x86_intel_mid_timer=apbt_only | lapic_and_apbt xen_emul_unplug= [HW,X86,XEN] Unplug Xen emulated devices diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt index 32351bfabf2..827104fb936 100644 --- a/Documentation/kernel-per-CPU-kthreads.txt +++ b/Documentation/kernel-per-CPU-kthreads.txt @@ -181,12 +181,17 @@ To reduce its OS jitter, do any of the following: make sure that this is safe on your particular system. d. It is not possible to entirely get rid of OS jitter from vmstat_update() on CONFIG_SMP=y systems, but you - can decrease its frequency by writing a large value to - /proc/sys/vm/stat_interval. The default value is HZ, - for an interval of one second. Of course, larger values - will make your virtual-memory statistics update more - slowly. Of course, you can also run your workload at - a real-time priority, thus preempting vmstat_update(). + can decrease its frequency by writing a large value + to /proc/sys/vm/stat_interval. The default value is + HZ, for an interval of one second. Of course, larger + values will make your virtual-memory statistics update + more slowly. Of course, you can also run your workload + at a real-time priority, thus preempting vmstat_update(), + but if your workload is CPU-bound, this is a bad idea. + However, there is an RFC patch from Christoph Lameter + (based on an earlier one from Gilad Ben-Yossef) that + reduces or even eliminates vmstat overhead for some + workloads at https://lkml.org/lkml/2013/9/4/379. e. If running on high-end powerpc servers, build with CONFIG_PPC_RTAS_DAEMON=n. This prevents the RTAS daemon from running on each CPU every second or so. diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 86c52360ffe..fc04c14de4b 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -1,7 +1,7 @@ ThinkPad ACPI Extras Driver - Version 0.24 - December 11th, 2009 + Version 0.25 + October 16th, 2013 Borislav Deianov <borislav@users.sf.net> Henrique de Moraes Holschuh <hmh@hmh.eng.br> @@ -741,6 +741,9 @@ compiled with the CONFIG_THINKPAD_ACPI_UNSAFE_LEDS option enabled. Distributions must never enable this option. Individual users that are aware of the consequences are welcome to enabling it. +Audio mute and microphone mute LEDs are supported, but currently not +visible to userspace. They are used by the snd-hda-intel audio driver. + procfs notes: The available commands are: diff --git a/Documentation/mic/mic_overview.txt b/Documentation/mic/mic_overview.txt new file mode 100644 index 00000000000..b4192922480 --- /dev/null +++ b/Documentation/mic/mic_overview.txt @@ -0,0 +1,51 @@ +An Intel MIC X100 device is a PCIe form factor add-in coprocessor +card based on the Intel Many Integrated Core (MIC) architecture +that runs a Linux OS. It is a PCIe endpoint in a platform and therefore +implements the three required standard address spaces i.e. configuration, +memory and I/O. The host OS loads a device driver as is typical for +PCIe devices. The card itself runs a bootstrap after reset that +transfers control to the card OS downloaded from the host driver. The +host driver supports OSPM suspend and resume operations. It shuts down +the card during suspend and reboots the card OS during resume. +The card OS as shipped by Intel is a Linux kernel with modifications +for the X100 devices. + +Since it is a PCIe card, it does not have the ability to host hardware +devices for networking, storage and console. We provide these devices +on X100 coprocessors thus enabling a self-bootable equivalent environment +for applications. A key benefit of our solution is that it leverages +the standard virtio framework for network, disk and console devices, +though in our case the virtio framework is used across a PCIe bus. + +Here is a block diagram of the various components described above. The +virtio backends are situated on the host rather than the card given better +single threaded performance for the host compared to MIC, the ability of +the host to initiate DMA's to/from the card using the MIC DMA engine and +the fact that the virtio block storage backend can only be on the host. + + | + +----------+ | +----------+ + | Card OS | | | Host OS | + +----------+ | +----------+ + | ++-------+ +--------+ +------+ | +---------+ +--------+ +--------+ +| Virtio| |Virtio | |Virtio| | |Virtio | |Virtio | |Virtio | +| Net | |Console | |Block | | |Net | |Console | |Block | +| Driver| |Driver | |Driver| | |backend | |backend | |backend | ++-------+ +--------+ +------+ | +---------+ +--------+ +--------+ + | | | | | | | + | | | |User | | | + | | | |------|------------|---------|------- + +-------------------+ |Kernel +--------------------------+ + | | | Virtio over PCIe IOCTLs | + | | +--------------------------+ + +--------------+ | | + |Intel MIC | | +---------------+ + |Card Driver | | |Intel MIC | + +--------------+ | |Host Driver | + | | +---------------+ + | | | + +-------------------------------------------------------------+ + | | + | PCIe Bus | + +-------------------------------------------------------------+ diff --git a/Documentation/mic/mpssd/.gitignore b/Documentation/mic/mpssd/.gitignore new file mode 100644 index 00000000000..8b7c72f07c9 --- /dev/null +++ b/Documentation/mic/mpssd/.gitignore @@ -0,0 +1 @@ +mpssd diff --git a/Documentation/mic/mpssd/Makefile b/Documentation/mic/mpssd/Makefile new file mode 100644 index 00000000000..eb860a7d152 --- /dev/null +++ b/Documentation/mic/mpssd/Makefile @@ -0,0 +1,19 @@ +# +# Makefile - Intel MIC User Space Tools. +# Copyright(c) 2013, Intel Corporation. +# +ifdef DEBUG +CFLAGS += $(USERWARNFLAGS) -I. -g -Wall -DDEBUG=$(DEBUG) +else +CFLAGS += $(USERWARNFLAGS) -I. -g -Wall +endif + +mpssd: mpssd.o sysfs.o + $(CC) $(CFLAGS) -o $@ $^ -lpthread + +install: + install mpssd /usr/sbin/mpssd + install micctrl /usr/sbin/micctrl + +clean: + rm -f mpssd *.o diff --git a/Documentation/mic/mpssd/micctrl b/Documentation/mic/mpssd/micctrl new file mode 100755 index 00000000000..8f2629b41c5 --- /dev/null +++ b/Documentation/mic/mpssd/micctrl @@ -0,0 +1,173 @@ +#!/bin/bash +# Intel MIC Platform Software Stack (MPSS) +# +# Copyright(c) 2013 Intel Corporation. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License, version 2, 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. +# +# The full GNU General Public License is included in this distribution in +# the file called "COPYING". +# +# Intel MIC User Space Tools. +# +# micctrl - Controls MIC boot/start/stop. +# +# chkconfig: 2345 95 05 +# description: start MPSS stack processing. +# +### BEGIN INIT INFO +# Provides: micctrl +### END INIT INFO + +# Source function library. +. /etc/init.d/functions + +sysfs="/sys/class/mic" + +_status() +{ + f=$sysfs/$1 + echo -e $1 state: "`cat $f/state`" shutdown_status: "`cat $f/shutdown_status`" +} + +status() +{ + if [ "`echo $1 | head -c3`" == "mic" ]; then + _status $1 + return $? + fi + for f in $sysfs/* + do + _status `basename $f` + RETVAL=$? + [ $RETVAL -ne 0 ] && return $RETVAL + done + return 0 +} + +_reset() +{ + f=$sysfs/$1 + echo reset > $f/state +} + +reset() +{ + if [ "`echo $1 | head -c3`" == "mic" ]; then + _reset $1 + return $? + fi + for f in $sysfs/* + do + _reset `basename $f` + RETVAL=$? + [ $RETVAL -ne 0 ] && return $RETVAL + done + return 0 +} + +_boot() +{ + f=$sysfs/$1 + echo "linux" > $f/bootmode + echo "mic/uos.img" > $f/firmware + echo "mic/$1.image" > $f/ramdisk + echo "boot" > $f/state +} + +boot() +{ + if [ "`echo $1 | head -c3`" == "mic" ]; then + _boot $1 + return $? + fi + for f in $sysfs/* + do + _boot `basename $f` + RETVAL=$? + [ $RETVAL -ne 0 ] && return $RETVAL + done + return 0 +} + +_shutdown() +{ + f=$sysfs/$1 + echo shutdown > $f/state +} + +shutdown() +{ + if [ "`echo $1 | head -c3`" == "mic" ]; then + _shutdown $1 + return $? + fi + for f in $sysfs/* + do + _shutdown `basename $f` + RETVAL=$? + [ $RETVAL -ne 0 ] && return $RETVAL + done + return 0 +} + +_wait() +{ + f=$sysfs/$1 + while [ "`cat $f/state`" != "offline" -a "`cat $f/state`" != "online" ] + do + sleep 1 + echo -e "Waiting for $1 to go offline" + done +} + +wait() +{ + if [ "`echo $1 | head -c3`" == "mic" ]; then + _wait $1 + return $? + fi + # Wait for the cards to go offline + for f in $sysfs/* + do + _wait `basename $f` + RETVAL=$? + [ $RETVAL -ne 0 ] && return $RETVAL + done + return 0 +} + +if [ ! -d "$sysfs" ]; then + echo -e $"Module unloaded " + exit 3 +fi + +case $1 in + -s) + status $2 + ;; + -r) + reset $2 + ;; + -b) + boot $2 + ;; + -S) + shutdown $2 + ;; + -w) + wait $2 + ;; + *) + echo $"Usage: $0 {-s (status) |-r (reset) |-b (boot) |-S (shutdown) |-w (wait)}" + exit 2 +esac + +exit $? diff --git a/Documentation/mic/mpssd/mpss b/Documentation/mic/mpssd/mpss new file mode 100755 index 00000000000..3136c68dad0 --- /dev/null +++ b/Documentation/mic/mpssd/mpss @@ -0,0 +1,202 @@ +#!/bin/bash +# Intel MIC Platform Software Stack (MPSS) +# +# Copyright(c) 2013 Intel Corporation. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License, version 2, 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. +# +# The full GNU General Public License is included in this distribution in +# the file called "COPYING". +# +# Intel MIC User Space Tools. +# +# mpss Start mpssd. +# +# chkconfig: 2345 95 05 +# description: start MPSS stack processing. +# +### BEGIN INIT INFO +# Provides: mpss +# Required-Start: +# Required-Stop: +# Short-Description: MPSS stack control +# Description: MPSS stack control +### END INIT INFO + +# Source function library. +. /etc/init.d/functions + +exec=/usr/sbin/mpssd +sysfs="/sys/class/mic" + +start() +{ + [ -x $exec ] || exit 5 + + if [ "`ps -e | awk '{print $4}' | grep mpssd | head -1`" = "mpssd" ]; then + echo -e $"MPSSD already running! " + success + echo + return 0 + fi + + echo -e $"Starting MPSS Stack" + echo -e $"Loading MIC_HOST Module" + + # Ensure the driver is loaded + if [ ! -d "$sysfs" ]; then + modprobe mic_host + RETVAL=$? + if [ $RETVAL -ne 0 ]; then + failure + echo + return $RETVAL + fi + fi + + # Start the daemon + echo -n $"Starting MPSSD " + $exec + RETVAL=$? + if [ $RETVAL -ne 0 ]; then + failure + echo + return $RETVAL + fi + success + echo + + sleep 5 + + # Boot the cards + micctrl -b + + # Wait till ping works + for f in $sysfs/* + do + count=100 + ipaddr=`cat $f/cmdline` + ipaddr=${ipaddr#*address,} + ipaddr=`echo $ipaddr | cut -d, -f1 | cut -d\; -f1` + while [ $count -ge 0 ] + do + echo -e "Pinging "`basename $f`" " + ping -c 1 $ipaddr &> /dev/null + RETVAL=$? + if [ $RETVAL -eq 0 ]; then + success + break + fi + sleep 1 + count=`expr $count - 1` + done + [ $RETVAL -ne 0 ] && failure || success + echo + done + return $RETVAL +} + +stop() +{ + echo -e $"Shutting down MPSS Stack: " + + # Bail out if module is unloaded + if [ ! -d "$sysfs" ]; then + echo -n $"Module unloaded " + success + echo + return 0 + fi + + # Shut down the cards. + micctrl -S + + # Wait for the cards to go offline + for f in $sysfs/* + do + while [ "`cat $f/state`" != "offline" ] + do + sleep 1 + echo -e "Waiting for "`basename $f`" to go offline" + done + done + + # Display the status of the cards + micctrl -s + + # Kill MPSSD now + echo -n $"Killing MPSSD" + killall -9 mpssd 2>/dev/null + RETVAL=$? + [ $RETVAL -ne 0 ] && failure || success + echo + return $RETVAL +} + +restart() +{ + stop + sleep 5 + start +} + +status() +{ + micctrl -s + if [ "`ps -e | awk '{print $4}' | grep mpssd | head -n 1`" = "mpssd" ]; then + echo "mpssd is running" + else + echo "mpssd is stopped" + fi + return 0 +} + +unload() +{ + if [ ! -d "$sysfs" ]; then + echo -n $"No MIC_HOST Module: " + success + echo + return + fi + + stop + + sleep 5 + echo -n $"Removing MIC_HOST Module: " + modprobe -r mic_host + RETVAL=$? + [ $RETVAL -ne 0 ] && failure || success + echo + return $RETVAL +} + +case $1 in + start) + start + ;; + stop) + stop + ;; + restart) + restart + ;; + status) + status + ;; + unload) + unload + ;; + *) + echo $"Usage: $0 {start|stop|restart|status|unload}" + exit 2 +esac + +exit $? diff --git a/Documentation/mic/mpssd/mpssd.c b/Documentation/mic/mpssd/mpssd.c new file mode 100644 index 00000000000..0c980ad40b1 --- /dev/null +++ b/Documentation/mic/mpssd/mpssd.c @@ -0,0 +1,1721 @@ +/* + * Intel MIC Platform Software Stack (MPSS) + * + * Copyright(c) 2013 Intel Corporation. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License, version 2, 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. + * + * The full GNU General Public License is included in this distribution in + * the file called "COPYING". + * + * Intel MIC User Space Tools. + */ + +#define _GNU_SOURCE + +#include <stdlib.h> +#include <fcntl.h> +#include <getopt.h> +#include <assert.h> +#include <unistd.h> +#include <stdbool.h> +#include <signal.h> +#include <poll.h> +#include <features.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <sys/mman.h> +#include <sys/socket.h> +#include <linux/virtio_ring.h> +#include <linux/virtio_net.h> +#include <linux/virtio_console.h> +#include <linux/virtio_blk.h> +#include <linux/version.h> +#include "mpssd.h" +#include <linux/mic_ioctl.h> +#include <linux/mic_common.h> + +static void init_mic(struct mic_info *mic); + +static FILE *logfp; +static struct mic_info mic_list; + +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) + +#define min_t(type, x, y) ({ \ + type __min1 = (x); \ + type __min2 = (y); \ + __min1 < __min2 ? __min1 : __min2; }) + +/* align addr on a size boundary - adjust address up/down if needed */ +#define _ALIGN_DOWN(addr, size) ((addr)&(~((size)-1))) +#define _ALIGN_UP(addr, size) _ALIGN_DOWN(addr + size - 1, size) + +/* align addr on a size boundary - adjust address up if needed */ +#define _ALIGN(addr, size) _ALIGN_UP(addr, size) + +/* to align the pointer to the (next) page boundary */ +#define PAGE_ALIGN(addr) _ALIGN(addr, PAGE_SIZE) + +#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x)) + +#define GSO_ENABLED 1 +#define MAX_GSO_SIZE (64 * 1024) +#define ETH_H_LEN 14 +#define MAX_NET_PKT_SIZE (_ALIGN_UP(MAX_GSO_SIZE + ETH_H_LEN, 64)) +#define MIC_DEVICE_PAGE_END 0x1000 + +#ifndef VIRTIO_NET_HDR_F_DATA_VALID +#define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */ +#endif + +static struct { + struct mic_device_desc dd; + struct mic_vqconfig vqconfig[2]; + __u32 host_features, guest_acknowledgements; + struct virtio_console_config cons_config; +} virtcons_dev_page = { + .dd = { + .type = VIRTIO_ID_CONSOLE, + .num_vq = ARRAY_SIZE(virtcons_dev_page.vqconfig), + .feature_len = sizeof(virtcons_dev_page.host_features), + .config_len = sizeof(virtcons_dev_page.cons_config), + }, + .vqconfig[0] = { + .num = htole16(MIC_VRING_ENTRIES), + }, + .vqconfig[1] = { + .num = htole16(MIC_VRING_ENTRIES), + }, +}; + +static struct { + struct mic_device_desc dd; + struct mic_vqconfig vqconfig[2]; + __u32 host_features, guest_acknowledgements; + struct virtio_net_config net_config; +} virtnet_dev_page = { + .dd = { + .type = VIRTIO_ID_NET, + .num_vq = ARRAY_SIZE(virtnet_dev_page.vqconfig), + .feature_len = sizeof(virtnet_dev_page.host_features), + .config_len = sizeof(virtnet_dev_page.net_config), + }, + .vqconfig[0] = { + .num = htole16(MIC_VRING_ENTRIES), + }, + .vqconfig[1] = { + .num = htole16(MIC_VRING_ENTRIES), + }, +#if GSO_ENABLED + .host_features = htole32( + 1 << VIRTIO_NET_F_CSUM | + 1 << VIRTIO_NET_F_GSO | + 1 << VIRTIO_NET_F_GUEST_TSO4 | + 1 << VIRTIO_NET_F_GUEST_TSO6 | + 1 << VIRTIO_NET_F_GUEST_ECN | + 1 << VIRTIO_NET_F_GUEST_UFO), +#else + .host_features = 0, +#endif +}; + +static const char *mic_config_dir = "/etc/sysconfig/mic"; +static const char *virtblk_backend = "VIRTBLK_BACKEND"; +static struct { + struct mic_device_desc dd; + struct mic_vqconfig vqconfig[1]; + __u32 host_features, guest_acknowledgements; + struct virtio_blk_config blk_config; +} virtblk_dev_page = { + .dd = { + .type = VIRTIO_ID_BLOCK, + .num_vq = ARRAY_SIZE(virtblk_dev_page.vqconfig), + .feature_len = sizeof(virtblk_dev_page.host_features), + .config_len = sizeof(virtblk_dev_page.blk_config), + }, + .vqconfig[0] = { + .num = htole16(MIC_VRING_ENTRIES), + }, + .host_features = + htole32(1<<VIRTIO_BLK_F_SEG_MAX), + .blk_config = { + .seg_max = htole32(MIC_VRING_ENTRIES - 2), + .capacity = htole64(0), + } +}; + +static char *myname; + +static int +tap_configure(struct mic_info *mic, char *dev) +{ + pid_t pid; + char *ifargv[7]; + char ipaddr[IFNAMSIZ]; + int ret = 0; + + pid = fork(); + if (pid == 0) { + ifargv[0] = "ip"; + ifargv[1] = "link"; + ifargv[2] = "set"; + ifargv[3] = dev; + ifargv[4] = "up"; + ifargv[5] = NULL; + mpsslog("Configuring %s\n", dev); + ret = execvp("ip", ifargv); + if (ret < 0) { + mpsslog("%s execvp failed errno %s\n", + mic->name, strerror(errno)); + return ret; + } + } + if (pid < 0) { + mpsslog("%s fork failed errno %s\n", + mic->name, strerror(errno)); + return ret; + } + + ret = waitpid(pid, NULL, 0); + if (ret < 0) { + mpsslog("%s waitpid failed errno %s\n", + mic->name, strerror(errno)); + return ret; + } + + snprintf(ipaddr, IFNAMSIZ, "172.31.%d.254/24", mic->id); + + pid = fork(); + if (pid == 0) { + ifargv[0] = "ip"; + ifargv[1] = "addr"; + ifargv[2] = "add"; + ifargv[3] = ipaddr; + ifargv[4] = "dev"; + ifargv[5] = dev; + ifargv[6] = NULL; + mpsslog("Configuring %s ipaddr %s\n", dev, ipaddr); + ret = execvp("ip", ifargv); + if (ret < 0) { + mpsslog("%s execvp failed errno %s\n", + mic->name, strerror(errno)); + return ret; + } + } + if (pid < 0) { + mpsslog("%s fork failed errno %s\n", + mic->name, strerror(errno)); + return ret; + } + + ret = waitpid(pid, NULL, 0); + if (ret < 0) { + mpsslog("%s waitpid failed errno %s\n", + mic->name, strerror(errno)); + return ret; + } + mpsslog("MIC name %s %s %d DONE!\n", + mic->name, __func__, __LINE__); + return 0; +} + +static int tun_alloc(struct mic_info *mic, char *dev) +{ + struct ifreq ifr; + int fd, err; +#if GSO_ENABLED + unsigned offload; +#endif + fd = open("/dev/net/tun", O_RDWR); + if (fd < 0) { + mpsslog("Could not open /dev/net/tun %s\n", strerror(errno)); + goto done; + } + + memset(&ifr, 0, sizeof(ifr)); + + ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_VNET_HDR; + if (*dev) + strncpy(ifr.ifr_name, dev, IFNAMSIZ); + + err = ioctl(fd, TUNSETIFF, (void *)&ifr); + if (err < 0) { + mpsslog("%s %s %d TUNSETIFF failed %s\n", + mic->name, __func__, __LINE__, strerror(errno)); + close(fd); + return err; + } +#if GSO_ENABLED + offload = TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 | + TUN_F_TSO_ECN | TUN_F_UFO; + + err = ioctl(fd, TUNSETOFFLOAD, offload); + if (err < 0) { + mpsslog("%s %s %d TUNSETOFFLOAD failed %s\n", + mic->name, __func__, __LINE__, strerror(errno)); + close(fd); + return err; + } +#endif + strcpy(dev, ifr.ifr_name); + mpsslog("Created TAP %s\n", dev); +done: + return fd; +} + +#define NET_FD_VIRTIO_NET 0 +#define NET_FD_TUN 1 +#define MAX_NET_FD 2 + +static void set_dp(struct mic_info *mic, int type, void *dp) +{ + switch (type) { + case VIRTIO_ID_CONSOLE: + mic->mic_console.console_dp = dp; + return; + case VIRTIO_ID_NET: + mic->mic_net.net_dp = dp; + return; + case VIRTIO_ID_BLOCK: + mic->mic_virtblk.block_dp = dp; + return; + } + mpsslog("%s %s %d not found\n", mic->name, __func__, type); + assert(0); +} + +static void *get_dp(struct mic_info *mic, int type) +{ + switch (type) { + case VIRTIO_ID_CONSOLE: + return mic->mic_console.console_dp; + case VIRTIO_ID_NET: + return mic->mic_net.net_dp; + case VIRTIO_ID_BLOCK: + return mic->mic_virtblk.block_dp; + } + mpsslog("%s %s %d not found\n", mic->name, __func__, type); + assert(0); + return NULL; +} + +static struct mic_device_desc *get_device_desc(struct mic_info *mic, int type) +{ + struct mic_device_desc *d; + int i; + void *dp = get_dp(mic, type); + + for (i = mic_aligned_size(struct mic_bootparam); i < PAGE_SIZE; + i += mic_total_desc_size(d)) { + d = dp + i; + + /* End of list */ + if (d->type == 0) + break; + + if (d->type == -1) + continue; + + mpsslog("%s %s d-> type %d d %p\n", + mic->name, __func__, d->type, d); + + if (d->type == (__u8)type) + return d; + } + mpsslog("%s %s %d not found\n", mic->name, __func__, type); + assert(0); + return NULL; +} + +/* See comments in vhost.c for explanation of next_desc() */ +static unsigned next_desc(struct vring_desc *desc) +{ + unsigned int next; + + if (!(le16toh(desc->flags) & VRING_DESC_F_NEXT)) + return -1U; + next = le16toh(desc->next); + return next; +} + +/* Sum up all the IOVEC length */ +static ssize_t +sum_iovec_len(struct mic_copy_desc *copy) +{ + ssize_t sum = 0; + int i; + + for (i = 0; i < copy->iovcnt; i++) + sum += copy->iov[i].iov_len; + return sum; +} + +static inline void verify_out_len(struct mic_info *mic, + struct mic_copy_desc *copy) +{ + if (copy->out_len != sum_iovec_len(copy)) { + mpsslog("%s %s %d BUG copy->out_len 0x%x len 0x%zx\n", + mic->name, __func__, __LINE__, + copy->out_len, sum_iovec_len(copy)); + assert(copy->out_len == sum_iovec_len(copy)); + } +} + +/* Display an iovec */ +static void +disp_iovec(struct mic_info *mic, struct mic_copy_desc *copy, + const char *s, int line) +{ + int i; + + for (i = 0; i < copy->iovcnt; i++) + mpsslog("%s %s %d copy->iov[%d] addr %p len 0x%zx\n", + mic->name, s, line, i, + copy->iov[i].iov_base, copy->iov[i].iov_len); +} + +static inline __u16 read_avail_idx(struct mic_vring *vr) +{ + return ACCESS_ONCE(vr->info->avail_idx); +} + +static inline void txrx_prepare(int type, bool tx, struct mic_vring *vr, + struct mic_copy_desc *copy, ssize_t len) +{ + copy->vr_idx = tx ? 0 : 1; + copy->update_used = true; + if (type == VIRTIO_ID_NET) + copy->iov[1].iov_len = len - sizeof(struct virtio_net_hdr); + else + copy->iov[0].iov_len = len; +} + +/* Central API which triggers the copies */ +static int +mic_virtio_copy(struct mic_info *mic, int fd, + struct mic_vring *vr, struct mic_copy_desc *copy) +{ + int ret; + + ret = ioctl(fd, MIC_VIRTIO_COPY_DESC, copy); + if (ret) { + mpsslog("%s %s %d errno %s ret %d\n", + mic->name, __func__, __LINE__, + strerror(errno), ret); + } + return ret; +} + +/* + * This initialization routine requires at least one + * vring i.e. vr0. vr1 is optional. + */ +static void * +init_vr(struct mic_info *mic, int fd, int type, + struct mic_vring *vr0, struct mic_vring *vr1, int num_vq) +{ + int vr_size; + char *va; + + vr_size = PAGE_ALIGN(vring_size(MIC_VRING_ENTRIES, + MIC_VIRTIO_RING_ALIGN) + sizeof(struct _mic_vring_info)); + va = mmap(NULL, MIC_DEVICE_PAGE_END + vr_size * num_vq, + PROT_READ, MAP_SHARED, fd, 0); + if (MAP_FAILED == va) { + mpsslog("%s %s %d mmap failed errno %s\n", + mic->name, __func__, __LINE__, + strerror(errno)); + goto done; + } + set_dp(mic, type, va); + vr0->va = (struct mic_vring *)&va[MIC_DEVICE_PAGE_END]; + vr0->info = vr0->va + + vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN); + vring_init(&vr0->vr, + MIC_VRING_ENTRIES, vr0->va, MIC_VIRTIO_RING_ALIGN); + mpsslog("%s %s vr0 %p vr0->info %p vr_size 0x%x vring 0x%x ", + __func__, mic->name, vr0->va, vr0->info, vr_size, + vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN)); + mpsslog("magic 0x%x expected 0x%x\n", + vr0->info->magic, MIC_MAGIC + type); + assert(vr0->info->magic == MIC_MAGIC + type); + if (vr1) { + vr1->va = (struct mic_vring *) + &va[MIC_DEVICE_PAGE_END + vr_size]; + vr1->info = vr1->va + vring_size(MIC_VRING_ENTRIES, + MIC_VIRTIO_RING_ALIGN); + vring_init(&vr1->vr, + MIC_VRING_ENTRIES, vr1->va, MIC_VIRTIO_RING_ALIGN); + mpsslog("%s %s vr1 %p vr1->info %p vr_size 0x%x vring 0x%x ", + __func__, mic->name, vr1->va, vr1->info, vr_size, + vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN)); + mpsslog("magic 0x%x expected 0x%x\n", + vr1->info->magic, MIC_MAGIC + type + 1); + assert(vr1->info->magic == MIC_MAGIC + type + 1); + } +done: + return va; +} + +static void +wait_for_card_driver(struct mic_info *mic, int fd, int type) +{ + struct pollfd pollfd; + int err; + struct mic_device_desc *desc = get_device_desc(mic, type); + + pollfd.fd = fd; + mpsslog("%s %s Waiting .... desc-> type %d status 0x%x\n", + mic->name, __func__, type, desc->status); + while (1) { + pollfd.events = POLLIN; + pollfd.revents = 0; + err = poll(&pollfd, 1, -1); + if (err < 0) { + mpsslog("%s %s poll failed %s\n", + mic->name, __func__, strerror(errno)); + continue; + } + + if (pollfd.revents) { + mpsslog("%s %s Waiting... desc-> type %d status 0x%x\n", + mic->name, __func__, type, desc->status); + if (desc->status & VIRTIO_CONFIG_S_DRIVER_OK) { + mpsslog("%s %s poll.revents %d\n", + mic->name, __func__, pollfd.revents); + mpsslog("%s %s desc-> type %d status 0x%x\n", + mic->name, __func__, type, + desc->status); + break; + } + } + } +} + +/* Spin till we have some descriptors */ +static void +spin_for_descriptors(struct mic_info *mic, struct mic_vring *vr) +{ + __u16 avail_idx = read_avail_idx(vr); + + while (avail_idx == le16toh(ACCESS_ONCE(vr->vr.avail->idx))) { +#ifdef DEBUG + mpsslog("%s %s waiting for desc avail %d info_avail %d\n", + mic->name, __func__, + le16toh(vr->vr.avail->idx), vr->info->avail_idx); +#endif + sched_yield(); + } +} + +static void * +virtio_net(void *arg) +{ + static __u8 vnet_hdr[2][sizeof(struct virtio_net_hdr)]; + static __u8 vnet_buf[2][MAX_NET_PKT_SIZE] __aligned(64); + struct iovec vnet_iov[2][2] = { + { { .iov_base = vnet_hdr[0], .iov_len = sizeof(vnet_hdr[0]) }, + { .iov_base = vnet_buf[0], .iov_len = sizeof(vnet_buf[0]) } }, + { { .iov_base = vnet_hdr[1], .iov_len = sizeof(vnet_hdr[1]) }, + { .iov_base = vnet_buf[1], .iov_len = sizeof(vnet_buf[1]) } }, + }; + struct iovec *iov0 = vnet_iov[0], *iov1 = vnet_iov[1]; + struct mic_info *mic = (struct mic_info *)arg; + char if_name[IFNAMSIZ]; + struct pollfd net_poll[MAX_NET_FD]; + struct mic_vring tx_vr, rx_vr; + struct mic_copy_desc copy; + struct mic_device_desc *desc; + int err; + + snprintf(if_name, IFNAMSIZ, "mic%d", mic->id); + mic->mic_net.tap_fd = tun_alloc(mic, if_name); + if (mic->mic_net.tap_fd < 0) + goto done; + + if (tap_configure(mic, if_name)) + goto done; + mpsslog("MIC name %s id %d\n", mic->name, mic->id); + + net_poll[NET_FD_VIRTIO_NET].fd = mic->mic_net.virtio_net_fd; + net_poll[NET_FD_VIRTIO_NET].events = POLLIN; + net_poll[NET_FD_TUN].fd = mic->mic_net.tap_fd; + net_poll[NET_FD_TUN].events = POLLIN; + + if (MAP_FAILED == init_vr(mic, mic->mic_net.virtio_net_fd, + VIRTIO_ID_NET, &tx_vr, &rx_vr, + virtnet_dev_page.dd.num_vq)) { + mpsslog("%s init_vr failed %s\n", + mic->name, strerror(errno)); + goto done; + } + + copy.iovcnt = 2; + desc = get_device_desc(mic, VIRTIO_ID_NET); + + while (1) { + ssize_t len; + + net_poll[NET_FD_VIRTIO_NET].revents = 0; + net_poll[NET_FD_TUN].revents = 0; + + /* Start polling for data from tap and virtio net */ + err = poll(net_poll, 2, -1); + if (err < 0) { + mpsslog("%s poll failed %s\n", + __func__, strerror(errno)); + continue; + } + if (!(desc->status & VIRTIO_CONFIG_S_DRIVER_OK)) + wait_for_card_driver(mic, mic->mic_net.virtio_net_fd, + VIRTIO_ID_NET); + /* + * Check if there is data to be read from TUN and write to + * virtio net fd if there is. + */ + if (net_poll[NET_FD_TUN].revents & POLLIN) { + copy.iov = iov0; + len = readv(net_poll[NET_FD_TUN].fd, + copy.iov, copy.iovcnt); + if (len > 0) { + struct virtio_net_hdr *hdr + = (struct virtio_net_hdr *)vnet_hdr[0]; + + /* Disable checksums on the card since we are on + a reliable PCIe link */ + hdr->flags |= VIRTIO_NET_HDR_F_DATA_VALID; +#ifdef DEBUG + mpsslog("%s %s %d hdr->flags 0x%x ", mic->name, + __func__, __LINE__, hdr->flags); + mpsslog("copy.out_len %d hdr->gso_type 0x%x\n", + copy.out_len, hdr->gso_type); +#endif +#ifdef DEBUG + disp_iovec(mic, copy, __func__, __LINE__); + mpsslog("%s %s %d read from tap 0x%lx\n", + mic->name, __func__, __LINE__, + len); +#endif + spin_for_descriptors(mic, &tx_vr); + txrx_prepare(VIRTIO_ID_NET, 1, &tx_vr, ©, + len); + + err = mic_virtio_copy(mic, + mic->mic_net.virtio_net_fd, &tx_vr, + ©); + if (err < 0) { + mpsslog("%s %s %d mic_virtio_copy %s\n", + mic->name, __func__, __LINE__, + strerror(errno)); + } + if (!err) + verify_out_len(mic, ©); +#ifdef DEBUG + disp_iovec(mic, copy, __func__, __LINE__); + mpsslog("%s %s %d wrote to net 0x%lx\n", + mic->name, __func__, __LINE__, + sum_iovec_len(©)); +#endif + /* Reinitialize IOV for next run */ + iov0[1].iov_len = MAX_NET_PKT_SIZE; + } else if (len < 0) { + disp_iovec(mic, ©, __func__, __LINE__); + mpsslog("%s %s %d read failed %s ", mic->name, + __func__, __LINE__, strerror(errno)); + mpsslog("cnt %d sum %zd\n", + copy.iovcnt, sum_iovec_len(©)); + } + } + + /* + * Check if there is data to be read from virtio net and + * write to TUN if there is. + */ + if (net_poll[NET_FD_VIRTIO_NET].revents & POLLIN) { + while (rx_vr.info->avail_idx != + le16toh(rx_vr.vr.avail->idx)) { + copy.iov = iov1; + txrx_prepare(VIRTIO_ID_NET, 0, &rx_vr, ©, + MAX_NET_PKT_SIZE + + sizeof(struct virtio_net_hdr)); + + err = mic_virtio_copy(mic, + mic->mic_net.virtio_net_fd, &rx_vr, + ©); + if (!err) { +#ifdef DEBUG + struct virtio_net_hdr *hdr + = (struct virtio_net_hdr *) + vnet_hdr[1]; + + mpsslog("%s %s %d hdr->flags 0x%x, ", + mic->name, __func__, __LINE__, + hdr->flags); + mpsslog("out_len %d gso_type 0x%x\n", + copy.out_len, + hdr->gso_type); +#endif + /* Set the correct output iov_len */ + iov1[1].iov_len = copy.out_len - + sizeof(struct virtio_net_hdr); + verify_out_len(mic, ©); +#ifdef DEBUG + disp_iovec(mic, copy, __func__, + __LINE__); + mpsslog("%s %s %d ", + mic->name, __func__, __LINE__); + mpsslog("read from net 0x%lx\n", + sum_iovec_len(copy)); +#endif + len = writev(net_poll[NET_FD_TUN].fd, + copy.iov, copy.iovcnt); + if (len != sum_iovec_len(©)) { + mpsslog("Tun write failed %s ", + strerror(errno)); + mpsslog("len 0x%zx ", len); + mpsslog("read_len 0x%zx\n", + sum_iovec_len(©)); + } else { +#ifdef DEBUG + disp_iovec(mic, ©, __func__, + __LINE__); + mpsslog("%s %s %d ", + mic->name, __func__, + __LINE__); + mpsslog("wrote to tap 0x%lx\n", + len); +#endif + } + } else { + mpsslog("%s %s %d mic_virtio_copy %s\n", + mic->name, __func__, __LINE__, + strerror(errno)); + break; + } + } + } + if (net_poll[NET_FD_VIRTIO_NET].revents & POLLERR) + mpsslog("%s: %s: POLLERR\n", __func__, mic->name); + } +done: + pthread_exit(NULL); +} + +/* virtio_console */ +#define VIRTIO_CONSOLE_FD 0 +#define MONITOR_FD (VIRTIO_CONSOLE_FD + 1) +#define MAX_CONSOLE_FD (MONITOR_FD + 1) /* must be the last one + 1 */ +#define MAX_BUFFER_SIZE PAGE_SIZE + +static void * +virtio_console(void *arg) +{ + static __u8 vcons_buf[2][PAGE_SIZE]; + struct iovec vcons_iov[2] = { + { .iov_base = vcons_buf[0], .iov_len = sizeof(vcons_buf[0]) }, + { .iov_base = vcons_buf[1], .iov_len = sizeof(vcons_buf[1]) }, + }; + struct iovec *iov0 = &vcons_iov[0], *iov1 = &vcons_iov[1]; + struct mic_info *mic = (struct mic_info *)arg; + int err; + struct pollfd console_poll[MAX_CONSOLE_FD]; + int pty_fd; + char *pts_name; + ssize_t len; + struct mic_vring tx_vr, rx_vr; + struct mic_copy_desc copy; + struct mic_device_desc *desc; + + pty_fd = posix_openpt(O_RDWR); + if (pty_fd < 0) { + mpsslog("can't open a pseudoterminal master device: %s\n", + strerror(errno)); + goto _return; + } + pts_name = ptsname(pty_fd); + if (pts_name == NULL) { + mpsslog("can't get pts name\n"); + goto _close_pty; + } + printf("%s console message goes to %s\n", mic->name, pts_name); + mpsslog("%s console message goes to %s\n", mic->name, pts_name); + err = grantpt(pty_fd); + if (err < 0) { + mpsslog("can't grant access: %s %s\n", + pts_name, strerror(errno)); + goto _close_pty; + } + err = unlockpt(pty_fd); + if (err < 0) { + mpsslog("can't unlock a pseudoterminal: %s %s\n", + pts_name, strerror(errno)); + goto _close_pty; + } + console_poll[MONITOR_FD].fd = pty_fd; + console_poll[MONITOR_FD].events = POLLIN; + + console_poll[VIRTIO_CONSOLE_FD].fd = mic->mic_console.virtio_console_fd; + console_poll[VIRTIO_CONSOLE_FD].events = POLLIN; + + if (MAP_FAILED == init_vr(mic, mic->mic_console.virtio_console_fd, + VIRTIO_ID_CONSOLE, &tx_vr, &rx_vr, + virtcons_dev_page.dd.num_vq)) { + mpsslog("%s init_vr failed %s\n", + mic->name, strerror(errno)); + goto _close_pty; + } + + copy.iovcnt = 1; + desc = get_device_desc(mic, VIRTIO_ID_CONSOLE); + + for (;;) { + console_poll[MONITOR_FD].revents = 0; + console_poll[VIRTIO_CONSOLE_FD].revents = 0; + err = poll(console_poll, MAX_CONSOLE_FD, -1); + if (err < 0) { + mpsslog("%s %d: poll failed: %s\n", __func__, __LINE__, + strerror(errno)); + continue; + } + if (!(desc->status & VIRTIO_CONFIG_S_DRIVER_OK)) + wait_for_card_driver(mic, + mic->mic_console.virtio_console_fd, + VIRTIO_ID_CONSOLE); + + if (console_poll[MONITOR_FD].revents & POLLIN) { + copy.iov = iov0; + len = readv(pty_fd, copy.iov, copy.iovcnt); + if (len > 0) { +#ifdef DEBUG + disp_iovec(mic, copy, __func__, __LINE__); + mpsslog("%s %s %d read from tap 0x%lx\n", + mic->name, __func__, __LINE__, + len); +#endif + spin_for_descriptors(mic, &tx_vr); + txrx_prepare(VIRTIO_ID_CONSOLE, 1, &tx_vr, + ©, len); + + err = mic_virtio_copy(mic, + mic->mic_console.virtio_console_fd, + &tx_vr, ©); + if (err < 0) { + mpsslog("%s %s %d mic_virtio_copy %s\n", + mic->name, __func__, __LINE__, + strerror(errno)); + } + if (!err) + verify_out_len(mic, ©); +#ifdef DEBUG + disp_iovec(mic, copy, __func__, __LINE__); + mpsslog("%s %s %d wrote to net 0x%lx\n", + mic->name, __func__, __LINE__, + sum_iovec_len(copy)); +#endif + /* Reinitialize IOV for next run */ + iov0->iov_len = PAGE_SIZE; + } else if (len < 0) { + disp_iovec(mic, ©, __func__, __LINE__); + mpsslog("%s %s %d read failed %s ", + mic->name, __func__, __LINE__, + strerror(errno)); + mpsslog("cnt %d sum %zd\n", + copy.iovcnt, sum_iovec_len(©)); + } + } + + if (console_poll[VIRTIO_CONSOLE_FD].revents & POLLIN) { + while (rx_vr.info->avail_idx != + le16toh(rx_vr.vr.avail->idx)) { + copy.iov = iov1; + txrx_prepare(VIRTIO_ID_CONSOLE, 0, &rx_vr, + ©, PAGE_SIZE); + + err = mic_virtio_copy(mic, + mic->mic_console.virtio_console_fd, + &rx_vr, ©); + if (!err) { + /* Set the correct output iov_len */ + iov1->iov_len = copy.out_len; + verify_out_len(mic, ©); +#ifdef DEBUG + disp_iovec(mic, copy, __func__, + __LINE__); + mpsslog("%s %s %d ", + mic->name, __func__, __LINE__); + mpsslog("read from net 0x%lx\n", + sum_iovec_len(copy)); +#endif + len = writev(pty_fd, + copy.iov, copy.iovcnt); + if (len != sum_iovec_len(©)) { + mpsslog("Tun write failed %s ", + strerror(errno)); + mpsslog("len 0x%zx ", len); + mpsslog("read_len 0x%zx\n", + sum_iovec_len(©)); + } else { +#ifdef DEBUG + disp_iovec(mic, copy, __func__, + __LINE__); + mpsslog("%s %s %d ", + mic->name, __func__, + __LINE__); + mpsslog("wrote to tap 0x%lx\n", + len); +#endif + } + } else { + mpsslog("%s %s %d mic_virtio_copy %s\n", + mic->name, __func__, __LINE__, + strerror(errno)); + break; + } + } + } + if (console_poll[NET_FD_VIRTIO_NET].revents & POLLERR) + mpsslog("%s: %s: POLLERR\n", __func__, mic->name); + } +_close_pty: + close(pty_fd); +_return: + pthread_exit(NULL); +} + +static void +add_virtio_device(struct mic_info *mic, struct mic_device_desc *dd) +{ + char path[PATH_MAX]; + int fd, err; + + snprintf(path, PATH_MAX, "/dev/mic%d", mic->id); + fd = open(path, O_RDWR); + if (fd < 0) { + mpsslog("Could not open %s %s\n", path, strerror(errno)); + return; + } + + err = ioctl(fd, MIC_VIRTIO_ADD_DEVICE, dd); + if (err < 0) { + mpsslog("Could not add %d %s\n", dd->type, strerror(errno)); + close(fd); + return; + } + switch (dd->type) { + case VIRTIO_ID_NET: + mic->mic_net.virtio_net_fd = fd; + mpsslog("Added VIRTIO_ID_NET for %s\n", mic->name); + break; + case VIRTIO_ID_CONSOLE: + mic->mic_console.virtio_console_fd = fd; + mpsslog("Added VIRTIO_ID_CONSOLE for %s\n", mic->name); + break; + case VIRTIO_ID_BLOCK: + mic->mic_virtblk.virtio_block_fd = fd; + mpsslog("Added VIRTIO_ID_BLOCK for %s\n", mic->name); + break; + } +} + +static bool +set_backend_file(struct mic_info *mic) +{ + FILE *config; + char buff[PATH_MAX], *line, *evv, *p; + + snprintf(buff, PATH_MAX, "%s/mpssd%03d.conf", mic_config_dir, mic->id); + config = fopen(buff, "r"); + if (config == NULL) + return false; + do { /* look for "virtblk_backend=XXXX" */ + line = fgets(buff, PATH_MAX, config); + if (line == NULL) + break; + if (*line == '#') + continue; + p = strchr(line, '\n'); + if (p) + *p = '\0'; + } while (strncmp(line, virtblk_backend, strlen(virtblk_backend)) != 0); + fclose(config); + if (line == NULL) + return false; + evv = strchr(line, '='); + if (evv == NULL) + return false; + mic->mic_virtblk.backend_file = malloc(strlen(evv) + 1); + if (mic->mic_virtblk.backend_file == NULL) { + mpsslog("%s %d can't allocate memory\n", mic->name, mic->id); + return false; + } + strcpy(mic->mic_virtblk.backend_file, evv + 1); + return true; +} + +#define SECTOR_SIZE 512 +static bool +set_backend_size(struct mic_info *mic) +{ + mic->mic_virtblk.backend_size = lseek(mic->mic_virtblk.backend, 0, + SEEK_END); + if (mic->mic_virtblk.backend_size < 0) { + mpsslog("%s: can't seek: %s\n", + mic->name, mic->mic_virtblk.backend_file); + return false; + } + virtblk_dev_page.blk_config.capacity = + mic->mic_virtblk.backend_size / SECTOR_SIZE; + if ((mic->mic_virtblk.backend_size % SECTOR_SIZE) != 0) + virtblk_dev_page.blk_config.capacity++; + + virtblk_dev_page.blk_config.capacity = + htole64(virtblk_dev_page.blk_config.capacity); + + return true; +} + +static bool +open_backend(struct mic_info *mic) +{ + if (!set_backend_file(mic)) + goto _error_exit; + mic->mic_virtblk.backend = open(mic->mic_virtblk.backend_file, O_RDWR); + if (mic->mic_virtblk.backend < 0) { + mpsslog("%s: can't open: %s\n", mic->name, + mic->mic_virtblk.backend_file); + goto _error_free; + } + if (!set_backend_size(mic)) + goto _error_close; + mic->mic_virtblk.backend_addr = mmap(NULL, + mic->mic_virtblk.backend_size, + PROT_READ|PROT_WRITE, MAP_SHARED, + mic->mic_virtblk.backend, 0L); + if (mic->mic_virtblk.backend_addr == MAP_FAILED) { + mpsslog("%s: can't map: %s %s\n", + mic->name, mic->mic_virtblk.backend_file, + strerror(errno)); + goto _error_close; + } + return true; + + _error_close: + close(mic->mic_virtblk.backend); + _error_free: + free(mic->mic_virtblk.backend_file); + _error_exit: + return false; +} + +static void +close_backend(struct mic_info *mic) +{ + munmap(mic->mic_virtblk.backend_addr, mic->mic_virtblk.backend_size); + close(mic->mic_virtblk.backend); + free(mic->mic_virtblk.backend_file); +} + +static bool +start_virtblk(struct mic_info *mic, struct mic_vring *vring) +{ + if (((unsigned long)&virtblk_dev_page.blk_config % 8) != 0) { + mpsslog("%s: blk_config is not 8 byte aligned.\n", + mic->name); + return false; + } + add_virtio_device(mic, &virtblk_dev_page.dd); + if (MAP_FAILED == init_vr(mic, mic->mic_virtblk.virtio_block_fd, + VIRTIO_ID_BLOCK, vring, NULL, + virtblk_dev_page.dd.num_vq)) { + mpsslog("%s init_vr failed %s\n", + mic->name, strerror(errno)); + return false; + } + return true; +} + +static void +stop_virtblk(struct mic_info *mic) +{ + int vr_size, ret; + + vr_size = PAGE_ALIGN(vring_size(MIC_VRING_ENTRIES, + MIC_VIRTIO_RING_ALIGN) + sizeof(struct _mic_vring_info)); + ret = munmap(mic->mic_virtblk.block_dp, + MIC_DEVICE_PAGE_END + vr_size * virtblk_dev_page.dd.num_vq); + if (ret < 0) + mpsslog("%s munmap errno %d\n", mic->name, errno); + close(mic->mic_virtblk.virtio_block_fd); +} + +static __u8 +header_error_check(struct vring_desc *desc) +{ + if (le32toh(desc->len) != sizeof(struct virtio_blk_outhdr)) { + mpsslog("%s() %d: length is not sizeof(virtio_blk_outhd)\n", + __func__, __LINE__); + return -EIO; + } + if (!(le16toh(desc->flags) & VRING_DESC_F_NEXT)) { + mpsslog("%s() %d: alone\n", + __func__, __LINE__); + return -EIO; + } + if (le16toh(desc->flags) & VRING_DESC_F_WRITE) { + mpsslog("%s() %d: not read\n", + __func__, __LINE__); + return -EIO; + } + return 0; +} + +static int +read_header(int fd, struct virtio_blk_outhdr *hdr, __u32 desc_idx) +{ + struct iovec iovec; + struct mic_copy_desc copy; + + iovec.iov_len = sizeof(*hdr); + iovec.iov_base = hdr; + copy.iov = &iovec; + copy.iovcnt = 1; + copy.vr_idx = 0; /* only one vring on virtio_block */ + copy.update_used = false; /* do not update used index */ + return ioctl(fd, MIC_VIRTIO_COPY_DESC, ©); +} + +static int +transfer_blocks(int fd, struct iovec *iovec, __u32 iovcnt) +{ + struct mic_copy_desc copy; + + copy.iov = iovec; + copy.iovcnt = iovcnt; + copy.vr_idx = 0; /* only one vring on virtio_block */ + copy.update_used = false; /* do not update used index */ + return ioctl(fd, MIC_VIRTIO_COPY_DESC, ©); +} + +static __u8 +status_error_check(struct vring_desc *desc) +{ + if (le32toh(desc->len) != sizeof(__u8)) { + mpsslog("%s() %d: length is not sizeof(status)\n", + __func__, __LINE__); + return -EIO; + } + return 0; +} + +static int +write_status(int fd, __u8 *status) +{ + struct iovec iovec; + struct mic_copy_desc copy; + + iovec.iov_base = status; + iovec.iov_len = sizeof(*status); + copy.iov = &iovec; + copy.iovcnt = 1; + copy.vr_idx = 0; /* only one vring on virtio_block */ + copy.update_used = true; /* Update used index */ + return ioctl(fd, MIC_VIRTIO_COPY_DESC, ©); +} + +static void * +virtio_block(void *arg) +{ + struct mic_info *mic = (struct mic_info *)arg; + int ret; + struct pollfd block_poll; + struct mic_vring vring; + __u16 avail_idx; + __u32 desc_idx; + struct vring_desc *desc; + struct iovec *iovec, *piov; + __u8 status; + __u32 buffer_desc_idx; + struct virtio_blk_outhdr hdr; + void *fos; + + for (;;) { /* forever */ + if (!open_backend(mic)) { /* No virtblk */ + for (mic->mic_virtblk.signaled = 0; + !mic->mic_virtblk.signaled;) + sleep(1); + continue; + } + + /* backend file is specified. */ + if (!start_virtblk(mic, &vring)) + goto _close_backend; + iovec = malloc(sizeof(*iovec) * + le32toh(virtblk_dev_page.blk_config.seg_max)); + if (!iovec) { + mpsslog("%s: can't alloc iovec: %s\n", + mic->name, strerror(ENOMEM)); + goto _stop_virtblk; + } + + block_poll.fd = mic->mic_virtblk.virtio_block_fd; + block_poll.events = POLLIN; + for (mic->mic_virtblk.signaled = 0; + !mic->mic_virtblk.signaled;) { + block_poll.revents = 0; + /* timeout in 1 sec to see signaled */ + ret = poll(&block_poll, 1, 1000); + if (ret < 0) { + mpsslog("%s %d: poll failed: %s\n", + __func__, __LINE__, + strerror(errno)); + continue; + } + + if (!(block_poll.revents & POLLIN)) { +#ifdef DEBUG + mpsslog("%s %d: block_poll.revents=0x%x\n", + __func__, __LINE__, block_poll.revents); +#endif + continue; + } + + /* POLLIN */ + while (vring.info->avail_idx != + le16toh(vring.vr.avail->idx)) { + /* read header element */ + avail_idx = + vring.info->avail_idx & + (vring.vr.num - 1); + desc_idx = le16toh( + vring.vr.avail->ring[avail_idx]); + desc = &vring.vr.desc[desc_idx]; +#ifdef DEBUG + mpsslog("%s() %d: avail_idx=%d ", + __func__, __LINE__, + vring.info->avail_idx); + mpsslog("vring.vr.num=%d desc=%p\n", + vring.vr.num, desc); +#endif + status = header_error_check(desc); + ret = read_header( + mic->mic_virtblk.virtio_block_fd, + &hdr, desc_idx); + if (ret < 0) { + mpsslog("%s() %d %s: ret=%d %s\n", + __func__, __LINE__, + mic->name, ret, + strerror(errno)); + break; + } + /* buffer element */ + piov = iovec; + status = 0; + fos = mic->mic_virtblk.backend_addr + + (hdr.sector * SECTOR_SIZE); + buffer_desc_idx = next_desc(desc); + desc_idx = buffer_desc_idx; + for (desc = &vring.vr.desc[buffer_desc_idx]; + desc->flags & VRING_DESC_F_NEXT; + desc_idx = next_desc(desc), + desc = &vring.vr.desc[desc_idx]) { + piov->iov_len = desc->len; + piov->iov_base = fos; + piov++; + fos += desc->len; + } + /* Returning NULLs for VIRTIO_BLK_T_GET_ID. */ + if (hdr.type & ~(VIRTIO_BLK_T_OUT | + VIRTIO_BLK_T_GET_ID)) { + /* + VIRTIO_BLK_T_IN - does not do + anything. Probably for documenting. + VIRTIO_BLK_T_SCSI_CMD - for + virtio_scsi. + VIRTIO_BLK_T_FLUSH - turned off in + config space. + VIRTIO_BLK_T_BARRIER - defined but not + used in anywhere. + */ + mpsslog("%s() %d: type %x ", + __func__, __LINE__, + hdr.type); + mpsslog("is not supported\n"); + status = -ENOTSUP; + + } else { + ret = transfer_blocks( + mic->mic_virtblk.virtio_block_fd, + iovec, + piov - iovec); + if (ret < 0 && + status != 0) + status = ret; + } + /* write status and update used pointer */ + if (status != 0) + status = status_error_check(desc); + ret = write_status( + mic->mic_virtblk.virtio_block_fd, + &status); +#ifdef DEBUG + mpsslog("%s() %d: write status=%d on desc=%p\n", + __func__, __LINE__, + status, desc); +#endif + } + } + free(iovec); +_stop_virtblk: + stop_virtblk(mic); +_close_backend: + close_backend(mic); + } /* forever */ + + pthread_exit(NULL); +} + +static void +reset(struct mic_info *mic) +{ +#define RESET_TIMEOUT 120 + int i = RESET_TIMEOUT; + setsysfs(mic->name, "state", "reset"); + while (i) { + char *state; + state = readsysfs(mic->name, "state"); + if (!state) + goto retry; + mpsslog("%s: %s %d state %s\n", + mic->name, __func__, __LINE__, state); + + /* + * If the shutdown was initiated by OSPM, the state stays + * in "suspended" which is also a valid condition for reset. + */ + if ((!strcmp(state, "offline")) || + (!strcmp(state, "suspended"))) { + free(state); + break; + } + free(state); +retry: + sleep(1); + i--; + } +} + +static int +get_mic_shutdown_status(struct mic_info *mic, char *shutdown_status) +{ + if (!strcmp(shutdown_status, "nop")) + return MIC_NOP; + if (!strcmp(shutdown_status, "crashed")) + return MIC_CRASHED; + if (!strcmp(shutdown_status, "halted")) + return MIC_HALTED; + if (!strcmp(shutdown_status, "poweroff")) + return MIC_POWER_OFF; + if (!strcmp(shutdown_status, "restart")) + return MIC_RESTART; + mpsslog("%s: BUG invalid status %s\n", mic->name, shutdown_status); + /* Invalid state */ + assert(0); +}; + +static int get_mic_state(struct mic_info *mic, char *state) +{ + if (!strcmp(state, "offline")) + return MIC_OFFLINE; + if (!strcmp(state, "online")) + return MIC_ONLINE; + if (!strcmp(state, "shutting_down")) + return MIC_SHUTTING_DOWN; + if (!strcmp(state, "reset_failed")) + return MIC_RESET_FAILED; + if (!strcmp(state, "suspending")) + return MIC_SUSPENDING; + if (!strcmp(state, "suspended")) + return MIC_SUSPENDED; + mpsslog("%s: BUG invalid state %s\n", mic->name, state); + /* Invalid state */ + assert(0); +}; + +static void mic_handle_shutdown(struct mic_info *mic) +{ +#define SHUTDOWN_TIMEOUT 60 + int i = SHUTDOWN_TIMEOUT, ret, stat = 0; + char *shutdown_status; + while (i) { + shutdown_status = readsysfs(mic->name, "shutdown_status"); + if (!shutdown_status) + continue; + mpsslog("%s: %s %d shutdown_status %s\n", + mic->name, __func__, __LINE__, shutdown_status); + switch (get_mic_shutdown_status(mic, shutdown_status)) { + case MIC_RESTART: + mic->restart = 1; + case MIC_HALTED: + case MIC_POWER_OFF: + case MIC_CRASHED: + free(shutdown_status); + goto reset; + default: + break; + } + free(shutdown_status); + sleep(1); + i--; + } +reset: + ret = kill(mic->pid, SIGTERM); + mpsslog("%s: %s %d kill pid %d ret %d\n", + mic->name, __func__, __LINE__, + mic->pid, ret); + if (!ret) { + ret = waitpid(mic->pid, &stat, + WIFSIGNALED(stat)); + mpsslog("%s: %s %d waitpid ret %d pid %d\n", + mic->name, __func__, __LINE__, + ret, mic->pid); + } + if (ret == mic->pid) + reset(mic); +} + +static void * +mic_config(void *arg) +{ + struct mic_info *mic = (struct mic_info *)arg; + char *state = NULL; + char pathname[PATH_MAX]; + int fd, ret; + struct pollfd ufds[1]; + char value[4096]; + + snprintf(pathname, PATH_MAX - 1, "%s/%s/%s", + MICSYSFSDIR, mic->name, "state"); + + fd = open(pathname, O_RDONLY); + if (fd < 0) { + mpsslog("%s: opening file %s failed %s\n", + mic->name, pathname, strerror(errno)); + goto error; + } + + do { + ret = read(fd, value, sizeof(value)); + if (ret < 0) { + mpsslog("%s: Failed to read sysfs entry '%s': %s\n", + mic->name, pathname, strerror(errno)); + goto close_error1; + } +retry: + state = readsysfs(mic->name, "state"); + if (!state) + goto retry; + mpsslog("%s: %s %d state %s\n", + mic->name, __func__, __LINE__, state); + switch (get_mic_state(mic, state)) { + case MIC_SHUTTING_DOWN: + mic_handle_shutdown(mic); + goto close_error; + case MIC_SUSPENDING: + mic->boot_on_resume = 1; + setsysfs(mic->name, "state", "suspend"); + mic_handle_shutdown(mic); + goto close_error; + case MIC_OFFLINE: + if (mic->boot_on_resume) { + setsysfs(mic->name, "state", "boot"); + mic->boot_on_resume = 0; + } + break; + default: + break; + } + free(state); + + ufds[0].fd = fd; + ufds[0].events = POLLERR | POLLPRI; + ret = poll(ufds, 1, -1); + if (ret < 0) { + mpsslog("%s: poll failed %s\n", + mic->name, strerror(errno)); + goto close_error1; + } + } while (1); +close_error: + free(state); +close_error1: + close(fd); +error: + init_mic(mic); + pthread_exit(NULL); +} + +static void +set_cmdline(struct mic_info *mic) +{ + char buffer[PATH_MAX]; + int len; + + len = snprintf(buffer, PATH_MAX, + "clocksource=tsc highres=off nohz=off "); + len += snprintf(buffer + len, PATH_MAX, + "cpufreq_on;corec6_off;pc3_off;pc6_off "); + len += snprintf(buffer + len, PATH_MAX, + "ifcfg=static;address,172.31.%d.1;netmask,255.255.255.0", + mic->id); + + setsysfs(mic->name, "cmdline", buffer); + mpsslog("%s: Command line: \"%s\"\n", mic->name, buffer); + snprintf(buffer, PATH_MAX, "172.31.%d.1", mic->id); + mpsslog("%s: IPADDR: \"%s\"\n", mic->name, buffer); +} + +static void +set_log_buf_info(struct mic_info *mic) +{ + int fd; + off_t len; + char system_map[] = "/lib/firmware/mic/System.map"; + char *map, *temp, log_buf[17] = {'\0'}; + + fd = open(system_map, O_RDONLY); + if (fd < 0) { + mpsslog("%s: Opening System.map failed: %d\n", + mic->name, errno); + return; + } + len = lseek(fd, 0, SEEK_END); + if (len < 0) { + mpsslog("%s: Reading System.map size failed: %d\n", + mic->name, errno); + close(fd); + return; + } + map = mmap(NULL, len, PROT_READ, MAP_PRIVATE, fd, 0); + if (map == MAP_FAILED) { + mpsslog("%s: mmap of System.map failed: %d\n", + mic->name, errno); + close(fd); + return; + } + temp = strstr(map, "__log_buf"); + if (!temp) { + mpsslog("%s: __log_buf not found: %d\n", mic->name, errno); + munmap(map, len); + close(fd); + return; + } + strncpy(log_buf, temp - 19, 16); + setsysfs(mic->name, "log_buf_addr", log_buf); + mpsslog("%s: log_buf_addr: %s\n", mic->name, log_buf); + temp = strstr(map, "log_buf_len"); + if (!temp) { + mpsslog("%s: log_buf_len not found: %d\n", mic->name, errno); + munmap(map, len); + close(fd); + return; + } + strncpy(log_buf, temp - 19, 16); + setsysfs(mic->name, "log_buf_len", log_buf); + mpsslog("%s: log_buf_len: %s\n", mic->name, log_buf); + munmap(map, len); + close(fd); +} + +static void init_mic(struct mic_info *mic); + +static void +change_virtblk_backend(int x, siginfo_t *siginfo, void *p) +{ + struct mic_info *mic; + + for (mic = mic_list.next; mic != NULL; mic = mic->next) + mic->mic_virtblk.signaled = 1/* true */; +} + +static void +init_mic(struct mic_info *mic) +{ + struct sigaction ignore = { + .sa_flags = 0, + .sa_handler = SIG_IGN + }; + struct sigaction act = { + .sa_flags = SA_SIGINFO, + .sa_sigaction = change_virtblk_backend, + }; + char buffer[PATH_MAX]; + int err; + + /* + * Currently, one virtio block device is supported for each MIC card + * at a time. Any user (or test) can send a SIGUSR1 to the MIC daemon. + * The signal informs the virtio block backend about a change in the + * configuration file which specifies the virtio backend file name on + * the host. Virtio block backend then re-reads the configuration file + * and switches to the new block device. This signalling mechanism may + * not be required once multiple virtio block devices are supported by + * the MIC daemon. + */ + sigaction(SIGUSR1, &ignore, NULL); + + mic->pid = fork(); + switch (mic->pid) { + case 0: + set_log_buf_info(mic); + set_cmdline(mic); + add_virtio_device(mic, &virtcons_dev_page.dd); + add_virtio_device(mic, &virtnet_dev_page.dd); + err = pthread_create(&mic->mic_console.console_thread, NULL, + virtio_console, mic); + if (err) + mpsslog("%s virtcons pthread_create failed %s\n", + mic->name, strerror(err)); + err = pthread_create(&mic->mic_net.net_thread, NULL, + virtio_net, mic); + if (err) + mpsslog("%s virtnet pthread_create failed %s\n", + mic->name, strerror(err)); + err = pthread_create(&mic->mic_virtblk.block_thread, NULL, + virtio_block, mic); + if (err) + mpsslog("%s virtblk pthread_create failed %s\n", + mic->name, strerror(err)); + sigemptyset(&act.sa_mask); + err = sigaction(SIGUSR1, &act, NULL); + if (err) + mpsslog("%s sigaction SIGUSR1 failed %s\n", + mic->name, strerror(errno)); + while (1) + sleep(60); + case -1: + mpsslog("fork failed MIC name %s id %d errno %d\n", + mic->name, mic->id, errno); + break; + default: + if (mic->restart) { + snprintf(buffer, PATH_MAX, "boot"); + setsysfs(mic->name, "state", buffer); + mpsslog("%s restarting mic %d\n", + mic->name, mic->restart); + mic->restart = 0; + } + pthread_create(&mic->config_thread, NULL, mic_config, mic); + } +} + +static void +start_daemon(void) +{ + struct mic_info *mic; + + for (mic = mic_list.next; mic != NULL; mic = mic->next) + init_mic(mic); + + while (1) + sleep(60); +} + +static int +init_mic_list(void) +{ + struct mic_info *mic = &mic_list; + struct dirent *file; + DIR *dp; + int cnt = 0; + + dp = opendir(MICSYSFSDIR); + if (!dp) + return 0; + + while ((file = readdir(dp)) != NULL) { + if (!strncmp(file->d_name, "mic", 3)) { + mic->next = calloc(1, sizeof(struct mic_info)); + if (mic->next) { + mic = mic->next; + mic->id = atoi(&file->d_name[3]); + mic->name = malloc(strlen(file->d_name) + 16); + if (mic->name) + strcpy(mic->name, file->d_name); + mpsslog("MIC name %s id %d\n", mic->name, + mic->id); + cnt++; + } + } + } + + closedir(dp); + return cnt; +} + +void +mpsslog(char *format, ...) +{ + va_list args; + char buffer[4096]; + char ts[52], *ts1; + time_t t; + + if (logfp == NULL) + return; + + va_start(args, format); + vsprintf(buffer, format, args); + va_end(args); + + time(&t); + ts1 = ctime_r(&t, ts); + ts1[strlen(ts1) - 1] = '\0'; + fprintf(logfp, "%s: %s", ts1, buffer); + + fflush(logfp); +} + +int +main(int argc, char *argv[]) +{ + int cnt; + pid_t pid; + + myname = argv[0]; + + logfp = fopen(LOGFILE_NAME, "a+"); + if (!logfp) { + fprintf(stderr, "cannot open logfile '%s'\n", LOGFILE_NAME); + exit(1); + } + pid = fork(); + switch (pid) { + case 0: + break; + case -1: + exit(2); + default: + exit(0); + } + + mpsslog("MIC Daemon start\n"); + + cnt = init_mic_list(); + if (cnt == 0) { + mpsslog("MIC module not loaded\n"); + exit(3); + } + mpsslog("MIC found %d devices\n", cnt); + + start_daemon(); + + exit(0); +} diff --git a/Documentation/mic/mpssd/mpssd.h b/Documentation/mic/mpssd/mpssd.h new file mode 100644 index 00000000000..f5f18b15d9a --- /dev/null +++ b/Documentation/mic/mpssd/mpssd.h @@ -0,0 +1,102 @@ +/* + * Intel MIC Platform Software Stack (MPSS) + * + * Copyright(c) 2013 Intel Corporation. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License, version 2, 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. + * + * The full GNU General Public License is included in this distribution in + * the file called "COPYING". + * + * Intel MIC User Space Tools. + */ +#ifndef _MPSSD_H_ +#define _MPSSD_H_ + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <fcntl.h> +#include <unistd.h> +#include <dirent.h> +#include <libgen.h> +#include <pthread.h> +#include <stdarg.h> +#include <time.h> +#include <errno.h> +#include <sys/dir.h> +#include <sys/ioctl.h> +#include <sys/poll.h> +#include <sys/types.h> +#include <sys/socket.h> +#include <sys/stat.h> +#include <sys/types.h> +#include <sys/mman.h> +#include <sys/utsname.h> +#include <sys/wait.h> +#include <netinet/in.h> +#include <arpa/inet.h> +#include <netdb.h> +#include <pthread.h> +#include <signal.h> +#include <limits.h> +#include <syslog.h> +#include <getopt.h> +#include <net/if.h> +#include <linux/if_tun.h> +#include <linux/if_tun.h> +#include <linux/virtio_ids.h> + +#define MICSYSFSDIR "/sys/class/mic" +#define LOGFILE_NAME "/var/log/mpssd" +#define PAGE_SIZE 4096 + +struct mic_console_info { + pthread_t console_thread; + int virtio_console_fd; + void *console_dp; +}; + +struct mic_net_info { + pthread_t net_thread; + int virtio_net_fd; + int tap_fd; + void *net_dp; +}; + +struct mic_virtblk_info { + pthread_t block_thread; + int virtio_block_fd; + void *block_dp; + volatile sig_atomic_t signaled; + char *backend_file; + int backend; + void *backend_addr; + long backend_size; +}; + +struct mic_info { + int id; + char *name; + pthread_t config_thread; + pid_t pid; + struct mic_console_info mic_console; + struct mic_net_info mic_net; + struct mic_virtblk_info mic_virtblk; + int restart; + int boot_on_resume; + struct mic_info *next; +}; + +__attribute__((format(printf, 1, 2))) +void mpsslog(char *format, ...); +char *readsysfs(char *dir, char *entry); +int setsysfs(char *dir, char *entry, char *value); +#endif diff --git a/Documentation/mic/mpssd/sysfs.c b/Documentation/mic/mpssd/sysfs.c new file mode 100644 index 00000000000..8dd32693608 --- /dev/null +++ b/Documentation/mic/mpssd/sysfs.c @@ -0,0 +1,102 @@ +/* + * Intel MIC Platform Software Stack (MPSS) + * + * Copyright(c) 2013 Intel Corporation. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License, version 2, 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. + * + * The full GNU General Public License is included in this distribution in + * the file called "COPYING". + * + * Intel MIC User Space Tools. + */ + +#include "mpssd.h" + +#define PAGE_SIZE 4096 + +char * +readsysfs(char *dir, char *entry) +{ + char filename[PATH_MAX]; + char value[PAGE_SIZE]; + char *string = NULL; + int fd; + int len; + + if (dir == NULL) + snprintf(filename, PATH_MAX, "%s/%s", MICSYSFSDIR, entry); + else + snprintf(filename, PATH_MAX, + "%s/%s/%s", MICSYSFSDIR, dir, entry); + + fd = open(filename, O_RDONLY); + if (fd < 0) { + mpsslog("Failed to open sysfs entry '%s': %s\n", + filename, strerror(errno)); + return NULL; + } + + len = read(fd, value, sizeof(value)); + if (len < 0) { + mpsslog("Failed to read sysfs entry '%s': %s\n", + filename, strerror(errno)); + goto readsys_ret; + } + if (len == 0) + goto readsys_ret; + + value[len - 1] = '\0'; + + string = malloc(strlen(value) + 1); + if (string) + strcpy(string, value); + +readsys_ret: + close(fd); + return string; +} + +int +setsysfs(char *dir, char *entry, char *value) +{ + char filename[PATH_MAX]; + char *oldvalue; + int fd, ret = 0; + + if (dir == NULL) + snprintf(filename, PATH_MAX, "%s/%s", MICSYSFSDIR, entry); + else + snprintf(filename, PATH_MAX, "%s/%s/%s", + MICSYSFSDIR, dir, entry); + + oldvalue = readsysfs(dir, entry); + + fd = open(filename, O_RDWR); + if (fd < 0) { + ret = errno; + mpsslog("Failed to open sysfs entry '%s': %s\n", + filename, strerror(errno)); + goto done; + } + + if (!oldvalue || strcmp(value, oldvalue)) { + if (write(fd, value, strlen(value)) < 0) { + ret = errno; + mpsslog("Failed to write new sysfs entry '%s': %s\n", + filename, strerror(errno)); + } + } + close(fd); +done: + if (oldvalue) + free(oldvalue); + return ret; +} diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt index c1d82047a4b..89490beb3c0 100644 --- a/Documentation/networking/batman-adv.txt +++ b/Documentation/networking/batman-adv.txt @@ -69,8 +69,7 @@ folder: # 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 +# bridge_loop_avoidance hop_penalty fragmentation There is a special folder for debugging information: @@ -78,7 +77,7 @@ There is a special folder for debugging information: # ls /sys/kernel/debug/batman_adv/bat0/ # bla_backbone_table log transtable_global # bla_claim_table originators transtable_local -# gateways socket vis_data +# gateways socket Some of the files contain all sort of status information regard- ing the mesh network. For example, you can view the table of @@ -127,51 +126,6 @@ ously assigned to interfaces now used by batman advanced, e.g. # ifconfig eth0 0.0.0.0 -VISUALIZATION -------------- - -If you want topology visualization, at least one mesh node must -be configured as VIS-server: - -# echo "server" > /sys/class/net/bat0/mesh/vis_mode - -Each node is either configured as "server" or as "client" (de- -fault: "client"). Clients send their topology data to the server -next to them, and server synchronize with other servers. If there -is no server configured (default) within the mesh, no topology -information will be transmitted. With these "synchronizing -servers", there can be 1 or more vis servers sharing the same (or -at least very similar) data. - -When configured as server, you can get a topology snapshot of -your mesh: - -# cat /sys/kernel/debug/batman_adv/bat0/vis_data - -This raw output is intended to be easily parsable and convertable -with other tools. Have a look at the batctl README if you want a -vis output in dot or json format for instance and how those out- -puts could then be visualised in an image. - -The raw format consists of comma separated values per entry where -each entry is giving information about a certain source inter- -face. Each entry can/has to have the following values: --> "mac" - mac address of an originator's source interface - (each line begins with it) --> "TQ mac value" - src mac's link quality towards mac address - of a neighbor originator's interface which - is being used for routing --> "TT mac" - TT announced by source mac --> "PRIMARY" - this is a primary interface --> "SEC mac" - secondary mac address of source - (requires preceding PRIMARY) - -The TQ value has a range from 4 to 255 with 255 being the best. -The TT entries are showing which hosts are connected to the mesh -via bat0 or being bridged into the mesh network. The PRIMARY/SEC -values are only applied on primary interfaces - - LOGGING/DEBUGGING ----------------- @@ -245,5 +199,5 @@ Mailing-list: b.a.t.m.a.n@open-mesh.org (optional subscription You can also contact the Authors: -Marek Lindner <lindner_marek@yahoo.de> -Simon Wunderlich <siwu@hrz.tu-chemnitz.de> +Marek Lindner <mareklindner@neomailbox.ch> +Simon Wunderlich <sw@simonwunderlich.de> diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 9b28e714831..2cdb8b66caa 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -639,6 +639,15 @@ num_unsol_na are generated by the ipv4 and ipv6 code and the numbers of repetitions cannot be set independently. +packets_per_slave + + Specify the number of packets to transmit through a slave before + moving to the next one. When set to 0 then a slave is chosen at + random. + + The valid range is 0 - 65535; the default value is 1. This option + has effect only in balance-rr mode. + primary A string (eth0, eth2, etc) specifying which slave is the @@ -743,21 +752,16 @@ xmit_hash_policy protocol information to generate the hash. Uses XOR of hardware MAC addresses and IP addresses to - generate the hash. The IPv4 formula is - - (((source IP XOR dest IP) AND 0xffff) XOR - ( source MAC XOR destination MAC )) - modulo slave count - - The IPv6 formula is + generate the hash. The formula is - hash = (source ip quad 2 XOR dest IP quad 2) XOR - (source ip quad 3 XOR dest IP quad 3) XOR - (source ip quad 4 XOR dest IP quad 4) + hash = source MAC XOR destination MAC + hash = hash XOR source IP XOR destination IP + hash = hash XOR (hash RSHIFT 16) + hash = hash XOR (hash RSHIFT 8) + And then hash is reduced modulo slave count. - (((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash) - XOR (source MAC XOR destination MAC)) - modulo slave count + If the protocol is IPv6 then the source and destination + addresses are first hashed using ipv6_addr_hash. This algorithm will place all traffic to a particular network peer on the same slave. For non-IP traffic, @@ -779,21 +783,16 @@ xmit_hash_policy slaves, although a single connection will not span multiple slaves. - The formula for unfragmented IPv4 TCP and UDP packets is + The formula for unfragmented TCP and UDP packets is - ((source port XOR dest port) XOR - ((source IP XOR dest IP) AND 0xffff) - modulo slave count + hash = source port, destination port (as in the header) + hash = hash XOR source IP XOR destination IP + hash = hash XOR (hash RSHIFT 16) + hash = hash XOR (hash RSHIFT 8) + And then hash is reduced modulo slave count. - The formula for unfragmented IPv6 TCP and UDP packets is - - hash = (source port XOR dest port) XOR - ((source ip quad 2 XOR dest IP quad 2) XOR - (source ip quad 3 XOR dest IP quad 3) XOR - (source ip quad 4 XOR dest IP quad 4)) - - ((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash) - modulo slave count + If the protocol is IPv6 then the source and destination + addresses are first hashed using ipv6_addr_hash. For fragmented TCP or UDP packets and all other IPv4 and IPv6 protocol traffic, the source and destination port @@ -801,10 +800,6 @@ xmit_hash_policy formula is the same as for the layer2 transmit hash policy. - The IPv4 policy is intended to mimic the behavior of - certain switches, notably Cisco switches with PFC2 as - well as some Foundry and IBM products. - This algorithm is not fully 802.3ad compliant. A single TCP or UDP conversation containing both fragmented and unfragmented packets will see packets @@ -815,6 +810,26 @@ xmit_hash_policy conversations. Other implementations of 802.3ad may or may not tolerate this noncompliance. + encap2+3 + + This policy uses the same formula as layer2+3 but it + relies on skb_flow_dissect to obtain the header fields + which might result in the use of inner headers if an + encapsulation protocol is used. For example this will + improve the performance for tunnel users because the + packets will be distributed according to the encapsulated + flows. + + encap3+4 + + This policy uses the same formula as layer3+4 but it + relies on skb_flow_dissect to obtain the header fields + which might result in the use of inner headers if an + encapsulation protocol is used. For example this will + improve the performance for tunnel users because the + packets will be distributed according to the encapsulated + flows. + The default value is layer2. This option was added in bonding version 2.6.3. In earlier versions of bonding, this parameter does not exist, and the layer2 policy is the only policy. The diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 820f55344ed..4c072414ead 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -25,6 +25,12 @@ This file contains 4.1.5 RAW socket option CAN_RAW_FD_FRAMES 4.1.6 RAW socket returned message flags 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) + 4.2.1 Broadcast Manager operations + 4.2.2 Broadcast Manager message flags + 4.2.3 Broadcast Manager transmission timers + 4.2.4 Broadcast Manager message sequence transmission + 4.2.5 Broadcast Manager receive filter timers + 4.2.6 Broadcast Manager multiplex message receive filter 4.3 connected transport protocols (SOCK_SEQPACKET) 4.4 unconnected transport protocols (SOCK_DGRAM) @@ -593,6 +599,217 @@ solution for a couple of reasons: In order to receive such messages, CAN_RAW_RECV_OWN_MSGS must be set. 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) + + The Broadcast Manager protocol provides a command based configuration + interface to filter and send (e.g. cyclic) CAN messages in kernel space. + + Receive filters can be used to down sample frequent messages; detect events + such as message contents changes, packet length changes, and do time-out + monitoring of received messages. + + Periodic transmission tasks of CAN frames or a sequence of CAN frames can be + created and modified at runtime; both the message content and the two + possible transmit intervals can be altered. + + A BCM socket is not intended for sending individual CAN frames using the + struct can_frame as known from the CAN_RAW socket. Instead a special BCM + configuration message is defined. The basic BCM configuration message used + to communicate with the broadcast manager and the available operations are + defined in the linux/can/bcm.h include. The BCM message consists of a + message header with a command ('opcode') followed by zero or more CAN frames. + The broadcast manager sends responses to user space in the same form: + + struct bcm_msg_head { + __u32 opcode; /* command */ + __u32 flags; /* special flags */ + __u32 count; /* run 'count' times with ival1 */ + struct timeval ival1, ival2; /* count and subsequent interval */ + canid_t can_id; /* unique can_id for task */ + __u32 nframes; /* number of can_frames following */ + struct can_frame frames[0]; + }; + + The aligned payload 'frames' uses the same basic CAN frame structure defined + at the beginning of section 4 and in the include/linux/can.h include. All + messages to the broadcast manager from user space have this structure. + + Note a CAN_BCM socket must be connected instead of bound after socket + creation (example without error checking): + + int s; + struct sockaddr_can addr; + struct ifreq ifr; + + s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM); + + strcpy(ifr.ifr_name, "can0"); + ioctl(s, SIOCGIFINDEX, &ifr); + + addr.can_family = AF_CAN; + addr.can_ifindex = ifr.ifr_ifindex; + + connect(s, (struct sockaddr *)&addr, sizeof(addr)) + + (..) + + The broadcast manager socket is able to handle any number of in flight + transmissions or receive filters concurrently. The different RX/TX jobs are + distinguished by the unique can_id in each BCM message. However additional + CAN_BCM sockets are recommended to communicate on multiple CAN interfaces. + When the broadcast manager socket is bound to 'any' CAN interface (=> the + interface index is set to zero) the configured receive filters apply to any + CAN interface unless the sendto() syscall is used to overrule the 'any' CAN + interface index. When using recvfrom() instead of read() to retrieve BCM + socket messages the originating CAN interface is provided in can_ifindex. + + 4.2.1 Broadcast Manager operations + + The opcode defines the operation for the broadcast manager to carry out, + or details the broadcast managers response to several events, including + user requests. + + Transmit Operations (user space to broadcast manager): + + TX_SETUP: Create (cyclic) transmission task. + + TX_DELETE: Remove (cyclic) transmission task, requires only can_id. + + TX_READ: Read properties of (cyclic) transmission task for can_id. + + TX_SEND: Send one CAN frame. + + Transmit Responses (broadcast manager to user space): + + TX_STATUS: Reply to TX_READ request (transmission task configuration). + + TX_EXPIRED: Notification when counter finishes sending at initial interval + 'ival1'. Requires the TX_COUNTEVT flag to be set at TX_SETUP. + + Receive Operations (user space to broadcast manager): + + RX_SETUP: Create RX content filter subscription. + + RX_DELETE: Remove RX content filter subscription, requires only can_id. + + RX_READ: Read properties of RX content filter subscription for can_id. + + Receive Responses (broadcast manager to user space): + + RX_STATUS: Reply to RX_READ request (filter task configuration). + + RX_TIMEOUT: Cyclic message is detected to be absent (timer ival1 expired). + + RX_CHANGED: BCM message with updated CAN frame (detected content change). + Sent on first message received or on receipt of revised CAN messages. + + 4.2.2 Broadcast Manager message flags + + When sending a message to the broadcast manager the 'flags' element may + contain the following flag definitions which influence the behaviour: + + SETTIMER: Set the values of ival1, ival2 and count + + STARTTIMER: Start the timer with the actual values of ival1, ival2 + and count. Starting the timer leads simultaneously to emit a CAN frame. + + TX_COUNTEVT: Create the message TX_EXPIRED when count expires + + TX_ANNOUNCE: A change of data by the process is emitted immediately. + + TX_CP_CAN_ID: Copies the can_id from the message header to each + subsequent frame in frames. This is intended as usage simplification. For + TX tasks the unique can_id from the message header may differ from the + can_id(s) stored for transmission in the subsequent struct can_frame(s). + + RX_FILTER_ID: Filter by can_id alone, no frames required (nframes=0). + + RX_CHECK_DLC: A change of the DLC leads to an RX_CHANGED. + + RX_NO_AUTOTIMER: Prevent automatically starting the timeout monitor. + + RX_ANNOUNCE_RESUME: If passed at RX_SETUP and a receive timeout occured, a + RX_CHANGED message will be generated when the (cyclic) receive restarts. + + TX_RESET_MULTI_IDX: Reset the index for the multiple frame transmission. + + RX_RTR_FRAME: Send reply for RTR-request (placed in op->frames[0]). + + 4.2.3 Broadcast Manager transmission timers + + Periodic transmission configurations may use up to two interval timers. + In this case the BCM sends a number of messages ('count') at an interval + 'ival1', then continuing to send at another given interval 'ival2'. When + only one timer is needed 'count' is set to zero and only 'ival2' is used. + When SET_TIMER and START_TIMER flag were set the timers are activated. + The timer values can be altered at runtime when only SET_TIMER is set. + + 4.2.4 Broadcast Manager message sequence transmission + + Up to 256 CAN frames can be transmitted in a sequence in the case of a cyclic + TX task configuration. The number of CAN frames is provided in the 'nframes' + element of the BCM message head. The defined number of CAN frames are added + as array to the TX_SETUP BCM configuration message. + + /* create a struct to set up a sequence of four CAN frames */ + struct { + struct bcm_msg_head msg_head; + struct can_frame frame[4]; + } mytxmsg; + + (..) + mytxmsg.nframes = 4; + (..) + + write(s, &mytxmsg, sizeof(mytxmsg)); + + With every transmission the index in the array of CAN frames is increased + and set to zero at index overflow. + + 4.2.5 Broadcast Manager receive filter timers + + The timer values ival1 or ival2 may be set to non-zero values at RX_SETUP. + When the SET_TIMER flag is set the timers are enabled: + + ival1: Send RX_TIMEOUT when a received message is not received again within + the given time. When START_TIMER is set at RX_SETUP the timeout detection + is activated directly - even without a former CAN frame reception. + + ival2: Throttle the received message rate down to the value of ival2. This + is useful to reduce messages for the application when the signal inside the + CAN frame is stateless as state changes within the ival2 periode may get + lost. + + 4.2.6 Broadcast Manager multiplex message receive filter + + To filter for content changes in multiplex message sequences an array of more + than one CAN frames can be passed in a RX_SETUP configuration message. The + data bytes of the first CAN frame contain the mask of relevant bits that + have to match in the subsequent CAN frames with the received CAN frame. + If one of the subsequent CAN frames is matching the bits in that frame data + mark the relevant content to be compared with the previous received content. + Up to 257 CAN frames (multiplex filter bit mask CAN frame plus 256 CAN + filters) can be added as array to the TX_SETUP BCM configuration message. + + /* usually used to clear CAN frame data[] - beware of endian problems! */ + #define U64_DATA(p) (*(unsigned long long*)(p)->data) + + struct { + struct bcm_msg_head msg_head; + struct can_frame frame[5]; + } msg; + + msg.msg_head.opcode = RX_SETUP; + msg.msg_head.can_id = 0x42; + msg.msg_head.flags = 0; + msg.msg_head.nframes = 5; + U64_DATA(&msg.frame[0]) = 0xFF00000000000000ULL; /* MUX mask */ + U64_DATA(&msg.frame[1]) = 0x01000000000000FFULL; /* data mask (MUX 0x01) */ + U64_DATA(&msg.frame[2]) = 0x0200FFFF000000FFULL; /* data mask (MUX 0x02) */ + U64_DATA(&msg.frame[3]) = 0x330000FFFFFF0003ULL; /* data mask (MUX 0x33) */ + U64_DATA(&msg.frame[4]) = 0x4F07FC0FF0000000ULL; /* data mask (MUX 0x4F) */ + + write(s, &msg, sizeof(msg)); + 4.3 connected transport protocols (SOCK_SEQPACKET) 4.4 unconnected transport protocols (SOCK_DGRAM) diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt index d718bc2ff1c..bf5dbe3ab8c 100644 --- a/Documentation/networking/dccp.txt +++ b/Documentation/networking/dccp.txt @@ -18,8 +18,8 @@ Introduction Datagram Congestion Control Protocol (DCCP) is an unreliable, connection oriented protocol designed to solve issues present in UDP and TCP, particularly for real-time and multimedia (streaming) traffic. -It divides into a base protocol (RFC 4340) and plugable congestion control -modules called CCIDs. Like plugable TCP congestion control, at least one CCID +It divides into a base protocol (RFC 4340) and pluggable congestion control +modules called CCIDs. Like pluggable TCP congestion control, at least one CCID needs to be enabled in order for the protocol to function properly. In the Linux implementation, this is the TCP-like CCID2 (RFC 4341). Additional CCIDs, such as the TCP-friendly CCID3 (RFC 4342), are optional. diff --git a/Documentation/networking/e100.txt b/Documentation/networking/e100.txt index 13a32124bca..f862cf3aff3 100644 --- a/Documentation/networking/e100.txt +++ b/Documentation/networking/e100.txt @@ -103,7 +103,7 @@ Additional Configurations PRO/100 Family of Adapters is e100. As an example, if you install the e100 driver for two PRO/100 adapters - (eth0 and eth1), add the following to a configuraton file in /etc/modprobe.d/ + (eth0 and eth1), add the following to a configuration file in /etc/modprobe.d/ alias eth0 e100 alias eth1 e100 diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt index 09eb57329f1..22bbc7225f8 100644 --- a/Documentation/networking/ieee802154.txt +++ b/Documentation/networking/ieee802154.txt @@ -4,7 +4,7 @@ Introduction ============ -The IEEE 802.15.4 working group focuses on standartization of bottom +The IEEE 802.15.4 working group focuses on standardization of bottom two layers: Medium Access Control (MAC) and Physical (PHY). And there are mainly two options available for upper layers: - ZigBee - proprietary protocol from ZigBee Alliance @@ -66,7 +66,7 @@ net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family code via plain sk_buffs. On skb reception skb->cb must contain additional info as described in the struct ieee802154_mac_cb. During packet transmission the skb->cb is used to provide additional data to device's header_ops->create -function. Be aware, that this data can be overriden later (when socket code +function. Be aware that this data can be overridden later (when socket code submits skb to qdisc), so if you need something from that cb later, you should store info in the skb->data on your own. diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index a46d78583ae..8b8a0578764 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -267,17 +267,6 @@ tcp_max_orphans - INTEGER more aggressively. Let me to remind again: each orphan eats up to ~64K of unswappable memory. -tcp_max_ssthresh - INTEGER - Limited Slow-Start for TCP with large congestion windows (cwnd) defined in - RFC3742. Limited slow-start is a mechanism to limit growth of the cwnd - on the region where cwnd is larger than tcp_max_ssthresh. TCP increases cwnd - by at most tcp_max_ssthresh segments, and by at least tcp_max_ssthresh/2 - segments per RTT when the cwnd is above tcp_max_ssthresh. - If TCP connection increased cwnd to thousands (or tens of thousands) segments, - and thousands of packets were being dropped during slow-start, you can set - tcp_max_ssthresh to improve performance for new TCP connection. - Default: 0 (off) - tcp_max_syn_backlog - INTEGER Maximal number of remembered connection requests, which have not received an acknowledgment from connecting client. @@ -451,7 +440,7 @@ tcp_fastopen - INTEGER connect() to perform a TCP handshake automatically. The values (bitmap) are - 1: Enables sending data in the opening SYN on the client. + 1: Enables sending data in the opening SYN on the client w/ MSG_FASTOPEN. 2: Enables TCP Fast Open on the server side, i.e., allowing data in a SYN packet to be accepted and passed to the application before 3-way hand shake finishes. @@ -464,7 +453,7 @@ tcp_fastopen - INTEGER different ways of setting max_qlen without the TCP_FASTOPEN socket option. - Default: 0 + Default: 1 Note that the client & server side Fast Open flags (1 and 2 respectively) must be also enabled before the rest of flags can take diff --git a/Documentation/networking/l2tp.txt b/Documentation/networking/l2tp.txt index e63fc1f7bf8..c74434de2fa 100644 --- a/Documentation/networking/l2tp.txt +++ b/Documentation/networking/l2tp.txt @@ -197,7 +197,7 @@ state information because the file format is subject to change. It is implemented to provide extra debug information to help diagnose problems.) Users should use the netlink API. -/proc/net/pppol2tp is also provided for backwards compaibility with +/proc/net/pppol2tp is also provided for backwards compatibility with the original pppol2tp driver. It lists information about L2TPv2 tunnels and sessions only. Its use is discouraged. diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt index d9112f01c44..0fe1c6e0dbc 100644 --- a/Documentation/networking/netdev-FAQ.txt +++ b/Documentation/networking/netdev-FAQ.txt @@ -4,23 +4,23 @@ Information you need to know about netdev Q: What is netdev? -A: It is a mailing list for all network related linux stuff. This includes +A: It is a mailing list for all network-related Linux stuff. This includes anything found under net/ (i.e. core code like IPv6) and drivers/net - (i.e. hardware specific drivers) in the linux source tree. + (i.e. hardware specific drivers) in the Linux source tree. Note that some subsystems (e.g. wireless drivers) which have a high volume of traffic have their own specific mailing lists. - The netdev list is managed (like many other linux mailing lists) through + The netdev list is managed (like many other Linux mailing lists) through VGER ( http://vger.kernel.org/ ) and archives can be found below: http://marc.info/?l=linux-netdev http://www.spinics.net/lists/netdev/ - Aside from subsystems like that mentioned above, all network related linux - development (i.e. RFC, review, comments, etc) takes place on netdev. + Aside from subsystems like that mentioned above, all network-related Linux + development (i.e. RFC, review, comments, etc.) takes place on netdev. -Q: How do the changes posted to netdev make their way into linux? +Q: How do the changes posted to netdev make their way into Linux? A: There are always two trees (git repositories) in play. Both are driven by David Miller, the main network maintainer. There is the "net" tree, @@ -35,7 +35,7 @@ A: There are always two trees (git repositories) in play. Both are driven Q: How often do changes from these trees make it to the mainline Linus tree? A: To understand this, you need to know a bit of background information - on the cadence of linux development. Each new release starts off with + on the cadence of Linux development. Each new release starts off with a two week "merge window" where the main maintainers feed their new stuff to Linus for merging into the mainline tree. After the two weeks, the merge window is closed, and it is called/tagged "-rc1". No new @@ -46,7 +46,7 @@ A: To understand this, you need to know a bit of background information things are in a state of churn), and a week after the last vX.Y-rcN was done, the official "vX.Y" is released. - Relating that to netdev: At the beginning of the 2 week merge window, + Relating that to netdev: At the beginning of the 2-week merge window, the net-next tree will be closed - no new changes/features. The accumulated new content of the past ~10 weeks will be passed onto mainline/Linus via a pull request for vX.Y -- at the same time, @@ -59,16 +59,16 @@ A: To understand this, you need to know a bit of background information IMPORTANT: Do not send new net-next content to netdev during the period during which net-next tree is closed. - Shortly after the two weeks have passed, (and vX.Y-rc1 is released) the + Shortly after the two weeks have passed (and vX.Y-rc1 is released), the tree for net-next reopens to collect content for the next (vX.Y+1) release. If you aren't subscribed to netdev and/or are simply unsure if net-next has re-opened yet, simply check the net-next git repository link above for - any new networking related commits. + any new networking-related commits. The "net" tree continues to collect fixes for the vX.Y content, and is fed back to Linus at regular (~weekly) intervals. Meaning that the - focus for "net" is on stablilization and bugfixes. + focus for "net" is on stabilization and bugfixes. Finally, the vX.Y gets released, and the whole cycle starts over. @@ -217,7 +217,7 @@ A: Attention to detail. Re-read your own work as if you were the to why it happens, and then if necessary, explain why the fix proposed is the best way to get things done. Don't mangle whitespace, and as is common, don't mis-indent function arguments that span multiple lines. - If it is your 1st patch, mail it to yourself so you can test apply + If it is your first patch, mail it to yourself so you can test apply it to an unpatched tree to confirm infrastructure didn't mangle it. Finally, go back and read Documentation/SubmittingPatches to be diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt index c7ecc708049..0b1cf6b2a59 100644 --- a/Documentation/networking/netdevices.txt +++ b/Documentation/networking/netdevices.txt @@ -10,12 +10,12 @@ network devices. struct net_device allocation rules ================================== Network device structures need to persist even after module is unloaded and -must be allocated with kmalloc. If device has registered successfully, -it will be freed on last use by free_netdev. This is required to handle the -pathologic case cleanly (example: rmmod mydriver </sys/class/net/myeth/mtu ) +must be allocated with alloc_netdev_mqs() and friends. +If device has registered successfully, it will be freed on last use +by free_netdev(). This is required to handle the pathologic case cleanly +(example: rmmod mydriver </sys/class/net/myeth/mtu ) -There are routines in net_init.c to handle the common cases of -alloc_etherdev, alloc_netdev. These reserve extra space for driver +alloc_netdev_mqs()/alloc_netdev() reserve extra space for driver private data which gets freed when the network device is freed. If separately allocated data is attached to the network device (netdev_priv(dev)) then it is up to the module exit handler to free that. diff --git a/Documentation/networking/netlink_mmap.txt b/Documentation/networking/netlink_mmap.txt index 53337883954..b2612297352 100644 --- a/Documentation/networking/netlink_mmap.txt +++ b/Documentation/networking/netlink_mmap.txt @@ -45,7 +45,7 @@ processing. Conversion of the reception path involves calling poll() on the file descriptor, once the socket is readable the frames from the ring are -processsed in order until no more messages are available, as indicated by +processed in order until no more messages are available, as indicated by a status word in the frame header. On kernel side, in order to make use of memory mapped I/O on receive, the @@ -56,7 +56,7 @@ Dumps of kernel databases automatically support memory mapped I/O. Conversion of the transmit path involves changing message construction to use memory from the TX ring instead of (usually) a buffer declared on the -stack and setting up the frame header approriately. Optionally poll() can +stack and setting up the frame header appropriately. Optionally poll() can be used to wait for free frames in the TX ring. Structured and definitions for using memory mapped I/O are contained in @@ -231,7 +231,7 @@ Ring setup: if (setsockopt(fd, NETLINK_TX_RING, &req, sizeof(req)) < 0) exit(1) - /* Calculate size of each invididual ring */ + /* Calculate size of each individual ring */ ring_size = req.nm_block_nr * req.nm_block_size; /* Map RX/TX rings. The TX ring is located after the RX ring */ diff --git a/Documentation/networking/operstates.txt b/Documentation/networking/operstates.txt index 97694572338..355c6d8ef8a 100644 --- a/Documentation/networking/operstates.txt +++ b/Documentation/networking/operstates.txt @@ -89,8 +89,8 @@ packets. The name 'carrier' and the inversion are historical, think of it as lower layer. Note that for certain kind of soft-devices, which are not managing any -real hardware, there is possible to set this bit from userpsace. -One should use TVL IFLA_CARRIER to do so. +real hardware, it is possible to set this bit from userspace. One +should use TVL IFLA_CARRIER to do so. netif_carrier_ok() can be used to query that bit. diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt index 60d05eb77c6..b89bc82eed4 100644 --- a/Documentation/networking/rxrpc.txt +++ b/Documentation/networking/rxrpc.txt @@ -144,7 +144,7 @@ An overview of the RxRPC protocol: (*) Calls use ACK packets to handle reliability. Data packets are also explicitly sequenced per call. - (*) There are two types of positive acknowledgement: hard-ACKs and soft-ACKs. + (*) There are two types of positive acknowledgment: hard-ACKs and soft-ACKs. A hard-ACK indicates to the far side that all the data received to a point has been received and processed; a soft-ACK indicates that the data has been received but may yet be discarded and re-requested. The sender may diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt index 457b8bbafb0..cdd916da838 100644 --- a/Documentation/networking/stmmac.txt +++ b/Documentation/networking/stmmac.txt @@ -160,7 +160,7 @@ Where: o pmt: core has the embedded power module (optional). o force_sf_dma_mode: force DMA to use the Store and Forward mode instead of the Threshold. - o force_thresh_dma_mode: force DMA to use the Shreshold mode other than + o force_thresh_dma_mode: force DMA to use the Threshold mode other than the Store and Forward mode. o riwt_off: force to disable the RX watchdog feature and switch to NAPI mode. o fix_mac_speed: this callback is used for modifying some syscfg registers @@ -175,7 +175,7 @@ Where: registers. o custom_cfg/custom_data: this is a custom configuration that can be passed while initializing the resources. - o bsp_priv: another private poiter. + o bsp_priv: another private pointer. For MDIO bus The we have: @@ -271,7 +271,7 @@ reset procedure etc). o dwmac1000_dma.c: dma functions for the GMAC chip; o dwmac1000.h: specific header file for the GMAC; o dwmac100_core: MAC 100 core and dma code; - o dwmac100_dma.c: dma funtions for the MAC chip; + o dwmac100_dma.c: dma functions for the MAC chip; o dwmac1000.h: specific header file for the MAC; o dwmac_lib.c: generic DMA functions shared among chips; o enh_desc.c: functions for handling enhanced descriptors; @@ -364,4 +364,4 @@ Auto-negotiated Link Parter Ability. 10) TODO: o XGMAC is not supported. o Complete the TBI & RTBI support. - o extened VLAN support for 3.70a SYNP GMAC. + o extend VLAN support for 3.70a SYNP GMAC. diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt index 9a8041dcbb5..97282da82b7 100644 --- a/Documentation/networking/vortex.txt +++ b/Documentation/networking/vortex.txt @@ -68,7 +68,7 @@ Module parameters There are several parameters which may be provided to the driver when its module is loaded. These are usually placed in /etc/modprobe.d/*.conf -configuretion files. Example: +configuration files. Example: options 3c59x debug=3 rx_copybreak=300 @@ -178,7 +178,7 @@ max_interrupt_work=N The driver's interrupt service routine can handle many receive and transmit packets in a single invocation. It does this in a loop. - The value of max_interrupt_work governs how mnay times the interrupt + The value of max_interrupt_work governs how many times the interrupt service routine will loop. The default value is 32 loops. If this is exceeded the interrupt service routine gives up and generates a warning message "eth0: Too much work in interrupt". diff --git a/Documentation/networking/x25-iface.txt b/Documentation/networking/x25-iface.txt index 78f662ee062..7f213b556e8 100644 --- a/Documentation/networking/x25-iface.txt +++ b/Documentation/networking/x25-iface.txt @@ -105,7 +105,7 @@ reduced by the following measures or a combination thereof: later. The lapb module interface was modified to support this. Its data_indication() method should now transparently pass the - netif_rx() return value to the (lapb mopdule) caller. + netif_rx() return value to the (lapb module) caller. (2) Drivers for kernel versions 2.2.x should always check the global variable netdev_dropping when a new frame is received. The driver should only call netif_rx() if netdev_dropping is zero. Otherwise diff --git a/Documentation/phy.txt b/Documentation/phy.txt new file mode 100644 index 00000000000..0103e4b15b0 --- /dev/null +++ b/Documentation/phy.txt @@ -0,0 +1,166 @@ + PHY SUBSYSTEM + Kishon Vijay Abraham I <kishon@ti.com> + +This document explains the Generic PHY Framework along with the APIs provided, +and how-to-use. + +1. Introduction + +*PHY* is the abbreviation for physical layer. It is used to connect a device +to the physical medium e.g., the USB controller has a PHY to provide functions +such as serialization, de-serialization, encoding, decoding and is responsible +for obtaining the required data transmission rate. Note that some USB +controllers have PHY functionality embedded into it and others use an external +PHY. Other peripherals that use PHY include Wireless LAN, Ethernet, +SATA etc. + +The intention of creating this framework is to bring the PHY drivers spread +all over the Linux kernel to drivers/phy to increase code re-use and for +better code maintainability. + +This framework will be of use only to devices that use external PHY (PHY +functionality is not embedded within the controller). + +2. Registering/Unregistering the PHY provider + +PHY provider refers to an entity that implements one or more PHY instances. +For the simple case where the PHY provider implements only a single instance of +the PHY, the framework provides its own implementation of of_xlate in +of_phy_simple_xlate. If the PHY provider implements multiple instances, it +should provide its own implementation of of_xlate. of_xlate is used only for +dt boot case. + +#define of_phy_provider_register(dev, xlate) \ + __of_phy_provider_register((dev), THIS_MODULE, (xlate)) + +#define devm_of_phy_provider_register(dev, xlate) \ + __devm_of_phy_provider_register((dev), THIS_MODULE, (xlate)) + +of_phy_provider_register and devm_of_phy_provider_register macros can be used to +register the phy_provider and it takes device and of_xlate as +arguments. For the dt boot case, all PHY providers should use one of the above +2 macros to register the PHY provider. + +void devm_of_phy_provider_unregister(struct device *dev, + struct phy_provider *phy_provider); +void of_phy_provider_unregister(struct phy_provider *phy_provider); + +devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to +unregister the PHY. + +3. Creating the PHY + +The PHY driver should create the PHY in order for other peripheral controllers +to make use of it. The PHY framework provides 2 APIs to create the PHY. + +struct phy *phy_create(struct device *dev, const struct phy_ops *ops, + struct phy_init_data *init_data); +struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops, + struct phy_init_data *init_data); + +The PHY drivers can use one of the above 2 APIs to create the PHY by passing +the device pointer, phy ops and init_data. +phy_ops is a set of function pointers for performing PHY operations such as +init, exit, power_on and power_off. *init_data* is mandatory to get a reference +to the PHY in the case of non-dt boot. See section *Board File Initialization* +on how init_data should be used. + +Inorder to dereference the private data (in phy_ops), the phy provider driver +can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in +phy_ops to get back the private data. + +4. Getting a reference to the PHY + +Before the controller can make use of the PHY, it has to get a reference to +it. This framework provides the following APIs to get a reference to the PHY. + +struct phy *phy_get(struct device *dev, const char *string); +struct phy *devm_phy_get(struct device *dev, const char *string); + +phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot, +the string arguments should contain the phy name as given in the dt data and +in the case of non-dt boot, it should contain the label of the PHY. +The only difference between the two APIs is that devm_phy_get associates the +device with the PHY using devres on successful PHY get. On driver detach, +release function is invoked on the the devres data and devres data is freed. + +5. Releasing a reference to the PHY + +When the controller no longer needs the PHY, it has to release the reference +to the PHY it has obtained using the APIs mentioned in the above section. The +PHY framework provides 2 APIs to release a reference to the PHY. + +void phy_put(struct phy *phy); +void devm_phy_put(struct device *dev, struct phy *phy); + +Both these APIs are used to release a reference to the PHY and devm_phy_put +destroys the devres associated with this PHY. + +6. Destroying the PHY + +When the driver that created the PHY is unloaded, it should destroy the PHY it +created using one of the following 2 APIs. + +void phy_destroy(struct phy *phy); +void devm_phy_destroy(struct device *dev, struct phy *phy); + +Both these APIs destroy the PHY and devm_phy_destroy destroys the devres +associated with this PHY. + +7. PM Runtime + +This subsystem is pm runtime enabled. So while creating the PHY, +pm_runtime_enable of the phy device created by this subsystem is called and +while destroying the PHY, pm_runtime_disable is called. Note that the phy +device created by this subsystem will be a child of the device that calls +phy_create (PHY provider device). + +So pm_runtime_get_sync of the phy_device created by this subsystem will invoke +pm_runtime_get_sync of PHY provider device because of parent-child relationship. +It should also be noted that phy_power_on and phy_power_off performs +phy_pm_runtime_get_sync and phy_pm_runtime_put respectively. +There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync, +phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and +phy_pm_runtime_forbid for performing PM operations. + +8. Board File Initialization + +Certain board file initialization is necessary in order to get a reference +to the PHY in the case of non-dt boot. +Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe, +then in the board file the following initialization should be done. + +struct phy_consumer consumers[] = { + PHY_CONSUMER("dwc3.0", "usb"), + PHY_CONSUMER("pcie.0", "pcie"), + PHY_CONSUMER("sata.0", "sata"), +}; +PHY_CONSUMER takes 2 parameters, first is the device name of the controller +(PHY consumer) and second is the port name. + +struct phy_init_data init_data = { + .consumers = consumers, + .num_consumers = ARRAY_SIZE(consumers), +}; + +static const struct platform_device pipe3_phy_dev = { + .name = "pipe3-phy", + .id = -1, + .dev = { + .platform_data = { + .init_data = &init_data, + }, + }, +}; + +then, while doing phy_create, the PHY driver should pass this init_data + phy_create(dev, ops, pdata->init_data); + +and the controller driver (phy consumer) should pass the port name along with +the device to get a reference to the PHY + phy_get(dev, "pcie"); + +9. DeviceTree Binding + +The documentation for PHY dt binding can be found @ +Documentation/devicetree/bindings/phy/phy-bindings.txt diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index c0ffd30eb55..a7929cb47e7 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -358,7 +358,12 @@ static struct pinctrl_gpio_range gpio_range = { .gc = &chip; }; -In this case the pin_base property will be ignored. +In this case the pin_base property will be ignored. If the name of a pin +group is known, the pins and npins elements of the above structure can be +initialised using the function pinctrl_get_group_pins(), e.g. for pin +group "foo": + +pinctrl_get_group_pins(pctl, "foo", &gpio_range.pins, &gpio_range.npins); When GPIO-specific functions in the pin control subsystem are called, these ranges will be used to look up the appropriate pin controller by inspecting diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt index 425c51d56ae..b8a907dc016 100644 --- a/Documentation/power/opp.txt +++ b/Documentation/power/opp.txt @@ -42,7 +42,7 @@ We can represent these as three OPPs as the following {Hz, uV} tuples: OPP library provides a set of helper functions to organize and query the OPP information. The library is located in drivers/base/power/opp.c and the header -is located in include/linux/opp.h. OPP library can be enabled by enabling +is located in include/linux/pm_opp.h. OPP library can be enabled by enabling CONFIG_PM_OPP from power management menuconfig menu. OPP library depends on CONFIG_PM as certain SoCs such as Texas Instrument's OMAP framework allows to optionally boot at a certain OPP without needing cpufreq. @@ -71,14 +71,14 @@ operations until that OPP could be re-enabled if possible. OPP library facilitates this concept in it's implementation. The following operational functions operate only on available opps: -opp_find_freq_{ceil, floor}, opp_get_voltage, opp_get_freq, opp_get_opp_count -and opp_init_cpufreq_table +opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq, dev_pm_opp_get_opp_count +and dev_pm_opp_init_cpufreq_table -opp_find_freq_exact is meant to be used to find the opp pointer which can then -be used for opp_enable/disable functions to make an opp available as required. +dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer which can then +be used for dev_pm_opp_enable/disable functions to make an opp available as required. WARNING: Users of OPP library should refresh their availability count using -get_opp_count if opp_enable/disable functions are invoked for a device, the +get_opp_count if dev_pm_opp_enable/disable functions are invoked for a device, the exact mechanism to trigger these or the notification mechanism to other dependent subsystems such as cpufreq are left to the discretion of the SoC specific framework which uses the OPP library. Similar care needs to be taken @@ -96,24 +96,24 @@ using RCU read locks. The opp_find_freq_{exact,ceil,floor}, opp_get_{voltage, freq, opp_count} fall into this category. opp_{add,enable,disable} are updaters which use mutex and implement it's own -RCU locking mechanisms. opp_init_cpufreq_table acts as an updater and uses +RCU locking mechanisms. dev_pm_opp_init_cpufreq_table acts as an updater and uses mutex to implment RCU updater strategy. These functions should *NOT* be called under RCU locks and other contexts that prevent blocking functions in RCU or mutex operations from working. 2. Initial OPP List Registration ================================ -The SoC implementation calls opp_add function iteratively to add OPPs per +The SoC implementation calls dev_pm_opp_add function iteratively to add OPPs per device. It is expected that the SoC framework will register the OPP entries optimally- typical numbers range to be less than 5. The list generated by registering the OPPs is maintained by OPP library throughout the device operation. The SoC framework can subsequently control the availability of the -OPPs dynamically using the opp_enable / disable functions. +OPPs dynamically using the dev_pm_opp_enable / disable functions. -opp_add - Add a new OPP for a specific domain represented by the device pointer. +dev_pm_opp_add - Add a new OPP for a specific domain represented by the device pointer. The OPP is defined using the frequency and voltage. Once added, the OPP is assumed to be available and control of it's availability can be done - with the opp_enable/disable functions. OPP library internally stores + with the dev_pm_opp_enable/disable functions. OPP library internally stores and manages this information in the opp struct. This function may be used by SoC framework to define a optimal list as per the demands of SoC usage environment. @@ -124,7 +124,7 @@ opp_add - Add a new OPP for a specific domain represented by the device pointer. soc_pm_init() { /* Do things */ - r = opp_add(mpu_dev, 1000000, 900000); + r = dev_pm_opp_add(mpu_dev, 1000000, 900000); if (!r) { pr_err("%s: unable to register mpu opp(%d)\n", r); goto no_cpufreq; @@ -143,44 +143,44 @@ functions return the matching pointer representing the opp if a match is found, else returns error. These errors are expected to be handled by standard error checks such as IS_ERR() and appropriate actions taken by the caller. -opp_find_freq_exact - Search for an OPP based on an *exact* frequency and +dev_pm_opp_find_freq_exact - Search for an OPP based on an *exact* frequency and availability. This function is especially useful to enable an OPP which is not available by default. Example: In a case when SoC framework detects a situation where a higher frequency could be made available, it can use this function to - find the OPP prior to call the opp_enable to actually make it available. + find the OPP prior to call the dev_pm_opp_enable to actually make it available. rcu_read_lock(); - opp = opp_find_freq_exact(dev, 1000000000, false); + opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false); rcu_read_unlock(); /* dont operate on the pointer.. just do a sanity check.. */ if (IS_ERR(opp)) { pr_err("frequency not disabled!\n"); /* trigger appropriate actions.. */ } else { - opp_enable(dev,1000000000); + dev_pm_opp_enable(dev,1000000000); } NOTE: This is the only search function that operates on OPPs which are not available. -opp_find_freq_floor - Search for an available OPP which is *at most* the +dev_pm_opp_find_freq_floor - Search for an available OPP which is *at most* the provided frequency. This function is useful while searching for a lesser match OR operating on OPP information in the order of decreasing frequency. Example: To find the highest opp for a device: freq = ULONG_MAX; rcu_read_lock(); - opp_find_freq_floor(dev, &freq); + dev_pm_opp_find_freq_floor(dev, &freq); rcu_read_unlock(); -opp_find_freq_ceil - Search for an available OPP which is *at least* the +dev_pm_opp_find_freq_ceil - Search for an available OPP which is *at least* the provided frequency. This function is useful while searching for a higher match OR operating on OPP information in the order of increasing frequency. Example 1: To find the lowest opp for a device: freq = 0; rcu_read_lock(); - opp_find_freq_ceil(dev, &freq); + dev_pm_opp_find_freq_ceil(dev, &freq); rcu_read_unlock(); Example 2: A simplified implementation of a SoC cpufreq_driver->target: soc_cpufreq_target(..) @@ -188,7 +188,7 @@ opp_find_freq_ceil - Search for an available OPP which is *at least* the /* Do stuff like policy checks etc. */ /* Find the best frequency match for the req */ rcu_read_lock(); - opp = opp_find_freq_ceil(dev, &freq); + opp = dev_pm_opp_find_freq_ceil(dev, &freq); rcu_read_unlock(); if (!IS_ERR(opp)) soc_switch_to_freq_voltage(freq); @@ -208,34 +208,34 @@ as thermal considerations (e.g. don't use OPPx until the temperature drops). WARNING: Do not use these functions in interrupt context. -opp_enable - Make a OPP available for operation. +dev_pm_opp_enable - Make a OPP available for operation. Example: Lets say that 1GHz OPP is to be made available only if the SoC temperature is lower than a certain threshold. The SoC framework implementation might choose to do something as follows: if (cur_temp < temp_low_thresh) { /* Enable 1GHz if it was disabled */ rcu_read_lock(); - opp = opp_find_freq_exact(dev, 1000000000, false); + opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false); rcu_read_unlock(); /* just error check */ if (!IS_ERR(opp)) - ret = opp_enable(dev, 1000000000); + ret = dev_pm_opp_enable(dev, 1000000000); else goto try_something_else; } -opp_disable - Make an OPP to be not available for operation +dev_pm_opp_disable - Make an OPP to be not available for operation Example: Lets say that 1GHz OPP is to be disabled if the temperature exceeds a threshold value. The SoC framework implementation might choose to do something as follows: if (cur_temp > temp_high_thresh) { /* Disable 1GHz if it was enabled */ rcu_read_lock(); - opp = opp_find_freq_exact(dev, 1000000000, true); + opp = dev_pm_opp_find_freq_exact(dev, 1000000000, true); rcu_read_unlock(); /* just error check */ if (!IS_ERR(opp)) - ret = opp_disable(dev, 1000000000); + ret = dev_pm_opp_disable(dev, 1000000000); else goto try_something_else; } @@ -247,7 +247,7 @@ information from the OPP structure is necessary. Once an OPP pointer is retrieved using the search functions, the following functions can be used by SoC framework to retrieve the information represented inside the OPP layer. -opp_get_voltage - Retrieve the voltage represented by the opp pointer. +dev_pm_opp_get_voltage - Retrieve the voltage represented by the opp pointer. Example: At a cpufreq transition to a different frequency, SoC framework requires to set the voltage represented by the OPP using the regulator framework to the Power Management chip providing the @@ -256,15 +256,15 @@ opp_get_voltage - Retrieve the voltage represented by the opp pointer. { /* do things */ rcu_read_lock(); - opp = opp_find_freq_ceil(dev, &freq); - v = opp_get_voltage(opp); + opp = dev_pm_opp_find_freq_ceil(dev, &freq); + v = dev_pm_opp_get_voltage(opp); rcu_read_unlock(); if (v) regulator_set_voltage(.., v); /* do other things */ } -opp_get_freq - Retrieve the freq represented by the opp pointer. +dev_pm_opp_get_freq - Retrieve the freq represented by the opp pointer. Example: Lets say the SoC framework uses a couple of helper functions we could pass opp pointers instead of doing additional parameters to handle quiet a bit of data parameters. @@ -273,8 +273,8 @@ opp_get_freq - Retrieve the freq represented by the opp pointer. /* do things.. */ max_freq = ULONG_MAX; rcu_read_lock(); - max_opp = opp_find_freq_floor(dev,&max_freq); - requested_opp = opp_find_freq_ceil(dev,&freq); + max_opp = dev_pm_opp_find_freq_floor(dev,&max_freq); + requested_opp = dev_pm_opp_find_freq_ceil(dev,&freq); if (!IS_ERR(max_opp) && !IS_ERR(requested_opp)) r = soc_test_validity(max_opp, requested_opp); rcu_read_unlock(); @@ -282,25 +282,25 @@ opp_get_freq - Retrieve the freq represented by the opp pointer. } soc_test_validity(..) { - if(opp_get_voltage(max_opp) < opp_get_voltage(requested_opp)) + if(dev_pm_opp_get_voltage(max_opp) < dev_pm_opp_get_voltage(requested_opp)) return -EINVAL; - if(opp_get_freq(max_opp) < opp_get_freq(requested_opp)) + if(dev_pm_opp_get_freq(max_opp) < dev_pm_opp_get_freq(requested_opp)) return -EINVAL; /* do things.. */ } -opp_get_opp_count - Retrieve the number of available opps for a device +dev_pm_opp_get_opp_count - Retrieve the number of available opps for a device Example: Lets say a co-processor in the SoC needs to know the available frequencies in a table, the main processor can notify as following: soc_notify_coproc_available_frequencies() { /* Do things */ rcu_read_lock(); - num_available = opp_get_opp_count(dev); + num_available = dev_pm_opp_get_opp_count(dev); speeds = kzalloc(sizeof(u32) * num_available, GFP_KERNEL); /* populate the table in increasing order */ freq = 0; - while (!IS_ERR(opp = opp_find_freq_ceil(dev, &freq))) { + while (!IS_ERR(opp = dev_pm_opp_find_freq_ceil(dev, &freq))) { speeds[i] = freq; freq++; i++; @@ -313,7 +313,7 @@ opp_get_opp_count - Retrieve the number of available opps for a device 6. Cpufreq Table Generation =========================== -opp_init_cpufreq_table - cpufreq framework typically is initialized with +dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with cpufreq_frequency_table_cpuinfo which is provided with the list of frequencies that are available for operation. This function provides a ready to use conversion routine to translate the OPP layer's internal @@ -326,7 +326,7 @@ opp_init_cpufreq_table - cpufreq framework typically is initialized with soc_pm_init() { /* Do things */ - r = opp_init_cpufreq_table(dev, &freq_table); + r = dev_pm_opp_init_cpufreq_table(dev, &freq_table); if (!r) cpufreq_frequency_table_cpuinfo(policy, freq_table); /* Do other things */ @@ -336,7 +336,7 @@ opp_init_cpufreq_table - cpufreq framework typically is initialized with addition to CONFIG_PM as power management feature is required to dynamically scale voltage and frequency in a system. -opp_free_cpufreq_table - Free up the table allocated by opp_init_cpufreq_table +dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table 7. Data Structures ================== @@ -358,16 +358,16 @@ accessed by various functions as described above. However, the structures representing the actual OPPs and domains are internal to the OPP library itself to allow for suitable abstraction reusable across systems. -struct opp - The internal data structure of OPP library which is used to +struct dev_pm_opp - The internal data structure of OPP library which is used to represent an OPP. In addition to the freq, voltage, availability information, it also contains internal book keeping information required for the OPP library to operate on. Pointer to this structure is provided back to the users such as SoC framework to be used as a identifier for OPP in the interactions with OPP layer. - WARNING: The struct opp pointer should not be parsed or modified by the - users. The defaults of for an instance is populated by opp_add, but the - availability of the OPP can be modified by opp_enable/disable functions. + WARNING: The struct dev_pm_opp pointer should not be parsed or modified by the + users. The defaults of for an instance is populated by dev_pm_opp_add, but the + availability of the OPP can be modified by dev_pm_opp_enable/disable functions. struct device - This is used to identify a domain to the OPP layer. The nature of the device and it's implementation is left to the user of @@ -377,19 +377,19 @@ Overall, in a simplistic view, the data structure operations is represented as following: Initialization / modification: - +-----+ /- opp_enable -opp_add --> | opp | <------- - | +-----+ \- opp_disable + +-----+ /- dev_pm_opp_enable +dev_pm_opp_add --> | opp | <------- + | +-----+ \- dev_pm_opp_disable \-------> domain_info(device) Search functions: - /-- opp_find_freq_ceil ---\ +-----+ -domain_info<---- opp_find_freq_exact -----> | opp | - \-- opp_find_freq_floor ---/ +-----+ + /-- dev_pm_opp_find_freq_ceil ---\ +-----+ +domain_info<---- dev_pm_opp_find_freq_exact -----> | opp | + \-- dev_pm_opp_find_freq_floor ---/ +-----+ Retrieval functions: -+-----+ /- opp_get_voltage ++-----+ /- dev_pm_opp_get_voltage | opp | <--- -+-----+ \- opp_get_freq ++-----+ \- dev_pm_opp_get_freq -domain_info <- opp_get_opp_count +domain_info <- dev_pm_opp_get_opp_count diff --git a/Documentation/power/powercap/powercap.txt b/Documentation/power/powercap/powercap.txt new file mode 100644 index 00000000000..1e6ef164e07 --- /dev/null +++ b/Documentation/power/powercap/powercap.txt @@ -0,0 +1,236 @@ +Power Capping Framework +================================== + +The power capping framework provides a consistent interface between the kernel +and the user space that allows power capping drivers to expose the settings to +user space in a uniform way. + +Terminology +========================= +The framework exposes power capping devices to user space via sysfs in the +form of a tree of objects. The objects at the root level of the tree represent +'control types', which correspond to different methods of power capping. For +example, the intel-rapl control type represents the Intel "Running Average +Power Limit" (RAPL) technology, whereas the 'idle-injection' control type +corresponds to the use of idle injection for controlling power. + +Power zones represent different parts of the system, which can be controlled and +monitored using the power capping method determined by the control type the +given zone belongs to. They each contain attributes for monitoring power, as +well as controls represented in the form of power constraints. If the parts of +the system represented by different power zones are hierarchical (that is, one +bigger part consists of multiple smaller parts that each have their own power +controls), those power zones may also be organized in a hierarchy with one +parent power zone containing multiple subzones and so on to reflect the power +control topology of the system. In that case, it is possible to apply power +capping to a set of devices together using the parent power zone and if more +fine grained control is required, it can be applied through the subzones. + + +Example sysfs interface tree: + +/sys/devices/virtual/powercap +??? intel-rapl + ??? intel-rapl:0 + ? ??? constraint_0_name + ? ??? constraint_0_power_limit_uw + ? ??? constraint_0_time_window_us + ? ??? constraint_1_name + ? ??? constraint_1_power_limit_uw + ? ??? constraint_1_time_window_us + ? ??? device -> ../../intel-rapl + ? ??? energy_uj + ? ??? intel-rapl:0:0 + ? ? ??? constraint_0_name + ? ? ??? constraint_0_power_limit_uw + ? ? ??? constraint_0_time_window_us + ? ? ??? constraint_1_name + ? ? ??? constraint_1_power_limit_uw + ? ? ??? constraint_1_time_window_us + ? ? ??? device -> ../../intel-rapl:0 + ? ? ??? energy_uj + ? ? ??? max_energy_range_uj + ? ? ??? name + ? ? ??? enabled + ? ? ??? power + ? ? ? ??? async + ? ? ? [] + ? ? ??? subsystem -> ../../../../../../class/power_cap + ? ? ??? uevent + ? ??? intel-rapl:0:1 + ? ? ??? constraint_0_name + ? ? ??? constraint_0_power_limit_uw + ? ? ??? constraint_0_time_window_us + ? ? ??? constraint_1_name + ? ? ??? constraint_1_power_limit_uw + ? ? ??? constraint_1_time_window_us + ? ? ??? device -> ../../intel-rapl:0 + ? ? ??? energy_uj + ? ? ??? max_energy_range_uj + ? ? ??? name + ? ? ??? enabled + ? ? ??? power + ? ? ? ??? async + ? ? ? [] + ? ? ??? subsystem -> ../../../../../../class/power_cap + ? ? ??? uevent + ? ??? max_energy_range_uj + ? ??? max_power_range_uw + ? ??? name + ? ??? enabled + ? ??? power + ? ? ??? async + ? ? [] + ? ??? subsystem -> ../../../../../class/power_cap + ? ??? enabled + ? ??? uevent + ??? intel-rapl:1 + ? ??? constraint_0_name + ? ??? constraint_0_power_limit_uw + ? ??? constraint_0_time_window_us + ? ??? constraint_1_name + ? ??? constraint_1_power_limit_uw + ? ??? constraint_1_time_window_us + ? ??? device -> ../../intel-rapl + ? ??? energy_uj + ? ??? intel-rapl:1:0 + ? ? ??? constraint_0_name + ? ? ??? constraint_0_power_limit_uw + ? ? ??? constraint_0_time_window_us + ? ? ??? constraint_1_name + ? ? ??? constraint_1_power_limit_uw + ? ? ??? constraint_1_time_window_us + ? ? ??? device -> ../../intel-rapl:1 + ? ? ??? energy_uj + ? ? ??? max_energy_range_uj + ? ? ??? name + ? ? ??? enabled + ? ? ??? power + ? ? ? ??? async + ? ? ? [] + ? ? ??? subsystem -> ../../../../../../class/power_cap + ? ? ??? uevent + ? ??? intel-rapl:1:1 + ? ? ??? constraint_0_name + ? ? ??? constraint_0_power_limit_uw + ? ? ??? constraint_0_time_window_us + ? ? ??? constraint_1_name + ? ? ??? constraint_1_power_limit_uw + ? ? ??? constraint_1_time_window_us + ? ? ??? device -> ../../intel-rapl:1 + ? ? ??? energy_uj + ? ? ??? max_energy_range_uj + ? ? ??? name + ? ? ??? enabled + ? ? ??? power + ? ? ? ??? async + ? ? ? [] + ? ? ??? subsystem -> ../../../../../../class/power_cap + ? ? ??? uevent + ? ??? max_energy_range_uj + ? ??? max_power_range_uw + ? ??? name + ? ??? enabled + ? ??? power + ? ? ??? async + ? ? [] + ? ??? subsystem -> ../../../../../class/power_cap + ? ??? uevent + ??? power + ? ??? async + ? [] + ??? subsystem -> ../../../../class/power_cap + ??? enabled + ??? uevent + +The above example illustrates a case in which the Intel RAPL technology, +available in Intel® IA-64 and IA-32 Processor Architectures, is used. There is one +control type called intel-rapl which contains two power zones, intel-rapl:0 and +intel-rapl:1, representing CPU packages. Each of these power zones contains +two subzones, intel-rapl:j:0 and intel-rapl:j:1 (j = 0, 1), representing the +"core" and the "uncore" parts of the given CPU package, respectively. All of +the zones and subzones contain energy monitoring attributes (energy_uj, +max_energy_range_uj) and constraint attributes (constraint_*) allowing controls +to be applied (the constraints in the 'package' power zones apply to the whole +CPU packages and the subzone constraints only apply to the respective parts of +the given package individually). Since Intel RAPL doesn't provide instantaneous +power value, there is no power_uw attribute. + +In addition to that, each power zone contains a name attribute, allowing the +part of the system represented by that zone to be identified. +For example: + +cat /sys/class/power_cap/intel-rapl/intel-rapl:0/name +package-0 + +The Intel RAPL technology allows two constraints, short term and long term, +with two different time windows to be applied to each power zone. Thus for +each zone there are 2 attributes representing the constraint names, 2 power +limits and 2 attributes representing the sizes of the time windows. Such that, +constraint_j_* attributes correspond to the jth constraint (j = 0,1). + +For example: + constraint_0_name + constraint_0_power_limit_uw + constraint_0_time_window_us + constraint_1_name + constraint_1_power_limit_uw + constraint_1_time_window_us + +Power Zone Attributes +================================= +Monitoring attributes +---------------------- + +energy_uj (rw): Current energy counter in micro joules. Write "0" to reset. +If the counter can not be reset, then this attribute is read only. + +max_energy_range_uj (ro): Range of the above energy counter in micro-joules. + +power_uw (ro): Current power in micro watts. + +max_power_range_uw (ro): Range of the above power value in micro-watts. + +name (ro): Name of this power zone. + +It is possible that some domains have both power ranges and energy counter ranges; +however, only one is mandatory. + +Constraints +---------------- +constraint_X_power_limit_uw (rw): Power limit in micro watts, which should be +applicable for the time window specified by "constraint_X_time_window_us". + +constraint_X_time_window_us (rw): Time window in micro seconds. + +constraint_X_name (ro): An optional name of the constraint + +constraint_X_max_power_uw(ro): Maximum allowed power in micro watts. + +constraint_X_min_power_uw(ro): Minimum allowed power in micro watts. + +constraint_X_max_time_window_us(ro): Maximum allowed time window in micro seconds. + +constraint_X_min_time_window_us(ro): Minimum allowed time window in micro seconds. + +Except power_limit_uw and time_window_us other fields are optional. + +Common zone and control type attributes +---------------------------------------- +enabled (rw): Enable/Disable controls at zone level or for all zones using +a control type. + +Power Cap Client Driver Interface +================================== +The API summary: + +Call powercap_register_control_type() to register control type object. +Call powercap_register_zone() to register a power zone (under a given +control type), either as a top-level power zone or as a subzone of another +power zone registered earlier. +The number of constraints in a power zone and the corresponding callbacks have +to be defined prior to calling powercap_register_zone() to register that zone. + +To Free a power zone call powercap_unregister_zone(). +To free a control type object call powercap_unregister_control_type(). +Detailed API can be generated using kernel-doc on include/linux/powercap.h. diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 71d8fe4e75d..0f54333b0ff 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -145,11 +145,13 @@ The action performed by the idle callback is totally dependent on the subsystem if the device can be suspended (i.e. if all of the conditions necessary for suspending the device are satisfied) and to queue up a suspend request for the device in that case. If there is no idle callback, or if the callback returns -0, then the PM core will attempt to carry out a runtime suspend of the device; -in essence, it will call pm_runtime_suspend() directly. To prevent this (for -example, if the callback routine has started a delayed suspend), the routine -should return a non-zero value. Negative error return codes are ignored by the -PM core. +0, then the PM core will attempt to carry out a runtime suspend of the device, +also respecting devices configured for autosuspend. In essence this means a +call to pm_runtime_autosuspend() (do note that drivers needs to update the +device last busy mark, pm_runtime_mark_last_busy(), to control the delay under +this circumstance). To prevent this (for example, if the callback routine has +started a delayed suspend), the routine must return a non-zero value. Negative +error return codes are ignored by the PM core. The helper functions provided by the PM core, described in Section 4, guarantee that the following constraints are met with respect to runtime PM callbacks for @@ -308,7 +310,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: - execute the subsystem-level idle callback for the device; returns an error code on failure, where -EINPROGRESS means that ->runtime_idle() is already being executed; if there is no callback or the callback returns 0 - then run pm_runtime_suspend(dev) and return its result + then run pm_runtime_autosuspend(dev) and return its result int pm_runtime_suspend(struct device *dev); - execute the subsystem-level suspend callback for the device; returns 0 on diff --git a/Documentation/pps/pps.txt b/Documentation/pps/pps.txt index d35dcdd82ff..c03b1be5eb1 100644 --- a/Documentation/pps/pps.txt +++ b/Documentation/pps/pps.txt @@ -66,6 +66,21 @@ In LinuxPPS the PPS sources are simply char devices usually mapped into files /dev/pps0, /dev/pps1, etc.. +PPS with USB to serial devices +------------------------------ + +It is possible to grab the PPS from an USB to serial device. However, +you should take into account the latencies and jitter introduced by +the USB stack. Users has reported clock instability around +-1ms when +synchronized with PPS through USB. This isn't suited for time server +synchronization. + +If your device doesn't report PPS, you can check that the feature is +supported by its driver. Most of the time, you only need to add a call +to usb_serial_handle_dcd_change after checking the DCD status (see +ch341 and pl2303 examples). + + Coding example -------------- diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c index f59ded06610..a74d0a84d32 100644 --- a/Documentation/ptp/testptp.c +++ b/Documentation/ptp/testptp.c @@ -100,6 +100,11 @@ static long ppb_to_scaled_ppm(int ppb) return (long) (ppb * 65.536); } +static int64_t pctns(struct ptp_clock_time *t) +{ + return t->sec * 1000000000LL + t->nsec; +} + static void usage(char *progname) { fprintf(stderr, @@ -112,6 +117,8 @@ static void usage(char *progname) " -f val adjust the ptp clock frequency by 'val' ppb\n" " -g get the ptp clock time\n" " -h prints this message\n" + " -k val measure the time offset between system and phc clock\n" + " for 'val' times (Maximum 25)\n" " -p val enable output with a period of 'val' nanoseconds\n" " -P val enable or disable (val=1|0) the system clock PPS\n" " -s set the ptp clock time from the system time\n" @@ -133,8 +140,12 @@ int main(int argc, char *argv[]) struct itimerspec timeout; struct sigevent sigevent; + struct ptp_clock_time *pct; + struct ptp_sys_offset *sysoff; + + char *progname; - int c, cnt, fd; + int i, c, cnt, fd; char *device = DEVICE; clockid_t clkid; @@ -144,14 +155,19 @@ int main(int argc, char *argv[]) int extts = 0; int gettime = 0; int oneshot = 0; + int pct_offset = 0; + int n_samples = 0; int periodic = 0; int perout = -1; int pps = -1; int settime = 0; + int64_t t1, t2, tp; + int64_t interval, offset; + progname = strrchr(argv[0], '/'); progname = progname ? 1+progname : argv[0]; - while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) { + while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghk:p:P:sSt:v"))) { switch (c) { case 'a': oneshot = atoi(optarg); @@ -174,6 +190,10 @@ int main(int argc, char *argv[]) case 'g': gettime = 1; break; + case 'k': + pct_offset = 1; + n_samples = atoi(optarg); + break; case 'p': perout = atoi(optarg); break; @@ -376,6 +396,47 @@ int main(int argc, char *argv[]) } } + if (pct_offset) { + if (n_samples <= 0 || n_samples > 25) { + puts("n_samples should be between 1 and 25"); + usage(progname); + return -1; + } + + sysoff = calloc(1, sizeof(*sysoff)); + if (!sysoff) { + perror("calloc"); + return -1; + } + sysoff->n_samples = n_samples; + + if (ioctl(fd, PTP_SYS_OFFSET, sysoff)) + perror("PTP_SYS_OFFSET"); + else + puts("system and phc clock time offset request okay"); + + pct = &sysoff->ts[0]; + for (i = 0; i < sysoff->n_samples; i++) { + t1 = pctns(pct+2*i); + tp = pctns(pct+2*i+1); + t2 = pctns(pct+2*i+2); + interval = t2 - t1; + offset = (t2 + t1) / 2 - tp; + + printf("system time: %ld.%ld\n", + (pct+2*i)->sec, (pct+2*i)->nsec); + printf("phc time: %ld.%ld\n", + (pct+2*i+1)->sec, (pct+2*i+1)->nsec); + printf("system time: %ld.%ld\n", + (pct+2*i+2)->sec, (pct+2*i+2)->nsec); + printf("system/phc clock time offset is %ld ns\n" + "system clock time delay is %ld ns\n", + offset, interval); + } + + free(sysoff); + } + close(fd); return 0; } diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt index fcaf0b4efba..3da163383c9 100644 --- a/Documentation/s390/s390dbf.txt +++ b/Documentation/s390/s390dbf.txt @@ -158,6 +158,16 @@ Return Value: none Description: Sets new actual debug level if new_level is valid. --------------------------------------------------------------------------- +bool debug_level_enabled (debug_info_t * id, int level); + +Parameter: id: handle for debug log + level: debug level + +Return Value: True if level is less or equal to the current debug level. + +Description: Returns true if debug events for the specified level would be + logged. Otherwise returns false. +--------------------------------------------------------------------------- void debug_stop_all(void); Parameter: none diff --git a/Documentation/scheduler/sched-arch.txt b/Documentation/scheduler/sched-arch.txt index b1b8587b86f..9290de70345 100644 --- a/Documentation/scheduler/sched-arch.txt +++ b/Documentation/scheduler/sched-arch.txt @@ -65,11 +65,6 @@ Possible arch/ problems Possible arch problems I found (and either tried to fix or didn't): -h8300 - Is such sleeping racy vs interrupts? (See #4a). - The H8/300 manual I found indicates yes, however disabling IRQs - over the sleep mean only NMIs can wake it up, so can't fix easily - without doing spin waiting. - ia64 - is safe_halt call racy vs interrupts? (does it sleep?) (See #4a) sh64 - Is sleeping racy vs interrupts? (See #4a) diff --git a/Documentation/serial/driver b/Documentation/serial/driver index 067c47d4691..c3a7689a90e 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver @@ -264,10 +264,6 @@ hardware. Locking: none. Interrupts: caller dependent. - set_wake(port,state) - Enable/disable power management wakeup on serial activity. Not - currently implemented. - type(port) Return a pointer to a string constant describing the specified port, or return NULL, in which case the string 'unknown' is diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 95731a08f25..b8dd0df7695 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -616,7 +616,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. As default, snd-dummy drivers doesn't allocate the real buffers but either ignores read/write or mmap a single dummy page to all - buffer pages, in order to save the resouces. If your apps need + buffer pages, in order to save the resources. If your apps need the read/ written buffer data to be consistent, pass fake_buffer=0 option. diff --git a/Documentation/sound/alsa/Audiophile-Usb.txt b/Documentation/sound/alsa/Audiophile-Usb.txt index 654dd3b694a..e7a5ed4dcae 100644 --- a/Documentation/sound/alsa/Audiophile-Usb.txt +++ b/Documentation/sound/alsa/Audiophile-Usb.txt @@ -232,7 +232,7 @@ The parameter can be given: # modprobe snd-usb-audio index=1 device_setup=0x09 * Or while configuring the modules options in your modules configuration file - (tipically a .conf file in /etc/modprobe.d/ directory: + (typically a .conf file in /etc/modprobe.d/ directory: alias snd-card-1 snd-usb-audio options snd-usb-audio index=1 device_setup=0x09 diff --git a/Documentation/sound/alsa/CMIPCI.txt b/Documentation/sound/alsa/CMIPCI.txt index 16935c8561f..4e36e6e809c 100644 --- a/Documentation/sound/alsa/CMIPCI.txt +++ b/Documentation/sound/alsa/CMIPCI.txt @@ -87,7 +87,7 @@ with 4 channels, and use the interleaved 4 channel data. -There are some control switchs affecting to the speaker connections: +There are some control switches affecting to the speaker connections: "Line-In Mode" - an enum control to change the behavior of line-in jack. Either "Line-In", "Rear Output" or "Bass Output" can diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index f911e365620..85c362d8ea3 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -28,6 +28,7 @@ ALC269/270/275/276/28x/29x alc269-dmic Enable ALC269(VA) digital mic workaround alc271-dmic Enable ALC271X digital mic workaround inv-dmic Inverted internal mic workaround + headset-mic Indicates a combined headset (headphone+mic) jack lenovo-dock Enables docking station I/O for some Lenovos dell-headset-multi Headset jack, which can also be used as mic-in dell-headset-dock Headset jack (without mic-in), and also dock I/O diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt index fd74ff26376..630c492c3dc 100644 --- a/Documentation/sound/alsa/compress_offload.txt +++ b/Documentation/sound/alsa/compress_offload.txt @@ -217,12 +217,12 @@ Not supported: would be enabled with ALSA kcontrols. - Audio policy/resource management. This API does not provide any - hooks to query the utilization of the audio DSP, nor any premption + hooks to query the utilization of the audio DSP, nor any preemption mechanisms. -- No notion of underun/overrun. Since the bytes written are compressed +- No notion of underrun/overrun. Since the bytes written are compressed in nature and data written/read doesn't translate directly to - rendered output in time, this does not deal with underrun/overun and + rendered output in time, this does not deal with underrun/overrun and maybe dealt in user-library Credits: diff --git a/Documentation/sound/alsa/soc/DPCM.txt b/Documentation/sound/alsa/soc/DPCM.txt new file mode 100644 index 00000000000..0110180b7ac --- /dev/null +++ b/Documentation/sound/alsa/soc/DPCM.txt @@ -0,0 +1,380 @@ +Dynamic PCM +=========== + +1. Description +============== + +Dynamic PCM allows an ALSA PCM device to digitally route its PCM audio to +various digital endpoints during the PCM stream runtime. e.g. PCM0 can route +digital audio to I2S DAI0, I2S DAI1 or PDM DAI2. This is useful for on SoC DSP +drivers that expose several ALSA PCMs and can route to multiple DAIs. + +The DPCM runtime routing is determined by the ALSA mixer settings in the same +way as the analog signal is routed in an ASoC codec driver. DPCM uses a DAPM +graph representing the DSP internal audio paths and uses the mixer settings to +determine the patch used by each ALSA PCM. + +DPCM re-uses all the existing component codec, platform and DAI drivers without +any modifications. + + +Phone Audio System with SoC based DSP +------------------------------------- + +Consider the following phone audio subsystem. This will be used in this +document for all examples :- + +| Front End PCMs | SoC DSP | Back End DAIs | Audio devices | + + ************* +PCM0 <------------> * * <----DAI0-----> Codec Headset + * * +PCM1 <------------> * * <----DAI1-----> Codec Speakers + * DSP * +PCM2 <------------> * * <----DAI2-----> MODEM + * * +PCM3 <------------> * * <----DAI3-----> BT + * * + * * <----DAI4-----> DMIC + * * + * * <----DAI5-----> FM + ************* + +This diagram shows a simple smart phone audio subsystem. It supports Bluetooth, +FM digital radio, Speakers, Headset Jack, digital microphones and cellular +modem. This sound card exposes 4 DSP front end (FE) ALSA PCM devices and +supports 6 back end (BE) DAIs. Each FE PCM can digitally route audio data to any +of the BE DAIs. The FE PCM devices can also route audio to more than 1 BE DAI. + + + +Example - DPCM Switching playback from DAI0 to DAI1 +--------------------------------------------------- + +Audio is being played to the Headset. After a while the user removes the headset +and audio continues playing on the speakers. + +Playback on PCM0 to Headset would look like :- + + ************* +PCM0 <============> * * <====DAI0=====> Codec Headset + * * +PCM1 <------------> * * <----DAI1-----> Codec Speakers + * DSP * +PCM2 <------------> * * <----DAI2-----> MODEM + * * +PCM3 <------------> * * <----DAI3-----> BT + * * + * * <----DAI4-----> DMIC + * * + * * <----DAI5-----> FM + ************* + +The headset is removed from the jack by user so the speakers must now be used :- + + ************* +PCM0 <============> * * <----DAI0-----> Codec Headset + * * +PCM1 <------------> * * <====DAI1=====> Codec Speakers + * DSP * +PCM2 <------------> * * <----DAI2-----> MODEM + * * +PCM3 <------------> * * <----DAI3-----> BT + * * + * * <----DAI4-----> DMIC + * * + * * <----DAI5-----> FM + ************* + +The audio driver processes this as follows :- + + 1) Machine driver receives Jack removal event. + + 2) Machine driver OR audio HAL disables the Headset path. + + 3) DPCM runs the PCM trigger(stop), hw_free(), shutdown() operations on DAI0 + for headset since the path is now disabled. + + 4) Machine driver or audio HAL enables the speaker path. + + 5) DPCM runs the PCM ops for startup(), hw_params(), prepapre() and + trigger(start) for DAI1 Speakers since the path is enabled. + +In this example, the machine driver or userspace audio HAL can alter the routing +and then DPCM will take care of managing the DAI PCM operations to either bring +the link up or down. Audio playback does not stop during this transition. + + + +DPCM machine driver +=================== + +The DPCM enabled ASoC machine driver is similar to normal machine drivers +except that we also have to :- + + 1) Define the FE and BE DAI links. + + 2) Define any FE/BE PCM operations. + + 3) Define widget graph connections. + + +1 FE and BE DAI links +--------------------- + +| Front End PCMs | SoC DSP | Back End DAIs | Audio devices | + + ************* +PCM0 <------------> * * <----DAI0-----> Codec Headset + * * +PCM1 <------------> * * <----DAI1-----> Codec Speakers + * DSP * +PCM2 <------------> * * <----DAI2-----> MODEM + * * +PCM3 <------------> * * <----DAI3-----> BT + * * + * * <----DAI4-----> DMIC + * * + * * <----DAI5-----> FM + ************* + +For the example above we have to define 4 FE DAI links and 6 BE DAI links. The +FE DAI links are defined as follows :- + +static struct snd_soc_dai_link machine_dais[] = { + { + .name = "PCM0 System", + .stream_name = "System Playback", + .cpu_dai_name = "System Pin", + .platform_name = "dsp-audio", + .codec_name = "snd-soc-dummy", + .codec_dai_name = "snd-soc-dummy-dai", + .dynamic = 1, + .trigger = {SND_SOC_DPCM_TRIGGER_POST, SND_SOC_DPCM_TRIGGER_POST}, + .dpcm_playback = 1, + }, + .....< other FE and BE DAI links here > +}; + +This FE DAI link is pretty similar to a regular DAI link except that we also +set the DAI link to a DPCM FE with the "dynamic = 1". The supported FE stream +directions should also be set with the "dpcm_playback" and "dpcm_capture" +flags. There is also an option to specify the ordering of the trigger call for +each FE. This allows the ASoC core to trigger the DSP before or after the other +components (as some DSPs have strong requirements for the ordering DAI/DSP +start and stop sequences). + +The FE DAI above sets the codec and code DAIs to dummy devices since the BE is +dynamic and will change depending on runtime config. + +The BE DAIs are configured as follows :- + +static struct snd_soc_dai_link machine_dais[] = { + .....< FE DAI links here > + { + .name = "Codec Headset", + .cpu_dai_name = "ssp-dai.0", + .platform_name = "snd-soc-dummy", + .no_pcm = 1, + .codec_name = "rt5640.0-001c", + .codec_dai_name = "rt5640-aif1", + .ignore_suspend = 1, + .ignore_pmdown_time = 1, + .be_hw_params_fixup = hswult_ssp0_fixup, + .ops = &haswell_ops, + .dpcm_playback = 1, + .dpcm_capture = 1, + }, + .....< other BE DAI links here > +}; + +This BE DAI link connects DAI0 to the codec (in this case RT5460 AIF1). It sets +the "no_pcm" flag to mark it has a BE and sets flags for supported stream +directions using "dpcm_playback" and "dpcm_capture" above. + +The BE has also flags set for ignoring suspend and PM down time. This allows +the BE to work in a hostless mode where the host CPU is not transferring data +like a BT phone call :- + + ************* +PCM0 <------------> * * <----DAI0-----> Codec Headset + * * +PCM1 <------------> * * <----DAI1-----> Codec Speakers + * DSP * +PCM2 <------------> * * <====DAI2=====> MODEM + * * +PCM3 <------------> * * <====DAI3=====> BT + * * + * * <----DAI4-----> DMIC + * * + * * <----DAI5-----> FM + ************* + +This allows the host CPU to sleep whilst the DSP, MODEM DAI and the BT DAI are +still in operation. + +A BE DAI link can also set the codec to a dummy device if the code is a device +that is managed externally. + +Likewise a BE DAI can also set a dummy cpu DAI if the CPU DAI is managed by the +DSP firmware. + + +2 FE/BE PCM operations +---------------------- + +The BE above also exports some PCM operations and a "fixup" callback. The fixup +callback is used by the machine driver to (re)configure the DAI based upon the +FE hw params. i.e. the DSP may perform SRC or ASRC from the FE to BE. + +e.g. DSP converts all FE hw params to run at fixed rate of 48k, 16bit, stereo for +DAI0. This means all FE hw_params have to be fixed in the machine driver for +DAI0 so that the DAI is running at desired configuration regardless of the FE +configuration. + +static int dai0_fixup(struct snd_soc_pcm_runtime *rtd, + struct snd_pcm_hw_params *params) +{ + struct snd_interval *rate = hw_param_interval(params, + SNDRV_PCM_HW_PARAM_RATE); + struct snd_interval *channels = hw_param_interval(params, + SNDRV_PCM_HW_PARAM_CHANNELS); + + /* The DSP will covert the FE rate to 48k, stereo */ + rate->min = rate->max = 48000; + channels->min = channels->max = 2; + + /* set DAI0 to 16 bit */ + snd_mask_set(¶ms->masks[SNDRV_PCM_HW_PARAM_FORMAT - + SNDRV_PCM_HW_PARAM_FIRST_MASK], + SNDRV_PCM_FORMAT_S16_LE); + return 0; +} + +The other PCM operation are the same as for regular DAI links. Use as necessary. + + +3 Widget graph connections +-------------------------- + +The BE DAI links will normally be connected to the graph at initialisation time +by the ASoC DAPM core. However, if the BE codec or BE DAI is a dummy then this +has to be set explicitly in the driver :- + +/* BE for codec Headset - DAI0 is dummy and managed by DSP FW */ +{"DAI0 CODEC IN", NULL, "AIF1 Capture"}, +{"AIF1 Playback", NULL, "DAI0 CODEC OUT"}, + + +Writing a DPCM DSP driver +========================= + +The DPCM DSP driver looks much like a standard platform class ASoC driver +combined with elements from a codec class driver. A DSP platform driver must +implement :- + + 1) Front End PCM DAIs - i.e. struct snd_soc_dai_driver. + + 2) DAPM graph showing DSP audio routing from FE DAIs to BEs. + + 3) DAPM widgets from DSP graph. + + 4) Mixers for gains, routing, etc. + + 5) DMA configuration. + + 6) BE AIF widgets. + +Items 6 is important for routing the audio outside of the DSP. AIF need to be +defined for each BE and each stream direction. e.g for BE DAI0 above we would +have :- + +SND_SOC_DAPM_AIF_IN("DAI0 RX", NULL, 0, SND_SOC_NOPM, 0, 0), +SND_SOC_DAPM_AIF_OUT("DAI0 TX", NULL, 0, SND_SOC_NOPM, 0, 0), + +The BE AIF are used to connect the DSP graph to the graphs for the other +component drivers (e.g. codec graph). + + +Hostless PCM streams +==================== + +A hostless PCM stream is a stream that is not routed through the host CPU. An +example of this would be a phone call from handset to modem. + + + ************* +PCM0 <------------> * * <----DAI0-----> Codec Headset + * * +PCM1 <------------> * * <====DAI1=====> Codec Speakers/Mic + * DSP * +PCM2 <------------> * * <====DAI2=====> MODEM + * * +PCM3 <------------> * * <----DAI3-----> BT + * * + * * <----DAI4-----> DMIC + * * + * * <----DAI5-----> FM + ************* + +In this case the PCM data is routed via the DSP. The host CPU in this use case +is only used for control and can sleep during the runtime of the stream. + +The host can control the hostless link either by :- + + 1) Configuring the link as a CODEC <-> CODEC style link. In this case the link + is enabled or disabled by the state of the DAPM graph. This usually means + there is a mixer control that can be used to connect or disconnect the path + between both DAIs. + + 2) Hostless FE. This FE has a virtual connection to the BE DAI links on the DAPM + graph. Control is then carried out by the FE as regular PCM operations. + This method gives more control over the DAI links, but requires much more + userspace code to control the link. Its recommended to use CODEC<->CODEC + unless your HW needs more fine grained sequencing of the PCM ops. + + +CODEC <-> CODEC link +-------------------- + +This DAI link is enabled when DAPM detects a valid path within the DAPM graph. +The machine driver sets some additional parameters to the DAI link i.e. + +static const struct snd_soc_pcm_stream dai_params = { + .formats = SNDRV_PCM_FMTBIT_S32_LE, + .rate_min = 8000, + .rate_max = 8000, + .channels_min = 2, + .channels_max = 2, +}; + +static struct snd_soc_dai_link dais[] = { + < ... more DAI links above ... > + { + .name = "MODEM", + .stream_name = "MODEM", + .cpu_dai_name = "dai2", + .codec_dai_name = "modem-aif1", + .codec_name = "modem", + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF + | SND_SOC_DAIFMT_CBM_CFM, + .params = &dai_params, + } + < ... more DAI links here ... > + +These parameters are used to configure the DAI hw_params() when DAPM detects a +valid path and then calls the PCM operations to start the link. DAPM will also +call the appropriate PCM operations to disable the DAI when the path is no +longer valid. + + +Hostless FE +----------- + +The DAI link(s) are enabled by a FE that does not read or write any PCM data. +This means creating a new FE that is connected with a virtual path to both +DAI links. The DAI links will be started when the FE PCM is started and stopped +when the FE PCM is stopped. Note that the FE PCM cannot read or write data in +this configuration. + + diff --git a/Documentation/sound/alsa/soc/codec.txt b/Documentation/sound/alsa/soc/codec.txt index bce23a4a787..db5f9c9ae14 100644 --- a/Documentation/sound/alsa/soc/codec.txt +++ b/Documentation/sound/alsa/soc/codec.txt @@ -1,22 +1,23 @@ -ASoC Codec Driver -================= +ASoC Codec Class Driver +======================= -The codec driver is generic and hardware independent code that configures the -codec to provide audio capture and playback. It should contain no code that is -specific to the target platform or machine. All platform and machine specific -code should be added to the platform and machine drivers respectively. +The codec class driver is generic and hardware independent code that configures +the codec, FM, MODEM, BT or external DSP to provide audio capture and playback. +It should contain no code that is specific to the target platform or machine. +All platform and machine specific code should be added to the platform and +machine drivers respectively. -Each codec driver *must* provide the following features:- +Each codec class driver *must* provide the following features:- 1) Codec DAI and PCM configuration - 2) Codec control IO - using I2C, 3 Wire(SPI) or both APIs + 2) Codec control IO - using RegMap API 3) Mixers and audio controls 4) Codec audio operations + 5) DAPM description. + 6) DAPM event handler. Optionally, codec drivers can also provide:- - 5) DAPM description. - 6) DAPM event handler. 7) DAC Digital mute control. Its probably best to use this guide in conjunction with the existing codec @@ -64,26 +65,9 @@ struct snd_soc_dai_driver wm8731_dai = { 2 - Codec control IO -------------------- The codec can usually be controlled via an I2C or SPI style interface -(AC97 combines control with data in the DAI). The codec drivers provide -functions to read and write the codec registers along with supplying a -register cache:- - - /* IO control data and register cache */ - void *control_data; /* codec control (i2c/3wire) data */ - void *reg_cache; - -Codec read/write should do any data formatting and call the hardware -read write below to perform the IO. These functions are called by the -core and ALSA when performing DAPM or changing the mixer:- - - unsigned int (*read)(struct snd_soc_codec *, unsigned int); - int (*write)(struct snd_soc_codec *, unsigned int, unsigned int); - -Codec hardware IO functions - usually points to either the I2C, SPI or AC97 -read/write:- - - hw_write_t hw_write; - hw_read_t hw_read; +(AC97 combines control with data in the DAI). The codec driver should use the +Regmap API for all codec IO. Please see include/linux/regmap.h and existing +codec drivers for example regmap usage. 3 - Mixers and audio controls @@ -127,7 +111,7 @@ Defines a stereo enumerated control 4 - Codec Audio Operations -------------------------- -The codec driver also supports the following ALSA operations:- +The codec driver also supports the following ALSA PCM operations:- /* SoC audio ops */ struct snd_soc_ops { diff --git a/Documentation/sound/alsa/soc/dapm.txt b/Documentation/sound/alsa/soc/dapm.txt index 05bf5a0eee4..6faab488000 100644 --- a/Documentation/sound/alsa/soc/dapm.txt +++ b/Documentation/sound/alsa/soc/dapm.txt @@ -21,7 +21,7 @@ level power systems. There are 4 power domains within DAPM - 1. Codec domain - VREF, VMID (core codec and audio power) + 1. Codec bias domain - VREF, VMID (core codec and audio power) Usually controlled at codec probe/remove and suspend/resume, although can be set at stream time if power is not needed for sidetone, etc. @@ -30,7 +30,7 @@ There are 4 power domains within DAPM machine driver and responds to asynchronous events e.g when HP are inserted - 3. Path domain - audio susbsystem signal paths + 3. Path domain - audio subsystem signal paths Automatically set when mixer and mux settings are changed by the user. e.g. alsamixer, amixer. @@ -63,14 +63,22 @@ Audio DAPM widgets fall into a number of types:- o Line - Line Input/Output (and optional Jack) o Speaker - Speaker o Supply - Power or clock supply widget used by other widgets. + o Regulator - External regulator that supplies power to audio components. + o Clock - External clock that supplies clock to audio components. + o AIF IN - Audio Interface Input (with TDM slot mask). + o AIF OUT - Audio Interface Output (with TDM slot mask). + o Siggen - Signal Generator. + o DAI IN - Digital Audio Interface Input. + o DAI OUT - Digital Audio Interface Output. + o DAI Link - DAI Link between two DAI structures */ o Pre - Special PRE widget (exec before all others) o Post - Special POST widget (exec after all others) (Widgets are defined in include/sound/soc-dapm.h) -Widgets are usually added in the codec driver and the machine driver. There are -convenience macros defined in soc-dapm.h that can be used to quickly build a -list of widgets of the codecs and machines DAPM widgets. +Widgets can be added to the sound card by any of the component driver types. +There are convenience macros defined in soc-dapm.h that can be used to quickly +build a list of widgets of the codecs and machines DAPM widgets. Most widgets have a name, register, shift and invert. Some widgets have extra parameters for stream name and kcontrols. @@ -80,11 +88,13 @@ parameters for stream name and kcontrols. ------------------------- Stream Widgets relate to the stream power domain and only consist of ADCs -(analog to digital converters) and DACs (digital to analog converters). +(analog to digital converters), DACs (digital to analog converters), +AIF IN and AIF OUT. Stream widgets have the following format:- SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert), +SND_SOC_DAPM_AIF_IN(name, stream, slot, reg, shift, invert) NOTE: the stream name must match the corresponding stream name in your codec snd_soc_codec_dai. @@ -94,6 +104,11 @@ e.g. stream widgets for HiFi playback and capture SND_SOC_DAPM_DAC("HiFi DAC", "HiFi Playback", REG, 3, 1), SND_SOC_DAPM_ADC("HiFi ADC", "HiFi Capture", REG, 2, 1), +e.g. stream widgets for AIF + +SND_SOC_DAPM_AIF_IN("AIF1RX", "AIF1 Playback", 0, SND_SOC_NOPM, 0, 0), +SND_SOC_DAPM_AIF_OUT("AIF1TX", "AIF1 Capture", 0, SND_SOC_NOPM, 0, 0), + 2.2 Path Domain Widgets ----------------------- @@ -121,12 +136,14 @@ If you dont want the mixer elements prefixed with the name of the mixer widget, you can use SND_SOC_DAPM_MIXER_NAMED_CTL instead. the parameters are the same as for SND_SOC_DAPM_MIXER. -2.3 Platform/Machine domain Widgets ------------------------------------ + +2.3 Machine domain Widgets +-------------------------- Machine widgets are different from codec widgets in that they don't have a codec register bit associated with them. A machine widget is assigned to each -machine audio component (non codec) that can be independently powered. e.g. +machine audio component (non codec or DSP) that can be independently +powered. e.g. o Speaker Amp o Microphone Bias @@ -146,12 +163,12 @@ static int spitz_mic_bias(struct snd_soc_dapm_widget* w, int event) SND_SOC_DAPM_MIC("Mic Jack", spitz_mic_bias), -2.4 Codec Domain ----------------- +2.4 Codec (BIAS) Domain +----------------------- -The codec power domain has no widgets and is handled by the codecs DAPM event -handler. This handler is called when the codec powerstate is changed wrt to any -stream event or by kernel PM events. +The codec bias power domain has no widgets and is handled by the codecs DAPM +event handler. This handler is called when the codec powerstate is changed wrt +to any stream event or by kernel PM events. 2.5 Virtual Widgets @@ -169,15 +186,16 @@ After all the widgets have been defined, they can then be added to the DAPM subsystem individually with a call to snd_soc_dapm_new_control(). -3. Codec Widget Interconnections -================================ +3. Codec/DSP Widget Interconnections +==================================== -Widgets are connected to each other within the codec and machine by audio paths -(called interconnections). Each interconnection must be defined in order to -create a map of all audio paths between widgets. +Widgets are connected to each other within the codec, platform and machine by +audio paths (called interconnections). Each interconnection must be defined in +order to create a map of all audio paths between widgets. -This is easiest with a diagram of the codec (and schematic of the machine audio -system), as it requires joining widgets together via their audio signal paths. +This is easiest with a diagram of the codec or DSP (and schematic of the machine +audio system), as it requires joining widgets together via their audio signal +paths. e.g., from the WM8731 output mixer (wm8731.c) @@ -247,16 +265,9 @@ machine and includes the codec. e.g. o Mic Jack o Codec Pins -When a codec pin is NC it can be marked as not used with a call to - -snd_soc_dapm_set_endpoint(codec, "Widget Name", 0); - -The last argument is 0 for inactive and 1 for active. This way the pin and its -input widget will never be powered up and consume power. - -This also applies to machine widgets. e.g. if a headphone is connected to a -jack then the jack can be marked active. If the headphone is removed, then -the headphone jack can be marked inactive. +Endpoints are added to the DAPM graph so that their usage can be determined in +order to save power. e.g. NC codecs pins will be switched OFF, unconnected +jacks can also be switched OFF. 5 DAPM Widget Events diff --git a/Documentation/sound/alsa/soc/machine.txt b/Documentation/sound/alsa/soc/machine.txt index d50c14df341..74056dba52b 100644 --- a/Documentation/sound/alsa/soc/machine.txt +++ b/Documentation/sound/alsa/soc/machine.txt @@ -1,8 +1,10 @@ ASoC Machine Driver =================== -The ASoC machine (or board) driver is the code that glues together the platform -and codec drivers. +The ASoC machine (or board) driver is the code that glues together all the +component drivers (e.g. codecs, platforms and DAIs). It also describes the +relationships between each componnent which include audio paths, GPIOs, +interrupts, clocking, jacks and voltage regulators. The machine driver can contain codec and platform specific code. It registers the audio subsystem with the kernel as a platform device and is represented by diff --git a/Documentation/sound/alsa/soc/platform.txt b/Documentation/sound/alsa/soc/platform.txt index d57efad37e0..3a08a2c9150 100644 --- a/Documentation/sound/alsa/soc/platform.txt +++ b/Documentation/sound/alsa/soc/platform.txt @@ -1,9 +1,9 @@ ASoC Platform Driver ==================== -An ASoC platform driver can be divided into audio DMA and SoC DAI configuration -and control. The platform drivers only target the SoC CPU and must have no board -specific code. +An ASoC platform driver class can be divided into audio DMA drivers, SoC DAI +drivers and DSP drivers. The platform drivers only target the SoC CPU and must +have no board specific code. Audio DMA ========= @@ -64,3 +64,16 @@ Each SoC DAI driver must provide the following features:- 5) Suspend and resume (optional) Please see codec.txt for a description of items 1 - 4. + + +SoC DSP Drivers +=============== + +Each SoC DSP driver usually supplies the following features :- + + 1) DAPM graph + 2) Mixer controls + 3) DMA IO to/from DSP buffers (if applicable) + 4) Definition of DSP front end (FE) PCM devices. + +Please see DPCM.txt for a description of item 4. diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 9d4c1d18ad4..26b7ee491df 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -290,13 +290,24 @@ Default value is "/sbin/hotplug". kptr_restrict: This toggle indicates whether restrictions are placed on -exposing kernel addresses via /proc and other interfaces. When -kptr_restrict is set to (0), there are no restrictions. When -kptr_restrict is set to (1), the default, kernel pointers -printed using the %pK format specifier will be replaced with 0's -unless the user has CAP_SYSLOG. When kptr_restrict is set to -(2), kernel pointers printed using %pK will be replaced with 0's -regardless of privileges. +exposing kernel addresses via /proc and other interfaces. + +When kptr_restrict is set to (0), the default, there are no restrictions. + +When kptr_restrict is set to (1), kernel pointers printed using the %pK +format specifier will be replaced with 0's unless the user has CAP_SYSLOG +and effective user and group ids are equal to the real ids. This is +because %pK checks are done at read() time rather than open() time, so +if permissions are elevated between the open() and the read() (e.g via +a setuid binary) then %pK will not leak kernel pointers to unprivileged +users. Note, this is a temporary solution only. The correct long-term +solution is to do the permission checks at open() time. Consider removing +world read permissions from files that use %pK, and using dmesg_restrict +to protect against uses of %pK in dmesg(8) if leaking kernel pointer +values to unprivileged users is a concern. + +When kptr_restrict is set to (2), kernel pointers printed using +%pK will be replaced with 0's regardless of privileges. ============================================================== @@ -355,6 +366,82 @@ utilize. ============================================================== +numa_balancing + +Enables/disables automatic page fault based NUMA memory +balancing. Memory is moved automatically to nodes +that access it often. + +Enables/disables automatic NUMA memory balancing. On NUMA machines, there +is a performance penalty if remote memory is accessed by a CPU. When this +feature is enabled the kernel samples what task thread is accessing memory +by periodically unmapping pages and later trapping a page fault. At the +time of the page fault, it is determined if the data being accessed should +be migrated to a local memory node. + +The unmapping of pages and trapping faults incur additional overhead that +ideally is offset by improved memory locality but there is no universal +guarantee. If the target workload is already bound to NUMA nodes then this +feature should be disabled. Otherwise, if the system overhead from the +feature is too high then the rate the kernel samples for NUMA hinting +faults may be controlled by the numa_balancing_scan_period_min_ms, +numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, +numa_balancing_scan_size_mb, numa_balancing_settle_count sysctls and +numa_balancing_migrate_deferred. + +============================================================== + +numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms, +numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb + +Automatic NUMA balancing scans tasks address space and unmaps pages to +detect if pages are properly placed or if the data should be migrated to a +memory node local to where the task is running. Every "scan delay" the task +scans the next "scan size" number of pages in its address space. When the +end of the address space is reached the scanner restarts from the beginning. + +In combination, the "scan delay" and "scan size" determine the scan rate. +When "scan delay" decreases, the scan rate increases. The scan delay and +hence the scan rate of every task is adaptive and depends on historical +behaviour. If pages are properly placed then the scan delay increases, +otherwise the scan delay decreases. The "scan size" is not adaptive but +the higher the "scan size", the higher the scan rate. + +Higher scan rates incur higher system overhead as page faults must be +trapped and potentially data must be migrated. However, the higher the scan +rate, the more quickly a tasks memory is migrated to a local node if the +workload pattern changes and minimises performance impact due to remote +memory accesses. These sysctls control the thresholds for scan delays and +the number of pages scanned. + +numa_balancing_scan_period_min_ms is the minimum time in milliseconds to +scan a tasks virtual memory. It effectively controls the maximum scanning +rate for each task. + +numa_balancing_scan_delay_ms is the starting "scan delay" used for a task +when it initially forks. + +numa_balancing_scan_period_max_ms is the maximum time in milliseconds to +scan a tasks virtual memory. It effectively controls the minimum scanning +rate for each task. + +numa_balancing_scan_size_mb is how many megabytes worth of pages are +scanned for a given scan. + +numa_balancing_settle_count is how many scan periods must complete before +the schedule balancer stops pushing the task towards a preferred node. This +gives the scheduler a chance to place the task on an alternative node if the +preferred node is overloaded. + +numa_balancing_migrate_deferred is how many page migrations get skipped +unconditionally, after a page migration is skipped because a page is shared +with other tasks. This reduces page migration overhead, and determines +how much stronger the "move task near its memory" policy scheduler becomes, +versus the "move memory near its task" memory management policy, for workloads +with shared memory. + +============================================================== + osrelease, ostype & version: # cat osrelease diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 79a797eb3e8..1fbd4eb7b64 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -119,8 +119,11 @@ other appears as 0 when read. dirty_background_ratio -Contains, as a percentage of total system memory, the number of pages at which -the background kernel flusher threads will start writing out dirty data. +Contains, as a percentage of total available memory that contains free pages +and reclaimable pages, the number of pages at which the background kernel +flusher threads will start writing out dirty data. + +The total avaiable memory is not equal to total system memory. ============================================================== @@ -151,9 +154,11 @@ interval will be written out next time a flusher thread wakes up. dirty_ratio -Contains, as a percentage of total system memory, the number of pages at which -a process which is generating disk writes will itself start writing out dirty -data. +Contains, as a percentage of total available memory that contains free pages +and reclaimable pages, the number of pages at which a process which is +generating disk writes will itself start writing out dirty data. + +The total avaiable memory is not equal to total system memory. ============================================================== diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index 8cb4d7842a5..0e307c94809 100644 --- a/Documentation/sysrq.txt +++ b/Documentation/sysrq.txt @@ -11,27 +11,29 @@ regardless of whatever else it is doing, unless it is completely locked up. You need to say "yes" to 'Magic SysRq key (CONFIG_MAGIC_SYSRQ)' when configuring the kernel. When running a kernel with SysRq compiled in, /proc/sys/kernel/sysrq controls the functions allowed to be invoked via -the SysRq key. By default the file contains 1 which means that every -possible SysRq request is allowed (in older versions SysRq was disabled -by default, and you were required to specifically enable it at run-time -but this is not the case any more). Here is the list of possible values -in /proc/sys/kernel/sysrq: +the SysRq key. The default value in this file is set by the +CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE config symbol, which itself defaults +to 1. Here is the list of possible values in /proc/sys/kernel/sysrq: 0 - disable sysrq completely 1 - enable all functions of sysrq >1 - bitmask of allowed sysrq functions (see below for detailed function description): - 2 - enable control of console logging level - 4 - enable control of keyboard (SAK, unraw) - 8 - enable debugging dumps of processes etc. - 16 - enable sync command - 32 - enable remount read-only - 64 - enable signalling of processes (term, kill, oom-kill) - 128 - allow reboot/poweroff - 256 - allow nicing of all RT tasks + 2 = 0x2 - enable control of console logging level + 4 = 0x4 - enable control of keyboard (SAK, unraw) + 8 = 0x8 - enable debugging dumps of processes etc. + 16 = 0x10 - enable sync command + 32 = 0x20 - enable remount read-only + 64 = 0x40 - enable signalling of processes (term, kill, oom-kill) + 128 = 0x80 - allow reboot/poweroff + 256 = 0x100 - allow nicing of all RT tasks You can set the value in the file by the following command: echo "number" >/proc/sys/kernel/sysrq +The number may be written here either as decimal or as hexadecimal +with the 0x prefix. CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE must always be +written in hexadecimal. + Note that the value of /proc/sys/kernel/sysrq influences only the invocation via a keyboard. Invocation of any operation via /proc/sysrq-trigger is always allowed (by a user with admin privileges). diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index ea2d35d64d2..bd365988e8d 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -655,7 +655,11 @@ explains which is which. read the irq flags variable, an 'X' will always be printed here. - need-resched: 'N' task need_resched is set, '.' otherwise. + need-resched: + 'N' both TIF_NEED_RESCHED and PREEMPT_NEED_RESCHED is set, + 'n' only TIF_NEED_RESCHED is set, + 'p' only PREEMPT_NEED_RESCHED is set, + '.' otherwise. hardirq/softirq: 'H' - hard irq occurred inside a softirq. diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.txt index ac4170dd0f2..6b018b53177 100644 --- a/Documentation/trace/tracepoints.txt +++ b/Documentation/trace/tracepoints.txt @@ -114,3 +114,8 @@ core kernel image or in modules. If the tracepoint has to be used in kernel modules, an EXPORT_TRACEPOINT_SYMBOL_GPL() or EXPORT_TRACEPOINT_SYMBOL() can be used to export the defined tracepoints. + +Note: The convenience macro TRACE_EVENT provides an alternative way to + define tracepoints. Check http://lwn.net/Articles/379903, + http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362 + for a series of articles with more details. diff --git a/Documentation/vm/zswap.txt b/Documentation/vm/zswap.txt index 7e492d8aaea..00c3d31e797 100644 --- a/Documentation/vm/zswap.txt +++ b/Documentation/vm/zswap.txt @@ -8,7 +8,7 @@ significant performance improvement if reads from the compressed cache are faster than reads from a swap device. NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memory -reclaim. This interaction has not be fully explored on the large set of +reclaim. This interaction has not been fully explored on the large set of potential configurations and workloads that exist. For this reason, zswap is a work in progress and should be considered experimental. @@ -23,7 +23,7 @@ Some potential benefits: drastically reducing life-shortening writes. Zswap evicts pages from compressed cache on an LRU basis to the backing swap -device when the compressed pool reaches it size limit. This requirement had +device when the compressed pool reaches its size limit. This requirement had been identified in prior community discussions. To enabled zswap, the "enabled" attribute must be set to 1 at boot time. e.g. @@ -37,7 +37,7 @@ the backing swap device in the case that the compressed pool is full. Zswap makes use of zbud for the managing the compressed memory pool. Each allocation in zbud is not directly accessible by address. Rather, a handle is -return by the allocation routine and that handle must be mapped before being +returned by the allocation routine and that handle must be mapped before being accessed. The compressed memory pool grows on demand and shrinks as compressed pages are freed. The pool is not preallocated. @@ -56,7 +56,7 @@ in the swap_map goes to 0) the swap code calls the zswap invalidate function, via frontswap, to free the compressed entry. Zswap seeks to be simple in its policies. Sysfs attributes allow for one user -controlled policies: +controlled policy: * max_pool_percent - The maximum percentage of memory that the compressed pool can occupy. |