diff options
Diffstat (limited to 'Documentation')
137 files changed, 5103 insertions, 1510 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 45b3df936d2f..0c4cc688e89a 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -187,6 +187,8 @@ firmware_class/ - request_firmware() hotplug interface info. flexible-arrays.txt - how to make use of flexible sized arrays in linux +fmc/ + - information about the FMC bus abstraction frv/ - Fujitsu FR-V Linux documentation. futex-requeue-pi.txt diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget new file mode 100644 index 000000000000..01e769d6984d --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget @@ -0,0 +1,81 @@ +What: /config/usb-gadget +Date: Jun 2013 +KenelVersion: 3.11 +Description: + This group contains sub-groups corresponding to created + USB gadgets. + +What: /config/usb-gadget/gadget +Date: Jun 2013 +KenelVersion: 3.11 +Description: + + The attributes of a gadget: + + UDC - bind a gadget to UDC/unbind a gadget; + write UDC's name found in /sys/class/udc/* + to bind a gadget, empty string "" to unbind. + + bDeviceClass - USB device class code + bDeviceSubClass - USB device subclass code + bDeviceProtocol - USB device protocol code + bMaxPacketSize0 - maximum endpoint 0 packet size + bcdDevice - bcd device release number + bcdUSB - bcd USB specification version number + idProduct - product ID + idVendor - vendor ID + +What: /config/usb-gadget/gadget/configs +Date: Jun 2013 +KenelVersion: 3.11 +Description: + This group contains a USB gadget's configurations + +What: /config/usb-gadget/gadget/configs/config +Date: Jun 2013 +KernelVersion: 3.11 +Description: + The attributes of a configuration: + + bmAttributes - configuration characteristics + MaxPower - maximum power consumption from the bus + +What: /config/usb-gadget/gadget/configs/config/strings +Date: Jun 2013 +KernelVersion: 3.11 +Description: + This group contains subdirectories for language-specific + strings for this configuration. + +What: /config/usb-gadget/gadget/configs/config/strings/language +Date: Jun 2013 +KernelVersion: 3.11 +Description: + The attributes: + + configuration - configuration description + + +What: /config/usb-gadget/gadget/functions +Date: Jun 2013 +KenelVersion: 3.11 +Description: + This group contains functions available to this USB gadget. + +What: /config/usb-gadget/gadget/strings +Date: Jun 2013 +KenelVersion: 3.11 +Description: + This group contains subdirectories for language-specific + strings for this gadget. + +What: /config/usb-gadget/gadget/strings/language +Date: Jun 2013 +KenelVersion: 3.11 +Description: + The attributes: + + serialnumber - gadget's serial number (string) + product - gadget's product description + manufacturer - gadget's manufacturer description + diff --git a/Documentation/ABI/testing/configfs-usb-gadget-acm b/Documentation/ABI/testing/configfs-usb-gadget-acm new file mode 100644 index 000000000000..5708a568b5f6 --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-acm @@ -0,0 +1,8 @@ +What: /config/usb-gadget/gadget/functions/acm.name +Date: Jun 2013 +KenelVersion: 3.11 +Description: + + This item contains just one readonly attribute: port_num. + It contains the port number of the /dev/ttyGS<n> device + associated with acm function's instance "name". diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ecm b/Documentation/ABI/testing/configfs-usb-gadget-ecm new file mode 100644 index 000000000000..6b9a582ce0b5 --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-ecm @@ -0,0 +1,16 @@ +What: /config/usb-gadget/gadget/functions/ecm.name +Date: Jun 2013 +KenelVersion: 3.11 +Description: + The attributes: + + ifname - network device interface name associated with + this function instance + qmult - queue length multiplier for high and + super speed + host_addr - MAC address of host's end of this + Ethernet over USB link + dev_addr - MAC address of device's end of this + Ethernet over USB link + + diff --git a/Documentation/ABI/testing/configfs-usb-gadget-eem b/Documentation/ABI/testing/configfs-usb-gadget-eem new file mode 100644 index 000000000000..dbddf36b48b3 --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-eem @@ -0,0 +1,14 @@ +What: /config/usb-gadget/gadget/functions/eem.name +Date: Jun 2013 +KenelVersion: 3.11 +Description: + The attributes: + + ifname - network device interface name associated with + this function instance + qmult - queue length multiplier for high and + super speed + host_addr - MAC address of host's end of this + Ethernet over USB link + dev_addr - MAC address of device's end of this + Ethernet over USB link diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ncm b/Documentation/ABI/testing/configfs-usb-gadget-ncm new file mode 100644 index 000000000000..bc309f42357d --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-ncm @@ -0,0 +1,15 @@ +What: /config/usb-gadget/gadget/functions/ncm.name +Date: Jun 2013 +KenelVersion: 3.11 +Description: + The attributes: + + ifname - network device interface name associated with + this function instance + qmult - queue length multiplier for high and + super speed + host_addr - MAC address of host's end of this + Ethernet over USB link + dev_addr - MAC address of device's end of this + Ethernet over USB link + diff --git a/Documentation/ABI/testing/configfs-usb-gadget-obex b/Documentation/ABI/testing/configfs-usb-gadget-obex new file mode 100644 index 000000000000..aaa5c96fb7c6 --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-obex @@ -0,0 +1,9 @@ +What: /config/usb-gadget/gadget/functions/obex.name +Date: Jun 2013 +KenelVersion: 3.11 +Description: + + This item contains just one readonly attribute: port_num. + It contains the port number of the /dev/ttyGS<n> device + associated with obex function's instance "name". + diff --git a/Documentation/ABI/testing/configfs-usb-gadget-phonet b/Documentation/ABI/testing/configfs-usb-gadget-phonet new file mode 100644 index 000000000000..3e3b742cdfd7 --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-phonet @@ -0,0 +1,8 @@ +What: /config/usb-gadget/gadget/functions/phonet.name +Date: Jun 2013 +KenelVersion: 3.11 +Description: + + This item contains just one readonly attribute: ifname. + It contains the network interface name assigned during + network device registration. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-rndis b/Documentation/ABI/testing/configfs-usb-gadget-rndis new file mode 100644 index 000000000000..822e6dad8fc0 --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-rndis @@ -0,0 +1,14 @@ +What: /config/usb-gadget/gadget/functions/rndis.name +Date: Jun 2013 +KenelVersion: 3.11 +Description: + The attributes: + + ifname - network device interface name associated with + this function instance + qmult - queue length multiplier for high and + super speed + host_addr - MAC address of host's end of this + Ethernet over USB link + dev_addr - MAC address of device's end of this + Ethernet over USB link diff --git a/Documentation/ABI/testing/configfs-usb-gadget-serial b/Documentation/ABI/testing/configfs-usb-gadget-serial new file mode 100644 index 000000000000..16f130c1501f --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-serial @@ -0,0 +1,9 @@ +What: /config/usb-gadget/gadget/functions/gser.name +Date: Jun 2013 +KenelVersion: 3.11 +Description: + + This item contains just one readonly attribute: port_num. + It contains the port number of the /dev/ttyGS<n> device + associated with gser function's instance "name". + diff --git a/Documentation/ABI/testing/configfs-usb-gadget-subset b/Documentation/ABI/testing/configfs-usb-gadget-subset new file mode 100644 index 000000000000..154ae597cd99 --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-subset @@ -0,0 +1,14 @@ +What: /config/usb-gadget/gadget/functions/geth.name +Date: Jun 2013 +KenelVersion: 3.11 +Description: + The attributes: + + ifname - network device interface name associated with + this function instance + qmult - queue length multiplier for high and + super speed + host_addr - MAC address of host's end of this + Ethernet over USB link + dev_addr - MAC address of device's end of this + Ethernet over USB link diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events index 0adeb524c0d4..8b25ffb42562 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events @@ -27,14 +27,36 @@ Description: Generic performance monitoring events "basename". -What: /sys/devices/cpu/events/PM_LD_MISS_L1 - /sys/devices/cpu/events/PM_LD_REF_L1 - /sys/devices/cpu/events/PM_CYC +What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL /sys/devices/cpu/events/PM_BRU_FIN - /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC /sys/devices/cpu/events/PM_BRU_MPRED - /sys/devices/cpu/events/PM_INST_CMPL /sys/devices/cpu/events/PM_CMPLU_STALL + /sys/devices/cpu/events/PM_CMPLU_STALL_BRU + /sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS + /sys/devices/cpu/events/PM_CMPLU_STALL_DFU + /sys/devices/cpu/events/PM_CMPLU_STALL_DIV + /sys/devices/cpu/events/PM_CMPLU_STALL_ERAT_MISS + /sys/devices/cpu/events/PM_CMPLU_STALL_FXU + /sys/devices/cpu/events/PM_CMPLU_STALL_IFU + /sys/devices/cpu/events/PM_CMPLU_STALL_LSU + /sys/devices/cpu/events/PM_CMPLU_STALL_REJECT + /sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR + /sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR_LONG + /sys/devices/cpu/events/PM_CMPLU_STALL_STORE + /sys/devices/cpu/events/PM_CMPLU_STALL_THRD + /sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR + /sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR_LONG + /sys/devices/cpu/events/PM_CYC + /sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED + /sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED_IC_MISS + /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC + /sys/devices/cpu/events/PM_GCT_NOSLOT_IC_MISS + /sys/devices/cpu/events/PM_GRP_CMPL + /sys/devices/cpu/events/PM_INST_CMPL + /sys/devices/cpu/events/PM_LD_MISS_L1 + /sys/devices/cpu/events/PM_LD_REF_L1 + /sys/devices/cpu/events/PM_RUN_CYC + /sys/devices/cpu/events/PM_RUN_INST_CMPL Date: 2013/01/08 diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format index 079afc71363d..77f47ff5ee02 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format @@ -9,6 +9,12 @@ Description: we want to export, so that userspace can deal with sane name/value pairs. + Userspace must be prepared for the possibility that attributes + define overlapping bit ranges. For example: + attr1 = 'config:0-23' + attr2 = 'config:0-7' + attr3 = 'config:12-35' + Example: 'config1:1,6-10,44' Defines contents of attribute that occupies bits 1,6-10,44 of perf_event_attr::config1. diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 2e33dc6b2346..dda81ffae5cf 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -690,45 +690,45 @@ Description: Actually start the buffer capture up. Will start trigger if first device and appropriate. -What: /sys/bus/iio/devices/iio:deviceX/buffer/scan_elements +What: /sys/bus/iio/devices/iio:deviceX/scan_elements KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: Directory containing interfaces for elements that will be captured for a single triggered sample set in the buffer. -What: /sys/.../buffer/scan_elements/in_accel_x_en -What: /sys/.../buffer/scan_elements/in_accel_y_en -What: /sys/.../buffer/scan_elements/in_accel_z_en -What: /sys/.../buffer/scan_elements/in_anglvel_x_en -What: /sys/.../buffer/scan_elements/in_anglvel_y_en -What: /sys/.../buffer/scan_elements/in_anglvel_z_en -What: /sys/.../buffer/scan_elements/in_magn_x_en -What: /sys/.../buffer/scan_elements/in_magn_y_en -What: /sys/.../buffer/scan_elements/in_magn_z_en -What: /sys/.../buffer/scan_elements/in_timestamp_en -What: /sys/.../buffer/scan_elements/in_voltageY_supply_en -What: /sys/.../buffer/scan_elements/in_voltageY_en -What: /sys/.../buffer/scan_elements/in_voltageY-voltageZ_en -What: /sys/.../buffer/scan_elements/in_incli_x_en -What: /sys/.../buffer/scan_elements/in_incli_y_en -What: /sys/.../buffer/scan_elements/in_pressureY_en -What: /sys/.../buffer/scan_elements/in_pressure_en +What: /sys/.../iio:deviceX/scan_elements/in_accel_x_en +What: /sys/.../iio:deviceX/scan_elements/in_accel_y_en +What: /sys/.../iio:deviceX/scan_elements/in_accel_z_en +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_en +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_en +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en +What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en +What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en +What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en +What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en +What: /sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en +What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en +What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en +What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en +What: /sys/.../iio:deviceX/scan_elements/in_pressure_en KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: Scan element control for triggered data capture. -What: /sys/.../buffer/scan_elements/in_accel_type -What: /sys/.../buffer/scan_elements/in_anglvel_type -What: /sys/.../buffer/scan_elements/in_magn_type -What: /sys/.../buffer/scan_elements/in_incli_type -What: /sys/.../buffer/scan_elements/in_voltageY_type -What: /sys/.../buffer/scan_elements/in_voltage_type -What: /sys/.../buffer/scan_elements/in_voltageY_supply_type -What: /sys/.../buffer/scan_elements/in_timestamp_type -What: /sys/.../buffer/scan_elements/in_pressureY_type -What: /sys/.../buffer/scan_elements/in_pressure_type +What: /sys/.../iio:deviceX/scan_elements/in_accel_type +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_type +What: /sys/.../iio:deviceX/scan_elements/in_magn_type +What: /sys/.../iio:deviceX/scan_elements/in_incli_type +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_type +What: /sys/.../iio:deviceX/scan_elements/in_voltage_type +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type +What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type +What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type +What: /sys/.../iio:deviceX/scan_elements/in_pressure_type KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: @@ -752,29 +752,29 @@ Description: For other storage combinations this attribute will be extended appropriately. -What: /sys/.../buffer/scan_elements/in_accel_type_available +What: /sys/.../iio:deviceX/scan_elements/in_accel_type_available KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: If the type parameter can take one of a small set of values, this attribute lists them. -What: /sys/.../buffer/scan_elements/in_voltageY_index -What: /sys/.../buffer/scan_elements/in_voltageY_supply_index -What: /sys/.../buffer/scan_elements/in_accel_x_index -What: /sys/.../buffer/scan_elements/in_accel_y_index -What: /sys/.../buffer/scan_elements/in_accel_z_index -What: /sys/.../buffer/scan_elements/in_anglvel_x_index -What: /sys/.../buffer/scan_elements/in_anglvel_y_index -What: /sys/.../buffer/scan_elements/in_anglvel_z_index -What: /sys/.../buffer/scan_elements/in_magn_x_index -What: /sys/.../buffer/scan_elements/in_magn_y_index -What: /sys/.../buffer/scan_elements/in_magn_z_index -What: /sys/.../buffer/scan_elements/in_incli_x_index -What: /sys/.../buffer/scan_elements/in_incli_y_index -What: /sys/.../buffer/scan_elements/in_timestamp_index -What: /sys/.../buffer/scan_elements/in_pressureY_index -What: /sys/.../buffer/scan_elements/in_pressure_index +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_index +What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index +What: /sys/.../iio:deviceX/scan_elements/in_accel_x_index +What: /sys/.../iio:deviceX/scan_elements/in_accel_y_index +What: /sys/.../iio:deviceX/scan_elements/in_accel_z_index +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_index +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_index +What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index +What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index +What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index +What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index +What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index +What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index +What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index +What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index +What: /sys/.../iio:deviceX/scan_elements/in_pressure_index KernelVersion: 2.6.37 Contact: linux-iio@vger.kernel.org Description: diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index 1ce5ae329c04..5210a51c90fd 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -64,7 +64,6 @@ Description: Writing a non-zero value to this attribute will force a rescan of all PCI buses in the system, and re-discover previously removed devices. - Depends on CONFIG_HOTPLUG. What: /sys/bus/pci/devices/.../msi_irqs/ Date: September, 2011 @@ -90,7 +89,6 @@ Contact: Linux PCI developers <linux-pci@vger.kernel.org> Description: Writing a non-zero value to this attribute will hot-remove the PCI device and any of its children. - Depends on CONFIG_HOTPLUG. What: /sys/bus/pci/devices/.../pci_bus/.../rescan Date: May 2011 @@ -99,7 +97,7 @@ Description: Writing a non-zero value to this attribute will force a rescan of the bus and all child buses, and re-discover devices removed earlier from this - part of the device tree. Depends on CONFIG_HOTPLUG. + part of the device tree. What: /sys/bus/pci/devices/.../rescan Date: January 2009 @@ -109,7 +107,6 @@ Description: force a rescan of the device's parent bus and all child buses, and re-discover devices removed earlier from this part of the device tree. - Depends on CONFIG_HOTPLUG. What: /sys/bus/pci/devices/.../reset Date: July 2009 diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index f093e59cbe5f..9759b8c91332 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -236,3 +236,30 @@ Description: This attribute is to expose these information to user space. The file will read "hotplug", "wired" and "not used" if the information is available, and "unknown" otherwise. + +What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout +Date: May 2013 +Contact: Mathias Nyman <mathias.nyman@linux.intel.com> +Description: + USB 2.0 devices may support hardware link power management (LPM) + L1 sleep state. The usb2_lpm_l1_timeout attribute allows + tuning the timeout for L1 inactivity timer (LPM timer), e.g. + needed inactivity time before host requests the device to go to L1 sleep. + Useful for power management tuning. + Supported values are 0 - 65535 microseconds. + +What: /sys/bus/usb/devices/.../power/usb2_lpm_besl +Date: May 2013 +Contact: Mathias Nyman <mathias.nyman@linux.intel.com> +Description: + USB 2.0 devices that support hardware link power management (LPM) + L1 sleep state now use a best effort service latency value (BESL) to + indicate the best effort to resumption of service to the device after the + initiation of the resume event. + If the device does not have a preferred besl value then the host can select + one instead. This usb2_lpm_besl attribute allows to tune the host selected besl + value in order to tune power saving and service latency. + + Supported values are 0 - 15. + More information on how besl values map to microseconds can be found in + USB 2.0 ECN Errata for Link Power Management, section 4.10) diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc index 25b1e751b777..5977e2875325 100644 --- a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc +++ b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc @@ -36,3 +36,22 @@ Description: Refer to [ECMA-368] section 10.3.1.1 for the value to use. + +What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_dnts +Date: June 2013 +KernelVersion: 3.11 +Contact: Thomas Pugliese <thomas.pugliese@gmail.com> +Description: + The device notification time slot (DNTS) count and inverval in + milliseconds that the WUSB host should use. This controls how + often the devices will have the opportunity to send + notifications to the host. + +What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_retry_count +Date: June 2013 +KernelVersion: 3.11 +Contact: Thomas Pugliese <thomas.pugliese@gmail.com> +Description: + The number of retries that the WUSB host should attempt + before reporting an error for a bus transaction. The range of + valid values is [0..15], where 0 indicates infinite retries. diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl index b3422341d65c..d16d21b7a3b7 100644 --- a/Documentation/DocBook/genericirq.tmpl +++ b/Documentation/DocBook/genericirq.tmpl @@ -464,6 +464,19 @@ if (desc->irq_data.chip->irq_eoi) protected via desc->lock, by the generic layer. </para> </chapter> + + <chapter id="genericchip"> + <title>Generic interrupt chip</title> + <para> + To avoid copies of identical implementations of irq chips the + core provides a configurable generic interrupt chip + implementation. Developers should check carefuly whether the + generic chip fits their needs before implementing the same + functionality slightly different themself. + </para> +!Ekernel/irq/generic-chip.c + </chapter> + <chapter id="structs"> <title>Structures</title> <para> diff --git a/Documentation/HOWTO b/Documentation/HOWTO index a9f288ff54f9..27faae3e3846 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO @@ -112,7 +112,7 @@ required reading: Other excellent descriptions of how to create patches properly are: "The Perfect Patch" - http://userweb.kernel.org/~akpm/stuff/tpp.txt + http://kerneltrap.org/node/3737 "Linux kernel patch submission format" http://linux.yyz.us/patch-format.html diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 79e789b8b8ea..7703ec73a9bb 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -354,12 +354,6 @@ over a rather long period of time, but improvements are always welcome! using RCU rather than SRCU, because RCU is almost always faster and easier to use than is SRCU. - If you need to enter your read-side critical section in a - hardirq or exception handler, and then exit that same read-side - critical section in the task that was interrupted, then you need - to srcu_read_lock_raw() and srcu_read_unlock_raw(), which avoid - the lockdep checking that would otherwise this practice illegal. - Also unlike other forms of RCU, explicit initialization and cleanup is required via init_srcu_struct() and cleanup_srcu_struct(). These are passed a "struct srcu_struct" diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt index 7dce8a17eac2..d8a502387397 100644 --- a/Documentation/RCU/torture.txt +++ b/Documentation/RCU/torture.txt @@ -182,12 +182,6 @@ torture_type The type of RCU to test, with string values as follows: "srcu_expedited": srcu_read_lock(), srcu_read_unlock() and synchronize_srcu_expedited(). - "srcu_raw": srcu_read_lock_raw(), srcu_read_unlock_raw(), - and call_srcu(). - - "srcu_raw_sync": srcu_read_lock_raw(), srcu_read_unlock_raw(), - and synchronize_srcu(). - "sched": preempt_disable(), preempt_enable(), and call_rcu_sched(). diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt index c776968f4463..f3778f8952da 100644 --- a/Documentation/RCU/trace.txt +++ b/Documentation/RCU/trace.txt @@ -530,113 +530,21 @@ o "nos" counts the number of times we balked for other reasons, e.g., the grace period ended first. -CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats +CONFIG_TINY_RCU debugfs Files and Formats These implementations of RCU provides a single debugfs file under the top-level directory RCU, namely rcu/rcudata, which displays fields in -rcu_bh_ctrlblk, rcu_sched_ctrlblk and, for CONFIG_TINY_PREEMPT_RCU, -rcu_preempt_ctrlblk. +rcu_bh_ctrlblk and rcu_sched_ctrlblk. The output of "cat rcu/rcudata" is as follows: -rcu_preempt: qlen=24 gp=1097669 g197/p197/c197 tasks=... - ttb=. btg=no ntb=184 neb=0 nnb=183 j=01f7 bt=0274 - normal balk: nt=1097669 gt=0 bt=371 b=0 ny=25073378 nos=0 - exp balk: bt=0 nos=0 rcu_sched: qlen: 0 rcu_bh: qlen: 0 -This is split into rcu_preempt, rcu_sched, and rcu_bh sections, with the -rcu_preempt section appearing only in CONFIG_TINY_PREEMPT_RCU builds. -The last three lines of the rcu_preempt section appear only in -CONFIG_RCU_BOOST kernel builds. The fields are as follows: +This is split into rcu_sched and rcu_bh sections. The field is as +follows: o "qlen" is the number of RCU callbacks currently waiting either for an RCU grace period or waiting to be invoked. This is the only field present for rcu_sched and rcu_bh, due to the short-circuiting of grace period in those two cases. - -o "gp" is the number of grace periods that have completed. - -o "g197/p197/c197" displays the grace-period state, with the - "g" number being the number of grace periods that have started - (mod 256), the "p" number being the number of grace periods - that the CPU has responded to (also mod 256), and the "c" - number being the number of grace periods that have completed - (once again mode 256). - - Why have both "gp" and "g"? Because the data flowing into - "gp" is only present in a CONFIG_RCU_TRACE kernel. - -o "tasks" is a set of bits. The first bit is "T" if there are - currently tasks that have recently blocked within an RCU - read-side critical section, the second bit is "N" if any of the - aforementioned tasks are blocking the current RCU grace period, - and the third bit is "E" if any of the aforementioned tasks are - blocking the current expedited grace period. Each bit is "." - if the corresponding condition does not hold. - -o "ttb" is a single bit. It is "B" if any of the blocked tasks - need to be priority boosted and "." otherwise. - -o "btg" indicates whether boosting has been carried out during - the current grace period, with "exp" indicating that boosting - is in progress for an expedited grace period, "no" indicating - that boosting has not yet started for a normal grace period, - "begun" indicating that boosting has bebug for a normal grace - period, and "done" indicating that boosting has completed for - a normal grace period. - -o "ntb" is the total number of tasks subjected to RCU priority boosting - periods since boot. - -o "neb" is the number of expedited grace periods that have had - to resort to RCU priority boosting since boot. - -o "nnb" is the number of normal grace periods that have had - to resort to RCU priority boosting since boot. - -o "j" is the low-order 16 bits of the jiffies counter in hexadecimal. - -o "bt" is the low-order 16 bits of the value that the jiffies counter - will have at the next time that boosting is scheduled to begin. - -o In the line beginning with "normal balk", the fields are as follows: - - o "nt" is the number of times that the system balked from - boosting because there were no blocked tasks to boost. - Note that the system will balk from boosting even if the - grace period is overdue when the currently running task - is looping within an RCU read-side critical section. - There is no point in boosting in this case, because - boosting a running task won't make it run any faster. - - o "gt" is the number of times that the system balked - from boosting because, although there were blocked tasks, - none of them were preventing the current grace period - from completing. - - o "bt" is the number of times that the system balked - from boosting because boosting was already in progress. - - o "b" is the number of times that the system balked from - boosting because boosting had already completed for - the grace period in question. - - o "ny" is the number of times that the system balked from - boosting because it was not yet time to start boosting - the grace period in question. - - o "nos" is the number of times that the system balked from - boosting for inexplicable ("not otherwise specified") - reasons. This can actually happen due to races involving - increments of the jiffies counter. - -o In the line beginning with "exp balk", the fields are as follows: - - o "bt" is the number of times that the system balked from - boosting because there were no blocked tasks to boost. - - o "nos" is the number of times that the system balked from - boosting for inexplicable ("not otherwise specified") - reasons. diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 10df0b82f459..0f0fb7c432c2 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -842,9 +842,7 @@ SRCU: Critical sections Grace period Barrier srcu_read_lock synchronize_srcu srcu_barrier srcu_read_unlock call_srcu - srcu_read_lock_raw synchronize_srcu_expedited - srcu_read_unlock_raw - srcu_dereference + srcu_dereference synchronize_srcu_expedited SRCU: Initialization/cleanup init_srcu_struct @@ -865,38 +863,32 @@ list can be helpful: a. Will readers need to block? If so, you need SRCU. -b. Is it necessary to start a read-side critical section in a - hardirq handler or exception handler, and then to complete - this read-side critical section in the task that was - interrupted? If so, you need SRCU's srcu_read_lock_raw() and - srcu_read_unlock_raw() primitives. - -c. What about the -rt patchset? If readers would need to block +b. What about the -rt patchset? If readers would need to block in an non-rt kernel, you need SRCU. If readers would block in a -rt kernel, but not in a non-rt kernel, SRCU is not necessary. -d. Do you need to treat NMI handlers, hardirq handlers, +c. Do you need to treat NMI handlers, hardirq handlers, and code segments with preemption disabled (whether via preempt_disable(), local_irq_save(), local_bh_disable(), or some other mechanism) as if they were explicit RCU readers? If so, RCU-sched is the only choice that will work for you. -e. Do you need RCU grace periods to complete even in the face +d. Do you need RCU grace periods to complete even in the face of softirq monopolization of one or more of the CPUs? For example, is your code subject to network-based denial-of-service attacks? If so, you need RCU-bh. -f. Is your workload too update-intensive for normal use of +e. Is your workload too update-intensive for normal use of RCU, but inappropriate for other synchronization mechanisms? If so, consider SLAB_DESTROY_BY_RCU. But please be careful! -g. Do you need read-side critical sections that are respected +f. Do you need read-side critical sections that are respected even though they are in the middle of the idle loop, during user-mode execution, or on an offlined CPU? If so, SRCU is the only choice that will work for you. -h. Otherwise, use RCU. +g. Otherwise, use RCU. Of course, this all assumes that you have determined that RCU is in fact the right tool for your job. diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist index dc0e33210d7e..2b7e32dfe00d 100644 --- a/Documentation/SubmitChecklist +++ b/Documentation/SubmitChecklist @@ -105,5 +105,5 @@ kernel patches. same time, just various/random combinations of them]: CONFIG_SMP, CONFIG_SYSFS, CONFIG_PROC_FS, CONFIG_INPUT, CONFIG_PCI, - CONFIG_BLOCK, CONFIG_PM, CONFIG_HOTPLUG, CONFIG_MAGIC_SYSRQ, + CONFIG_BLOCK, CONFIG_PM, CONFIG_MAGIC_SYSRQ, CONFIG_NET, CONFIG_INET=n (but latter with CONFIG_NET=y) diff --git a/Documentation/acpi/apei/einj.txt b/Documentation/acpi/apei/einj.txt index e20b6daaced4..a58b63da1a36 100644 --- a/Documentation/acpi/apei/einj.txt +++ b/Documentation/acpi/apei/einj.txt @@ -47,11 +47,16 @@ directory apei/einj. The following files are provided. - param1 This file is used to set the first error parameter value. Effect of - parameter depends on error_type specified. + parameter depends on error_type specified. For example, if error + type is memory related type, the param1 should be a valid physical + memory address. - param2 This file is used to set the second error parameter value. Effect of - parameter depends on error_type specified. + parameter depends on error_type specified. For example, if error + type is memory related type, the param2 should be a physical memory + address mask. Linux requires page or narrower granularity, say, + 0xfffffffffffff000. - notrigger The EINJ mechanism is a two step process. First inject the error, then diff --git a/Documentation/arm/sti/overview.txt b/Documentation/arm/sti/overview.txt new file mode 100644 index 000000000000..1a4e93d6027f --- /dev/null +++ b/Documentation/arm/sti/overview.txt @@ -0,0 +1,33 @@ + STi ARM Linux Overview + ========================== + +Introduction +------------ + + The ST Microelectronics Multimedia and Application Processors range of + CortexA9 System-on-Chip are supported by the 'STi' platform of + ARM Linux. Currently STiH415, STiH416 SOCs are supported with both + B2000 and B2020 Reference boards. + + + configuration + ------------- + + A generic configuration is provided for both STiH415/416, and can be used as the + default by + make stih41x_defconfig + + Layout + ------ + All the files for multiple machine families (STiH415, STiH416, and STiG125) + are located in the platform code contained in arch/arm/mach-sti + + There is a generic board board-dt.c in the mach folder which support + Flattened Device Tree, which means, It works with any compatible board with + Device Trees. + + + Document Author + --------------- + + Srinivas Kandagatla <srinivas.kandagatla@st.com>, (c) 2013 ST Microelectronics diff --git a/Documentation/arm/sti/stih415-overview.txt b/Documentation/arm/sti/stih415-overview.txt new file mode 100644 index 000000000000..1383e33f265d --- /dev/null +++ b/Documentation/arm/sti/stih415-overview.txt @@ -0,0 +1,12 @@ + STiH415 Overview + ================ + +Introduction +------------ + + The STiH415 is the next generation of HD, AVC set-top box processors + for satellite, cable, terrestrial and IP-STB markets. + + Features + - ARM Cortex-A9 1.0 GHz, dual-core CPU + - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2 diff --git a/Documentation/arm/sti/stih416-overview.txt b/Documentation/arm/sti/stih416-overview.txt new file mode 100644 index 000000000000..558444c201c6 --- /dev/null +++ b/Documentation/arm/sti/stih416-overview.txt @@ -0,0 +1,12 @@ + STiH416 Overview + ================ + +Introduction +------------ + + The STiH416 is the next generation of HD, AVC set-top box processors + for satellite, cable, terrestrial and IP-STB markets. + + Features + - ARM Cortex-A9 1.2 GHz dual core CPU + - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2 diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README index 87a1e8fb6242..e3f93fb9224e 100644 --- a/Documentation/arm/sunxi/README +++ b/Documentation/arm/sunxi/README @@ -3,17 +3,26 @@ ARM Allwinner SoCs This document lists all the ARM Allwinner SoCs that are currently supported in mainline by the Linux kernel. This document will also -provide links to documentation and or datasheet for these SoCs. +provide links to documentation and/or datasheet for these SoCs. SunXi family ------------ + Linux kernel mach directory: arch/arm/mach-sunxi Flavors: - Allwinner A10 (sun4i) - Datasheet : http://dl.linux-sunxi.org/A10/A10%20Datasheet%20-%20v1.21%20%282012-04-06%29.pdf + * ARM Cortex-A8 based SoCs + - Allwinner A10 (sun4i) + + Datasheet + http://dl.linux-sunxi.org/A10/A10%20Datasheet%20-%20v1.21%20%282012-04-06%29.pdf + + User Manual + http://dl.linux-sunxi.org/A10/A10%20User%20Manual%20-%20v1.20%20%282012-04-09%2c%20DECRYPTED%29.pdf - Allwinner A13 (sun5i) - Datasheet : http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf + - Allwinner A10s (sun5i) + + Datasheet + http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf - Core: Cortex A8 - Linux kernel mach directory: arch/arm/mach-sunxi
\ No newline at end of file + - Allwinner A13 (sun5i) + + 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 diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index 12e01d432bfe..7740038d82bc 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroups/cpusets.txt @@ -373,7 +373,7 @@ can become very uneven. 1.7 What is sched_load_balance ? -------------------------------- -The kernel scheduler (kernel/sched.c) automatically load balances +The kernel scheduler (kernel/sched/core.c) automatically load balances tasks. If one CPU is underutilized, kernel code running on that CPU will look for tasks on other more overloaded CPUs and move those tasks to itself, within the constraints of such placement mechanisms diff --git a/Documentation/console/console.txt b/Documentation/console/console.txt index 926cf1b5e63e..f93810d599ad 100644 --- a/Documentation/console/console.txt +++ b/Documentation/console/console.txt @@ -12,20 +12,20 @@ The second type has to be explicitly loaded and unloaded. This will be called any time with each driver sharing the console with other drivers including the system driver. However, modular drivers cannot take over the console that is currently occupied by another modular driver. (Exception: Drivers that -call take_over_console() will succeed in the takeover regardless of the type +call do_take_over_console() will succeed in the takeover regardless of the type of driver occupying the consoles.) They can only take over the console that is occupied by the system driver. In the same token, if the modular driver is released by the console, the system driver will take over. Modular drivers, from the programmer's point of view, has to call: - take_over_console() - load and bind driver to console layer - give_up_console() - unbind and unload driver + do_take_over_console() - load and bind driver to console layer + give_up_console() - unload driver, it will only work if driver is fully unbond In newer kernels, the following are also available: - register_con_driver() - unregister_con_driver() + do_register_con_driver() + do_unregister_con_driver() If sysfs is enabled, the contents of /sys/class/vtconsole can be examined. This shows the console backends currently registered by the @@ -94,12 +94,12 @@ for more details). Notes for developers: ===================== -take_over_console() is now broken up into: +do_take_over_console() is now broken up into: - register_con_driver() - bind_con_driver() - private function + do_register_con_driver() + do_bind_con_driver() - private function -give_up_console() is a wrapper to unregister_con_driver(), and a driver must +give_up_console() is a wrapper to do_unregister_con_driver(), and a driver must be fully unbound for this call to succeed. con_is_bound() will check if the driver is bound or not. @@ -109,10 +109,10 @@ Guidelines for console driver writers: In order for binding to and unbinding from the console to properly work, console drivers must follow these guidelines: -1. All drivers, except system drivers, must call either register_con_driver() - or take_over_console(). register_con_driver() will just add the driver to +1. All drivers, except system drivers, must call either do_register_con_driver() + or do_take_over_console(). do_register_con_driver() will just add the driver to the console's internal list. It won't take over the - console. take_over_console(), as it name implies, will also take over (or + console. do_take_over_console(), as it name implies, will also take over (or bind to) the console. 2. All resources allocated during con->con_init() must be released in @@ -128,10 +128,10 @@ console drivers must follow these guidelines: rebind the driver to the console arrives. 4. Upon exit of the driver, ensure that the driver is totally unbound. If the - condition is satisfied, then the driver must call unregister_con_driver() + condition is satisfied, then the driver must call do_unregister_con_driver() or give_up_console(). -5. unregister_con_driver() can also be called on conditions which make it +5. do_unregister_con_driver() can also be called on conditions which make it impossible for the driver to service console requests. This can happen with the framebuffer console that suddenly lost all of its drivers. diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index 9f401350f502..0efd1b905b9d 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -128,7 +128,7 @@ A: When doing make defconfig, Enable CPU hotplug support "Processor type and Features" -> Support for Hotpluggable CPUs -Make sure that you have CONFIG_HOTPLUG, and CONFIG_SMP turned on as well. +Make sure that you have CONFIG_SMP turned on as well. You would need to enable CONFIG_HOTPLUG_CPU for SMP suspend/resume support as well. diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt new file mode 100644 index 000000000000..92d36e2aa877 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/cci.txt @@ -0,0 +1,172 @@ +======================================================= +ARM CCI cache coherent interconnect binding description +======================================================= + +ARM multi-cluster systems maintain intra-cluster coherency through a +cache coherent interconnect (CCI) that is capable of monitoring bus +transactions and manage coherency, TLB invalidations and memory barriers. + +It allows snooping and distributed virtual memory message broadcast across +clusters, through memory mapped interface, with a global control register +space and multiple sets of interface control registers, one per slave +interface. + +Bindings for the CCI node follow the ePAPR standard, available from: + +www.power.org/documentation/epapr-version-1-1/ + +with the addition of the bindings described in this document which are +specific to ARM. + +* CCI interconnect node + + Description: Describes a CCI cache coherent Interconnect component + + Node name must be "cci". + Node's parent must be the root node /, and the address space visible + through the CCI interconnect is the same as the one seen from the + root node (ie from CPUs perspective as per DT standard). + Every CCI node has to define the following properties: + + - compatible + Usage: required + Value type: <string> + Definition: must be set to + "arm,cci-400" + + - reg + Usage: required + Value type: <prop-encoded-array> + Definition: A standard property. Specifies base physical + address of CCI control registers common to all + interfaces. + + - ranges: + Usage: required + Value type: <prop-encoded-array> + Definition: A standard property. Follow rules in the ePAPR for + hierarchical bus addressing. CCI interfaces + addresses refer to the parent node addressing + scheme to declare their register bases. + + CCI interconnect node can define the following child nodes: + + - CCI control interface nodes + + Node name must be "slave-if". + Parent node must be CCI interconnect node. + + A CCI control interface node must contain the following + properties: + + - compatible + Usage: required + Value type: <string> + Definition: must be set to + "arm,cci-400-ctrl-if" + + - interface-type: + Usage: required + Value type: <string> + Definition: must be set to one of {"ace", "ace-lite"} + depending on the interface type the node + represents. + + - reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the base address and size of the + corresponding interface programming + registers. + +* CCI interconnect bus masters + + Description: masters in the device tree connected to a CCI port + (inclusive of CPUs and their cpu nodes). + + A CCI interconnect bus master node must contain the following + properties: + + - cci-control-port: + Usage: required + Value type: <phandle> + Definition: a phandle containing the CCI control interface node + the master is connected to. + +Example: + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + cci-control-port = <&cci_control1>; + reg = <0x0>; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "arm,cortex-a15"; + cci-control-port = <&cci_control1>; + reg = <0x1>; + }; + + CPU2: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + cci-control-port = <&cci_control2>; + reg = <0x100>; + }; + + CPU3: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a7"; + cci-control-port = <&cci_control2>; + reg = <0x101>; + }; + + }; + + dma0: dma@3000000 { + compatible = "arm,pl330", "arm,primecell"; + cci-control-port = <&cci_control0>; + reg = <0x0 0x3000000 0x0 0x1000>; + interrupts = <10>; + #dma-cells = <1>; + #dma-channels = <8>; + #dma-requests = <32>; + }; + + cci@2c090000 { + compatible = "arm,cci-400"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x0 0x2c090000 0 0x1000>; + ranges = <0x0 0x0 0x2c090000 0x6000>; + + cci_control0: slave-if@1000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace-lite"; + reg = <0x1000 0x1000>; + }; + + cci_control1: slave-if@4000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace"; + reg = <0x4000 0x1000>; + }; + + cci_control2: slave-if@5000 { + compatible = "arm,cci-400-ctrl-if"; + interface-type = "ace"; + reg = <0x5000 0x1000>; + }; + }; + +This CCI node corresponds to a CCI component whose control registers sits +at address 0x000000002c090000. +CCI slave interface @0x000000002c091000 is connected to dma controller dma0. +CCI slave interface @0x000000002c094000 is connected to CPUs {CPU0, CPU1}; +CCI slave interface @0x000000002c095000 is connected to CPUs {CPU2, CPU3}; diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt new file mode 100644 index 000000000000..63c0e6ae5cf7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt @@ -0,0 +1,10 @@ +TI Keystone Platforms Device Tree Bindings +----------------------------------------------- + +Boards with Keystone2 based devices (TCI66xxK2H) SOC shall have the +following properties. + +Required properties: + - compatible: All TI specific devices present in Keystone SOC should be in + the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550 + type UART should use the specified compatible for those devices. diff --git a/Documentation/devicetree/bindings/arm/nspire.txt b/Documentation/devicetree/bindings/arm/nspire.txt new file mode 100644 index 000000000000..4d08518bd176 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/nspire.txt @@ -0,0 +1,14 @@ +TI-NSPIRE calculators + +Required properties: +- compatible: Compatible property value should contain "ti,nspire". + CX models should have "ti,nspire-cx" + Touchpad models should have "ti,nspire-tp" + Clickpad models should have "ti,nspire-clp" + +Example: + +/ { + model = "TI-NSPIRE CX"; + compatible = "ti,nspire-cx"; + ... diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index f8288ea1b530..6d498c758b45 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -56,3 +56,6 @@ Boards: - OMAP5 EVM : Evaluation Module compatible = "ti,omap5-evm", "ti,omap5" + +- AM43x EPOS EVM + compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43" diff --git a/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt b/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt new file mode 100644 index 000000000000..3b8fbf3c00c5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt @@ -0,0 +1,19 @@ +ARM Dual Cluster System Configuration Block +------------------------------------------- + +The Dual Cluster System Configuration Block (DCSCB) provides basic +functionality for controlling clocks, resets and configuration pins in +the Dual Cluster System implemented by the Real-Time System Model (RTSM). + +Required properties: + +- compatible : should be "arm,rtsm,dcscb" + +- reg : physical base address and the size of the registers window + +Example: + + dcscb@60000000 { + compatible = "arm,rtsm,dcscb"; + reg = <0x60000000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/ste-nomadik.txt b/Documentation/devicetree/bindings/arm/ste-nomadik.txt index 19bca04b81c9..6256ec31666d 100644 --- a/Documentation/devicetree/bindings/arm/ste-nomadik.txt +++ b/Documentation/devicetree/bindings/arm/ste-nomadik.txt @@ -3,6 +3,11 @@ ST-Ericsson Nomadik Device Tree Bindings For various board the "board" node may contain specific properties that pertain to this particular board, such as board-specific GPIOs. +Required root node property: src +- Nomadik System and reset controller used for basic chip control, clock + and reset line control. +- compatible: must be "stericsson,nomadik,src" + Boards with the Nomadik SoC include: S8815 "MiniKit" manufactured by Calao Systems: diff --git a/Documentation/devicetree/bindings/arm/ste-u300.txt b/Documentation/devicetree/bindings/arm/ste-u300.txt new file mode 100644 index 000000000000..69b5ab0b5f4b --- /dev/null +++ b/Documentation/devicetree/bindings/arm/ste-u300.txt @@ -0,0 +1,46 @@ +ST-Ericsson U300 Device Tree Bindings + +For various board the "board" node may contain specific properties +that pertain to this particular board, such as board-specific GPIOs +or board power regulator supplies. + +Required root node property: + +compatible="stericsson,u300"; + +Required node: syscon +This contains the system controller. +- compatible: must be "stericsson,u300-syscon". +- reg: the base address and size of the system controller. + +Boards with the U300 SoC include: + +S365 "Small Board U365": + +Required node: s365 +This contains the board-specific information. +- compatible: must be "stericsson,s365". +- vana15-supply: the regulator supplying the 1.5V to drive the + board. +- syscon: a pointer to the syscon node so we can acccess the + syscon registers to set the board as self-powered. + +Example: + +/ { + model = "ST-Ericsson U300"; + compatible = "stericsson,u300"; + #address-cells = <1>; + #size-cells = <1>; + + s365 { + compatible = "stericsson,s365"; + vana15-supply = <&ab3100_ldo_d_reg>; + syscon = <&syscon>; + }; + + syscon: syscon@c0011000 { + compatible = "stericsson,u300-syscon"; + reg = <0xc0011000 0x1000>; + }; +}; diff --git a/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt b/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt new file mode 100644 index 000000000000..c1d22b3ae134 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt @@ -0,0 +1,19 @@ +Atmel AT91RM9200 CompactFlash + +Required properties: +- compatible : "atmel,at91rm9200-cf". +- reg : should specify localbus address and size used. +- gpios : specifies the gpio pins to control the CF device. Detect + and reset gpio's are mandatory while irq and vcc gpio's are + optional and may be set to 0 if not present. + +Example: +compact-flash@50000000 { + compatible = "atmel,at91rm9200-cf"; + reg = <0x50000000 0x30000000>; + gpios = <&pioC 13 0 /* irq */ + &pioC 15 0 /* detect */ + 0 /* vcc */ + &pioC 5 0 /* reset */ + >; +}; diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt new file mode 100644 index 000000000000..cedc2a9c4785 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/imx-weim.txt @@ -0,0 +1,49 @@ +Device tree bindings for i.MX Wireless External Interface Module (WEIM) + +The term "wireless" does not imply that the WEIM is literally an interface +without wires. It simply means that this module was originally designed for +wireless and mobile applications that use low-power technology. + +The actual devices are instantiated from the child nodes of a WEIM node. + +Required properties: + + - compatible: Should be set to "fsl,imx6q-weim" + - reg: A resource specifier for the register space + (see the example below) + - clocks: the clock, see the example below. + - #address-cells: Must be set to 2 to allow memory address translation + - #size-cells: Must be set to 1 to allow CS address passing + - ranges: Must be set up to reflect the memory layout with four + integer values for each chip-select line in use: + + <cs-number> 0 <physical address of mapping> <size> + +Timing property for child nodes. It is mandatory, not optional. + + - fsl,weim-cs-timing: The timing array, contains 6 timing values for the + child node. We can get the CS index from the child + node's "reg" property. This property contains the values + for the registers EIM_CSnGCR1, EIM_CSnGCR2, EIM_CSnRCR1, + EIM_CSnRCR2, EIM_CSnWCR1, EIM_CSnWCR2 in this order. + +Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM: + + weim: weim@021b8000 { + compatible = "fsl,imx6q-weim"; + reg = <0x021b8000 0x4000>; + clocks = <&clks 196>; + #address-cells = <2>; + #size-cells = <1>; + ranges = <0 0 0x08000000 0x08000000>; + + nor@0,0 { + compatible = "cfi-flash"; + reg = <0 0 0x02000000>; + #address-cells = <1>; + #size-cells = <1>; + bank-width = <2>; + fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000 + 0x0000c000 0x1404a38e 0x00000000>; + }; + }; diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt index 4b87ea1194e3..704be9306c9f 100644 --- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt @@ -95,7 +95,6 @@ GPMC chip-select settings properties for child nodes. All are optional. - gpmc,burst-wrap Enables wrap bursting - gpmc,burst-read Enables read page/burst mode - gpmc,burst-write Enables write page/burst mode -- gpmc,device-nand Device is NAND - gpmc,device-width Total width of device(s) connected to a GPMC chip-select in bytes. The GPMC supports 8-bit and 16-bit devices and so this property must be diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt index bd0c8416a5c8..0045433eae1f 100644 --- a/Documentation/devicetree/bindings/clock/altr_socfpga.txt +++ b/Documentation/devicetree/bindings/clock/altr_socfpga.txt @@ -9,6 +9,9 @@ Required properties: "altr,socfpga-pll-clock" - for a PLL clock "altr,socfpga-perip-clock" - The peripheral clock divided from the PLL clock. + "altr,socfpga-gate-clk" - Clocks that directly feed peripherals and + can get gated. + - reg : shall be the control register offset from CLOCK_MANAGER's base for the clock. - clocks : shall be the input parent clock phandle for the clock. This is either an oscillator or a pll output. @@ -16,3 +19,7 @@ Required properties: Optional properties: - fixed-divider : If clocks have a fixed divider value, use this property. +- clk-gate : For "socfpga-gate-clk", clk-gate contains the gating register + and the bit index. +- div-reg : For "socfpga-gate-clk", div-reg contains the divider register, bit shift, + and width. diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt new file mode 100644 index 000000000000..a1201802f90d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt @@ -0,0 +1,64 @@ +* Samsung Audio Subsystem Clock Controller + +The Samsung Audio Subsystem clock controller generates and supplies clocks +to Audio Subsystem block available in the S5PV210 and Exynos SoCs. The clock +binding described here is applicable to all SoC's in Exynos family. + +Required Properties: + +- compatible: should be one of the following: + - "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs. + - "samsung,exynos5250-audss-clock" - controller compatible with all Exynos5 SoCs. + +- reg: physical base address and length of the controller's register set. + +- #clock-cells: should be 1. + +The following is the list of clocks generated by the controller. Each clock is +assigned an identifier and client nodes use this identifier to specify the +clock which they consume. Some of the clocks are available only on a particular +Exynos4 SoC and this is specified where applicable. + +Provided clocks: + +Clock ID SoC (if specific) +----------------------------------------------- + +mout_audss 0 +mout_i2s 1 +dout_srp 2 +dout_aud_bus 3 +dout_i2s 4 +srp_clk 5 +i2s_bus 6 +sclk_i2s 7 +pcm_bus 8 +sclk_pcm 9 + +Example 1: An example of a clock controller node is listed below. + +clock_audss: audss-clock-controller@3810000 { + compatible = "samsung,exynos5250-audss-clock"; + reg = <0x03810000 0x0C>; + #clock-cells = <1>; +}; + +Example 2: I2S controller node that consumes the clock generated by the clock + controller. Refer to the standard clock bindings for information + about 'clocks' and 'clock-names' property. + +i2s0: i2s@03830000 { + compatible = "samsung,i2s-v5"; + reg = <0x03830000 0x100>; + dmas = <&pdma0 10 + &pdma0 9 + &pdma0 8>; + dma-names = "tx", "rx", "tx-sec"; + clocks = <&clock_audss EXYNOS_I2S_BUS>, + <&clock_audss EXYNOS_I2S_BUS>, + <&clock_audss EXYNOS_SCLK_I2S>, + <&clock_audss EXYNOS_MOUT_AUDSS>, + <&clock_audss EXYNOS_MOUT_I2S>; + clock-names = "iis", "i2s_opclk0", "i2s_opclk1", + "mout_audss", "mout_i2s"; +}; diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt index ea5e26f16aec..14d5c2af26f4 100644 --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt @@ -102,6 +102,7 @@ Exynos4 SoC and this is specified where applicable. sclk_spi0_isp 174 Exynos4x12 sclk_spi1_isp 175 Exynos4x12 sclk_uart_isp 176 Exynos4x12 + sclk_fimg2d 177 [Peripheral Clock Gates] @@ -129,7 +130,7 @@ Exynos4 SoC and this is specified where applicable. smmu_mfcl 274 smmu_mfcr 275 g3d 276 - g2d 277 Exynos4210 + g2d 277 rotator 278 Exynos4210 mdma 279 Exynos4210 smmu_g2d 280 Exynos4210 diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt new file mode 100644 index 000000000000..9bcc4b1bff51 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt @@ -0,0 +1,201 @@ +* Samsung Exynos5420 Clock Controller + +The Exynos5420 clock controller generates and supplies clock to various +controllers within the Exynos5420 SoC. + +Required Properties: + +- comptible: should be one of the following. + - "samsung,exynos5420-clock" - controller compatible with Exynos5420 SoC. + +- reg: physical base address of the controller and length of memory mapped + region. + +- #clock-cells: should be 1. + +The following is the list of clocks generated by the controller. Each clock is +assigned an identifier and client nodes use this identifier to specify the +clock which they consume. + + + [Core Clocks] + + Clock ID + ---------------------------- + + fin_pll 1 + + [Clock Gate for Special Clocks] + + Clock ID + ---------------------------- + sclk_uart0 128 + sclk_uart1 129 + sclk_uart2 130 + sclk_uart3 131 + sclk_mmc0 132 + sclk_mmc1 133 + sclk_mmc2 134 + sclk_spi0 135 + sclk_spi1 136 + sclk_spi2 137 + sclk_i2s1 138 + sclk_i2s2 139 + sclk_pcm1 140 + sclk_pcm2 141 + sclk_spdif 142 + sclk_hdmi 143 + sclk_pixel 144 + sclk_dp1 145 + sclk_mipi1 146 + sclk_fimd1 147 + sclk_maudio0 148 + sclk_maupcm0 149 + sclk_usbd300 150 + sclk_usbd301 151 + sclk_usbphy300 152 + sclk_usbphy301 153 + sclk_unipro 154 + sclk_pwm 155 + sclk_gscl_wa 156 + sclk_gscl_wb 157 + + [Peripheral Clock Gates] + + Clock ID + ---------------------------- + + aclk66_peric 256 + uart0 257 + uart1 258 + uart2 259 + uart3 260 + i2c0 261 + i2c1 262 + i2c2 263 + i2c3 264 + i2c4 265 + i2c5 266 + i2c6 267 + i2c7 268 + i2c_hdmi 269 + tsadc 270 + spi0 271 + spi1 272 + spi2 273 + keyif 274 + i2s1 275 + i2s2 276 + pcm1 277 + pcm2 278 + pwm 279 + spdif 280 + i2c8 281 + i2c9 282 + i2c10 283 + aclk66_psgen 300 + chipid 301 + sysreg 302 + tzpc0 303 + tzpc1 304 + tzpc2 305 + tzpc3 306 + tzpc4 307 + tzpc5 308 + tzpc6 309 + tzpc7 310 + tzpc8 311 + tzpc9 312 + hdmi_cec 313 + seckey 314 + mct 315 + wdt 316 + rtc 317 + tmu 318 + tmu_gpu 319 + pclk66_gpio 330 + aclk200_fsys2 350 + mmc0 351 + mmc1 352 + mmc2 353 + sromc 354 + ufs 355 + aclk200_fsys 360 + tsi 361 + pdma0 362 + pdma1 363 + rtic 364 + usbh20 365 + usbd300 366 + usbd301 377 + aclk400_mscl 380 + mscl0 381 + mscl1 382 + mscl2 383 + smmu_mscl0 384 + smmu_mscl1 385 + smmu_mscl2 386 + aclk333 400 + mfc 401 + smmu_mfcl 402 + smmu_mfcr 403 + aclk200_disp1 410 + dsim1 411 + dp1 412 + hdmi 413 + aclk300_disp1 420 + fimd1 421 + smmu_fimd1 422 + aclk166 430 + mixer 431 + aclk266 440 + rotator 441 + mdma1 442 + smmu_rotator 443 + smmu_mdma1 444 + aclk300_jpeg 450 + jpeg 451 + jpeg2 452 + smmu_jpeg 453 + aclk300_gscl 460 + smmu_gscl0 461 + smmu_gscl1 462 + gscl_wa 463 + gscl_wb 464 + gscl0 465 + gscl1 466 + clk_3aa 467 + aclk266_g2d 470 + sss 471 + slim_sss 472 + mdma0 473 + aclk333_g2d 480 + g2d 481 + aclk333_432_gscl 490 + smmu_3aa 491 + smmu_fimcl0 492 + smmu_fimcl1 493 + smmu_fimcl3 494 + fimc_lite3 495 + aclk_g3d 500 + g3d 501 + +Example 1: An example of a clock controller node is listed below. + + clock: clock-controller@0x10010000 { + compatible = "samsung,exynos5420-clock"; + reg = <0x10010000 0x30000>; + #clock-cells = <1>; + }; + +Example 2: UART controller node that consumes the clock generated by the clock + controller. Refer to the standard clock bindings for information + about 'clocks' and 'clock-names' property. + + serial@13820000 { + compatible = "samsung,exynos4210-uart"; + reg = <0x13820000 0x100>; + interrupts = <0 54 0>; + clocks = <&clock 259>, <&clock 130>; + clock-names = "uart", "clk_uart_baud0"; + }; diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt index d71b4b2c077d..f46f5625d8ad 100644 --- a/Documentation/devicetree/bindings/clock/imx5-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt @@ -184,6 +184,19 @@ clocks and IDs. cko2 170 srtc_gate 171 pata_gate 172 + sata_gate 173 + spdif_xtal_sel 174 + spdif0_sel 175 + spdif1_sel 176 + spdif0_pred 177 + spdif0_podf 178 + spdif1_pred 179 + spdif1_podf 180 + spdif0_com_sel 181 + spdif1_com_sel 182 + spdif0_gate 183 + spdif1_gate 184 + spdif_ipg_gate 185 Examples (for mx53): diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index 6deb6fd1c7cd..a0e104f0527e 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt @@ -208,6 +208,7 @@ clocks and IDs. pll4_post_div 193 pll5_post_div 194 pll5_video_div 195 + eim_slow 196 Examples: diff --git a/Documentation/devicetree/bindings/clock/imx6sl-clock.txt b/Documentation/devicetree/bindings/clock/imx6sl-clock.txt new file mode 100644 index 000000000000..15e40bdf147d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx6sl-clock.txt @@ -0,0 +1,10 @@ +* Clock bindings for Freescale i.MX6 SoloLite + +Required properties: +- compatible: Should be "fsl,imx6sl-ccm" +- reg: Address and length of the register set +- #clock-cells: Should be <1> + +The clock consumer should specify the desired clock by having the clock +ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sl-clock.h +for the full list of i.MX6 SoloLite clock IDs. diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt index d6cb083b90a2..0c80c2677104 100644 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt @@ -12,253 +12,9 @@ Required properties : - clocks : Should contain phandle and clock specifiers for two clocks: the 32 KHz "32k_in", and the board-specific oscillator "osc". - #clock-cells : Should be 1. - In clock consumers, this cell represents the clock ID exposed by the CAR. - - The first 160 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB - registers. These IDs often match those in the CAR's RST_DEVICES registers, - but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In - this case, those clocks are assigned IDs above 160 in order to highlight - this issue. Implementations that interpret these clock IDs as bit values - within the CLK_OUT_ENB or RST_DEVICES registers should be careful to - explicitly handle these special cases. - - The balance of the clocks controlled by the CAR are assigned IDs of 160 and - above. - - 0 unassigned - 1 unassigned - 2 unassigned - 3 unassigned - 4 rtc - 5 timer - 6 uarta - 7 unassigned (register bit affects uartb and vfir) - 8 unassigned - 9 sdmmc2 - 10 unassigned (register bit affects spdif_in and spdif_out) - 11 i2s1 - 12 i2c1 - 13 ndflash - 14 sdmmc1 - 15 sdmmc4 - 16 unassigned - 17 pwm - 18 i2s2 - 19 epp - 20 unassigned (register bit affects vi and vi_sensor) - 21 2d - 22 usbd - 23 isp - 24 3d - 25 unassigned - 26 disp2 - 27 disp1 - 28 host1x - 29 vcp - 30 i2s0 - 31 unassigned - - 32 unassigned - 33 unassigned - 34 apbdma - 35 unassigned - 36 kbc - 37 unassigned - 38 unassigned - 39 unassigned (register bit affects fuse and fuse_burn) - 40 kfuse - 41 sbc1 - 42 nor - 43 unassigned - 44 sbc2 - 45 unassigned - 46 sbc3 - 47 i2c5 - 48 dsia - 49 unassigned - 50 mipi - 51 hdmi - 52 csi - 53 unassigned - 54 i2c2 - 55 uartc - 56 mipi-cal - 57 emc - 58 usb2 - 59 usb3 - 60 msenc - 61 vde - 62 bsea - 63 bsev - - 64 unassigned - 65 uartd - 66 unassigned - 67 i2c3 - 68 sbc4 - 69 sdmmc3 - 70 unassigned - 71 owr - 72 afi - 73 csite - 74 unassigned - 75 unassigned - 76 la - 77 trace - 78 soc_therm - 79 dtv - 80 ndspeed - 81 i2cslow - 82 dsib - 83 tsec - 84 unassigned - 85 unassigned - 86 unassigned - 87 unassigned - 88 unassigned - 89 xusb_host - 90 unassigned - 91 msenc - 92 csus - 93 unassigned - 94 unassigned - 95 unassigned (bit affects xusb_dev and xusb_dev_src) - - 96 unassigned - 97 unassigned - 98 unassigned - 99 mselect - 100 tsensor - 101 i2s3 - 102 i2s4 - 103 i2c4 - 104 sbc5 - 105 sbc6 - 106 d_audio - 107 apbif - 108 dam0 - 109 dam1 - 110 dam2 - 111 hda2codec_2x - 112 unassigned - 113 audio0_2x - 114 audio1_2x - 115 audio2_2x - 116 audio3_2x - 117 audio4_2x - 118 spdif_2x - 119 actmon - 120 extern1 - 121 extern2 - 122 extern3 - 123 unassigned - 124 unassigned - 125 hda - 126 unassigned - 127 se - - 128 hda2hdmi - 129 unassigned - 130 unassigned - 131 unassigned - 132 unassigned - 133 unassigned - 134 unassigned - 135 unassigned - 136 unassigned - 137 unassigned - 138 unassigned - 139 unassigned - 140 unassigned - 141 unassigned - 142 unassigned - 143 unassigned (bit affects xusb_falcon_src, xusb_fs_src, - xusb_host_src and xusb_ss_src) - 144 cilab - 145 cilcd - 146 cile - 147 dsialp - 148 dsiblp - 149 unassigned - 150 dds - 151 unassigned - 152 dp2 - 153 amx - 154 adx - 155 unassigned (bit affects dfll_ref and dfll_soc) - 156 xusb_ss - - 192 uartb - 193 vfir - 194 spdif_in - 195 spdif_out - 196 vi - 197 vi_sensor - 198 fuse - 199 fuse_burn - 200 clk_32k - 201 clk_m - 202 clk_m_div2 - 203 clk_m_div4 - 204 pll_ref - 205 pll_c - 206 pll_c_out1 - 207 pll_c2 - 208 pll_c3 - 209 pll_m - 210 pll_m_out1 - 211 pll_p - 212 pll_p_out1 - 213 pll_p_out2 - 214 pll_p_out3 - 215 pll_p_out4 - 216 pll_a - 217 pll_a_out0 - 218 pll_d - 219 pll_d_out0 - 220 pll_d2 - 221 pll_d2_out0 - 222 pll_u - 223 pll_u_480M - 224 pll_u_60M - 225 pll_u_48M - 226 pll_u_12M - 227 pll_x - 228 pll_x_out0 - 229 pll_re_vco - 230 pll_re_out - 231 pll_e_out0 - 232 spdif_in_sync - 233 i2s0_sync - 234 i2s1_sync - 235 i2s2_sync - 236 i2s3_sync - 237 i2s4_sync - 238 vimclk_sync - 239 audio0 - 240 audio1 - 241 audio2 - 242 audio3 - 243 audio4 - 244 spdif - 245 clk_out_1 - 246 clk_out_2 - 247 clk_out_3 - 248 blink - 252 xusb_host_src - 253 xusb_falcon_src - 254 xusb_fs_src - 255 xusb_ss_src - 256 xusb_dev_src - 257 xusb_dev - 258 xusb_hs_src - 259 sclk - 260 hclk - 261 pclk - 262 cclk_g - 263 cclk_lp - 264 dfll_ref - 265 dfll_soc + In clock consumers, this cell represents the clock ID exposed by the + CAR. The assignments may be found in header file + <dt-bindings/clock/tegra114-car.h>. Example SoC include file: @@ -270,7 +26,7 @@ Example SoC include file: }; usb@c5004000 { - clocks = <&tegra_car 58>; /* usb2 */ + clocks = <&tegra_car TEGRA114_CLK_USB2>; }; }; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt index e885680f6b45..fcfed5bf73fb 100644 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt @@ -12,155 +12,9 @@ Required properties : - clocks : Should contain phandle and clock specifiers for two clocks: the 32 KHz "32k_in", and the board-specific oscillator "osc". - #clock-cells : Should be 1. - In clock consumers, this cell represents the clock ID exposed by the CAR. - - The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB - registers. These IDs often match those in the CAR's RST_DEVICES registers, - but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In - this case, those clocks are assigned IDs above 95 in order to highlight - this issue. Implementations that interpret these clock IDs as bit values - within the CLK_OUT_ENB or RST_DEVICES registers should be careful to - explicitly handle these special cases. - - The balance of the clocks controlled by the CAR are assigned IDs of 96 and - above. - - 0 cpu - 1 unassigned - 2 unassigned - 3 ac97 - 4 rtc - 5 tmr - 6 uart1 - 7 unassigned (register bit affects uart2 and vfir) - 8 gpio - 9 sdmmc2 - 10 unassigned (register bit affects spdif_in and spdif_out) - 11 i2s1 - 12 i2c1 - 13 ndflash - 14 sdmmc1 - 15 sdmmc4 - 16 twc - 17 pwm - 18 i2s2 - 19 epp - 20 unassigned (register bit affects vi and vi_sensor) - 21 2d - 22 usbd - 23 isp - 24 3d - 25 ide - 26 disp2 - 27 disp1 - 28 host1x - 29 vcp - 30 unassigned - 31 cache2 - - 32 mem - 33 ahbdma - 34 apbdma - 35 unassigned - 36 kbc - 37 stat_mon - 38 pmc - 39 fuse - 40 kfuse - 41 sbc1 - 42 snor - 43 spi1 - 44 sbc2 - 45 xio - 46 sbc3 - 47 dvc - 48 dsi - 49 unassigned (register bit affects tvo and cve) - 50 mipi - 51 hdmi - 52 csi - 53 tvdac - 54 i2c2 - 55 uart3 - 56 unassigned - 57 emc - 58 usb2 - 59 usb3 - 60 mpe - 61 vde - 62 bsea - 63 bsev - - 64 speedo - 65 uart4 - 66 uart5 - 67 i2c3 - 68 sbc4 - 69 sdmmc3 - 70 pcie - 71 owr - 72 afi - 73 csite - 74 unassigned - 75 avpucq - 76 la - 77 unassigned - 78 unassigned - 79 unassigned - 80 unassigned - 81 unassigned - 82 unassigned - 83 unassigned - 84 irama - 85 iramb - 86 iramc - 87 iramd - 88 cram2 - 89 audio_2x a/k/a audio_2x_sync_clk - 90 clk_d - 91 unassigned - 92 sus - 93 cdev2 - 94 cdev1 - 95 unassigned - - 96 uart2 - 97 vfir - 98 spdif_in - 99 spdif_out - 100 vi - 101 vi_sensor - 102 tvo - 103 cve - 104 osc - 105 clk_32k a/k/a clk_s - 106 clk_m - 107 sclk - 108 cclk - 109 hclk - 110 pclk - 111 blink - 112 pll_a - 113 pll_a_out0 - 114 pll_c - 115 pll_c_out1 - 116 pll_d - 117 pll_d_out0 - 118 pll_e - 119 pll_m - 120 pll_m_out1 - 121 pll_p - 122 pll_p_out1 - 123 pll_p_out2 - 124 pll_p_out3 - 125 pll_p_out4 - 126 pll_s - 127 pll_u - 128 pll_x - 129 cop a/k/a avp - 130 audio a/k/a audio_sync_clk - 131 pll_ref - 132 twd + In clock consumers, this cell represents the clock ID exposed by the + CAR. The assignments may be found in header file + <dt-bindings/clock/tegra20-car.h>. Example SoC include file: @@ -172,7 +26,7 @@ Example SoC include file: }; usb@c5004000 { - clocks = <&tegra_car 58>; /* usb2 */ + clocks = <&tegra_car TEGRA20_CLK_USB2>; }; }; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt index f3da3be5fcad..0f714081e986 100644 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt @@ -12,212 +12,9 @@ Required properties : - clocks : Should contain phandle and clock specifiers for two clocks: the 32 KHz "32k_in", and the board-specific oscillator "osc". - #clock-cells : Should be 1. - In clock consumers, this cell represents the clock ID exposed by the CAR. - - The first 130 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB - registers. These IDs often match those in the CAR's RST_DEVICES registers, - but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In - this case, those clocks are assigned IDs above 160 in order to highlight - this issue. Implementations that interpret these clock IDs as bit values - within the CLK_OUT_ENB or RST_DEVICES registers should be careful to - explicitly handle these special cases. - - The balance of the clocks controlled by the CAR are assigned IDs of 160 and - above. - - 0 cpu - 1 unassigned - 2 unassigned - 3 unassigned - 4 rtc - 5 timer - 6 uarta - 7 unassigned (register bit affects uartb and vfir) - 8 gpio - 9 sdmmc2 - 10 unassigned (register bit affects spdif_in and spdif_out) - 11 i2s1 - 12 i2c1 - 13 ndflash - 14 sdmmc1 - 15 sdmmc4 - 16 unassigned - 17 pwm - 18 i2s2 - 19 epp - 20 unassigned (register bit affects vi and vi_sensor) - 21 2d - 22 usbd - 23 isp - 24 3d - 25 unassigned - 26 disp2 - 27 disp1 - 28 host1x - 29 vcp - 30 i2s0 - 31 cop_cache - - 32 mc - 33 ahbdma - 34 apbdma - 35 unassigned - 36 kbc - 37 statmon - 38 pmc - 39 unassigned (register bit affects fuse and fuse_burn) - 40 kfuse - 41 sbc1 - 42 nor - 43 unassigned - 44 sbc2 - 45 unassigned - 46 sbc3 - 47 i2c5 - 48 dsia - 49 unassigned (register bit affects cve and tvo) - 50 mipi - 51 hdmi - 52 csi - 53 tvdac - 54 i2c2 - 55 uartc - 56 unassigned - 57 emc - 58 usb2 - 59 usb3 - 60 mpe - 61 vde - 62 bsea - 63 bsev - - 64 speedo - 65 uartd - 66 uarte - 67 i2c3 - 68 sbc4 - 69 sdmmc3 - 70 pcie - 71 owr - 72 afi - 73 csite - 74 pciex - 75 avpucq - 76 la - 77 unassigned - 78 unassigned - 79 dtv - 80 ndspeed - 81 i2cslow - 82 dsib - 83 unassigned - 84 irama - 85 iramb - 86 iramc - 87 iramd - 88 cram2 - 89 unassigned - 90 audio_2x a/k/a audio_2x_sync_clk - 91 unassigned - 92 csus - 93 cdev2 - 94 cdev1 - 95 unassigned - - 96 cpu_g - 97 cpu_lp - 98 3d2 - 99 mselect - 100 tsensor - 101 i2s3 - 102 i2s4 - 103 i2c4 - 104 sbc5 - 105 sbc6 - 106 d_audio - 107 apbif - 108 dam0 - 109 dam1 - 110 dam2 - 111 hda2codec_2x - 112 atomics - 113 audio0_2x - 114 audio1_2x - 115 audio2_2x - 116 audio3_2x - 117 audio4_2x - 118 audio5_2x - 119 actmon - 120 extern1 - 121 extern2 - 122 extern3 - 123 sata_oob - 124 sata - 125 hda - 127 se - 128 hda2hdmi - 129 sata_cold - - 160 uartb - 161 vfir - 162 spdif_in - 163 spdif_out - 164 vi - 165 vi_sensor - 166 fuse - 167 fuse_burn - 168 cve - 169 tvo - - 170 clk_32k - 171 clk_m - 172 clk_m_div2 - 173 clk_m_div4 - 174 pll_ref - 175 pll_c - 176 pll_c_out1 - 177 pll_m - 178 pll_m_out1 - 179 pll_p - 180 pll_p_out1 - 181 pll_p_out2 - 182 pll_p_out3 - 183 pll_p_out4 - 184 pll_a - 185 pll_a_out0 - 186 pll_d - 187 pll_d_out0 - 188 pll_d2 - 189 pll_d2_out0 - 190 pll_u - 191 pll_x - 192 pll_x_out0 - 193 pll_e - 194 spdif_in_sync - 195 i2s0_sync - 196 i2s1_sync - 197 i2s2_sync - 198 i2s3_sync - 199 i2s4_sync - 200 vimclk - 201 audio0 - 202 audio1 - 203 audio2 - 204 audio3 - 205 audio4 - 206 audio5 - 207 clk_out_1 (extern1) - 208 clk_out_2 (extern2) - 209 clk_out_3 (extern3) - 210 sclk - 211 blink - 212 cclk_g - 213 cclk_lp - 214 twd - 215 cml0 - 216 cml1 - 217 hclk - 218 pclk + In clock consumers, this cell represents the clock ID exposed by the + CAR. The assignments may be found in header file + <dt-bindings/clock/tegra30-car.h>. Example SoC include file: @@ -229,7 +26,7 @@ Example SoC include file: }; usb@c5004000 { - clocks = <&tegra_car 58>; /* usb2 */ + clocks = <&tegra_car TEGRA30_CLK_USB2>; }; }; diff --git a/Documentation/devicetree/bindings/clock/st,nomadik.txt b/Documentation/devicetree/bindings/clock/st,nomadik.txt new file mode 100644 index 000000000000..7fc09773de46 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st,nomadik.txt @@ -0,0 +1,104 @@ +ST Microelectronics Nomadik SRC System Reset and Control + +This binding uses the common clock binding: +Documentation/devicetree/bindings/clock/clock-bindings.txt + +The Nomadik SRC controller is responsible of controlling chrystals, +PLLs and clock gates. + +Required properties for the SRC node: +- compatible: must be "stericsson,nomadik-src" +- reg: must contain the SRC register base and size + +Optional properties for the SRC node: +- disable-sxtalo: if present this will disable the SXTALO + i.e. the driver output for the slow 32kHz chrystal, if the + board has its own circuitry for providing this oscillator +- disable-mxtal: if present this will disable the MXTALO, + i.e. the driver output for the main (~19.2 MHz) chrystal, + if the board has its own circuitry for providing this + osciallator + + +PLL nodes: these nodes represent the two PLLs on the system, +which should both have the main chrystal, represented as a +fixed frequency clock, as parent. + +Required properties for the two PLL nodes: +- compatible: must be "st,nomadik-pll-clock" +- clock-cells: must be 0 +- clock-id: must be 1 or 2 for PLL1 and PLL2 respectively +- clocks: this clock will have main chrystal as parent + + +HCLK nodes: these represent the clock gates on individual +lines from the HCLK clock tree and the gate for individual +lines from the PCLK clock tree. + +Requires properties for the HCLK nodes: +- compatible: must be "st,nomadik-hclk-clock" +- clock-cells: must be 0 +- clock-id: must be the clock ID from 0 to 63 according to + this table: + + 0: HCLKDMA0 + 1: HCLKSMC + 2: HCLKSDRAM + 3: HCLKDMA1 + 4: HCLKCLCD + 5: PCLKIRDA + 6: PCLKSSP + 7: PCLKUART0 + 8: PCLKSDI + 9: PCLKI2C0 + 10: PCLKI2C1 + 11: PCLKUART1 + 12: PCLMSP0 + 13: HCLKUSB + 14: HCLKDIF + 15: HCLKSAA + 16: HCLKSVA + 17: PCLKHSI + 18: PCLKXTI + 19: PCLKUART2 + 20: PCLKMSP1 + 21: PCLKMSP2 + 22: PCLKOWM + 23: HCLKHPI + 24: PCLKSKE + 25: PCLKHSEM + 26: HCLK3D + 27: HCLKHASH + 28: HCLKCRYP + 29: PCLKMSHC + 30: HCLKUSBM + 31: HCLKRNG + (32, 33, 34, 35 RESERVED) + 36: CLDCLK + 37: IRDACLK + 38: SSPICLK + 39: UART0CLK + 40: SDICLK + 41: I2C0CLK + 42: I2C1CLK + 43: UART1CLK + 44: MSPCLK0 + 45: USBCLK + 46: DIFCLK + 47: IPI2CCLK + 48: IPBMCCLK + 49: HSICLKRX + 50: HSICLKTX + 51: UART2CLK + 52: MSPCLK1 + 53: MSPCLK2 + 54: OWMCLK + (55 RESERVED) + 56: SKECLK + (57 RESERVED) + 58: 3DCLK + 59: PCLKMSP3 + 60: MSPCLK3 + 61: MSHCCLK + 62: USBMCLK + 63: RNGCCLK diff --git a/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt b/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt new file mode 100644 index 000000000000..7cafcb98ead7 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt @@ -0,0 +1,80 @@ +Clock bindings for ST-Ericsson U300 System Controller Clocks + +Bindings for the gated system controller clocks: + +Required properties: +- compatible: must be "stericsson,u300-syscon-clk" +- #clock-cells: must be <0> +- clock-type: specifies the type of clock: + 0 = slow clock + 1 = fast clock + 2 = rest/remaining clock +- clock-id: specifies the clock in the type range + +Optional properties: +- clocks: parent clock(s) + +The available clocks per type are as follows: + +Type: ID: Clock: +------------------- +0 0 Slow peripheral bridge clock +0 1 UART0 clock +0 4 GPIO clock +0 6 RTC clock +0 7 Application timer clock +0 8 Access timer clock + +1 0 Fast peripheral bridge clock +1 1 I2C bus 0 clock +1 2 I2C bus 1 clock +1 5 MMC interface peripheral (silicon) clock +1 6 SPI clock + +2 3 CPU clock +2 4 DMA controller clock +2 5 External Memory Interface (EMIF) clock +2 6 NAND flask interface clock +2 8 XGAM graphics engine clock +2 9 Shared External Memory Interface (SEMI) clock +2 10 AHB Subsystem Bridge clock +2 12 Interrupt controller clock + +Example: + +gpio_clk: gpio_clk@13M { + #clock-cells = <0>; + compatible = "stericsson,u300-syscon-clk"; + clock-type = <0>; /* Slow */ + clock-id = <4>; + clocks = <&slow_clk>; +}; + +gpio: gpio@c0016000 { + compatible = "stericsson,gpio-coh901"; + (...) + clocks = <&gpio_clk>; +}; + + +Bindings for the MMC/SD card clock: + +Required properties: +- compatible: must be "stericsson,u300-syscon-mclk" +- #clock-cells: must be <0> + +Optional properties: +- clocks: parent clock(s) + +mmc_mclk: mmc_mclk { + #clock-cells = <0>; + compatible = "stericsson,u300-syscon-mclk"; + clocks = <&mmc_pclk>; +}; + +mmcsd: mmcsd@c0001000 { + compatible = "arm,pl18x", "arm,primecell"; + clocks = <&mmc_pclk>, <&mmc_mclk>; + clock-names = "apb_pclk", "mclk"; + (...) +}; diff --git a/Documentation/devicetree/bindings/clock/vf610-clock.txt b/Documentation/devicetree/bindings/clock/vf610-clock.txt new file mode 100644 index 000000000000..c80863d344ac --- /dev/null +++ b/Documentation/devicetree/bindings/clock/vf610-clock.txt @@ -0,0 +1,26 @@ +* Clock bindings for Freescale Vybrid VF610 SOC + +Required properties: +- compatible: Should be "fsl,vf610-ccm" +- reg: Address and length of the register set +- #clock-cells: Should be <1> + +The clock consumer should specify the desired clock by having the clock +ID in its "clocks" phandle cell. See include/dt-bindings/clock/vf610-clock.h +for the full list of VF610 clock IDs. + +Examples: + +clks: ccm@4006b000 { + compatible = "fsl,vf610-ccm"; + reg = <0x4006b000 0x1000>; + #clock-cells = <1>; +}; + +uart1: serial@40028000 { + compatible = "fsl,vf610-uart"; + reg = <0x40028000 0x1000>; + interrupts = <0 62 0x04>; + clocks = <&clks VF610_CLK_UART1>; + clock-names = "ipg"; +}; diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt index 23ae1db1bc13..d99af878f5d7 100644 --- a/Documentation/devicetree/bindings/clock/zynq-7000.txt +++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt @@ -6,50 +6,99 @@ The purpose of this document is to document their usage. See clock_bindings.txt for more information on the generic clock bindings. See Chapter 25 of Zynq TRM for more information about Zynq clocks. -== PLLs == - -Used to describe the ARM_PLL, DDR_PLL, and IO_PLL. +== Clock Controller == +The clock controller is a logical abstraction of Zynq's clock tree. It reads +required input clock frequencies from the devicetree and acts as clock provider +for all clock consumers of PS clocks. Required properties: -- #clock-cells : shall be 0 (only one clock is output from this node) -- compatible : "xlnx,zynq-pll" -- reg : pair of u32 values, which are the address offsets within the SLCR - of the relevant PLL_CTRL register and PLL_CFG register respectively -- clocks : phandle for parent clock. should be the phandle for ps_clk + - #clock-cells : Must be 1 + - compatible : "xlnx,ps7-clkc" + - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ + (usually 33 MHz oscillators are used for Zynq platforms) + - clock-output-names : List of strings used to name the clock outputs. Shall be + a list of the outputs given below. Optional properties: -- clock-output-names : name of the output clock - -Example: - armpll: armpll { - #clock-cells = <0>; - compatible = "xlnx,zynq-pll"; - clocks = <&ps_clk>; - reg = <0x100 0x110>; - clock-output-names = "armpll"; - }; - -== Peripheral clocks == + - clocks : as described in the clock bindings + - clock-names : as described in the clock bindings -Describes clock node for the SDIO, SMC, SPI, QSPI, and UART clocks. +Clock inputs: +The following strings are optional parameters to the 'clock-names' property in +order to provide an optional (E)MIO clock source. + - swdt_ext_clk + - gem0_emio_clk + - gem1_emio_clk + - mio_clk_XX # with XX = 00..53 +... -Required properties: -- #clock-cells : shall be 1 -- compatible : "xlnx,zynq-periph-clock" -- reg : a single u32 value, describing the offset within the SLCR where - the CLK_CTRL register is found for this peripheral -- clocks : phandle for parent clocks. should hold phandles for - the IO_PLL, ARM_PLL, and DDR_PLL in order -- clock-output-names : names of the output clock(s). For peripherals that have - two output clocks (for example, the UART), two clocks - should be listed. +Clock outputs: + 0: armpll + 1: ddrpll + 2: iopll + 3: cpu_6or4x + 4: cpu_3or2x + 5: cpu_2x + 6: cpu_1x + 7: ddr2x + 8: ddr3x + 9: dci + 10: lqspi + 11: smc + 12: pcap + 13: gem0 + 14: gem1 + 15: fclk0 + 16: fclk1 + 17: fclk2 + 18: fclk3 + 19: can0 + 20: can1 + 21: sdio0 + 22: sdio1 + 23: uart0 + 24: uart1 + 25: spi0 + 26: spi1 + 27: dma + 28: usb0_aper + 29: usb1_aper + 30: gem0_aper + 31: gem1_aper + 32: sdio0_aper + 33: sdio1_aper + 34: spi0_aper + 35: spi1_aper + 36: can0_aper + 37: can1_aper + 38: i2c0_aper + 39: i2c1_aper + 40: uart0_aper + 41: uart1_aper + 42: gpio_aper + 43: lqspi_aper + 44: smc_aper + 45: swdt + 46: dbg_trc + 47: dbg_apb Example: - uart_clk: uart_clk { + clkc: clkc { #clock-cells = <1>; - compatible = "xlnx,zynq-periph-clock"; - clocks = <&iopll &armpll &ddrpll>; - reg = <0x154>; - clock-output-names = "uart0_ref_clk", - "uart1_ref_clk"; + compatible = "xlnx,ps7-clkc"; + ps-clk-frequency = <33333333>; + clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x", + "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x", + "dci", "lqspi", "smc", "pcap", "gem0", "gem1", + "fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1", + "sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1", + "dma", "usb0_aper", "usb1_aper", "gem0_aper", + "gem1_aper", "sdio0_aper", "sdio1_aper", + "spi0_aper", "spi1_aper", "can0_aper", "can1_aper", + "i2c0_aper", "i2c1_aper", "uart0_aper", "uart1_aper", + "gpio_aper", "lqspi_aper", "smc_aper", "swdt", + "dbg_trc", "dbg_apb"; + # optional props + clocks = <&clkc 16>, <&clk_foo>; + clock-names = "gem1_emio_clk", "can_mio_clk_23"; }; diff --git a/Documentation/devicetree/bindings/dma/ste-coh901318.txt b/Documentation/devicetree/bindings/dma/ste-coh901318.txt new file mode 100644 index 000000000000..091ad057e9cf --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ste-coh901318.txt @@ -0,0 +1,32 @@ +ST-Ericsson COH 901 318 DMA Controller + +This is a DMA controller which has begun as a fork of the +ARM PL08x PrimeCell VHDL code. + +Required properties: +- compatible: should be "stericsson,coh901318" +- reg: register locations and length +- interrupts: the single DMA IRQ +- #dma-cells: must be set to <1>, as the channels on the + COH 901 318 are simple and identified by a single number +- dma-channels: the number of DMA channels handled + +Example: + +dmac: dma-controller@c00020000 { + compatible = "stericsson,coh901318"; + reg = <0xc0020000 0x1000>; + interrupt-parent = <&vica>; + interrupts = <2>; + #dma-cells = <1>; + dma-channels = <40>; +}; + +Consumers example: + +uart0: serial@c0013000 { + compatible = "..."; + (...) + dmas = <&dmac 17 &dmac 18>; + dma-names = "tx", "rx"; +}; diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt new file mode 100644 index 000000000000..bea5b73a7390 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt @@ -0,0 +1,66 @@ +* DMA40 DMA Controller + +Required properties: +- compatible: "stericsson,dma40" +- reg: Address range of the DMAC registers +- reg-names: Names of the above areas to use during resource look-up +- interrupt: Should contain the DMAC interrupt number +- #dma-cells: must be <3> +- memcpy-channels: Channels to be used for memcpy + +Optional properties: +- dma-channels: Number of channels supported by hardware - if not present + the driver will attempt to obtain the information from H/W +- disabled-channels: Channels which can not be used + +Example: + + dma: dma-controller@801C0000 { + compatible = "stericsson,db8500-dma40", "stericsson,dma40"; + reg = <0x801C0000 0x1000 0x40010000 0x800>; + reg-names = "base", "lcpa"; + interrupt-parent = <&intc>; + interrupts = <0 25 0x4>; + + #dma-cells = <2>; + memcpy-channels = <56 57 58 59 60>; + disabled-channels = <12>; + dma-channels = <8>; + }; + +Clients +Required properties: +- dmas: Comma separated list of dma channel requests +- dma-names: Names of the aforementioned requested channels + +Each dmas request consists of 4 cells: + 1. A phandle pointing to the DMA controller + 2. Device Type + 3. The DMA request line number (only when 'use fixed channel' is set) + 4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow] + 0x00000001: Mode: + Logical channel when unset + Physical channel when set + 0x00000002: Direction: + Memory to Device when unset + Device to Memory when set + 0x00000004: Endianess: + Little endian when unset + Big endian when set + 0x00000008: Use fixed channel: + Use automatic channel selection when unset + Use DMA request line number when set + +Example: + + uart@80120000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x80120000 0x1000>; + interrupts = <0 11 0x4>; + + dmas = <&dma 13 0 0x2>, /* Logical - DevToMem */ + <&dma 13 0 0x0>; /* Logical - MemToDev */ + dma-names = "rx", "rx"; + + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt new file mode 100644 index 000000000000..9fbbdb783a72 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -0,0 +1,34 @@ +TI EDMA + +Required properties: +- compatible : "ti,edma3" +- ti,edma-regions: Number of regions +- ti,edma-slots: Number of slots +- #dma-cells: Should be set to <1> + Clients should use a single channel number per DMA request. +- dma-channels: Specify total DMA channels per CC +- reg: Memory map for accessing module +- interrupt-parent: Interrupt controller the interrupt is routed through +- interrupts: Exactly 3 interrupts need to be specified in the order: + 1. Transfer completion interrupt. + 2. Memory protection interrupt. + 3. Error interrupt. +Optional properties: +- ti,hwmods: Name of the hwmods associated to the EDMA +- ti,edma-xbar-event-map: Crossbar event to channel map + +Example: + +edma: edma@49000000 { + reg = <0x49000000 0x10000>; + interrupt-parent = <&intc>; + interrupts = <12 13 14>; + compatible = "ti,edma3"; + ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2"; + #dma-cells = <1>; + dma-channels = <64>; + ti,edma-regions = <4>; + ti,edma-slots = <256>; + ti,edma-xbar-event-map = <1 12 + 2 13>; +}; diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt b/Documentation/devicetree/bindings/extcon/extcon-twl.txt new file mode 100644 index 000000000000..58f531ab4df3 --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/extcon-twl.txt @@ -0,0 +1,15 @@ +EXTCON FOR TWL CHIPS + +PALMAS USB COMPARATOR +Required Properties: + - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb" + - vbus-supply : phandle to the regulator device tree node. + +Optional Properties: + - ti,wakeup : To enable the wakeup comparator in probe + +palmas-usb { + compatible = "ti,twl6035-usb", "ti,palmas-usb"; + vbus-supply = <&smps10_reg>; + ti,wakeup; +}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt b/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt new file mode 100644 index 000000000000..e0d0446a6b78 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt @@ -0,0 +1,28 @@ +Cirrus Logic CLPS711X GPIO controller + +Required properties: +- compatible: Should be "cirrus,clps711x-gpio" +- reg: Physical base GPIO controller registers location and length. + There should be two registers, first is DATA register, the second + is DIRECTION. +- gpio-controller: Marks the device node as a gpio controller. +- #gpio-cells: Should be two. The first cell is the pin number and + the second cell is used to specify the gpio polarity: + 0 = active high + 1 = active low + +Note: Each GPIO port should have an alias correctly numbered in "aliases" +node. + +Example: + +aliases { + gpio0 = &porta; +}; + +porta: gpio@80000000 { + compatible = "cirrus,clps711x-gpio"; + reg = <0x80000000 0x1>, <0x80000040 0x1>; + gpio-controller; + #gpio-cells = <2>; +}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-msm.txt b/Documentation/devicetree/bindings/gpio/gpio-msm.txt new file mode 100644 index 000000000000..ac20e68a004e --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-msm.txt @@ -0,0 +1,26 @@ +MSM GPIO controller bindings + +Required properties: +- compatible: + - "qcom,msm-gpio" for MSM controllers +- #gpio-cells : Should be two. + - first cell is the pin number + - second cell is used to specify optional parameters (unused) +- gpio-controller : Marks the device node as a GPIO controller. +- #interrupt-cells : Should be 2. +- interrupt-controller: Mark the device node as an interrupt controller +- interrupts : Specify the TLMM summary interrupt number +- ngpio : Specify the number of MSM GPIOs + +Example: + + msmgpio: gpio@fd510000 { + compatible = "qcom,msm-gpio"; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0xfd510000 0x4000>; + interrupts = <0 208 0>; + ngpio = <150>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt index f1e5dfecf55d..5375625e8cd2 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt @@ -39,46 +39,3 @@ Example: #gpio-cells = <4>; gpio-controller; }; - - -Samsung S3C24XX GPIO Controller - -Required properties: -- compatible: Compatible property value should be "samsung,s3c24xx-gpio". - -- reg: Physical base address of the controller and length of memory mapped - region. - -- #gpio-cells: Should be 3. The syntax of the gpio specifier used by client nodes - should be the following with values derived from the SoC user manual. - <[phandle of the gpio controller node] - [pin number within the gpio controller] - [mux function] - [flags and pull up/down] - - Values for gpio specifier: - - Pin number: depending on the controller a number from 0 up to 15. - - Mux function: Depending on the SoC and the gpio bank the gpio can be set - as input, output or a special function - - Flags and Pull Up/Down: the values to use differ for the individual SoCs - example S3C2416/S3C2450: - 0 - Pull Up/Down Disabled. - 1 - Pull Down Enabled. - 2 - Pull Up Enabled. - Bit 16 (0x00010000) - Input is active low. - Consult the user manual for the correct values of Mux and Pull Up/Down. - -- gpio-controller: Specifies that the node is a gpio controller. -- #address-cells: should be 1. -- #size-cells: should be 1. - -Example: - - gpa: gpio-controller@56000000 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "samsung,s3c24xx-gpio"; - reg = <0x56000000 0x10>; - #gpio-cells = <3>; - gpio-controller; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt b/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt new file mode 100644 index 000000000000..fd665b44d767 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt @@ -0,0 +1,7 @@ +ST-Ericsson COH 901 571/3 GPIO controller + +Required properties: +- compatible: Compatible property value should be "stericsson,gpio-coh901" +- reg: Physical base address of the controller and length of memory mapped + region. +- interrupts: the 0...n interrupts assigned to the different GPIO ports/banks. diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt new file mode 100644 index 000000000000..cb3dc7bcd8e6 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt @@ -0,0 +1,46 @@ +* Renesas R-Car GPIO Controller + +Required Properties: + + - compatible: should be one of the following. + - "renesas,gpio-r8a7778": for R8A7778 (R-Mobile M1) compatible GPIO controller. + - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller. + - "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller. + - "renesas,gpio-rcar": for generic R-Car GPIO controller. + + - reg: Base address and length of each memory resource used by the GPIO + controller hardware module. + + - interrupt-parent: phandle of the parent interrupt controller. + - interrupts: Interrupt specifier for the controllers interrupt. + + - 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. + - gpio-ranges: Range of pins managed by the GPIO controller. + +Please refer to gpio.txt in this directory for details of gpio-ranges property +and the common GPIO bindings used by client devices. + +Example: R8A7779 (R-Car H1) GPIO controller nodes + + gpio0: gpio@ffc40000 { + compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar"; + reg = <0xffc40000 0x2c>; + interrupt-parent = <&gic>; + interrupts = <0 141 0x4>; + #gpio-cells = <2>; + gpio-controller; + gpio-ranges = <&pfc 0 0 32>; + }; + ... + gpio6: gpio@ffc46000 { + compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar"; + reg = <0xffc46000 0x2c>; + interrupt-parent = <&gic>; + interrupts = <0 147 0x4>; + #gpio-cells = <2>; + gpio-controller; + gpio-ranges = <&pfc 0 192 9>; + }; diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt index 2b14a940eb75..3f454ffc654a 100644 --- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt +++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt @@ -10,11 +10,16 @@ Required properties: mapped region. - interrupts : G2D interrupt number to the CPU. + - clocks : from common clock binding: handle to G2D clocks. + - clock-names : from common clock binding: must contain "sclk_fimg2d" and + "fimg2d", corresponding to entries in the clocks property. Example: g2d@12800000 { compatible = "samsung,s5pv210-g2d"; reg = <0x12800000 0x1000>; interrupts = <0 89 0>; + clocks = <&clock 177>, <&clock 277>; + clock-names = "sclk_fimg2d", "fimg2d"; status = "disabled"; }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt b/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt new file mode 100644 index 000000000000..bd81a482634f --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt @@ -0,0 +1,15 @@ +ST Microelectronics DDC I2C + +Required properties : +- compatible : Must be "st,ddci2c" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: interrupt number to the cpu. +- #address-cells = <1>; +- #size-cells = <0>; + +Optional properties: +- Child nodes conforming to i2c bus binding + +Examples : + diff --git a/Documentation/devicetree/bindings/iio/dac/ad7303.txt b/Documentation/devicetree/bindings/iio/dac/ad7303.txt new file mode 100644 index 000000000000..914610f0556e --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/ad7303.txt @@ -0,0 +1,23 @@ +Analog Devices AD7303 DAC device driver + +Required properties: + - compatible: Must be "adi,ad7303" + - reg: SPI chip select number for the device + - spi-max-frequency: Max SPI frequency to use (< 30000000) + - Vdd-supply: Phandle to the Vdd power supply + +Optional properties: + - REF-supply: Phandle to the external reference voltage supply. This should + only be set if there is an external reference voltage connected to the REF + pin. If the property is not set Vdd/2 is used as the reference voltage. + +Example: + + ad7303@4 { + compatible = "adi,ad7303"; + reg = <4>; + spi-max-frequency = <10000000>; + Vdd-supply = <&vdd_supply>; + adi,use-external-reference; + REF-supply = <&vref_supply>; + }; diff --git a/Documentation/devicetree/bindings/iio/frequency/adf4350.txt b/Documentation/devicetree/bindings/iio/frequency/adf4350.txt new file mode 100644 index 000000000000..f8c181d81d2d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/frequency/adf4350.txt @@ -0,0 +1,86 @@ +Analog Devices ADF4350/ADF4351 device driver + +Required properties: + - compatible: Should be one of + * "adi,adf4350": When using the ADF4350 device + * "adi,adf4351": When using the ADF4351 device + - reg: SPI chip select numbert for the device + - spi-max-frequency: Max SPI frequency to use (< 20000000) + - clocks: From common clock binding. Clock is phandle to clock for + ADF435x Reference Clock (CLKIN). + +Optional properties: + - gpios: GPIO Lock detect - If set with a valid phandle and GPIO number, + pll lock state is tested upon read. + - adi,channel-spacing: Channel spacing in Hz (influences MODULUS). + - adi,power-up-frequency: If set in Hz the PLL tunes to + the desired frequency on probe. + - adi,reference-div-factor: If set the driver skips dynamic calculation + and uses this default value instead. + - adi,reference-doubler-enable: Enables reference doubler. + - adi,reference-div2-enable: Enables reference divider. + - adi,phase-detector-polarity-positive-enable: Enables positive phase + detector polarity. Default = negative. + - adi,lock-detect-precision-6ns-enable: Enables 6ns lock detect precision. + Default = 10ns. + - adi,lock-detect-function-integer-n-enable: Enables lock detect + for integer-N mode. Default = factional-N mode. + - adi,charge-pump-current: Charge pump current in mA. + Default = 2500mA. + - adi,muxout-select: On chip multiplexer output selection. + Valid values for the multiplexer output are: + 0: Three-State Output (default) + 1: DVDD + 2: DGND + 3: R-Counter output + 4: N-Divider output + 5: Analog lock detect + 6: Digital lock detect + - adi,low-spur-mode-enable: Enables low spur mode. + Default = Low noise mode. + - adi,cycle-slip-reduction-enable: Enables cycle slip reduction. + - adi,charge-cancellation-enable: Enabled charge pump + charge cancellation for integer-N modes. + - adi,anti-backlash-3ns-enable: Enables 3ns antibacklash pulse width + for integer-N modes. + - adi,band-select-clock-mode-high-enable: Enables faster band + selection logic. + - adi,12bit-clk-divider: Clock divider value used when + adi,12bit-clkdiv-mode != 0 + - adi,clk-divider-mode: + Valid values for the clkdiv mode are: + 0: Clock divider off (default) + 1: Fast lock enable + 2: Phase resync enable + - adi,aux-output-enable: Enables auxiliary RF output. + - adi,aux-output-fundamental-enable: Selects fundamental VCO output on + the auxiliary RF output. Default = Output of RF dividers. + - adi,mute-till-lock-enable: Enables Mute-Till-Lock-Detect function. + - adi,output-power: Output power selection. + Valid values for the power mode are: + 0: -4dBm (default) + 1: -1dBm + 2: +2dBm + 3: +5dBm + - adi,aux-output-power: Auxiliary output power selection. + Valid values for the power mode are: + 0: -4dBm (default) + 1: -1dBm + 2: +2dBm + 3: +5dBm + + +Example: + lo_pll0_rx_adf4351: adf4351-rx-lpc@4 { + compatible = "adi,adf4351"; + reg = <4>; + spi-max-frequency = <10000000>; + clocks = <&clk0_ad9523 9>; + clock-names = "clkin"; + adi,channel-spacing = <10000>; + adi,power-up-frequency = <2400000000>; + adi,phase-detector-polarity-positive-enable; + adi,charge-pump-current = <2500>; + adi,output-power = <3>; + adi,mute-till-lock-enable; + }; diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt new file mode 100644 index 000000000000..011679f1a425 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt @@ -0,0 +1,18 @@ +* AsahiKASEI AK8975 magnetometer sensor + +Required properties: + + - compatible : should be "asahi-kasei,ak8975" + - reg : the I2C address of the magnetometer + +Optional properties: + + - gpios : should be device tree identifier of the magnetometer DRDY pin + +Example: + +ak8975@0c { + compatible = "asahi-kasei,ak8975"; + reg = <0x0c>; + gpios = <&gpj0 7 0>; +}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt b/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt new file mode 100644 index 000000000000..9d52d5afe3e9 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt @@ -0,0 +1,38 @@ +TB10x Top Level Interrupt Controller +==================================== + +The Abilis TB10x SOC contains a custom interrupt controller. It performs +one-to-one mapping of external interrupt sources to CPU interrupts and +provides support for reconfigurable trigger modes. + +Required properties +------------------- + +- compatible: Should be "abilis,tb10x-ictl" +- reg: specifies physical base address and size of register range. +- interrupt-congroller: Identifies the node as an interrupt controller. +- #interrupt cells: Specifies the number of cells used to encode an interrupt + source connected to this controller. The value shall be 2. +- interrupt-parent: Specifies the parent interrupt controller. +- interrupts: Specifies the list of interrupt lines which are handled by + the interrupt controller in the parent controller's notation. Interrupts + are mapped one-to-one to parent interrupts. + +Example +------- + +intc: interrupt-controller { /* Parent interrupt controller */ + interrupt-controller; + #interrupt-cells = <1>; /* For example below */ + /* ... */ +}; + +tb10x_ictl: pic@2000 { /* TB10x interrupt controller */ + compatible = "abilis,tb10x-ictl"; + reg = <0x2000 0x20>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&intc>; + interrupts = <5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 + 20 21 22 23 24 25 26 27 28 29 30 31>; +}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt index e7f4dc14eff2..57edb30dbbca 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt @@ -8,91 +8,8 @@ Required properties: - #interrupt-cells : Specifies the number of cells needed to encode an interrupt source. The value shall be 1. -The interrupt sources are as follows: - -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: SDMC0 -33: SDMC1 -34: SDMC2 -35: SDMC3 -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 +For the valid interrupt sources for your SoC, see the documentation in +sunxi/<soc>.txt Example: diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt new file mode 100644 index 000000000000..2c11ac76fac9 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt @@ -0,0 +1,48 @@ +Marvell Orion SoC interrupt controllers + +* Main interrupt controller + +Required properties: +- compatible: shall be "marvell,orion-intc" +- reg: base address(es) of interrupt registers starting with CAUSE register +- interrupt-controller: identifies the node as an interrupt controller +- #interrupt-cells: number of cells to encode an interrupt source, shall be 1 + +The interrupt sources map to the corresponding bits in the interrupt +registers, i.e. +- 0 maps to bit 0 of first base address, +- 1 maps to bit 1 of first base address, +- 32 maps to bit 0 of second base address, and so on. + +Example: + intc: interrupt-controller { + compatible = "marvell,orion-intc"; + interrupt-controller; + #interrupt-cells = <1>; + /* Dove has 64 first level interrupts */ + reg = <0x20200 0x10>, <0x20210 0x10>; + }; + +* Bridge interrupt controller + +Required properties: +- compatible: shall be "marvell,orion-bridge-intc" +- reg: base address of bridge interrupt registers starting with CAUSE register +- interrupts: bridge interrupt of the main interrupt controller +- interrupt-controller: identifies the node as an interrupt controller +- #interrupt-cells: number of cells to encode an interrupt source, shall be 1 + +Optional properties: +- marvell,#interrupts: number of interrupts provided by bridge interrupt + controller, defaults to 32 if not set + +Example: + bridge_intc: interrupt-controller { + compatible = "marvell,orion-bridge-intc"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x20110 0x8>; + interrupts = <0>; + /* Dove bridge provides 5 interrupts */ + marvell,#interrupts = <5>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt new file mode 100644 index 000000000000..1f8b0c507c26 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt @@ -0,0 +1,16 @@ +DT bindings for the R-/SH-Mobile irqpin controller + +Required properties: + +- compatible: has to be "renesas,intc-irqpin" +- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in + interrupts.txt in this directory + +Optional properties: + +- any properties, listed in interrupts.txt, and any standard resource allocation + properties +- sense-bitfield-width: width of a single sense bitfield in the SENSE register, + if different from the default 4 bits +- control-parent: disable and enable interrupts on the parent interrupt + controller, needed for some broken implementations diff --git a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt new file mode 100644 index 000000000000..76b98c834499 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt @@ -0,0 +1,89 @@ +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 new file mode 100644 index 000000000000..2ec3b5ce1a0b --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt @@ -0,0 +1,55 @@ +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/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index bf0182d8da25..df37b0230c75 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -15,6 +15,9 @@ Required properties: mapped region. - interrupts : MFC interrupt number to the CPU. + - clocks : from common clock binding: handle to mfc clocks. + - clock-names : from common clock binding: must contain "sclk_mfc" and "mfc", + corresponding to entries in the clocks property. - samsung,mfc-r : Base address of the first memory bank used by MFC for DMA contiguous memory allocation and its size. @@ -34,6 +37,8 @@ mfc: codec@13400000 { reg = <0x13400000 0x10000>; interrupts = <0 94 0>; samsung,power-domain = <&pd_mfc>; + clocks = <&clock 170>, <&clock 273>; + clock-names = "sclk_mfc", "mfc"; }; Board specific DT entry: diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt new file mode 100644 index 000000000000..653c90c34a71 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt @@ -0,0 +1,156 @@ +Device tree bindings for MVEBU Device Bus controllers + +The Device Bus controller available in some Marvell's SoC allows to control +different types of standard memory and I/O devices such as NOR, NAND, and FPGA. +The actual devices are instantiated from the child nodes of a Device Bus node. + +Required properties: + + - compatible: Currently only Armada 370/XP SoC are supported, + with this compatible string: + + marvell,mvebu-devbus + + - reg: A resource specifier for the register space. + This is the base address of a chip select within + the controller's register space. + (see the example below) + + - #address-cells: Must be set to 1 + - #size-cells: Must be set to 1 + - ranges: Must be set up to reflect the memory layout with four + integer values for each chip-select line in use: + 0 <physical address of mapping> <size> + +Mandatory timing properties for child nodes: + +Read parameters: + + - devbus,turn-off-ps: Defines the time during which the controller does not + drive the AD bus after the completion of a device read. + This prevents contentions on the Device Bus after a read + cycle from a slow device. + + - devbus,bus-width: Defines the bus width (e.g. <16>) + + - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle, + to read data sample. This parameter is useful for + synchronous pipelined devices, where the address + precedes the read data by one or two cycles. + + - devbus,acc-first-ps: Defines the time delay from the negation of + ALE[0] to the cycle that the first read data is sampled + by the controller. + + - devbus,acc-next-ps: Defines the time delay between the cycle that + samples data N and the cycle that samples data N+1 + (in burst accesses). + + - devbus,rd-setup-ps: Defines the time delay between DEV_CSn assertion to + DEV_OEn assertion. If set to 0 (default), + DEV_OEn and DEV_CSn are asserted at the same cycle. + This parameter has no affect on <acc-first-ps> parameter + (no affect on first data sample). Set <rd-setup-ps> + to a value smaller than <acc-first-ps>. + + - devbus,rd-hold-ps: Defines the time between the last data sample to the + de-assertion of DEV_CSn. If set to 0 (default), + DEV_OEn and DEV_CSn are de-asserted at the same cycle + (the cycle of the last data sample). + This parameter has no affect on DEV_OEn de-assertion. + DEV_OEn is always de-asserted the next cycle after + last data sampled. Also this parameter has no + affect on <turn-off-ps> parameter. + Set <rd-hold-ps> to a value smaller than <turn-off-ps>. + +Write parameters: + + - devbus,ale-wr-ps: Defines the time delay from the ALE[0] negation cycle + to the DEV_WEn assertion. + + - devbus,wr-low-ps: Defines the time during which DEV_WEn is active. + A[2:0] and Data are kept valid as long as DEV_WEn + is active. This parameter defines the setup time of + address and data to DEV_WEn rise. + + - devbus,wr-high-ps: Defines the time during which DEV_WEn is kept + inactive (high) between data beats of a burst write. + DEV_A[2:0] and Data are kept valid (do not toggle) for + <wr-high-ps> - <tick> ps. + This parameter defines the hold time of address and + data after DEV_WEn rise. + + - devbus,sync-enable: Synchronous device enable. + 1: True + 0: False + +An example for an Armada XP GP board, with a 16 MiB NOR device as child +is showed below. Note that the Device Bus driver is in charge of allocating +the mbus address decoding window for each of its child devices. +The window is created using the chip select specified in the child +device node together with the base address and size specified in the ranges +property. For instance, in the example below the allocated decoding window +will start at base address 0xf0000000, with a size 0x1000000 (16 MiB) +for chip select 0 (a.k.a DEV_BOOTCS). + +This address window handling is done in this mvebu-devbus only as a temporary +solution. It will be removed when the support for mbus device tree binding is +added. + +The reg property implicitly specifies the chip select as this: + + 0x10400: DEV_BOOTCS + 0x10408: DEV_CS0 + 0x10410: DEV_CS1 + 0x10418: DEV_CS2 + 0x10420: DEV_CS3 + +Example: + + devbus-bootcs@d0010400 { + status = "okay"; + ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf0000000, size 0x1000000 */ + #address-cells = <1>; + #size-cells = <1>; + + /* Device Bus parameters are required */ + + /* Read parameters */ + devbus,bus-width = <8>; + devbus,turn-off-ps = <60000>; + devbus,badr-skew-ps = <0>; + devbus,acc-first-ps = <124000>; + devbus,acc-next-ps = <248000>; + devbus,rd-setup-ps = <0>; + devbus,rd-hold-ps = <0>; + + /* Write parameters */ + devbus,sync-enable = <0>; + devbus,wr-high-ps = <60000>; + devbus,wr-low-ps = <60000>; + devbus,ale-wr-ps = <60000>; + + flash@0 { + compatible = "cfi-flash"; + + /* 16 MiB */ + reg = <0 0x1000000>; + bank-width = <2>; + #address-cells = <1>; + #size-cells = <1>; + + /* + * We split the 16 MiB in two partitions, + * just as an example. + */ + partition@0 { + label = "First"; + reg = <0 0x800000>; + }; + + partition@800000 { + label = "Second"; + reg = <0x800000 0x800000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt index c3a14e0ad0ad..cd9e90c5d171 100644 --- a/Documentation/devicetree/bindings/mfd/ab8500.txt +++ b/Documentation/devicetree/bindings/mfd/ab8500.txt @@ -120,7 +120,7 @@ ab8500 { "USB_LINK_STATUS", "USB_ADP_PROBE_PLUG", "USB_ADP_PROBE_UNPLUG"; - vddulpivio18-supply = <&ab8500_ldo_initcore_reg>; + vddulpivio18-supply = <&ab8500_ldo_intcore_reg>; v-ape-supply = <&db8500_vape_reg>; musb_1v8-supply = <&db8500_vsmps2_reg>; }; diff --git a/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt b/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt new file mode 100644 index 000000000000..094ae010f2fb --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt @@ -0,0 +1,16 @@ +Broadcom BCM281xx SDHCI + +This file documents differences between the core properties in mmc.txt +and the properties present in the bcm281xx SDHCI + +Required properties: +- compatible : Should be "bcm,kona-sdhci" + +Example: + +sdio2: sdio@0x3f1a0000 { + compatible = "bcm,kona-sdhci"; + reg = <0x3f1a0000 0x10000>; + interrupts = <0x0 74 0x4>; +}; + diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index 6a983c1d87cd..df338cb5059c 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -29,6 +29,13 @@ Optional properties: "bch4" 4-bit BCH ecc code "bch8" 8-bit BCH ecc code + - ti,nand-xfer-type: A string setting the data transfer type. One of: + + "prefetch-polled" Prefetch polled mode (default) + "polled" Polled mode, without prefetch + "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. @@ -55,6 +62,7 @@ Example for an AM33xx board: reg = <0 0 0>; /* CS0, offset 0 */ nand-bus-width = <16>; ti,nand-ecc-opt = "bch8"; + ti,nand-xfer-type = "polled"; gpmc,sync-clk-ps = <0>; gpmc,cs-on-ns = <0>; diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt new file mode 100644 index 000000000000..e2371f5cdebe --- /dev/null +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -0,0 +1,73 @@ +* Synopsis Designware PCIe interface + +Required properties: +- compatible: should contain "snps,dw-pcie" to identify the + core, plus an identifier for the specific instance, such + as "samsung,exynos5440-pcie". +- reg: base addresses and lengths of the pcie controller, + the phy controller, additional register for the phy controller. +- interrupts: interrupt values for level interrupt, + pulse interrupt, special interrupt. +- clocks: from common clock binding: handle to pci clock. +- clock-names: from common clock binding: should be "pcie" and "pcie_bus". +- #address-cells: set to <3> +- #size-cells: set to <2> +- device_type: set to "pci" +- ranges: ranges for the PCI memory and I/O regions +- #interrupt-cells: set to <1> +- interrupt-map-mask and interrupt-map: standard PCI properties + to define the mapping of the PCIe interface to interrupt + numbers. +- reset-gpio: gpio pin number of power good signal + +Example: + +SoC specific DT Entry: + + pcie@290000 { + compatible = "samsung,exynos5440-pcie", "snps,dw-pcie"; + reg = <0x290000 0x1000 + 0x270000 0x1000 + 0x271000 0x40>; + interrupts = <0 20 0>, <0 21 0>, <0 22 0>; + clocks = <&clock 28>, <&clock 27>; + clock-names = "pcie", "pcie_bus"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */ + 0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */ + 0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */ + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0x0 0 &gic 53>; + }; + + pcie@2a0000 { + compatible = "samsung,exynos5440-pcie", "snps,dw-pcie"; + reg = <0x2a0000 0x1000 + 0x272000 0x1000 + 0x271040 0x40>; + interrupts = <0 23 0>, <0 24 0>, <0 25 0>; + clocks = <&clock 29>, <&clock 27>; + clock-names = "pcie", "pcie_bus"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */ + 0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */ + 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */ + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0x0 0 &gic 56>; + }; + +Board specific DT Entry: + + pcie@290000 { + reset-gpio = <&pin_ctrl 5 0>; + }; + + pcie@2a0000 { + reset-gpio = <&pin_ctrl 22 0>; + }; diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt new file mode 100644 index 000000000000..f8d405897a94 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt @@ -0,0 +1,221 @@ +* Marvell EBU PCIe interfaces + +Mandatory properties: +- compatible: one of the following values: + marvell,armada-370-pcie + marvell,armada-xp-pcie + marvell,kirkwood-pcie +- #address-cells, set to <3> +- #size-cells, set to <2> +- #interrupt-cells, set to <1> +- bus-range: PCI bus numbers covered +- device_type, set to "pci" +- ranges: ranges for the PCI memory and I/O regions, as well as the + MMIO registers to control the PCIe interfaces. + +In addition, the Device Tree node must have sub-nodes describing each +PCIe interface, having the following mandatory properties: +- reg: used only for interrupt mapping, so only the first four bytes + are used to refer to the correct bus number and device number. +- assigned-addresses: reference to the MMIO registers used to control + this PCIe interface. +- clocks: the clock associated to this PCIe interface +- marvell,pcie-port: the physical PCIe port number +- status: either "disabled" or "okay" +- device_type, set to "pci" +- #address-cells, set to <3> +- #size-cells, set to <2> +- #interrupt-cells, set to <1> +- ranges, empty property. +- interrupt-map-mask and interrupt-map, standard PCI properties to + define the mapping of the PCIe interface to interrupt numbers. + +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. + +Example: + +pcie-controller { + compatible = "marvell,armada-xp-pcie"; + status = "disabled"; + device_type = "pci"; + + #address-cells = <3>; + #size-cells = <2>; + + bus-range = <0x00 0xff>; + + ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000 /* Port 0.0 registers */ + 0x82000000 0 0xd0042000 0xd0042000 0 0x00002000 /* Port 2.0 registers */ + 0x82000000 0 0xd0044000 0xd0044000 0 0x00002000 /* Port 0.1 registers */ + 0x82000000 0 0xd0048000 0xd0048000 0 0x00002000 /* Port 0.2 registers */ + 0x82000000 0 0xd004c000 0xd004c000 0 0x00002000 /* Port 0.3 registers */ + 0x82000000 0 0xd0080000 0xd0080000 0 0x00002000 /* Port 1.0 registers */ + 0x82000000 0 0xd0082000 0xd0082000 0 0x00002000 /* Port 3.0 registers */ + 0x82000000 0 0xd0084000 0xd0084000 0 0x00002000 /* Port 1.1 registers */ + 0x82000000 0 0xd0088000 0xd0088000 0 0x00002000 /* Port 1.2 registers */ + 0x82000000 0 0xd008c000 0xd008c000 0 0x00002000 /* Port 1.3 registers */ + 0x82000000 0 0xe0000000 0xe0000000 0 0x08000000 /* non-prefetchable memory */ + 0x81000000 0 0 0xe8000000 0 0x00100000>; /* downstream I/O */ + + pcie@1,0 { + device_type = "pci"; + assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>; + reg = <0x0800 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 58>; + marvell,pcie-port = <0>; + marvell,pcie-lane = <0>; + clocks = <&gateclk 5>; + status = "disabled"; + }; + + pcie@2,0 { + device_type = "pci"; + assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>; + reg = <0x1000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 59>; + marvell,pcie-port = <0>; + marvell,pcie-lane = <1>; + clocks = <&gateclk 6>; + status = "disabled"; + }; + + pcie@3,0 { + device_type = "pci"; + assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>; + reg = <0x1800 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 60>; + marvell,pcie-port = <0>; + marvell,pcie-lane = <2>; + clocks = <&gateclk 7>; + status = "disabled"; + }; + + pcie@4,0 { + device_type = "pci"; + assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>; + reg = <0x2000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 61>; + marvell,pcie-port = <0>; + marvell,pcie-lane = <3>; + clocks = <&gateclk 8>; + status = "disabled"; + }; + + pcie@5,0 { + device_type = "pci"; + assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>; + reg = <0x2800 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 62>; + marvell,pcie-port = <1>; + marvell,pcie-lane = <0>; + clocks = <&gateclk 9>; + status = "disabled"; + }; + + pcie@6,0 { + device_type = "pci"; + assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>; + reg = <0x3000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 63>; + marvell,pcie-port = <1>; + marvell,pcie-lane = <1>; + clocks = <&gateclk 10>; + status = "disabled"; + }; + + pcie@7,0 { + device_type = "pci"; + assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>; + reg = <0x3800 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 64>; + marvell,pcie-port = <1>; + marvell,pcie-lane = <2>; + clocks = <&gateclk 11>; + status = "disabled"; + }; + + pcie@8,0 { + device_type = "pci"; + assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>; + reg = <0x4000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 65>; + marvell,pcie-port = <1>; + marvell,pcie-lane = <3>; + clocks = <&gateclk 12>; + status = "disabled"; + }; + pcie@9,0 { + device_type = "pci"; + assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>; + reg = <0x4800 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 99>; + marvell,pcie-port = <2>; + marvell,pcie-lane = <0>; + clocks = <&gateclk 26>; + status = "disabled"; + }; + + pcie@10,0 { + device_type = "pci"; + assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>; + reg = <0x5000 0 0 0 0>; + #address-cells = <3>; + #size-cells = <2>; + #interrupt-cells = <1>; + ranges; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &mpic 103>; + marvell,pcie-port = <3>; + marvell,pcie-lane = <0>; + clocks = <&gateclk 27>; + status = "disabled"; + }; +}; diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt new file mode 100644 index 000000000000..41aeed38926d --- /dev/null +++ b/Documentation/devicetree/bindings/pci/pci.txt @@ -0,0 +1,9 @@ +PCI bus bridges have standardized Device Tree bindings: + +PCI Bus Binding to: IEEE Std 1275-1994 +http://www.openfirmware.org/ofwg/bindings/pci/pci2_1.pdf + +And for the interrupt mapping part: + +Open Firmware Recommended Practice: Interrupt Mapping +http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf diff --git a/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt new file mode 100644 index 000000000000..30b364e504ba --- /dev/null +++ b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt @@ -0,0 +1,15 @@ +V3 Semiconductor V360 EPC PCI bridge + +This bridge is found in the ARM Integrator/AP (Application Platform) + +Integrator-specific notes: + +- syscon: should contain a link to the syscon device node (since + on the Integrator, some registers in the syscon are required to + operate the V3). + +V360 EPC specific notes: + +- reg: should contain the base address of the V3 adapter. +- interrupts: should contain a reference to the V3 error interrupt + as routed on the system. diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt index bcfdab5d442e..3a7caf7a744a 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt @@ -58,7 +58,7 @@ Some requirements for using fsl,imx-pinctrl binding: Examples: usdhc@0219c000 { /* uSDHC4 */ - fsl,card-wired; + non-removable; vmmc-supply = <®_3p3v>; status = "okay"; pinctrl-names = "default"; diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index c70fca146e91..36281e7a2a46 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -7,10 +7,15 @@ on-chip controllers onto these pads. Required Properties: - compatible: should be one of the following. + - "samsung,s3c2412-pinctrl": for S3C2412-compatible pin-controller, + - "samsung,s3c2416-pinctrl": for S3C2416-compatible pin-controller, + - "samsung,s3c2440-pinctrl": for S3C2440-compatible pin-controller, + - "samsung,s3c2450-pinctrl": for S3C2450-compatible pin-controller, - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller, - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller. - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller. - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller. + - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller. - reg: Base address of the pin controller hardware module and length of the address space it occupies. @@ -21,8 +26,18 @@ Required Properties: - gpio-controller: identifies the node as a gpio controller and pin bank. - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO - binding is used, the amount of cells must be specified as 2. See generic - GPIO binding documentation for description of particular cells. + binding is used, the amount of cells must be specified as 2. See the below + mentioned gpio binding representation for description of particular cells. + + Eg: <&gpx2 6 0> + <[phandle of the gpio controller node] + [pin number within the gpio controller] + [flags]> + + Values for gpio specifier: + - Pin number: is a value between 0 to 7. + - Flags: 0 - Active High + 1 - Active Low - Pin mux/config groups as child nodes: The pin mux (selecting pin function mode) and pin config (pull up/down, driver strength) settings are represented @@ -106,6 +121,10 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a - compatible: identifies the type of the external wakeup interrupt controller The possible values are: + - samsung,s3c2410-wakeup-eint: represents wakeup interrupt controller + found on Samsung S3C24xx SoCs except S3C2412 and S3C2413, + - samsung,s3c2412-wakeup-eint: represents wakeup interrupt controller + found on Samsung S3C2412 and S3C2413 SoCs, - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller found on Samsung S3C64xx SoCs, - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller @@ -266,3 +285,33 @@ Example 4: Set up the default pin state for uart controller. pinctrl = devm_pinctrl_get_select_default(&pdev->dev); } + +Example 5: A display port client node that supports 'default' pinctrl state + and gpio binding. + + display-port-controller { + /* ... */ + + samsung,hpd-gpio = <&gpx2 6 0>; + pinctrl-names = "default"; + pinctrl-0 = <&dp_hpd>; + }; + +Example 6: Request the gpio for display port controller + + static int exynos_dp_probe(struct platform_device *pdev) + { + int hpd_gpio, ret; + struct device *dev = &pdev->dev; + struct device_node *dp_node = dev->of_node; + + /* ... */ + + hpd_gpio = of_get_named_gpio(dp_node, "samsung,hpd-gpio", 0); + + /* ... */ + + ret = devm_gpio_request_one(&pdev->dev, hpd_gpio, GPIOF_IN, + "hpd_gpio"); + /* ... */ + } diff --git a/Documentation/devicetree/bindings/rtc/dw-apb.txt b/Documentation/devicetree/bindings/rtc/dw-apb.txt index 93e2b0f048e6..eb2327b2bdb3 100644 --- a/Documentation/devicetree/bindings/rtc/dw-apb.txt +++ b/Documentation/devicetree/bindings/rtc/dw-apb.txt @@ -5,9 +5,20 @@ Required properties: - reg: physical base address of the controller and length of memory mapped region. - interrupts: IRQ line for the timer. +- either clocks+clock-names or clock-frequency properties + +Optional properties: +- clocks : list of clock specifiers, corresponding to entries in + the clock-names property; +- clock-names : should contain "timer" and "pclk" entries, matching entries + in the clocks property. - clock-frequency: The frequency in HZ of the timer. - clock-freq: For backwards compatibility with picoxcell +If using the clock specifiers, the pclk clock is optional, as not all +systems may use one. + + Example: timer1: timer@ffc09000 { @@ -23,3 +34,11 @@ Example: clock-frequency = <200000000>; reg = <0xffd00000 0x1000>; }; + + timer3: timer@ffe00000 { + compatible = "snps,dw-apb-timer-osc"; + interrupts = <0 170 4>; + reg = <0xffe00000 0x1000>; + clocks = <&timer_clk>, <&timer_pclk>; + clock-names = "timer", "pclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt b/Documentation/devicetree/bindings/sound/samsung-i2s.txt index 3070046da2e5..025e66b85a43 100644 --- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt +++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt @@ -8,6 +8,16 @@ Required SoC Specific Properties: - dmas: list of DMA controller phandle and DMA request line ordered pairs. - dma-names: identifier string for each DMA request line in the dmas property. These strings correspond 1:1 with the ordered pairs in dmas. +- clocks: Handle to iis clock and RCLK source clk. +- clock-names: + i2s0 uses some base clks from CMU and some are from audio subsystem internal + clock controller. The clock names for i2s0 should be "iis", "i2s_opclk0" and + "i2s_opclk1" as shown in the example below. + i2s1 and i2s2 uses clocks from CMU. The clock names for i2s1 and i2s2 should + be "iis" and "i2s_opclk0". + "iis" is the i2s bus clock and i2s_opclk0, i2s_opclk1 are sources of the root + clk. i2s0 has internal mux to select the source of root clk and i2s1 and i2s2 + doesn't have any such mux. Optional SoC Specific Properties: @@ -20,44 +30,26 @@ Optional SoC Specific Properties: then this flag is enabled. - samsung,idma-addr: Internal DMA register base address of the audio sub system(used in secondary sound source). - -Required Board Specific Properties: - -- gpios: The gpio specifier for data out,data in, LRCLK, CDCLK and SCLK - interface lines. The format of the gpio specifier depends on the gpio - controller. - The syntax of samsung gpio specifier is - <[phandle of the gpio controller node] - [pin number within the gpio controller] - [mux function] - [flags and pull up/down] - [drive strength]> +- pinctrl-0: Should specify pin control groups used for this controller. +- pinctrl-names: Should contain only one value - "default". Example: -- SoC Specific Portion: - -i2s@03830000 { +i2s0: i2s@03830000 { compatible = "samsung,i2s-v5"; reg = <0x03830000 0x100>; dmas = <&pdma0 10 &pdma0 9 &pdma0 8>; dma-names = "tx", "rx", "tx-sec"; + clocks = <&clock_audss EXYNOS_I2S_BUS>, + <&clock_audss EXYNOS_I2S_BUS>, + <&clock_audss EXYNOS_SCLK_I2S>; + clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; samsung,supports-6ch; samsung,supports-rstclr; samsung,supports-secdai; samsung,idma-addr = <0x03000000>; -}; - -- Board Specific Portion: - -i2s@03830000 { - gpios = <&gpz 0 2 0 0>, /* I2S_0_SCLK */ - <&gpz 1 2 0 0>, /* I2S_0_CDCLK */ - <&gpz 2 2 0 0>, /* I2S_0_LRCK */ - <&gpz 3 2 0 0>, /* I2S_0_SDI */ - <&gpz 4 2 0 0>, /* I2S_0_SDO[1] */ - <&gpz 5 2 0 0>, /* I2S_0_SDO[2] */ - <&gpz 6 2 0 0>; /* I2S_0_SDO[3] */ + pinctrl-names = "default"; + pinctrl-0 = <&i2s0_bus>; }; diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt new file mode 100644 index 000000000000..ed9377811ee2 --- /dev/null +++ b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt @@ -0,0 +1,99 @@ +Device-Tree bindings for LVDS Display Bridge (ldb) + +LVDS Display Bridge +=================== + +The LVDS Display Bridge device tree node contains up to two lvds-channel +nodes describing each of the two LVDS encoder channels of the bridge. + +Required properties: + - #address-cells : should be <1> + - #size-cells : should be <0> + - compatible : should be "fsl,imx53-ldb" or "fsl,imx6q-ldb". + Both LDB versions are similar, but i.MX6 has an additional + multiplexer in the front to select any of the four IPU display + interfaces as input for each LVDS channel. + - gpr : should be <&gpr> on i.MX53 and i.MX6q. + The phandle points to the iomuxc-gpr region containing the LVDS + control register. +- clocks, clock-names : phandles to the LDB divider and selector clocks and to + the display interface selector clocks, as described in + Documentation/devicetree/bindings/clock/clock-bindings.txt + The following clocks are expected on i.MX53: + "di0_pll" - LDB LVDS channel 0 mux + "di1_pll" - LDB LVDS channel 1 mux + "di0" - LDB LVDS channel 0 gate + "di1" - LDB LVDS channel 1 gate + "di0_sel" - IPU1 DI0 mux + "di1_sel" - IPU1 DI1 mux + On i.MX6q the following additional clocks are needed: + "di2_sel" - IPU2 DI0 mux + "di3_sel" - IPU2 DI1 mux + The needed clock numbers for each are documented in + Documentation/devicetree/bindings/clock/imx5-clock.txt, and in + Documentation/devicetree/bindings/clock/imx6q-clock.txt. + +Optional properties: + - pinctrl-names : should be "default" on i.MX53, not used on i.MX6q + - pinctrl-0 : a phandle pointing to LVDS pin settings on i.MX53, + not used on i.MX6q + - fsl,dual-channel : boolean. if it exists, only LVDS channel 0 should + be configured - one input will be distributed on both outputs in dual + channel mode + +LVDS Channel +============ + +Each LVDS Channel has to contain a display-timings node that describes the +video timings for the connected LVDS display. For detailed information, also +have a look at Documentation/devicetree/bindings/video/display-timing.txt. + +Required properties: + - reg : should be <0> or <1> + - crtcs : a list of phandles with index pointing to the IPU display interfaces + that can be used as video source for this channel. + - fsl,data-mapping : should be "spwg" or "jeida" + This describes how the color bits are laid out in the + serialized LVDS signal. + - fsl,data-width : should be <18> or <24> + +example: + +gpr: iomuxc-gpr@53fa8000 { + /* ... */ +}; + +ldb: ldb@53fa8008 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx53-ldb"; + gpr = <&gpr>; + clocks = <&clks 122>, <&clks 120>, + <&clks 115>, <&clks 116>, + <&clks 123>, <&clks 85>; + clock-names = "di0_pll", "di1_pll", + "di0_sel", "di1_sel", + "di0", "di1"; + + lvds-channel@0 { + reg = <0>; + crtcs = <&ipu 0>; + fsl,data-mapping = "spwg"; + fsl,data-width = <24>; + + display-timings { + /* ... */ + }; + }; + + lvds-channel@1 { + reg = <1>; + crtcs = <&ipu 1>; + fsl,data-mapping = "spwg"; + fsl,data-width = <24>; + + display-timings { + /* ... */ + }; + }; +}; diff --git a/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt b/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt new file mode 100644 index 000000000000..9499bc8ee9e3 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt @@ -0,0 +1,18 @@ +ST-Ericsson U300 apptimer + +Required properties: + +- compatible : should be "stericsson,u300-apptimer" +- reg : Specifies base physical address and size of the registers. +- interrupts : A list of 4 interrupts; one for each subtimer. These + are, in order: OS (operating system), DD (device driver) both + adopted for EPOC/Symbian with two specific IRQs for these tasks, + then GP1 and GP2, which are general-purpose timers. + +Example: + +timer { + compatible = "stericsson,u300-apptimer"; + reg = <0xc0014000 0x1000>; + interrupts = <24 25 26 27>; +}; diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt index b462d0c54823..c662eb36be29 100644 --- a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt +++ b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt @@ -8,6 +8,8 @@ Required properties: Optional properties: - fsl,uart-has-rtscts : Indicate the uart has rts and cts - fsl,irda-mode : Indicate the uart supports irda mode +- fsl,dte-mode : Indicate the uart works in DTE mode. The uart works + is DCE mode by default. Example: @@ -16,4 +18,5 @@ serial@73fbc000 { reg = <0x73fbc000 0x4000>; interrupts = <31>; fsl,uart-has-rtscts; + fsl,dte-mode; }; diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt new file mode 100644 index 000000000000..6fd1dd1638dd --- /dev/null +++ b/Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt @@ -0,0 +1,14 @@ +* Freescale low power universal asynchronous receiver/transmitter (lpuart) + +Required properties: +- compatible : Should be "fsl,<soc>-lpuart" +- reg : Address and length of the register set for the device +- interrupts : Should contain uart interrupt + +Example: + +uart0: serial@40027000 { + compatible = "fsl,vf610-lpuart"; + reg = <0x40027000 0x1000>; + interrupts = <0 61 0x00>; + }; diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt index 60bd2150a3e6..55f51af08bc7 100644 --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt @@ -47,3 +47,85 @@ usb1: gadget@fffa4000 { interrupts = <10 4>; atmel,vbus-gpio = <&pioC 5 0>; }; + +Atmel High-Speed USB device controller + +Required properties: + - compatible: Should be "atmel,at91sam9rl-udc" + - reg: Address and length of the register set for the device + - interrupts: Should contain usba interrupt + - ep childnode: To specify the number of endpoints and their properties. + +Optional properties: + - atmel,vbus-gpio: If present, specifies a gpio that needs to be + activated for the bus to be powered. + +Required child node properties: + - name: Name of the endpoint. + - reg: Num of the endpoint. + - atmel,fifo-size: Size of the fifo. + - atmel,nb-banks: Number of banks. + - atmel,can-dma: Boolean to specify if the endpoint support DMA. + - atmel,can-isoc: Boolean to specify if the endpoint support ISOC. + +usb2: gadget@fff78000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "atmel,at91sam9rl-udc"; + reg = <0x00600000 0x80000 + 0xfff78000 0x400>; + interrupts = <27 4 0>; + atmel,vbus-gpio = <&pioB 19 0>; + + ep0 { + reg = <0>; + atmel,fifo-size = <64>; + atmel,nb-banks = <1>; + }; + + ep1 { + reg = <1>; + atmel,fifo-size = <1024>; + atmel,nb-banks = <2>; + atmel,can-dma; + atmel,can-isoc; + }; + + ep2 { + reg = <2>; + atmel,fifo-size = <1024>; + atmel,nb-banks = <2>; + atmel,can-dma; + atmel,can-isoc; + }; + + ep3 { + reg = <3>; + atmel,fifo-size = <1024>; + atmel,nb-banks = <3>; + atmel,can-dma; + }; + + ep4 { + reg = <4>; + atmel,fifo-size = <1024>; + atmel,nb-banks = <3>; + atmel,can-dma; + }; + + ep5 { + reg = <5>; + atmel,fifo-size = <1024>; + atmel,nb-banks = <3>; + atmel,can-dma; + atmel,can-isoc; + }; + + ep6 { + reg = <6>; + atmel,fifo-size = <1024>; + atmel,nb-banks = <3>; + atmel,can-dma; + atmel,can-isoc; + }; +}; diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt index 1c04a4c9515f..b4b5b7906c88 100644 --- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt @@ -5,6 +5,12 @@ Required properties: - reg: Should contain registers location and length - interrupts: Should contain controller interrupt +Recommended properies: +- phy_type: the type of the phy connected to the core. Should be one + of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this + property the PORTSC register won't be touched +- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg" + Optional properties: - fsl,usbphy: phandler of usb phy that connects to the only one port - fsl,usbmisc: phandler of non-core register device, with one argument diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt index b3abde736017..d967ba16de60 100644 --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt @@ -48,3 +48,37 @@ Example: clocks = <&clock 285>; clock-names = "usbhost"; }; + +DWC3 +Required properties: + - compatible: should be "samsung,exynos5250-dwusb3" for USB 3.0 DWC3 + controller. + - #address-cells, #size-cells : should be '1' if the device has sub-nodes + with 'reg' property. + - ranges: allows valid 1:1 translation between child's address space and + parent's address space + - clocks: Clock IDs array as required by the controller. + - clock-names: names of clocks correseponding to IDs in the clock property + +Sub-nodes: +The dwc3 core should be added as subnode to Exynos dwc3 glue. +- dwc3 : + The binding details of dwc3 can be found in: + Documentation/devicetree/bindings/usb/dwc3.txt + +Example: + usb@12000000 { + compatible = "samsung,exynos5250-dwusb3"; + clocks = <&clock 286>; + clock-names = "usbdrd30"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + dwc3 { + compatible = "synopsys,dwc3"; + reg = <0x12000000 0x10000>; + interrupts = <0 72 0>; + usb-phy = <&usb2_phy &usb3_phy>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt index 34c952883276..df0933043a5b 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt @@ -6,27 +6,10 @@ Practice : Universal Serial Bus" with the following modifications and additions : Required properties : - - compatible : Should be "nvidia,tegra20-ehci" for USB controllers - used in host mode. - - phy_type : Should be one of "ulpi" or "utmi". - - nvidia,vbus-gpio : If present, specifies a gpio that needs to be - activated for the bus to be powered. - - nvidia,phy : phandle of the PHY instance, the controller is connected to. - -Required properties for phy_type == ulpi: - - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. + - compatible : Should be "nvidia,tegra20-ehci". + - nvidia,phy : phandle of the PHY that the controller is connected to. + - clocks : Contains a single entry which defines the USB controller's clock. Optional properties: - - dr_mode : dual role mode. Indicates the working mode for - nvidia,tegra20-ehci compatible controllers. Can be "host", "peripheral", - or "otg". Default to "host" if not defined for backward compatibility. - host means this is a host controller - peripheral means it is device controller - otg means it can operate as either ("on the go") - - nvidia,has-legacy-mode : boolean indicates whether this controller can - operate in legacy mode (as APX 2500 / 2600). In legacy mode some - registers are accessed through the APB_MISC base address instead of - the USB controller. Since this is a legacy issue it probably does not - warrant a compatible string of its own. - - nvidia,needs-double-reset : boolean is to be set for some of the Tegra2 - USB ports, which need reset twice due to hardware issues. + - nvidia,needs-double-reset : boolean is to be set for some of the Tegra20 + USB ports, which need reset twice due to hardware issues. diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt index 6bdaba2f0aa1..c4c9e9e664aa 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt @@ -4,14 +4,49 @@ The device node for Tegra SOC USB PHY: Required properties : - compatible : Should be "nvidia,tegra20-usb-phy". - - reg : Address and length of the register set for the USB PHY interface. - - phy_type : Should be one of "ulpi" or "utmi". + - reg : Defines the following set of registers, in the order listed: + - The PHY's own register set. + Always present. + - The register set of the PHY containing the UTMI pad control registers. + Present if-and-only-if phy_type == utmi. + - phy_type : Should be one of "utmi", "ulpi" or "hsic". + - clocks : Defines the clocks listed in the clock-names property. + - clock-names : The following clock names must be present: + - reg: The clock needed to access the PHY's own registers. This is the + associated EHCI controller's clock. Always present. + - pll_u: PLL_U. Always present. + - timer: The timeout clock (clk_m). Present if phy_type == utmi. + - utmi-pads: The clock needed to access the UTMI pad control registers. + Present if phy_type == utmi. + - ulpi-link: The clock Tegra provides to the ULPI PHY (cdev2). + Present if phy_type == ulpi, and ULPI link mode is in use. Required properties for phy_type == ulpi: - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. +Required PHY timing params for utmi phy: + - nvidia,hssync-start-delay : Number of 480 Mhz clock cycles to wait before + start of sync launches RxActive + - nvidia,elastic-limit : Variable FIFO Depth of elastic input store + - nvidia,idle-wait-delay : Number of 480 Mhz clock cycles of idle to wait + before declare IDLE. + - nvidia,term-range-adj : Range adjusment on terminations + - nvidia,xcvr-setup : HS driver output control + - nvidia,xcvr-lsfslew : LS falling slew rate control. + - nvidia,xcvr-lsrslew : LS rising slew rate control. + Optional properties: - nvidia,has-legacy-mode : boolean indicates whether this controller can operate in legacy mode (as APX 2500 / 2600). In legacy mode some registers are accessed through the APB_MISC base address instead of - the USB controller.
\ No newline at end of file + the USB controller. + - nvidia,is-wired : boolean. Indicates whether we can do certain kind of power + optimizations for the devices that are always connected. e.g. modem. + - dr_mode : dual role mode. Indicates the working mode for the PHY. Can be + "host", "peripheral", or "otg". Defaults to "host" if not defined. + host means this is a host controller + peripheral means it is device controller + otg means it can operate as either ("on the go") + +Required properties for dr_mode == otg: + - vbus-supply: regulator for VBUS diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt index 6813a715fc7d..8c5be48b43c8 100644 --- a/Documentation/devicetree/bindings/usb/usb3503.txt +++ b/Documentation/devicetree/bindings/usb/usb3503.txt @@ -4,6 +4,10 @@ Required properties: - compatible: Should be "smsc,usb3503". - reg: Specifies the i2c slave address, it should be 0x08. - connect-gpios: Should specify GPIO for connect. +- disabled-ports: Should specify the ports unused. + '1' or '2' or '3' are availe for this property to describe the port + number. 1~3 property values are possible to be desribed. + Do not describe this property if all ports have to be enabled. - intn-gpios: Should specify GPIO for interrupt. - reset-gpios: Should specify GPIO for reset. - initial-mode: Should specify initial mode. @@ -14,6 +18,7 @@ Examples: compatible = "smsc,usb3503"; reg = <0x08>; connect-gpios = <&gpx3 0 1>; + disabled-ports = <2 3>; intn-gpios = <&gpx3 4 1>; reset-gpios = <&gpx3 5 1>; initial-mode = <1>; diff --git a/Documentation/devicetree/bindings/usb/ux500-usb.txt b/Documentation/devicetree/bindings/usb/ux500-usb.txt new file mode 100644 index 000000000000..330d6ec15401 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/ux500-usb.txt @@ -0,0 +1,50 @@ +Ux500 MUSB + +Required properties: + - compatible : Should be "stericsson,db8500-musb" + - reg : Offset and length of registers + - interrupts : Interrupt; mode, number and trigger + - dr_mode : Dual-role; either host mode "host", peripheral mode "peripheral" + or both "otg" + +Optional properties: + - dmas : A list of dma channels; + dma-controller, event-line, fixed-channel, flags + - dma-names : An ordered list of channel names affiliated to the above + +Example: + +usb_per5@a03e0000 { + compatible = "stericsson,db8500-musb", "mentor,musb"; + reg = <0xa03e0000 0x10000>; + interrupts = <0 23 0x4>; + interrupt-names = "mc"; + + dr_mode = "otg"; + + dmas = <&dma 38 0 0x2>, /* Logical - DevToMem */ + <&dma 38 0 0x0>, /* Logical - MemToDev */ + <&dma 37 0 0x2>, /* Logical - DevToMem */ + <&dma 37 0 0x0>, /* Logical - MemToDev */ + <&dma 36 0 0x2>, /* Logical - DevToMem */ + <&dma 36 0 0x0>, /* Logical - MemToDev */ + <&dma 19 0 0x2>, /* Logical - DevToMem */ + <&dma 19 0 0x0>, /* Logical - MemToDev */ + <&dma 18 0 0x2>, /* Logical - DevToMem */ + <&dma 18 0 0x0>, /* Logical - MemToDev */ + <&dma 17 0 0x2>, /* Logical - DevToMem */ + <&dma 17 0 0x0>, /* Logical - MemToDev */ + <&dma 16 0 0x2>, /* Logical - DevToMem */ + <&dma 16 0 0x0>, /* Logical - MemToDev */ + <&dma 39 0 0x2>, /* Logical - DevToMem */ + <&dma 39 0 0x0>; /* Logical - MemToDev */ + + dma-names = "iep_1_9", "oep_1_9", + "iep_2_10", "oep_2_10", + "iep_3_11", "oep_3_11", + "iep_4_12", "oep_4_12", + "iep_5_13", "oep_5_13", + "iep_6_14", "oep_6_14", + "iep_7_15", "oep_7_15", + "iep_8", "oep_8"; +}; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 6931c4348d24..db0457d61682 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -31,6 +31,7 @@ idt Integrated Device Technologies, Inc. img Imagination Technologies Ltd. intercontrol Inter Control Group linux Linux-specific binding +lsi LSI Corp. (LSI Logic) marvell Marvell Technology Group Ltd. maxim Maxim Integrated Products mosaixtech Mosaix Technologies, Inc. @@ -59,6 +60,7 @@ ste ST-Ericsson stericsson ST-Ericsson ti Texas Instruments toshiba Toshiba Corporation +v3 V3 Semiconductor via VIA Technologies, Inc. wlf Wolfson Microelectronics wm Wondermedia Technologies, Inc. diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt index c60da67a5d76..84f10c16cb38 100644 --- a/Documentation/devicetree/bindings/video/exynos_dp.txt +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt @@ -21,6 +21,10 @@ Required properties for dp-controller: of memory mapped region. -interrupts: interrupt combiner values. + -clocks: + from common clock binding: handle to dp clock. + -clock-names: + from common clock binding: Shall be "dp". -interrupt-parent: phandle to Interrupt combiner node. -samsung,color-space: @@ -61,6 +65,8 @@ SOC specific portion: reg = <0x145b0000 0x10000>; interrupts = <10 3>; interrupt-parent = <&combiner>; + clocks = <&clock 342>; + clock-names = "dp"; dptx-phy { reg = <0x10040720>; diff --git a/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt new file mode 100644 index 000000000000..8ffb88e39e76 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt @@ -0,0 +1,19 @@ +ST-Ericsson COH 901 327 Watchdog timer + +Required properties: +- compatible: must be "stericsson,coh901327". +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: the interrupt used for the watchdog timeout warning. + +Optional properties: +- timeout-sec: contains the watchdog timeout in seconds. + +Example: + +watchdog: watchdog@c0012000 { + compatible = "stericsson,coh901327"; + reg = <0xc0012000 0x1000>; + interrupts = <3>; + timeout-sec = <60>; +}; diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 0706d32a61e6..fe7afe225381 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -11,10 +11,8 @@ be able to use diff(1). prototypes: int (*d_revalidate)(struct dentry *, unsigned int); int (*d_weak_revalidate)(struct dentry *, unsigned int); - int (*d_hash)(const struct dentry *, const struct inode *, - struct qstr *); - int (*d_compare)(const struct dentry *, const struct inode *, - const struct dentry *, const struct inode *, + int (*d_hash)(const struct dentry *, struct qstr *); + int (*d_compare)(const struct dentry *, const struct dentry *, unsigned int, const char *, const struct qstr *); int (*d_delete)(struct dentry *); void (*d_release)(struct dentry *); @@ -66,6 +64,7 @@ prototypes: int (*atomic_open)(struct inode *, struct dentry *, struct file *, unsigned open_flag, umode_t create_mode, int *opened); + int (*tmpfile) (struct inode *, struct dentry *, umode_t); locking rules: all may block @@ -93,6 +92,7 @@ removexattr: yes fiemap: no update_time: no atomic_open: yes +tmpfile: no Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on victim. @@ -189,7 +189,7 @@ prototypes: loff_t pos, unsigned len, unsigned copied, struct page *page, void *fsdata); sector_t (*bmap)(struct address_space *, sector_t); - int (*invalidatepage) (struct page *, unsigned long); + void (*invalidatepage) (struct page *, unsigned int, unsigned int); int (*releasepage) (struct page *, int); void (*freepage)(struct page *); int (*direct_IO)(int, struct kiocb *, const struct iovec *iov, @@ -310,8 +310,8 @@ filesystems and by the swapper. The latter will eventually go away. Please, keep it that way and don't breed new callers. ->invalidatepage() is called when the filesystem must attempt to drop -some or all of the buffers from the page when it is being truncated. It -returns zero on success. If ->invalidatepage is zero, the kernel uses +some or all of the buffers from the page when it is being truncated. It +returns zero on success. If ->invalidatepage is zero, the kernel uses block_invalidatepage() instead. ->releasepage() is called when the kernel is about to try to drop the @@ -344,25 +344,38 @@ prototypes: locking rules: - file_lock_lock may block + inode->i_lock may block fl_copy_lock: yes no fl_release_private: maybe no ----------------------- lock_manager_operations --------------------------- prototypes: int (*lm_compare_owner)(struct file_lock *, struct file_lock *); + unsigned long (*lm_owner_key)(struct file_lock *); void (*lm_notify)(struct file_lock *); /* unblock callback */ int (*lm_grant)(struct file_lock *, struct file_lock *, int); void (*lm_break)(struct file_lock *); /* break_lease callback */ int (*lm_change)(struct file_lock **, int); locking rules: - file_lock_lock may block -lm_compare_owner: yes no -lm_notify: yes no -lm_grant: no no -lm_break: yes no -lm_change yes no + + inode->i_lock blocked_lock_lock may block +lm_compare_owner: yes[1] maybe no +lm_owner_key yes[1] yes no +lm_notify: yes yes no +lm_grant: no no no +lm_break: yes no no +lm_change yes no no + +[1]: ->lm_compare_owner and ->lm_owner_key are generally called with +*an* inode->i_lock held. It may not be the i_lock of the inode +associated with either file_lock argument! This is the case with deadlock +detection, since the code has to chase down the owners of locks that may +be entirely unrelated to the one on which the lock is being acquired. +For deadlock detection however, the blocked_lock_lock is also held. The +fact that these locks are held ensures that the file_locks do not +disappear out from under you while doing the comparison or generating an +owner key. --------------------------- buffer_head ----------------------------------- prototypes: @@ -414,7 +427,7 @@ prototypes: ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t); ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t); - int (*readdir) (struct file *, void *, filldir_t); + int (*iterate) (struct file *, struct dir_context *); unsigned int (*poll) (struct file *, struct poll_table_struct *); long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); long (*compat_ioctl) (struct file *, unsigned int, unsigned long); diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index bd3c56c67380..b91e2f26b672 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -98,8 +98,13 @@ Cleaning Overhead MOUNT OPTIONS ================================================================================ -background_gc_off Turn off cleaning operations, namely garbage collection, - triggered in background when I/O subsystem is idle. +background_gc=%s Turn on/off cleaning operations, namely garbage + collection, triggered in background when I/O subsystem is + idle. If background_gc=on, it will turn on the garbage + collection and if background_gc=off, garbage collection + will be truned off. + Default value for this option is on. So garbage + collection is on by default. disable_roll_forward Disable the roll-forward recovery routine discard Issue discard/TRIM commands when a segment is cleaned. no_heap Disable heap-style segment allocation which finds free diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index 4db22f6491e0..206a1bdc7321 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -445,3 +445,9 @@ object doesn't exist. It's remote/distributed ones that might care... [mandatory] FS_REVAL_DOT is gone; if you used to have it, add ->d_weak_revalidate() in your dentry operations instead. +-- +[mandatory] + vfs_readdir() is gone; switch to iterate_dir() instead +-- +[mandatory] + ->readdir() is gone now; switch to ->iterate() diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index bc4b06b3160a..1f0ba30ae47e 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -360,6 +360,8 @@ struct inode_operations { int (*removexattr) (struct dentry *, const char *); void (*update_time)(struct inode *, struct timespec *, int); int (*atomic_open)(struct inode *, struct dentry *, + int (*tmpfile) (struct inode *, struct dentry *, umode_t); +} ____cacheline_aligned; struct file *, unsigned open_flag, umode_t create_mode, int *opened); }; @@ -472,6 +474,9 @@ otherwise noted. component is negative or needs lookup. Cached positive dentries are still handled by f_op->open(). + tmpfile: called in the end of O_TMPFILE open(). Optional, equivalent to + atomically creating, opening and unlinking a file in given directory. + The Address Space Object ======================== @@ -549,7 +554,7 @@ struct address_space_operations ------------------------------- This describes how the VFS can manipulate mapping of a file to page cache in -your filesystem. As of kernel 2.6.22, the following members are defined: +your filesystem. The following members are defined: struct address_space_operations { int (*writepage)(struct page *page, struct writeback_control *wbc); @@ -566,7 +571,7 @@ struct address_space_operations { loff_t pos, unsigned len, unsigned copied, struct page *page, void *fsdata); sector_t (*bmap)(struct address_space *, sector_t); - int (*invalidatepage) (struct page *, unsigned long); + void (*invalidatepage) (struct page *, unsigned int, unsigned int); int (*releasepage) (struct page *, int); void (*freepage)(struct page *); ssize_t (*direct_IO)(int, struct kiocb *, const struct iovec *iov, @@ -685,14 +690,14 @@ struct address_space_operations { invalidatepage: If a page has PagePrivate set, then invalidatepage will be called when part or all of the page is to be removed from the address space. This generally corresponds to either a - truncation or a complete invalidation of the address space - (in the latter case 'offset' will always be 0). - Any private data associated with the page should be updated - to reflect this truncation. If offset is 0, then - the private data should be released, because the page - must be able to be completely discarded. This may be done by - calling the ->releasepage function, but in this case the - release MUST succeed. + truncation, punch hole or a complete invalidation of the address + space (in the latter case 'offset' will always be 0 and 'length' + will be PAGE_CACHE_SIZE). Any private data associated with the page + should be updated to reflect this truncation. If offset is 0 and + length is PAGE_CACHE_SIZE, then the private data should be released, + because the page must be able to be completely discarded. This may + be done by calling the ->releasepage function, but in this case the + release MUST succeed. releasepage: releasepage is called on PagePrivate pages to indicate that the page should be freed if possible. ->releasepage @@ -777,7 +782,7 @@ struct file_operations { ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t); ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t); - int (*readdir) (struct file *, void *, filldir_t); + int (*iterate) (struct file *, struct dir_context *); unsigned int (*poll) (struct file *, struct poll_table_struct *); long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); long (*compat_ioctl) (struct file *, unsigned int, unsigned long); @@ -815,7 +820,7 @@ otherwise noted. aio_write: called by io_submit(2) and other asynchronous I/O operations - readdir: called when the VFS needs to read the directory contents + iterate: called when the VFS needs to read the directory contents poll: called by the VFS when a process wants to check if there is activity on this file and (optionally) go to sleep until there @@ -901,10 +906,8 @@ defined: struct dentry_operations { int (*d_revalidate)(struct dentry *, unsigned int); int (*d_weak_revalidate)(struct dentry *, unsigned int); - int (*d_hash)(const struct dentry *, const struct inode *, - struct qstr *); - int (*d_compare)(const struct dentry *, const struct inode *, - const struct dentry *, const struct inode *, + int (*d_hash)(const struct dentry *, struct qstr *); + int (*d_compare)(const struct dentry *, const struct dentry *, unsigned int, const char *, const struct qstr *); int (*d_delete)(const struct dentry *); void (*d_release)(struct dentry *); @@ -949,25 +952,24 @@ struct dentry_operations { d_hash: called when the VFS adds a dentry to the hash table. The first dentry passed to d_hash is the parent directory that the name is - to be hashed into. The inode is the dentry's inode. + to be hashed into. Same locking and synchronisation rules as d_compare regarding what is safe to dereference etc. d_compare: called to compare a dentry name with a given name. The first dentry is the parent of the dentry to be compared, the second is - the parent's inode, then the dentry and inode (may be NULL) of the - child dentry. len and name string are properties of the dentry to be - compared. qstr is the name to compare it with. + the child dentry. len and name string are properties of the dentry + to be compared. qstr is the name to compare it with. Must be constant and idempotent, and should not take locks if - possible, and should not or store into the dentry or inodes. - Should not dereference pointers outside the dentry or inodes without + possible, and should not or store into the dentry. + Should not dereference pointers outside the dentry without lots of care (eg. d_parent, d_inode, d_name should not be used). However, our vfsmount is pinned, and RCU held, so the dentries and inodes won't disappear, neither will our sb or filesystem module. - ->i_sb and ->d_sb may be used. + ->d_sb may be used. It is a tricky calling convention because it needs to be called under "rcu-walk", ie. without any locks or references on things. diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX new file mode 100644 index 000000000000..431c69570f43 --- /dev/null +++ b/Documentation/fmc/00-INDEX @@ -0,0 +1,38 @@ + +Documentation in this directory comes from sections of the manual we +wrote for the externally-developed fmc-bus package. The complete +manual as of today (2013-02) is available in PDF format at +http://www.ohwr.org/projects/fmc-bus/files + +00-INDEX + - this file. + +FMC-and-SDB.txt + - What are FMC and SDB, basic concepts for this framework + +API.txt + - The functions that are exported by the bus driver + +parameters.txt + - The module parameters + +carrier.txt + - writing a carrier (a device) + +mezzanine.txt + - writing code for your mezzanine (a driver) + +identifiers.txt + - how identification and matching works + +fmc-fakedev.txt + - about drivers/fmc/fmc-fakedev.ko + +fmc-trivial.txt + - about drivers/fmc/fmc-trivial.ko + +fmc-write-eeprom.txt + - about drivers/fmc/fmc-write-eeprom.ko + +fmc-chardev.txt + - about drivers/fmc/fmc-chardev.ko diff --git a/Documentation/fmc/API.txt b/Documentation/fmc/API.txt new file mode 100644 index 000000000000..06b06b92c794 --- /dev/null +++ b/Documentation/fmc/API.txt @@ -0,0 +1,47 @@ +Functions Exported by fmc.ko +**************************** + +The FMC core exports the usual 4 functions that are needed for a bus to +work, and a few more: + + int fmc_driver_register(struct fmc_driver *drv); + void fmc_driver_unregister(struct fmc_driver *drv); + int fmc_device_register(struct fmc_device *fmc); + void fmc_device_unregister(struct fmc_device *fmc); + + int fmc_device_register_n(struct fmc_device **fmc, int n); + void fmc_device_unregister_n(struct fmc_device **fmc, int n); + + uint32_t fmc_readl(struct fmc_device *fmc, int offset); + void fmc_writel(struct fmc_device *fmc, uint32_t val, int off); + void *fmc_get_drvdata(struct fmc_device *fmc); + void fmc_set_drvdata(struct fmc_device *fmc, void *data); + + int fmc_reprogram(struct fmc_device *f, struct fmc_driver *d, char *gw, + int sdb_entry); + +The data structure that describe a device is detailed in *note FMC +Device::, the one that describes a driver is detailed in *note FMC +Driver::. Please note that structures of type fmc_device must be +allocated by the caller, but must not be released after unregistering. +The fmc-bus itself takes care of releasing the structure when their use +count reaches zero - actually, the device model does that in lieu of us. + +The functions to register and unregister n devices are meant to be used +by carriers that host more than one mezzanine. The devices must all be +registered at the same time because if the FPGA is reprogrammed, all +devices in the array are affected. Usually, the driver matching the +first device will reprogram the FPGA, so other devices must know they +are already driven by a reprogrammed FPGA. + +If a carrier hosts slots that are driven by different FPGA devices, it +should register as a group only mezzanines that are driven by the same +FPGA, for the reason outlined above. + +Finally, the fmc_reprogram function calls the reprogram method (see +*note The API Offered by Carriers:: and also scans the memory area for +an SDB tree. You can pass -1 as sdb_entry to disable such scan. +Otherwise, the function fails if no tree is found at the specified +entry point. The function is meant to factorize common code, and by +the time you read this it is already used by the spec-sw and fine-delay +modules. diff --git a/Documentation/fmc/FMC-and-SDB.txt b/Documentation/fmc/FMC-and-SDB.txt new file mode 100644 index 000000000000..fa14e0b24521 --- /dev/null +++ b/Documentation/fmc/FMC-and-SDB.txt @@ -0,0 +1,88 @@ + +FMC (FPGA Mezzanine Card) is the standard we use for our I/O devices, +in the context of White Rabbit and related hardware. + +In our I/O environments we need to write drivers for each mezzanine +card, and such drivers must work regardless of the carrier being used. +To achieve this, we abstract the FMC interface. + +We have a carrier for PCI-E called SPEC and one for VME called SVEC, +but more are planned. Also, we support stand-alone devices (usually +plugged on a SPEC card), controlled through Etherbone, developed by GSI. + +Code and documentation for the FMC bus was born as part of the spec-sw +project, but now it lives in its own project. Other projects, i.e. +software support for the various carriers, should include this as a +submodule. + +The most up to date version of code and documentation is always +available from the repository you can clone from: + + git://ohwr.org/fmc-projects/fmc-bus.git (read-only) + git@ohwr.org:fmc-projects/fmc-bus.git (read-write for developers) + +Selected versions of the documentation, as well as complete tar +archives for selected revisions are placed to the Files section of the +project: `http://www.ohwr.org/projects/fmc-bus/files' + + +What is FMC +*********** + +FMC, as said, stands for "FPGA Mezzanine Card". It is a standard +developed by the VME consortium called VITA (VMEbus International Trade +Association and ratified by ANSI, the American National Standard +Institute. The official documentation is called "ANSI-VITA 57.1". + +The FMC card is an almost square PCB, around 70x75 millimeters, that is +called mezzanine in this document. It usually lives plugged into +another PCB for power supply and control; such bigger circuit board is +called carrier from now on, and a single carrier may host more than one +mezzanine. + +In the typical application the mezzanine is mostly analog while the +carrier is mostly digital, and hosts an FPGA that must be configured to +match the specific mezzanine and the desired application. Thus, you may +need to load different FPGA images to drive different instances of the +same mezzanine. + +FMC, as such, is not a bus in the usual meaning of the term, because +most carriers have only one connector, and carriers with several +connectors have completely separate electrical connections to them. +This package, however, implements a bus as a software abstraction. + + +What is SDB +*********** + +SDB (Self Describing Bus) is a set of data structures that we use for +enumerating the internal structure of an FPGA image. We also use it as +a filesystem inside the FMC EEPROM. + +SDB is not mandatory for use of this FMC kernel bus, but if you have SDB +this package can make good use of it. SDB itself is developed in the +fpga-config-space OHWR project. The link to the repository is +`git://ohwr.org/hdl-core-lib/fpga-config-space.git' and what is used in +this project lives in the sdbfs subdirectory in there. + +SDB support for FMC is described in *note FMC Identification:: and +*note SDB Support:: + + +SDB Support +*********** + +The fmc.ko bus driver exports a few functions to help drivers taking +advantage of the SDB information that may be present in your own FPGA +memory image. + +The module exports the following functions, in the special header +<linux/fmc-sdb.h>. The linux/ prefix in the name is there because we +plan to submit it upstream in the future, and don't want to force +changes on our drivers if that happens. + + int fmc_scan_sdb_tree(struct fmc_device *fmc, unsigned long address); + void fmc_show_sdb_tree(struct fmc_device *fmc); + signed long fmc_find_sdb_device(struct sdb_array *tree, uint64_t vendor, + uint32_t device, unsigned long *sz); + int fmc_free_sdb_tree(struct fmc_device *fmc); diff --git a/Documentation/fmc/carrier.txt b/Documentation/fmc/carrier.txt new file mode 100644 index 000000000000..173f6d65c88d --- /dev/null +++ b/Documentation/fmc/carrier.txt @@ -0,0 +1,311 @@ +FMC Device +********** + +Within the Linux bus framework, the FMC device is created and +registered by the carrier driver. For example, the PCI driver for the +SPEC card fills a data structure for each SPEC that it drives, and +registers an associated FMC device for each card. The SVEC driver can +do exactly the same for the VME carrier (actually, it should do it +twice, because the SVEC carries two FMC mezzanines). Similarly, an +Etherbone driver will be able to register its own FMC devices, offering +communication primitives through frame exchange. + +The contents of the EEPROM within the FMC are used for identification +purposes, i.e. for matching the device with its own driver. For this +reason the device structure includes a complete copy of the EEPROM +(actually, the carrier driver may choose whether or not to return it - +for example we most likely won't have the whole EEPROM available for +Etherbone devices. + +The following listing shows the current structure defining a device. +Please note that all the machinery is in place but some details may +still change in the future. For this reason, there is a version field +at the beginning of the structure. As usual, the minor number will +change for compatible changes (like a new flag) and the major number +will increase when an incompatible change happens (for example, a +change in layout of some fmc data structures). Device writers should +just set it to the value FMC_VERSION, and be ready to get back -EINVAL +at registration time. + + struct fmc_device { + unsigned long version; + unsigned long flags; + struct module *owner; /* char device must pin it */ + struct fmc_fru_id id; /* for EEPROM-based match */ + struct fmc_operations *op; /* carrier-provided */ + int irq; /* according to host bus. 0 == none */ + int eeprom_len; /* Usually 8kB, may be less */ + int eeprom_addr; /* 0x50, 0x52 etc */ + uint8_t *eeprom; /* Full contents or leading part */ + char *carrier_name; /* "SPEC" or similar, for special use */ + void *carrier_data; /* "struct spec *" or equivalent */ + __iomem void *fpga_base; /* May be NULL (Etherbone) */ + __iomem void *slot_base; /* Set by the driver */ + struct fmc_device **devarray; /* Allocated by the bus */ + int slot_id; /* Index in the slot array */ + int nr_slots; /* Number of slots in this carrier */ + unsigned long memlen; /* Used for the char device */ + struct device dev; /* For Linux use */ + struct device *hwdev; /* The underlying hardware device */ + unsigned long sdbfs_entry; + struct sdb_array *sdb; + uint32_t device_id; /* Filled by the device */ + char *mezzanine_name; /* Defaults to ``fmc'' */ + void *mezzanine_data; + }; + +The meaning of most fields is summarized in the code comment above. + +The following fields must be filled by the carrier driver before +registration: + + * version: must be set to FMC_VERSION. + + * owner: set to MODULE_OWNER. + + * op: the operations to act on the device. + + * irq: number for the mezzanine; may be zero. + + * eeprom_len: length of the following array. + + * eeprom_addr: 0x50 for first mezzanine and so on. + + * eeprom: the full content of the I2C EEPROM. + + * carrier_name. + + * carrier_data: a unique pointer for the carrier. + + * fpga_base: the I/O memory address (may be NULL). + + * slot_id: the index of this slot (starting from zero). + + * memlen: if fpga_base is valid, the length of I/O memory. + + * hwdev: to be used in some dev_err() calls. + + * device_id: a slot-specific unique integer number. + + +Please note that the carrier should read its own EEPROM memory before +registering the device, as well as fill all other fields listed above. + +The following fields should not be assigned, because they are filled +later by either the bus or the device driver: + + * flags. + + * fru_id: filled by the bus, parsing the eeprom. + + * slot_base: filled and used by the driver, if useful to it. + + * devarray: an array og all mezzanines driven by a singe FPGA. + + * nr_slots: set by the core at registration time. + + * dev: used by Linux. + + * sdb: FPGA contents, scanned according to driver's directions. + + * sdbfs_entry: SDB entry point in EEPROM: autodetected. + + * mezzanine_data: available for the driver. + + * mezzanine_name: filled by fmc-bus during identification. + + +Note: mezzanine_data may be redundant, because Linux offers the drvdata +approach, so the field may be removed in later versions of this bus +implementation. + +As I write this, she SPEC carrier is already completely functional in +the fmc-bus environment, and is a good reference to look at. + + +The API Offered by Carriers +=========================== + +The carrier provides a number of methods by means of the +`fmc_operations' structure, which currently is defined like this +(again, it is a moving target, please refer to the header rather than +this document): + + struct fmc_operations { + uint32_t (*readl)(struct fmc_device *fmc, int offset); + void (*writel)(struct fmc_device *fmc, uint32_t value, int offset); + int (*reprogram)(struct fmc_device *f, struct fmc_driver *d, char *gw); + int (*validate)(struct fmc_device *fmc, struct fmc_driver *drv); + int (*irq_request)(struct fmc_device *fmc, irq_handler_t h, + char *name, int flags); + void (*irq_ack)(struct fmc_device *fmc); + int (*irq_free)(struct fmc_device *fmc); + int (*gpio_config)(struct fmc_device *fmc, struct fmc_gpio *gpio, + int ngpio); + int (*read_ee)(struct fmc_device *fmc, int pos, void *d, int l); + int (*write_ee)(struct fmc_device *fmc, int pos, const void *d, int l); + }; + +The individual methods perform the following tasks: + +`readl' +`writel' + These functions access FPGA registers by whatever means the + carrier offers. They are not expected to fail, and most of the time + they will just make a memory access to the host bus. If the + carrier provides a fpga_base pointer, the driver may use direct + access through that pointer. For this reason the header offers the + inline functions fmc_readl and fmc_writel that access fpga_base if + the respective method is NULL. A driver that wants to be portable + and efficient should use fmc_readl and fmc_writel. For Etherbone, + or other non-local carriers, error-management is still to be + defined. + +`validate' + Module parameters are used to manage different applications for + two or more boards of the same kind. Validation is based on the + busid module parameter, if provided, and returns the matching + index in the associated array. See *note Module Parameters:: in in + doubt. If no match is found, `-ENOENT' is returned; if the user + didn't pass `busid=', all devices will pass validation. The value + returned by the validate method can be used as index into other + parameters (for example, some drivers use the `lm32=' parameter in + this way). Such "generic parameters" are documented in *note + Module Parameters::, below. The validate method is used by + `fmc-trivial.ko', described in *note fmc-trivial::. + +`reprogram' + The carrier enumerates FMC devices by loading a standard (or + golden) FPGA binary that allows EEPROM access. Each driver, then, + will need to reprogram the FPGA by calling this function. If the + name argument is NULL, the carrier should reprogram the golden + binary. If the gateware name has been overridden through module + parameters (in a carrier-specific way) the file loaded will match + the parameters. Per-device gateware names can be specified using + the `gateware=' parameter, see *note Module Parameters::. Note: + Clients should call rhe new helper, fmc_reprogram, which both + calls this method and parse the SDB tree of the FPGA. + +`irq_request' +`irq_ack' +`irq_free' + Interrupt management is carrier-specific, so it is abstracted as + operations. The interrupt number is listed in the device + structure, and for the mezzanine driver the number is only + informative. The handler will receive the fmc pointer as dev_id; + the flags argument is passed to the Linux request_irq function, + but fmc-specific flags may be added in the future. You'll most + likely want to pass the `IRQF_SHARED' flag. + +`gpio_config' + The method allows to configure a GPIO pin in the carrier, and read + its current value if it is configured as input. See *note The GPIO + Abstraction:: for details. + +`read_ee' +`write_ee' + Read or write the EEPROM. The functions are expected to be only + called before reprogramming and the carrier should refuse them + with `ENODEV' after reprogramming. The offset is expected to be + within 8kB (the current size), but addresses up to 1MB are + reserved to fit bigger I2C devices in the future. Carriers may + offer access to other internal flash memories using these same + methods: for example the SPEC driver may define that its carrier + I2C memory is seen at offset 1M and the internal SPI flash is seen + at offset 16M. This multiplexing of several flash memories in the + same address space is is carrier-specific and should only be used + by a driver that has verified the `carrier_name' field. + + + +The GPIO Abstraction +==================== + +Support for GPIO pins in the fmc-bus environment is not very +straightforward and deserves special discussion. + +While the general idea of a carrier-independent driver seems to fly, +configuration of specific signals within the carrier needs at least +some knowledge of the carrier itself. For this reason, the specific +driver can request to configure carrier-specific GPIO pins, numbered +from 0 to at most 4095. Configuration is performed by passing a +pointer to an array of struct fmc_gpio items, as well as the length of +the array. This is the data structure: + + struct fmc_gpio { + char *carrier_name; + int gpio; + int _gpio; /* internal use by the carrier */ + int mode; /* GPIOF_DIR_OUT etc, from <linux/gpio.h> */ + int irqmode; /* IRQF_TRIGGER_LOW and so on */ + }; + +By specifying a carrier_name for each pin, the driver may access +different pins in different carriers. The gpio_config method is +expected to return the number of pins successfully configured, ignoring +requests for other carriers. However, if no pin is configured (because +no structure at all refers to the current carrier_name), the operation +returns an error so the caller will know that it is running under a +yet-unsupported carrier. + +So, for example, a driver that has been developed and tested on both +the SPEC and the SVEC may request configuration of two different GPIO +pins, and expect one such configuration to succeed - if none succeeds +it most likely means that the current carrier is a still-unknown one. + +If, however, your GPIO pin has a specific known role, you can pass a +special number in the gpio field, using one of the following macros: + + #define FMC_GPIO_RAW(x) (x) /* 4096 of them */ + #define FMC_GPIO_IRQ(x) ((x) + 0x1000) /* 256 of them */ + #define FMC_GPIO_LED(x) ((x) + 0x1100) /* 256 of them */ + #define FMC_GPIO_KEY(x) ((x) + 0x1200) /* 256 of them */ + #define FMC_GPIO_TP(x) ((x) + 0x1300) /* 256 of them */ + #define FMC_GPIO_USER(x) ((x) + 0x1400) /* 256 of them */ + +Use of virtual GPIO numbers (anything but FMC_GPIO_RAW) is allowed +provided the carrier_name field in the data structure is left +unspecified (NULL). Each carrier is responsible for providing a mapping +between virtual and physical GPIO numbers. The carrier may then use the +_gpio field to cache the result of this mapping. + +All carriers must map their I/O lines to the sets above starting from +zero. The SPEC, for example, maps interrupt pins 0 and 1, and test +points 0 through 3 (even if the test points on the PCB are called +5,6,7,8). + +If, for example, a driver requires a free LED and a test point (for a +scope probe to be plugged at some point during development) it may ask +for FMC_GPIO_LED(0) and FMC_GPIO_TP(0). Each carrier will provide +suitable GPIO pins. Clearly, the person running the drivers will know +the order used by the specific carrier driver in assigning leds and +testpoints, so to make a carrier-dependent use of the diagnostic tools. + +In theory, some form of autodetection should be possible: a driver like +the wr-nic (which uses IRQ(1) on the SPEC card) should configure +IRQ(0), make a test with software-generated interrupts and configure +IRQ(1) if the test fails. This probing step should be used because even +if the wr-nic gateware is known to use IRQ1 on the SPEC, the driver +should be carrier-independent and thus use IRQ(0) as a first bet - +actually, the knowledge that IRQ0 may fail is carrier-dependent +information, but using it doesn't make the driver unsuitable for other +carriers. + +The return value of gpio_config is defined as follows: + + * If no pin in the array can be used by the carrier, `-ENODEV'. + + * If at least one virtual GPIO number cannot be mapped, `-ENOENT'. + + * On success, 0 or positive. The value returned is the number of + high input bits (if no input is configured, the value for success + is 0). + +While I admit the procedure is not completely straightforward, it +allows configuration, input and output with a single carrier operation. +Given the typical use case of FMC devices, GPIO operations are not +expected to ever by in hot paths, and GPIO access so fare has only been +used to configure the interrupt pin, mode and polarity. Especially +reading inputs is not expected to be common. If your device has GPIO +capabilities in the hot path, you should consider using the kernel's +GPIO mechanisms. diff --git a/Documentation/fmc/fmc-chardev.txt b/Documentation/fmc/fmc-chardev.txt new file mode 100644 index 000000000000..d9ccb278e597 --- /dev/null +++ b/Documentation/fmc/fmc-chardev.txt @@ -0,0 +1,64 @@ +fmc-chardev +=========== + +This is a simple generic driver, that allows user access by means of a +character device (actually, one for each mezzanine it takes hold of). + +The char device is created as a misc device. Its name in /dev (as +created by udev) is the same name as the underlying FMC device. Thus, +the name can be a silly fmc-0000 look-alike if the device has no +identifiers nor bus_id, a more specific fmc-0400 if the device has a +bus-specific address but no associated name, or something like +fdelay-0400 if the FMC core can rely on both a mezzanine name and a bus +address. + +Currently the driver only supports read and write: you can lseek to the +desired address and read or write a register. + +The driver assumes all registers are 32-bit in size, and only accepts a +single read or write per system call. However, as a result of Unix read +and write semantics, users can simply fread or fwrite bigger areas in +order to dump or store bigger memory areas. + +There is currently no support for mmap, user-space interrupt management +and DMA buffers. They may be added in later versions, if the need +arises. + +The example below shows raw access to a SPEC card programmed with its +golden FPGA file, that features an SDB structure at offset 256 - i.e. +64 words. The mezzanine's EEPROM in this case is not programmed, so the +default name is fmc-<bus><devfn>, and there are two cards in the system: + + spusa.root# insmod fmc-chardev.ko + [ 1073.339332] spec 0000:02:00.0: Driver has no ID: matches all + [ 1073.345051] spec 0000:02:00.0: Created misc device "fmc-0200" + [ 1073.350821] spec 0000:04:00.0: Driver has no ID: matches all + [ 1073.356525] spec 0000:04:00.0: Created misc device "fmc-0400" + spusa.root# ls -l /dev/fmc* + crw------- 1 root root 10, 58 Nov 20 19:23 /dev/fmc-0200 + crw------- 1 root root 10, 57 Nov 20 19:23 /dev/fmc-0400 + spusa.root# dd bs=4 skip=64 count=1 if=/dev/fmc-0200 2> /dev/null | od -t x1z + 0000000 2d 42 44 53 >-BDS< + 0000004 + +The simple program tools/fmc-mem in this package can access an FMC char +device and read or write a word or a whole area. Actually, the program +is not specific to FMC at all, it just uses lseek, read and write. + +Its first argument is the device name, the second the offset, the third +(if any) the value to write and the optional last argument that must +begin with "+" is the number of bytes to read or write. In case of +repeated reading data is written to stdout; repeated writes read from +stdin and the value argument is ignored. + +The following examples show reading the SDB magic number and the first +SDB record from a SPEC device programmed with its golden image: + + spusa.root# ./fmc-mem /dev/fmc-0200 100 + 5344422d + spusa.root# ./fmc-mem /dev/fmc-0200 100 +40 | od -Ax -t x1z + 000000 2d 42 44 53 00 01 02 00 00 00 00 00 00 00 00 00 >-BDS............< + 000010 00 00 00 00 ff 01 00 00 00 00 00 00 51 06 00 00 >............Q...< + 000020 c9 42 a5 e6 02 00 00 00 11 05 12 20 2d 34 42 57 >.B......... -4BW< + 000030 73 6f 72 43 72 61 62 73 49 53 47 2d 00 20 20 20 >sorCrabsISG-. < + 000040 diff --git a/Documentation/fmc/fmc-fakedev.txt b/Documentation/fmc/fmc-fakedev.txt new file mode 100644 index 000000000000..e85b74a4ae30 --- /dev/null +++ b/Documentation/fmc/fmc-fakedev.txt @@ -0,0 +1,36 @@ +fmc-fakedev +=========== + +This package includes a software-only device, called fmc-fakedev, which +is able to register up to 4 mezzanines (by default it registers one). +Unlike the SPEC driver, which creates an FMC device for each PCI cards +it manages, this module creates a single instance of its set of +mezzanines. + +It is meant as the simplest possible example of how a driver should be +written, and it includes a fake EEPROM image (built using the tools +described in *note FMC Identification::),, which by default is +replicated for each fake mezzanine. + +You can also use this device to verify the match algorithms, by asking +it to test your own EEPROM image. You can provide the image by means of +the eeprom= module parameter: the new EEPROM image is loaded, as usual, +by means of the firmware loader. This example shows the defaults and a +custom EEPROM image: + + spusa.root# insmod fmc-fakedev.ko + [ 99.971247] fake-fmc-carrier: mezzanine 0 + [ 99.975393] Manufacturer: fake-vendor + [ 99.979624] Product name: fake-design-for-testing + spusa.root# rmmod fmc-fakedev + spusa.root# insmod fmc-fakedev.ko eeprom=fdelay-eeprom.bin + [ 121.447464] fake-fmc-carrier: Mezzanine 0: eeprom "fdelay-eeprom.bin" + [ 121.462725] fake-fmc-carrier: mezzanine 0 + [ 121.466858] Manufacturer: CERN + [ 121.470477] Product name: FmcDelay1ns4cha + spusa.root# rmmod fmc-fakedev + +After loading the device, you can use the write_ee method do modify its +own internal fake EEPROM: whenever the image is overwritten starting at +offset 0, the module will unregister and register again the FMC device. +This is shown in fmc-write-eeprom.txt diff --git a/Documentation/fmc/fmc-trivial.txt b/Documentation/fmc/fmc-trivial.txt new file mode 100644 index 000000000000..d1910bc67159 --- /dev/null +++ b/Documentation/fmc/fmc-trivial.txt @@ -0,0 +1,17 @@ +fmc-trivial +=========== + +The simple module fmc-trivial is just a simple client that registers an +interrupt handler. I used it to verify the basic mechanism of the FMC +bus and how interrupts worked. + +The module implements the generic FMC parameters, so it can program a +different gateware file in each card. The whole list of parameters it +accepts are: + +`busid=' +`gateware=' + Generic parameters. See mezzanine.txt + + +This driver is worth reading, in my opinion. diff --git a/Documentation/fmc/fmc-write-eeprom.txt b/Documentation/fmc/fmc-write-eeprom.txt new file mode 100644 index 000000000000..44a3bc678bf0 --- /dev/null +++ b/Documentation/fmc/fmc-write-eeprom.txt @@ -0,0 +1,125 @@ +fmc-write-eeprom +================ + +This module is designed to load a binary file from /lib/firmware and to +write it to the internal EEPROM of the mezzanine card. This driver uses +the `busid' generic parameter. + +Overwriting the EEPROM is not something you should do daily, and it is +expected to only happen during manufacturing. For this reason, the +module makes it unlikely for the random user to change a working EEPROM. + +The module takes the following measures: + + * It accepts a `file=' argument (within /lib/firmware) and if no + such argument is received, it doesn't write anything to EEPROM + (i.e. there is no default file name). + + * If the file name ends with `.bin' it is written verbatim starting + at offset 0. + + * If the file name ends with `.tlv' it is interpreted as + type-length-value (i.e., it allows writev(2)-like operation). + + * If the file name doesn't match any of the patterns above, it is + ignored and no write is performed. + + * Only cards listed with `busid=' are written to. If no busid is + specified, no programming is done (and the probe function of the + driver will fail). + + +Each TLV tuple is formatted in this way: the header is 5 bytes, +followed by data. The first byte is `w' for write, the next two bytes +represent the address, in little-endian byte order, and the next two +represent the data length, in little-endian order. The length does not +include the header (it is the actual number of bytes to be written). + +This is a real example: that writes 5 bytes at position 0x110: + + spusa.root# od -t x1 -Ax /lib/firmware/try.tlv + 000000 77 10 01 05 00 30 31 32 33 34 + 00000a + spusa.root# insmod /tmp/fmc-write-eeprom.ko busid=0x0200 file=try.tlv + [19983.391498] spec 0000:03:00.0: write 5 bytes at 0x0110 + [19983.414615] spec 0000:03:00.0: write_eeprom: success + +Please note that you'll most likely want to use SDBFS to build your +EEPROM image, at least if your mezzanines are being used in the White +Rabbit environment. For this reason the TLV format is not expected to +be used much and is not expected to be developed further. + +If you want to try reflashing fake EEPROM devices, you can use the +fmc-fakedev.ko module (see *note fmc-fakedev::). Whenever you change +the image starting at offset 0, it will deregister and register again +after two seconds. Please note, however, that if fmc-write-eeprom is +still loaded, the system will associate it to the new device, which +will be reprogrammed and thus will be unloaded after two seconds. The +following example removes the module after it reflashed fakedev the +first time. + + spusa.root# insmod fmc-fakedev.ko + [ 72.984733] fake-fmc: Manufacturer: fake-vendor + [ 72.989434] fake-fmc: Product name: fake-design-for-testing + spusa.root# insmod fmc-write-eeprom.ko busid=0 file=fdelay-eeprom.bin; \ + rmmod fmc-write-eeprom + [ 130.874098] fake-fmc: Matching a generic driver (no ID) + [ 130.887845] fake-fmc: programming 6155 bytes + [ 130.894567] fake-fmc: write_eeprom: success + [ 132.895794] fake-fmc: Manufacturer: CERN + [ 132.899872] fake-fmc: Product name: FmcDelay1ns4cha + + +Writing to the EEPROM +===================== + +Once you have created a binary file for your EEPROM, you can write it +to the storage medium using the fmc-write-eeprom (See *note +fmc-write-eeprom::, while relying on a carrier driver. The procedure +here shown here uses the SPEC driver +(`http://www.ohwr.org/projects/spec-sw'). + +The example assumes no driver is already loaded (actually, I unloaded +them by hand as everything loads automatically at boot time after you +installed the modules), and shows kernel messages together with +commands. Here the prompt is spusa.root# and two SPEC cards are plugged +in the system. + + spusa.root# insmod fmc.ko + spusa.root# insmod spec.ko + [13972.382818] spec 0000:02:00.0: probe for device 0002:0000 + [13972.392773] spec 0000:02:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes + [13972.591388] spec 0000:02:00.0: FPGA programming successful + [13972.883011] spec 0000:02:00.0: EEPROM has no FRU information + [13972.888719] spec 0000:02:00.0: No device_id filled, using index + [13972.894676] spec 0000:02:00.0: No mezzanine_name found + [13972.899863] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init + [13972.906578] spec 0000:04:00.0: probe for device 0004:0000 + [13972.916509] spec 0000:04:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes + [13973.115096] spec 0000:04:00.0: FPGA programming successful + [13973.401798] spec 0000:04:00.0: EEPROM has no FRU information + [13973.407474] spec 0000:04:00.0: No device_id filled, using index + [13973.413417] spec 0000:04:00.0: No mezzanine_name found + [13973.418600] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init + spusa.root# ls /sys/bus/fmc/devices + fmc-0000 fmc-0001 + spusa.root# insmod fmc-write-eeprom.ko busid=0x0200 file=fdelay-eeprom.bin + [14103.966259] spec 0000:02:00.0: Matching an generic driver (no ID) + [14103.975519] spec 0000:02:00.0: programming 6155 bytes + [14126.373762] spec 0000:02:00.0: write_eeprom: success + [14126.378770] spec 0000:04:00.0: Matching an generic driver (no ID) + [14126.384903] spec 0000:04:00.0: fmc_write_eeprom: no filename given: not programming + [14126.392600] fmc_write_eeprom: probe of fmc-0001 failed with error -2 + +Reading back the EEPROM +======================= + +In order to read back the binary content of the EEPROM of your +mezzanine device, the bus creates a read-only sysfs file called eeprom +for each mezzanine it knows about: + + spusa.root# cd /sys/bus/fmc/devices; ls -l */eeprom + -r--r--r-- 1 root root 8192 Apr 9 16:53 FmcDelay1ns4cha-f001/eeprom + -r--r--r-- 1 root root 8192 Apr 9 17:19 fake-design-for-testing-f002/eeprom + -r--r--r-- 1 root root 8192 Apr 9 17:19 fake-design-for-testing-f003/eeprom + -r--r--r-- 1 root root 8192 Apr 9 17:19 fmc-f004/eeprom diff --git a/Documentation/fmc/identifiers.txt b/Documentation/fmc/identifiers.txt new file mode 100644 index 000000000000..3bb577ff0d52 --- /dev/null +++ b/Documentation/fmc/identifiers.txt @@ -0,0 +1,168 @@ +FMC Identification +****************** + +The FMC standard requires every compliant mezzanine to carry +identification information in an I2C EEPROM. The information must be +laid out according to the "IPMI Platform Management FRU Information", +where IPMI is a lie I'd better not expand, and FRU means "Field +Replaceable Unit". + +The FRU information is an intricate unreadable binary blob that must +live at offset 0 of the EEPROM, and typically extends for a few hundred +bytes. The standard allows the application to use all the remaining +storage area of the EEPROM as it wants. + +This chapter explains how to create your own EEPROM image and how to +write it in your mezzanine, as well as how devices and drivers are +paired at run time. EEPROM programming uses tools that are part of this +package and SDB (part of the fpga-config-space package). + +The first sections are only interesting for manufacturers who need to +write the EEPROM. If you are just a software developer writing an FMC +device or driver, you may jump straight to *note SDB Support::. + + +Building the FRU Structure +========================== + +If you want to know the internals of the FRU structure and despair, you +can retrieve the document from +`http://download.intel.com/design/servers/ipmi/FRU1011.pdf' . The +standard is awful and difficult without reason, so we only support the +minimum mandatory subset - we create a simple structure and parse it +back at run time, but we are not able to either generate or parse more +arcane features like non-english languages and 6-bit text. If you need +more items of the FRU standard for your boards, please submit patches. + +This package includes the Python script that Matthieu Cattin wrote to +generate the FRU binary blob, based on an helper libipmi by Manohar +Vanga and Matthieu himself. I changed the test script to receive +parameters from the command line or from the environment (the command +line takes precedence) + +To make a long story short, in order to build a standard-compliant +binary file to be burned in your EEPROM, you need the following items: + + Environment Opt Official Name Default +--------------------------------------------------------------------- + FRU_VENDOR -v "Board Manufacturer" fmc-example + FRU_NAME -n "Board Product Name" mezzanine + FRU_SERIAL -s `Board Serial Number" 0001 + FRU_PART -p "Board Part Number" sample-part + FRU_OUTPUT -o not applicable /dev/stdout + +The "Official Name" above is what you find in the FRU official +documentation, chapter 11, page 7 ("Board Info Area Format"). The +output option is used to save the generated binary to a specific file +name instead of stdout. + +You can pass the items to the FRU generator either in the environment +or on the command line. This package has currently no support for +specifying power consumption or such stuff, but I plan to add it as +soon as I find some time for that. + +FIXME: consumption etc for FRU are here or in PTS? + +The following example creates a binary image for a specific board: + + ./tools/fru-generator -v CERN -n FmcAdc100m14b4cha \ + -s HCCFFIA___-CR000003 -p EDA-02063-V5-0 > eeprom.bin + +The following example shows a script that builds several binary EEPROM +images for a series of boards, changing the serial number for each of +them. The script uses a mix of environment variables and command line +options, and uses the same string patterns shown above. + + #!/bin/sh + + export FRU_VENDOR="CERN" + export FRU_NAME="FmcAdc100m14b4cha" + export FRU_PART="EDA-02063-V5-0" + + serial="HCCFFIA___-CR" + + for number in $(seq 1 50); do + # build number-string "ns" + ns="$(printf %06d $number)" + ./fru-generator -s "${serial}${ns}" > eeprom-${ns}.bin + done + + +Using SDB-FS in the EEPROM +========================== + +If you want to use SDB as a filesystem in the EEPROM device within the +mezzanine, you should create one such filesystem using gensdbfs, from +the fpga-config-space package on OHWR. + +By using an SBD filesystem you can cluster several files in a single +EEPROM, so both the host system and a soft-core running in the FPGA (if +any) can access extra production-time information. + +We chose to use SDB as a storage filesystem because the format is very +simple, and both the host system and the soft-core will likely already +include support code for such format. The SDB library offered by the +fpga-config-space is less than 1kB under LM32, so it proves quite up to +the task. + +The SDB entry point (which acts as a directory listing) cannot live at +offset zero in the flash device, because the FRU information must live +there. To avoid wasting precious storage space while still allowing +for more-than-minimal FRU structures, the fmc.ko will look for the SDB +record at address 256, 512 and 1024. + +In order to generate the complete EEPROM image you'll need a +configuration file for gensdbfs: you tell the program where to place +the sdb entry point, and you must force the FRU data file to be placed +at the beginning of the storage device. If needed, you can also place +other files at a special offset (we sometimes do it for backward +compatibility with drivers we wrote before implementing SDB for flash +memory). + +The directory tools/sdbfs of this package includes a well-commented +example that you may want to use as a starting point (the comments are +in the file called -SDB-CONFIG-). Reading documentation for gensdbfs +is a suggested first step anyways. + +This package (generic FMC bus support) only accesses two files in the +EEPROM: the FRU information, at offset zero, with a suggested filename +of IPMI-FRU and the short name for the mezzanine, in a file called +name. The IPMI-FRU name is not mandatory, but a strongly suggested +choice; the name filename is mandatory, because this is the preferred +short name used by the FMC core. For example, a name of "fdelay" may +supplement a Product Name like "FmcDelay1ns4cha" - exactly as +demonstrated in `tools/sdbfs'. + +Note: SDB access to flash memory is not yet supported, so the short +name currently in use is just the "Product Name" FRU string. + +The example in tools/sdbfs includes an extra file, that is needed by +the fine-delay driver, and must live at a known address of 0x1800. By +running gensdbfs on that directory you can output your binary EEPROM +image (here below spusa$ is the shell prompt): + + spusa$ ../fru-generator -v CERN -n FmcDelay1ns4cha -s proto-0 \ + -p EDA-02267-V3 > IPMI-FRU + spusa$ ls -l + total 16 + -rw-rw-r-- 1 rubini staff 975 Nov 19 18:08 --SDB-CONFIG-- + -rw-rw-r-- 1 rubini staff 216 Nov 19 18:13 IPMI-FRU + -rw-rw-r-- 1 rubini staff 11 Nov 19 18:04 fd-calib + -rw-rw-r-- 1 rubini staff 7 Nov 19 18:04 name + spusa$ sudo gensdbfs . /lib/firmware/fdelay-eeprom.bin + spusa$ sdb-read -l -e 0x100 /lib/firmware/fdelay-eeprom.bin + /home/rubini/wip/sdbfs/userspace/sdb-read: listing format is to be defined + 46696c6544617461:2e202020 00000100-000018ff . + 46696c6544617461:6e616d65 00000200-00000206 name + 46696c6544617461:66642d63 00001800-000018ff fd-calib + 46696c6544617461:49504d49 00000000-000000d7 IPMI-FRU + spusa$ ../fru-dump /lib/firmware/fdelay-eeprom.bin + /lib/firmware/fdelay-eeprom.bin: manufacturer: CERN + /lib/firmware/fdelay-eeprom.bin: product-name: FmcDelay1ns4cha + /lib/firmware/fdelay-eeprom.bin: serial-number: proto-0 + /lib/firmware/fdelay-eeprom.bin: part-number: EDA-02267-V3 + +As expected, the output file is both a proper sdbfs object and an IPMI +FRU information blob. The fd-calib file lives at offset 0x1800 and is +over-allocated to 256 bytes, according to the configuration file for +gensdbfs. diff --git a/Documentation/fmc/mezzanine.txt b/Documentation/fmc/mezzanine.txt new file mode 100644 index 000000000000..87910dbfc91e --- /dev/null +++ b/Documentation/fmc/mezzanine.txt @@ -0,0 +1,123 @@ +FMC Driver +********** + +An FMC driver is concerned with the specific mezzanine and associated +gateware. As such, it is expected to be independent of the carrier +being used: it will perform I/O accesses only by means of +carrier-provided functions. + +The matching between device and driver is based on the content of the +EEPROM (as mandated by the FMC standard) or by the actual cores +configured in the FPGA; the latter technique is used when the FPGA is +already programmed when the device is registered to the bus core. + +In some special cases it is possible for a driver to directly access +FPGA registers, by means of the `fpga_base' field of the device +structure. This may be needed for high-bandwidth peripherals like fast +ADC cards. If the device module registered a remote device (for example +by means of Etherbone), the `fpga_base' pointer will be NULL. +Therefore, drivers must be ready to deal with NULL base pointers, and +fail gracefully. Most driver, however, are not expected to access the +pointer directly but run fmc_readl and fmc_writel instead, which will +work in any case. + +In even more special cases, the driver may access carrier-specific +functionality: the `carrier_name' string allows the driver to check +which is the current carrier and make use of the `carrier_data' +pointer. We chose to use carrier names rather than numeric identifiers +for greater flexibility, but also to avoid a central registry within +the `fmc.h' file - we hope other users will exploit our framework with +their own carriers. An example use of carrier names is in GPIO setup +(see *note The GPIO Abstraction::), although the name match is not +expected to be performed by the driver. If you depend on specific +carriers, please check the carrier name and fail gracefully if your +driver finds it is running in a yet-unknown-to-it environment. + + +ID Table +======== + +Like most other Linux drivers, and FMC driver must list all the devices +which it is able to drive. This is usually done by means of a device +table, but in FMC we can match hardware based either on the contents of +their EEPROM or on the actual FPGA cores that can be enumerated. +Therefore, we have two tables of identifiers. + +Matching of FRU information depends on two names, the manufacturer (or +vendor) and the device (see *note FMC Identification::); for +flexibility during production (i.e. before writing to the EEPROM) the +bus supports a catch-all driver that specifies NULL strings. For this +reason, the table is specified as pointer-and-length, not a a +null-terminated array - the entry with NULL names can be a valid entry. + +Matching on FPGA cores depends on two numeric fields: the 64-bit vendor +number and the 32-bit device number. Support for matching based on +class is not yet implemented. Each device is expected to be uniquely +identified by an array of cores (it matches if all of the cores are +instantiated), and for consistency the list is passed as +pointer-and-length. Several similar devices can be driven by the same +driver, and thus the driver specifies and array of such arrays. + +The complete set of involved data structures is thus the following: + + struct fmc_fru_id { char *manufacturer; char *product_name; }; + struct fmc_sdb_one_id { uint64_t vendor; uint32_t device; }; + struct fmc_sdb_id { struct fmc_sdb_one_id *cores; int cores_nr; }; + + struct fmc_device_id { + struct fmc_fru_id *fru_id; int fru_id_nr; + struct fmc_sdb_id *sdb_id; int sdb_id_nr; + }; + +A better reference, with full explanation, is the <linux/fmc.h> header. + + +Module Parameters +================= + +Most of the FMC drivers need the same set of kernel parameters. This +package includes support to implement common parameters by means of +fields in the `fmc_driver' structure and simple macro definitions. + +The parameters are carrier-specific, in that they rely on the busid +concept, that varies among carriers. For the SPEC, the identifier is a +PCI bus and devfn number, 16 bits wide in total; drivers for other +carriers will most likely offer something similar but not identical, +and some code duplication is unavoidable. + +This is the list of parameters that are common to several modules to +see how they are actually used, please look at spec-trivial.c. + +`busid=' + This is an array of integers, listing carrier-specific + identification numbers. For PIC, for example, `0x0400' represents + bus 4, slot 0. If any such ID is specified, the driver will only + accept to drive cards that appear in the list (even if the FMC ID + matches). This is accomplished by the validate carrier method. + +`gateware=' + The argument is an array of strings. If no busid= is specified, + the first string of gateware= is used for all cards; otherwise the + identifiers and gateware names are paired one by one, in the order + specified. + +`show_sdb=' + For modules supporting it, this parameter asks to show the SDB + internal structure by means of kernel messages. It is disabled by + default because those lines tend to hide more important messages, + if you look at the system console while loading the drivers. + Note: the parameter is being obsoleted, because fmc.ko itself now + supports dump_sdb= that applies to every client driver. + + +For example, if you are using the trivial driver to load two different +gateware files to two different cards, you can use the following +parameters to load different binaries to the cards, after looking up +the PCI identifiers. This has been tested with a SPEC carrier. + + insmod fmc-trivial.ko \ + busid=0x0200,0x0400 \ + gateware=fmc/fine-delay.bin,fmc/simple-dio.bin + +Please note that not all sub-modules support all of those parameters. +You can use modinfo to check what is supported by each module. diff --git a/Documentation/fmc/parameters.txt b/Documentation/fmc/parameters.txt new file mode 100644 index 000000000000..59edf088e3a4 --- /dev/null +++ b/Documentation/fmc/parameters.txt @@ -0,0 +1,56 @@ +Module Parameters in fmc.ko +*************************** + +The core driver receives two module parameters, meant to help debugging +client modules. Both parameters can be modified by writing to +/sys/module/fmc/parameters/, because they are used when client drivers +are devices are registered, not when fmc.ko is loaded. + +`dump_eeprom=' + If not zero, the parameter asks the bus controller to dump the + EEPROM of any device that is registered, using printk. + +`dump_sdb=' + If not zero, the parameter prints the SDB tree of every FPGA it is + loaded by fmc_reprogram(). If greater than one, it asks to dump + the binary content of SDB records. This currently only dumps the + top-level SDB array, though. + + +EEPROM dumping avoids repeating lines, since most of the contents is +usually empty and all bits are one or zero. This is an example of the +output: + + [ 6625.850480] spec 0000:02:00.0: FPGA programming successful + [ 6626.139949] spec 0000:02:00.0: Manufacturer: CERN + [ 6626.144666] spec 0000:02:00.0: Product name: FmcDelay1ns4cha + [ 6626.150370] FMC: mezzanine 0: 0000:02:00.0 on SPEC + [ 6626.155179] FMC: dumping eeprom 0x2000 (8192) bytes + [ 6626.160087] 0000: 01 00 00 01 00 0b 00 f3 01 0a 00 a5 85 87 c4 43 + [ 6626.167069] 0010: 45 52 4e cf 46 6d 63 44 65 6c 61 79 31 6e 73 34 + [ 6626.174019] 0020: 63 68 61 c7 70 72 6f 74 6f 2d 30 cc 45 44 41 2d + [ 6626.180975] 0030: 30 32 32 36 37 2d 56 33 da 32 30 31 32 2d 31 31 + [...] + [ 6626.371366] 0200: 66 64 65 6c 61 79 0a 00 00 00 00 00 00 00 00 00 + [ 6626.378359] 0210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + [ 6626.385361] [...] + [ 6626.387308] 1800: 70 6c 61 63 65 68 6f 6c 64 65 72 ff ff ff ff ff + [ 6626.394259] 1810: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff + [ 6626.401250] [...] + +The dump of SDB looks like the following; the example shows the simple +golden gateware for the SPEC card, removing the leading timestamps to +fit the page: + + spec 0000:02:00.0: SDB: 00000651:e6a542c9 WB4-Crossbar-GSI + spec 0000:02:00.0: SDB: 0000ce42:ff07fc47 WR-Periph-Syscon (00000000-000000ff) + FMC: mezzanine 0: 0000:02:00.0 on SPEC + FMC: poor dump of sdb first level: + 0000: 53 44 42 2d 00 02 01 00 00 00 00 00 00 00 00 00 + 0010: 00 00 00 00 00 00 01 ff 00 00 00 00 00 00 06 51 + 0020: e6 a5 42 c9 00 00 00 02 20 12 05 11 57 42 34 2d + 0030: 43 72 6f 73 73 62 61 72 2d 47 53 49 20 20 20 00 + 0040: 00 00 01 01 00 00 00 07 00 00 00 00 00 00 00 00 + 0050: 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 ce 42 + 0060: ff 07 fc 47 00 00 00 01 20 12 03 05 57 52 2d 50 + 0070: 65 72 69 70 68 2d 53 79 73 63 6f 6e 20 20 20 01 diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches index 843751c41fea..46286460462b 100644 --- a/Documentation/hwmon/submitting-patches +++ b/Documentation/hwmon/submitting-patches @@ -27,8 +27,7 @@ increase the chances of your change being accepted. explicitly below the patch header. * If your patch (or the driver) is affected by configuration options such as - CONFIG_SMP or CONFIG_HOTPLUG, make sure it compiles for all configuration - variants. + CONFIG_SMP, make sure it compiles for all configuration variants. 2. Adding functionality to existing drivers diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index 3f429ed8b3b8..213859e69e88 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt @@ -165,7 +165,7 @@ Searching in menuconfig: Example: /hotplug This lists all config symbols that contain "hotplug", - e.g., HOTPLUG, HOTPLUG_CPU, MEMORY_HOTPLUG. + e.g., HOTPLUG_CPU, MEMORY_HOTPLUG. For search help, enter / followed TAB-TAB-TAB (to highlight <Help>) and Enter. This will tell you that you can also use diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2fe6e767b3d6..81732b8abd3a 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3341,6 +3341,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted. that this also can be controlled per-workqueue for workqueues visible under /sys/bus/workqueue/. + workqueue.power_efficient + Per-cpu workqueues are generally preferred because + they show better performance thanks to cache + locality; unfortunately, per-cpu workqueues tend to + be more power hungry than unbound workqueues. + + Enabling this makes the per-cpu workqueues which + were observed to contribute significantly to power + consumption unbound, leading to measurably lower + power usage at the cost of small performance + overhead. + + The default value of this parameter is determined by + the config option CONFIG_WQ_POWER_EFFICIENT_DEFAULT. + x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of default x2apic cluster mode on platforms supporting x2apic. diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt index cbf7ae412da4..5f39ef55c6f6 100644 --- a/Documentation/kernel-per-CPU-kthreads.txt +++ b/Documentation/kernel-per-CPU-kthreads.txt @@ -157,6 +157,53 @@ RCU_SOFTIRQ: Do at least one of the following: calls and by forcing both kernel threads and interrupts to execute elsewhere. +Name: kworker/%u:%d%s (cpu, id, priority) +Purpose: Execute workqueue requests +To reduce its OS jitter, do any of the following: +1. Run your workload at a real-time priority, which will allow + preempting the kworker daemons. +2. Do any of the following needed to avoid jitter that your + application cannot tolerate: + a. Build your kernel with CONFIG_SLUB=y rather than + CONFIG_SLAB=y, thus avoiding the slab allocator's periodic + use of each CPU's workqueues to run its cache_reap() + function. + b. Avoid using oprofile, thus avoiding OS jitter from + wq_sync_buffer(). + c. Limit your CPU frequency so that a CPU-frequency + governor is not required, possibly enlisting the aid of + special heatsinks or other cooling technologies. If done + correctly, and if you CPU architecture permits, you should + be able to build your kernel with CONFIG_CPU_FREQ=n to + avoid the CPU-frequency governor periodically running + on each CPU, including cs_dbs_timer() and od_dbs_timer(). + WARNING: Please check your CPU specifications to + 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(). + 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. + (This will require editing Kconfig files and will defeat + this platform's RAS functionality.) This avoids jitter + due to the rtas_event_scan() function. + WARNING: Please check your CPU specifications to + make sure that this is safe on your particular system. + f. If running on Cell Processor, build your kernel with + CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from + spu_gov_work(). + WARNING: Please check your CPU specifications to + make sure that this is safe on your particular system. + g. If running on PowerMAC, build your kernel with + CONFIG_PMAC_RACKMETER=n to disable the CPU-meter, + avoiding OS jitter from rackmeter_do_timer(). + Name: rcuc/%u Purpose: Execute RCU callbacks in CONFIG_RCU_BOOST=y kernels. To reduce its OS jitter, do at least one of the following: diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index f98ca633b528..3458d6343e01 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -420,10 +420,10 @@ tcp_synack_retries - INTEGER for a passive TCP connection will happen after 63seconds. tcp_syncookies - BOOLEAN - Only valid when the kernel was compiled with CONFIG_SYNCOOKIES + Only valid when the kernel was compiled with CONFIG_SYN_COOKIES Send out syncookies when the syn backlog queue of a socket overflows. This is to prevent against the common 'SYN flood attack' - Default: FALSE + Default: 1 Note, that syncookies is fallback facility. It MUST NOT be used to help highly loaded servers to stand diff --git a/Documentation/rt-mutex-design.txt b/Documentation/rt-mutex-design.txt index 33ed8007a845..a5bcd7f5c33f 100644 --- a/Documentation/rt-mutex-design.txt +++ b/Documentation/rt-mutex-design.txt @@ -384,7 +384,7 @@ priority back. __rt_mutex_adjust_prio examines the result of rt_mutex_getprio, and if the result does not equal the task's current priority, then rt_mutex_setprio is called to adjust the priority of the task to the new priority. -Note that rt_mutex_setprio is defined in kernel/sched.c to implement the +Note that rt_mutex_setprio is defined in kernel/sched/core.c to implement the actual change in priority. It is interesting to note that __rt_mutex_adjust_prio can either increase diff --git a/Documentation/scheduler/sched-domains.txt b/Documentation/scheduler/sched-domains.txt index 443f0c76bab4..4af80b1c05aa 100644 --- a/Documentation/scheduler/sched-domains.txt +++ b/Documentation/scheduler/sched-domains.txt @@ -25,7 +25,7 @@ is treated as one entity. The load of a group is defined as the sum of the load of each of its member CPUs, and only when the load of a group becomes out of balance are tasks moved between groups. -In kernel/sched.c, trigger_load_balance() is run periodically on each CPU +In kernel/sched/core.c, trigger_load_balance() is run periodically on each CPU through scheduler_tick(). It raises a softirq after the next regularly scheduled rebalancing event for the current runqueue has arrived. The actual load balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run @@ -62,7 +62,7 @@ struct sched_domain fields, SD_FLAG_*, SD_*_INIT to get an idea of the specifics and what to tune. Architectures may retain the regular override the default SD_*_INIT flags -while using the generic domain builder in kernel/sched.c if they wish to +while using the generic domain builder in kernel/sched/core.c if they wish to retain the traditional SMT->SMP->NUMA topology (or some subset of that). This can be done by #define'ing ARCH_HASH_SCHED_TUNE. diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX index f7b0c7dc25ef..1f1b22fbd739 100644 --- a/Documentation/serial/00-INDEX +++ b/Documentation/serial/00-INDEX @@ -16,8 +16,6 @@ serial-rs485.txt - info about RS485 structures and support in the kernel. specialix.txt - info on hardware/driver for specialix IO8+ multiport serial card. -stallion.txt - - info on using the Stallion multiport serial driver. sx.txt - info on the Specialix SX/SI multiport serial driver. tty.txt diff --git a/Documentation/serial/stallion.txt b/Documentation/serial/stallion.txt deleted file mode 100644 index 4d798c0cb5cb..000000000000 --- a/Documentation/serial/stallion.txt +++ /dev/null @@ -1,392 +0,0 @@ -* NOTE - This is an unmaintained driver. Lantronix, which bought Stallion -technologies, is not active in driver maintenance, and they have no information -on when or if they will have a 2.6 driver. - -James Nelson <james4765@gmail.com> - 12-12-2004 - -Stallion Multiport Serial Driver Readme ---------------------------------------- - -Copyright (C) 1994-1999, Stallion Technologies. - -Version: 5.5.1 -Date: 28MAR99 - - - -1. INTRODUCTION - -There are two drivers that work with the different families of Stallion -multiport serial boards. One is for the Stallion smart boards - that is -EasyIO, EasyConnection 8/32 and EasyConnection 8/64-PCI, the other for -the true Stallion intelligent multiport boards - EasyConnection 8/64 -(ISA, EISA), EasyConnection/RA-PCI, ONboard and Brumby. - -If you are using any of the Stallion intelligent multiport boards (Brumby, -ONboard, EasyConnection 8/64 (ISA, EISA), EasyConnection/RA-PCI) with -Linux you will need to get the driver utility package. This contains a -firmware loader and the firmware images necessary to make the devices operate. - -The Stallion Technologies ftp site, ftp.stallion.com, will always have -the latest version of the driver utility package. - -ftp://ftp.stallion.com/drivers/ata5/Linux/ata-linux-550.tar.gz - -As of the printing of this document the latest version of the driver -utility package is 5.5.0. If a later version is now available then you -should use the latest version. - -If you are using the EasyIO, EasyConnection 8/32 or EasyConnection 8/64-PCI -boards then you don't need this package, although it does have a serial stats -display program. - -If you require DIP switch settings, or EISA configuration files, or any -other information related to Stallion boards then have a look at Stallion's -web pages at http://www.stallion.com. - - - -2. INSTALLATION - -The drivers can be used as loadable modules or compiled into the kernel. -You can choose which when doing a "config" on the kernel. - -All ISA, and EISA boards that you want to use need to be configured into -the driver(s). All PCI boards will be automatically detected when you load -the driver - so they do not need to be entered into the driver(s) -configuration structure. Note that kernel PCI support is required to use PCI -boards. - -There are two methods of configuring ISA and EISA boards into the drivers. -If using the driver as a loadable module then the simplest method is to pass -the driver configuration as module arguments. The other method is to modify -the driver source to add configuration lines for each board in use. - -If you have pre-built Stallion driver modules then the module argument -configuration method should be used. A lot of Linux distributions come with -pre-built driver modules in /lib/modules/X.Y.Z/misc for the kernel in use. -That makes things pretty simple to get going. - - -2.1 MODULE DRIVER CONFIGURATION: - -The simplest configuration for modules is to use the module load arguments -to configure any ISA or EISA boards. PCI boards are automatically -detected, so do not need any additional configuration at all. - -If using EasyIO, EasyConnection 8/32 ISA, or EasyConnection 8/63-PCI -boards then use the "stallion" driver module, Otherwise if you are using -an EasyConnection 8/64 ISA or EISA, EasyConnection/RA-PCI, ONboard, -Brumby or original Stallion board then use the "istallion" driver module. - -Typically to load up the smart board driver use: - - modprobe stallion - -This will load the EasyIO and EasyConnection 8/32 driver. It will output a -message to say that it loaded and print the driver version number. It will -also print out whether it found the configured boards or not. These messages -may not appear on the console, but typically are always logged to -/var/adm/messages or /var/log/syslog files - depending on how the klogd and -syslogd daemons are setup on your system. - -To load the intelligent board driver use: - - modprobe istallion - -It will output similar messages to the smart board driver. - -If not using an auto-detectable board type (that is a PCI board) then you -will also need to supply command line arguments to the modprobe command -when loading the driver. The general form of the configuration argument is - - board?=<name>[,<ioaddr>[,<addr>][,<irq>]] - -where: - - board? -- specifies the arbitrary board number of this board, - can be in the range 0 to 3. - - name -- textual name of this board. The board name is the common - board name, or any "shortened" version of that. The board - type number may also be used here. - - ioaddr -- specifies the I/O address of this board. This argument is - optional, but should generally be specified. - - addr -- optional second address argument. Some board types require - a second I/O address, some require a memory address. The - exact meaning of this argument depends on the board type. - - irq -- optional IRQ line used by this board. - -Up to 4 board configuration arguments can be specified on the load line. -Here is some examples: - - modprobe stallion board0=easyio,0x2a0,5 - -This configures an EasyIO board as board 0 at I/O address 0x2a0 and IRQ 5. - - modprobe istallion board3=ec8/64,0x2c0,0xcc000 - -This configures an EasyConnection 8/64 ISA as board 3 at I/O address 0x2c0 at -memory address 0xcc000. - - modprobe stallion board1=ec8/32-at,0x2a0,0x280,10 - -This configures an EasyConnection 8/32 ISA board at primary I/O address 0x2a0, -secondary address 0x280 and IRQ 10. - -You will probably want to enter this module load and configuration information -into your system startup scripts so that the drivers are loaded and configured -on each system boot. Typically configuration files are put in the -/etc/modprobe.d/ directory. - - -2.2 STATIC DRIVER CONFIGURATION: - -For static driver configuration you need to modify the driver source code. -Entering ISA and EISA boards into the driver(s) configuration structure -involves editing the driver(s) source file. It's pretty easy if you follow -the instructions below. Both drivers can support up to 4 boards. The smart -card driver (the stallion.c driver) supports any combination of EasyIO and -EasyConnection 8/32 boards (up to a total of 4). The intelligent driver -supports any combination of ONboards, Brumbys, Stallions and EasyConnection -8/64 (ISA and EISA) boards (up to a total of 4). - -To set up the driver(s) for the boards that you want to use you need to -edit the appropriate driver file and add configuration entries. - -If using EasyIO or EasyConnection 8/32 ISA boards, - In drivers/char/stallion.c: - - find the definition of the stl_brdconf array (of structures) - near the top of the file - - modify this to match the boards you are going to install - (the comments before this structure should help) - - save and exit - -If using ONboard, Brumby, Stallion or EasyConnection 8/64 (ISA or EISA) -boards, - In drivers/char/istallion.c: - - find the definition of the stli_brdconf array (of structures) - near the top of the file - - modify this to match the boards you are going to install - (the comments before this structure should help) - - save and exit - -Once you have set up the board configurations then you are ready to build -the kernel or modules. - -When the new kernel is booted, or the loadable module loaded then the -driver will emit some kernel trace messages about whether the configured -boards were detected or not. Depending on how your system logger is set -up these may come out on the console, or just be logged to -/var/adm/messages or /var/log/syslog. You should check the messages to -confirm that all is well. - - -2.3 SHARING INTERRUPTS - -It is possible to share interrupts between multiple EasyIO and -EasyConnection 8/32 boards in an EISA system. To do this you must be using -static driver configuration, modifying the driver source code to add driver -configuration. Then a couple of extra things are required: - -1. When entering the board resources into the stallion.c file you need to - mark the boards as using level triggered interrupts. Do this by replacing - the "0" entry at field position 6 (the last field) in the board - configuration structure with a "1". (This is the structure that defines - the board type, I/O locations, etc. for each board). All boards that are - sharing an interrupt must be set this way, and each board should have the - same interrupt number specified here as well. Now build the module or - kernel as you would normally. - -2. When physically installing the boards into the system you must enter - the system EISA configuration utility. You will need to install the EISA - configuration files for *all* the EasyIO and EasyConnection 8/32 boards - that are sharing interrupts. The Stallion EasyIO and EasyConnection 8/32 - EISA configuration files required are supplied by Stallion Technologies - on the EASY Utilities floppy diskette (usually supplied in the box with - the board when purchased. If not, you can pick it up from Stallion's FTP - site, ftp.stallion.com). You will need to edit the board resources to - choose level triggered interrupts, and make sure to set each board's - interrupt to the same IRQ number. - -You must complete both the above steps for this to work. When you reboot -or load the driver your EasyIO and EasyConnection 8/32 boards will be -sharing interrupts. - - -2.4 USING HIGH SHARED MEMORY - -The EasyConnection 8/64-EI, ONboard and Stallion boards are capable of -using shared memory addresses above the usual 640K - 1Mb range. The ONboard -ISA and the Stallion boards can be programmed to use memory addresses up to -16Mb (the ISA bus addressing limit), and the EasyConnection 8/64-EI and -ONboard/E can be programmed for memory addresses up to 4Gb (the EISA bus -addressing limit). - -The higher than 1Mb memory addresses are fully supported by this driver. -Just enter the address as you normally would for a lower than 1Mb address -(in the driver's board configuration structure). - - - -2.5 TROUBLE SHOOTING - -If a board is not found by the driver but is actually in the system then the -most likely problem is that the I/O address is wrong. Change the module load -argument for the loadable module form. Or change it in the driver stallion.c -or istallion.c configuration structure and rebuild the kernel or modules, or -change it on the board. - -On EasyIO and EasyConnection 8/32 boards the IRQ is software programmable, so -if there is a conflict you may need to change the IRQ used for a board. There -are no interrupts to worry about for ONboard, Brumby or EasyConnection 8/64 -(ISA and EISA) boards. The memory region on EasyConnection 8/64 and -ONboard boards is software programmable, but not on the Brumby boards. - - - -3. USING THE DRIVERS - -3.1 INTELLIGENT DRIVER OPERATION - -The intelligent boards also need to have their "firmware" code downloaded -to them. This is done via a user level application supplied in the driver -utility package called "stlload". Compile this program wherever you dropped -the package files, by typing "make". In its simplest form you can then type - - ./stlload -i cdk.sys - -in this directory and that will download board 0 (assuming board 0 is an -EasyConnection 8/64 or EasyConnection/RA board). To download to an -ONboard, Brumby or Stallion do: - - ./stlload -i 2681.sys - -Normally you would want all boards to be downloaded as part of the standard -system startup. To achieve this, add one of the lines above into the -/etc/rc.d/rc.S or /etc/rc.d/rc.serial file. To download each board just add -the "-b <brd-number>" option to the line. You will need to download code for -every board. You should probably move the stlload program into a system -directory, such as /usr/sbin. Also, the default location of the cdk.sys image -file in the stlload down-loader is /usr/lib/stallion. Create that directory -and put the cdk.sys and 2681.sys files in it. (It's a convenient place to put -them anyway). As an example your /etc/rc.d/rc.S file might have the -following lines added to it (if you had 3 boards): - - /usr/sbin/stlload -b 0 -i /usr/lib/stallion/cdk.sys - /usr/sbin/stlload -b 1 -i /usr/lib/stallion/2681.sys - /usr/sbin/stlload -b 2 -i /usr/lib/stallion/2681.sys - -The image files cdk.sys and 2681.sys are specific to the board types. The -cdk.sys will only function correctly on an EasyConnection 8/64 board. Similarly -the 2681.sys image fill only operate on ONboard, Brumby and Stallion boards. -If you load the wrong image file into a board it will fail to start up, and -of course the ports will not be operational! - -If you are using the modularized version of the driver you might want to put -the modprobe calls in the startup script as well (before the download lines -obviously). - - -3.2 USING THE SERIAL PORTS - -Once the driver is installed you will need to setup some device nodes to -access the serial ports. The simplest method is to use the /dev/MAKEDEV program. -It will automatically create device entries for Stallion boards. This will -create the normal serial port devices as /dev/ttyE# where# is the port number -starting from 0. A bank of 64 minor device numbers is allocated to each board, -so the first port on the second board is port 64,etc. A set of callout type -devices may also be created. They are created as the devices /dev/cue# where # -is the same as for the ttyE devices. - -For the most part the Stallion driver tries to emulate the standard PC system -COM ports and the standard Linux serial driver. The idea is that you should -be able to use Stallion board ports and COM ports interchangeably without -modifying anything but the device name. Anything that doesn't work like that -should be considered a bug in this driver! - -If you look at the driver code you will notice that it is fairly closely -based on the Linux serial driver (linux/drivers/char/serial.c). This is -intentional, obviously this is the easiest way to emulate its behavior! - -Since this driver tries to emulate the standard serial ports as much as -possible, most system utilities should work as they do for the standard -COM ports. Most importantly "stty" works as expected and "setserial" can -also be used (excepting the ability to auto-configure the I/O and IRQ -addresses of boards). Higher baud rates are supported in the usual fashion -through setserial or using the CBAUDEX extensions. Note that the EasyIO and -EasyConnection (all types) support at least 57600 and 115200 baud. The newer -EasyConnection XP modules and new EasyIO boards support 230400 and 460800 -baud as well. The older boards including ONboard and Brumby support a -maximum baud rate of 38400. - -If you are unfamiliar with how to use serial ports, then get the Serial-HOWTO -by Greg Hankins. It will explain everything you need to know! - - - -4. NOTES - -You can use both drivers at once if you have a mix of board types installed -in a system. However to do this you will need to change the major numbers -used by one of the drivers. Currently both drivers use major numbers 24, 25 -and 28 for their devices. Change one driver to use some other major numbers, -and then modify the mkdevnods script to make device nodes based on those new -major numbers. For example, you could change the istallion.c driver to use -major numbers 60, 61 and 62. You will also need to create device nodes with -different names for the ports, for example ttyF# and cuf#. - -The original Stallion board is no longer supported by Stallion Technologies. -Although it is known to work with the istallion driver. - -Finding a free physical memory address range can be a problem. The older -boards like the Stallion and ONboard need large areas (64K or even 128K), so -they can be very difficult to get into a system. If you have 16 Mb of RAM -then you have no choice but to put them somewhere in the 640K -> 1Mb range. -ONboards require 64K, so typically 0xd0000 is good, or 0xe0000 on some -systems. If you have an original Stallion board, "V4.0" or Rev.O, then you -need a 64K memory address space, so again 0xd0000 and 0xe0000 are good. -Older Stallion boards are a much bigger problem. They need 128K of address -space and must be on a 128K boundary. If you don't have a VGA card then -0xc0000 might be usable - there is really no other place you can put them -below 1Mb. - -Both the ONboard and old Stallion boards can use higher memory addresses as -well, but you must have less than 16Mb of RAM to be able to use them. Usual -high memory addresses used include 0xec0000 and 0xf00000. - -The Brumby boards only require 16Kb of address space, so you can usually -squeeze them in somewhere. Common addresses are 0xc8000, 0xcc000, or in -the 0xd0000 range. EasyConnection 8/64 boards are even better, they only -require 4Kb of address space, again usually 0xc8000, 0xcc000 or 0xd0000 -are good. - -If you are using an EasyConnection 8/64-EI or ONboard/E then usually the -0xd0000 or 0xe0000 ranges are the best options below 1Mb. If neither of -them can be used then the high memory support to use the really high address -ranges is the best option. Typically the 2Gb range is convenient for them, -and gets them well out of the way. - -The ports of the EasyIO-8M board do not have DCD or DTR signals. So these -ports cannot be used as real modem devices. Generally, when using these -ports you should only use the cueX devices. - -The driver utility package contains a couple of very useful programs. One -is a serial port statistics collection and display program - very handy -for solving serial port problems. The other is an extended option setting -program that works with the intelligent boards. - - - -5. DISCLAIMER - -The information contained in this document is believed to be accurate and -reliable. However, no responsibility is assumed by Stallion Technologies -Pty. Ltd. for its use, nor any infringements of patents or other rights -of third parties resulting from its use. Stallion Technologies reserves -the right to modify the design of its products and will endeavour to change -the information in manuals and accompanying documentation accordingly. - diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt index 9dbe885ecd8d..97eaf5727178 100644 --- a/Documentation/spinlocks.txt +++ b/Documentation/spinlocks.txt @@ -137,7 +137,7 @@ don't block on each other (and thus there is no dead-lock wrt interrupts. But when you do the write-lock, you have to use the irq-safe version. For an example of being clever with rw-locks, see the "waitqueue_lock" -handling in kernel/sched.c - nothing ever _changes_ a wait-queue from +handling in kernel/sched/core.c - nothing ever _changes_ a wait-queue from within an interrupt, they only read the queue in order to know whom to wake up. So read-locks are safe (which is good: they are very common indeed), while write-locks need to protect themselves against interrupts. diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index ccd42589e124..ab7d16efa96b 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -70,12 +70,12 @@ show up in /proc/sys/kernel: - shmall - shmmax [ sysv ipc ] - shmmni -- softlockup_thresh - stop-a [ SPARC only ] - sysrq ==> Documentation/sysrq.txt - tainted - threads-max - unknown_nmi_panic +- watchdog_thresh - version ============================================================== @@ -427,6 +427,32 @@ This file shows up if CONFIG_DEBUG_STACKOVERFLOW is enabled. ============================================================== +perf_cpu_time_max_percent: + +Hints to the kernel how much CPU time it should be allowed to +use to handle perf sampling events. If the perf subsystem +is informed that its samples are exceeding this limit, it +will drop its sampling frequency to attempt to reduce its CPU +usage. + +Some perf sampling happens in NMIs. If these samples +unexpectedly take too long to execute, the NMIs can become +stacked up next to each other so much that nothing else is +allowed to execute. + +0: disable the mechanism. Do not monitor or correct perf's + sampling rate no matter how CPU time it takes. + +1-100: attempt to throttle perf's sample rate to this + percentage of CPU. Note: the kernel calculates an + "expected" length of each sample event. 100 here means + 100% of that expected length. Even if this is set to + 100, you may still see sample throttling if this + length is exceeded. Set to 0 if you truly do not care + how much CPU is consumed. + +============================================================== + pid_max: @@ -604,15 +630,6 @@ without users and with a dead originative process will be destroyed. ============================================================== -softlockup_thresh: - -This value can be used to lower the softlockup tolerance threshold. The -default threshold is 60 seconds. If a cpu is locked up for 60 seconds, -the kernel complains. Valid values are 1-60 seconds. Setting this -tunable to zero will disable the softlockup detection altogether. - -============================================================== - tainted: Non-zero if the kernel has been tainted. Numeric values, which @@ -648,3 +665,16 @@ that time, kernel debugging information is displayed on console. NMI switch that most IA32 servers have fires unknown NMI up, for example. If a system hangs up, try pressing the NMI switch. + +============================================================== + +watchdog_thresh: + +This value can be used to control the frequency of hrtimer and NMI +events and the soft and hard lockup thresholds. The default threshold +is 10 seconds. + +The softlockup threshold is (2 * watchdog_thresh). Setting this +tunable to zero will disable lockup detection altogether. + +============================================================== diff --git a/Documentation/timers/NO_HZ.txt b/Documentation/timers/NO_HZ.txt index 5b5322024067..88697584242b 100644 --- a/Documentation/timers/NO_HZ.txt +++ b/Documentation/timers/NO_HZ.txt @@ -7,21 +7,59 @@ efficiency and reducing OS jitter. Reducing OS jitter is important for some types of computationally intensive high-performance computing (HPC) applications and for real-time applications. -There are two main contexts in which the number of scheduling-clock -interrupts can be reduced compared to the old-school approach of sending -a scheduling-clock interrupt to all CPUs every jiffy whether they need -it or not (CONFIG_HZ_PERIODIC=y or CONFIG_NO_HZ=n for older kernels): +There are three main ways of managing scheduling-clock interrupts +(also known as "scheduling-clock ticks" or simply "ticks"): -1. Idle CPUs (CONFIG_NO_HZ_IDLE=y or CONFIG_NO_HZ=y for older kernels). +1. Never omit scheduling-clock ticks (CONFIG_HZ_PERIODIC=y or + CONFIG_NO_HZ=n for older kernels). You normally will -not- + want to choose this option. -2. CPUs having only one runnable task (CONFIG_NO_HZ_FULL=y). +2. Omit scheduling-clock ticks on idle CPUs (CONFIG_NO_HZ_IDLE=y or + CONFIG_NO_HZ=y for older kernels). This is the most common + approach, and should be the default. -These two cases are described in the following two sections, followed +3. Omit scheduling-clock ticks on CPUs that are either idle or that + have only one runnable task (CONFIG_NO_HZ_FULL=y). Unless you + are running realtime applications or certain types of HPC + workloads, you will normally -not- want this option. + +These three cases are described in the following three sections, followed by a third section on RCU-specific considerations and a fourth and final section listing known issues. -IDLE CPUs +NEVER OMIT SCHEDULING-CLOCK TICKS + +Very old versions of Linux from the 1990s and the very early 2000s +are incapable of omitting scheduling-clock ticks. It turns out that +there are some situations where this old-school approach is still the +right approach, for example, in heavy workloads with lots of tasks +that use short bursts of CPU, where there are very frequent idle +periods, but where these idle periods are also quite short (tens or +hundreds of microseconds). For these types of workloads, scheduling +clock interrupts will normally be delivered any way because there +will frequently be multiple runnable tasks per CPU. In these cases, +attempting to turn off the scheduling clock interrupt will have no effect +other than increasing the overhead of switching to and from idle and +transitioning between user and kernel execution. + +This mode of operation can be selected using CONFIG_HZ_PERIODIC=y (or +CONFIG_NO_HZ=n for older kernels). + +However, if you are instead running a light workload with long idle +periods, failing to omit scheduling-clock interrupts will result in +excessive power consumption. This is especially bad on battery-powered +devices, where it results in extremely short battery lifetimes. If you +are running light workloads, you should therefore read the following +section. + +In addition, if you are running either a real-time workload or an HPC +workload with short iterations, the scheduling-clock interrupts can +degrade your applications performance. If this describes your workload, +you should read the following two sections. + + +OMIT SCHEDULING-CLOCK TICKS FOR IDLE CPUs If a CPU is idle, there is little point in sending it a scheduling-clock interrupt. After all, the primary purpose of a scheduling-clock interrupt @@ -59,10 +97,12 @@ By default, CONFIG_NO_HZ_IDLE=y kernels boot with "nohz=on", enabling dyntick-idle mode. -CPUs WITH ONLY ONE RUNNABLE TASK +OMIT SCHEDULING-CLOCK TICKS FOR CPUs WITH ONLY ONE RUNNABLE TASK If a CPU has only one runnable task, there is little point in sending it a scheduling-clock interrupt because there is no other task to switch to. +Note that omitting scheduling-clock ticks for CPUs with only one runnable +task implies also omitting them for idle CPUs. The CONFIG_NO_HZ_FULL=y Kconfig option causes the kernel to avoid sending scheduling-clock interrupts to CPUs with a single runnable task, @@ -238,6 +278,11 @@ o Adaptive-ticks does not do anything unless there is only one single runnable SCHED_FIFO task and multiple runnable SCHED_OTHER tasks, even though these interrupts are unnecessary. + And even when there are multiple runnable tasks on a given CPU, + there is little point in interrupting that CPU until the current + running task's timeslice expires, which is almost always way + longer than the time of the next scheduling-clock interrupt. + Better handling of these sorts of situations is future work. o A reboot is required to reconfigure both adaptive idle and RCU @@ -268,6 +313,16 @@ o Unless all CPUs are idle, at least one CPU must keep the scheduling-clock interrupt going in order to support accurate timekeeping. -o If there are adaptive-ticks CPUs, there will be at least one - CPU keeping the scheduling-clock interrupt going, even if all - CPUs are otherwise idle. +o If there might potentially be some adaptive-ticks CPUs, there + will be at least one CPU keeping the scheduling-clock interrupt + going, even if all CPUs are otherwise idle. + + Better handling of this situation is ongoing work. + +o Some process-handling operations still require the occasional + scheduling-clock tick. These operations include calculating CPU + load, maintaining sched average, computing CFS entity vruntime, + computing avenrun, and carrying out load balancing. They are + currently accommodated by scheduling-clock tick every second + or so. On-going work will eliminate the need even for these + infrequent scheduling-clock ticks. diff --git a/Documentation/trace/events-nmi.txt b/Documentation/trace/events-nmi.txt new file mode 100644 index 000000000000..c03c8c89f08d --- /dev/null +++ b/Documentation/trace/events-nmi.txt @@ -0,0 +1,43 @@ +NMI Trace Events + +These events normally show up here: + + /sys/kernel/debug/tracing/events/nmi + +-- + +nmi_handler: + +You might want to use this tracepoint if you suspect that your +NMI handlers are hogging large amounts of CPU time. The kernel +will warn if it sees long-running handlers: + + INFO: NMI handler took too long to run: 9.207 msecs + +and this tracepoint will allow you to drill down and get some +more details. + +Let's say you suspect that perf_event_nmi_handler() is causing +you some problems and you only want to trace that handler +specifically. You need to find its address: + + $ grep perf_event_nmi_handler /proc/kallsyms + ffffffff81625600 t perf_event_nmi_handler + +Let's also say you are only interested in when that function is +really hogging a lot of CPU time, like a millisecond at a time. +Note that the kernel's output is in milliseconds, but the input +to the filter is in nanoseconds! You can filter on 'delta_ns': + +cd /sys/kernel/debug/tracing/events/nmi/nmi_handler +echo 'handler==0xffffffff81625600 && delta_ns>1000000' > filter +echo 1 > enable + +Your output would then look like: + +$ cat /sys/kernel/debug/tracing/trace_pipe +<idle>-0 [000] d.h3 505.397558: nmi_handler: perf_event_nmi_handler() delta_ns: 3236765 handled: 1 +<idle>-0 [000] d.h3 505.805893: nmi_handler: perf_event_nmi_handler() delta_ns: 3174234 handled: 1 +<idle>-0 [000] d.h3 506.158206: nmi_handler: perf_event_nmi_handler() delta_ns: 3084642 handled: 1 +<idle>-0 [000] d.h3 506.334346: nmi_handler: perf_event_nmi_handler() delta_ns: 3080351 handled: 1 + diff --git a/Documentation/usb/gadget_configfs.txt b/Documentation/usb/gadget_configfs.txt new file mode 100644 index 000000000000..8ec2a67c39b7 --- /dev/null +++ b/Documentation/usb/gadget_configfs.txt @@ -0,0 +1,384 @@ + + + + + Linux USB gadget configured through configfs + + + 25th April 2013 + + + + +Overview +======== + +A USB Linux Gadget is a device which has a UDC (USB Device Controller) and can +be connected to a USB Host to extend it with additional functions like a serial +port or a mass storage capability. + +A gadget is seen by its host as a set of configurations, each of which contains +a number of interfaces which, from the gadget's perspective, are known as +functions, each function representing e.g. a serial connection or a SCSI disk. + +Linux provides a number of functions for gadgets to use. + +Creating a gadget means deciding what configurations there will be +and which functions each configuration will provide. + +Configfs (please see Documentation/filesystems/configfs/*) lends itslef nicely +for the purpose of telling the kernel about the above mentioned decision. +This document is about how to do it. + +It also describes how configfs integration into gadget is designed. + + + + +Requirements +============ + +In order for this to work configfs must be available, so CONFIGFS_FS must be +'y' or 'm' in .config. As of this writing USB_LIBCOMPOSITE selects CONFIGFS_FS. + + + + +Usage +===== + +(The original post describing the first function +made available through configfs can be seen here: +http://www.spinics.net/lists/linux-usb/msg76388.html) + +$ modprobe libcomposite +$ mount none $CONFIGFS_HOME -t configfs + +where CONFIGFS_HOME is the mount point for configfs + +1. Creating the gadgets +----------------------- + +For each gadget to be created its corresponding directory must be created: + +$ mkdir $CONFIGFS_HOME/usb_gadget/<gadget name> + +e.g.: + +$ mkdir $CONFIGFS_HOME/usb_gadget/g1 + +... +... +... + +$ cd $CONFIGFS_HOME/usb_gadget/g1 + +Each gadget needs to have its vendor id <VID> and product id <PID> specified: + +$ echo <VID> > idVendor +$ echo <PID> > idProduct + +A gadget also needs its serial number, manufacturer and product strings. +In order to have a place to store them, a strings subdirectory must be created +for each language, e.g.: + +$ mkdir strings/0x409 + +Then the strings can be specified: + +$ echo <serial number> > strings/0x409/serialnumber +$ echo <manufacturer> > strings/0x409/manufacturer +$ echo <product> > strings/0x409/product + +2. Creating the configurations +------------------------------ + +Each gadget will consist of a number of configurations, their corresponding +directories must be created: + +$ mkdir configs/<name>.<number> + +where <name> can be any string which is legal in a filesystem and the +<numebr> is the configuration's number, e.g.: + +$ mkdir configs/c.1 + +... +... +... + +Each configuration also needs its strings, so a subdirectory must be created +for each language, e.g.: + +$ mkdir configs/c.1/strings/0x409 + +Then the configuration string can be specified: + +$ echo <configuration> > configs/c.1/strings/0x409/configuration + +Some attributes can also be set for a configuration, e.g.: + +$ echo 120 > configs/c.1/MaxPower + +3. Creating the functions +------------------------- + +The gadget will provide some functions, for each function its corresponding +directory must be created: + +$ mkdir functions/<name>.<instance name> + +where <name> corresponds to one of allowed function names and instance name +is an arbitrary string allowed in a filesystem, e.g.: + +$ mkdir functions/ncm.usb0 # usb_f_ncm.ko gets loaded with request_module() + +... +... +... + +Each function provides its specific set of attributes, with either read-only +or read-write access. Where applicable they need to be written to as +appropriate. +Please refer to Documentation/ABI/*/configfs-usb-gadget* for more information. + +4. Associating the functions with their configurations +------------------------------------------------------ + +At this moment a number of gadgets is created, each of which has a number of +configurations specified and a number of functions available. What remains +is specifying which function is available in which configuration (the same +function can be used in multiple configurations). This is achieved with +creating symbolic links: + +$ ln -s functions/<name>.<instance name> configs/<name>.<number> + +e.g.: + +$ ln -s functions/ncm.usb0 configs/c.1 + +... +... +... + +5. Enabling the gadget +---------------------- + +All the above steps serve the purpose of composing the gadget of +configurations and functions. + +An example directory structure might look like this: + +. +./strings +./strings/0x409 +./strings/0x409/serialnumber +./strings/0x409/product +./strings/0x409/manufacturer +./configs +./configs/c.1 +./configs/c.1/ncm.usb0 -> ../../../../usb_gadget/g1/functions/ncm.usb0 +./configs/c.1/strings +./configs/c.1/strings/0x409 +./configs/c.1/strings/0x409/configuration +./configs/c.1/bmAttributes +./configs/c.1/MaxPower +./functions +./functions/ncm.usb0 +./functions/ncm.usb0/ifname +./functions/ncm.usb0/qmult +./functions/ncm.usb0/host_addr +./functions/ncm.usb0/dev_addr +./UDC +./bcdUSB +./bcdDevice +./idProduct +./idVendor +./bMaxPacketSize0 +./bDeviceProtocol +./bDeviceSubClass +./bDeviceClass + + +Such a gadget must be finally enabled so that the USB host can enumerate it. +In order to enable the gadget it must be bound to a UDC (USB Device Controller). + +$ echo <udc name> > UDC + +where <udc name> is one of those found in /sys/class/udc/* +e.g.: + +$ echo s3c-hsotg > UDC + + +6. Disabling the gadget +----------------------- + +$ echo "" > UDC + +7. Cleaning up +-------------- + +Remove functions from configurations: + +$ rm configs/<config name>.<number>/<function> + +where <config name>.<number> specify the configuration and <function> is +a symlink to a function being removed from the configuration, e.g.: + +$ rm configfs/c.1/ncm.usb0 + +... +... +... + +Remove strings directories in configurations + +$ rmdir configs/<config name>.<number>/strings/<lang> + +e.g.: + +$ rmdir configs/c.1/strings/0x409 + +... +... +... + +and remove the configurations + +$ rmdir configs/<config name>.<number> + +e.g.: + +rmdir configs/c.1 + +... +... +... + +Remove functions (function modules are not unloaded, though) + +$ rmdir functions/<name>.<instance name> + +e.g.: + +$ rmdir functions/ncm.usb0 + +... +... +... + +Remove strings directories in the gadget + +$ rmdir strings/<lang> + +e.g.: + +$ rmdir strings/0x409 + +and finally remove the gadget: + +$ cd .. +$ rmdir <gadget name> + +e.g.: + +$ rmdir g1 + + + + +Implementation design +===================== + +Below the idea of how configfs works is presented. +In configfs there are items and groups, both represented as directories. +The difference between an item and a group is that a group can contain +other groups. In the picture below only an item is shown. +Both items and groups can have attributes, which are represented as files. +The user can create and remove directories, but cannot remove files, +which can be read-only or read-write, depending on what they represent. + +The filesystem part of configfs operates on config_items/groups and +configfs_attributes which are generic and of the same type for all +configured elements. However, they are embedded in usage-specific +larger structures. In the picture below there is a "cs" which contains +a config_item and an "sa" which contains a configfs_attribute. + +The filesystem view would be like this: + +./ +./cs (directory) + | + +--sa (file) + | + . + . + . + +Whenever a user reads/writes the "sa" file, a function is called +which accepts a struct config_item and a struct configfs_attribute. +In the said function the "cs" and "sa" are retrieved using the well +known container_of technique and an appropriate sa's function (show or +store) is called and passed the "cs" and a character buffer. The "show" +is for displaying the file's contents (copy data from the cs to the +buffer), while the "store" is for modifying the file's contents (copy data +from the buffer to the cs), but it is up to the implementer of the +two functions to decide what they actually do. + +typedef struct configured_structure cs; +typedef struc specific_attribute sa; + + sa + +----------------------------------+ + cs | (*show)(cs *, buffer); | ++-----------------+ | (*store)(cs *, buffer, length); | +| | | | +| +-------------+ | | +------------------+ | +| | struct |-|----|------>|struct | | +| | config_item | | | |configfs_attribute| | +| +-------------+ | | +------------------+ | +| | +----------------------------------+ +| data to be set | . +| | . ++-----------------+ . + +The file names are decided by the config item/group designer, while +the directories in general can be named at will. A group can have +a number of its default sub-groups created automatically. + +For more information on configfs please see +Documentation/filesystems/configfs/*. + +The concepts described above translate to USB gadgets like this: + +1. A gadget has its config group, which has some attributes (idVendor, +idProduct etc) and default sub-groups (configs, functions, strings). +Writing to the attributes causes the information to be stored in +appropriate locations. In the configs, functions and strings sub-groups +a user can create their sub-groups to represent configurations, functions, +and groups of strings in a given language. + +2. The user creates configurations and functions, in the configurations +creates symbolic links to functions. This information is used when the +gadget's UDC attribute is written to, which means binding the gadget +to the UDC. The code in drivers/usb/gadget/configfs.c iterates over +all configurations, and in each configuration it iterates over all +functions and binds them. This way the whole gadget is bound. + +3. The file drivers/usb/gadget/configfs.c contains code for + + - gadget's config_group + - gadget's default groups (configs, functions, strings) + - associating functions with configurations (symlinks) + +4. Each USB function naturally has its own view of what it wants +configured, so config_groups for particular functions are defined +in the functions implementation files drivers/usb/gadget/f_*.c. + +5. Funciton's code is written in such a way that it uses + +usb_get_function_instance(), which, in turn, calls request_module. +So, provided that modprobe works, modules for particular functions +are loaded automatically. Please note that the converse is not true: +after a gadget is disabled and torn down, the modules remain loaded. diff --git a/Documentation/usb/hotplug.txt b/Documentation/usb/hotplug.txt index 4c945716a660..6424b130485c 100644 --- a/Documentation/usb/hotplug.txt +++ b/Documentation/usb/hotplug.txt @@ -33,9 +33,9 @@ you get the best hotplugging when you configure a highly modular system. KERNEL HOTPLUG HELPER (/sbin/hotplug) -When you compile with CONFIG_HOTPLUG, you get a new kernel parameter: -/proc/sys/kernel/hotplug, which normally holds the pathname "/sbin/hotplug". -That parameter names a program which the kernel may invoke at various times. +There is a kernel parameter: /proc/sys/kernel/hotplug, which normally +holds the pathname "/sbin/hotplug". That parameter names a program +which the kernel may invoke at various times. The /sbin/hotplug program can be invoked by any subsystem as part of its reaction to a configuration change, from a thread in that subsystem. diff --git a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt index a5f8436753e7..f4099ca6b483 100644 --- a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt +++ b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt @@ -3127,7 +3127,7 @@ at process_kern.c:156 #3 0x1006a052 in switch_to (prev=0x50072000, next=0x507e8000, last=0x50072000) at process_kern.c:161 - #4 0x10001d12 in schedule () at sched.c:777 + #4 0x10001d12 in schedule () at core.c:777 #5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71 #6 0x1006aa10 in __down_failed () at semaphore.c:157 #7 0x1006c5d8 in segv_handler (sc=0x5006e940) at trap_user.c:174 @@ -3191,7 +3191,7 @@ at process_kern.c:161 161 _switch_to(prev, next); (gdb) - #4 0x10001d12 in schedule () at sched.c:777 + #4 0x10001d12 in schedule () at core.c:777 777 switch_to(prev, next, prev); (gdb) #5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71 diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic index 212f4ac31c01..a31c5a242973 100644 --- a/Documentation/w1/w1.generic +++ b/Documentation/w1/w1.generic @@ -25,8 +25,8 @@ When a w1 master driver registers with the w1 subsystem, the following occurs: - sysfs entries for that w1 master are created - the w1 bus is periodically searched for new slave devices -When a device is found on the bus, w1 core checks if driver for its family is -loaded. If so, the family driver is attached to the slave. +When a device is found on the bus, w1 core tries to load the driver for its family +and check if it is loaded. If so, the family driver is attached to the slave. If there is no driver for the family, default one is assigned, which allows to perform almost any kind of operations. Each logical operation is a transaction in nature, which can contain several (two or one) low-level operations. diff --git a/Documentation/ww-mutex-design.txt b/Documentation/ww-mutex-design.txt new file mode 100644 index 000000000000..8a112dc304c3 --- /dev/null +++ b/Documentation/ww-mutex-design.txt @@ -0,0 +1,344 @@ +Wait/Wound Deadlock-Proof Mutex Design +====================================== + +Please read mutex-design.txt first, as it applies to wait/wound mutexes too. + +Motivation for WW-Mutexes +------------------------- + +GPU's do operations that commonly involve many buffers. Those buffers +can be shared across contexts/processes, exist in different memory +domains (for example VRAM vs system memory), and so on. And with +PRIME / dmabuf, they can even be shared across devices. So there are +a handful of situations where the driver needs to wait for buffers to +become ready. If you think about this in terms of waiting on a buffer +mutex for it to become available, this presents a problem because +there is no way to guarantee that buffers appear in a execbuf/batch in +the same order in all contexts. That is directly under control of +userspace, and a result of the sequence of GL calls that an application +makes. Which results in the potential for deadlock. The problem gets +more complex when you consider that the kernel may need to migrate the +buffer(s) into VRAM before the GPU operates on the buffer(s), which +may in turn require evicting some other buffers (and you don't want to +evict other buffers which are already queued up to the GPU), but for a +simplified understanding of the problem you can ignore this. + +The algorithm that the TTM graphics subsystem came up with for dealing with +this problem is quite simple. For each group of buffers (execbuf) that need +to be locked, the caller would be assigned a unique reservation id/ticket, +from a global counter. In case of deadlock while locking all the buffers +associated with a execbuf, the one with the lowest reservation ticket (i.e. +the oldest task) wins, and the one with the higher reservation id (i.e. the +younger task) unlocks all of the buffers that it has already locked, and then +tries again. + +In the RDBMS literature this deadlock handling approach is called wait/wound: +The older tasks waits until it can acquire the contended lock. The younger tasks +needs to back off and drop all the locks it is currently holding, i.e. the +younger task is wounded. + +Concepts +-------- + +Compared to normal mutexes two additional concepts/objects show up in the lock +interface for w/w mutexes: + +Acquire context: To ensure eventual forward progress it is important the a task +trying to acquire locks doesn't grab a new reservation id, but keeps the one it +acquired when starting the lock acquisition. This ticket is stored in the +acquire context. Furthermore the acquire context keeps track of debugging state +to catch w/w mutex interface abuse. + +W/w class: In contrast to normal mutexes the lock class needs to be explicit for +w/w mutexes, since it is required to initialize the acquire context. + +Furthermore there are three different class of w/w lock acquire functions: + +* Normal lock acquisition with a context, using ww_mutex_lock. + +* Slowpath lock acquisition on the contending lock, used by the wounded task + after having dropped all already acquired locks. These functions have the + _slow postfix. + + From a simple semantics point-of-view the _slow functions are not strictly + required, since simply calling the normal ww_mutex_lock functions on the + contending lock (after having dropped all other already acquired locks) will + work correctly. After all if no other ww mutex has been acquired yet there's + no deadlock potential and hence the ww_mutex_lock call will block and not + prematurely return -EDEADLK. The advantage of the _slow functions is in + interface safety: + - ww_mutex_lock has a __must_check int return type, whereas ww_mutex_lock_slow + has a void return type. Note that since ww mutex code needs loops/retries + anyway the __must_check doesn't result in spurious warnings, even though the + very first lock operation can never fail. + - When full debugging is enabled ww_mutex_lock_slow checks that all acquired + ww mutex have been released (preventing deadlocks) and makes sure that we + block on the contending lock (preventing spinning through the -EDEADLK + slowpath until the contended lock can be acquired). + +* Functions to only acquire a single w/w mutex, which results in the exact same + semantics as a normal mutex. This is done by calling ww_mutex_lock with a NULL + context. + + Again this is not strictly required. But often you only want to acquire a + single lock in which case it's pointless to set up an acquire context (and so + better to avoid grabbing a deadlock avoidance ticket). + +Of course, all the usual variants for handling wake-ups due to signals are also +provided. + +Usage +----- + +Three different ways to acquire locks within the same w/w class. Common +definitions for methods #1 and #2: + +static DEFINE_WW_CLASS(ww_class); + +struct obj { + struct ww_mutex lock; + /* obj data */ +}; + +struct obj_entry { + struct list_head head; + struct obj *obj; +}; + +Method 1, using a list in execbuf->buffers that's not allowed to be reordered. +This is useful if a list of required objects is already tracked somewhere. +Furthermore the lock helper can use propagate the -EALREADY return code back to +the caller as a signal that an object is twice on the list. This is useful if +the list is constructed from userspace input and the ABI requires userspace to +not have duplicate entries (e.g. for a gpu commandbuffer submission ioctl). + +int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx) +{ + struct obj *res_obj = NULL; + struct obj_entry *contended_entry = NULL; + struct obj_entry *entry; + + ww_acquire_init(ctx, &ww_class); + +retry: + list_for_each_entry (entry, list, head) { + if (entry->obj == res_obj) { + res_obj = NULL; + continue; + } + ret = ww_mutex_lock(&entry->obj->lock, ctx); + if (ret < 0) { + contended_entry = entry; + goto err; + } + } + + ww_acquire_done(ctx); + return 0; + +err: + list_for_each_entry_continue_reverse (entry, list, head) + ww_mutex_unlock(&entry->obj->lock); + + if (res_obj) + ww_mutex_unlock(&res_obj->lock); + + if (ret == -EDEADLK) { + /* we lost out in a seqno race, lock and retry.. */ + ww_mutex_lock_slow(&contended_entry->obj->lock, ctx); + res_obj = contended_entry->obj; + goto retry; + } + ww_acquire_fini(ctx); + + return ret; +} + +Method 2, using a list in execbuf->buffers that can be reordered. Same semantics +of duplicate entry detection using -EALREADY as method 1 above. But the +list-reordering allows for a bit more idiomatic code. + +int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx) +{ + struct obj_entry *entry, *entry2; + + ww_acquire_init(ctx, &ww_class); + + list_for_each_entry (entry, list, head) { + ret = ww_mutex_lock(&entry->obj->lock, ctx); + if (ret < 0) { + entry2 = entry; + + list_for_each_entry_continue_reverse (entry2, list, head) + ww_mutex_unlock(&entry2->obj->lock); + + if (ret != -EDEADLK) { + ww_acquire_fini(ctx); + return ret; + } + + /* we lost out in a seqno race, lock and retry.. */ + ww_mutex_lock_slow(&entry->obj->lock, ctx); + + /* + * Move buf to head of the list, this will point + * buf->next to the first unlocked entry, + * restarting the for loop. + */ + list_del(&entry->head); + list_add(&entry->head, list); + } + } + + ww_acquire_done(ctx); + return 0; +} + +Unlocking works the same way for both methods #1 and #2: + +void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx) +{ + struct obj_entry *entry; + + list_for_each_entry (entry, list, head) + ww_mutex_unlock(&entry->obj->lock); + + ww_acquire_fini(ctx); +} + +Method 3 is useful if the list of objects is constructed ad-hoc and not upfront, +e.g. when adjusting edges in a graph where each node has its own ww_mutex lock, +and edges can only be changed when holding the locks of all involved nodes. w/w +mutexes are a natural fit for such a case for two reasons: +- They can handle lock-acquisition in any order which allows us to start walking + a graph from a starting point and then iteratively discovering new edges and + locking down the nodes those edges connect to. +- Due to the -EALREADY return code signalling that a given objects is already + held there's no need for additional book-keeping to break cycles in the graph + or keep track off which looks are already held (when using more than one node + as a starting point). + +Note that this approach differs in two important ways from the above methods: +- Since the list of objects is dynamically constructed (and might very well be + different when retrying due to hitting the -EDEADLK wound condition) there's + no need to keep any object on a persistent list when it's not locked. We can + therefore move the list_head into the object itself. +- On the other hand the dynamic object list construction also means that the -EALREADY return + code can't be propagated. + +Note also that methods #1 and #2 and method #3 can be combined, e.g. to first lock a +list of starting nodes (passed in from userspace) using one of the above +methods. And then lock any additional objects affected by the operations using +method #3 below. The backoff/retry procedure will be a bit more involved, since +when the dynamic locking step hits -EDEADLK we also need to unlock all the +objects acquired with the fixed list. But the w/w mutex debug checks will catch +any interface misuse for these cases. + +Also, method 3 can't fail the lock acquisition step since it doesn't return +-EALREADY. Of course this would be different when using the _interruptible +variants, but that's outside of the scope of these examples here. + +struct obj { + struct ww_mutex ww_mutex; + struct list_head locked_list; +}; + +static DEFINE_WW_CLASS(ww_class); + +void __unlock_objs(struct list_head *list) +{ + struct obj *entry, *temp; + + list_for_each_entry_safe (entry, temp, list, locked_list) { + /* need to do that before unlocking, since only the current lock holder is + allowed to use object */ + list_del(&entry->locked_list); + ww_mutex_unlock(entry->ww_mutex) + } +} + +void lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx) +{ + struct obj *obj; + + ww_acquire_init(ctx, &ww_class); + +retry: + /* re-init loop start state */ + loop { + /* magic code which walks over a graph and decides which objects + * to lock */ + + ret = ww_mutex_lock(obj->ww_mutex, ctx); + if (ret == -EALREADY) { + /* we have that one already, get to the next object */ + continue; + } + if (ret == -EDEADLK) { + __unlock_objs(list); + + ww_mutex_lock_slow(obj, ctx); + list_add(&entry->locked_list, list); + goto retry; + } + + /* locked a new object, add it to the list */ + list_add_tail(&entry->locked_list, list); + } + + ww_acquire_done(ctx); + return 0; +} + +void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx) +{ + __unlock_objs(list); + ww_acquire_fini(ctx); +} + +Method 4: Only lock one single objects. In that case deadlock detection and +prevention is obviously overkill, since with grabbing just one lock you can't +produce a deadlock within just one class. To simplify this case the w/w mutex +api can be used with a NULL context. + +Implementation Details +---------------------- + +Design: + ww_mutex currently encapsulates a struct mutex, this means no extra overhead for + normal mutex locks, which are far more common. As such there is only a small + increase in code size if wait/wound mutexes are not used. + + In general, not much contention is expected. The locks are typically used to + serialize access to resources for devices. The only way to make wakeups + smarter would be at the cost of adding a field to struct mutex_waiter. This + would add overhead to all cases where normal mutexes are used, and + ww_mutexes are generally less performance sensitive. + +Lockdep: + Special care has been taken to warn for as many cases of api abuse + as possible. Some common api abuses will be caught with + CONFIG_DEBUG_MUTEXES, but CONFIG_PROVE_LOCKING is recommended. + + Some of the errors which will be warned about: + - Forgetting to call ww_acquire_fini or ww_acquire_init. + - Attempting to lock more mutexes after ww_acquire_done. + - Attempting to lock the wrong mutex after -EDEADLK and + unlocking all mutexes. + - Attempting to lock the right mutex after -EDEADLK, + before unlocking all mutexes. + + - Calling ww_mutex_lock_slow before -EDEADLK was returned. + + - Unlocking mutexes with the wrong unlock function. + - Calling one of the ww_acquire_* twice on the same context. + - Using a different ww_class for the mutex than for the ww_acquire_ctx. + - Normal lockdep errors that can result in deadlocks. + + Some of the lockdep errors that can result in deadlocks: + - Calling ww_acquire_init to initialize a second ww_acquire_ctx before + having called ww_acquire_fini on the first. + - 'normal' deadlocks that can occur. + +FIXME: Update this section once we have the TASK_DEADLOCK task state flag magic +implemented. diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt index 4aaf0dfb0cb8..d62bea6796da 100644 --- a/Documentation/x86/early-microcode.txt +++ b/Documentation/x86/early-microcode.txt @@ -11,7 +11,8 @@ file and loaded to CPUs during boot time. The format of the combined initrd image is microcode in cpio format followed by the initrd image (maybe compressed). Kernel parses the combined initrd image during boot time. The microcode file in cpio name space is: -kernel/x86/microcode/GenuineIntel.bin +on Intel: kernel/x86/microcode/GenuineIntel.bin +on AMD : kernel/x86/microcode/AuthenticAMD.bin During BSP boot (before SMP starts), if the kernel finds the microcode file in the initrd file, it parses the microcode and saves matching microcode in memory. @@ -34,10 +35,8 @@ original initrd image /boot/initrd-3.5.0.img. mkdir initrd cd initrd -mkdir kernel -mkdir kernel/x86 -mkdir kernel/x86/microcode -cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin -find .|cpio -oc >../ucode.cpio +mkdir -p kernel/x86/microcode +cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin (or AuthenticAMD.bin) +find . | cpio -o -H newc >../ucode.cpio cd .. cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img |