From c6cc142dac52e62e1e8a2aff5de1300202b96c66 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Wed, 17 Apr 2013 20:18:56 +0200 Subject: xen-blkback: use balloon pages for all mappings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Using balloon pages for all granted pages allows us to simplify the logic in blkback, especially in the xen_blkbk_map function, since now we can decide if we want to map a grant persistently or not after we have actually mapped it. This could not be done before because persistent grants used ballooned pages, whereas non-persistent grants used pages from the kernel. This patch also introduces several changes, the first one is that the list of free pages is no longer global, now each blkback instance has it's own list of free pages that can be used to map grants. Also, a run time parameter (max_buffer_pages) has been added in order to tune the maximum number of free pages each blkback instance will keep in it's buffer. Signed-off-by: Roger Pau Monné Cc: xen-devel@lists.xen.org Cc: Konrad Rzeszutek Wilk Signed-off-by: Konrad Rzeszutek Wilk --- Documentation/ABI/stable/sysfs-bus-xen-backend | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-bus-xen-backend b/Documentation/ABI/stable/sysfs-bus-xen-backend index 3d5951c..e04afe0 100644 --- a/Documentation/ABI/stable/sysfs-bus-xen-backend +++ b/Documentation/ABI/stable/sysfs-bus-xen-backend @@ -73,3 +73,11 @@ KernelVersion: 3.0 Contact: Konrad Rzeszutek Wilk Description: Number of sectors written by the frontend. + +What: /sys/module/xen_blkback/parameters/max_buffer_pages +Date: March 2013 +KernelVersion: 3.10 +Contact: Roger Pau Monné +Description: + Maximum number of free pages to keep in each block + backend buffer. -- cgit v1.1 From 3f3aad5e6686ed49242bbf86de378b39f119ec9d Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Wed, 17 Apr 2013 20:18:57 +0200 Subject: xen-blkback: implement LRU mechanism for persistent grants MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This mechanism allows blkback to change the number of grants persistently mapped at run time. The algorithm uses a simple LRU mechanism that removes (if needed) the persistent grants that have not been used since the last LRU run, or if all grants have been used it removes the first grants in the list (that are not in use). The algorithm allows the user to change the maximum number of persistent grants, by changing max_persistent_grants in sysfs. Since we are storing the persistent grants used inside the request struct (to be able to mark them as "unused" when unmapping), we no longer need the bitmap (unmap_seg). Signed-off-by: Roger Pau Monné Cc: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xen.org Signed-off-by: Konrad Rzeszutek Wilk --- Documentation/ABI/stable/sysfs-bus-xen-backend | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-bus-xen-backend b/Documentation/ABI/stable/sysfs-bus-xen-backend index e04afe0..947db11 100644 --- a/Documentation/ABI/stable/sysfs-bus-xen-backend +++ b/Documentation/ABI/stable/sysfs-bus-xen-backend @@ -81,3 +81,13 @@ Contact: Roger Pau Monné Description: Maximum number of free pages to keep in each block backend buffer. + +What: /sys/module/xen_blkback/parameters/max_persistent_grants +Date: March 2013 +KernelVersion: 3.10 +Contact: Roger Pau Monné +Description: + Maximum number of grants to map persistently in + blkback. If the frontend tries to use more than + max_persistent_grants, the LRU kicks in and starts + removing 5% of max_persistent_grants every 100ms. -- cgit v1.1 From 3512f976d252bd5d07d04e9e157f0cd210c959a0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= Date: Wed, 24 Apr 2013 18:52:34 +0300 Subject: drm: Add struct drm_rect and assorted utility functions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit struct drm_rect represents a simple rectangle. The utility functions are there to help driver writers. v2: Moved the region stuff into its own file, made the smaller funcs static inline, used 64bit maths in the scaled clipping function to avoid overflows (instead it will saturate to INT_MIN or INT_MAX). v3: Renamed drm_region to drm_rect, drm_region_clip to drm_rect_intersect, and drm_region_subsample to drm_rect_downscale. v4: Renamed some function parameters, improve kernel-doc comments a bit, and actually generate documentation for drm_rect.[ch]. v5: s/RETUTRNS/RETURNS/ Reviewed-by: Laurent Pinchart Reviewed-by: Chris Wilson Signed-off-by: Ville Syrjälä Acked-by: Dave Airlie Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index f9df3b8..7c7af25 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -1653,6 +1653,8 @@ void intel_crt_init(struct drm_device *dev) KMS API Functions !Edrivers/gpu/drm/drm_crtc.c +!Edrivers/gpu/drm/drm_rect.c +!Finclude/drm/drm_rect.h -- cgit v1.1 From 4f3549d72d1b5c90ecc7e673402f38f4486d22c2 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 2 May 2013 22:15:29 +0200 Subject: Driver core: Add offline/online device operations In some cases, graceful hot-removal of devices is not possible, although in principle the devices in question support hotplug. For example, that may happen for the last CPU in the system or for memory modules holding kernel memory. In those cases it is nice to be able to check if the given device can be gracefully hot-removed before triggering a removal procedure that cannot be aborted or reversed. Unfortunately, however, the kernel currently doesn't provide any support for that. To address that deficiency, introduce support for offline and online operations that can be performed on devices, respectively, before a hot-removal and in case when it is necessary (or convenient) to put a device back online after a successful offline (that has not been followed by removal). The idea is that the offline will fail whenever the given device cannot be gracefully removed from the system and it will not be allowed to use the device after a successful offline (until a subsequent online) in analogy with the existing CPU offline/online mechanism. For now, the offline and online operations are introduced at the bus type level, as that should be sufficient for the most urgent use cases (CPUs and memory modules). In the future, however, the approach may be extended to cover some more complicated device offline/online scenarios involving device drivers etc. The lock_device_hotplug() and unlock_device_hotplug() functions are introduced because subsequent patches need to put larger pieces of code under device_hotplug_lock to prevent race conditions between device offline and removal from happening. Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman Reviewed-by: Toshi Kani --- Documentation/ABI/testing/sysfs-devices-online | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-devices-online (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-online b/Documentation/ABI/testing/sysfs-devices-online new file mode 100644 index 0000000..f990026 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-online @@ -0,0 +1,20 @@ +What: /sys/devices/.../online +Date: April 2013 +Contact: Rafael J. Wysocki +Description: + The /sys/devices/.../online attribute is only present for + devices whose bus types provide .online() and .offline() + callbacks. The number read from it (0 or 1) reflects the value + of the device's 'offline' field. If that number is 1 and '0' + (or 'n', or 'N') is written to this file, the device bus type's + .offline() callback is executed for the device and (if + successful) its 'offline' field is updated accordingly. In + turn, if that number is 0 and '1' (or 'y', or 'Y') is written to + this file, the device bus type's .online() callback is executed + for the device and (if successful) its 'offline' field is + updated as appropriate. + + After a successful execution of the bus type's .offline() + callback the device cannot be used for any purpose until either + it is removed (i.e. device_del() is called for it), or its bus + type's .online() is exeucted successfully. -- cgit v1.1 From 683058e315f00a216fd6c79df4f63bc9945ca434 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Fri, 3 May 2013 00:26:16 +0200 Subject: ACPI / hotplug: Use device offline/online for graceful hot-removal Modify the generic ACPI hotplug code to be able to check if devices scheduled for hot-removal may be gracefully removed from the system using the device offline/online mechanism introduced previously. Namely, make acpi_scan_hot_remove() handling device hot-removal call device_offline() for all physical companions of the ACPI device nodes involved in the operation and check the results. If any of the device_offline() calls fails, the function will not progress to the removal phase (which cannot be aborted), unless its (new) force argument is set (in case of a failing offline it will put the devices offlined by it back online). In support of 'forced' device hot-removal, add a new sysfs attribute 'force_remove' that will reside under /sys/firmware/acpi/hotplug/. Signed-off-by: Rafael J. Wysocki Reviewed-by: Toshi Kani --- Documentation/ABI/testing/sysfs-firmware-acpi | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi index ce9bee9..b4436cca 100644 --- a/Documentation/ABI/testing/sysfs-firmware-acpi +++ b/Documentation/ABI/testing/sysfs-firmware-acpi @@ -44,6 +44,16 @@ Description: or 0 (unset). Attempts to write any other values to it will cause -EINVAL to be returned. +What: /sys/firmware/acpi/hotplug/force_remove +Date: May 2013 +Contact: Rafael J. Wysocki +Description: + The number in this file (0 or 1) determines whether (1) or not + (0) the ACPI subsystem will allow devices to be hot-removed even + if they cannot be put offline gracefully (from the kernel's + viewpoint). That number can be changed by writing a boolean + value to this file. + What: /sys/firmware/acpi/interrupts/ Date: February 2008 Contact: Len Brown -- cgit v1.1 From 40b1936efebdb9c31d9ed6fe59055f71ea366509 Mon Sep 17 00:00:00 2001 From: "Andrii.Tseglytskyi" Date: Thu, 2 May 2013 12:20:10 -0500 Subject: regulator: Introduce TI Adaptive Body Bias(ABB) on-chip LDO driver Adaptive Body Biasing (ABB) modulates transistor bias voltages dynamically in order to optimize switching speed versus leakage. Texas Instruments' SmartReflex 2 technology provides support for this power management technique with Forward Body Biasing (FBB) and Reverse Body Biasing (RBB). These modulate the body voltage of transistor cells or blocks dynamically to gain performance and reduce leakage. TI's SmartReflex white paper[1] has further information for usage in conjunction with other power management techniques. The application of FBB/RBB technique is determined for each unique device in some process nodes, whereas, they are mandated on other process nodes. In a nutshell, ABB technique is implemented on TI SoC as an on-chip LDO which has ABB module controlling the bias voltage. However, the voltage is unique per device. These vary per SoC family and the manner in which these techniques are used may vary depending on the Operating Performance Point (OPP) voltage targeted. For example: OMAP3630/OMAP4430: certain OPPs mandate usage of FBB independent of devices. OMAP4460/OMAP4470: certain OPPs mandate usage of FBB, while others may optionally use FBB or optimization with RBB. OMAP5: ALL OPPs may optionally use ABB, and ABB biasing voltage is influenced by vset fused in s/w and requiring s/w override of default values. Further, two generations of ABB module are used in various TI SoCs. They have remained mostly register field compatible, however the register offset had switched between versions. We introduce ABB LDO support in the form of a regulator which is controlled by voltages denoting the desired Operating Performance Point which is targeted. However, since ABB transition is part of OPP change sequence, the sequencing required to ensure sane operation w.r.t OPP change is left to the controlling driver (example: cpufreq SoC driver) using standard regulator operations. The driver supports all ABB modes and ability to override ABB LDO vset control efuse based ABB mode detection etc. Current implementation is heavily influenced by the original patch series [2][3] from Mike Turquette. However, the current implementation supports only device tree based information. [1] http://www.ti.com/pdfs/wtbu/smartreflex_whitepaper.pdf [2] http://marc.info/?l=linux-omap&m=134931341818379&w=2 [3] http://marc.info/?l=linux-arm-kernel&m=134931402406853&w=2 [nm@ti.com: co-developer] Signed-off-by: Nishanth Menon Signed-off-by: Andrii.Tseglytskyi Signed-off-by: Mark Brown --- .../bindings/regulator/ti-abb-regulator.txt | 128 +++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt new file mode 100644 index 0000000..2e57a33 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt @@ -0,0 +1,128 @@ +Adaptive Body Bias(ABB) SoC internal LDO regulator for Texas Instruments SoCs + +Required Properties: +- compatible: Should be one of: + - "ti,abb-v1" for older SoCs like OMAP3 + - "ti,abb-v2" for newer SoCs like OMAP4, OMAP5 +- reg: Address and length of the register set for the device. It contains + the information of registers in the same order as described by reg-names +- reg-names: Should contain the reg names + - "base-address" - contains base address of ABB module + - "int-address" - contains address of interrupt register for ABB module + (also see Optional properties) +- #address-cell: should be 0 +- #size-cell: should be 0 +- clocks: should point to the clock node used by ABB module +- ti,settling-time: Settling time in uSecs from SoC documentation for ABB module + to settle down(target time for SR2_WTCNT_VALUE). +- ti,clock-cycles: SoC specific data about count of system ti,clock-cycles used for + computing settling time from SoC Documentation for ABB module(clock + cycles for SR2_WTCNT_VALUE). +- ti,tranxdone-status-mask: Mask to the int-register to write-to-clear mask + indicating LDO tranxdone (operation complete). +- ti,abb_info: An array of 6-tuples u32 items providing information about ABB + configuration needed per operational voltage of the device. + Each item consists of the following in the same order: + volt: voltage in uV - Only used to index ABB information. + ABB mode: one of the following: + 0-bypass + 1-Forward Body Bias(FBB) + 3-Reverse Body Bias(RBB) + efuse: (see Optional properties) + RBB enable efuse Mask: (See Optional properties) + FBB enable efuse Mask: (See Optional properties) + Vset value efuse Mask: (See Optional properties) + + NOTE: If more than 1 entry is present, then regulator is setup to change + voltage, allowing for various modes to be selected indexed off + the regulator. Further, ABB LDOs are considered always-on by + default. + +Optional Properties: +- reg-names: In addition to the required properties, the following are optional + - "efuse-address" - Contains efuse base address used to pick up ABB info. + - "ldo-address" - Contains address of ABB LDO overide register address. + "efuse-address" is required for this. +- ti,ldovbb-vset-mask - Required if ldo-address is set, mask for LDO override + register to provide override vset value. +- ti,ldovbb-override-mask - Required if ldo-address is set, mask for LDO + override register to enable override vset value. +- ti,abb_opp_sel: Addendum to the description in required properties + efuse: Mandatory if 'efuse-address' register is defined. Provides offset + from efuse-address to pick up ABB characteristics. Set to 0 if + 'efuse-address' is not defined. + RBB enable efuse Mask: Optional if 'efuse-address' register is defined. + 'ABB mode' is force set to RBB mode if value at "efuse-address" + + efuse maps to RBB mask. Set to 0 to ignore this. + FBB enable efuse Mask: Optional if 'efuse-address' register is defined. + 'ABB mode' is force set to FBB mode if value at "efuse-address" + + efuse maps to FBB mask (valid only if RBB mask does not match) + Set to 0 to ignore this. + Vset value efuse Mask: Mandatory if ldo-address is set. Picks up from + efuse the value to set in 'ti,ldovbb-vset-mask' at ldo-address. + +Example #1: Simplest configuration (no efuse data, hard coded ABB table): +abb_x: regulator-abb-x { + compatible = "ti,abb-v1"; + regulator-name = "abb_x"; + #address-cell = <0>; + #size-cells = <0>; + reg = <0x483072f0 0x8>, <0x48306818 0x4>; + reg-names = "base-address", "int-address"; + ti,tranxdone-status-mask = <0x4000000>; + clocks = <&sysclk>; + ti,settling-time = <30>; + ti,clock-cycles = <8>; + ti,abb_info = < + /* uV ABB efuse rbb_m fbb_m vset_m */ + 1012500 0 0 0 0 0 /* Bypass */ + 1200000 3 0 0 0 0 /* RBB mandatory */ + 1320000 1 0 0 0 0 /* FBB mandatory */ + >; +}; + +Example #2: Efuse bits contain ABB mode setting (no LDO override capability) +abb_y: regulator-abb-y { + compatible = "ti,abb-v2"; + regulator-name = "abb_y"; + #address-cell = <0>; + #size-cells = <0>; + reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>, <0x4A002268 0x8>; + reg-names = "base-address", "int-address", "efuse-address"; + ti,tranxdone-status-mask = <0x4000000>; + clocks = <&sysclk>; + ti,settling-time = <50>; + ti,clock-cycles = <16>; + ti,abb_info = < + /* uV ABB efuse rbb_m fbb_m vset_m */ + 975000 0 0 0 0 0 /* Bypass */ + 1012500 0 0 0x40000 0 0 /* RBB optional */ + 1200000 0 0x4 0 0x40000 0 /* FBB optional */ + 1320000 1 0 0 0 0 /* FBB mandatory */ + >; +}; + +Example #3: Efuse bits contain ABB mode setting and LDO override capability +abb_z: regulator-abb-z { + compatible = "ti,abb-v2"; + regulator-name = "abb_z"; + #address-cell = <0>; + #size-cells = <0>; + reg = <0x4ae07ce4 0x8>, <0x4ae06010 0x4>, + <0x4a002194 0x8>, <0x4ae0C314 0x4>; + reg-names = "base-address", "int-address", + "efuse-address", "ldo-address"; + ti,tranxdone-status-mask = <0x8000000>; + /* LDOVBBMM_MUX_CTRL */ + ti,ldovbb-override-mask = <0x400>; + /* LDOVBBMM_VSET_OUT */ + ti,ldovbb-vset-mask = <0x1F>; + clocks = <&sysclk>; + ti,settling-time = <50>; + ti,clock-cycles = <16>; + ti,abb_info = < + /* uV ABB efuse rbb_m fbb_m vset_m */ + 975000 0 0 0 0 0 /* Bypass */ + 1200000 0 0x4 0 0x40000 0x1f00 /* FBB optional, vset */ + >; +}; -- cgit v1.1 From 1b7c8b350fd4751051f0abba040a29b72f829665 Mon Sep 17 00:00:00 2001 From: Marek Belisko Date: Thu, 25 Apr 2013 15:13:13 +0200 Subject: ASoC: spdif_transmitter: Add DT support. Add devicetree support for this dummy audio soc driver. Signed-off-by: Michal Bachraty Signed-off-by: Marek Belisko Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/spdif-transmitter.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/spdif-transmitter.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/spdif-transmitter.txt b/Documentation/devicetree/bindings/sound/spdif-transmitter.txt new file mode 100644 index 0000000..55a8584 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/spdif-transmitter.txt @@ -0,0 +1,10 @@ +Device-Tree bindings for dummy spdif transmitter + +Required properties: + - compatible: should be "linux,spdif-dit". + +Example node: + + codec: spdif-transmitter { + compatible = "linux,spdif-dit"; + }; -- cgit v1.1 From f9c8ba8965597bb45b95014338d59ade15d53e93 Mon Sep 17 00:00:00 2001 From: Marek Belisko Date: Thu, 25 Apr 2013 15:13:14 +0200 Subject: ASoC: spdif_receiver: Add DT support. Add devicetree support for this dummy audio soc driver. Signed-off-by: Michal Bachraty Signed-off-by: Marek Belisko Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/spdif-receiver.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/spdif-receiver.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/spdif-receiver.txt b/Documentation/devicetree/bindings/sound/spdif-receiver.txt new file mode 100644 index 0000000..80f807b --- /dev/null +++ b/Documentation/devicetree/bindings/sound/spdif-receiver.txt @@ -0,0 +1,10 @@ +Device-Tree bindings for dummy spdif receiver + +Required properties: + - compatible: should be "linux,spdif-dir". + +Example node: + + codec: spdif-receiver { + compatible = "linux,spdif-dir"; + }; -- cgit v1.1 From 6e2b07a172b6ed98c7cdc301333b2d9f86c11880 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 16 Apr 2013 21:38:29 +0200 Subject: ARM: nomadik: convert all clocks except timer to dt This moves all Nomadik clocks except the one used for the timer/clocksource over to the device tree. Acked-by: Mike Turquette Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/arm/ste-nomadik.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/ste-nomadik.txt b/Documentation/devicetree/bindings/arm/ste-nomadik.txt index 19bca04..6256ec3 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: -- cgit v1.1 From 62477adf5f4ede918a97e648a5173b00bbbb17cc Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Mon, 13 May 2013 13:30:56 +0800 Subject: ASoC: mxs: move to use generic DMA helper With mxs-dma converted to generic DMA bindings, let's move mxs-pcm to use it by removing flages SND_DMAENGINE_PCM_FLAG_NO_DT and SND_DMAENGINE_PCM_FLAG_COMPAT. As the result, those mxs custom dma params code can be removed now. Signed-off-by: Shawn Guo Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/mxs-saif.txt | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/mxs-saif.txt b/Documentation/devicetree/bindings/sound/mxs-saif.txt index c37ba61..7ba07a1 100644 --- a/Documentation/devicetree/bindings/sound/mxs-saif.txt +++ b/Documentation/devicetree/bindings/sound/mxs-saif.txt @@ -3,8 +3,11 @@ Required properties: - compatible: Should be "fsl,-saif" - reg: Should contain registers location and length -- interrupts: Should contain ERROR and DMA interrupts -- fsl,saif-dma-channel: APBX DMA channel for the SAIF +- interrupts: Should contain ERROR interrupt number +- dmas: DMA specifier, consisting of a phandle to DMA controller node + and SAIF DMA channel ID. + Refer to dma.txt and fsl-mxs-dma.txt for details. +- dma-names: Must be "rx-tx". Optional properties: - fsl,saif-master: phandle to the master SAIF. It's only required for @@ -23,14 +26,16 @@ aliases { saif0: saif@80042000 { compatible = "fsl,imx28-saif"; reg = <0x80042000 2000>; - interrupts = <59 80>; - fsl,saif-dma-channel = <4>; + interrupts = <59>; + dmas = <&dma_apbx 4>; + dma-names = "rx-tx"; }; saif1: saif@80046000 { compatible = "fsl,imx28-saif"; reg = <0x80046000 2000>; - interrupts = <58 81>; - fsl,saif-dma-channel = <5>; + interrupts = <58>; + dmas = <&dma_apbx 5>; + dma-names = "rx-tx"; fsl,saif-master = <&saif0>; }; -- cgit v1.1 From cee22a15052faa817e3ec8985a28154d3fabc7aa Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Mon, 8 Apr 2013 16:45:40 +0530 Subject: workqueues: Introduce new flag WQ_POWER_EFFICIENT for power oriented workqueues Workqueues can be performance or power-oriented. Currently, most workqueues are bound to the CPU they were created on. This gives good performance (due to cache effects) at the cost of potentially waking up otherwise idle cores (Idle from scheduler's perspective. Which may or may not be physically idle) just to process some work. To save power, we can allow the work to be rescheduled on a core that is already awake. Workqueues created with the WQ_UNBOUND flag will allow some power savings. However, we don't change the default behaviour of the system. To enable power-saving behaviour, a new config option CONFIG_WQ_POWER_EFFICIENT needs to be turned on. This option can also be overridden by the workqueue.power_efficient boot parameter. tj: Updated config description and comments. Renamed CONFIG_WQ_POWER_EFFICIENT to CONFIG_WQ_POWER_EFFICIENT_DEFAULT. Signed-off-by: Viresh Kumar Reviewed-by: Amit Kucheria Signed-off-by: Tejun Heo --- Documentation/kernel-parameters.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c3bfacb..37dfd72 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3320,6 +3320,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. -- cgit v1.1 From 9138125beabbb76b4a373d4a619870f6f5d86fc5 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Tue, 14 May 2013 13:52:38 -0700 Subject: blk-throttle: implement proper hierarchy support With the recent updates, blk-throttle is finally ready for proper hierarchy support. Dispatching now honors service_queue->parent_sq and propagates correctly. The only thing missing is setting ->parent_sq correctly so that throtl_grp hierarchy matches the cgroup hierarchy. This patch updates throtl_pd_init() such that service_queues form the same hierarchy as the cgroup hierarchy if sane_behavior is enabled. As this concludes proper hierarchy support for blkcg, the shameful .broken_hierarchy tag is removed from blkio_subsys. v2: Updated blkio-controller.txt as suggested by Vivek. Signed-off-by: Tejun Heo Acked-by: Vivek Goyal Cc: Li Zefan --- Documentation/cgroups/blkio-controller.txt | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index da272c8..cd556b9 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt @@ -94,11 +94,13 @@ Throttling/Upper Limit policy Hierarchical Cgroups ==================== -- Currently only CFQ supports hierarchical groups. For throttling, - cgroup interface does allow creation of hierarchical cgroups and - internally it treats them as flat hierarchy. - If somebody created a hierarchy like as follows. +Both CFQ and throttling implement hierarchy support; however, +throttling's hierarchy support is enabled iff "sane_behavior" is +enabled from cgroup side, which currently is a development option and +not publicly available. + +If somebody created a hierarchy like as follows. root / \ @@ -106,21 +108,20 @@ Hierarchical Cgroups | test3 - CFQ will handle the hierarchy correctly but and throttling will - practically treat all groups at same level. For details on CFQ - hierarchy support, refer to Documentation/block/cfq-iosched.txt. - Throttling will treat the hierarchy as if it looks like the - following. +CFQ by default and throttling with "sane_behavior" will handle the +hierarchy correctly. For details on CFQ hierarchy support, refer to +Documentation/block/cfq-iosched.txt. For throttling, all limits apply +to the whole subtree while all statistics are local to the IOs +directly generated by tasks in that cgroup. + +Throttling without "sane_behavior" enabled from cgroup side will +practically treat all groups at same level as if it looks like the +following. pivot / / \ \ root test1 test2 test3 - Nesting cgroups, while allowed, isn't officially supported and blkio - genereates warning when cgroups nest. Once throttling implements - hierarchy support, hierarchy will be supported and the warning will - be removed. - Various user visible config options =================================== CONFIG_BLK_CGROUP -- cgit v1.1 From fe0a797a6b42d9ad0ed063eaef705da1eb3c8147 Mon Sep 17 00:00:00 2001 From: Gabriel Date: Wed, 24 Apr 2013 19:51:02 +0200 Subject: bcache: clarify free/available/unused space Don't describe bcache_available_percent as free space but as non-writeback space. Describe priority_stats in more detail and point to that for total bcache occupation. Signed-off-by: Gabriel de Perthuis Signed-off-by: Kent Overstreet --- Documentation/bcache.txt | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bcache.txt b/Documentation/bcache.txt index 77db880..b3a7e7d 100644 --- a/Documentation/bcache.txt +++ b/Documentation/bcache.txt @@ -319,7 +319,10 @@ cache<0..n> Symlink to each of the cache devices comprising this cache set. cache_available_percent - Percentage of cache device free. + Percentage of cache device which doesn't contain dirty data, and could + potentially be used for writeback. This doesn't mean this space isn't used + for clean cached data; the unused statistic (in priority_stats) is typically + much lower. clear_stats Clears the statistics associated with this cache @@ -423,8 +426,11 @@ nbuckets Total buckets in this cache priority_stats - Statistics about how recently data in the cache has been accessed. This can - reveal your working set size. + Statistics about how recently data in the cache has been accessed. + This can reveal your working set size. Unused is the percentage of + the cache that doesn't contain any data. Metadata is bcache's + metadata overhead. Average is the average priority of cache buckets. + Next is a list of quantiles with the priority threshold of each. written Sum of all data that has been written to the cache; comparison with -- cgit v1.1 From 3b656fed6ff65d6d268da9ed0760c2a58d125771 Mon Sep 17 00:00:00 2001 From: Christian Daudt Date: Thu, 9 May 2013 22:21:01 +0100 Subject: ARM: 7716/1: bcm281xx: Add L2 support for Rev A2 chips Rev A2 SoCs have an unorthodox memory re-mapping and this needs to be reflected in the cache operations. This patch adds new outer cache functions for the l2x0 driver to support this SoC revision. It also adds a new compatible value for the cache to enable this functionality. Updates from V1: - remove section 1 altogether and note that in comments - simplify section selection caused by section 1 removal - BUG_ON just in case section 1 shows up Signed-off-by: Christian Daudt Reviewed-by: Will Deacon Acked-by: Olof Johansson Signed-off-by: Russell King --- Documentation/devicetree/bindings/arm/l2cc.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt index cbef09b..69ddf9f 100644 --- a/Documentation/devicetree/bindings/arm/l2cc.txt +++ b/Documentation/devicetree/bindings/arm/l2cc.txt @@ -16,6 +16,9 @@ Required properties: performs the same operation). "marvell,"aurora-outer-cache: Marvell Controller designed to be compatible with the ARM one with outer cache mode. + "bcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an + offset needs to be added to the address before passing down to the L2 + cache controller - cache-unified : Specifies the cache is a unified cache. - cache-level : Should be set to 2 for a level 2 cache. - reg : Physical base address and size of cache controller's memory mapped -- cgit v1.1 From 496c8a0bbb726c2608b3b1318d231ab04a9a2ec3 Mon Sep 17 00:00:00 2001 From: Mark Jackson Date: Fri, 19 Apr 2013 21:08:28 +0100 Subject: ARM: OMAP2+: Allow NAND transfer mode to be specified in DT OMAP devices support various NAND transfer modes. Currently all device-tree definitions will use the default "prefetch polled" mode, so this patch enables the transfer mode to be specified in the device-tree. Signed-off-by: Mark Jackson Acked-by: Pekon Gupta Signed-off-by: Tony Lindgren --- Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index 6a983c1..df338cb 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>; -- cgit v1.1 From f40739faba8e804cf46505869ab98ad7c4a88833 Mon Sep 17 00:00:00 2001 From: Jon Hunter Date: Tue, 30 Apr 2013 09:11:22 -0500 Subject: ARM: dts: OMAP2+: Simplify NAND support Commit 8c8a777 (ARM: OMAP2+: Add function to read GPMC settings from device-tree) added a device-tree property "gpmc,device-nand" to indicate is the GPMC child device is NAND. This commit should have updated the GPMC NAND documentation (Documentation/devicetree/bindings/mtd/gpmc-nand.txt) to list the property "gpmc,device-nand" as a required property and also updated the example. However, this property is redundant and not needed because the GPMC child device node for NAND is called "nand". Therefore, remove this property. Signed-off-by: Jon Hunter Signed-off-by: Tony Lindgren --- Documentation/devicetree/bindings/bus/ti-gpmc.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt index 4b87ea1..704be93 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 -- cgit v1.1 From 1fbeeba35e1a25f1a7598e0f5d1433c18084e96a Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 17 May 2013 15:08:41 +0200 Subject: block: remove refs to XD disks from documentation Commit d1a6f4f19728d6e90480e53601a90fc9f6a348ad "block: delete super ancient PC-XT driver for 1980's hardware" deleted the XD disk driver, but there are still a few references to it in the documentation directory. Delete the remnants and thus also free up the major block device 13 for reuse. Cc: Paul Gortmaker Cc: Jens Axboe Signed-off-by: Linus Walleij Signed-off-by: Jens Axboe --- Documentation/devices.txt | 8 ++------ Documentation/kernel-parameters.txt | 3 --- Documentation/m68k/kernel-options.txt | 2 -- 3 files changed, 2 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 08f01e7..b901591 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -498,12 +498,8 @@ Your cooperation is appreciated. Each device type has 5 bits (32 minors). - 13 block 8-bit MFM/RLL/IDE controller - 0 = /dev/xda First XT disk whole disk - 64 = /dev/xdb Second XT disk whole disk - - Partitions are handled in the same way as IDE disks - (see major number 3). + 13 block Previously used for the XT disk (/dev/xdN) + Deleted in kernel v3.9. 14 char Open Sound System (OSS) 0 = /dev/mixer Mixer control diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c3bfacb..5469dbf 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3330,9 +3330,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. plus one apbt timer for broadcast timer. x86_mrst_timer=apbt_only | lapic_and_apbt - xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks. - xd_geo= See header of drivers/block/xd.c. - xen_emul_unplug= [HW,X86,XEN] Unplug Xen emulated devices Format: [unplug0,][unplug1] diff --git a/Documentation/m68k/kernel-options.txt b/Documentation/m68k/kernel-options.txt index 97d45f2..eaf32a1 100644 --- a/Documentation/m68k/kernel-options.txt +++ b/Documentation/m68k/kernel-options.txt @@ -80,8 +80,6 @@ Valid names are: /dev/sdd: -> 0x0830 (forth SCSI disk) /dev/sde: -> 0x0840 (fifth SCSI disk) /dev/fd : -> 0x0200 (floppy disk) - /dev/xda: -> 0x0c00 (first XT disk, unused in Linux/m68k) - /dev/xdb: -> 0x0c40 (second XT disk, unused in Linux/m68k) The name must be followed by a decimal number, that stands for the partition number. Internally, the value of the number is just -- cgit v1.1 From d400f209b4afe4a196baac276128eccac6a11b31 Mon Sep 17 00:00:00 2001 From: Venu Byravarasu Date: Thu, 16 May 2013 19:42:55 +0530 Subject: ARM: tegra: finalize USB EHCI and PHY bindings The existing Tegra USB bindings have a few issues: 1) Many properties are documented as being part of the EHCI controller node, yet they apply more to the PHY device. They should be moved. 2) Some registers in PHY1 are shared with PHY3, and hence PHY3 needs a reg entry to point at PHY1's register space. We can't assume the PHY1 driver is present, so the PHY3 driver will directly access those registers. 3) The list of clocks required by the PHY was missing some required entries. 4) UTMI PHY Timing parameters are added 5) VBUS control is now specified using a regulator rather than a plain GPIO 6) Added nvidia,is-wired property to indicate whether the device is hard wired on the board, or pluggable. This patch fixes the binding definition to resolve these issues. Signed-off-by: Venu Byravarasu Signed-off-by: Stephen Warren --- .../bindings/usb/nvidia,tegra20-ehci.txt | 27 +++----------- .../bindings/usb/nvidia,tegra20-usb-phy.txt | 41 ++++++++++++++++++++-- 2 files changed, 43 insertions(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt index 34c9528..df09330 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 6bdaba2..c4c9e9e 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 -- cgit v1.1 From 3cc7587b30032b7c4dd9610a55a77519e84da7db Mon Sep 17 00:00:00 2001 From: Rami Rosen Date: Fri, 17 May 2013 09:10:34 +0000 Subject: Documentation/sysctl/net.txt: fix (attribute removal). This patch removes mentioning the sysfsf net_device weight attribute (class/net//weight) in Documentation/sysctl/net.txt, since the net sysfs weight attribute was removed by the following patch: [NET]: Make NAPI polling independent of struct net_device objects bea3348eef27e6044b6161fd04c3152215f96411 Signed-off-by: Rami Rosen Signed-off-by: David S. Miller --- Documentation/sysctl/net.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index 98335b7..c1f8640 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -93,8 +93,7 @@ netdev_budget Maximum number of packets taken from all interfaces in one polling cycle (NAPI poll). In one polling cycle interfaces which are registered to polling are -probed in a round-robin manner. The limit of packets in one such probe can be -set per-device via sysfs class/net//weight . +probed in a round-robin manner. netdev_max_backlog ------------------ -- cgit v1.1 From d781009ca6bb5b9711c74700242855e0a70ee7a3 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Mon, 25 Mar 2013 00:11:27 +0000 Subject: mfd: Add device tree bindings for Arizona class devices Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/mfd/arizona.txt | 62 +++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/arizona.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt new file mode 100644 index 0000000..0e295c9 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -0,0 +1,62 @@ +Wolfson Arizona class audio SoCs + +These devices are audio SoCs with extensive digital capabilites and a range +of analogue I/O. + +Required properties: + + - compatible : one of the following chip-specific strings: + "wlf,wm5102" + "wlf,wm5110" + - reg : I2C slave address when connected using I2C, chip select number when + using SPI. + + - interrupts : The interrupt line the /IRQ signal for the device is + connected to. + - interrupt-controller : Arizona class devices contain interrupt controllers + and may provide interrupt services to other devices. + - interrupt-parent : The parent interrupt controller. + - #interrupt-cells: the number of cells to describe an IRQ, this should be 2. + The first cell is the IRQ number. + The second cell is the flags, encoded as the trigger masks from + Documentation/devicetree/bindings/interrupts.txt + + - gpio-controller : Indicates this device is a GPIO controller. + - #gpio-cells : Must be 2. The first cell is the pin number and the + second cell is used to specify optional parameters (currently unused). + + - AVDD1-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply, + SPKVDDL-supply, SPKVDDR-supply : power supplies for the device, as covered + in Documentation/devicetree/bindings/regulator/regulator.txt + +Optional properties: + + - wlf,reset : GPIO specifier for the GPIO controlling /RESET + - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA + + - wlf,gpio-defaults : A list of GPIO configuration register values. If + absent, no configuration of these registers is performed. If any + entry has a value that is out of range for a 16 bit register then + the chip default will be used. If present exactly five values must + be specified. + +Example: + +codec: wm5102@1a { + compatible = "wlf,wm5102"; + reg = <0x1a>; + interrupts = <347>; + #interrupt-cells = <2>; + interrupt-parent = <&gic>; + + gpio-controller; + #gpio-cells = <2>; + + wlf,gpio-defaults = < + 0x00000000, /* AIF1TXLRCLK */ + 0xffffffff, + 0xffffffff, + 0xffffffff, + 0xffffffff, + >; +}; -- cgit v1.1 From af99a7507469d4fa6dd4d8d633e093b1ff7aff6e Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Tue, 21 May 2013 00:56:13 +0900 Subject: pinctrl: Add pinctrl-s3c24xx driver The s3c24xx pins follow a similar pattern as the other Samsung SoCs and can therefore reuse the already introduced infrastructure. The s3c24xx SoCs have one design oddity in that the first 4 external interrupts do not reside in the eint pending register but in the main interrupt controller instead. We solve this by forwarding the external interrupt from the main controller into the irq domain of the pin bank. The masking/acking of these interrupts is handled in the same way. Furthermore the S3C2412/2413 SoCs contain another oddity in that they keep the same 4 eints in the main interrupt controller and eintpend register and requiring ack operations to happen in both. This is solved by using different compatible properties for the wakeup eint node which set a property accordingly. Signed-off-by: Heiko Stuebner Reviewed-by: Tomasz Figa Reviewed-by: Sylwester Nawrocki Acked-by: Linus Walleij Signed-off-by: Kukjin Kim --- Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index c70fca1..b2bc219 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -7,6 +7,10 @@ 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. @@ -106,6 +110,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 -- cgit v1.1 From 45361a4fe4464180815157654aabbd2afb4848ad Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Thu, 16 May 2013 17:55:22 +0200 Subject: pci: PCIe driver for Marvell Armada 370/XP systems This driver implements the support for the PCIe interfaces on the Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to cover earlier families of Marvell SoCs, such as Dove, Orion and Kirkwood. The driver implements the hw_pci operations needed by the core ARM PCI code to setup PCI devices and get their corresponding IRQs, and the pci_ops operations that are used by the PCI core to read/write the configuration space of PCI devices. Since the PCIe interfaces of Marvell SoCs are completely separate and not linked together in a bus, this driver sets up an emulated PCI host bridge, with one PCI-to-PCI bridge as child for each hardware PCIe interface. In addition, this driver enumerates the different PCIe slots, and for those having a device plugged in, it sets up the necessary address decoding windows, using the mvebu-mbus driver. Signed-off-by: Thomas Petazzoni Acked-by: Bjorn Helgaas Signed-off-by: Jason Cooper --- .../devicetree/bindings/pci/mvebu-pci.txt | 220 +++++++++++++++++++++ 1 file changed, 220 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/mvebu-pci.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt new file mode 100644 index 0000000..eb69d92 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt @@ -0,0 +1,220 @@ +* Marvell EBU PCIe interfaces + +Mandatory properties: +- compatible: one of the following values: + marvell,armada-370-pcie + marvell,armada-xp-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"; + }; +}; -- cgit v1.1 From 6dffbe53fbdcc7bd5f6379fa18264f060b0cf61d Mon Sep 17 00:00:00 2001 From: Tony Prisk Date: Sat, 18 May 2013 09:39:07 +0000 Subject: net: velocity: Add platform device support to VIA velocity driver Add support for the VIA Velocity network driver to be bound to a OF created platform device. Signed-off-by: Tony Prisk Signed-off-by: David S. Miller --- .../devicetree/bindings/net/via-velocity.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/via-velocity.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/via-velocity.txt b/Documentation/devicetree/bindings/net/via-velocity.txt new file mode 100644 index 0000000..b3db469 --- /dev/null +++ b/Documentation/devicetree/bindings/net/via-velocity.txt @@ -0,0 +1,20 @@ +* VIA Velocity 10/100/1000 Network Controller + +Required properties: +- compatible : Should be "via,velocity-vt6110" +- reg : Address and length of the io space +- interrupts : Should contain the controller interrupt line + +Optional properties: +- no-eeprom : PCI network cards use an external EEPROM to store data. Embedded + devices quite often set this data in uboot and do not provide an eeprom. + Specify this option if you have no external eeprom. + +Examples: + +eth0@d8004000 { + compatible = "via,velocity-vt6110"; + reg = <0xd8004000 0x400>; + interrupts = <10>; + no-eeprom; +}; -- cgit v1.1 From 0b8bf1baabe56f721d541953f083560d0660d78f Mon Sep 17 00:00:00 2001 From: Tomasz Figa Date: Mon, 20 May 2013 09:16:58 +0000 Subject: net: dm9000: Allow instantiation using device tree This patch adds Device Tree support to dm9000 driver. Signed-off-by: Tomasz Figa Reviewed-by: Sylwester Nawrocki Reviewed-by: Sascha Hauer Signed-off-by: David S. Miller --- .../devicetree/bindings/net/davicom-dm9000.txt | 26 ++++++++++++++++++++++ .../devicetree/bindings/vendor-prefixes.txt | 1 + 2 files changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/davicom-dm9000.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt b/Documentation/devicetree/bindings/net/davicom-dm9000.txt new file mode 100644 index 0000000..2d39c99 --- /dev/null +++ b/Documentation/devicetree/bindings/net/davicom-dm9000.txt @@ -0,0 +1,26 @@ +Davicom DM9000 Fast Ethernet controller + +Required properties: +- compatible = "davicom,dm9000"; +- reg : physical addresses and sizes of registers, must contain 2 entries: + first entry : address register, + second entry : data register. +- interrupt-parent : interrupt controller to which the device is connected +- interrupts : interrupt specifier specific to interrupt controller + +Optional properties: +- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address + to use (from firmware or bootloader) +- davicom,no-eeprom : Configuration EEPROM is not available +- davicom,ext-phy : Use external PHY + +Example: + + ethernet@18000000 { + compatible = "davicom,dm9000"; + reg = <0x18000000 0x2 0x18000004 0x2>; + interrupt-parent = <&gpn>; + interrupts = <7 4>; + local-mac-address = [00 00 de ad be ef]; + davicom,no-eeprom; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 6931c43..2fe74e6 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -18,6 +18,7 @@ chrp Common Hardware Reference Platform cirrus Cirrus Logic, Inc. cortina Cortina Systems, Inc. dallas Maxim Integrated Products (formerly Dallas Semiconductor) +davicom DAVICOM Semiconductor, Inc. denx Denx Software Engineering emmicro EM Microelectronic epson Seiko Epson Corp. -- cgit v1.1 From 00fd6e6153100ae868975cab67f02df6f16343eb Mon Sep 17 00:00:00 2001 From: "Kim, Milo" Date: Mon, 20 May 2013 12:36:07 +0000 Subject: regulator: lp872x: support the device tree feature This patch enables the DT structure of the LP8720 and LP8725 device. The LP872x platform data is generated when the device tree is configured. Even if the platform data is NULL, it is no issue at all because the driver is configured with the default mode. Signed-off-by: Milo(Woogyom) Kim Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/lp872x.txt | 160 +++++++++++++++++++++ 1 file changed, 160 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/lp872x.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt b/Documentation/devicetree/bindings/regulator/lp872x.txt new file mode 100644 index 0000000..7818318 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/lp872x.txt @@ -0,0 +1,160 @@ +Binding for TI/National Semiconductor LP872x Driver + +Required properties: + - compatible: "ti,lp8720" or "ti,lp8725" + - reg: I2C slave address. 0x7d = LP8720, 0x7a = LP8725 + +Optional properties: + - ti,general-config: the value of LP872X_GENERAL_CFG register (u8) + (LP8720) + bit[2]: BUCK output voltage control by external DVS pin or register + 1 = external pin, 0 = bit7 of register 08h + bit[1]: sleep control by external DVS pin or register + 1 = external pin, 0 = bit6 of register 08h + bit[0]: time step unit(usec). 1 = 25, 0 = 50 + + (LP8725) + bit[7:6]: time step unit(usec). 00 = 32, 01 = 64, 10 = 128, 11 = 256 + bit[4]: BUCK2 enable control. 1 = enable, 0 = disable + bit[3]: BUCK2 output voltage register address. 1 = 0Ah, 0 = 0Bh + bit[2]: BUCK1 output voltage control by external DVS pin or register + 1 = register 08h, 0 = DVS + bit[1]: LDO sleep control. 1 = sleep mode, 0 = normal + bit[0]: BUCK1 enable control, 1 = enable, 0 = disable + + For more details, please see the datasheet. + + - ti,update-config: define it when LP872X_GENERAL_CFG register should be set + - ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices. + - ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2. + - ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH. + + Sub nodes for regulator_init_data + LP8720 has maximum 6 nodes. (child name: ldo1 ~ 5 and buck) + LP8725 has maximum 9 nodes. (child name: ldo1 ~ 5, lilo1,2 and buck1,2) + For more details, please see the following binding document. + (Documentation/devicetree/bindings/regulator/regulator.txt) + +Datasheet + - LP8720: http://www.ti.com/lit/ds/symlink/lp8720.pdf + - LP8725: http://www.ti.com/lit/ds/symlink/lp8725.pdf + +Example 1) LP8720 + +lp8720@7d { + compatible = "ti,lp8720"; + reg = <0x7d>; + + /* external DVS pin used, timestep is 25usec */ + ti,general-config = /bits/ 8 <0x03>; + ti,update-config; + + /* + * The dvs-gpio depends on the processor environment. + * For example, following GPIO specifier means GPIO134 in OMAP4. + */ + ti,dvs-gpio = <&gpio5 6 0>; + ti,dvs-vsel = /bits/ 8 <1>; /* SEL_V2 */ + ti,dvs-state = /bits/ 8 <1>; /* DVS_HIGH */ + + vaf: ldo1 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + }; + + vmmc: ldo2 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + }; + + vcam_io: ldo3 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + }; + + vcam_core: ldo4 { + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <2850000>; + regulator-boot-on; + }; + + vcam: ldo5 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + }; + + vcc: buck { + regulator-name = "VBUCK"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <2300000>; + }; +}; + +Example 2) LP8725 + +lp8725@7a { + compatible = "ti,lp8725"; + reg = <0x7a>; + + /* Enable BUCK1,2, no DVS, normal LDO mode, timestep is 256usec */ + ti,general-config = /bits/ 8 <0xdd>; + ti,update-config; + + vcam_io: ldo1 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + }; + + vcam_core: ldo2 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + }; + + vcam: ldo3 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + }; + + vcmmb_io: ldo4 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + }; + + vcmmb_core: ldo5 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + }; + + vaux1: lilo1 { + regulator-name = "VAUX1"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3300000>; + }; + + vaux2: lilo2 { + regulator-name = "VAUX2"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3300000>; + }; + + vcc1: buck1 { + regulator-name = "VBUCK1"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3000000>; + regulator-min-microamp = <460000>; + regulator-max-microamp = <1370000>; + regulator-boot-on; + }; + + vcc2: buck2 { + regulator-name = "VBUCK2"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3000000>; + regulator-min-microamp = <460000>; + regulator-max-microamp = <1370000>; + regulator-boot-on; + }; +}; -- cgit v1.1 From 6e7df1cd373d688486b0b0b6626cb32f59ebdcfa Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Tue, 7 May 2013 08:06:11 -0300 Subject: [media] DocBook: media: update codec section, drop obsolete 'suspended' state The Codec section in the V4L2 specification was marked as 'suspended', even though codec support has been around for quite some time. Update this section, explaining a bit about memory-to-memory devices and pointing to the MPEG controls section. Signed-off-by: Hans Verkuil Acked-by: Kamil Debski Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/dev-codec.xml | 35 +++++++++++++++++---------- 1 file changed, 22 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/dev-codec.xml b/Documentation/DocBook/media/v4l/dev-codec.xml index dca0ecd..ff44c16 100644 --- a/Documentation/DocBook/media/v4l/dev-codec.xml +++ b/Documentation/DocBook/media/v4l/dev-codec.xml @@ -1,18 +1,27 @@ Codec Interface - - Suspended + A V4L2 codec can compress, decompress, transform, or otherwise +convert video data from one format into another format, in memory. Typically +such devices are memory-to-memory devices (i.e. devices with the +V4L2_CAP_VIDEO_M2M or V4L2_CAP_VIDEO_M2M_MPLANE +capability set). + - This interface has been be suspended from the V4L2 API -implemented in Linux 2.6 until we have more experience with codec -device interfaces. - + A memory-to-memory video node acts just like a normal video node, but it +supports both output (sending frames from memory to the codec hardware) and +capture (receiving the processed frames from the codec hardware into memory) +stream I/O. An application will have to setup the stream +I/O for both sides and finally call &VIDIOC-STREAMON; for both capture and output +to start the codec. - A V4L2 codec can compress, decompress, transform, or otherwise -convert video data from one format into another format, in memory. -Applications send data to be converted to the driver through a -&func-write; call, and receive the converted data through a -&func-read; call. For efficiency a driver may also support streaming -I/O. + Video compression codecs use the MPEG controls to setup their codec parameters +(note that the MPEG controls actually support many more codecs than just MPEG). +See . - [to do] + Memory-to-memory devices can often be used as a shared resource: you can +open the video node multiple times, each application setting up their own codec properties +that are local to the file handle, and each can use it independently from the others. +The driver will arbitrate access to the codec and reprogram it whenever another file +handler gets access. This is different from the usual video node behavior where the video properties +are global to the device (i.e. changing something through one file handle is visible +through another file handle). -- cgit v1.1 From 835ab0121adb24ff27729bd3743f1477af00c435 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 12 Apr 2013 09:30:29 -0300 Subject: [media] bttv: Add Adlink MPG24 entry to the bttv cardlist Add a proper card entry for this device, rather than abusing entries that are not-quite-right. Regards, Hans Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.bttv | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv index 581f666..407ab46 100644 --- a/Documentation/video4linux/CARDLIST.bttv +++ b/Documentation/video4linux/CARDLIST.bttv @@ -160,3 +160,4 @@ 159 -> ProVideo PV183 [1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540] 160 -> Tongwei Video Technology TD-3116 [f200:3116] 161 -> Aposonic W-DVR [0279:0228] +162 -> Adlink MPG24 -- cgit v1.1 From 05ff7240b0aa1794cebd8b0ecb846ed629fb5da3 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sat, 20 Apr 2013 08:57:41 -0300 Subject: [media] CARDLIST.bttv: add new cards Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.bttv | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv index 407ab46..f144750 100644 --- a/Documentation/video4linux/CARDLIST.bttv +++ b/Documentation/video4linux/CARDLIST.bttv @@ -161,3 +161,5 @@ 160 -> Tongwei Video Technology TD-3116 [f200:3116] 161 -> Aposonic W-DVR [0279:0228] 162 -> Adlink MPG24 +163 -> Bt848 Capture 14MHz +164 -> CyberVision CV06 (SV) -- cgit v1.1 From 60bc53d5f7a2b5117fe665c6db1f03ec389f4ae6 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 21 May 2013 08:16:19 -0300 Subject: [media] update saa7134 and tuner cardlists Those are automatically updated using the cardlist script. Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.saa7134 | 1 + Documentation/video4linux/CARDLIST.tuner | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index b3ad683..8df17d0 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -190,3 +190,4 @@ 189 -> Kworld PC150-U [17de:a134] 190 -> Asus My Cinema PS3-100 [1043:48cd] 191 -> Hawell HW-9004V1 +192 -> AverMedia AverTV Satellite Hybrid+FM A706 [1461:2055] diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner index 5b83a3f..ac88621 100644 --- a/Documentation/video4linux/CARDLIST.tuner +++ b/Documentation/video4linux/CARDLIST.tuner @@ -86,6 +86,6 @@ tuner=85 - Philips FQ1236 MK5 tuner=86 - Tena TNF5337 MFD tuner=87 - Xceive 4000 tuner tuner=88 - Xceive 5000C tuner -tuner=89 - Sony PAL+SECAM (BTF-PG472Z) -tuner=90 - Sony NTSC-M-JP (BTF-PK467Z) -tuner=91 - Sony NTSC-M (BTF-PB463Z) +tuner=89 - Sony BTF-PG472Z PAL/SECAM +tuner=90 - Sony BTF-PK467Z NTSC-M-JP +tuner=91 - Sony BTF-PB463Z NTSC-M -- cgit v1.1 From c79b069d72f54ff0589e7615160420553aa4f04e Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Thu, 9 May 2013 08:43:34 -0300 Subject: [media] exynos4-is: Correct fimc-lite compatible property description Ensure the compatible property for FIMC-LITE IP blocks is properly documented, a cut&paste error fix. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab --- Documentation/devicetree/bindings/media/exynos-fimc-lite.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt index 3f62adf..de9f6b7 100644 --- a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt +++ b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt @@ -2,7 +2,7 @@ Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE) Required properties: -- compatible : should be "samsung,exynos4212-fimc" for Exynos4212 and +- compatible : should be "samsung,exynos4212-fimc-lite" for Exynos4212 and Exynos4412 SoCs; - reg : physical base address and size of the device memory mapped registers; -- cgit v1.1 From 3edad321b1bd2e6c8b5f38146c115c8982438f06 Mon Sep 17 00:00:00 2001 From: Ezequiel Garcia Date: Tue, 23 Apr 2013 16:21:26 -0300 Subject: drivers: memory: Introduce Marvell EBU Device Bus driver Marvell EBU SoCs such as Armada 370/XP, Orion5x (88f5xxx) and Discovery (mv78xx0) supports a Device Bus controller to access several kinds of memories and I/O devices (NOR, NAND, SRAM, FPGA). This commit adds a driver to handle this controller. So far only Armada 370, Armada XP and Discovery SoCs are supported. The driver must be registered through a device tree node; as explained in the binding document. For each child node in the device tree, this driver will: * set timing parameters * register a child device * setup an address decoding window, using the mbus driver Keep in mind the address decoding window setup is only a temporary hack. This code will be removed from this devbus driver as soon as a proper device tree binding for the mbus driver is added. Signed-off-by: Ezequiel Garcia Acked-by: Arnd Bergmann Acked-by: Jason Cooper Signed-off-by: Greg Kroah-Hartman --- .../bindings/memory-controllers/mvebu-devbus.txt | 156 +++++++++++++++++++++ 1 file changed, 156 insertions(+) create mode 100644 Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt (limited to 'Documentation') 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 0000000..653c90c --- /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 + +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 parameter + (no affect on first data sample). Set + to a value smaller than . + + - 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 parameter. + Set to a value smaller than . + +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 + - 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>; + }; + }; + }; -- cgit v1.1 From 6b5f146535fe6969aeded9f00b0bc42b3783f7fd Mon Sep 17 00:00:00 2001 From: Wang YanQing Date: Tue, 21 May 2013 23:29:11 +0800 Subject: TTY:console: update document console.txt Update Documentatin/console/console.txt to reflect the following changes: take_over_console|register_con_driver|unregister_con_driver|bind_con_driver had gone, they had been replace by the new caller hold console lock version, do_take_over_console|do_register_con_driver|do_unregister_con_driver|do_bind_con_driver. This patch also fix a place include wrong description about give_up_console. Signed-off-by: Wang YanQing Signed-off-by: Greg Kroah-Hartman --- Documentation/console/console.txt | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/console/console.txt b/Documentation/console/console.txt index 926cf1b..f93810d 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. -- cgit v1.1 From 966fbe193f47c68e70a80ec9991098e88e7959cb Mon Sep 17 00:00:00 2001 From: Vincent Pelletier Date: Tue, 21 May 2013 22:30:58 +0200 Subject: libata: Add atapi_dmadir force flag Some device require DMADIR to be enabled, but are not detected as such by atapi_id_dmadir. One such example is "Asus Serillel 2" SATA-host-to-PATA-device bridge: the bridge itself requires DMADIR, even if the bridged device does not. As atapi_dmadir module parameter can cause problems with some devices (as per Tejun Heo's memory), enabling it globally may not be possible depending on the hardware. This patch adds atapi_dmadir in the form of a "force" horkage value, allowing global, per-bus and per-device control. Signed-off-by: Vincent Pelletier Signed-off-by: Tejun Heo --- Documentation/kernel-parameters.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c3bfacb..489815e 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1456,6 +1456,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. * dump_id: dump IDENTIFY data. + * atapi_dmadir: Enable ATAPI DMADIR bridge support + If there are multiple matching configurations changing the same attribute, the last one is used. -- cgit v1.1 From d47992f86b307985b3215bcf141d56d1849d71df Mon Sep 17 00:00:00 2001 From: Lukas Czerner Date: Tue, 21 May 2013 23:17:23 -0400 Subject: mm: change invalidatepage prototype to accept length Currently there is no way to truncate partial page where the end truncate point is not at the end of the page. This is because it was not needed and the functionality was enough for file system truncate operation to work properly. However more file systems now support punch hole feature and it can benefit from mm supporting truncating page just up to the certain point. Specifically, with this functionality truncate_inode_pages_range() can be changed so it supports truncating partial page at the end of the range (currently it will BUG_ON() if 'end' is not at the end of the page). This commit changes the invalidatepage() address space operation prototype to accept range to be invalidated and update all the instances for it. We also change the block_invalidatepage() in the same way and actually make a use of the new length argument implementing range invalidation. Actual file system implementations will follow except the file systems where the changes are really simple and should not change the behaviour in any way .Implementation for truncate_page_range() which will be able to accept page unaligned ranges will follow as well. Signed-off-by: Lukas Czerner Cc: Andrew Morton Cc: Hugh Dickins --- Documentation/filesystems/Locking | 6 +++--- Documentation/filesystems/vfs.txt | 20 ++++++++++---------- 2 files changed, 13 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 0706d32..cbbac3f 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -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 diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index bc4b06b..e445b95 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -549,7 +549,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 +566,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 +685,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 -- cgit v1.1 From f4b7f751c6fd2bd7e6d3a83385ee292c39995bdb Mon Sep 17 00:00:00 2001 From: Jacek Anaszewski Date: Tue, 7 May 2013 11:41:00 +0100 Subject: iio:ak8975 Add support for gpios DT property Add support for parsing 'gpios' property when initializing from oftree. This patch adds also the binding documentation file. Signed-off-by: Jacek Anaszewski Signed-off-by: Kyungmin Park Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/magnetometer/ak8975.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt new file mode 100644 index 0000000..011679f --- /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>; +}; -- cgit v1.1 From 039735369c8fb105d0a090c949b7f894425121d8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= Date: Wed, 8 May 2013 17:16:45 +0300 Subject: drm: Fix drm_rect documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The 'struct' keyword was missing so struct drm_rect documentation never ended up in the generated docs. Also move the drm_rect documentations to a new section alognside the various helper functions and add a short description about the intended purpose of drm_rect. v2: Move to new section and add general description Signed-off-by: Ville Syrjälä Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 7c7af25..91ee107 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -1653,8 +1653,6 @@ void intel_crt_init(struct drm_device *dev) KMS API Functions !Edrivers/gpu/drm/drm_crtc.c -!Edrivers/gpu/drm/drm_rect.c -!Finclude/drm/drm_rect.h @@ -2163,6 +2161,12 @@ void intel_crt_init(struct drm_device *dev) EDID Helper Functions Reference !Edrivers/gpu/drm/drm_edid.c + + Rectangle Utilities Reference +!Pinclude/drm/drm_rect.h rect utils +!Iinclude/drm/drm_rect.h +!Edrivers/gpu/drm/drm_rect.c + -- cgit v1.1 From fa332de5c6b3891485798adfe3252125457e5377 Mon Sep 17 00:00:00 2001 From: Lee Jones Date: Fri, 3 May 2013 15:32:12 +0100 Subject: dmaengine: ste_dma40: Supply full Device Tree parsing support Using the new DMA DT bindings and API, we can register the DMA40 driver as Device Tree capable. Now, when a client attempts to allocate a channel using the DMA DT bindings via its own node, we are able to parse the request and allocate a channel in the correct manner. Cc: Dan Williams Cc: Per Forlin Cc: Rabin Vincent Cc: Rob Herring Cc: devicetree-discuss@lists.ozlabs.org Acked-by: Vinod Koul Reviewed-by: Arnd Bergmann Signed-off-by: Lee Jones Signed-off-by: Linus Walleij --- .../devicetree/bindings/dma/ste-dma40.txt | 62 ++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/ste-dma40.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt new file mode 100644 index 0000000..2679a87 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt @@ -0,0 +1,62 @@ +* 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> + +Optional properties: +- dma-channels: Number of channels supported by hardware - if not present + the driver will attempt to obtain the information from H/W + +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>; + 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"; + }; -- cgit v1.1 From 4a3ae9324ebeb9715369d2bca799bfd7dcff6dd7 Mon Sep 17 00:00:00 2001 From: Jean-Christophe PLAGNIOL-VILLARD Date: Fri, 3 May 2013 20:22:57 +0800 Subject: USB: gadget: atmel_usba: add DT support Allow to compile the driver all the time if AT91 enabled. Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Acked-by: Felipe Balbi Acked-by: Nicolas Ferre Tested-by: Bo Shen --- .../devicetree/bindings/usb/atmel-usb.txt | 82 ++++++++++++++++++++++ 1 file changed, 82 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt index 60bd215..55f51af 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; + }; +}; -- cgit v1.1 From 191cb1f21afd9a7fbaa085ad9b86cb307e9a3891 Mon Sep 17 00:00:00 2001 From: Willem de Bruijn Date: Wed, 22 May 2013 07:54:40 +0000 Subject: rps: document flow limit in scaling.txt Explain the mechanism and API of the recently merged rps flow limit patch. Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller --- Documentation/networking/scaling.txt | 58 ++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt index 579994a..ca6977f 100644 --- a/Documentation/networking/scaling.txt +++ b/Documentation/networking/scaling.txt @@ -163,6 +163,64 @@ and unnecessary. If there are fewer hardware queues than CPUs, then RPS might be beneficial if the rps_cpus for each queue are the ones that share the same memory domain as the interrupting CPU for that queue. +==== RPS Flow Limit + +RPS scales kernel receive processing across CPUs without introducing +reordering. The trade-off to sending all packets from the same flow +to the same CPU is CPU load imbalance if flows vary in packet rate. +In the extreme case a single flow dominates traffic. Especially on +common server workloads with many concurrent connections, such +behavior indicates a problem such as a misconfiguration or spoofed +source Denial of Service attack. + +Flow Limit is an optional RPS feature that prioritizes small flows +during CPU contention by dropping packets from large flows slightly +ahead of those from small flows. It is active only when an RPS or RFS +destination CPU approaches saturation. Once a CPU's input packet +queue exceeds half the maximum queue length (as set by sysctl +net.core.netdev_max_backlog), the kernel starts a per-flow packet +count over the last 256 packets. If a flow exceeds a set ratio (by +default, half) of these packets when a new packet arrives, then the +new packet is dropped. Packets from other flows are still only +dropped once the input packet queue reaches netdev_max_backlog. +No packets are dropped when the input packet queue length is below +the threshold, so flow limit does not sever connections outright: +even large flows maintain connectivity. + +== Interface + +Flow limit is compiled in by default (CONFIG_NET_FLOW_LIMIT), but not +turned on. It is implemented for each CPU independently (to avoid lock +and cache contention) and toggled per CPU by setting the relevant bit +in sysctl net.core.flow_limit_cpu_bitmap. It exposes the same CPU +bitmap interface as rps_cpus (see above) when called from procfs: + + /proc/sys/net/core/flow_limit_cpu_bitmap + +Per-flow rate is calculated by hashing each packet into a hashtable +bucket and incrementing a per-bucket counter. The hash function is +the same that selects a CPU in RPS, but as the number of buckets can +be much larger than the number of CPUs, flow limit has finer-grained +identification of large flows and fewer false positives. The default +table has 4096 buckets. This value can be modified through sysctl + + net.core.flow_limit_table_len + +The value is only consulted when a new table is allocated. Modifying +it does not update active tables. + +== Suggested Configuration + +Flow limit is useful on systems with many concurrent connections, +where a single connection taking up 50% of a CPU indicates a problem. +In such environments, enable the feature on all CPUs that handle +network rx interrupts (as set in /proc/irq/N/smp_affinity). + +The feature depends on the input packet queue length to exceed +the flow limit threshold (50%) + the flow history length (256). +Setting net.core.netdev_max_backlog to either 1000 or 10000 +performed well in experiments. + RFS: Receive Flow Steering ========================== -- cgit v1.1 From 8d61ffa5e01c5f676431d12caba17db164a48a86 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Fri, 10 May 2013 12:32:47 +0200 Subject: cfg80211/mac80211: use cfg80211 wdev mutex in mac80211 Using separate locks in cfg80211 and mac80211 has always caused issues, for example having to unlock in places in mac80211 to call cfg80211, which even needed a framework to make cfg80211 calls after some functions returned etc. Additionally, I suspect some issues people have reported with the cfg80211 state getting confused could be due to such issues, when cfg80211 is asking mac80211 to change state but mac80211 is in the process of telling cfg80211 that the state changed (in another way.) Signed-off-by: Johannes Berg --- Documentation/DocBook/80211.tmpl | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index 0f6a3ed..ebe8969 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -132,9 +132,7 @@ !Finclude/net/cfg80211.h cfg80211_send_rx_assoc !Finclude/net/cfg80211.h cfg80211_send_assoc_timeout !Finclude/net/cfg80211.h cfg80211_send_deauth -!Finclude/net/cfg80211.h __cfg80211_send_deauth !Finclude/net/cfg80211.h cfg80211_send_disassoc -!Finclude/net/cfg80211.h __cfg80211_send_disassoc !Finclude/net/cfg80211.h cfg80211_ibss_joined !Finclude/net/cfg80211.h cfg80211_connect_result !Finclude/net/cfg80211.h cfg80211_roamed -- cgit v1.1 From b6b5e76bb8bb22ecff90a7840dc4845d63328289 Mon Sep 17 00:00:00 2001 From: Lars-Peter Clausen Date: Thu, 23 May 2013 20:14:50 +0200 Subject: ASoC: Add ssm2518 support This patch adds a ASoC CODEC driver for the SSM2516. The SSM2516 is a stereo Class-D audio amplifier with an I2S interface for audio in and a built-in dynamic range control processor. Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/ssm2518.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/ssm2518.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/ssm2518.txt b/Documentation/devicetree/bindings/sound/ssm2518.txt new file mode 100644 index 0000000..59381a7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ssm2518.txt @@ -0,0 +1,20 @@ +SSM2518 audio amplifier + +This device supports I2C only. + +Required properties: + - compatible : Must be "adi,ssm2518" + - reg : the I2C address of the device. This will either be 0x34 (ADDR pin low) + or 0x35 (ADDR pin high) + +Optional properties: + - gpios : GPIO connected to the nSD pin. If the property is not present it is + assumed that the nSD pin is hardwired to always on. + +Example: + + ssm2518: ssm2518@34 { + compatible = "adi,ssm2518"; + reg = <0x34>; + gpios = <&gpio 5 0>; + }; -- cgit v1.1 From 04561eacaa6ccd1988e468cdcbf4acc475ae2221 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Thu, 23 May 2013 15:46:05 +0200 Subject: ASoC: codecs: adau1701: add DT bindings Apart from pure matching, the bindings also support setting the the reset gpio line. Signed-off-by: Daniel Mack Acked-by: Lars-Peter Clausen Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/adi,adau1701.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/adi,adau1701.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/adi,adau1701.txt b/Documentation/devicetree/bindings/sound/adi,adau1701.txt new file mode 100644 index 0000000..3afeda7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/adi,adau1701.txt @@ -0,0 +1,23 @@ +Analog Devices ADAU1701 + +Required properties: + + - compatible: Should contain "adi,adau1701" + - reg: The i2c address. Value depends on the state of ADDR0 + and ADDR1, as wired in hardware. + +Optional properties: + + - reset-gpio: A GPIO spec to define which pin is connected to the + chip's !RESET pin. If specified, the driver will + assert a hardware reset at probe time. + +Examples: + + i2c_bus { + adau1701@34 { + compatible = "adi,adau1701"; + reg = <0x34>; + reset-gpio = <&gpio 23 0>; + }; + }; -- cgit v1.1 From 0ee52b157b8ed88550ddd6291e54bb4bfabde364 Mon Sep 17 00:00:00 2001 From: Soren Brinkmann Date: Mon, 13 May 2013 10:46:37 -0700 Subject: clk: zynq: Add clock controller driver Add a clock controller driver and documentation. Signed-off-by: Soren Brinkmann Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-doc@vger.kernel.org Signed-off-by: Michal Simek Acked-by: Mike Turquette --- .../devicetree/bindings/clock/zynq-7000.txt | 97 ++++++++++++++++++++++ 1 file changed, 97 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt index 23ae1db..1049a31 100644 --- a/Documentation/devicetree/bindings/clock/zynq-7000.txt +++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt @@ -6,6 +6,103 @@ 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. +== 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 : 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: + - clocks : as described in the clock bindings + - clock-names : as described in the clock bindings + +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 +... + +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: + clkc: clkc { + #clock-cells = <1>; + 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"; + }; + == PLLs == Used to describe the ARM_PLL, DDR_PLL, and IO_PLL. -- cgit v1.1 From 97c4e87d45498fb4d18c995721bba72345a7d257 Mon Sep 17 00:00:00 2001 From: Soren Brinkmann Date: Mon, 13 May 2013 10:46:39 -0700 Subject: clk: zynq: Remove deprecated clock code Signed-off-by: Soren Brinkmann Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-doc@vger.kernel.org Signed-off-by: Michal Simek Acked-by: Mike Turquette --- .../devicetree/bindings/clock/zynq-7000.txt | 48 ---------------------- 1 file changed, 48 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt index 1049a31..d99af87 100644 --- a/Documentation/devicetree/bindings/clock/zynq-7000.txt +++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt @@ -102,51 +102,3 @@ Example: clocks = <&clkc 16>, <&clk_foo>; clock-names = "gem1_emio_clk", "can_mio_clk_23"; }; - -== PLLs == - -Used to describe the ARM_PLL, DDR_PLL, and IO_PLL. - -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 - -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 == - -Describes clock node for the SDIO, SMC, SPI, QSPI, and UART clocks. - -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. - -Example: - uart_clk: uart_clk { - #clock-cells = <1>; - compatible = "xlnx,zynq-periph-clock"; - clocks = <&iopll &armpll &ddrpll>; - reg = <0x154>; - clock-output-names = "uart0_ref_clk", - "uart1_ref_clk"; - }; -- cgit v1.1 From 99b38eef5a86648131b8c0340ce386e9bfc71ae3 Mon Sep 17 00:00:00 2001 From: Fabio Baltieri Date: Tue, 9 Apr 2013 11:16:56 +0200 Subject: ARM: ux500: Fix intcore regulator name Ux500 regulator name for V-INTCORE is misspelled as vinitcore instead of vintcore in some .dts file, causing the AB8500 regulator driver to not bind properly. Fix this by replacing all occurrences with the right name. Acked-by: Lee Jones Signed-off-by: Fabio Baltieri Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/mfd/ab8500.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt index c3a14e0..cd9e90c 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>; }; -- cgit v1.1 From 005625fc5d62220242ec488d112e0a97e7fcd7bc Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Wed, 15 May 2013 15:36:54 +0200 Subject: pci: mvebu: enable driver usage on Kirkwood We allow the pci-mvebu driver to be compiled on the Kirkwood platform, and add the 'marvell,kirkwood-pcie' as a compatible string supported by the driver. Signed-off-by: Thomas Petazzoni Tested-by: Andrew Lunn Signed-off-by: Jason Cooper --- Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt index eb69d92..f8d4058 100644 --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt @@ -4,6 +4,7 @@ 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> -- cgit v1.1 From eb982001dbd8546f273f444868a1031cc78b4250 Mon Sep 17 00:00:00 2001 From: Eduardo Valentin Date: Wed, 15 May 2013 15:46:00 +0000 Subject: thermal: introduce TI SoC thermal driver This patch moves the ti-soc-thermal driver out of the staging tree to the thermal tree. Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: Greg Kroah-Hartman Cc: Zhang Rui Cc: Eduardo Valentin Cc: J Keerthy Cc: Radhesh Fadnis Cc: Cyril Roelandt Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: devel@driverdev.osuosl.org Cc: linux-pm@vger.kernel.org Signed-off-by: Eduardo Valentin Signed-off-by: Zhang Rui --- .../devicetree/bindings/thermal/ti_soc_thermal.txt | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt new file mode 100644 index 0000000..a4a33d1 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt @@ -0,0 +1,60 @@ +* Texas Instrument OMAP SCM bandgap bindings + +In the System Control Module, OMAP supplies a voltage reference +and a temperature sensor feature that are gathered in the band +gap voltage and temperature sensor (VBGAPTS) module. The band +gap provides current and voltage reference for its internal +circuits and other analog IP blocks. The analog-to-digital +converter (ADC) produces an output value that is proportional +to the silicon temperature. + +Required properties: +- compatible : Should be: + - "ti,omap4430-bandgap" : for OMAP4430 bandgap + - "ti,omap4460-bandgap" : for OMAP4460 bandgap + - "ti,omap4470-bandgap" : for OMAP4470 bandgap + - "ti,omap5430-bandgap" : for OMAP5430 bandgap +- interrupts : this entry should indicate which interrupt line +the talert signal is routed to; +Specific: +- ti,tshut-gpio : this entry should be used to inform which GPIO +line the tshut signal is routed to; +- regs : this entry must also be specified and it is specific +to each bandgap version, because the mapping may change from +soc to soc, apart of depending on available features. + +Example: +OMAP4430: +bandgap { + reg = <0x4a002260 0x4 0x4a00232C 0x4>; + compatible = "ti,omap4430-bandgap"; +}; + +OMAP4460: +bandgap { + reg = <0x4a002260 0x4 + 0x4a00232C 0x4 + 0x4a002378 0x18>; + compatible = "ti,omap4460-bandgap"; + interrupts = <0 126 4>; /* talert */ + ti,tshut-gpio = <86>; +}; + +OMAP4470: +bandgap { + reg = <0x4a002260 0x4 + 0x4a00232C 0x4 + 0x4a002378 0x18>; + compatible = "ti,omap4470-bandgap"; + interrupts = <0 126 4>; /* talert */ + ti,tshut-gpio = <86>; +}; + +OMAP5430: +bandgap { + reg = <0x4a0021e0 0xc + 0x4a00232c 0xc + 0x4a002380 0x2c + 0x4a0023C0 0x3c>; + compatible = "ti,omap5430-bandgap"; +}; -- cgit v1.1 From 87227b8b2d4d556a6924ad9af87450fdc3fcd7e3 Mon Sep 17 00:00:00 2001 From: Jean-Christophe PLAGNIOL-VILLARD Date: Thu, 23 May 2013 23:01:22 +0000 Subject: net: micrel : ks8851-ml: add dt support Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/micrel-ks8851.txt | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/micrel-ks8851.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/micrel-ks8851.txt b/Documentation/devicetree/bindings/net/micrel-ks8851.txt new file mode 100644 index 0000000..11ace3c --- /dev/null +++ b/Documentation/devicetree/bindings/net/micrel-ks8851.txt @@ -0,0 +1,9 @@ +Micrel KS8851 Ethernet mac + +Required properties: +- compatible = "micrel,ks8851-ml" of parallel interface +- reg : 2 physical address and size of registers for data and command +- interrupts : interrupt connection + +Optional properties: +- local-mac-address : Ethernet mac address to use -- cgit v1.1 From 3dd17edea018bf37ca1c33685ca0256270ccdb2c Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Fri, 24 May 2013 07:05:59 +0000 Subject: doc:networking: Fix typo in documentation/networking Correct spelling typo Signed-off-by: Masanari Iida Signed-off-by: David S. Miller --- Documentation/networking/ifenslave.c | 2 +- Documentation/networking/ip-sysctl.txt | 2 +- Documentation/networking/netlink_mmap.txt | 14 +++++++------- 3 files changed, 9 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/ifenslave.c b/Documentation/networking/ifenslave.c index ac5debb..9f6a8ff 100644 --- a/Documentation/networking/ifenslave.c +++ b/Documentation/networking/ifenslave.c @@ -501,7 +501,7 @@ out: static short mif_flags; -/* Get the inteface configuration from the kernel. */ +/* Get the interface configuration from the kernel. */ static int if_getconfig(char *ifname) { struct ifreq ifr; diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index f98ca63..398d0fb 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -183,7 +183,7 @@ tcp_early_retrans - INTEGER for triggering fast retransmit when the amount of outstanding data is small and when no previously unsent data can be transmitted (such that limited transmit could be used). Also controls the use of - Tail loss probe (TLP) that converts RTOs occuring due to tail + Tail loss probe (TLP) that converts RTOs occurring due to tail losses into fast recovery (draft-dukkipati-tcpm-tcp-loss-probe-01). Possible values: 0 disables ER diff --git a/Documentation/networking/netlink_mmap.txt b/Documentation/networking/netlink_mmap.txt index 1c2dab4..e6088ba 100644 --- a/Documentation/networking/netlink_mmap.txt +++ b/Documentation/networking/netlink_mmap.txt @@ -54,7 +54,7 @@ it will use an allocated socket buffer as usual and the contents will be copied to the ring on transmission, nullifying most of the performance gains. Dumps of kernel databases automatically support memory mapped I/O. -Conversion of the transmit path involves changing message contruction to +Conversion of the transmit path involves changing message construction to use memory from the TX ring instead of (usually) a buffer declared on the stack and setting up the frame header approriately. Optionally poll() can be used to wait for free frames in the TX ring. @@ -65,8 +65,8 @@ Structured and definitions for using memory mapped I/O are contained in RX and TX rings ---------------- -Each ring contains a number of continous memory blocks, containing frames of -fixed size dependant on the parameters used for ring setup. +Each ring contains a number of continuous memory blocks, containing frames of +fixed size dependent on the parameters used for ring setup. Ring: [ block 0 ] [ frame 0 ] @@ -80,7 +80,7 @@ Ring: [ block 0 ] [ frame 2 * n + 1 ] The blocks are only visible to the kernel, from the point of view of user-space -the ring just contains the frames in a continous memory zone. +the ring just contains the frames in a continuous memory zone. The ring parameters used for setting up the ring are defined as follows: @@ -91,7 +91,7 @@ struct nl_mmap_req { unsigned int nm_frame_nr; }; -Frames are grouped into blocks, where each block is a continous region of memory +Frames are grouped into blocks, where each block is a continuous region of memory and holds nm_block_size / nm_frame_size frames. The total number of frames in the ring is nm_frame_nr. The following invariants hold: @@ -113,8 +113,8 @@ Some parameters are constrained, specifically: - nm_frame_nr must equal the actual number of frames as specified above. -When the kernel can't allocate phsyically continous memory for a ring block, -it will fall back to use physically discontinous memory. This might affect +When the kernel can't allocate phsyically continuous memory for a ring block, +it will fall back to use physically discontinuous memory. This might affect performance negatively, in order to avoid this the nm_frame_size parameter should be chosen to be as small as possible for the required frame size and the number of blocks should be increased instead. -- cgit v1.1 From b1098bbe1b24d5d90cff92fbd716d2ef4bed2cff Mon Sep 17 00:00:00 2001 From: Cong Wang Date: Mon, 27 May 2013 15:49:16 +0000 Subject: bonding: remove ifenslave.c from kernel source As Stephen proposed: Since bonding supports configuration via iproute (netlink) and sysfs, I think it is time to purge the old ifenslave code out of Documentation/networking and update the documentation. Suggested-by: Stephen Hemminger Cc: Stephen Hemminger Cc: Jay Vosburgh Cc: "David S. Miller" Signed-off-by: Cong Wang Signed-off-by: David S. Miller --- Documentation/networking/.gitignore | 1 - Documentation/networking/00-INDEX | 2 - Documentation/networking/Makefile | 5 - Documentation/networking/bonding.txt | 54 +- Documentation/networking/ifenslave.c | 1105 ---------------------------------- 5 files changed, 10 insertions(+), 1157 deletions(-) delete mode 100644 Documentation/networking/ifenslave.c (limited to 'Documentation') diff --git a/Documentation/networking/.gitignore b/Documentation/networking/.gitignore index 286a568..e69de29 100644 --- a/Documentation/networking/.gitignore +++ b/Documentation/networking/.gitignore @@ -1 +0,0 @@ -ifenslave diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 258d9b9..32dfbd9 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -88,8 +88,6 @@ gianfar.txt - Gianfar Ethernet Driver. ieee802154.txt - Linux IEEE 802.15.4 implementation, API and drivers -ifenslave.c - - Configure network interfaces for parallel routing (bonding). igb.txt - README for the Intel Gigabit Ethernet Driver (igb). igbvf.txt diff --git a/Documentation/networking/Makefile b/Documentation/networking/Makefile index 24c308d..0aa1ac9 100644 --- a/Documentation/networking/Makefile +++ b/Documentation/networking/Makefile @@ -1,11 +1,6 @@ # kbuild trick to avoid linker error. Can be omitted if a module is built. obj- := dummy.o -# List of programs to build -hostprogs-y := ifenslave - -HOSTCFLAGS_ifenslave.o += -I$(objtree)/usr/include - # Tell kbuild to always build the programs always := $(hostprogs-y) diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 10a015c..e7454fc 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -104,8 +104,7 @@ Table of Contents ============================== Most popular distro kernels ship with the bonding driver -already available as a module and the ifenslave user level control -program installed and ready for use. If your distro does not, or you +already available as a module. If your distro does not, or you have need to compile bonding from source (e.g., configuring and installing a mainline kernel from kernel.org), you'll need to perform the following steps: @@ -124,46 +123,13 @@ device support" section. It is recommended that you configure the driver as module since it is currently the only way to pass parameters to the driver or configure more than one bonding device. - Build and install the new kernel and modules, then continue -below to install ifenslave. + Build and install the new kernel and modules. -1.2 Install ifenslave Control Utility +1.2 Bonding Control Utility ------------------------------------- - The ifenslave user level control program is included in the -kernel source tree, in the file Documentation/networking/ifenslave.c. -It is generally recommended that you use the ifenslave that -corresponds to the kernel that you are using (either from the same -source tree or supplied with the distro), however, ifenslave -executables from older kernels should function (but features newer -than the ifenslave release are not supported). Running an ifenslave -that is newer than the kernel is not supported, and may or may not -work. - - To install ifenslave, do the following: - -# gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave -# cp ifenslave /sbin/ifenslave - - If your kernel source is not in "/usr/src/linux," then replace -"/usr/src/linux/include" in the above with the location of your kernel -source include directory. - - You may wish to back up any existing /sbin/ifenslave, or, for -testing or informal use, tag the ifenslave to the kernel version -(e.g., name the ifenslave executable /sbin/ifenslave-2.6.10). - -IMPORTANT NOTE: - - If you omit the "-I" or specify an incorrect directory, you -may end up with an ifenslave that is incompatible with the kernel -you're trying to build it for. Some distros (e.g., Red Hat from 7.1 -onwards) do not have /usr/include/linux symbolically linked to the -default kernel source include directory. - -SECOND IMPORTANT NOTE: - If you plan to configure bonding using sysfs or using the -/etc/network/interfaces file, you do not need to use ifenslave. + It is recommended to configure bonding via iproute2 (netlink) +or sysfs, the old ifenslave control utility is obsolete. 2. Bonding Driver Options ========================= @@ -851,7 +817,7 @@ resend_igmp ============================== You can configure bonding using either your distro's network -initialization scripts, or manually using either ifenslave or the +initialization scripts, or manually using either iproute2 or the sysfs interface. Distros generally use one of three packages for the network initialization scripts: initscripts, sysconfig or interfaces. Recent versions of these packages have support for bonding, while older @@ -1160,7 +1126,7 @@ not support this method for specifying multiple bonding interfaces; for those instances, see the "Configuring Multiple Bonds Manually" section, below. -3.3 Configuring Bonding Manually with Ifenslave +3.3 Configuring Bonding Manually with iproute2 ----------------------------------------------- This section applies to distros whose network initialization @@ -1171,7 +1137,7 @@ version 8. The general method for these systems is to place the bonding module parameters into a config file in /etc/modprobe.d/ (as appropriate for the installed distro), then add modprobe and/or -ifenslave commands to the system's global init script. The name of +`ip link` commands to the system's global init script. The name of the global init script differs; for sysconfig, it is /etc/init.d/boot.local and for initscripts it is /etc/rc.d/rc.local. @@ -1183,8 +1149,8 @@ reboots, edit the appropriate file (/etc/init.d/boot.local or modprobe bonding mode=balance-alb miimon=100 modprobe e100 ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up -ifenslave bond0 eth0 -ifenslave bond0 eth1 +ip link set eth0 master bond0 +ip link set eth1 master bond0 Replace the example bonding module parameters and bond0 network configuration (IP address, netmask, etc) with the appropriate diff --git a/Documentation/networking/ifenslave.c b/Documentation/networking/ifenslave.c deleted file mode 100644 index 9f6a8ff..0000000 --- a/Documentation/networking/ifenslave.c +++ /dev/null @@ -1,1105 +0,0 @@ -/* Mode: C; - * ifenslave.c: Configure network interfaces for parallel routing. - * - * This program controls the Linux implementation of running multiple - * network interfaces in parallel. - * - * Author: Donald Becker - * Copyright 1994-1996 Donald Becker - * - * This program is free software; you can redistribute it - * and/or modify it under the terms of the GNU General Public - * License as published by the Free Software Foundation. - * - * The author may be reached as becker@CESDIS.gsfc.nasa.gov, or C/O - * Center of Excellence in Space Data and Information Sciences - * Code 930.5, Goddard Space Flight Center, Greenbelt MD 20771 - * - * Changes : - * - 2000/10/02 Willy Tarreau : - * - few fixes. Master's MAC address is now correctly taken from - * the first device when not previously set ; - * - detach support : call BOND_RELEASE to detach an enslaved interface. - * - give a mini-howto from command-line help : # ifenslave -h - * - * - 2001/02/16 Chad N. Tindel : - * - Master is now brought down before setting the MAC address. In - * the 2.4 kernel you can't change the MAC address while the device is - * up because you get EBUSY. - * - * - 2001/09/13 Takao Indoh - * - Added the ability to change the active interface on a mode 1 bond - * at runtime. - * - * - 2001/10/23 Chad N. Tindel : - * - No longer set the MAC address of the master. The bond device will - * take care of this itself - * - Try the SIOC*** versions of the bonding ioctls before using the - * old versions - * - 2002/02/18 Erik Habbinga : - * - ifr2.ifr_flags was not initialized in the hwaddr_notset case, - * SIOCGIFFLAGS now called before hwaddr_notset test - * - * - 2002/10/31 Tony Cureington : - * - If the master does not have a hardware address when the first slave - * is enslaved, the master is assigned the hardware address of that - * slave - there is a comment in bonding.c stating "ifenslave takes - * care of this now." This corrects the problem of slaves having - * different hardware addresses in active-backup mode when - * multiple interfaces are specified on a single ifenslave command - * (ifenslave bond0 eth0 eth1). - * - * - 2003/03/18 - Tsippy Mendelson and - * Shmulik Hen - * - Moved setting the slave's mac address and openning it, from - * the application to the driver. This enables support of modes - * that need to use the unique mac address of each slave. - * The driver also takes care of closing the slave and restoring its - * original mac address upon release. - * In addition, block possibility of enslaving before the master is up. - * This prevents putting the system in an undefined state. - * - * - 2003/05/01 - Amir Noam - * - Added ABI version control to restore compatibility between - * new/old ifenslave and new/old bonding. - * - Prevent adding an adapter that is already a slave. - * Fixes the problem of stalling the transmission and leaving - * the slave in a down state. - * - * - 2003/05/01 - Shmulik Hen - * - Prevent enslaving if the bond device is down. - * Fixes the problem of leaving the system in unstable state and - * halting when trying to remove the module. - * - Close socket on all abnormal exists. - * - Add versioning scheme that follows that of the bonding driver. - * current version is 1.0.0 as a base line. - * - * - 2003/05/22 - Jay Vosburgh - * - ifenslave -c was broken; it's now fixed - * - Fixed problem with routes vanishing from master during enslave - * processing. - * - * - 2003/05/27 - Amir Noam - * - Fix backward compatibility issues: - * For drivers not using ABI versions, slave was set down while - * it should be left up before enslaving. - * Also, master was not set down and the default set_mac_address() - * would fail and generate an error message in the system log. - * - For opt_c: slave should not be set to the master's setting - * while it is running. It was already set during enslave. To - * simplify things, it is now handled separately. - * - * - 2003/12/01 - Shmulik Hen - * - Code cleanup and style changes - * set version to 1.1.0 - */ - -#define APP_VERSION "1.1.0" -#define APP_RELDATE "December 1, 2003" -#define APP_NAME "ifenslave" - -static char *version = -APP_NAME ".c:v" APP_VERSION " (" APP_RELDATE ")\n" -"o Donald Becker (becker@cesdis.gsfc.nasa.gov).\n" -"o Detach support added on 2000/10/02 by Willy Tarreau (willy at meta-x.org).\n" -"o 2.4 kernel support added on 2001/02/16 by Chad N. Tindel\n" -" (ctindel at ieee dot org).\n"; - -static const char *usage_msg = -"Usage: ifenslave [-f] [...]\n" -" ifenslave -d [...]\n" -" ifenslave -c \n" -" ifenslave --help\n"; - -static const char *help_msg = -"\n" -" To create a bond device, simply follow these three steps :\n" -" - ensure that the required drivers are properly loaded :\n" -" # modprobe bonding ; modprobe <3c59x|eepro100|pcnet32|tulip|...>\n" -" - assign an IP address to the bond device :\n" -" # ifconfig bond0 netmask broadcast \n" -" - attach all the interfaces you need to the bond device :\n" -" # ifenslave [{-f|--force}] bond0 eth0 [eth1 [eth2]...]\n" -" If bond0 didn't have a MAC address, it will take eth0's. Then, all\n" -" interfaces attached AFTER this assignment will get the same MAC addr.\n" -" (except for ALB/TLB modes)\n" -"\n" -" To set the bond device down and automatically release all the slaves :\n" -" # ifconfig bond0 down\n" -"\n" -" To detach a dead interface without setting the bond device down :\n" -" # ifenslave {-d|--detach} bond0 eth0 [eth1 [eth2]...]\n" -"\n" -" To change active slave :\n" -" # ifenslave {-c|--change-active} bond0 eth0\n" -"\n" -" To show master interface info\n" -" # ifenslave bond0\n" -"\n" -" To show all interfaces info\n" -" # ifenslave {-a|--all-interfaces}\n" -"\n" -" To be more verbose\n" -" # ifenslave {-v|--verbose} ...\n" -"\n" -" # ifenslave {-u|--usage} Show usage\n" -" # ifenslave {-V|--version} Show version\n" -" # ifenslave {-h|--help} This message\n" -"\n"; - -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include -#include - -typedef unsigned long long u64; /* hack, so we may include kernel's ethtool.h */ -typedef __uint32_t u32; /* ditto */ -typedef __uint16_t u16; /* ditto */ -typedef __uint8_t u8; /* ditto */ -#include - -struct option longopts[] = { - /* { name has_arg *flag val } */ - {"all-interfaces", 0, 0, 'a'}, /* Show all interfaces. */ - {"change-active", 0, 0, 'c'}, /* Change the active slave. */ - {"detach", 0, 0, 'd'}, /* Detach a slave interface. */ - {"force", 0, 0, 'f'}, /* Force the operation. */ - {"help", 0, 0, 'h'}, /* Give help */ - {"usage", 0, 0, 'u'}, /* Give usage */ - {"verbose", 0, 0, 'v'}, /* Report each action taken. */ - {"version", 0, 0, 'V'}, /* Emit version information. */ - { 0, 0, 0, 0} -}; - -/* Command-line flags. */ -unsigned int -opt_a = 0, /* Show-all-interfaces flag. */ -opt_c = 0, /* Change-active-slave flag. */ -opt_d = 0, /* Detach a slave interface. */ -opt_f = 0, /* Force the operation. */ -opt_h = 0, /* Help */ -opt_u = 0, /* Usage */ -opt_v = 0, /* Verbose flag. */ -opt_V = 0; /* Version */ - -int skfd = -1; /* AF_INET socket for ioctl() calls.*/ -int abi_ver = 0; /* userland - kernel ABI version */ -int hwaddr_set = 0; /* Master's hwaddr is set */ -int saved_errno; - -struct ifreq master_mtu, master_flags, master_hwaddr; -struct ifreq slave_mtu, slave_flags, slave_hwaddr; - -struct dev_ifr { - struct ifreq *req_ifr; - char *req_name; - int req_type; -}; - -struct dev_ifr master_ifra[] = { - {&master_mtu, "SIOCGIFMTU", SIOCGIFMTU}, - {&master_flags, "SIOCGIFFLAGS", SIOCGIFFLAGS}, - {&master_hwaddr, "SIOCGIFHWADDR", SIOCGIFHWADDR}, - {NULL, "", 0} -}; - -struct dev_ifr slave_ifra[] = { - {&slave_mtu, "SIOCGIFMTU", SIOCGIFMTU}, - {&slave_flags, "SIOCGIFFLAGS", SIOCGIFFLAGS}, - {&slave_hwaddr, "SIOCGIFHWADDR", SIOCGIFHWADDR}, - {NULL, "", 0} -}; - -static void if_print(char *ifname); -static int get_drv_info(char *master_ifname); -static int get_if_settings(char *ifname, struct dev_ifr ifra[]); -static int get_slave_flags(char *slave_ifname); -static int set_master_hwaddr(char *master_ifname, struct sockaddr *hwaddr); -static int set_slave_hwaddr(char *slave_ifname, struct sockaddr *hwaddr); -static int set_slave_mtu(char *slave_ifname, int mtu); -static int set_if_flags(char *ifname, short flags); -static int set_if_up(char *ifname, short flags); -static int set_if_down(char *ifname, short flags); -static int clear_if_addr(char *ifname); -static int set_if_addr(char *master_ifname, char *slave_ifname); -static int change_active(char *master_ifname, char *slave_ifname); -static int enslave(char *master_ifname, char *slave_ifname); -static int release(char *master_ifname, char *slave_ifname); -#define v_print(fmt, args...) \ - if (opt_v) \ - fprintf(stderr, fmt, ## args ) - -int main(int argc, char *argv[]) -{ - char **spp, *master_ifname, *slave_ifname; - int c, i, rv; - int res = 0; - int exclusive = 0; - - while ((c = getopt_long(argc, argv, "acdfhuvV", longopts, 0)) != EOF) { - switch (c) { - case 'a': opt_a++; exclusive++; break; - case 'c': opt_c++; exclusive++; break; - case 'd': opt_d++; exclusive++; break; - case 'f': opt_f++; exclusive++; break; - case 'h': opt_h++; exclusive++; break; - case 'u': opt_u++; exclusive++; break; - case 'v': opt_v++; break; - case 'V': opt_V++; exclusive++; break; - - case '?': - fprintf(stderr, "%s", usage_msg); - res = 2; - goto out; - } - } - - /* options check */ - if (exclusive > 1) { - fprintf(stderr, "%s", usage_msg); - res = 2; - goto out; - } - - if (opt_v || opt_V) { - printf("%s", version); - if (opt_V) { - res = 0; - goto out; - } - } - - if (opt_u) { - printf("%s", usage_msg); - res = 0; - goto out; - } - - if (opt_h) { - printf("%s", usage_msg); - printf("%s", help_msg); - res = 0; - goto out; - } - - /* Open a basic socket */ - if ((skfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { - perror("socket"); - res = 1; - goto out; - } - - if (opt_a) { - if (optind == argc) { - /* No remaining args */ - /* show all interfaces */ - if_print((char *)NULL); - goto out; - } else { - /* Just show usage */ - fprintf(stderr, "%s", usage_msg); - res = 2; - goto out; - } - } - - /* Copy the interface name */ - spp = argv + optind; - master_ifname = *spp++; - - if (master_ifname == NULL) { - fprintf(stderr, "%s", usage_msg); - res = 2; - goto out; - } - - /* exchange abi version with bonding module */ - res = get_drv_info(master_ifname); - if (res) { - fprintf(stderr, - "Master '%s': Error: handshake with driver failed. " - "Aborting\n", - master_ifname); - goto out; - } - - slave_ifname = *spp++; - - if (slave_ifname == NULL) { - if (opt_d || opt_c) { - fprintf(stderr, "%s", usage_msg); - res = 2; - goto out; - } - - /* A single arg means show the - * configuration for this interface - */ - if_print(master_ifname); - goto out; - } - - res = get_if_settings(master_ifname, master_ifra); - if (res) { - /* Probably a good reason not to go on */ - fprintf(stderr, - "Master '%s': Error: get settings failed: %s. " - "Aborting\n", - master_ifname, strerror(res)); - goto out; - } - - /* check if master is indeed a master; - * if not then fail any operation - */ - if (!(master_flags.ifr_flags & IFF_MASTER)) { - fprintf(stderr, - "Illegal operation; the specified interface '%s' " - "is not a master. Aborting\n", - master_ifname); - res = 1; - goto out; - } - - /* check if master is up; if not then fail any operation */ - if (!(master_flags.ifr_flags & IFF_UP)) { - fprintf(stderr, - "Illegal operation; the specified master interface " - "'%s' is not up.\n", - master_ifname); - res = 1; - goto out; - } - - /* Only for enslaving */ - if (!opt_c && !opt_d) { - sa_family_t master_family = master_hwaddr.ifr_hwaddr.sa_family; - unsigned char *hwaddr = - (unsigned char *)master_hwaddr.ifr_hwaddr.sa_data; - - /* The family '1' is ARPHRD_ETHER for ethernet. */ - if (master_family != 1 && !opt_f) { - fprintf(stderr, - "Illegal operation: The specified master " - "interface '%s' is not ethernet-like.\n " - "This program is designed to work with " - "ethernet-like network interfaces.\n " - "Use the '-f' option to force the " - "operation.\n", - master_ifname); - res = 1; - goto out; - } - - /* Check master's hw addr */ - for (i = 0; i < 6; i++) { - if (hwaddr[i] != 0) { - hwaddr_set = 1; - break; - } - } - - if (hwaddr_set) { - v_print("current hardware address of master '%s' " - "is %2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x, " - "type %d\n", - master_ifname, - hwaddr[0], hwaddr[1], - hwaddr[2], hwaddr[3], - hwaddr[4], hwaddr[5], - master_family); - } - } - - /* Accepts only one slave */ - if (opt_c) { - /* change active slave */ - res = get_slave_flags(slave_ifname); - if (res) { - fprintf(stderr, - "Slave '%s': Error: get flags failed. " - "Aborting\n", - slave_ifname); - goto out; - } - res = change_active(master_ifname, slave_ifname); - if (res) { - fprintf(stderr, - "Master '%s', Slave '%s': Error: " - "Change active failed\n", - master_ifname, slave_ifname); - } - } else { - /* Accept multiple slaves */ - do { - if (opt_d) { - /* detach a slave interface from the master */ - rv = get_slave_flags(slave_ifname); - if (rv) { - /* Can't work with this slave. */ - /* remember the error and skip it*/ - fprintf(stderr, - "Slave '%s': Error: get flags " - "failed. Skipping\n", - slave_ifname); - res = rv; - continue; - } - rv = release(master_ifname, slave_ifname); - if (rv) { - fprintf(stderr, - "Master '%s', Slave '%s': Error: " - "Release failed\n", - master_ifname, slave_ifname); - res = rv; - } - } else { - /* attach a slave interface to the master */ - rv = get_if_settings(slave_ifname, slave_ifra); - if (rv) { - /* Can't work with this slave. */ - /* remember the error and skip it*/ - fprintf(stderr, - "Slave '%s': Error: get " - "settings failed: %s. " - "Skipping\n", - slave_ifname, strerror(rv)); - res = rv; - continue; - } - rv = enslave(master_ifname, slave_ifname); - if (rv) { - fprintf(stderr, - "Master '%s', Slave '%s': Error: " - "Enslave failed\n", - master_ifname, slave_ifname); - res = rv; - } - } - } while ((slave_ifname = *spp++) != NULL); - } - -out: - if (skfd >= 0) { - close(skfd); - } - - return res; -} - -static short mif_flags; - -/* Get the interface configuration from the kernel. */ -static int if_getconfig(char *ifname) -{ - struct ifreq ifr; - int metric, mtu; /* Parameters of the master interface. */ - struct sockaddr dstaddr, broadaddr, netmask; - unsigned char *hwaddr; - - strcpy(ifr.ifr_name, ifname); - if (ioctl(skfd, SIOCGIFFLAGS, &ifr) < 0) - return -1; - mif_flags = ifr.ifr_flags; - printf("The result of SIOCGIFFLAGS on %s is %x.\n", - ifname, ifr.ifr_flags); - - strcpy(ifr.ifr_name, ifname); - if (ioctl(skfd, SIOCGIFADDR, &ifr) < 0) - return -1; - printf("The result of SIOCGIFADDR is %2.2x.%2.2x.%2.2x.%2.2x.\n", - ifr.ifr_addr.sa_data[0], ifr.ifr_addr.sa_data[1], - ifr.ifr_addr.sa_data[2], ifr.ifr_addr.sa_data[3]); - - strcpy(ifr.ifr_name, ifname); - if (ioctl(skfd, SIOCGIFHWADDR, &ifr) < 0) - return -1; - - /* Gotta convert from 'char' to unsigned for printf(). */ - hwaddr = (unsigned char *)ifr.ifr_hwaddr.sa_data; - printf("The result of SIOCGIFHWADDR is type %d " - "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n", - ifr.ifr_hwaddr.sa_family, hwaddr[0], hwaddr[1], - hwaddr[2], hwaddr[3], hwaddr[4], hwaddr[5]); - - strcpy(ifr.ifr_name, ifname); - if (ioctl(skfd, SIOCGIFMETRIC, &ifr) < 0) { - metric = 0; - } else - metric = ifr.ifr_metric; - printf("The result of SIOCGIFMETRIC is %d\n", metric); - - strcpy(ifr.ifr_name, ifname); - if (ioctl(skfd, SIOCGIFMTU, &ifr) < 0) - mtu = 0; - else - mtu = ifr.ifr_mtu; - printf("The result of SIOCGIFMTU is %d\n", mtu); - - strcpy(ifr.ifr_name, ifname); - if (ioctl(skfd, SIOCGIFDSTADDR, &ifr) < 0) { - memset(&dstaddr, 0, sizeof(struct sockaddr)); - } else - dstaddr = ifr.ifr_dstaddr; - - strcpy(ifr.ifr_name, ifname); - if (ioctl(skfd, SIOCGIFBRDADDR, &ifr) < 0) { - memset(&broadaddr, 0, sizeof(struct sockaddr)); - } else - broadaddr = ifr.ifr_broadaddr; - - strcpy(ifr.ifr_name, ifname); - if (ioctl(skfd, SIOCGIFNETMASK, &ifr) < 0) { - memset(&netmask, 0, sizeof(struct sockaddr)); - } else - netmask = ifr.ifr_netmask; - - return 0; -} - -static void if_print(char *ifname) -{ - char buff[1024]; - struct ifconf ifc; - struct ifreq *ifr; - int i; - - if (ifname == (char *)NULL) { - ifc.ifc_len = sizeof(buff); - ifc.ifc_buf = buff; - if (ioctl(skfd, SIOCGIFCONF, &ifc) < 0) { - perror("SIOCGIFCONF failed"); - return; - } - - ifr = ifc.ifc_req; - for (i = ifc.ifc_len / sizeof(struct ifreq); --i >= 0; ifr++) { - if (if_getconfig(ifr->ifr_name) < 0) { - fprintf(stderr, - "%s: unknown interface.\n", - ifr->ifr_name); - continue; - } - - if (((mif_flags & IFF_UP) == 0) && !opt_a) continue; - /*ife_print(&ife);*/ - } - } else { - if (if_getconfig(ifname) < 0) { - fprintf(stderr, - "%s: unknown interface.\n", ifname); - } - } -} - -static int get_drv_info(char *master_ifname) -{ - struct ifreq ifr; - struct ethtool_drvinfo info; - char *endptr; - - memset(&ifr, 0, sizeof(ifr)); - strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); - ifr.ifr_data = (caddr_t)&info; - - info.cmd = ETHTOOL_GDRVINFO; - strncpy(info.driver, "ifenslave", 32); - snprintf(info.fw_version, 32, "%d", BOND_ABI_VERSION); - - if (ioctl(skfd, SIOCETHTOOL, &ifr) < 0) { - if (errno == EOPNOTSUPP) { - goto out; - } - - saved_errno = errno; - v_print("Master '%s': Error: get bonding info failed %s\n", - master_ifname, strerror(saved_errno)); - return 1; - } - - abi_ver = strtoul(info.fw_version, &endptr, 0); - if (*endptr) { - v_print("Master '%s': Error: got invalid string as an ABI " - "version from the bonding module\n", - master_ifname); - return 1; - } - -out: - v_print("ABI ver is %d\n", abi_ver); - - return 0; -} - -static int change_active(char *master_ifname, char *slave_ifname) -{ - struct ifreq ifr; - int res = 0; - - if (!(slave_flags.ifr_flags & IFF_SLAVE)) { - fprintf(stderr, - "Illegal operation: The specified slave interface " - "'%s' is not a slave\n", - slave_ifname); - return 1; - } - - strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); - strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ); - if ((ioctl(skfd, SIOCBONDCHANGEACTIVE, &ifr) < 0) && - (ioctl(skfd, BOND_CHANGE_ACTIVE_OLD, &ifr) < 0)) { - saved_errno = errno; - v_print("Master '%s': Error: SIOCBONDCHANGEACTIVE failed: " - "%s\n", - master_ifname, strerror(saved_errno)); - res = 1; - } - - return res; -} - -static int enslave(char *master_ifname, char *slave_ifname) -{ - struct ifreq ifr; - int res = 0; - - if (slave_flags.ifr_flags & IFF_SLAVE) { - fprintf(stderr, - "Illegal operation: The specified slave interface " - "'%s' is already a slave\n", - slave_ifname); - return 1; - } - - res = set_if_down(slave_ifname, slave_flags.ifr_flags); - if (res) { - fprintf(stderr, - "Slave '%s': Error: bring interface down failed\n", - slave_ifname); - return res; - } - - if (abi_ver < 2) { - /* Older bonding versions would panic if the slave has no IP - * address, so get the IP setting from the master. - */ - set_if_addr(master_ifname, slave_ifname); - } else { - res = clear_if_addr(slave_ifname); - if (res) { - fprintf(stderr, - "Slave '%s': Error: clear address failed\n", - slave_ifname); - return res; - } - } - - if (master_mtu.ifr_mtu != slave_mtu.ifr_mtu) { - res = set_slave_mtu(slave_ifname, master_mtu.ifr_mtu); - if (res) { - fprintf(stderr, - "Slave '%s': Error: set MTU failed\n", - slave_ifname); - return res; - } - } - - if (hwaddr_set) { - /* Master already has an hwaddr - * so set it's hwaddr to the slave - */ - if (abi_ver < 1) { - /* The driver is using an old ABI, so - * the application sets the slave's - * hwaddr - */ - res = set_slave_hwaddr(slave_ifname, - &(master_hwaddr.ifr_hwaddr)); - if (res) { - fprintf(stderr, - "Slave '%s': Error: set hw address " - "failed\n", - slave_ifname); - goto undo_mtu; - } - - /* For old ABI the application needs to bring the - * slave back up - */ - res = set_if_up(slave_ifname, slave_flags.ifr_flags); - if (res) { - fprintf(stderr, - "Slave '%s': Error: bring interface " - "down failed\n", - slave_ifname); - goto undo_slave_mac; - } - } - /* The driver is using a new ABI, - * so the driver takes care of setting - * the slave's hwaddr and bringing - * it up again - */ - } else { - /* No hwaddr for master yet, so - * set the slave's hwaddr to it - */ - if (abi_ver < 1) { - /* For old ABI, the master needs to be - * down before setting its hwaddr - */ - res = set_if_down(master_ifname, master_flags.ifr_flags); - if (res) { - fprintf(stderr, - "Master '%s': Error: bring interface " - "down failed\n", - master_ifname); - goto undo_mtu; - } - } - - res = set_master_hwaddr(master_ifname, - &(slave_hwaddr.ifr_hwaddr)); - if (res) { - fprintf(stderr, - "Master '%s': Error: set hw address " - "failed\n", - master_ifname); - goto undo_mtu; - } - - if (abi_ver < 1) { - /* For old ABI, bring the master - * back up - */ - res = set_if_up(master_ifname, master_flags.ifr_flags); - if (res) { - fprintf(stderr, - "Master '%s': Error: bring interface " - "up failed\n", - master_ifname); - goto undo_master_mac; - } - } - - hwaddr_set = 1; - } - - /* Do the real thing */ - strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); - strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ); - if ((ioctl(skfd, SIOCBONDENSLAVE, &ifr) < 0) && - (ioctl(skfd, BOND_ENSLAVE_OLD, &ifr) < 0)) { - saved_errno = errno; - v_print("Master '%s': Error: SIOCBONDENSLAVE failed: %s\n", - master_ifname, strerror(saved_errno)); - res = 1; - } - - if (res) { - goto undo_master_mac; - } - - return 0; - -/* rollback (best effort) */ -undo_master_mac: - set_master_hwaddr(master_ifname, &(master_hwaddr.ifr_hwaddr)); - hwaddr_set = 0; - goto undo_mtu; -undo_slave_mac: - set_slave_hwaddr(slave_ifname, &(slave_hwaddr.ifr_hwaddr)); -undo_mtu: - set_slave_mtu(slave_ifname, slave_mtu.ifr_mtu); - return res; -} - -static int release(char *master_ifname, char *slave_ifname) -{ - struct ifreq ifr; - int res = 0; - - if (!(slave_flags.ifr_flags & IFF_SLAVE)) { - fprintf(stderr, - "Illegal operation: The specified slave interface " - "'%s' is not a slave\n", - slave_ifname); - return 1; - } - - strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); - strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ); - if ((ioctl(skfd, SIOCBONDRELEASE, &ifr) < 0) && - (ioctl(skfd, BOND_RELEASE_OLD, &ifr) < 0)) { - saved_errno = errno; - v_print("Master '%s': Error: SIOCBONDRELEASE failed: %s\n", - master_ifname, strerror(saved_errno)); - return 1; - } else if (abi_ver < 1) { - /* The driver is using an old ABI, so we'll set the interface - * down to avoid any conflicts due to same MAC/IP - */ - res = set_if_down(slave_ifname, slave_flags.ifr_flags); - if (res) { - fprintf(stderr, - "Slave '%s': Error: bring interface " - "down failed\n", - slave_ifname); - } - } - - /* set to default mtu */ - set_slave_mtu(slave_ifname, 1500); - - return res; -} - -static int get_if_settings(char *ifname, struct dev_ifr ifra[]) -{ - int i; - int res = 0; - - for (i = 0; ifra[i].req_ifr; i++) { - strncpy(ifra[i].req_ifr->ifr_name, ifname, IFNAMSIZ); - res = ioctl(skfd, ifra[i].req_type, ifra[i].req_ifr); - if (res < 0) { - saved_errno = errno; - v_print("Interface '%s': Error: %s failed: %s\n", - ifname, ifra[i].req_name, - strerror(saved_errno)); - - return saved_errno; - } - } - - return 0; -} - -static int get_slave_flags(char *slave_ifname) -{ - int res = 0; - - strncpy(slave_flags.ifr_name, slave_ifname, IFNAMSIZ); - res = ioctl(skfd, SIOCGIFFLAGS, &slave_flags); - if (res < 0) { - saved_errno = errno; - v_print("Slave '%s': Error: SIOCGIFFLAGS failed: %s\n", - slave_ifname, strerror(saved_errno)); - } else { - v_print("Slave %s: flags %04X.\n", - slave_ifname, slave_flags.ifr_flags); - } - - return res; -} - -static int set_master_hwaddr(char *master_ifname, struct sockaddr *hwaddr) -{ - unsigned char *addr = (unsigned char *)hwaddr->sa_data; - struct ifreq ifr; - int res = 0; - - strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); - memcpy(&(ifr.ifr_hwaddr), hwaddr, sizeof(struct sockaddr)); - res = ioctl(skfd, SIOCSIFHWADDR, &ifr); - if (res < 0) { - saved_errno = errno; - v_print("Master '%s': Error: SIOCSIFHWADDR failed: %s\n", - master_ifname, strerror(saved_errno)); - return res; - } else { - v_print("Master '%s': hardware address set to " - "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n", - master_ifname, addr[0], addr[1], addr[2], - addr[3], addr[4], addr[5]); - } - - return res; -} - -static int set_slave_hwaddr(char *slave_ifname, struct sockaddr *hwaddr) -{ - unsigned char *addr = (unsigned char *)hwaddr->sa_data; - struct ifreq ifr; - int res = 0; - - strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ); - memcpy(&(ifr.ifr_hwaddr), hwaddr, sizeof(struct sockaddr)); - res = ioctl(skfd, SIOCSIFHWADDR, &ifr); - if (res < 0) { - saved_errno = errno; - - v_print("Slave '%s': Error: SIOCSIFHWADDR failed: %s\n", - slave_ifname, strerror(saved_errno)); - - if (saved_errno == EBUSY) { - v_print(" The device is busy: it must be idle " - "before running this command.\n"); - } else if (saved_errno == EOPNOTSUPP) { - v_print(" The device does not support setting " - "the MAC address.\n" - " Your kernel likely does not support slave " - "devices.\n"); - } else if (saved_errno == EINVAL) { - v_print(" The device's address type does not match " - "the master's address type.\n"); - } - return res; - } else { - v_print("Slave '%s': hardware address set to " - "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n", - slave_ifname, addr[0], addr[1], addr[2], - addr[3], addr[4], addr[5]); - } - - return res; -} - -static int set_slave_mtu(char *slave_ifname, int mtu) -{ - struct ifreq ifr; - int res = 0; - - ifr.ifr_mtu = mtu; - strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ); - - res = ioctl(skfd, SIOCSIFMTU, &ifr); - if (res < 0) { - saved_errno = errno; - v_print("Slave '%s': Error: SIOCSIFMTU failed: %s\n", - slave_ifname, strerror(saved_errno)); - } else { - v_print("Slave '%s': MTU set to %d.\n", slave_ifname, mtu); - } - - return res; -} - -static int set_if_flags(char *ifname, short flags) -{ - struct ifreq ifr; - int res = 0; - - ifr.ifr_flags = flags; - strncpy(ifr.ifr_name, ifname, IFNAMSIZ); - - res = ioctl(skfd, SIOCSIFFLAGS, &ifr); - if (res < 0) { - saved_errno = errno; - v_print("Interface '%s': Error: SIOCSIFFLAGS failed: %s\n", - ifname, strerror(saved_errno)); - } else { - v_print("Interface '%s': flags set to %04X.\n", ifname, flags); - } - - return res; -} - -static int set_if_up(char *ifname, short flags) -{ - return set_if_flags(ifname, flags | IFF_UP); -} - -static int set_if_down(char *ifname, short flags) -{ - return set_if_flags(ifname, flags & ~IFF_UP); -} - -static int clear_if_addr(char *ifname) -{ - struct ifreq ifr; - int res = 0; - - strncpy(ifr.ifr_name, ifname, IFNAMSIZ); - ifr.ifr_addr.sa_family = AF_INET; - memset(ifr.ifr_addr.sa_data, 0, sizeof(ifr.ifr_addr.sa_data)); - - res = ioctl(skfd, SIOCSIFADDR, &ifr); - if (res < 0) { - saved_errno = errno; - v_print("Interface '%s': Error: SIOCSIFADDR failed: %s\n", - ifname, strerror(saved_errno)); - } else { - v_print("Interface '%s': address cleared\n", ifname); - } - - return res; -} - -static int set_if_addr(char *master_ifname, char *slave_ifname) -{ - struct ifreq ifr; - int res; - unsigned char *ipaddr; - int i; - struct { - char *req_name; - char *desc; - int g_ioctl; - int s_ioctl; - } ifra[] = { - {"IFADDR", "addr", SIOCGIFADDR, SIOCSIFADDR}, - {"DSTADDR", "destination addr", SIOCGIFDSTADDR, SIOCSIFDSTADDR}, - {"BRDADDR", "broadcast addr", SIOCGIFBRDADDR, SIOCSIFBRDADDR}, - {"NETMASK", "netmask", SIOCGIFNETMASK, SIOCSIFNETMASK}, - {NULL, NULL, 0, 0}, - }; - - for (i = 0; ifra[i].req_name; i++) { - strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ); - res = ioctl(skfd, ifra[i].g_ioctl, &ifr); - if (res < 0) { - int saved_errno = errno; - - v_print("Interface '%s': Error: SIOCG%s failed: %s\n", - master_ifname, ifra[i].req_name, - strerror(saved_errno)); - - ifr.ifr_addr.sa_family = AF_INET; - memset(ifr.ifr_addr.sa_data, 0, - sizeof(ifr.ifr_addr.sa_data)); - } - - strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ); - res = ioctl(skfd, ifra[i].s_ioctl, &ifr); - if (res < 0) { - int saved_errno = errno; - - v_print("Interface '%s': Error: SIOCS%s failed: %s\n", - slave_ifname, ifra[i].req_name, - strerror(saved_errno)); - - } - - ipaddr = (unsigned char *)ifr.ifr_addr.sa_data; - v_print("Interface '%s': set IP %s to %d.%d.%d.%d\n", - slave_ifname, ifra[i].desc, - ipaddr[0], ipaddr[1], ipaddr[2], ipaddr[3]); - } - - return 0; -} - -/* - * Local variables: - * version-control: t - * kept-new-versions: 5 - * c-indent-level: 4 - * c-basic-offset: 4 - * tab-width: 4 - * compile-command: "gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave" - * End: - */ - -- cgit v1.1 From 08825c90af6e4bb902b3a51abb0ae6530199f682 Mon Sep 17 00:00:00 2001 From: Li Zefan Date: Fri, 17 May 2013 10:31:20 +0800 Subject: watchdog: Document watchdog_thresh sysctl Signed-off-by: Li Zefan Acked-by: Don Zickus Link: http://lkml.kernel.org/r/51959678.6000802@huawei.com Signed-off-by: Ingo Molnar --- Documentation/sysctl/kernel.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index ccd4258..e8fabd6 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -76,6 +76,7 @@ show up in /proc/sys/kernel: - tainted - threads-max - unknown_nmi_panic +- watchdog_thresh - version ============================================================== @@ -648,3 +649,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. + +============================================================== -- cgit v1.1 From c0ffaf3655fab1909a920c8f30ba1722932d01bb Mon Sep 17 00:00:00 2001 From: Li Zefan Date: Fri, 17 May 2013 10:31:35 +0800 Subject: watchdog: Remove softlockup_thresh from Documentation The old softlockup detector has been replaced with new lockup detector long ago. Signed-off-by: Li Zefan Acked-by: Don Zickus Link: http://lkml.kernel.org/r/51959687.9090305@huawei.com Signed-off-by: Ingo Molnar --- Documentation/sysctl/kernel.txt | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index e8fabd6..bcff3f9 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -70,7 +70,6 @@ show up in /proc/sys/kernel: - shmall - shmmax [ sysv ipc ] - shmmni -- softlockup_thresh - stop-a [ SPARC only ] - sysrq ==> Documentation/sysrq.txt - tainted @@ -605,15 +604,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 -- cgit v1.1 From bbc79089ae2bd0306db7f8dce85d56f9be65b205 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Mon, 22 Apr 2013 11:55:54 +0200 Subject: video: ssd1307fb: Add support for SSD1306 OLED controller The Solomon SSD1306 OLED controller is very similar to the SSD1307, except for the fact that the power is given through an external PWM for the 1307, and while the 1306 can generate its own power without any PWM. Signed-off-by: Maxime Ripard Signed-off-by: Tomi Valkeinen --- Documentation/devicetree/bindings/video/ssd1307fb.txt | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt index 3d0060c..7a12542 100644 --- a/Documentation/devicetree/bindings/video/ssd1307fb.txt +++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt @@ -1,13 +1,17 @@ * Solomon SSD1307 Framebuffer Driver Required properties: - - compatible: Should be "solomon,ssd1307fb-". The only supported bus for - now is i2c. + - compatible: Should be "solomon,fb-". The only supported bus for + now is i2c, and the supported chips are ssd1306 and ssd1307. - reg: Should contain address of the controller on the I2C bus. Most likely 0x3c or 0x3d - pwm: Should contain the pwm to use according to the OF device tree PWM - specification [0] + specification [0]. Only required for the ssd1307. - reset-gpios: Should contain the GPIO used to reset the OLED display + - solomon,height: Height in pixel of the screen driven by the controller + - solomon,width: Width in pixel of the screen driven by the controller + - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is + mapped to. Optional properties: - reset-active-low: Is the reset gpio is active on physical low? -- cgit v1.1 From ec23ad67f641b09673d337e80b7fb6afe424f621 Mon Sep 17 00:00:00 2001 From: Hiroshi Doyu Date: Wed, 22 May 2013 19:45:31 +0300 Subject: ARM: tegra20: create a DT header defining CLK IDs Create a header file to define the clock IDs used by the Tegra20 clock binding. Remove the list of definitions from the binding documentation, and refer the reader to the header file. This will allow the same header to be used by both device tree files, and drivers implementing this binding, which guarantees that the two stay in sync. This also makes device trees more readable by using names instead of magic numbers. Signed-off-by: Hiroshi Doyu [swarren, add header to clock/ instead of clk/ to match binding location] Signed-off-by: Stephen Warren --- .../bindings/clock/nvidia,tegra20-car.txt | 154 +-------------------- 1 file changed, 4 insertions(+), 150 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt index e885680..fcfed5b 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 + . 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>; }; }; -- cgit v1.1 From 9513109df85184ab5c4a20c939a0eeea92422118 Mon Sep 17 00:00:00 2001 From: Hiroshi Doyu Date: Wed, 22 May 2013 19:45:33 +0300 Subject: ARM: tegra30: create a DT header defining CLK IDs Create a header file to define the clock IDs used by the Tegra30 clock binding. Remove the list of definitions from the binding documentation, and refer the reader to the header file. This will allow the same header to be used by both device tree files, and drivers implementing this binding, which guarantees that the two stay in sync. This also makes device trees more readable by using names instead of magic numbers. Signed-off-by: Hiroshi Doyu [swarren, add header to clock/ instead of clk/ to match binding location] Signed-off-by: Stephen Warren --- .../bindings/clock/nvidia,tegra30-car.txt | 211 +-------------------- 1 file changed, 4 insertions(+), 207 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt index f3da3be..0f71408 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 + . 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>; }; }; -- cgit v1.1 From 992bb598f690542a2f539fd12a42b960b7692025 Mon Sep 17 00:00:00 2001 From: Hiroshi Doyu Date: Wed, 22 May 2013 19:45:35 +0300 Subject: ARM: tegra114: create a DT header defining CLK IDs Create a header file to define the clock IDs used by the Tegra114 clock binding. Remove the list of definitions from the binding documentation, and refer the reader to the header file. This will allow the same header to be used by both device tree files, and drivers implementing this binding, which guarantees that the two stay in sync. This also makes device trees more readable by using names instead of magic numbers. Signed-off-by: Hiroshi Doyu [swarren, add header to clock/ instead of clk/ to match binding location] Signed-off-by: Stephen Warren --- .../bindings/clock/nvidia,tegra114-car.txt | 252 +-------------------- 1 file changed, 4 insertions(+), 248 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt index d6cb083..0c80c26 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 + . 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>; }; }; -- cgit v1.1 From 1a0483d2a4c2c5e218d415c90d1a62b3b917d34e Mon Sep 17 00:00:00 2001 From: Sebastian Hesselbarth Date: Fri, 3 May 2013 07:33:27 +0200 Subject: clk: si5351: Allow user to define disabled state for every clock output This patch adds platform data and DT bindings to allow to overwrite the stored disabled state for each clock output. Signed-off-by: Marek Belisko Signed-off-by: Sebastian Hesselbarth Signed-off-by: Mike Turquette --- Documentation/devicetree/bindings/clock/silabs,si5351.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt index cc37465..66c75b2 100644 --- a/Documentation/devicetree/bindings/clock/silabs,si5351.txt +++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt @@ -44,6 +44,11 @@ Optional child node properties: - silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth divider. - silabs,pll-master: boolean, multisynth can change pll frequency. +- silabs,disable-state : clock output disable state, shall be + 0 = clock output is driven LOW when disabled + 1 = clock output is driven HIGH when disabled + 2 = clock output is FLOATING (HIGH-Z) when disabled + 3 = clock output is NEVER disabled ==Example== -- cgit v1.1 From 4f985b4c800e824cd4fdde00c9575dd573a7b933 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Tue, 30 Apr 2013 11:56:22 +0200 Subject: clk: sun5i: Add compatibles for Allwinner A13 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The A13 has a lot less clocks than the one found in the Allwinner A10. Add these stripped down clocks to the clock driver and in the documentation. Signed-off-by: Maxime Ripard Acked-by: Emilio López Signed-off-by: Mike Turquette --- Documentation/devicetree/bindings/clock/sunxi.txt | 117 +++------------------ .../bindings/clock/sunxi/sun4i-a10-gates.txt | 93 ++++++++++++++++ .../bindings/clock/sunxi/sun5i-a13-gates.txt | 58 ++++++++++ 3 files changed, 164 insertions(+), 104 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt create mode 100644 Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index 729f524..d495521 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -12,22 +12,30 @@ Required properties: "allwinner,sun4i-axi-clk" - for the AXI clock "allwinner,sun4i-axi-gates-clk" - for the AXI gates "allwinner,sun4i-ahb-clk" - for the AHB clock - "allwinner,sun4i-ahb-gates-clk" - for the AHB gates + "allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10 + "allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13 "allwinner,sun4i-apb0-clk" - for the APB0 clock - "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates + "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10 + "allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13 "allwinner,sun4i-apb1-clk" - for the APB1 clock "allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing - "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates + "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10 + "allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13 Required properties for all clocks: - reg : shall be the control register address for the clock. - clocks : shall be the input parent clock(s) phandle for the clock - #clock-cells : from common clock binding; shall be set to 0 except for - "allwinner,sun4i-*-gates-clk" where it shall be set to 1 + "allwinner,*-gates-clk" where it shall be set to 1 -Additionally, "allwinner,sun4i-*-gates-clk" clocks require: +Additionally, "allwinner,*-gates-clk" clocks require: - clock-output-names : the corresponding gate names that the clock controls +Clock consumers should specify the desired clocks they use with a +"clocks" phandle cell. Consumers that are using a gated clock should +provide an additional ID in their clock property. The values of this +ID are documented in sunxi/-gates.txt. + For example: osc24M: osc24M@01c20050 { @@ -50,102 +58,3 @@ cpu: cpu@01c20054 { reg = <0x01c20054 0x4>; clocks = <&osc32k>, <&osc24M>, <&pll1>; }; - - - -Gate clock outputs - -The "allwinner,sun4i-*-gates-clk" clocks provide several gatable outputs; -their corresponding offsets as present on sun4i are listed below. Note that -some of these gates are not present on sun5i. - - * AXI gates ("allwinner,sun4i-axi-gates-clk") - - DRAM 0 - - * AHB gates ("allwinner,sun4i-ahb-gates-clk") - - USB0 0 - EHCI0 1 - OHCI0 2* - EHCI1 3 - OHCI1 4* - SS 5 - DMA 6 - BIST 7 - MMC0 8 - MMC1 9 - MMC2 10 - MMC3 11 - MS 12** - NAND 13 - SDRAM 14 - - ACE 16 - EMAC 17 - TS 18 - - SPI0 20 - SPI1 21 - SPI2 22 - SPI3 23 - PATA 24 - SATA 25** - GPS 26* - - VE 32 - TVD 33 - TVE0 34 - TVE1 35 - LCD0 36 - LCD1 37 - - CSI0 40 - CSI1 41 - - HDMI 43 - DE_BE0 44 - DE_BE1 45 - DE_FE0 46 - DE_FE1 47 - - MP 50 - - MALI400 52 - - * APB0 gates ("allwinner,sun4i-apb0-gates-clk") - - CODEC 0 - SPDIF 1* - AC97 2 - IIS 3 - - PIO 5 - IR0 6 - IR1 7 - - KEYPAD 10 - - * APB1 gates ("allwinner,sun4i-apb1-gates-clk") - - I2C0 0 - I2C1 1 - I2C2 2 - - CAN 4 - SCR 5 - PS20 6 - PS21 7 - - UART0 16 - UART1 17 - UART2 18 - UART3 19 - UART4 20 - UART5 21 - UART6 22 - UART7 23 - -Notation: - [*]: The datasheet didn't mention these, but they are present on AW code - [**]: The datasheet had this marked as "NC" but they are used on AW code diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt new file mode 100644 index 0000000..6a03475 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt @@ -0,0 +1,93 @@ +Gate clock outputs +------------------ + + * AXI gates ("allwinner,sun4i-axi-gates-clk") + + DRAM 0 + + * AHB gates ("allwinner,sun4i-ahb-gates-clk") + + USB0 0 + EHCI0 1 + OHCI0 2* + EHCI1 3 + OHCI1 4* + SS 5 + DMA 6 + BIST 7 + MMC0 8 + MMC1 9 + MMC2 10 + MMC3 11 + MS 12** + NAND 13 + SDRAM 14 + + ACE 16 + EMAC 17 + TS 18 + + SPI0 20 + SPI1 21 + SPI2 22 + SPI3 23 + PATA 24 + SATA 25** + GPS 26* + + VE 32 + TVD 33 + TVE0 34 + TVE1 35 + LCD0 36 + LCD1 37 + + CSI0 40 + CSI1 41 + + HDMI 43 + DE_BE0 44 + DE_BE1 45 + DE_FE1 46 + DE_FE1 47 + + MP 50 + + MALI400 52 + + * APB0 gates ("allwinner,sun4i-apb0-gates-clk") + + CODEC 0 + SPDIF 1* + AC97 2 + IIS 3 + + PIO 5 + IR0 6 + IR1 7 + + KEYPAD 10 + + * APB1 gates ("allwinner,sun4i-apb1-gates-clk") + + I2C0 0 + I2C1 1 + I2C2 2 + + CAN 4 + SCR 5 + PS20 6 + PS21 7 + + UART0 16 + UART1 17 + UART2 18 + UART3 19 + UART4 20 + UART5 21 + UART6 22 + UART7 23 + +Notation: + [*]: The datasheet didn't mention these, but they are present on AW code + [**]: The datasheet had this marked as "NC" but they are used on AW code diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt new file mode 100644 index 0000000..006b6df --- /dev/null +++ b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt @@ -0,0 +1,58 @@ +Gate clock outputs +------------------ + + * AXI gates ("allwinner,sun4i-axi-gates-clk") + + DRAM 0 + + * AHB gates ("allwinner,sun5i-a13-ahb-gates-clk") + + USBOTG 0 + EHCI 1 + OHCI 2 + + SS 5 + DMA 6 + BIST 7 + MMC0 8 + MMC1 9 + MMC2 10 + + NAND 13 + SDRAM 14 + + SPI0 20 + SPI1 21 + SPI2 22 + + STIMER 28 + + VE 32 + + LCD 36 + + CSI 40 + + DE_BE 44 + + DE_FE 46 + + IEP 51 + MALI400 52 + + * APB0 gates ("allwinner,sun5i-a13-apb0-gates-clk") + + CODEC 0 + + PIO 5 + IR 6 + + * APB1 gates ("allwinner,sun5i-a13-apb1-gates-clk") + + I2C0 0 + I2C1 1 + I2C2 2 + + UART1 17 + + UART3 19 -- cgit v1.1 From af65d4592de0710a25abe2a7afe29db52a3a6282 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 10 Apr 2013 22:21:49 +0200 Subject: ARM: sunxi: Update datasheet documentation We have access to more documentation now, especially the user manuals, so add the links to them, and do so minor comestic changes while we're at it. Signed-off-by: Maxime Ripard --- Documentation/arm/sunxi/README | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README index 87a1e8f..d9a372d 100644 --- a/Documentation/arm/sunxi/README +++ b/Documentation/arm/sunxi/README @@ -3,17 +3,22 @@ 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 - - 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 -- cgit v1.1 From ec3805e6199649db2a462045a38eb1050c6151aa Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Wed, 10 Apr 2013 22:39:54 +0200 Subject: ARM: sunxi: irqchip: Update the documentation A10 and A13 have a different set of available interrupt sources, reflect this in the documentation. Signed-off-by: Maxime Ripard --- .../interrupt-controller/allwinner,sun4i-ic.txt | 87 +-------------------- .../interrupt-controller/sunxi/sun4i-a10.txt | 89 ++++++++++++++++++++++ .../interrupt-controller/sunxi/sun5i-a13.txt | 55 +++++++++++++ 3 files changed, 146 insertions(+), 85 deletions(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt index e7f4dc1..57edb30 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/.txt Example: 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 0000000..76b98c8 --- /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 0000000..2ec3b5c --- /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 -- cgit v1.1 From 54aa3b99982a6e5f12b52b394244b5086a330a34 Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu Date: Sat, 6 Apr 2013 09:52:05 -0700 Subject: perf: Power7 Update testing ABI to list CPI-stack events Following patch added several Power7 events into /sys/devices/cpu/events. Document those events in the testing ABI. https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-April/105167.html Signed-off-by: Sukadev Bhattiprolu Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-dev@ozlabs.org Link: http://lkml.kernel.org/r/20130406170623.GA900@us.ibm.com Signed-off-by: Arnaldo Carvalho de Melo --- .../testing/sysfs-bus-event_source-devices-events | 32 ++++++++++++++++++---- 1 file changed, 27 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events index 0adeb52..8b25ffb 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 -- cgit v1.1 From fd851780e61ac36e8d59fe87cca01a2e673930ff Mon Sep 17 00:00:00 2001 From: Michael Ellerman Date: Fri, 10 May 2013 17:33:00 +0200 Subject: perf: Expand definition of sysfs format attribute Make it explicit that the format attributes may define overlapping bit ranges. Unfortunately this was left unspecified originally, and all the examples show non-overlapping ranges. I don't believe this is an ABI change, as we are defining something that was previously undefined, but others may disagree. The POWER8 PMU would like to define overlapping ranges, as bit ranges in the event code have different meanings for certain events. It will also allow us to define an overarching "event" field, that encompasses all others. As far as I can see perf is comfortable with this change, however I am not sure if there are any other users of the interface. Signed-off-by: Michael Ellerman Acked-by: Peter Zijlstra Cc: Corey Ashford Cc: Frederic Weisbecker Cc: Jiri Olsa Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1368199980-20283-1-git-send-email-jolsa@redhat.com Signed-off-by: Jiri Olsa Signed-off-by: Arnaldo Carvalho de Melo --- Documentation/ABI/testing/sysfs-bus-event_source-devices-format | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format index 079afc7..77f47ff 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. -- cgit v1.1 From ed69bdd8fd9b2db68b915ce5f60fc51d4744a9b1 Mon Sep 17 00:00:00 2001 From: Lorenzo Pieralisi Date: Fri, 13 Jul 2012 15:55:52 +0100 Subject: drivers: bus: add ARM CCI support On ARM multi-cluster systems coherency between cores running on different clusters is managed by the cache-coherent interconnect (CCI). It allows broadcasting of TLB invalidates and memory barriers and it guarantees cache coherency at system level through snooping of slave interfaces connected to it. This patch enables the basic infrastructure required in Linux to handle and programme the CCI component. Non-local variables used by the CCI management functions called by power down function calls after disabling the cache must be flushed out to main memory in advance, otherwise incoherency of those values may occur if they are sitting in the cache of some other CPU when power down functions execute. Driver code ensures that relevant data structures are flushed from inner and outer caches after the driver probe is completed. CCI slave port resources are linked to set of CPUs through bus masters phandle properties that link the interface resources to masters node in the device tree. Documentation describing the CCI DT bindings is provided with the patch. Signed-off-by: Lorenzo Pieralisi Signed-off-by: Nicolas Pitre --- Documentation/devicetree/bindings/arm/cci.txt | 172 ++++++++++++++++++++++++++ 1 file changed, 172 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/cci.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt new file mode 100644 index 0000000..92d36e2 --- /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: + Definition: must be set to + "arm,cci-400" + + - reg + Usage: required + Value type: + Definition: A standard property. Specifies base physical + address of CCI control registers common to all + interfaces. + + - ranges: + Usage: required + Value type: + 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: + Definition: must be set to + "arm,cci-400-ctrl-if" + + - interface-type: + Usage: required + Value type: + Definition: must be set to one of {"ace", "ace-lite"} + depending on the interface type the node + represents. + + - reg: + Usage: required + Value type: + 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: + 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}; -- cgit v1.1 From 1e904e1bf6f1285cc2dd5696c44b7cf78cda643f Mon Sep 17 00:00:00 2001 From: Nicolas Pitre Date: Wed, 2 May 2012 20:56:52 -0400 Subject: ARM: vexpress: introduce DCSCB support This adds basic CPU and cluster reset controls on RTSM for the A15x4-A7x4 model configuration using the Dual Cluster System Configuration Block (DCSCB). The cache coherency interconnect (CCI) is not handled yet. Signed-off-by: Nicolas Pitre Reviewed-by: Santosh Shilimkar Acked-by: Pawel Moll --- Documentation/devicetree/bindings/arm/rtsm-dcscb.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/rtsm-dcscb.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt b/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt new file mode 100644 index 0000000..3b8fbf3 --- /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>; + }; -- cgit v1.1 From 518d4709f1961539a64f5d5f9b5b842824c0d971 Mon Sep 17 00:00:00 2001 From: Tony Prisk Date: Mon, 13 May 2013 20:20:59 +1200 Subject: clk: vt8500: Add support for clocks on the WM8850 SoCs The WM8850 has a different PLL clock to the previous versions. This patch adds support for the WM8850-style PLL clocks. Signed-off-by: Tony Prisk Signed-off-by: Mike Turquette --- Documentation/devicetree/bindings/clock/vt8500.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/vt8500.txt b/Documentation/devicetree/bindings/clock/vt8500.txt index a880c70..91d71cc 100644 --- a/Documentation/devicetree/bindings/clock/vt8500.txt +++ b/Documentation/devicetree/bindings/clock/vt8500.txt @@ -8,6 +8,8 @@ Required properties: - compatible : shall be one of the following: "via,vt8500-pll-clock" - for a VT8500/WM8505 PLL clock "wm,wm8650-pll-clock" - for a WM8650 PLL clock + "wm,wm8750-pll-clock" - for a WM8750 PLL clock + "wm,wm8850-pll-clock" - for a WM8850 PLL clock "via,vt8500-device-clock" - for a VT/WM device clock Required properties for PLL clocks: -- cgit v1.1 From e8b58b49130f40c29bb95cd5d9b36955ff703822 Mon Sep 17 00:00:00 2001 From: Dongjin Kim Date: Wed, 22 May 2013 05:20:09 +0900 Subject: usb: misc: usb3503: Adding device tree entry 'disabled-ports' This patch is to add a property 'disabled-ports' representing the unused port of USB3503. USB3503 can support up to 3 USB host port and each ports can be controlled to be enabled or disabled. Do not describe this property if all ports must be enabled. You can represent the ports to disable in the device tree. usb3503@08{ ... disabled-ports = <2 3>; ... }; Signed-off-by: Dongjin Kim Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/usb3503.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt index 6813a71..8c5be48 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>; -- cgit v1.1 From 76723bca2802eb80990a5fefa179662e2e561d66 Mon Sep 17 00:00:00 2001 From: Sebastian Hesselbarth Date: Wed, 29 May 2013 09:32:48 +0000 Subject: net: mv643xx_eth: add DT parsing support This adds device tree parsing support for the shared driver of mv643xx_eth. As the bindings are slightly different from current PPC bindings new binding documentation is also added. Following PPC-style device setup, the shared driver now also adds port platform_devices and sets up port platform_data. Signed-off-by: Sebastian Hesselbarth Signed-off-by: David S. Miller --- .../devicetree/bindings/net/marvell-orion-net.txt | 85 ++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/marvell-orion-net.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/marvell-orion-net.txt b/Documentation/devicetree/bindings/net/marvell-orion-net.txt new file mode 100644 index 0000000..a73b79f --- /dev/null +++ b/Documentation/devicetree/bindings/net/marvell-orion-net.txt @@ -0,0 +1,85 @@ +Marvell Orion/Discovery ethernet controller +============================================= + +The Marvell Discovery ethernet controller can be found on Marvell Orion SoCs +(Kirkwood, Dove, Orion5x, and Discovery Innovation) and as part of Marvell +Discovery system controller chips (mv64[345]60). + +The Discovery ethernet controller is described with two levels of nodes. The +first level describes the ethernet controller itself and the second level +describes up to 3 ethernet port nodes within that controller. The reason for +the multiple levels is that the port registers are interleaved within a single +set of controller registers. Each port node describes port-specific properties. + +Note: The above separation is only true for Discovery system controllers. +For Orion SoCs we stick to the separation, although there each controller has +only one port associated. Multiple ports are implemented as multiple single-port +controllers. As Kirkwood has some issues with proper initialization after reset, +an extra compatible string is added for it. + +* Ethernet controller node + +Required controller properties: + - #address-cells: shall be 1. + - #size-cells: shall be 0. + - compatible: shall be one of "marvell,orion-eth", "marvell,kirkwood-eth". + - reg: address and length of the controller registers. + +Optional controller properties: + - clocks: phandle reference to the controller clock. + - marvell,tx-checksum-limit: max tx packet size for hardware checksum. + +* Ethernet port node + +Required port properties: + - device_type: shall be "network". + - compatible: shall be one of "marvell,orion-eth-port", + "marvell,kirkwood-eth-port". + - reg: port number relative to ethernet controller, shall be 0, 1, or 2. + - interrupts: port interrupt. + - local-mac-address: 6 bytes MAC address. + +Optional port properties: + - marvell,tx-queue-size: size of the transmit ring buffer. + - marvell,tx-sram-addr: address of transmit descriptor buffer located in SRAM. + - marvell,tx-sram-size: size of transmit descriptor buffer located in SRAM. + - marvell,rx-queue-size: size of the receive ring buffer. + - marvell,rx-sram-addr: address of receive descriptor buffer located in SRAM. + - marvell,rx-sram-size: size of receive descriptor buffer located in SRAM. + +and + + - phy-handle: phandle reference to ethernet PHY. + +or + + - speed: port speed if no PHY connected. + - duplex: port mode if no PHY connected. + +* Node example: + +mdio-bus { + ... + ethphy: ethernet-phy@8 { + device_type = "ethernet-phy"; + ... + }; +}; + +eth: ethernet-controller@72000 { + compatible = "marvell,orion-eth"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x72000 0x2000>; + clocks = <&gate_clk 2>; + marvell,tx-checksum-limit = <1600>; + + ethernet@0 { + device_type = "network"; + compatible = "marvell,orion-eth-port"; + reg = <0>; + interrupts = <29>; + phy-handle = <ðphy>; + local-mac-address = [00 00 00 00 00 00]; + }; +}; -- cgit v1.1 From 757885e94a22bcc82beb9b1445c95218cb20ceab Mon Sep 17 00:00:00 2001 From: Jacob Shin Date: Thu, 30 May 2013 14:09:19 -0500 Subject: x86, microcode, amd: Early microcode patch loading support for AMD Add early microcode patch loading support for AMD. Signed-off-by: Jacob Shin Link: http://lkml.kernel.org/r/1369940959-2077-5-git-send-email-jacob.shin@amd.com Signed-off-by: H. Peter Anvin Cc: Fenghua Yu --- Documentation/x86/early-microcode.txt | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt index 4aaf0df..d62bea6 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 -- cgit v1.1 From 63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski Date: Mon, 13 May 2013 23:58:46 +0000 Subject: uvesafb: Clean up MTRR code The old code allowed very strange memory types. Now it works like all the other video drivers: ioremap_wc is used unconditionally, and MTRRs are set if PAT is unavailable (unless MTRR is disabled by a module parameter). UC, WB, and WT support is gone. If there are MTRR conflicts that prevent addition of a WC MTRR, adding a non-conflicting MTRR is pointless; it's better to just turn off MTRR support entirely. As an added bonus, any MTRR added is freed on unload. Reviewed-by: Daniel Vetter Signed-off-by: Andy Lutomirski Signed-off-by: Dave Airlie --- Documentation/fb/uvesafb.txt | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt index eefdd91..f6362d8 100644 --- a/Documentation/fb/uvesafb.txt +++ b/Documentation/fb/uvesafb.txt @@ -81,17 +81,11 @@ pmipal Use the protected mode interface for palette changes. mtrr:n Setup memory type range registers for the framebuffer where n: - 0 - disabled (equivalent to nomtrr) (default) - 1 - uncachable - 2 - write-back - 3 - write-combining - 4 - write-through - - If you see the following in dmesg, choose the type that matches - the old one. In this example, use "mtrr:2". -... -mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining -... + 0 - disabled (equivalent to nomtrr) + 3 - write-combining (default) + + Values other than 0 and 3 will result in a warning and will be + treated just like 3. nomtrr Do not use memory type range registers. -- cgit v1.1 From 5a5056cccfb0479f52a0464a6b371b441c84aa0c Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 8 Apr 2013 10:50:11 +0200 Subject: ARM: u300: device tree support for the timer This adds device tree support for the U300 timer, by making the memory base offset and IRQ dynamically assigned, then optionally looking them up from the device tree. Since the timer needs to be registered before any platform devices are created, we will go into the device tree and look up the "/timer@c0014000" node and read our base address and IRQ from there. Signed-off-by: Linus Walleij --- .../bindings/timer/stericsson-u300-apptimer.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt (limited to 'Documentation') 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 0000000..9499bc8 --- /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>; +}; -- cgit v1.1 From 351c2163f918e2a4218e0206f854dbec7799fda8 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Wed, 10 Apr 2013 10:49:31 +0200 Subject: pinctrl: coh901: add device tree support This makes it possible to probe the COH901 pinctrl driver from the device tree, and assigned the device tree node in the gpio_chip so we can look up cross-references from the device tree. Start grabbing the per-port (bank) IRQs by index instead of by name so we don't have to look up the IRQs by name going forward. Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt (limited to 'Documentation') 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 0000000..fd665b4 --- /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. -- cgit v1.1 From 978577ea21fb05c12511c25b71e493859e36892f Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 8 Apr 2013 11:38:50 +0200 Subject: ARM: u300: basic device tree support This register the most basic peripherals and makes the U300 boot to prompt from a device tree. Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/arm/ste-u300.txt | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/ste-u300.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/ste-u300.txt b/Documentation/devicetree/bindings/arm/ste-u300.txt new file mode 100644 index 0000000..222dca5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/ste-u300.txt @@ -0,0 +1,9 @@ +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"; -- cgit v1.1 From 8c58d891576c726bb8217842e955827ba8bb405a Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 11 Apr 2013 14:59:47 +0200 Subject: i2c: stu300: device tree support This adds device tree support for the ST DDC I2C driver known as "stu300" in the kernel tree. Reviewed-by: Wolfram Sang Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt (limited to 'Documentation') 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 0000000..bd81a48 --- /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 : + -- cgit v1.1 From c83c199199b9d68c56b5cc53b01b8f513f91b93a Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 19 Apr 2013 12:56:36 +0200 Subject: watchdog: coh901327: devicetree support This adds support for probing the COH 901 327 watchdog from the device tree and also adds associated bindings. Acked-by: Wim Van Sebroeck Reviewed-by: Guenter Roeck Signed-off-by: Linus Walleij --- .../bindings/watchdog/stericsson-coh901327.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt new file mode 100644 index 0000000..8ffb88e --- /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>; +}; -- cgit v1.1 From 7d1818fa6683daee6f6bf6f420ac850e5fe4e544 Mon Sep 17 00:00:00 2001 From: Daniel Tang Date: Fri, 31 May 2013 19:27:33 +1000 Subject: clk: Add TI-Nspire clock drivers This patch adds a basic clock driver for the TI-Nspire calculator series. Changes from v1: * Removed filename in header comment * Removed unnecessary #undef EXTRACT statement Signed-off-by: Daniel Tang Signed-off-by: Mike Turquette [mturquette@linaro.org: fixed $SUBJECT and changelog max width] --- .../devicetree/bindings/clock/nspire-clock.txt | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/nspire-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/nspire-clock.txt b/Documentation/devicetree/bindings/clock/nspire-clock.txt new file mode 100644 index 0000000..7c3bc8b --- /dev/null +++ b/Documentation/devicetree/bindings/clock/nspire-clock.txt @@ -0,0 +1,24 @@ +TI-NSPIRE Clocks + +Required properties: +- compatible: Valid compatible properties include: + "lsi,nspire-cx-ahb-divider" for the AHB divider in the CX model + "lsi,nspire-classic-ahb-divider" for the AHB divider in the older model + "lsi,nspire-cx-clock" for the base clock in the CX model + "lsi,nspire-classic-clock" for the base clock in the older model + +- reg: Physical base address of the controller and length of memory mapped + region. + +Optional: +- clocks: For the "nspire-*-ahb-divider" compatible clocks, this is the parent + clock where it divides the rate from. + +Example: + +ahb_clk { + #clock-cells = <0>; + compatible = "lsi,nspire-cx-clock"; + reg = <0x900B0000 0x4>; + clocks = <&base_clk>; +}; -- cgit v1.1 From 24b92375dc4ec8a15262e8aaaab60b7404d4b1e7 Mon Sep 17 00:00:00 2001 From: Michael Neuling Date: Sun, 26 May 2013 18:09:38 +0000 Subject: powerpc/tm: Update cause codes documentation Signed-off-by: Michael Neuling Cc: # 3.9 only Signed-off-by: Benjamin Herrenschmidt --- Documentation/powerpc/transactional_memory.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.txt index c907be4..84e04a0 100644 --- a/Documentation/powerpc/transactional_memory.txt +++ b/Documentation/powerpc/transactional_memory.txt @@ -155,6 +155,7 @@ These are defined in , and distinguish different reasons why the kernel aborted a transaction: TM_CAUSE_RESCHED Thread was rescheduled. + TM_CAUSE_TLBI Software TLB invalide. TM_CAUSE_FAC_UNAV FP/VEC/VSX unavailable trap. TM_CAUSE_SYSCALL Currently unused; future syscalls that must abort transactions for consistency will use this. -- cgit v1.1 From 6ce6c629fd8254b3177650de99699682ff7f6707 Mon Sep 17 00:00:00 2001 From: Michael Neuling Date: Sun, 26 May 2013 18:09:39 +0000 Subject: powerpc/tm: Abort on emulation and alignment faults If we are emulating an instruction inside an active user transaction that touches memory, the kernel can't emulate it as it operates in transactional suspend context. We need to abort these transactions and send them back to userspace for the hardware to rollback. We can service these if the user transaction is in suspend mode, since the kernel will operate in the same suspend context. This adds a check to all alignment faults and to specific instruction emulations (only string instructions for now). If the user process is in an active (non-suspended) transaction, we abort the transaction go back to userspace allowing the HW to roll back the transaction and tell the user of the failure. This also adds new tm abort cause codes to report the reason of the persistent error to the user. Crappy test case here http://neuling.org/devel/junkcode/aligntm.c Signed-off-by: Michael Neuling Cc: # v3.9 Signed-off-by: Benjamin Herrenschmidt --- Documentation/powerpc/transactional_memory.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.txt index 84e04a0..c54bf31 100644 --- a/Documentation/powerpc/transactional_memory.txt +++ b/Documentation/powerpc/transactional_memory.txt @@ -161,9 +161,12 @@ kernel aborted a transaction: transactions for consistency will use this. TM_CAUSE_SIGNAL Signal delivered. TM_CAUSE_MISC Currently unused. + TM_CAUSE_ALIGNMENT Alignment fault. + TM_CAUSE_EMULATE Emulation that touched memory. -These can be checked by the user program's abort handler as TEXASR[0:7]. - +These can be checked by the user program's abort handler as TEXASR[0:7]. If +bit 7 is set, it indicates that the error is consider persistent. For example +a TM_CAUSE_ALIGNMENT will be persistent while a TM_CAUSE_RESCHED will not.q GDB === -- cgit v1.1 From 2b3f8e87cf99a33fb6faf5026d7147748bbd77b6 Mon Sep 17 00:00:00 2001 From: Michael Neuling Date: Sun, 26 May 2013 18:09:41 +0000 Subject: powerpc/tm: Fix userspace stack corruption on signal delivery for active transactions When in an active transaction that takes a signal, we need to be careful with the stack. It's possible that the stack has moved back up after the tbegin. The obvious case here is when the tbegin is called inside a function that returns before a tend. In this case, the stack is part of the checkpointed transactional memory state. If we write over this non transactionally or in suspend, we are in trouble because if we get a tm abort, the program counter and stack pointer will be back at the tbegin but our in memory stack won't be valid anymore. To avoid this, when taking a signal in an active transaction, we need to use the stack pointer from the checkpointed state, rather than the speculated state. This ensures that the signal context (written tm suspended) will be written below the stack required for the rollback. The transaction is aborted becuase of the treclaim, so any memory written between the tbegin and the signal will be rolled back anyway. For signals taken in non-TM or suspended mode, we use the normal/non-checkpointed stack pointer. Tested with 64 and 32 bit signals Signed-off-by: Michael Neuling Cc: # v3.9 Signed-off-by: Benjamin Herrenschmidt --- Documentation/powerpc/transactional_memory.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.txt index c54bf31..dc23e58 100644 --- a/Documentation/powerpc/transactional_memory.txt +++ b/Documentation/powerpc/transactional_memory.txt @@ -147,6 +147,25 @@ Example signal handler: fix_the_problem(ucp->dar); } +When in an active transaction that takes a signal, we need to be careful with +the stack. It's possible that the stack has moved back up after the tbegin. +The obvious case here is when the tbegin is called inside a function that +returns before a tend. In this case, the stack is part of the checkpointed +transactional memory state. If we write over this non transactionally or in +suspend, we are in trouble because if we get a tm abort, the program counter and +stack pointer will be back at the tbegin but our in memory stack won't be valid +anymore. + +To avoid this, when taking a signal in an active transaction, we need to use +the stack pointer from the checkpointed state, rather than the speculated +state. This ensures that the signal context (written tm suspended) will be +written below the stack required for the rollback. The transaction is aborted +becuase of the treclaim, so any memory written between the tbegin and the +signal will be rolled back anyway. + +For signals taken in non-TM or suspended mode, we use the +normal/non-checkpointed stack pointer. + Failure cause codes used by kernel ================================== -- cgit v1.1 From 492205050d77bcc4f85f6dc0da6b6fdbca1d6ff7 Mon Sep 17 00:00:00 2001 From: Stefan Roese Date: Thu, 30 May 2013 03:49:20 +0000 Subject: net: Add EMAC ethernet driver found on Allwinner A10 SoC's The Allwinner A10 has an ethernet controller that seem to be developped internally by them. The exact feature set of this controller is unknown, since there is no public documentation for this IP, and this driver is mostly the one published by Allwinner that has been heavily cleaned up. Signed-off-by: Stefan Roese Signed-off-by: Maxime Ripard Tested-by: Richard Genoud Signed-off-by: David S. Miller --- .../bindings/net/allwinner,sun4i-emac.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt new file mode 100644 index 0000000..b90bfcd --- /dev/null +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt @@ -0,0 +1,22 @@ +* Allwinner EMAC ethernet controller + +Required properties: +- compatible: should be "allwinner,sun4i-emac". +- reg: address and length of the register set for the device. +- interrupts: interrupt for the device +- phy: A phandle to a phy node defining the PHY address (as the reg + property, a single integer). +- clocks: A phandle to the reference clock for this device + +Optional properties: +- (local-)mac-address: mac address to be used by this driver + +Example: + +emac: ethernet@01c0b000 { + compatible = "allwinner,sun4i-emac"; + reg = <0x01c0b000 0x1000>; + interrupts = <55>; + clocks = <&ahb_gates 17>; + phy = <&phy0>; +}; -- cgit v1.1 From 4bdcb1dd9feb03608e12cfa46aba385035af8ea5 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Thu, 30 May 2013 03:49:21 +0000 Subject: net: Add MDIO bus driver for the Allwinner EMAC This patch adds a separate driver for the MDIO interface of the Allwinner ethernet controllers. Signed-off-by: Maxime Ripard Tested-by: Richard Genoud Signed-off-by: David S. Miller --- .../bindings/net/allwinner,sun4i-mdio.txt | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt new file mode 100644 index 0000000..00b9f9a --- /dev/null +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt @@ -0,0 +1,26 @@ +* Allwinner A10 MDIO Ethernet Controller interface + +Required properties: +- compatible: should be "allwinner,sun4i-mdio". +- reg: address and length of the register set for the device. + +Optional properties: +- phy-supply: phandle to a regulator if the PHY needs one + +Example at the SoC level: +mdio@01c0b080 { + compatible = "allwinner,sun4i-mdio"; + reg = <0x01c0b080 0x14>; + #address-cells = <1>; + #size-cells = <0>; +}; + +And at the board level: + +mdio@01c0b080 { + phy-supply = <®_emac_3v3>; + + phy0: ethernet-phy@0 { + reg = <0>; + }; +}; -- cgit v1.1 From 301d2d87cb4f826a38548f692e1b3c8c23590a9f Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Wed, 13 Feb 2013 15:21:21 +0100 Subject: Documentation/devicetree: add a small note on PCI Throw in a file with references to the IEEE binding documents. Acked-by: Arnd Bergmann Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pci/pci.txt | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/pci.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt new file mode 100644 index 0000000..41aeed3 --- /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 -- cgit v1.1 From 2d178a4abb33916fb8e1dea540921acdafe53875 Mon Sep 17 00:00:00 2001 From: Steffen Trumtrar Date: Mon, 27 May 2013 12:33:34 +0000 Subject: video: of: display_timing: add doubleclk flag Signed-off-by: Steffen Trumtrar Signed-off-by: Dave Airlie --- Documentation/devicetree/bindings/video/display-timing.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt index 1500385..e1d4a0b 100644 --- a/Documentation/devicetree/bindings/video/display-timing.txt +++ b/Documentation/devicetree/bindings/video/display-timing.txt @@ -34,6 +34,7 @@ optional properties: - ignored = ignored - interlaced (bool): boolean to enable interlaced mode - doublescan (bool): boolean to enable doublescan mode + - doubleclk (bool): boolean to enable doubleclock mode All the optional properties that are not bool follow the following logic: <1>: high active -- cgit v1.1 From c7da08677d73e887380e64c865b99536027191aa Mon Sep 17 00:00:00 2001 From: David Herrmann Date: Sun, 5 May 2013 23:13:04 +0200 Subject: HID: wiimote: add sysfs extension/device-type attrs Two new attributes, "extension" and "devtype" now allow user-space to read the extension type and device type. As device detection is asynchronous, we send a CHANGED event after it is done. This also allows user-space to wait for a device to settle before opening its input event devices. The "extension" device is compatible with the old "extension" sysfs field (which was registered by the static extension support code). Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina --- Documentation/ABI/testing/sysfs-driver-hid-wiimote | 24 +++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-hid-wiimote b/Documentation/ABI/testing/sysfs-driver-hid-wiimote index 3d98009..e8f6b16 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-wiimote +++ b/Documentation/ABI/testing/sysfs-driver-hid-wiimote @@ -12,7 +12,7 @@ Description: Make it possible to set/get current led state. Reading from it What: /sys/bus/hid/drivers/wiimote//extension Date: August 2011 KernelVersion: 3.2 -Contact: David Herrmann +Contact: David Herrmann Description: This file contains the currently connected and initialized extensions. It can be one of: none, motionp, nunchuck, classic, motionp+nunchuck, motionp+classic @@ -20,3 +20,25 @@ Description: This file contains the currently connected and initialized the official Nintendo Nunchuck extension and classic is the Nintendo Classic Controller extension. The motionp extension can be combined with the other two. + Starting with kernel-version 3.11 Motion Plus hotplugging is + supported and if detected, it's no longer reported as static + extension. You will get uevent notifications for the motion-plus + device then. + +What: /sys/bus/hid/drivers/wiimote//devtype +Date: May 2013 +KernelVersion: 3.11 +Contact: David Herrmann +Description: While a device is initialized by the wiimote driver, we perform + a device detection and signal a "change" uevent after it is + done. This file shows the detected device type. "pending" means + that the detection is still ongoing, "unknown" means, that the + device couldn't be detected or loaded. "generic" means, that the + device couldn't be detected but supports basic Wii Remote + features and can be used. + Other strings for each device-type are available and may be + added if new device-specific detections are added. + Currently supported are: + gen10: First Wii Remote generation + gen20: Second Wii Remote Plus generation (builtin MP) + balanceboard: Wii Balance Board -- cgit v1.1 From 8b1fded7a352cbd926b314d3b42a538a848c15d8 Mon Sep 17 00:00:00 2001 From: David Herrmann Date: Sun, 5 May 2013 23:13:05 +0200 Subject: HID: wiimote: add "bboard_calib" attribute Balance-Boards provide 3 16bit calibration values for each of the 4 sensors. We provide these now as 192bit value via a new "bboard_calib" sysfs attribute. We also re-read the calibration data from the device whenever user-space attempts to read this file. On normal Nintendo boards, this always produces the same results, however, on some 3rd party devices these values change until the device is fully initialized. As I have currently no idea how long to wait until it's ready (sometimes takes up to 10s?) we provide a simple workaround for users by reading this file. If we, at some point, figure out how it works, we can implement it in the kernel and provide offline data via "bboard_calib". This won't break user-space then. Signed-off-by: David Herrmann Signed-off-by: Jiri Kosina --- Documentation/ABI/testing/sysfs-driver-hid-wiimote | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-hid-wiimote b/Documentation/ABI/testing/sysfs-driver-hid-wiimote index e8f6b16..ed5dd56 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-wiimote +++ b/Documentation/ABI/testing/sysfs-driver-hid-wiimote @@ -42,3 +42,18 @@ Description: While a device is initialized by the wiimote driver, we perform gen10: First Wii Remote generation gen20: Second Wii Remote Plus generation (builtin MP) balanceboard: Wii Balance Board + +What: /sys/bus/hid/drivers/wiimote//bboard_calib +Date: May 2013 +KernelVersion: 3.11 +Contact: David Herrmann +Description: This attribute is only provided if the device was detected as a + balance board. It provides a single line with 3 calibration + values for all 4 sensors. The values are separated by colons and + are each 2 bytes long (encoded as 4 digit hexadecimal value). + First, 0kg values for all 4 sensors are written, followed by the + 17kg values for all 4 sensors and last the 34kg values for all 4 + sensors. + Calibration data is already applied by the kernel to all input + values but may be used by user-space to perform other + transformations. -- cgit v1.1 From de9c739435b47e7d39e448b2cc4c8154cabc9e5a Mon Sep 17 00:00:00 2001 From: MyungJoo Ham Date: Tue, 5 Feb 2013 18:40:17 +0900 Subject: PM / devfreq: add comments and Documentation - Added missing ABI documents - Added comments to clarify the objectives of functions Signed-off-by: MyungJoo Ham Acked-by: Nishanth Menon Acked-by: Rajagopal Venkat --- Documentation/ABI/testing/sysfs-class-devfreq | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-devfreq b/Documentation/ABI/testing/sysfs-class-devfreq index 0ba6ea2..ee39aca 100644 --- a/Documentation/ABI/testing/sysfs-class-devfreq +++ b/Documentation/ABI/testing/sysfs-class-devfreq @@ -78,3 +78,23 @@ Contact: Nishanth Menon Description: The /sys/class/devfreq/.../available_governors shows currently available governors in the system. + +What: /sys/class/devfreq/.../min_freq +Date: January 2013 +Contact: MyungJoo Ham +Description: + The /sys/class/devfreq/.../min_freq shows and stores + the minimum frequency requested by users. It is 0 if + the user does not care. min_freq overrides the + frequency requested by governors. + +What: /sys/class/devfreq/.../max_freq +Date: January 2013 +Contact: MyungJoo Ham +Description: + The /sys/class/devfreq/.../max_freq shows and stores + the maximum frequency requested by users. It is 0 if + the user does not care. max_freq overrides the + frequency requested by governors and min_freq. + The max_freq overrides min_freq because max_freq may be + used to throttle devices to avoid overheating. -- cgit v1.1 From b996ac90f595dda271cbd858b136b45557fc1a57 Mon Sep 17 00:00:00 2001 From: Shane Huang Date: Mon, 3 Jun 2013 18:24:55 +0800 Subject: i2c-piix4: Add AMD CZ SMBus device ID To add AMD CZ SMBus controller device ID. [bhelgaas: drop pci_ids.h update] Signed-off-by: Shane Huang Signed-off-by: Bjorn Helgaas Reviewed-by: Tejun Heo Reviewed-by: Jean Delvare Cc: stable@vger.kernel.org --- Documentation/i2c/busses/i2c-piix4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index 1e6634f..a370b20 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 @@ -13,7 +13,7 @@ Supported adapters: * AMD SP5100 (SB700 derivative found on some server mainboards) Datasheet: Publicly available at the AMD website http://support.amd.com/us/Embedded_TechDocs/44413.pdf - * AMD Hudson-2 + * AMD Hudson-2, CZ Datasheet: Not publicly available * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge Datasheet: Publicly available at the SMSC website http://www.smsc.com -- cgit v1.1 From 45f0a85c8258741d11bda25c0a5669c06267204a Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Mon, 3 Jun 2013 21:49:52 +0200 Subject: PM / Runtime: Rework the "runtime idle" helper routine The "runtime idle" helper routine, rpm_idle(), currently ignores return values from .runtime_idle() callbacks executed by it. However, it turns out that many subsystems use pm_generic_runtime_idle() which checks the return value of the driver's callback and executes pm_runtime_suspend() for the device unless that value is not 0. If that logic is moved to rpm_idle() instead, pm_generic_runtime_idle() can be dropped and its users will not need any .runtime_idle() callbacks any more. Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle() routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and ata_port_runtime_idle(), respectively, as well as a few drivers' ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has been returned by the .runtime_idle() callback executed by it. To reduce overall code bloat, make the changes described above. Tested-by: Mika Westerberg Tested-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki Acked-by: Kevin Hilman Reviewed-by: Ulf Hansson Acked-by: Alan Stern --- Documentation/power/runtime_pm.txt | 5 ----- 1 file changed, 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 6c9f5d9..6c470c7 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -660,11 +660,6 @@ Subsystems may wish to conserve code space by using the set of generic power management callbacks provided by the PM core, defined in driver/base/power/generic_ops.c: - int pm_generic_runtime_idle(struct device *dev); - - invoke the ->runtime_idle() callback provided by the driver of this - device, if defined, and call pm_runtime_suspend() for this device if the - return value is 0 or the callback is not defined - int pm_generic_runtime_suspend(struct device *dev); - invoke the ->runtime_suspend() callback provided by the driver of this device and return its result, or return -EINVAL if not defined -- cgit v1.1 From 43d51af489126305dbacc1b8ebd1ce4797d277ea Mon Sep 17 00:00:00 2001 From: Alan Stern Date: Mon, 3 Jun 2013 21:49:59 +0200 Subject: PM / Runtime: Update .runtime_idle() callback documentation Runtime PM documentation needs to be updated after the previous change of the rpm_idle() behavior, so modify it as appropriate. [rjw: Subject and changelog] Signed-off-by: Alan Stern Signed-off-by: Rafael J. Wysocki --- Documentation/power/runtime_pm.txt | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 6c470c7..71d8fe4 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -144,8 +144,12 @@ The action performed by the idle callback is totally dependent on the subsystem (or driver) in question, but the expected and recommended action is to check if the device can be suspended (i.e. if all of the conditions necessary for suspending the device are satisfied) and to queue up a suspend request for the -device in that case. The value returned by this callback is ignored by the PM -core. +device in that case. If there is no idle callback, or if the callback returns +0, then the PM core will attempt to carry out a runtime suspend of the device; +in essence, it will call pm_runtime_suspend() directly. To prevent this (for +example, if the callback routine has started a delayed suspend), the routine +should return a non-zero value. Negative error return codes are ignored by the +PM core. The helper functions provided by the PM core, described in Section 4, guarantee that the following constraints are met with respect to runtime PM callbacks for @@ -301,9 +305,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: removing the device from device hierarchy int pm_runtime_idle(struct device *dev); - - execute the subsystem-level idle callback for the device; returns 0 on - success or error code on failure, where -EINPROGRESS means that - ->runtime_idle() is already being executed + - execute the subsystem-level idle callback for the device; returns an + error code on failure, where -EINPROGRESS means that ->runtime_idle() is + already being executed; if there is no callback or the callback returns 0 + then run pm_runtime_suspend(dev) and return its result int pm_runtime_suspend(struct device *dev); - execute the subsystem-level suspend callback for the device; returns 0 on -- cgit v1.1 From 8d7bda51888d14c07cbebacc5a10be776477bb63 Mon Sep 17 00:00:00 2001 From: Alexander Stein Date: Sun, 26 May 2013 20:06:50 +0200 Subject: w1: add family based automatic module loading This patch allows the 1-wire bus to autoload the corresponding module for each slave being attached. This works similar to bluetooth protocols. Signed-off-by: Alexander Stein Signed-off-by: Greg Kroah-Hartman --- Documentation/w1/w1.generic | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic index 212f4ac..a31c5a2 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. -- cgit v1.1 From 40b313608ad4ea655addd2ec6cdd106477ae8e15 Mon Sep 17 00:00:00 2001 From: Stephen Rothwell Date: Tue, 21 May 2013 13:49:35 +1000 Subject: Finally eradicate CONFIG_HOTPLUG Ever since commit 45f035ab9b8f ("CONFIG_HOTPLUG should be always on"), it has been basically impossible to build a kernel with CONFIG_HOTPLUG turned off. Remove all the remaining references to it. Cc: Russell King Cc: Doug Thompson Cc: Bjorn Helgaas Cc: Steven Whitehouse Cc: Arnd Bergmann Cc: Pavel Machek Cc: "Rafael J. Wysocki" Cc: Andrew Morton Signed-off-by: Stephen Rothwell Acked-by: Mauro Carvalho Chehab Acked-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-pci | 5 +---- Documentation/SubmitChecklist | 2 +- Documentation/cpu-hotplug.txt | 2 +- Documentation/hwmon/submitting-patches | 3 +-- Documentation/kbuild/kconfig.txt | 2 +- Documentation/usb/hotplug.txt | 6 +++--- 6 files changed, 8 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index 1ce5ae3..5210a51 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 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/SubmitChecklist b/Documentation/SubmitChecklist index dc0e332..2b7e32d 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/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index 9f40135..0efd1b9 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/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches index 843751c..4628646 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 3f429ed..213859e 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 ) and Enter. This will tell you that you can also use diff --git a/Documentation/usb/hotplug.txt b/Documentation/usb/hotplug.txt index 4c94571..6424b13 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. -- cgit v1.1 From 17c057a35f2672ba2e4d4f9bd7b5652ca0e11b92 Mon Sep 17 00:00:00 2001 From: Ben Minerds Date: Wed, 22 May 2013 18:42:07 +1000 Subject: Documentation: Updated broken link in HOWTO Updated broken "The Perfect Patch" link in HOWTO to a copy at kerneltrap.org. Signed-off-by: Ben Minerds Signed-off-by: Greg Kroah-Hartman --- Documentation/HOWTO | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/HOWTO b/Documentation/HOWTO index a9f288f..27faae3 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 -- cgit v1.1 From 20ff2fe60aa86683a68cd369c919ae6a98059c80 Mon Sep 17 00:00:00 2001 From: Huang Shijie Date: Thu, 30 May 2013 14:07:12 +0800 Subject: serial: imx: add support for DTE mode The uart works in the DCE mode by default, but sometime we need it works at the DTE mode. This patch adds the support for the DTE mode. Signed-off-by: Huang Shijie Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt index b462d0c..c662eb3 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; }; -- cgit v1.1 From e943f58ea84a80cc88dfceb6a5ed788d0ba24a1e Mon Sep 17 00:00:00 2001 From: Paul Bolle Date: Tue, 28 May 2013 09:29:36 +0200 Subject: stallion: final cleanup Support for the Stallion multiport serial drivers was removed in v3.1. Clean up their last references in the tree: mainly an outdated Kconfig entry and unneeded documentation. Signed-off-by: Paul Bolle Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman --- Documentation/serial/00-INDEX | 2 - Documentation/serial/stallion.txt | 392 -------------------------------------- 2 files changed, 394 deletions(-) delete mode 100644 Documentation/serial/stallion.txt (limited to 'Documentation') diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX index f7b0c7d..1f1b22f 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 4d798c0..0000000 --- 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 - 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?=[,[,][,]] - -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 " 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. - -- cgit v1.1 From 313bdb11e52a301aa7f6f8729a87ff0908785163 Mon Sep 17 00:00:00 2001 From: Lee Jones Date: Wed, 15 May 2013 10:51:48 +0100 Subject: usb: musb: ux500: add device tree probing support This patch will allow ux500-musb to be probed and configured solely from configuration found in Device Tree. Cc: Rob Herring Cc: linux-usb@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org Acked-by: Felipe Balbi Acked-by: Fabio Baltieri Signed-off-by: Lee Jones Signed-off-by: Linus Walleij --- .../devicetree/bindings/usb/ux500-usb.txt | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/ux500-usb.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/ux500-usb.txt b/Documentation/devicetree/bindings/usb/ux500-usb.txt new file mode 100644 index 0000000..330d6ec --- /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"; +}; -- cgit v1.1 From a7dacb68b35a193d9bdaabde1e4e98140d81a991 Mon Sep 17 00:00:00 2001 From: Lee Jones Date: Wed, 15 May 2013 10:51:59 +0100 Subject: dmaengine: ste_dma40: Allow memcpy channels to be configured from DT At this moment in time the memcpy channels which can be used by the D40 are fixed, as each supported platform in Mainline uses the same ones. However, platforms do exist which don't follow this convention, so these will need to be tailored. Fortunately, these platforms will be DT only, so this change has very little impact on platform data. Cc: Dan Williams Cc: Per Forlin Cc: Rabin Vincent Acked-by: Vinod Koul Acked-by: Arnd Bergmann Signed-off-by: Lee Jones Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/dma/ste-dma40.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt index 2679a87..aa272d8 100644 --- a/Documentation/devicetree/bindings/dma/ste-dma40.txt +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt @@ -6,6 +6,7 @@ Required properties: - 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 @@ -21,6 +22,7 @@ Example: interrupts = <0 25 0x4>; #dma-cells = <2>; + memcpy-channels = <56 57 58 59 60>; dma-channels = <8>; }; -- cgit v1.1 From 499c2bc3cc89dcbbf08aa526cd4a984b92a4d2a8 Mon Sep 17 00:00:00 2001 From: Lee Jones Date: Wed, 15 May 2013 10:52:02 +0100 Subject: dmaengine: ste_dma40: Fetch disabled channels from DT Some platforms have channels which are not available for normal use. This information is currently passed though platform data in internal BSP kernels. Once those platforms land, they'll need to configure them appropriately, so we may as well add the infrastructure. Cc: Dan Williams Cc: Per Forlin Cc: Rabin Vincent Acked-by: Vinod Koul Acked-by: Arnd Bergmann Signed-off-by: Lee Jones Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/dma/ste-dma40.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt index aa272d8..bea5b73 100644 --- a/Documentation/devicetree/bindings/dma/ste-dma40.txt +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt @@ -11,6 +11,7 @@ Required properties: 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: @@ -23,6 +24,7 @@ Example: #dma-cells = <2>; memcpy-channels = <56 57 58 59 60>; + disabled-channels = <12>; dma-channels = <8>; }; -- cgit v1.1 From 5070158804b5339c71809f5e673cea1cfacd804d Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Sat, 30 Mar 2013 16:25:15 +0530 Subject: cpufreq: rename index as driver_data in cpufreq_frequency_table The "index" field of struct cpufreq_frequency_table was never an index and isn't used at all by the cpufreq core. It only is useful for cpufreq drivers for their internal purposes. Many people nowadays blindly set it in ascending order with the assumption that the core will use it, which is a mistake. Rename it to "driver_data" as that's what its purpose is. All of its users are updated accordingly. [rjw: Changelog] Signed-off-by: Viresh Kumar Acked-by: Simon Horman Signed-off-by: Rafael J. Wysocki --- Documentation/cpu-freq/cpu-drivers.txt | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index a3585ea..19fa98e 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -186,7 +186,7 @@ As most cpufreq processors only allow for being set to a few specific frequencies, a "frequency table" with some functions might assist in some work of the processor driver. Such a "frequency table" consists of an array of struct cpufreq_frequency_table entries, with any value in -"index" you want to use, and the corresponding frequency in +"driver_data" you want to use, and the corresponding frequency in "frequency". At the end of the table, you need to add a cpufreq_frequency_table entry with frequency set to CPUFREQ_TABLE_END. And if you want to skip one entry in the table, set the frequency to @@ -214,10 +214,4 @@ int cpufreq_frequency_table_target(struct cpufreq_policy *policy, is the corresponding frequency table helper for the ->target stage. Just pass the values to this function, and the unsigned int index returns the number of the frequency table entry which contains -the frequency the CPU shall be set to. PLEASE NOTE: This is not the -"index" which is in this cpufreq_table_entry.index, but instead -cpufreq_table[index]. So, the new frequency is -cpufreq_table[index].frequency, and the value you stored into the -frequency table "index" field is -cpufreq_table[index].index. - +the frequency the CPU shall be set to. -- cgit v1.1 From fc4f314618923c2bef708a535f8483fa7f7dbad2 Mon Sep 17 00:00:00 2001 From: Daniel Tang Date: Thu, 30 May 2013 13:16:10 -0700 Subject: Input: add TI-Nspire keypad support This is a driver for the keypads found on the TI-Nspire series calculators. Signed-off-by: Daniel Tang Signed-off-by: Dmitry Torokhov --- .../devicetree/bindings/input/ti,nspire-keypad.txt | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/ti,nspire-keypad.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt b/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt new file mode 100644 index 0000000..513d94d --- /dev/null +++ b/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt @@ -0,0 +1,60 @@ +TI-NSPIRE Keypad + +Required properties: +- compatible: Compatible property value should be "ti,nspire-keypad". + +- reg: Physical base address of the peripheral and length of memory mapped + region. + +- interrupts: The interrupt number for the peripheral. + +- scan-interval: How often to scan in us. Based on a APB speed of 33MHz, the + maximum and minimum delay time is ~2000us and ~500us respectively + +- row-delay: How long to wait before scanning each row. + +- clocks: The clock this peripheral is attached to. + +- linux,keymap: The keymap to use + (see Documentation/devicetree/bindings/input/matrix-keymap.txt) + +Optional properties: +- active-low: Specify that the keypad is active low (i.e. logical low signifies + a key press). + +Example: + +input { + compatible = "ti,nspire-keypad"; + reg = <0x900E0000 0x1000>; + interrupts = <16>; + + scan-interval = <1000>; + row-delay = <200>; + + clocks = <&apb_pclk>; + + linux,keymap = < + 0x0000001c 0x0001001c 0x00040039 + 0x0005002c 0x00060015 0x0007000b + 0x0008000f 0x0100002d 0x01010011 + 0x0102002f 0x01030004 0x01040016 + 0x01050014 0x0106001f 0x01070002 + 0x010a006a 0x02000013 0x02010010 + 0x02020019 0x02030007 0x02040018 + 0x02050031 0x02060032 0x02070005 + 0x02080028 0x0209006c 0x03000026 + 0x03010025 0x03020024 0x0303000a + 0x03040017 0x03050023 0x03060022 + 0x03070008 0x03080035 0x03090069 + 0x04000021 0x04010012 0x04020020 + 0x0404002e 0x04050030 0x0406001e + 0x0407000d 0x04080037 0x04090067 + 0x05010038 0x0502000c 0x0503001b + 0x05040034 0x0505001a 0x05060006 + 0x05080027 0x0509000e 0x050a006f + 0x0600002b 0x0602004e 0x06030068 + 0x06040003 0x0605006d 0x06060009 + 0x06070001 0x0609000f 0x0708002a + 0x0709001d 0x070a0033 >; +}; -- cgit v1.1 From 1642e66201d7b35c383d8e832603c24a78670e62 Mon Sep 17 00:00:00 2001 From: Sujit Reddy Thumma Date: Tue, 14 May 2013 21:34:15 +0530 Subject: [SCSI] Documentation/devicetree: Add DT bindings for UFS host controller Compatible list is used in commit 03b1781 but is not documented. Add necessary device tree bindings to describe on-chip UFS host controllers. Signed-off-by: Sujit Reddy Thumma Signed-off-by: Santosh Y Signed-off-by: James Bottomley --- Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt new file mode 100644 index 0000000..20468b2 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -0,0 +1,16 @@ +* Universal Flash Storage (UFS) Host Controller + +UFSHC nodes are defined to describe on-chip UFS host controllers. +Each UFS controller instance should have its own node. + +Required properties: +- compatible : compatible list, contains "jedec,ufs-1.1" +- interrupts : +- reg : + +Example: + ufshc@0xfc598000 { + compatible = "jedec,ufs-1.1"; + reg = <0xfc598000 0x800>; + interrupts = <0 28 0>; + }; -- cgit v1.1 From 2d5dc3ba853344f39a41ae5bdb0a337b2ecaafa6 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk Date: Wed, 15 May 2013 10:39:34 -0400 Subject: xen-blkfront: Introduce a 'max' module parameter to alter the amount of indirect segments. The max module parameter (by default 32) is the maximum number of segments that the frontend will negotiate with the backend for indirect descriptors. Higher value means more potential throughput but more memory usage. The backend picks the minimum of the frontend and its default backend value. Signed-off-by: Konrad Rzeszutek Wilk --- Documentation/ABI/testing/sysfs-driver-xen-blkfront | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-xen-blkfront (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-xen-blkfront b/Documentation/ABI/testing/sysfs-driver-xen-blkfront new file mode 100644 index 0000000..c0a6cb7 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-xen-blkfront @@ -0,0 +1,10 @@ +What: /sys/module/xen_blkfront/parameters/max +Date: June 2013 +KernelVersion: 3.11 +Contact: Konrad Rzeszutek Wilk +Description: + Maximum number of segments that the frontend will negotiate + with the backend for indirect descriptors. The default value + is 32 - higher value means more potential throughput but more + memory usage. The backend picks the minimum of the frontend + and its default backend value. -- cgit v1.1 From 1d1996509cd3f90551f4460a68aaf3dc940a05e3 Mon Sep 17 00:00:00 2001 From: Konrad Rzeszutek Wilk Date: Tue, 4 Jun 2013 09:32:41 -0400 Subject: xen-blkback/sysfs: Move the parameters for the persistent grant features to a testing subdirectory (as this value should not be baked for the life-time) and also in an appropiate file. Also modified the introduction Linux version from 3.10 to 3.11. Signed-off-by: Konrad Rzeszutek Wilk --- Documentation/ABI/stable/sysfs-bus-xen-backend | 18 ------------------ Documentation/ABI/testing/sysfs-driver-xen-blkback | 17 +++++++++++++++++ 2 files changed, 17 insertions(+), 18 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-driver-xen-blkback (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-bus-xen-backend b/Documentation/ABI/stable/sysfs-bus-xen-backend index 947db11..3d5951c 100644 --- a/Documentation/ABI/stable/sysfs-bus-xen-backend +++ b/Documentation/ABI/stable/sysfs-bus-xen-backend @@ -73,21 +73,3 @@ KernelVersion: 3.0 Contact: Konrad Rzeszutek Wilk Description: Number of sectors written by the frontend. - -What: /sys/module/xen_blkback/parameters/max_buffer_pages -Date: March 2013 -KernelVersion: 3.10 -Contact: Roger Pau Monné -Description: - Maximum number of free pages to keep in each block - backend buffer. - -What: /sys/module/xen_blkback/parameters/max_persistent_grants -Date: March 2013 -KernelVersion: 3.10 -Contact: Roger Pau Monné -Description: - Maximum number of grants to map persistently in - blkback. If the frontend tries to use more than - max_persistent_grants, the LRU kicks in and starts - removing 5% of max_persistent_grants every 100ms. diff --git a/Documentation/ABI/testing/sysfs-driver-xen-blkback b/Documentation/ABI/testing/sysfs-driver-xen-blkback new file mode 100644 index 0000000..8bb43b6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-xen-blkback @@ -0,0 +1,17 @@ +What: /sys/module/xen_blkback/parameters/max_buffer_pages +Date: March 2013 +KernelVersion: 3.11 +Contact: Roger Pau Monné +Description: + Maximum number of free pages to keep in each block + backend buffer. + +What: /sys/module/xen_blkback/parameters/max_persistent_grants +Date: March 2013 +KernelVersion: 3.11 +Contact: Roger Pau Monné +Description: + Maximum number of grants to map persistently in + blkback. If the frontend tries to use more than + max_persistent_grants, the LRU kicks in and starts + removing 5% of max_persistent_grants every 100ms. -- cgit v1.1 From c5ceea7a2813fecded01567383cca4d6855164ab Mon Sep 17 00:00:00 2001 From: Mugunthan V N Date: Mon, 3 Jun 2013 20:10:10 +0000 Subject: drivers: net: ethernet: cpsw: add phy-mode support to cpsw driver Adding phy-mode support to cpsw driver and updating the cpsw binding documentation. Signed-off-by: Mugunthan V N Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/cpsw.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index 4f2ca6b..05d660e 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -28,6 +28,8 @@ Optional properties: Slave Properties: Required properties: - phy_id : Specifies slave phy id +- phy-mode : The interface between the SoC and the PHY (a string + that of_get_phy_mode() can understand) - mac-address : Specifies slave MAC address Optional properties: @@ -58,11 +60,13 @@ Examples: cpts_clock_shift = <29>; cpsw_emac0: slave@0 { phy_id = <&davinci_mdio>, <0>; + phy-mode = "rgmii-txid"; /* Filled in by U-Boot */ mac-address = [ 00 00 00 00 00 00 ]; }; cpsw_emac1: slave@1 { phy_id = <&davinci_mdio>, <1>; + phy-mode = "rgmii-txid"; /* Filled in by U-Boot */ mac-address = [ 00 00 00 00 00 00 ]; }; @@ -84,11 +88,13 @@ Examples: cpts_clock_shift = <29>; cpsw_emac0: slave@0 { phy_id = <&davinci_mdio>, <0>; + phy-mode = "rgmii-txid"; /* Filled in by U-Boot */ mac-address = [ 00 00 00 00 00 00 ]; }; cpsw_emac1: slave@1 { phy_id = <&davinci_mdio>, <1>; + phy-mode = "rgmii-txid"; /* Filled in by U-Boot */ mac-address = [ 00 00 00 00 00 00 ]; }; -- cgit v1.1 From 780b40df12cf0161d8ccc5381940e04584793933 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Wed, 5 Jun 2013 09:32:50 +0200 Subject: wireless: fix kernel-doc Some kernel-doc fixes for forgotten fields and renamed things. Signed-off-by: Johannes Berg --- Documentation/DocBook/80211.tmpl | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index ebe8969..49267ea9 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -127,12 +127,11 @@ !Finclude/net/cfg80211.h cfg80211_ibss_params !Finclude/net/cfg80211.h cfg80211_connect_params !Finclude/net/cfg80211.h cfg80211_pmksa -!Finclude/net/cfg80211.h cfg80211_send_rx_auth -!Finclude/net/cfg80211.h cfg80211_send_auth_timeout -!Finclude/net/cfg80211.h cfg80211_send_rx_assoc -!Finclude/net/cfg80211.h cfg80211_send_assoc_timeout -!Finclude/net/cfg80211.h cfg80211_send_deauth -!Finclude/net/cfg80211.h cfg80211_send_disassoc +!Finclude/net/cfg80211.h cfg80211_rx_mlme_mgmt +!Finclude/net/cfg80211.h cfg80211_auth_timeout +!Finclude/net/cfg80211.h cfg80211_rx_assoc_resp +!Finclude/net/cfg80211.h cfg80211_assoc_timeout +!Finclude/net/cfg80211.h cfg80211_tx_mlme_mgmt !Finclude/net/cfg80211.h cfg80211_ibss_joined !Finclude/net/cfg80211.h cfg80211_connect_result !Finclude/net/cfg80211.h cfg80211_roamed -- cgit v1.1 From d3eaace84e40bf946129e516dcbd617173c1cf14 Mon Sep 17 00:00:00 2001 From: Dave Chinner Date: Wed, 5 Jun 2013 12:09:09 +1000 Subject: xfs: disable noattr2/attr2 mount options for CRC enabled filesystems attr2 format is always enabled for v5 superblock filesystems, so the mount options to enable or disable it need to be cause mount errors. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Ben Myers --- Documentation/filesystems/xfs.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 3e4b3dd..83577f0 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt @@ -33,6 +33,9 @@ When mounting an XFS filesystem, the following options are accepted. removing extended attributes) the on-disk superblock feature bit field will be updated to reflect this format being in use. + CRC enabled filesystems always use the attr2 format, and so + will reject the noattr2 mount option if it is set. + barrier Enables the use of block layer write barriers for writes into the journal and unwritten extent conversion. This allows for -- cgit v1.1 From 17f34867e98d2fb0c03918faab79efb989fa134b Mon Sep 17 00:00:00 2001 From: Mathias Nyman Date: Thu, 23 May 2013 17:14:31 +0300 Subject: usb: add usb2 Link PM variables to sysfs and usb_device Adds abitilty to tune L1 timeout (inactivity timer for usb2 link sleep) and BESL (best effort service latency)via sysfs. This also adds a new usb2_lpm_parameters structure with those variables to struct usb_device. Signed-off-by: Mathias Nyman Signed-off-by: Sarah Sharp --- Documentation/ABI/testing/sysfs-bus-usb | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index f093e59..9759b8c 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 +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 +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) -- cgit v1.1 From 77ba83bb1bb1cdabd522d32536f8eee65a870145 Mon Sep 17 00:00:00 2001 From: Daniel Tang Date: Sat, 1 Jun 2013 16:02:37 +1000 Subject: clocksource: Add TI-Nspire timer support This patch adds a clocksource/clockevent driver for the timer found on some models in the TI-Nspire calculator series. The timer has two 16bit subtimers within its memory mapped I/O interface but only the first can generate interrupts. The first subtimer is used to generate clockevents but only if an interrupt number and register is given. The interrupt acknowledgement mechanism is a little strange because the interrupt mask and acknowledge registers are located in another memory mapped I/O peripheral. The address of this register is passed to the driver through device tree bindings. The second subtimer is used as a clocksource because it isn't capable of generating an interrupt. This subtimer is always added. Reviewed-by: Linus Walleij Signed-off-by: Daniel Tang Signed-off-by: Daniel Lezcano --- .../devicetree/bindings/timer/lsi,zevio-timer.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt b/Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt new file mode 100644 index 0000000..b2d07ad --- /dev/null +++ b/Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt @@ -0,0 +1,33 @@ +TI-NSPIRE timer + +Required properties: + +- compatible : should be "lsi,zevio-timer". +- reg : The physical base address and size of the timer (always first). +- clocks: phandle to the source clock. + +Optional properties: + +- interrupts : The interrupt number of the first timer. +- reg : The interrupt acknowledgement registers + (always after timer base address) + +If any of the optional properties are not given, the timer is added as a +clock-source only. + +Example: + +timer { + compatible = "lsi,zevio-timer"; + reg = <0x900D0000 0x1000>, <0x900A0020 0x8>; + interrupts = <19>; + clocks = <&timer_clk>; +}; + +Example (no clock-events): + +timer { + compatible = "lsi,zevio-timer"; + reg = <0x900D0000 0x1000>; + clocks = <&timer_clk>; +}; -- cgit v1.1 From f763fd440e094be37b38596ee14f1d64caa9bf9c Mon Sep 17 00:00:00 2001 From: Dave Chinner Date: Wed, 5 Jun 2013 12:09:09 +1000 Subject: xfs: disable noattr2/attr2 mount options for CRC enabled filesystems attr2 format is always enabled for v5 superblock filesystems, so the mount options to enable or disable it need to be cause mount errors. Signed-off-by: Dave Chinner Reviewed-by: Brian Foster Signed-off-by: Ben Myers (cherry picked from commit d3eaace84e40bf946129e516dcbd617173c1cf14) --- Documentation/filesystems/xfs.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 3e4b3dd..83577f0 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt @@ -33,6 +33,9 @@ When mounting an XFS filesystem, the following options are accepted. removing extended attributes) the on-disk superblock feature bit field will be updated to reflect this format being in use. + CRC enabled filesystems always use the attr2 format, and so + will reject the noattr2 mount option if it is set. + barrier Enables the use of block layer write barriers for writes into the journal and unwritten extent conversion. This allows for -- cgit v1.1 From ed9084ecfccae55ea45c7f068d1f513b979a0132 Mon Sep 17 00:00:00 2001 From: Joachim Eastwood Date: Thu, 6 Jun 2013 10:24:18 +0200 Subject: pcmcia: at91_cf: add support for DT Signed-off-by: Joachim Eastwood Signed-off-by: Nicolas Ferre Acked-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/ata/atmel-at91_cf.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/ata/atmel-at91_cf.txt (limited to 'Documentation') 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 0000000..c1d22b3 --- /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 */ + >; +}; -- cgit v1.1 From d50b110f14ad07066f9ad6e7f32e2b1a595b92f9 Mon Sep 17 00:00:00 2001 From: Mark Langsdorf Date: Thu, 6 Jun 2013 07:52:41 -0500 Subject: sata highbank: add bit-banged SGPIO driver support Highbank supports SGPIO by bit-banging out the SGPIO signals over three GPIO pins defined in the DTB. Add support for this SGPIO functionality. Signed-off-by: Mark Langsdorf Signed-off-by: Tejun Heo --- Documentation/devicetree/bindings/ata/ahci-platform.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index b519f9b..3ec0c5c 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -12,6 +12,11 @@ Optional properties: - calxeda,port-phys: phandle-combophy and lane assignment, which maps each SATA port to a combophy and a lane within that combophy +- calxeda,sgpio-gpio: phandle-gpio bank, bit offset, and default on or off, + which indicates that the driver supports SGPIO + indicator lights using the indicated GPIOs +- calxeda,led-order : a u32 array that map port numbers to offsets within the + SGPIO bitstream. - dma-coherent : Present if dma operations are coherent Example: -- cgit v1.1 From ace3647afb3eca214f6da5d653ad116ff77545b6 Mon Sep 17 00:00:00 2001 From: Chen Gong Date: Thu, 6 Jun 2013 15:28:11 -0700 Subject: ACPI/APEI: Update einj documentation for param1/param2 To ensure EINJ working well when injecting errors via EINJ table, add some restrictions: param1 must be a valid physical RAM address and param2 must specify page granularity or narrower. Signed-off-by: Chen Gong Signed-off-by: Tony Luck --- Documentation/acpi/apei/einj.txt | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/acpi/apei/einj.txt b/Documentation/acpi/apei/einj.txt index e20b6da..a58b63d 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 -- cgit v1.1 From 17b4565b308ed31fa20b59842c75e685a101dc8a Mon Sep 17 00:00:00 2001 From: "Kim, Milo" Date: Fri, 10 May 2013 07:17:51 +0000 Subject: lp8727_charger: Support the device tree feature The interrupt and charging parameters are configurable in the device tree structure. In the board test, a GPIO is used for handling LP8727 interrupts. The device tree binding documentation is added also. Signed-off-by: Milo(Woogyom) Kim Signed-off-by: Anton Vorontsov --- .../bindings/power_supply/lp8727_charger.txt | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/power_supply/lp8727_charger.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power_supply/lp8727_charger.txt b/Documentation/devicetree/bindings/power_supply/lp8727_charger.txt new file mode 100644 index 0000000..2246bc5 --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/lp8727_charger.txt @@ -0,0 +1,44 @@ +Binding for TI/National Semiconductor LP8727 Charger + +Required properties: +- compatible: "ti,lp8727" +- reg: I2C slave address 27h + +Optional properties: +- interrupt-parent: interrupt controller node (see interrupt binding[0]) +- interrupts: interrupt specifier (see interrupt binding[0]) +- debounce-ms: interrupt debounce time. (u32) + +AC and USB charging parameters +- charger-type: "ac" or "usb" (string) +- eoc-level: value of 'enum lp8727_eoc_level' (u8) +- charging-current: value of 'enum lp8727_ichg' (u8) + +[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt + +Example) + +lp8727@27 { + compatible = "ti,lp8727"; + reg = <0x27>; + + /* GPIO 134 is used for LP8728 interrupt pin */ + interrupt-parent = <&gpio5>; /* base = 128 */ + interrupts = <6 0x2>; /* offset = 6, falling edge type */ + + debounce-ms = <300>; + + /* AC charger: 5% EOC and 500mA charging current */ + ac { + charger-type = "ac"; + eoc-level = /bits/ 8 <0>; + charging-current = /bits/ 8 <4>; + }; + + /* USB charger: 10% EOC and 400mA charging current */ + usb { + charger-type = "usb"; + eoc-level = /bits/ 8 <1>; + charging-current = /bits/ 8 <2>; + }; +}; -- cgit v1.1 From d74e9e7090aeb9b61e683e5abf7ca70fa18f846b Mon Sep 17 00:00:00 2001 From: Nicolin Chen Date: Fri, 7 Jun 2013 11:23:27 +0800 Subject: ASoC: wm8962: Add device tree binding Document the device tree binding for the WM8962 codec, and modify the driver to extract platform data from the device tree, if present. Based on work of WM8903 by Stephen Warren Signed-off-by: Nicolin Chen Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/wm8962.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/wm8962.txt b/Documentation/devicetree/bindings/sound/wm8962.txt index dceb3b1..7f82b59 100644 --- a/Documentation/devicetree/bindings/sound/wm8962.txt +++ b/Documentation/devicetree/bindings/sound/wm8962.txt @@ -8,9 +8,32 @@ Required properties: - reg : the I2C address of the device. +Optional properties: + - spk-mono: This is a boolean property. If present, the SPK_MONO bit + of R51 (Class D Control 2) gets set, indicating that the speaker is + in mono mode. + + - mic-cfg : Default register value for R48 (Additional Control 4). + If absent, the default should be the register default. + + - gpio-cfg : A list of GPIO configuration register values. The list must + be 6 entries long. If absent, no configuration of these registers is + performed. And note that only the value within [0x0, 0xffff] is valid. + Any other value is regarded as setting the GPIO register by its reset + value 0x0. + Example: codec: wm8962@1a { compatible = "wlf,wm8962"; reg = <0x1a>; + + gpio-cfg = < + 0x0000 /* 0:Default */ + 0x0000 /* 1:Default */ + 0x0013 /* 2:FN_DMICCLK */ + 0x0000 /* 3:Default */ + 0x8014 /* 4:FN_DMICCDAT */ + 0x0000 /* 5:Default */ + >; }; -- cgit v1.1 From bcc567e3115055a9cc256183d72864f01286be22 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 23 May 2013 14:29:53 +0300 Subject: dmatest: do not allow to interrupt ongoing tests When user interrupts ongoing transfers the dmatest may end up with console lockup, oops, or data mismatch. This patch prevents user to abort any ongoing test. Documentation is updated accordingly. Signed-off-by: Andy Shevchenko Reported-by: Will Deacon Tested-by: Will Deacon Signed-off-by: Vinod Koul --- Documentation/dmatest.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dmatest.txt b/Documentation/dmatest.txt index 279ac0a..132a094 100644 --- a/Documentation/dmatest.txt +++ b/Documentation/dmatest.txt @@ -34,7 +34,7 @@ command: After a while you will start to get messages about current status or error like in the original code. -Note that running a new test will stop any in progress test. +Note that running a new test will not stop any in progress test. The following command should return actual state of the test. % cat /sys/kernel/debug/dmatest/run @@ -52,8 +52,8 @@ To wait for test done the user may perform a busy loop that checks the state. The module parameters that is supplied to the kernel command line will be used for the first performed test. After user gets a control, the test could be -interrupted or re-run with same or different parameters. For the details see -the above section "Part 2 - When dmatest is built as a module..." +re-run with the same or different parameters. For the details see the above +section "Part 2 - When dmatest is built as a module..." In both cases the module parameters are used as initial values for the test case. You always could check them at run-time by running -- cgit v1.1 From d70a3f887a38cb0acc7233a1d05f15c2b6e0be2b Mon Sep 17 00:00:00 2001 From: Daniel Borkmann Date: Thu, 6 Jun 2013 14:08:13 +0000 Subject: doc: packet: simplify tpacket example code This patch simplifies the tpacket_v3 example code a bit by getting rid of unecessary macro wrappers, removing some debugging code so that it is more to the point, and also adds a header comment. Now this example code is the very minimum one needs to start from when dealing with tpacket_v3 and ~100 lines smaller than before. Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller --- Documentation/networking/packet_mmap.txt | 133 +++++++------------------------ 1 file changed, 28 insertions(+), 105 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index 23dd80e..8572796 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -704,6 +704,12 @@ So it seems to be a good candidate to be used with packet fanout. Minimal example code by Daniel Borkmann based on Chetan Loke's lolpcap (compile it with gcc -Wall -O2 blob.c, and try things like "./a.out eth0", etc.): +/* Written from scratch, but kernel-to-user space API usage + * dissected from lolpcap: + * Copyright 2011, Chetan Loke + * License: GPL, version 2.0 + */ + #include #include #include @@ -722,27 +728,6 @@ it with gcc -Wall -O2 blob.c, and try things like "./a.out eth0", etc.): #include #include -#define BLOCK_SIZE (1 << 22) -#define FRAME_SIZE 2048 - -#define NUM_BLOCKS 64 -#define NUM_FRAMES ((BLOCK_SIZE * NUM_BLOCKS) / FRAME_SIZE) - -#define BLOCK_RETIRE_TOV_IN_MS 64 -#define BLOCK_PRIV_AREA_SZ 13 - -#define ALIGN_8(x) (((x) + 8 - 1) & ~(8 - 1)) - -#define BLOCK_STATUS(x) ((x)->h1.block_status) -#define BLOCK_NUM_PKTS(x) ((x)->h1.num_pkts) -#define BLOCK_O2FP(x) ((x)->h1.offset_to_first_pkt) -#define BLOCK_LEN(x) ((x)->h1.blk_len) -#define BLOCK_SNUM(x) ((x)->h1.seq_num) -#define BLOCK_O2PRIV(x) ((x)->offset_to_priv) -#define BLOCK_PRIV(x) ((void *) ((uint8_t *) (x) + BLOCK_O2PRIV(x))) -#define BLOCK_HDR_LEN (ALIGN_8(sizeof(struct block_desc))) -#define BLOCK_PLUS_PRIV(sz_pri) (BLOCK_HDR_LEN + ALIGN_8((sz_pri))) - #ifndef likely # define likely(x) __builtin_expect(!!(x), 1) #endif @@ -765,7 +750,7 @@ struct ring { static unsigned long packets_total = 0, bytes_total = 0; static sig_atomic_t sigint = 0; -void sighandler(int num) +static void sighandler(int num) { sigint = 1; } @@ -774,6 +759,8 @@ static int setup_socket(struct ring *ring, char *netdev) { int err, i, fd, v = TPACKET_V3; struct sockaddr_ll ll; + unsigned int blocksiz = 1 << 22, framesiz = 1 << 11; + unsigned int blocknum = 64; fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); if (fd < 0) { @@ -788,13 +775,12 @@ static int setup_socket(struct ring *ring, char *netdev) } memset(&ring->req, 0, sizeof(ring->req)); - ring->req.tp_block_size = BLOCK_SIZE; - ring->req.tp_frame_size = FRAME_SIZE; - ring->req.tp_block_nr = NUM_BLOCKS; - ring->req.tp_frame_nr = NUM_FRAMES; - ring->req.tp_retire_blk_tov = BLOCK_RETIRE_TOV_IN_MS; - ring->req.tp_sizeof_priv = BLOCK_PRIV_AREA_SZ; - ring->req.tp_feature_req_word |= TP_FT_REQ_FILL_RXHASH; + ring->req.tp_block_size = blocksiz; + ring->req.tp_frame_size = framesiz; + ring->req.tp_block_nr = blocknum; + ring->req.tp_frame_nr = (blocksiz * blocknum) / framesiz; + ring->req.tp_retire_blk_tov = 60; + ring->req.tp_feature_req_word = TP_FT_REQ_FILL_RXHASH; err = setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &ring->req, sizeof(ring->req)); @@ -804,8 +790,7 @@ static int setup_socket(struct ring *ring, char *netdev) } ring->map = mmap(NULL, ring->req.tp_block_size * ring->req.tp_block_nr, - PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED, - fd, 0); + PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED, fd, 0); if (ring->map == MAP_FAILED) { perror("mmap"); exit(1); @@ -835,58 +820,6 @@ static int setup_socket(struct ring *ring, char *netdev) return fd; } -#ifdef __checked -static uint64_t prev_block_seq_num = 0; - -void assert_block_seq_num(struct block_desc *pbd) -{ - if (unlikely(prev_block_seq_num + 1 != BLOCK_SNUM(pbd))) { - printf("prev_block_seq_num:%"PRIu64", expected seq:%"PRIu64" != " - "actual seq:%"PRIu64"\n", prev_block_seq_num, - prev_block_seq_num + 1, (uint64_t) BLOCK_SNUM(pbd)); - exit(1); - } - - prev_block_seq_num = BLOCK_SNUM(pbd); -} - -static void assert_block_len(struct block_desc *pbd, uint32_t bytes, int block_num) -{ - if (BLOCK_NUM_PKTS(pbd)) { - if (unlikely(bytes != BLOCK_LEN(pbd))) { - printf("block:%u with %upackets, expected len:%u != actual len:%u\n", - block_num, BLOCK_NUM_PKTS(pbd), bytes, BLOCK_LEN(pbd)); - exit(1); - } - } else { - if (unlikely(BLOCK_LEN(pbd) != BLOCK_PLUS_PRIV(BLOCK_PRIV_AREA_SZ))) { - printf("block:%u, expected len:%lu != actual len:%u\n", - block_num, BLOCK_HDR_LEN, BLOCK_LEN(pbd)); - exit(1); - } - } -} - -static void assert_block_header(struct block_desc *pbd, const int block_num) -{ - uint32_t block_status = BLOCK_STATUS(pbd); - - if (unlikely((block_status & TP_STATUS_USER) == 0)) { - printf("block:%u, not in TP_STATUS_USER\n", block_num); - exit(1); - } - - assert_block_seq_num(pbd); -} -#else -static inline void assert_block_header(struct block_desc *pbd, const int block_num) -{ -} -static void assert_block_len(struct block_desc *pbd, uint32_t bytes, int block_num) -{ -} -#endif - static void display(struct tpacket3_hdr *ppd) { struct ethhdr *eth = (struct ethhdr *) ((uint8_t *) ppd + ppd->tp_mac); @@ -916,37 +849,27 @@ static void display(struct tpacket3_hdr *ppd) static void walk_block(struct block_desc *pbd, const int block_num) { - int num_pkts = BLOCK_NUM_PKTS(pbd), i; + int num_pkts = pbd->h1.num_pkts, i; unsigned long bytes = 0; - unsigned long bytes_with_padding = BLOCK_PLUS_PRIV(BLOCK_PRIV_AREA_SZ); struct tpacket3_hdr *ppd; - assert_block_header(pbd, block_num); - - ppd = (struct tpacket3_hdr *) ((uint8_t *) pbd + BLOCK_O2FP(pbd)); + ppd = (struct tpacket3_hdr *) ((uint8_t *) pbd + + pbd->h1.offset_to_first_pkt); for (i = 0; i < num_pkts; ++i) { bytes += ppd->tp_snaplen; - if (ppd->tp_next_offset) - bytes_with_padding += ppd->tp_next_offset; - else - bytes_with_padding += ALIGN_8(ppd->tp_snaplen + ppd->tp_mac); - display(ppd); - ppd = (struct tpacket3_hdr *) ((uint8_t *) ppd + ppd->tp_next_offset); - __sync_synchronize(); + ppd = (struct tpacket3_hdr *) ((uint8_t *) ppd + + ppd->tp_next_offset); } - assert_block_len(pbd, bytes_with_padding, block_num); - packets_total += num_pkts; bytes_total += bytes; } -void flush_block(struct block_desc *pbd) +static void flush_block(struct block_desc *pbd) { - BLOCK_STATUS(pbd) = TP_STATUS_KERNEL; - __sync_synchronize(); + pbd->h1.block_status = TP_STATUS_KERNEL; } static void teardown_socket(struct ring *ring, int fd) @@ -962,7 +885,7 @@ int main(int argc, char **argp) socklen_t len; struct ring ring; struct pollfd pfd; - unsigned int block_num = 0; + unsigned int block_num = 0, blocks = 64; struct block_desc *pbd; struct tpacket_stats_v3 stats; @@ -984,15 +907,15 @@ int main(int argc, char **argp) while (likely(!sigint)) { pbd = (struct block_desc *) ring.rd[block_num].iov_base; -retry_block: - if ((BLOCK_STATUS(pbd) & TP_STATUS_USER) == 0) { + + if ((pbd->h1.block_status & TP_STATUS_USER) == 0) { poll(&pfd, 1, -1); - goto retry_block; + continue; } walk_block(pbd, block_num); flush_block(pbd); - block_num = (block_num + 1) % NUM_BLOCKS; + block_num = (block_num + 1) % blocks; } len = sizeof(stats); -- cgit v1.1 From e8b265e8ba322a01bb746504f6f64b5506853eac Mon Sep 17 00:00:00 2001 From: Rami Rosen Date: Fri, 7 Jun 2013 20:16:19 +0000 Subject: doc:networking: Fix default value (icmp_ignore_bogus_error_responses). This patch fixes icmp_ignore_bogus_error_responses default value to be 1 instead of FALSE. It is initialized to 1 in icmp_sk_init(). Signed-off-by: Rami Rosen Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 398d0fb..9cea5d3 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -729,7 +729,7 @@ icmp_ignore_bogus_error_responses - BOOLEAN frames. Such violations are normally logged via a kernel warning. If this is set to TRUE, the kernel will not give such warnings, which will avoid log file clutter. - Default: FALSE + Default: 1 icmp_errors_use_inbound_ifaddr - BOOLEAN -- cgit v1.1 From dfd50fc9030a62521838eecbe488e1962edcba80 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 29 May 2013 05:03:32 -0300 Subject: [media] DocBook/media/v4l: update version number The version number was still 3.9: update to 3.10. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/v4l2.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index bfc93cd..bfe823d 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -493,7 +493,7 @@ and discussions on the V4L mailing list. Video for Linux Two API Specification - Revision 3.9 + Revision 3.10 &sub-common; -- cgit v1.1 From 1bddf1b3ac021feb9dafcc2c6ef7018453e22589 Mon Sep 17 00:00:00 2001 From: Andrzej Hajda Date: Mon, 3 Jun 2013 05:16:13 -0300 Subject: [media] media: Rename media_entity_remote_source to media_entity_remote_pad Function media_entity_remote_source actually returns the remote pad to the given one, regardless if this is the source or the sink pad. Name media_entity_remote_pad is more adequate for this function. Signed-off-by: Andrzej Hajda Signed-off-by: Kyungmin Park Acked-by: Sakari Ailus Acked-by: Sylwester Nawrocki Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- Documentation/media-framework.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 77bd0a4..3702eff 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -265,7 +265,7 @@ connected to another pad through an enabled link media_entity_find_link(struct media_pad *source, struct media_pad *sink); - media_entity_remote_source(struct media_pad *pad); + media_entity_remote_pad(struct media_pad *pad); Refer to the kerneldoc documentation for more information. -- cgit v1.1 From c9e2e946fb0ba5d2398feb89558f98c5c28e23e3 Mon Sep 17 00:00:00 2001 From: Jingchang Lu Date: Fri, 7 Jun 2013 09:20:40 +0800 Subject: tty: serial: add Freescale lpuart driver support Add Freescale lpuart driver support. The lpuart device can be found on Vybrid VF610 and Layerscape LS-1 SoCs. Signed-off-by: Jingchang Lu Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/tty/serial/fsl-lpuart.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt (limited to 'Documentation') 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 0000000..6fd1dd1 --- /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,-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>; + }; -- cgit v1.1 From e764df67963940b4123325710536a9471d1e24ae Mon Sep 17 00:00:00 2001 From: Michael Hennerich Date: Mon, 3 Jun 2013 14:30:00 +0100 Subject: iio: frequency: adf4350: Add support for dt bindings Per review feedback from Lars-Peter Clausen Changes since V1: Fix return value handling of adf4350_parse_dt() Use of_get_gpio Avoid abbreviations in devicetree properties Fix typo in docs Signed-off-by: Michael Hennerich Reviewed-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/frequency/adf4350.txt | 86 ++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/frequency/adf4350.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/frequency/adf4350.txt b/Documentation/devicetree/bindings/iio/frequency/adf4350.txt new file mode 100644 index 0000000..f8c181d --- /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; + }; -- cgit v1.1 From 0629f1558a043fdc79b937d31bbbc10ca1c1237b Mon Sep 17 00:00:00 2001 From: Vivek Gautam Date: Wed, 10 Apr 2013 19:37:52 +0900 Subject: ARM: dts: Add device tree bindings for dwc3-exynos Document device tree binding information as required by the Samsung' USB 3.0 controller. Signed-off-by: Vivek Gautam Signed-off-by: Kukjin Kim --- .../devicetree/bindings/usb/exynos-usb.txt | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt index b3abde7..d967ba1 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>; + }; + }; -- cgit v1.1 From dc3c83581c915903a2cd9ef1a9d32014e6849a9f Mon Sep 17 00:00:00 2001 From: Sachin Kamat Date: Wed, 10 Apr 2013 19:01:51 +0900 Subject: ARM: dts: Update MFC documentation for clock entries Added clock entry definitions to MFC bindings document. Signed-off-by: Sachin Kamat Reviewed-by: Sylwester Nawrocki Signed-off-by: Kukjin Kim --- Documentation/devicetree/bindings/media/s5p-mfc.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index bf0182d..df37b02 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: -- cgit v1.1 From 83408745b202695e8911d71a9854c517e565c343 Mon Sep 17 00:00:00 2001 From: Andrzej Pietrasiewicz Date: Thu, 23 May 2013 10:51:15 +0200 Subject: usb: gadget: f_phonet: add configfs support f_phonet learns about configfs so we can remove in-kernel gadget drivers. Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Kyungmin Park Signed-off-by: Felipe Balbi --- Documentation/ABI/testing/configfs-usb-gadget-phonet | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-phonet (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-phonet b/Documentation/ABI/testing/configfs-usb-gadget-phonet new file mode 100644 index 0000000..19b67d3 --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-phonet @@ -0,0 +1,8 @@ +What: /config/usb-gadget/gadget/functions/phonet.name +Date: May 2013 +KenelVersion: 3.11 +Description: + + This item contains just one readonly attribute: ifname. + It contains the network interface name assigned during + network device registration. -- cgit v1.1 From 17b80976f0aa28842593dae8b05fae9274b51375 Mon Sep 17 00:00:00 2001 From: Andrzej Pietrasiewicz Date: Tue, 28 May 2013 09:15:51 +0200 Subject: usb: gadget: f_eem: add configfs support f_eem learns about our configfs interface so we can remove in-kernel gadget drivers in future. Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Kyungmin Park Signed-off-by: Felipe Balbi --- Documentation/ABI/testing/configfs-usb-gadget-eem | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-eem (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-eem b/Documentation/ABI/testing/configfs-usb-gadget-eem new file mode 100644 index 0000000..10e87d6 --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-eem @@ -0,0 +1,14 @@ +What: /config/usb-gadget/gadget/functions/eem.name +Date: May 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 -- cgit v1.1 From 02832e56f88a981474ee4c7c141f46fc1b4454f4 Mon Sep 17 00:00:00 2001 From: Andrzej Pietrasiewicz Date: Tue, 28 May 2013 09:15:56 +0200 Subject: usb: gadget: f_subset: add configfs support f_subset learns about configfs so we can, eventually, remove in-kernel gadget drivers. Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Kyungmin Park Signed-off-by: Felipe Balbi --- Documentation/ABI/testing/configfs-usb-gadget-subset | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-subset (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-subset b/Documentation/ABI/testing/configfs-usb-gadget-subset new file mode 100644 index 0000000..f47170a --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-subset @@ -0,0 +1,14 @@ +What: /config/usb-gadget/gadget/functions/geth.name +Date: May 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 -- cgit v1.1 From b3df2faacb40da7d9c4ed1a0b5304cf346e46ca0 Mon Sep 17 00:00:00 2001 From: Andrzej Pietrasiewicz Date: Tue, 28 May 2013 09:16:01 +0200 Subject: usb: gadget: f_rndis: add configfs support f_rndis learns about configfs so we can, eventually, remove in-kernel gadget drivers. Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Kyungmin Park Signed-off-by: Felipe Balbi --- Documentation/ABI/testing/configfs-usb-gadget-rndis | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-rndis (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget-rndis b/Documentation/ABI/testing/configfs-usb-gadget-rndis new file mode 100644 index 0000000..ff127dd --- /dev/null +++ b/Documentation/ABI/testing/configfs-usb-gadget-rndis @@ -0,0 +1,14 @@ +What: /config/usb-gadget/gadget/functions/rndis.name +Date: May 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 -- cgit v1.1 From 295fde89be1b7dce874c0f38d8bb78975a25d46e Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Mon, 29 Apr 2013 10:09:41 -0700 Subject: nohz_full: Update based on Sedat Dilek review Make it more clear that there are three options, and give hints as to which of the three is most likely to be useful in different situations. Reported-by: Sedat Dilek Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett --- Documentation/timers/NO_HZ.txt | 58 +++++++++++++++++++++++++++++++++++------- 1 file changed, 49 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/timers/NO_HZ.txt b/Documentation/timers/NO_HZ.txt index 5b53220..d5323e0 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, -- cgit v1.1 From ce5f4fc861e84739289c187f147040e6af6599b2 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Mon, 13 May 2013 10:32:10 -0700 Subject: nohz_full: Document additional restrictions This commit calls out the potential for slowing the tick even when there are multiple runnable processes per CPU, It also points out that current mainlined version keeps the tick going on at least one CPU even when all CPUs are otherwise idle. Finally, it notes the need for a 1-HZ tick in order to calculate CPU load, maintain sched average, compute CFS entity vruntime, compute avenrun, and carry out load balancing. Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett --- Documentation/timers/NO_HZ.txt | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/timers/NO_HZ.txt b/Documentation/timers/NO_HZ.txt index d5323e0..8869758 100644 --- a/Documentation/timers/NO_HZ.txt +++ b/Documentation/timers/NO_HZ.txt @@ -278,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 @@ -308,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. -- cgit v1.1 From f7bac9b85a333ebdfa5f500cf6acf753edffc05f Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Tue, 30 Apr 2013 10:48:35 -0700 Subject: kthread: Add kworker kthreads to OS-jitter documentation The kworker workqueue kthreads can also contribute to OS jitter. The amount of jitter depends on their use, so this commit adds documentation on avoiding OS jitter due to workqueue use. Reported-by: Jonathan Clairembault Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett --- Documentation/kernel-per-CPU-kthreads.txt | 47 +++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt index cbf7ae41..5f39ef5 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: -- cgit v1.1 From 99f88919f8fa8a8b01b5306c59c9977b94604df8 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Tue, 12 Mar 2013 16:54:14 -0700 Subject: rcu: Remove srcu_read_lock_raw() and srcu_read_unlock_raw(). These interfaces never did get used, so this commit removes them, their rcutorture tests, and documentation referencing them. Signed-off-by: Paul E. McKenney Reviewed-by: Lai Jiangshan Reviewed-by: Josh Triplett --- Documentation/RCU/checklist.txt | 6 ------ Documentation/RCU/torture.txt | 6 ------ Documentation/RCU/whatisRCU.txt | 22 +++++++--------------- 3 files changed, 7 insertions(+), 27 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 79e789b8..7703ec7 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 7dce8a1..d8a5023 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/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 10df0b8..0f0fb7c 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. -- cgit v1.1 From 7807acdb6b794b3af42dfa1912edd4fba8d0b622 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Wed, 27 Mar 2013 11:32:12 -0700 Subject: rcu: Remove TINY_PREEMPT_RCU tracing documentation Because TINY_PREEMPT_RCU is no more, this commit removes its tracing formats from the documentation. Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett --- Documentation/RCU/trace.txt | 100 ++------------------------------------------ 1 file changed, 4 insertions(+), 96 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt index c776968..f3778f8 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. -- cgit v1.1 From 060212928670593fb89243640bf05cf89560b023 Mon Sep 17 00:00:00 2001 From: Eliezer Tamir Date: Mon, 10 Jun 2013 11:39:50 +0300 Subject: net: add low latency socket poll Adds an ndo_ll_poll method and the code that supports it. This method can be used by low latency applications to busy-poll Ethernet device queues directly from the socket code. sysctl_net_ll_poll controls how many microseconds to poll. Default is zero (disabled). Individual protocol support will be added by subsequent patches. Signed-off-by: Alexander Duyck Signed-off-by: Jesse Brandeburg Signed-off-by: Eliezer Tamir Acked-by: Eric Dumazet Tested-by: Willem de Bruijn Signed-off-by: David S. Miller --- Documentation/sysctl/net.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index c1f8640..85ab72d 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -50,6 +50,13 @@ The maximum number of packets that kernel can handle on a NAPI interrupt, it's a Per-CPU variable. Default: 64 +low_latency_poll +---------------- +Low latency busy poll timeout. (needs CONFIG_NET_LL_RX_POLL) +Approximate time in us to spin waiting for packets on the device queue. +Recommended value is 50. May increase power usage. +Default: 0 (off) + rmem_default ------------ -- cgit v1.1 From 9dbd90f17e4f380593ec5194c2a4d5e52c5f72d1 Mon Sep 17 00:00:00 2001 From: Sebastian Hesselbarth Date: Thu, 6 Jun 2013 18:27:09 +0200 Subject: irqchip: Add support for Marvell Orion SoCs This patch adds an irqchip driver for the main interrupt controller found on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation). Corresponding device tree documentation is also added. Signed-off-by: Sebastian Hesselbarth Acked-by: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: John Stultz Cc: Russell King Cc: Jason Cooper Cc: Andrew Lunn Cc: Thomas Petazzoni Cc: Gregory Clement Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1370536034-23956-2-git-send-email-sebastian.hesselbarth@gmail.com Signed-off-by: Thomas Gleixner --- .../interrupt-controller/marvell,orion-intc.txt | 48 ++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt (limited to 'Documentation') 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 0000000..2c11ac7 --- /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>; + }; -- cgit v1.1 From f83478240e742efe1103110c28d48cc2b4dcee5c Mon Sep 17 00:00:00 2001 From: Lars-Peter Clausen Date: Tue, 11 Jun 2013 17:56:00 +0100 Subject: iio:dac: Add support for the AD7303 This patch adds support for the AD7303. The AD7303 is a simple 2 channel 8 bit DAC with an SPI interface. Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/dac/ad7303.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/ad7303.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/ad7303.txt b/Documentation/devicetree/bindings/iio/dac/ad7303.txt new file mode 100644 index 0000000..914610f --- /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>; + }; -- cgit v1.1 From 60e69858a377637bda4cd67981f2d865106983e6 Mon Sep 17 00:00:00 2001 From: Jingoo Han Date: Mon, 10 Jun 2013 17:38:32 +0900 Subject: ARM: dts: Document DP clock in samsung,exynos5-dp binding The exynos5-dp node needs a clock specified using the common clock framework. Signed-off-by: Jingoo Han Reviewed-by: Doug Anderson Signed-off-by: Kukjin Kim --- Documentation/devicetree/bindings/video/exynos_dp.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt index c60da67..84f10c1 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>; -- cgit v1.1 From 5cd644d837ae8c825066c225480647eb691e027d Mon Sep 17 00:00:00 2001 From: Sachin Kamat Date: Mon, 10 Jun 2013 17:49:41 +0900 Subject: clk: exynos4: Add additional G2D clocks Add G2D clocks for Exynos4x12 SoC and sclk_fimg2d required by G2D IP. Signed-off-by: Sachin Kamat Cc: Thomas Abraham Acked-by: Mike Turquette Signed-off-by: Kukjin Kim --- Documentation/devicetree/bindings/clock/exynos4-clock.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt index ea5e26f..14d5c2a 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 -- cgit v1.1 From 82f73176fd8511b5c45493416b8f76ca0d102f5f Mon Sep 17 00:00:00 2001 From: Sachin Kamat Date: Mon, 10 Jun 2013 17:52:30 +0900 Subject: ARM: dts: Update G2D documentation for clock entries Added clock entry definitions to G2D bindings document. Signed-off-by: Sachin Kamat Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Kukjin Kim --- Documentation/devicetree/bindings/gpu/samsung-g2d.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt index 2b14a94..3f454ff 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"; }; -- cgit v1.1 From ab52a9580fb0f32a033cca8761616ed16708fc03 Mon Sep 17 00:00:00 2001 From: Alexandre Relange Date: Tue, 11 Jun 2013 15:52:00 +0100 Subject: iio: ABI doc: update scan_elements sysfs paths update ABI documentation with current paths related to scan_elements folder Paths changed long time ago in commit: 26d25ae3f0d8ffe350aacc75b71198d6b35bd1f4 Signed-off-by: Alexandre Relange Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 90 ++++++++++++++++----------------- 1 file changed, 45 insertions(+), 45 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 2e33dc6..dda81ff 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: -- cgit v1.1 From 9fdb27d48a3a1abae4c3554b82dce9f0aafc377a Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Mon, 10 Jun 2013 18:22:19 +0900 Subject: gpio: samsung: Remove OF support for s3c24xx There is no users of this code and there is already a pinctrl driver written for s3c24xx which is going to be used on any s3c24xx DT platforms. Hence this has been effectively a dead code in mainline. This reverts commit 172c6a13653ac8cd6a231293b87c93821e90c1d6 gpio: samsung: add devicetree init for s3c24xx arches Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Acked-by: Heiko Stuebner Acked-by: Linus Walleij Signed-off-by: Kukjin Kim --- .../devicetree/bindings/gpio/gpio-samsung.txt | 43 ---------------------- 1 file changed, 43 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt index f1e5dfe..5375625 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; - }; -- cgit v1.1 From ad71d889b88055e61e3970a6744a271a51a94f42 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" Date: Tue, 30 Apr 2013 15:46:14 -0400 Subject: tracing: Add function probe to trigger a ftrace dump to console Add the "dump" command to have the ftrace buffer dumped to console if a function is hit. This is useful when debugging a tripple fault, where you have an idea of a function that is called just before the tripple fault occurs, and can tell ftrace to dump its content out to the console before it continues. Format is: :dump echo 'bad_address:dump' > /debug/tracing/set_ftrace_filter To remove this: echo '!bad_address:dump' > /debug/tracing/set_ftrace_filter Requested-by: Luis Claudio R. Goncalves Signed-off-by: Steven Rostedt --- Documentation/trace/ftrace.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index bfe8c29..cc9ec57 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -2430,6 +2430,13 @@ The following commands are supported: echo '!schedule:disable_event:sched:sched_switch' > \ set_ftrace_filter +- dump + When the function is hit, it will dump the contents of the ftrace + ring buffer to the console. This is useful if you need to debug + something, and want to dump the trace when a certain function + is hit. Perhaps its a function that is called before a tripple + fault happens and does not allow you to get a regular dump. + trace_pipe ---------- -- cgit v1.1 From 90e3c03c3a09a7b176b3fe59d78f5d9755ac8e37 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" Date: Tue, 30 Apr 2013 19:00:46 -0400 Subject: tracing: Add function probe to trigger a ftrace dump of current CPU trace Add the "cpudump" command to have the current CPU ftrace buffer dumped to console if a function is hit. This is useful when debugging a tripple fault, where you have an idea of a function that is called just before the tripple fault occurs, and can tell ftrace to dump its content out to the console before it continues. This differs from the "dump" command as it only dumps the content of the ring buffer for the currently executing CPU, and does not show the contents of the other CPUs. Format is: :cpudump echo 'bad_address:cpudump' > /debug/tracing/set_ftrace_filter To remove this: echo '!bad_address:cpudump' > /debug/tracing/set_ftrace_filter Signed-off-by: Steven Rostedt --- Documentation/trace/ftrace.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index cc9ec57..b937c6e 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -2437,6 +2437,12 @@ The following commands are supported: is hit. Perhaps its a function that is called before a tripple fault happens and does not allow you to get a regular dump. +- cpudump + When the function is hit, it will dump the contents of the ftrace + ring buffer for the current CPU to the console. Unlike the "dump" + command, it only prints out the contents of the ring buffer for the + CPU that executed the function that triggered the dump. + trace_pipe ---------- -- cgit v1.1 From a180132f270a96d3b0e1e290b2911647abe9ed8e Mon Sep 17 00:00:00 2001 From: Alexander Shiyan Date: Fri, 26 Apr 2013 19:47:30 +0400 Subject: GPIO: clps711x: Add DT support Add DT support to the CLPS711X GPIO driver. Signed-off-by: Alexander Shiyan Acked-by: Arnd Bergmann Acked-by: Linus Walleij Signed-off-by: Olof Johansson --- .../devicetree/bindings/gpio/gpio-clps711x.txt | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-clps711x.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt b/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt new file mode 100644 index 0000000..e0d0446 --- /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>; +}; -- cgit v1.1 From a92b83af289002080d47ff89269047ed84952729 Mon Sep 17 00:00:00 2001 From: Dinh Nguyen Date: Wed, 5 Jun 2013 10:02:54 -0500 Subject: ARM: socfpga: dts: Add gate-clock bindings Add bindings for "socfpga-gate-clk" clocks. These clocks directly feed the peripherals. Signed-off-by: Dinh Nguyen Reviewed-by: Pavel Machek CC: Arnd Bergmann CC: Olof Johansson Cc: Pavel Machek CC: Signed-off-by: Olof Johansson --- Documentation/devicetree/bindings/clock/altr_socfpga.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt index bd0c841..0045433 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. -- cgit v1.1 From 8d561b60a9174defff2e48e109f68a5f2ae7dd9c Mon Sep 17 00:00:00 2001 From: J Keerthy Date: Thu, 6 Jun 2013 10:57:21 +0530 Subject: mfd: DT bindings for the palmas family MFD Add the various binding files for the palmas family of chips. There is a top level MFD binding then a seperate binding for regulators IP blocks on chips. Signed-off-by: Graeme Gregory Signed-off-by: J Keerthy Signed-off-by: Ian Lartey Reviewed-by: Stephen Warren Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/mfd/palmas.txt | 49 +++++++++++++++ .../devicetree/bindings/regulator/palmas-pmic.txt | 72 ++++++++++++++++++++++ 2 files changed, 121 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/palmas.txt create mode 100644 Documentation/devicetree/bindings/regulator/palmas-pmic.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt new file mode 100644 index 0000000..892537d --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -0,0 +1,49 @@ +* palmas device tree bindings + +The TI palmas family current members :- +twl6035 (palmas) +twl6037 (palmas) +tps65913 (palmas) +tps65914 (palmas) + +Required properties: +- compatible : Should be from the list + ti,twl6035 + ti,twl6036 + ti,twl6037 + ti,tps65913 + ti,tps65914 + ti,tps80036 +and also the generic series names + ti,palmas +- interrupt-controller : palmas has its own internal IRQs +- #interrupt-cells : should be set to 2 for IRQ number and flags + The first cell is the IRQ number. + The second cell is the flags, encoded as the trigger masks from + Documentation/devicetree/bindings/interrupts.txt +- interrupt-parent : The parent interrupt controller. + +Optional properties: + ti,mux-padX : set the pad register X (1-2) to the correct muxing for the + hardware, if not set will use muxing in OTP. + +Example: + +palmas { + compatible = "ti,twl6035", "ti,palmas"; + reg = <0x48> + interrupt-parent = <&intc>; + interrupt-controller; + #interrupt-cells = <2>; + + ti,mux-pad1 = <0>; + ti,mux-pad2 = <0>; + + #address-cells = <1>; + #size-cells = <0>; + + pmic { + compatible = "ti,twl6035-pmic", "ti,palmas-pmic"; + .... + }; +} diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt new file mode 100644 index 0000000..d5a3086 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -0,0 +1,72 @@ +* palmas regulator IP block devicetree bindings + +Required properties: +- compatible : Should be from the list + ti,twl6035-pmic + ti,twl6036-pmic + ti,twl6037-pmic + ti,tps65913-pmic + ti,tps65914-pmic +and also the generic series names + ti,palmas-pmic +- interrupt-parent : The parent interrupt controller which is palmas. +- interrupts : The interrupt number and the type which can be looked up here: + arch/arm/boot/dts/include/dt-bindings/interrupt-controller/irq.h +- interrupts-name: The names of the individual interrupts. + +Optional properties: +- ti,ldo6-vibrator : ldo6 is in vibrator mode + +Optional nodes: +- regulators : Must contain a sub-node per regulator from the list below. + Each sub-node should contain the constraints and initialization + information for that regulator. See regulator.txt for a + description of standard properties for these sub-nodes. + Additional custom properties are listed below. + + For ti,palmas-pmic - smps12, smps123, smps3 depending on OTP, + smps45, smps457, smps7 depending on variant, smps6, smps[8-10], + ldo[1-9], ldoln, ldousb. + + Optional sub-node properties: + ti,warm-reset - maintain voltage during warm reset(boolean) + ti,roof-floor - control voltage selection by pin(boolean) + ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto, + 2 - eco, 3 - forced pwm + ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 2.5mV/us + ti,smps-range - OTP has the wrong range set for the hardware so override + 0 - low range, 1 - high range. + +Example: + +#include + +pmic { + compatible = "ti,twl6035-pmic", "ti,palmas-pmic"; + interrupt-parent = <&palmas>; + interrupts = <14 IRQ_TYPE_NONE>; + interrupts-name = "short-irq"; + + ti,ldo6-vibrator; + + regulators { + smps12_reg : smps12 { + regulator-name = "smps12"; + regulator-min-microvolt = < 600000>; + regulator-max-microvolt = <1500000>; + regulator-always-on; + regulator-boot-on; + ti,warm-reset; + ti,roof-floor; + ti,mode-sleep = <0>; + ti,tstep = <0>; + ti,smps-range = <1>; + }; + + ldo1_reg: ldo1 { + regulator-name = "ldo1"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + }; + }; +}; -- cgit v1.1 From 88b613e6234def882b0b601bf831bf89af2e27f0 Mon Sep 17 00:00:00 2001 From: Steffen Trumtrar Date: Thu, 30 May 2013 09:50:12 +0200 Subject: pwm: add pca9685 driver Add pwm driver for the NXP pca9685 16 channel pwm-led controller. The driver is really barebones at this stage. E.g. the OE' pin and therefore the corresponding registers are not supported. The driver was tested on a HW where this pin is tied to GND. Signed-off-by: Steffen Trumtrar [thierry.reding@gmail.com: style and whitespace cleanups] Signed-off-by: Thierry Reding --- .../devicetree/bindings/pwm/nxp,pca9685-pwm.txt | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt new file mode 100644 index 0000000..1e3dfe7 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt @@ -0,0 +1,27 @@ +NXP PCA9685 16-channel 12-bit PWM LED controller +================================================ + +Required properties: + - compatible: "nxp,pca9685-pwm" + - #pwm-cells: should be 2. The first cell specifies the per-chip index + of the PWM to use and the second cell is the period in nanoseconds. + The index 16 is the ALLCALL channel, that sets all PWM channels at the same + time. + +Optional properties: + - invert (bool): boolean to enable inverted logic + - open-drain (bool): boolean to configure outputs with open-drain structure; + if omitted use totem-pole structure + +Example: + +For LEDs that are directly connected to the PCA, the following setting is +applicable: + +pca: pca@41 { + compatible = "nxp,pca9685-pwm"; + #pwm-cells = <2>; + reg = <0x41>; + invert; + open-drain; +}; -- cgit v1.1 From a8b447f2bbbba737ff4478f498d7f83c75a9461b Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Tue, 4 Jun 2013 11:37:36 +0200 Subject: clocksource: dw_apb_timer_of: add clock-handling Add the possibility to get the clock-frequency from a timer clock instead of specifying it as dt property. Additionally also add the possibility to also define a controlling periphal clock for the timer block. The clock-frequency property is kept to act as fallback if no clocks are specified. Signed-off-by: Heiko Stuebner Acked-by: Jamie Iles --- Documentation/devicetree/bindings/rtc/dw-apb.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/dw-apb.txt b/Documentation/devicetree/bindings/rtc/dw-apb.txt index 93e2b0f..eb2327b 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"; + }; -- cgit v1.1 From 159f8a0209aff155af7f6fcdedd4a4484dd19c23 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Tue, 21 May 2013 13:40:06 +0200 Subject: gpio-rcar: Add DT support Add DT bindings for the gpio-rcar driver and read the device configuration from the DT node at probe time if available. Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Laurent Pinchart Signed-off-by: Simon Horman --- .../devicetree/bindings/gpio/renesas,gpio-rcar.txt | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt (limited to 'Documentation') 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 0000000..46d76a0 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt @@ -0,0 +1,52 @@ +* 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 is used to specify optional parameters as bit flags. Only the GPIO + active low flag (bit 0) is currently supported. + - gpio-ranges: Range of pins managed by the GPIO controller as a 4-cells + tuple using the following syntax. + + <[phandle of the pin controller node] + 0 + [index of the first pin] + [number of pins]> + +Please refer to gpio.txt in this directory for details of 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>; + }; -- cgit v1.1 From 77845b11a35f293a344fe868852e8c61498ae777 Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Mon, 10 Jun 2013 10:24:42 -0300 Subject: ASoC: sgtl5000: Add 'clocks' entry as a required propery Since commit 9e13f345 (ASoC: sgtl5000: Let the codec acquire its clock) , the 'clocks' entry is mandatory, so update the binding doc. Signed-off-by: Fabio Estevam Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/sgtl5000.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.txt b/Documentation/devicetree/bindings/sound/sgtl5000.txt index 9cc4444..955df60 100644 --- a/Documentation/devicetree/bindings/sound/sgtl5000.txt +++ b/Documentation/devicetree/bindings/sound/sgtl5000.txt @@ -5,9 +5,12 @@ Required properties: - reg : the I2C address of the device +- clocks : the clock provider of SYS_MCLK + Example: codec: sgtl5000@0a { compatible = "fsl,sgtl5000"; reg = <0x0a>; + clocks = <&clks 150>; }; -- cgit v1.1 From 8de2ae2a7f1fd71dc56d6b014029f93093e9c5d5 Mon Sep 17 00:00:00 2001 From: Nicolin Chen Date: Tue, 11 Jun 2013 02:43:30 +0800 Subject: ASoC: fsl: add imx-wm8962 machine driver This is the initial imx-wm8962 device-tree-only machine driver working with fsl_ssi driver. More features can be added on top of it later. Signed-off-by: Nicolin Chen Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/imx-audio-wm8962.txt | 46 ++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt b/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt new file mode 100644 index 0000000..f49450a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt @@ -0,0 +1,46 @@ +Freescale i.MX audio complex with WM8962 codec + +Required properties: +- compatible : "fsl,imx-audio-wm8962" +- model : The user-visible name of this sound complex +- ssi-controller : The phandle of the i.MX SSI controller +- audio-codec : The phandle of the WM8962 audio codec +- audio-routing : A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names could be power + supplies, WM8962 pins, and the jacks on the board: + + Power supplies: + * Mic Bias + + Board connectors: + * Mic Jack + * Headphone Jack + * Ext Spk + +- mux-int-port : The internal port of the i.MX audio muxer (AUDMUX) +- mux-ext-port : The external port of the i.MX audio muxer + +Note: The AUDMUX port numbering should start at 1, which is consistent with +hardware manual. + +Example: + +sound { + compatible = "fsl,imx6q-sabresd-wm8962", + "fsl,imx-audio-wm8962"; + model = "wm8962-audio"; + ssi-controller = <&ssi2>; + audio-codec = <&codec>; + audio-routing = + "Headphone Jack", "HPOUTL", + "Headphone Jack", "HPOUTR", + "Ext Spk", "SPKOUTL", + "Ext Spk", "SPKOUTR", + "MICBIAS", "AMIC", + "IN3R", "MICBIAS", + "DMIC", "MICBIAS", + "DMICDAT", "DMIC"; + mux-int-port = <2>; + mux-ext-port = <3>; +}; -- cgit v1.1 From 379e04c79e8a9ded8a202f1e266f0c5830185bea Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Tue, 2 Apr 2013 17:46:31 +0100 Subject: arm64: KVM: userspace API documentation Unsurprisingly, the arm64 userspace API is extremely similar to the 32bit one, the only significant difference being the ONE_REG register mapping. Reviewed-by: Catalin Marinas Signed-off-by: Marc Zyngier --- Documentation/virtual/kvm/api.txt | 58 ++++++++++++++++++++++++++------------- 1 file changed, 39 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 5f91eda..9bfadeb 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -280,7 +280,7 @@ kvm_run' (see below). 4.11 KVM_GET_REGS Capability: basic -Architectures: all except ARM +Architectures: all except ARM, arm64 Type: vcpu ioctl Parameters: struct kvm_regs (out) Returns: 0 on success, -1 on error @@ -301,7 +301,7 @@ struct kvm_regs { 4.12 KVM_SET_REGS Capability: basic -Architectures: all except ARM +Architectures: all except ARM, arm64 Type: vcpu ioctl Parameters: struct kvm_regs (in) Returns: 0 on success, -1 on error @@ -587,7 +587,7 @@ struct kvm_fpu { 4.24 KVM_CREATE_IRQCHIP Capability: KVM_CAP_IRQCHIP -Architectures: x86, ia64, ARM +Architectures: x86, ia64, ARM, arm64 Type: vm ioctl Parameters: none Returns: 0 on success, -1 on error @@ -595,14 +595,14 @@ Returns: 0 on success, -1 on error Creates an interrupt controller model in the kernel. On x86, creates a virtual ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23 -only go to the IOAPIC. On ia64, a IOSAPIC is created. On ARM, a GIC is +only go to the IOAPIC. On ia64, a IOSAPIC is created. On ARM/arm64, a GIC is created. 4.25 KVM_IRQ_LINE Capability: KVM_CAP_IRQCHIP -Architectures: x86, ia64, arm +Architectures: x86, ia64, arm, arm64 Type: vm ioctl Parameters: struct kvm_irq_level Returns: 0 on success, -1 on error @@ -612,9 +612,10 @@ On some architectures it is required that an interrupt controller model has been previously created with KVM_CREATE_IRQCHIP. Note that edge-triggered interrupts require the level to be set to 1 and then back to 0. -ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip -(GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for -specific cpus. The irq field is interpreted like this: +ARM/arm64 can signal an interrupt either at the CPU level, or at the +in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to +use PPIs designated for specific cpus. The irq field is interpreted +like this:  bits: | 31 ... 24 | 23 ... 16 | 15 ... 0 | field: | irq_type | vcpu_index | irq_id | @@ -1831,6 +1832,22 @@ ARM 32-bit VFP control registers have the following id bit patterns: ARM 64-bit FP registers have the following id bit patterns: 0x4030 0000 0012 0 + +arm64 registers are mapped using the lower 32 bits. The upper 16 of +that is the register group type, or coprocessor number: + +arm64 core/FP-SIMD registers have the following id bit patterns. Note +that the size of the access is variable, as the kvm_regs structure +contains elements ranging from 32 to 128 bits. The index is a 32bit +value in the kvm_regs structure seen as a 32bit array. + 0x60x0 0000 0010 + +arm64 CCSIDR registers are demultiplexed by CSSELR value: + 0x6020 0000 0011 00 + +arm64 system registers have the following id bit patterns: + 0x6030 0000 0013 + 4.69 KVM_GET_ONE_REG Capability: KVM_CAP_ONE_REG @@ -2264,7 +2281,7 @@ current state. "addr" is ignored. 4.77 KVM_ARM_VCPU_INIT Capability: basic -Architectures: arm +Architectures: arm, arm64 Type: vcpu ioctl Parameters: struct struct kvm_vcpu_init (in) Returns: 0 on success; -1 on error @@ -2283,12 +2300,14 @@ should be created before this ioctl is invoked. Possible features: - KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state. Depends on KVM_CAP_ARM_PSCI. + - KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode. + Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only). 4.78 KVM_GET_REG_LIST Capability: basic -Architectures: arm +Architectures: arm, arm64 Type: vcpu ioctl Parameters: struct kvm_reg_list (in/out) Returns: 0 on success; -1 on error @@ -2308,7 +2327,7 @@ KVM_GET_ONE_REG/KVM_SET_ONE_REG calls. 4.80 KVM_ARM_SET_DEVICE_ADDR Capability: KVM_CAP_ARM_SET_DEVICE_ADDR -Architectures: arm +Architectures: arm, arm64 Type: vm ioctl Parameters: struct kvm_arm_device_address (in) Returns: 0 on success, -1 on error @@ -2329,18 +2348,19 @@ can access emulated or directly exposed devices, which the host kernel needs to know about. The id field is an architecture specific identifier for a specific device. -ARM divides the id field into two parts, a device id and an address type id -specific to the individual device. +ARM/arm64 divides the id field into two parts, a device id and an +address type id specific to the individual device.  bits: | 63 ... 32 | 31 ... 16 | 15 ... 0 | field: | 0x00000000 | device id | addr type id | -ARM currently only require this when using the in-kernel GIC support for the -hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2 as the device id. When -setting the base address for the guest's mapping of the VGIC virtual CPU -and distributor interface, the ioctl must be called after calling -KVM_CREATE_IRQCHIP, but before calling KVM_RUN on any of the VCPUs. Calling -this ioctl twice for any of the base addresses will return -EEXIST. +ARM/arm64 currently only require this when using the in-kernel GIC +support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2 +as the device id. When setting the base address for the guest's +mapping of the VGIC virtual CPU and distributor interface, the ioctl +must be called after calling KVM_CREATE_IRQCHIP, but before calling +KVM_RUN on any of the VCPUs. Calling this ioctl twice for any of the +base addresses will return -EEXIST. 4.82 KVM_PPC_RTAS_DEFINE_TOKEN -- cgit v1.1 From aa4a73a0a23a65a2f531d01f1865d1e61c6acb55 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Thu, 2 May 2013 14:31:03 +0100 Subject: arm64: KVM: document kernel object mappings in HYP HYP mode has access to some of the kernel pages. Document the memory mapping and the offset between kernel VA and HYP VA. Reviewed-by: Catalin Marinas Signed-off-by: Marc Zyngier --- Documentation/arm64/memory.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt index 5f583af..78a37712 100644 --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -73,3 +73,10 @@ Translation table lookup with 64KB pages: | | +--------------------------> [41:29] L2 index (only 38:29 used) | +-------------------------------> [47:42] L1 index (not used) +-------------------------------------------------> [63] TTBR0/1 + +When using KVM, the hypervisor maps kernel pages in EL2, at a fixed +offset from the kernel VA (top 24bits of the kernel VA set to zero): + +Start End Size Use +----------------------------------------------------------------------- +0000004000000000 0000007fffffffff 256GB kernel objects mapped in HYP -- cgit v1.1 From 0396310b0eba71595c1151ce7c8fde7a9f33f719 Mon Sep 17 00:00:00 2001 From: "Patil, Rachna" Date: Thu, 24 Jan 2013 03:45:10 +0000 Subject: input: ti_am33x_tsc: Add DT support This patch adds DT support to touch driver. It also provides a binding document which is used by the MFD and IIO part of the device. This patch also renames steps_to_configure to coordinate_readouts because the original name misleads the purpose of the variable. Signed-off-by: Pantelis Antoniou Signed-off-by: Patil, Rachna Signed-off-by: Felipe Balbi Signed-off-by: Sebastian Andrzej Siewior --- .../bindings/input/touchscreen/ti-tsc-adc.txt | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt new file mode 100644 index 0000000..491c97b --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt @@ -0,0 +1,44 @@ +* TI - TSC ADC (Touschscreen and analog digital converter) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Required properties: +- child "tsc" + ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen + support on the platform. + ti,x-plate-resistance: X plate resistance + ti,coordiante-readouts: The sequencer supports a total of 16 + programmable steps each step is used to + read a single coordinate. A single + readout is enough but multiple reads can + increase the quality. + A value of 5 means, 5 reads for X, 5 for + Y and 2 for Z (always). This utilises 12 + of the 16 software steps available. The + remaining 4 can be used by the ADC. + ti,wire-config: Different boards could have a different order for + connecting wires on touchscreen. We need to provide an + 8 bit number where in the 1st four bits represent the + analog lines and the next 4 bits represent positive/ + negative terminal on that input line. Notations to + represent the input lines and terminals resoectively + is as follows: + AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. + XP = 0, XN = 1, YP = 2, YN = 3. +- child "adc" + ti,adc-channels: List of analog inputs available for ADC. + AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7. + +Example: + tscadc: tscadc@44e0d000 { + compatible = "ti,am3359-tscadc"; + tsc { + ti,wires = <4>; + ti,x-plate-resistance = <200>; + ti,coordiante-readouts = <5>; + ti,wire-config = <0x00 0x11 0x22 0x33>; + }; + + adc { + ti,adc-channels = <4 5 6 7>; + }; + } -- cgit v1.1 From dcad9f031240d59e9e1475a8e5b2cb427da94f6e Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Wed, 12 Jun 2013 11:34:30 -0600 Subject: ASoC: rt5640: add device tree support Modify the RT5640 driver to parse platform data from device tree. Write a DT binding document to describe those properties. Slight re-ordering of rt5640_i2c_probe() to better fit the DT parsing. Since ldo1_en is optional, guard usage of it with gpio_is_valid(), rather than open-coding an if (gpio) check. Signed-off-by: Stephen Warren Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/rt5640.txt | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/rt5640.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/rt5640.txt b/Documentation/devicetree/bindings/sound/rt5640.txt new file mode 100644 index 0000000..005bcb2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rt5640.txt @@ -0,0 +1,30 @@ +RT5640 audio CODEC + +This device supports I2C only. + +Required properties: + +- compatible : "realtek,rt5640". + +- reg : The I2C address of the device. + +- interrupts : The CODEC's interrupt output. + +Optional properties: + +- realtek,in1-differential +- realtek,in2-differential + Boolean. Indicate MIC1/2 input are differential, rather than single-ended. + +- realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin. + +Example: + +rt5640 { + compatible = "realtek,rt5640"; + reg = <0x1c>; + interrupt-parent = <&gpio>; + interrupts = ; + realtek,ldo1-en-gpios = + <&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>; +}; -- cgit v1.1 From 040a62cf1c040362fb11587fb9f02e1881f4c237 Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Wed, 12 Jun 2013 11:35:34 -0600 Subject: ASoC: tegra: add tegra+RT5640 machine driver Initially, this binding and driver only describe/support playback to headphones and speakers. This driver will support Beaver and Dalmore. Signed-off-by: Stephen Warren Signed-off-by: Mark Brown --- .../bindings/sound/nvidia,tegra-audio-rt5640.txt | 71 ++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt new file mode 100644 index 0000000..d130818 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt @@ -0,0 +1,71 @@ +NVIDIA Tegra audio complex, with RT5640 CODEC + +Required properties: +- compatible : "nvidia,tegra-audio-rt5640" +- clocks : Must contain an entry for each entry in clock-names. +- clock-names : Must include the following entries: + "pll_a" (The Tegra clock of that name), + "pll_a_out0" (The Tegra clock of that name), + "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) +- nvidia,model : The user-visible name of this sound complex. +- nvidia,audio-routing : A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the RT5640's pins, and the jacks on the board: + + RT5640 pins: + + * DMIC1 + * DMIC2 + * MICBIAS1 + * IN1P + * IN1R + * IN2P + * IN2R + * HPOL + * HPOR + * LOUTL + * LOUTR + * MONOP + * MONON + * SPOLP + * SPOLN + * SPORP + * SPORN + + Board connectors: + + * Headphones + * Speakers + +- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's + connected to the CODEC. +- nvidia,audio-codec : The phandle of the RT5640 audio codec. This binding + assumes that AIF1 on the CODEC is connected to Tegra. + +Optional properties: +- nvidia,hp-det-gpios : The GPIO that detects headphones are plugged in + +Example: + +sound { + compatible = "nvidia,tegra-audio-rt5640-dalmore", + "nvidia,tegra-audio-rt5640"; + nvidia,model = "NVIDIA Tegra Dalmore"; + + nvidia,audio-routing = + "Headphones", "HPOR", + "Headphones", "HPOL", + "Speakers", "SPORP", + "Speakers", "SPORN", + "Speakers", "SPOLP", + "Speakers", "SPOLN"; + + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&rt5640>; + + nvidia,hp-det-gpios = <&gpio 143 0>; /* GPIO PR7 */ + + clocks = <&tegra_car 216>, <&tegra_car 217>, <&tegra_car 120>; + clock-names = "pll_a", "pll_a_out0", "mclk"; +}; -- cgit v1.1 From 43f68444bce70e360ff6ce3653a54e511625f651 Mon Sep 17 00:00:00 2001 From: Rohit Vaswani Date: Mon, 10 Jun 2013 15:50:21 -0700 Subject: gpio: msm: Add device tree and irqdomain support for gpio-msm-v2 This cleans up the gpio-msm-v2 driver of all the global define usage. The number of gpios are now defined in the device tree. This enables adding irqdomain support as well. Signed-off-by: Rohit Vaswani Acked-by: Grant Likely Signed-off-by: David Brown --- .../devicetree/bindings/gpio/gpio-msm.txt | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-msm.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-msm.txt b/Documentation/devicetree/bindings/gpio/gpio-msm.txt new file mode 100644 index 0000000..ac20e68 --- /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>; + }; -- cgit v1.1 From e3d73bcedfdf66d21349fee00241b0931d28a943 Mon Sep 17 00:00:00 2001 From: Cong Wang Date: Tue, 11 Jun 2013 18:54:39 +0800 Subject: net: add doc for ip_early_demux sysctl commit 6648bd7e0e62c0c8c03b (ipv4: Add sysctl knob to control early socket demux) introduced such sysctl, but forgot to add doc into Documentation/networking/ip-sysctl.txt. This patch adds it. Basically I grab the doc from the description of commit 41063e9dd11956f2d285 (ipv4: Early TCP socket demux.) and the above commit. Cc: Eric Dumazet Cc: Alexander Duyck Cc: David S. Miller Signed-off-by: Cong Wang Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 9cea5d3..36e5a40 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -685,6 +685,15 @@ ip_dynaddr - BOOLEAN occurs. Default: 0 +ip_early_demux - BOOLEAN + Optimize input packet processing down to one demux for + certain kinds of local sockets. Currently we only do this + for established TCP sockets. + + It may add an additional cost for pure routing workloads that + reduces overall throughput, in such case you should disable it. + Default: 1 + icmp_echo_ignore_all - BOOLEAN If set non-zero, then the kernel will ignore all ICMP ECHO requests sent to it. -- cgit v1.1 From bba00e59107275faa615573c44eb0a513a1220a6 Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Wed, 12 Jun 2013 14:04:57 -0700 Subject: rtc-at91rm9200: use shadow IMR on at91sam9x5 Add support for the at91sam9x5-family which must use the shadow interrupt mask due to a hardware issue (causing RTC_IMR to always be zero). Signed-off-by: Johan Hovold Acked-by: Nicolas Ferre Cc: Douglas Gilbert Cc: Jean-Christophe PLAGNIOL-VILLARD Cc: Ludovic Desroches Cc: Robert Nelson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt index 2a3feab..34c1505 100644 --- a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt +++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt @@ -1,7 +1,7 @@ Atmel AT91RM9200 Real Time Clock Required properties: -- compatible: should be: "atmel,at91rm9200-rtc" +- compatible: should be: "atmel,at91rm9200-rtc" or "atmel,at91sam9x5-rtc" - reg: physical base address of the controller and length of memory mapped region. - interrupts: rtc alarm/event interrupt -- cgit v1.1 From c28c99e7741f848ffe808a578b265dd2bb23a52f Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Wed, 8 May 2013 14:24:14 -0300 Subject: [media] exynos4-is: Fix example dts in .../bindings/samsung-fimc.txt The s5c73m3 sensor node should be off an I2C bus controller node. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/samsung-fimc.txt | 26 +++++++++++----------- 1 file changed, 13 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt index 51c776b..96312f6 100644 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt @@ -127,22 +127,22 @@ Example: }; }; }; - }; - /* MIPI CSI-2 bus IF sensor */ - s5c73m3: sensor@0x1a { - compatible = "samsung,s5c73m3"; - reg = <0x1a>; - vddio-supply = <...>; + /* MIPI CSI-2 bus IF sensor */ + s5c73m3: sensor@0x1a { + compatible = "samsung,s5c73m3"; + reg = <0x1a>; + vddio-supply = <...>; - clock-frequency = <24000000>; - clocks = <...>; - clock-names = "mclk"; + clock-frequency = <24000000>; + clocks = <...>; + clock-names = "mclk"; - port { - s5c73m3_1: endpoint { - data-lanes = <1 2 3 4>; - remote-endpoint = <&csis0_ep>; + port { + s5c73m3_1: endpoint { + data-lanes = <1 2 3 4>; + remote-endpoint = <&csis0_ep>; + }; }; }; }; -- cgit v1.1 From 0c1569590a6f14130b3660241580036176dba718 Mon Sep 17 00:00:00 2001 From: Eduardo Valentin Date: Wed, 29 May 2013 15:07:40 +0000 Subject: thermal: ti-soc-thermal: update DT reference for OMAP5430 Add missing irq line for TALERT on DT entry for OMAP5430. Cc: linux-pm@vger.kernel.org Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: Greg Kroah-Hartman Cc: Zhang Rui Cc: J Keerthy Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin Signed-off-by: Zhang Rui --- Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt index a4a33d1..1629652 100644 --- a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt +++ b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt @@ -57,4 +57,5 @@ bandgap { 0x4a002380 0x2c 0x4a0023C0 0x3c>; compatible = "ti,omap5430-bandgap"; + interrupts = <0 126 4>; /* talert */ }; -- cgit v1.1 From ca0c711463565a8735b24f3b08310287adb6b4c9 Mon Sep 17 00:00:00 2001 From: Eduardo Valentin Date: Wed, 29 May 2013 15:07:46 +0000 Subject: thermal: ti-soc-thermal: add DT example for DRA752 chip Update documentation by adding an example for DRA752 on DT description. Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: Greg Kroah-Hartman Cc: Zhang Rui Cc: J Keerthy Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin Signed-off-by: Zhang Rui --- Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt index 1629652..1953b33 100644 --- a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt +++ b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt @@ -59,3 +59,15 @@ bandgap { compatible = "ti,omap5430-bandgap"; interrupts = <0 126 4>; /* talert */ }; + +DRA752: +bandgap { + reg = <0x4a0021e0 0xc + 0x4a00232c 0xc + 0x4a002380 0x2c + 0x4a0023C0 0x3c + 0x4a002564 0x8 + 0x4a002574 0x50>; + compatible = "ti,dra752-bandgap"; + interrupts = <0 126 4>; /* talert */ +}; -- cgit v1.1 From c24d2976c7834aa948f9d8a48ad4285cfbaf1c3a Mon Sep 17 00:00:00 2001 From: James Hogan Date: Wed, 5 Dec 2012 16:32:10 +0000 Subject: metag: minimal TZ1090 (Comet) SoC infrastructure Add really minimal support for Toumaz Xenif TZ1090 SoC (A.K.A. Comet). This consists of minimal build infrastructure, device tree files, and a defconfig based on meta2_defconfig. This SoC contains a 2-threaded HTP (Meta 2) as the main application processor, and is found in a number of development boards and digital radios, such as the Minimorph Development Platform. Signed-off-by: James Hogan Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: Arnd Bergmann Cc: linux-doc@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 6931c43..be80992 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -57,6 +57,7 @@ snps Synopsys, Inc. st STMicroelectronics ste ST-Ericsson stericsson ST-Ericsson +toumaz Toumaz ti Texas Instruments toshiba Toshiba Corporation via VIA Technologies, Inc. -- cgit v1.1 From caa279dda4d9a442d824cd333e8b72078b83e855 Mon Sep 17 00:00:00 2001 From: James Hogan Date: Tue, 15 Jan 2013 15:27:45 +0000 Subject: metag: init common clk and use "core" clk If the common clock framework is enabled, call of_clk_init(NULL) in time_init() to register device tree clocks with the clock framework. After this time_init() calls a new function init_metag_clocks(), which looks for a clock named "core" in the node compatible with "img,meta" (usually the root node). If found the get_core_freq machine callback is overridden to obtain the core clock frequency using that clock. Signed-off-by: James Hogan Cc: Mike Turquette Cc: Grant Likely Cc: Rob Herring Cc: devicetree-discuss@lists.ozlabs.org --- Documentation/devicetree/bindings/metag/meta.txt | 30 ++++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 Documentation/devicetree/bindings/metag/meta.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/metag/meta.txt b/Documentation/devicetree/bindings/metag/meta.txt new file mode 100644 index 0000000..f4457f5 --- /dev/null +++ b/Documentation/devicetree/bindings/metag/meta.txt @@ -0,0 +1,30 @@ +* Meta Processor Binding + +This binding specifies what properties must be available in the device tree +representation of a Meta Processor Core, which is the root node in the tree. + +Required properties: + + - compatible: Specifies the compatibility list for the Meta processor. + The type shall be and the value shall include "img,meta". + +Optional properties: + + - clocks: Clock consumer specifiers as described in + Documentation/devicetree/bindings/clock/clock-bindings.txt + + - clock-names: Clock consumer names as described in + Documentation/devicetree/bindings/clock/clock-bindings.txt. + +Clocks are identified by name. Valid clocks are: + + - "core": The Meta core clock from which the Meta timers are derived. + +* Examples + +/ { + compatible = "toumaz,tz1090", "img,meta"; + + clocks = <&meta_core_clk>; + clock-names = "core"; +}; -- cgit v1.1 From 257867dc8d893690c175c1f717f91c3b6d44a63d Mon Sep 17 00:00:00 2001 From: Peter Hutterer Date: Fri, 31 May 2013 16:29:44 +1000 Subject: Input: MT - Specify that ABS_MT_SLOT must have a minimum of 0 This is effectively already in force through input_mt_init_slots, and uinput too ignores the actual minimum. Since slots are a kernel-genenerated axis only, non-zero minimums make little sense and are likely to cause errors. Better to treat a non-zero minimum as kernel bug if it ever happens. Signed-off-by: Peter Hutterer Acked-by: Benjamin Tissoires Signed-off-by: Henrik Rydberg --- Documentation/input/multi-touch-protocol.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt index 2c17961..de139b1 100644 --- a/Documentation/input/multi-touch-protocol.txt +++ b/Documentation/input/multi-touch-protocol.txt @@ -80,6 +80,8 @@ Userspace can detect that a driver can report more total contacts than slots by noting that the largest supported BTN_TOOL_*TAP event is larger than the total number of type B slots reported in the absinfo for the ABS_MT_SLOT axis. +The minimum value of the ABS_MT_SLOT axis must be 0. + Protocol Example A ------------------ -- cgit v1.1 From 9092c02d943515b3c9ffd5d0003527f8cc1dd77b Mon Sep 17 00:00:00 2001 From: Jonathan Brassow Date: Thu, 2 May 2013 14:19:24 -0500 Subject: DM RAID: Add ability to restore transiently failed devices on resume DM RAID: Add ability to restore transiently failed devices on resume This patch adds code to the resume function to check over the devices in the RAID array. If any are found to be marked as failed and their superblocks can be read, an attempt is made to reintegrate them into the array. This allows the user to refresh the array with a simple suspend and resume of the array - rather than having to load a completely new table, allocate and initialize all the structures and throw away the old instantiation. Signed-off-by: Jonathan Brassow Signed-off-by: NeilBrown --- Documentation/device-mapper/dm-raid.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt index e919228..2bb3a68 100644 --- a/Documentation/device-mapper/dm-raid.txt +++ b/Documentation/device-mapper/dm-raid.txt @@ -222,3 +222,4 @@ Version History 1.4.2 Add RAID10 "far" and "offset" algorithm support. 1.5.0 Add message interface to allow manipulation of the sync_action. New status (STATUSTYPE_INFO) fields: sync_action and mismatch_cnt. +1.5.1 Add ability to restore transiently failed devices on resume. -- cgit v1.1 From 6bb2ff846f24fa6efee756e5e2a2b8433d65671e Mon Sep 17 00:00:00 2001 From: Fenghua Yu Date: Tue, 21 May 2013 15:35:17 -0400 Subject: x86 thermal: Disable power limit notification interrupt by default The package power limit notification interrupt is primarily for system diagnosis, and should not be blindly enabled on every system by default -- particuarly since Linux does nothing in the handler except count how many times it has been called... Add a new kernel cmdline parameter "int_pln_enable" for situations where users want to oberve these events via existing system counters: $ grep TRM /proc/interrupts $ grep . /sys/devices/system/cpu/cpu*/thermal_throttle/* https://bugzilla.kernel.org/show_bug.cgi?id=36182 Signed-off-by: Fenghua Yu Signed-off-by: Len Brown Signed-off-by: Tony Luck --- Documentation/kernel-parameters.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 6e3b18a..a7a1f34 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1158,6 +1158,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver Format: + int_pln_enable [x86] Enable power limit notification interrupt + intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option on Enable intel iommu driver. -- cgit v1.1 From 560746eb79d3124a278452c8dd968682b521cc82 Mon Sep 17 00:00:00 2001 From: Tony Prisk Date: Sat, 15 Jun 2013 09:52:16 +1200 Subject: i2c: vt8500: Add support for I2C bus on Wondermedia SoCs This patch adds support for the I2C bus controllers found on Wondermedia 8xxx-series SoCs. Only master-mode is supported. Signed-off-by: Tony Prisk [wsa: fixed one macro to shift 8 instead of 16] Signed-off-by: Wolfram Sang --- .../devicetree/bindings/i2c/i2c-vt8500.txt | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-vt8500.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt b/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt new file mode 100644 index 0000000..94a425e --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt @@ -0,0 +1,24 @@ +* Wondermedia I2C Controller + +Required properties : + + - compatible : should be "wm,wm8505-i2c" + - reg : Offset and length of the register set for the device + - interrupts : where IRQ is the interrupt number + - clocks : phandle to the I2C clock source + +Optional properties : + + - clock-frequency : desired I2C bus clock frequency in Hz. + Valid values are 100000 and 400000. + Default to 100000 if not specified, or invalid value. + +Example : + + i2c_0: i2c@d8280000 { + compatible = "wm,wm8505-i2c"; + reg = <0xd8280000 0x1000>; + interrupts = <19>; + clocks = <&clki2c0>; + clock-frequency = <400000>; + }; -- cgit v1.1 From f55b2b56cd37fa8bcfcb75248c27094eaf09e04c Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 1 Mar 2013 02:20:55 +0100 Subject: ARM: integrator: basic PCIv3 device tree support This registers the memory ranges for I/O, non-prefetched and prefetched memory and configuration space for the PCIv3 bridge and let us fetch these basic memory resources from the device tree in the device tree boot path. Remove the stepping stone platform device. This is an either/or approach - the platform data path is mutually exclusive to the plain platform data path and provided addresses from the device tree have to be correct. This adds the interrupt-map property to the PCIv3 DTS file and makes the bridge obtain mappings from the device tree. Acked-by: Arnd Bergmann Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt | 15 +++++++++++++++ Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 2 files changed, 16 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt (limited to 'Documentation') 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 0000000..30b364e --- /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/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 6931c43..d247d10 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -59,6 +59,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. -- cgit v1.1 From bbd7b275dbc24cc712b6bbc0f5211e9a9791dd89 Mon Sep 17 00:00:00 2001 From: Sebastian Hesselbarth Date: Tue, 7 May 2013 01:36:08 +0200 Subject: pinctrl: dove: add PMU functions to pinctrl Dove power management unit can mux some special functions to mpp0-15. This patch adds support to set/get the current PMU function mapped to the corresponding mpp pins. The device tree documentation is also updated accordingly. Signed-off-by: Sebastian Hesselbarth Acked-by: Jason Cooper Signed-off-by: Linus Walleij --- .../bindings/pinctrl/marvell,dove-pinctrl.txt | 49 +++++++++++++++------- 1 file changed, 33 insertions(+), 16 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt index a648aaa..50ec351 100644 --- a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt @@ -10,29 +10,31 @@ Required properties: Available mpp pins/groups and functions: Note: brackets (x) are not part of the mpp name for marvell,function and given only for more detailed description in this document. +Note: pmu* also allows for Power Management functions listed below name pins functions ================================================================================ -mpp0 0 gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm) -mpp1 1 gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm) +mpp0 0 gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm), pmu* +mpp1 1 gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm), pmu* mpp2 2 gpio, pmu, uart2(txd), sdio0(buspwr), sata(prsnt), - uart1(rts) + uart1(rts), pmu* mpp3 3 gpio, pmu, uart2(rxd), sdio0(ledctrl), sata(act), - uart1(cts), lcd-spi(cs1) -mpp4 4 gpio, pmu, uart3(rts), sdio1(cd), spi1(miso) -mpp5 5 gpio, pmu, uart3(cts), sdio1(wp), spi1(cs) -mpp6 6 gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi) -mpp7 7 gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck) -mpp8 8 gpio, pmu, watchdog(rstout) -mpp9 9 gpio, pmu, pex1(clkreq) -mpp10 10 gpio, pmu, ssp(sclk) + uart1(cts), lcd-spi(cs1), pmu* +mpp4 4 gpio, pmu, uart3(rts), sdio1(cd), spi1(miso), pmu* +mpp5 5 gpio, pmu, uart3(cts), sdio1(wp), spi1(cs), pmu* +mpp6 6 gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi), pmu* +mpp7 7 gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck), pmu* +mpp8 8 gpio, pmu, watchdog(rstout), pmu* +mpp9 9 gpio, pmu, pex1(clkreq), pmu* +mpp10 10 gpio, pmu, ssp(sclk), pmu* mpp11 11 gpio, pmu, sata(prsnt), sata-1(act), sdio0(ledctrl), - sdio1(ledctrl), pex0(clkreq) -mpp12 12 gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd), sata(act) + sdio1(ledctrl), pex0(clkreq), pmu* +mpp12 12 gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd), + sata(act), pmu* mpp13 13 gpio, pmu, uart2(cts), audio1(extclk), sdio1(wp), - ssp(extclk) -mpp14 14 gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd) -mpp15 15 gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm) + ssp(extclk), pmu* +mpp14 14 gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd), pmu* +mpp15 15 gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm), pmu* mpp16 16 gpio, uart3(rts), sdio0(cd), ac97(sdi1), lcd-spi(cs1) mpp17 17 gpio, uart3(cts), sdio0(wp), ac97(sdi2), twsi(sda), ac97-1(sysclko) @@ -57,6 +59,21 @@ mpp_nand 64-71 gpo, nand audio0 - i2s, ac97 twsi - none, opt1, opt2, opt3 +Power Management functions (pmu*): +pmu-nc Pin not driven by any PM function +pmu-low Pin driven low (0) +pmu-high Pin driven high (1) +pmic(sdi) Pin is used for PMIC SDI +cpu-pwr-down Pin is used for CPU_PWRDWN +standby-pwr-down Pin is used for STBY_PWRDWN +core-pwr-good Pin is used for CORE_PWR_GOOD (Pins 0-7 only) +cpu-pwr-good Pin is used for CPU_PWR_GOOD (Pins 8-15 only) +bat-fault Pin is used for BATTERY_FAULT +ext0-wakeup Pin is used for EXT0_WU +ext1-wakeup Pin is used for EXT0_WU +ext2-wakeup Pin is used for EXT0_WU +pmu-blink Pin is used for blink function + Notes: * group "mpp_audio1" allows the following functions and gpio pins: - gpio : gpio on pins 52-57 -- cgit v1.1 From 7bbc87b801fcaa817d828fdaa0ca8c6d223a1347 Mon Sep 17 00:00:00 2001 From: James Hogan Date: Tue, 28 May 2013 10:31:48 +0100 Subject: Documentation/pinctrl.txt: fix typo "with with" Fix typo in "communicate directly with with the pinctrl subsystem". Signed-off-by: James Hogan Cc: Linus Walleij Acked-by: Rob Landley Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 447fd4c..f6e664b 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -1226,8 +1226,8 @@ setting up the config and muxing for the pins right before the device is probing, nevertheless orthogonal to the GPIO subsystem. But there are also situations where it makes sense for the GPIO subsystem -to communicate directly with with the pinctrl subsystem, using the latter -as a back-end. This is when the GPIO driver may call out to the functions +to communicate directly with the pinctrl subsystem, using the latter as a +back-end. This is when the GPIO driver may call out to the functions described in the section "Pin control interaction with the GPIO subsystem" above. This only involves per-pin multiplexing, and will be completely hidden behind the gpio_*() function namespace. In this case, the driver -- cgit v1.1 From 78bafc66180d42f972b443b0b573a1b6ff9aa522 Mon Sep 17 00:00:00 2001 From: Jingchang Lu Date: Tue, 28 May 2013 17:32:08 +0800 Subject: pinctrl: add VF610 pinctrl driver Adds Freescale Vybrid VF610 pin controller driver to IMX common pinctrl driver framework. Signed-off-by: Jingchang Lu Acked-by: Shawn Guo Signed-off-by: Linus Walleij --- .../bindings/pinctrl/fsl,vf610-pinctrl.txt | 41 ++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt new file mode 100644 index 0000000..ddcdeb6 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt @@ -0,0 +1,41 @@ +Freescale Vybrid VF610 IOMUX Controller + +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part +and usage. + +Required properties: +- compatible: "fsl,vf610-iomuxc" +- fsl,pins: two integers array, represents a group of pins mux and config + setting. The format is fsl,pins = , PIN_FUNC_ID is + a pin working on a specific function, CONFIG is the pad setting value + such as pull-up, speed, ode for this pin. Please refer to Vybrid VF610 + datasheet for the valid pad config settings. + +CONFIG bits definition: +PAD_CTL_SPEED_LOW (1 << 12) +PAD_CTL_SPEED_MED (2 << 12) +PAD_CTL_SPEED_HIGH (3 << 12) +PAD_CTL_SRE_FAST (1 << 11) +PAD_CTL_SRE_SLOW (0 << 11) +PAD_CTL_ODE (1 << 10) +PAD_CTL_HYS (1 << 9) +PAD_CTL_DSE_DISABLE (0 << 6) +PAD_CTL_DSE_150ohm (1 << 6) +PAD_CTL_DSE_75ohm (2 << 6) +PAD_CTL_DSE_50ohm (3 << 6) +PAD_CTL_DSE_37ohm (4 << 6) +PAD_CTL_DSE_30ohm (5 << 6) +PAD_CTL_DSE_25ohm (6 << 6) +PAD_CTL_DSE_20ohm (7 << 6) +PAD_CTL_PUS_100K_DOWN (0 << 4) +PAD_CTL_PUS_47K_UP (1 << 4) +PAD_CTL_PUS_100K_UP (2 << 4) +PAD_CTL_PUS_22K_UP (3 << 4) +PAD_CTL_PKE (1 << 3) +PAD_CTL_PUE (1 << 2) +PAD_CTL_OBE_ENABLE (1 << 1) +PAD_CTL_IBE_ENABLE (1 << 0) +PAD_CTL_OBE_IBE_ENABLE (3 << 0) + +Please refer to vf610-pinfunc.h in device tree source folder +for all available PIN_FUNC_ID for Vybrid VF610. -- cgit v1.1 From 4e7e8017a80e1810100c9b416b86e3baef900285 Mon Sep 17 00:00:00 2001 From: "Manjunathappa, Prakash" Date: Tue, 21 May 2013 19:38:00 +0530 Subject: pinctrl: pinctrl-single: enhance to configure multiple pins of different modules Add support to configure multiple pins in each register, existing implementation added by [1] does not support full fledge multiple pin configuration in single register, reports a pin clash when different modules configure different bits of same register. The issue reported and discussed here http://www.spinics.net/lists/arm-kernel/msg235213.html With pinctrl-single,bits-per-mux property specified, use function-mask property to find out number pins to configure. Allocate and register pin control functions based sub mask. Tested on da850/omap-l138 EVM. does not support variable submask for pins. does not support pinconf. [1] "pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux" (9e605cb68a21d5704839a192a46ebcf387773704), Signed-off-by: Manjunathappa, Prakash Reported-by: Lad, Prabhakar Tested-by: Lad, Prabhakar Acked-by: Haojian Zhuang Acked-by: Tony Lindgren Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt index 08f0c3d..5a02e30 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt @@ -18,7 +18,8 @@ Optional properties: pin functions is ignored - pinctrl-single,bit-per-mux : boolean to indicate that one register controls - more than one pin + more than one pin, for which "pinctrl-single,function-mask" property specifies + position mask of pin. - pinctrl-single,drive-strength : array of value that are used to configure drive strength in the pinmux register. They're value of drive strength -- cgit v1.1 From 7db9af4b6e41be599e0fcd50d687138a5add428c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Mon, 10 Jun 2013 21:40:29 +0200 Subject: pinctrl: add function to parse generic pinconfig properties from a dt node pinconf_generic_parse_dt_config() takes a node as input and generates an array of generic pinconfig values from the properties of this node. As I couldn't find a mechanism to count the number of properties of a node the function uses internally an array to accept one of parameter and copies the real present options to a smaller variable at its end. Signed-off-by: Heiko Stuebner Signed-off-by: Linus Walleij --- .../bindings/pinctrl/pinctrl-bindings.txt | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index c95ea82..ef7cd57 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -126,3 +126,41 @@ device; they may be grandchildren, for example. Whether this is legal, and whether there is any interaction between the child and intermediate parent nodes, is again defined entirely by the binding for the individual pin controller device. + +== Using generic pinconfig options == + +Generic pinconfig parameters can be used by defining a separate node containing +the applicable parameters (and optional values), like: + +pcfg_pull_up: pcfg_pull_up { + bias-pull-up; + drive-strength = <20>; +}; + +This node should then be referenced in the appropriate pinctrl node as a phandle +and parsed in the driver using the pinconf_generic_parse_dt_config function. + +Supported configuration parameters are: + +bias-disable - disable any pin bias +bias-high-impedance - high impedance mode ("third-state", "floating") +bias-bus-hold - latch weakly +bias-pull-up - pull up the pin +bias-pull-down - pull down the pin +bias-pull-pin-default - use pin-default pull state +drive-push-pull - drive actively high and low +drive-open-drain - drive with open drain +drive-open-source - drive with open source +drive-strength - sink or source at most X mA +input-schmitt-enable - enable schmitt-trigger mode +input-schmitt-disable - disable schmitt-trigger mode +input-schmitt - run in schmitt-trigger mode with hysteresis X +input-debounce - debounce mode with debound time X +power-source - select power source X +slew-rate - use slew-rate X +low-power-mode - low power mode +output-low - set the pin to output mode with low level +output-high - set the pin to output mode with high level + +More in-depth documentation on these parameters can be found in + -- cgit v1.1 From d3e5116119bd02ea7716bbe04b39c21bba4bcf42 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Mon, 10 Jun 2013 22:16:22 +0200 Subject: pinctrl: add pinctrl driver for Rockchip SoCs This driver adds support the Cortex-A9 based SoCs from Rockchip, so at least the RK2928, RK3066 (a and b) and RK3188. Earlier Rockchip SoCs seem to use similar mechanics for gpio handling so should be supportable with relative small changes. Pull handling on the rk3188 is currently a stub, due to it being a bit different to the earlier SoCs. Pinmuxing as well as gpio (and interrupt-) handling tested on a rk3066a based machine. Signed-off-by: Heiko Stuebner Signed-off-by: Linus Walleij --- .../bindings/pinctrl/rockchip,pinctrl.txt | 97 ++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt new file mode 100644 index 0000000..b0fb101 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt @@ -0,0 +1,97 @@ +* Rockchip Pinmux Controller + +The Rockchip Pinmux Controller, enables the IC +to share one PAD to several functional blocks. The sharing is done by +multiplexing the PAD input/output signals. For each PAD there are up to +4 muxing options with option 0 being the use as a GPIO. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The Rockchip pin configuration node is a node of a group of pins which can be +used for a specific device or function. This node represents both mux and +config of the pins in that group. The 'pins' selects the function mode(also +named pin mode) this pin can work on and the 'config' configures various pad +settings such as pull-up, etc. + +The pins are grouped into up to 5 individual pin banks which need to be +defined as gpio sub-nodes of the pinmux controller. + +Required properties for iomux controller: + - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl" + "rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl" + +Required properties for gpio sub nodes: + - compatible: "rockchip,gpio-bank" + - reg: register of the gpio bank (different than the iomux registerset) + - interrupts: base interrupt of the gpio bank in the interrupt controller + - clocks: clock that drives this bank + - gpio-controller: identifies the node as a gpio controller and pin bank. + - #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. + - interrupt-controller: identifies the controller node as interrupt-parent. + - #interrupt-cells: the value of this property should be 2 and the interrupt + cells should use the standard two-cell scheme described in + bindings/interrupt-controller/interrupts.txt + +Required properties for pin configuration node: + - rockchip,pins: 3 integers array, represents a group of pins mux and config + setting. The format is rockchip,pins = . + The MUX 0 means gpio and MUX 1 to 3 mean the specific device function. + The phandle of a node containing the generic pinconfig options + to use, as described in pinctrl-bindings.txt in this directory. + +Examples: + +#include + +... + +pinctrl@20008000 { + compatible = "rockchip,rk3066a-pinctrl"; + reg = <0x20008000 0x150>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + gpio0: gpio0@20034000 { + compatible = "rockchip,gpio-bank"; + reg = <0x20034000 0x100>; + interrupts = ; + clocks = <&clk_gates8 9>; + + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + + ... + + pcfg_pull_default: pcfg_pull_default { + bias-pull-pin-default + }; + + uart2 { + uart2_xfer: uart2-xfer { + rockchip,pins = , + ; + }; + }; +}; + +uart2: serial@20064000 { + compatible = "snps,dw-apb-uart"; + reg = <0x20064000 0x400>; + interrupts = ; + reg-shift = <2>; + reg-io-width = <1>; + clocks = <&mux_uart2>; + status = "okay"; + + pinctrl-names = "default"; + pinctrl-0 = <&uart2_xfer>; +}; -- cgit v1.1 From 81265dfb1ccba0941e54a61c2473befe8c09edc0 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Sun, 9 Jun 2013 09:40:05 +0200 Subject: ARM: sunxi: Add Allwinner A10s machine compatible The A10s is a SoC member of the Allwinner sun5i family. It is basically an A13 with an EMAC and an HDMI controller. Signed-off-by: Maxime Ripard --- Documentation/arm/sunxi/README | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README index d9a372d..e3f93fb 100644 --- a/Documentation/arm/sunxi/README +++ b/Documentation/arm/sunxi/README @@ -17,6 +17,10 @@ SunXi family + User Manual http://dl.linux-sunxi.org/A10/A10%20User%20Manual%20-%20v1.20%20%282012-04-09%2c%20DECRYPTED%29.pdf + - Allwinner A10s (sun5i) + + Datasheet + http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf + - Allwinner A13 (sun5i) + Datasheet http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf -- cgit v1.1 From 6090a0fa5cefe6cc0aa95786b21dcf1bf19942da Mon Sep 17 00:00:00 2001 From: Michal Simek Date: Mon, 3 Jun 2013 14:31:21 +0200 Subject: DT: Add documentation for gpio-xilinx Describe gpio-xilinx binding. Signed-off-by: Michal Simek Signed-off-by: Linus Walleij --- .../devicetree/bindings/gpio/gpio-xilinx.txt | 48 ++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-xilinx.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt new file mode 100644 index 0000000..63bf4be --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt @@ -0,0 +1,48 @@ +Xilinx plb/axi GPIO controller + +Dual channel GPIO controller with configurable number of pins +(from 1 to 32 per channel). Every pin can be configured as +input/output/tristate. Both channels share the same global IRQ but +local interrupts can be enabled on channel basis. + +Required properties: +- compatible : Should be "xlnx,xps-gpio-1.00.a" +- reg : Address and length of the register set for the device +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters (currently unused). +- gpio-controller : Marks the device node as a GPIO controller. + +Optional properties: +- interrupts : Interrupt mapping for GPIO IRQ. +- interrupt-parent : Phandle for the interrupt controller that + services interrupts for this device. +- xlnx,all-inputs : if n-th bit is setup, GPIO-n is input +- xlnx,dout-default : if n-th bit is 1, GPIO-n default value is 1 +- xlnx,gpio-width : gpio width +- xlnx,tri-default : if n-th bit is 1, GPIO-n is in tristate mode +- xlnx,is-dual : if 1, controller also uses the second channel +- xlnx,all-inputs-2 : as above but for the second channel +- xlnx,dout-default-2 : as above but the second channel +- xlnx,gpio2-width : as above but for the second channel +- xlnx,tri-default-2 : as above but for the second channel + + +Example: +gpio: gpio@40000000 { + #gpio-cells = <2>; + compatible = "xlnx,xps-gpio-1.00.a"; + gpio-controller ; + interrupt-parent = <µblaze_0_intc>; + interrupts = < 6 2 >; + reg = < 0x40000000 0x10000 >; + xlnx,all-inputs = <0x0>; + xlnx,all-inputs-2 = <0x0>; + xlnx,dout-default = <0x0>; + xlnx,dout-default-2 = <0x0>; + xlnx,gpio-width = <0x2>; + xlnx,gpio2-width = <0x2>; + xlnx,interrupt-present = <0x1>; + xlnx,is-dual = <0x1>; + xlnx,tri-default = <0xffffffff>; + xlnx,tri-default-2 = <0xffffffff>; +} ; -- cgit v1.1 From 45fe6810347b0a83561a13d9ee656c899a309fc0 Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Fri, 3 May 2013 11:06:46 +0800 Subject: ARM: imx: add clock support for imx6sl Add clock support for i.MX6 SoloLite. It uses the dtc marco support to define all clock IDs in imx6sl-clock.h, which will be included by both clock driver and device tree sources, so that the data will stay sync all the time between kernel and DT. Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/clock/imx6sl-clock.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/imx6sl-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/imx6sl-clock.txt b/Documentation/devicetree/bindings/clock/imx6sl-clock.txt new file mode 100644 index 0000000..15e40bd --- /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. -- cgit v1.1 From 9545b2ed68eef1541219d5c6351c10e698a24f39 Mon Sep 17 00:00:00 2001 From: Huang Shijie Date: Fri, 17 May 2013 17:15:23 +0800 Subject: ARM: imx6q: clk: add the eim_slow clock Add the eim_slow clock, since the weim needs it. Signed-off-by: Huang Shijie Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/clock/imx6q-clock.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index 6deb6fd..a0e104f 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: -- cgit v1.1 From c9a74f556987ff696da3050ad66595458ad649c6 Mon Sep 17 00:00:00 2001 From: Sascha Hauer Date: Fri, 17 May 2013 15:49:02 +0200 Subject: ARM i.MX53: Add SATA clock Signed-off-by: Sascha Hauer Signed-off-by: Philipp Zabel Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/clock/imx5-clock.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt index d71b4b2..b66cf36 100644 --- a/Documentation/devicetree/bindings/clock/imx5-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt @@ -184,6 +184,7 @@ clocks and IDs. cko2 170 srtc_gate 171 pata_gate 172 + sata_gate 173 Examples (for mx53): -- cgit v1.1 From beb2d1c1ba8bcbb31cc15875f65bcff0b2f79f64 Mon Sep 17 00:00:00 2001 From: Philipp Zabel Date: Fri, 17 May 2013 15:49:03 +0200 Subject: ARM i.MX5: Add S/PDIF clocks This patch adds the S/PDIF clocks for i.MX51 and i.MX53. Tested on i.MX53. The i.MX51 has a second set of spdif_root clock dividers, and on i.MX53 there is an additional input to the spdif_xtal mux. Signed-off-by: Philipp Zabel Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/clock/imx5-clock.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt index b66cf36..f46f562 100644 --- a/Documentation/devicetree/bindings/clock/imx5-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt @@ -185,6 +185,18 @@ clocks and IDs. 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): -- cgit v1.1 From 1f2c5fd5f0486566f73aa0149577d5f69df90bcc Mon Sep 17 00:00:00 2001 From: Jingchang Lu Date: Tue, 28 May 2013 17:12:20 +0800 Subject: ARM: imx: add VF610 clock support Add clock support for Vybrid VF610. It uses dtc macro support to define all clock IDs in vf610-clock.h to keep clock IDs coherence between kernel and DT. Signed-off-by: Jingchang Lu Signed-off-by: Shawn Guo --- .../devicetree/bindings/clock/vf610-clock.txt | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/vf610-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/vf610-clock.txt b/Documentation/devicetree/bindings/clock/vf610-clock.txt new file mode 100644 index 0000000..c80863d --- /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"; +}; -- cgit v1.1 From a04ad043d5139f262005ee728aa1a13a563f5eef Mon Sep 17 00:00:00 2001 From: Dirk Behme Date: Thu, 16 May 2013 08:51:34 +0200 Subject: i.MX6: Documentation: update from fsl,card-wired to non-removable With the commit 7f217794f (mmc: dt: Consolidate DT bindings), the device tree properties used by various device drivers for SD/MMC host controllers were standardized. One of the changes was that the property "fsl,card-wired", previously used by the Freescale driver, was replaced with "non-removable". Fix the example documentation regarding this. Signed-off-by: Dirk Behme Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt index bcfdab5..3a7caf7 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"; -- cgit v1.1 From 85bf6d4e4b100efda8169f6f98fd65d0029c7813 Mon Sep 17 00:00:00 2001 From: Huang Shijie Date: Tue, 28 May 2013 14:20:07 +0800 Subject: drivers: bus: add a new driver for WEIM The WEIM(Wireless External Interface Module) works like a bus. You can attach many different devices on it, such as NOR, onenand. In the case of i.MX6q-sabreauto, the NOR is connected to WEIM. This patch also adds the devicetree binding document. The driver only works when the devicetree is enabled. Signed-off-by: Huang Shijie Acked-by: Sascha Hauer Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/bus/imx-weim.txt | 49 ++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/bus/imx-weim.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt new file mode 100644 index 0000000..cedc2a9 --- /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: + + 0 + +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>; + }; + }; -- cgit v1.1 From e32aa85ab49203104019025eba83f03f88a3a0e3 Mon Sep 17 00:00:00 2001 From: David Henningsson Date: Mon, 17 Jun 2013 11:04:02 +0200 Subject: ALSA: hda - Add models for Dell headset jacks These headset jacks keep coming in on more and more platforms, and it's possible I don't catch them all. Make it easier to test and verify by making models. Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index bb8b0dc..77d68e2 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -29,6 +29,8 @@ ALC269/270/275/276/280/282 alc271-dmic Enable ALC271X digital mic workaround inv-dmic Inverted internal mic workaround lenovo-dock Enables docking station I/O for some Lenovos + dell-headset-multi Headset jack, which can also be used as mic-in + dell-headset-dock Headset jack (without mic-in), and also dock I/O ALC662/663/272 ============== @@ -42,6 +44,7 @@ ALC662/663/272 asus-mode7 ASUS asus-mode8 ASUS inv-dmic Inverted internal mic workaround + dell-headset-multi Headset jack, which can also be used as mic-in ALC680 ====== -- cgit v1.1 From 4cf4f4b4c16e8faf740295ed02ac2f48fda5a8b8 Mon Sep 17 00:00:00 2001 From: David Henningsson Date: Mon, 17 Jun 2013 11:04:03 +0200 Subject: ALSA: hda - Update HD-Audio-Models.txt Add new known codecs, and fix up tabs. Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 40 ++++++++++++++-------------- 1 file changed, 20 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 77d68e2..809d72b 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -21,41 +21,41 @@ ALC267/268 ========== inv-dmic Inverted internal mic workaround -ALC269/270/275/276/280/282 +ALC269/270/275/276/28x/29x ====== - laptop-amic Laptops with analog-mic input - laptop-dmic Laptops with digital-mic input - alc269-dmic Enable ALC269(VA) digital mic workaround - alc271-dmic Enable ALC271X digital mic workaround - inv-dmic Inverted internal mic workaround - lenovo-dock Enables docking station I/O for some Lenovos + laptop-amic Laptops with analog-mic input + laptop-dmic Laptops with digital-mic input + alc269-dmic Enable ALC269(VA) digital mic workaround + alc271-dmic Enable ALC271X digital mic workaround + inv-dmic Inverted internal mic workaround + lenovo-dock Enables docking station I/O for some Lenovos dell-headset-multi Headset jack, which can also be used as mic-in dell-headset-dock Headset jack (without mic-in), and also dock I/O -ALC662/663/272 +ALC66x/67x/892 ============== - mario Chromebook mario model fixup - asus-mode1 ASUS - asus-mode2 ASUS - asus-mode3 ASUS - asus-mode4 ASUS - asus-mode5 ASUS - asus-mode6 ASUS - asus-mode7 ASUS - asus-mode8 ASUS - inv-dmic Inverted internal mic workaround + mario Chromebook mario model fixup + asus-mode1 ASUS + asus-mode2 ASUS + asus-mode3 ASUS + asus-mode4 ASUS + asus-mode5 ASUS + asus-mode6 ASUS + asus-mode7 ASUS + asus-mode8 ASUS + inv-dmic Inverted internal mic workaround dell-headset-multi Headset jack, which can also be used as mic-in ALC680 ====== N/A -ALC882/883/885/888/889 +ALC88x/898/1150 ====================== acer-aspire-4930g Acer Aspire 4930G/5930G/6530G/6930G/7730G acer-aspire-8930g Acer Aspire 8330G/6935G acer-aspire Acer Aspire others - inv-dmic Inverted internal mic workaround + inv-dmic Inverted internal mic workaround no-primary-hp VAIO Z/VGC-LN51JGB workaround (for fixed speaker DAC) ALC861/660 -- cgit v1.1 From 4d3ab5ec205472c79a6efb4be6fdf4817f0405e2 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 19 Apr 2013 10:50:42 +0200 Subject: ARM: u300: set up board power from device tree This adds support for setting up the board power from the device tree on the U300. We use a board-specific node in the device tree for the S365 board and bind a regulator for the board power to this node. Cc: Mark Brown Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/arm/ste-u300.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/ste-u300.txt b/Documentation/devicetree/bindings/arm/ste-u300.txt index 222dca5..cd9001a 100644 --- a/Documentation/devicetree/bindings/arm/ste-u300.txt +++ b/Documentation/devicetree/bindings/arm/ste-u300.txt @@ -7,3 +7,16 @@ or board power regulator supplies. Required root node property: compatible="stericsson,u300"; + +Boards with the U300 SoC include: + +S365 "Small Board U365": + +Required node: s365 + +Example: + +s365 { + compatible = "stericsson,s365"; + vana15-supply = <&ab3100_ldo_d_reg>; +}; -- cgit v1.1 From faadc6e3d5e0ab718dc1e131fb14bbb52f144238 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 19 Apr 2013 13:42:55 +0200 Subject: dma: coh901318: add devicetree support This adds support for probing the COH 901 318 DMA controller and channels from the device tree. Contains portions of a sketch patch from Arnd Bergmann. Cc: Arnd Bergmann Acked-by: Vinod Koul Signed-off-by: Linus Walleij --- .../devicetree/bindings/dma/ste-coh901318.txt | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/ste-coh901318.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/ste-coh901318.txt b/Documentation/devicetree/bindings/dma/ste-coh901318.txt new file mode 100644 index 0000000..091ad05 --- /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"; +}; -- cgit v1.1 From cf0ce095c932becf48ed794ecdfad925e931dc9c Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Wed, 22 May 2013 16:15:13 +0200 Subject: ARM: u300: add syscon node This adds a device tree node for the U300 system controller and remaps this dynamically instead of using hard-coded virtual addresses. The board power set-up code is altered to fetch a reference to the syscon using ampersand <&syscon> notation. This way of passing a pointer to the syscon will also be used by the clocks. Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/arm/ste-u300.txt | 30 +++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/ste-u300.txt b/Documentation/devicetree/bindings/arm/ste-u300.txt index cd9001a..69b5ab0 100644 --- a/Documentation/devicetree/bindings/arm/ste-u300.txt +++ b/Documentation/devicetree/bindings/arm/ste-u300.txt @@ -8,15 +8,39 @@ 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: -s365 { - compatible = "stericsson,s365"; - vana15-supply = <&ab3100_ldo_d_reg>; +/ { + 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>; + }; }; -- cgit v1.1 From bba5f2cc2f0fe4191ad2699c7c03a6def31f54e2 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 23 May 2013 15:42:33 +0200 Subject: ARM: u300: move the gated system controller clocks to DT This moves the slow, fast, AHB bridge and "rest" clocks on the U300 system controller over to registration from the device tree. Acked-by: Mike Turquette Signed-off-by: Linus Walleij --- .../bindings/clock/ste-u300-syscon-clock.txt | 57 ++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt (limited to 'Documentation') 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 0000000..b6a30f5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt @@ -0,0 +1,57 @@ +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>; +}; -- cgit v1.1 From 85fb28bed813469ba56706a7e48fba596f47c253 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 23 May 2013 19:18:28 +0200 Subject: ARM: u300: convert MMC/SD clock to device tree This converts the last of the U300 clocks to being probed from the device tree. Acked-by: Mike Turquette Signed-off-by: Linus Walleij --- .../bindings/clock/ste-u300-syscon-clock.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt b/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt index b6a30f5..7cafcb9 100644 --- a/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt +++ b/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt @@ -55,3 +55,26 @@ gpio: gpio@c0016000 { (...) 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"; + (...) +}; -- cgit v1.1 From 696c018c7718f5e33e1107da19c4d64a25018878 Mon Sep 17 00:00:00 2001 From: Namjae Jeon Date: Sun, 16 Jun 2013 09:48:48 +0900 Subject: f2fs: add remount_fs callback support Add the f2fs_remount function call which will be used during the filesystem remounting. This function will help us to change the mount options specific to f2fs. Also modify the f2fs background_gc mount option, which will allow the user to dynamically trun on/off the garbage collection in f2fs based on the background_gc value. If background_gc=on, Garbage collection will be turned off & if background_gc=off, Garbage collection will be truned on. By default the garbage collection is on in f2fs. Change Log: v2: Incorporated the review comments by Gu Zheng. Removing the restore part for VFS flags Updating comments with proper flag conditions Display GC background option as ON/OFF Revised conditions to stop GC in case of remount v1: Initial changes for adding remount_fs callback support. Cc: Gu Zheng Signed-off-by: Namjae Jeon Signed-off-by: Pankaj Kumar Reviewed-by: Gu Zheng [Jaegeuk Kim: change /** with /* for the coding style] Signed-off-by: Jaegeuk Kim --- Documentation/filesystems/f2fs.txt | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index bd3c56c..b91e2f2 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 -- cgit v1.1 From abbec2d401d6698db44e632f5adbef2a47e6e812 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 29 May 2013 07:00:11 -0300 Subject: [media] DocBook/media/v4l: update VIDIOC_DBG_ documentation - Remove the "On failure the structure remains unchanged." part since that isn't necessarily true. - Document the 'size' field. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../DocBook/media/v4l/vidioc-dbg-g-chip-info.xml | 3 +-- Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml | 15 ++++++++++----- 2 files changed, 11 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml index e1cece6..80e8021 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml @@ -73,8 +73,7 @@ fields of a &v4l2-dbg-chip-info; and call VIDIOC_DBG_G_CHIP_INFO with a pointer to this structure. On success the driver stores information about the selected chip in the name and -flags fields. On failure the structure -remains unchanged. +flags fields. When match.type is V4L2_CHIP_MATCH_BRIDGE, diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml index d13bac9..e23285f 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml @@ -76,7 +76,7 @@ compiled with the CONFIG_VIDEO_ADV_DEBUG option to enable these ioctls. To write a register applications must initialize all fields -of a &v4l2-dbg-register; and call +of a &v4l2-dbg-register; except for size and call VIDIOC_DBG_S_REGISTER with a pointer to this structure. The match.type and match.addr or match.name @@ -91,8 +91,8 @@ written into the register. reg fields, and call VIDIOC_DBG_G_REGISTER with a pointer to this structure. On success the driver stores the register value in the -val field. On failure the structure remains -unchanged. +val field and the size (in bytes) of the +value in size. When match.type is V4L2_CHIP_MATCH_BRIDGE, @@ -150,7 +150,7 @@ LinuxTV v4l-dvb repository; see http://linuxtv.org/repo/ for access instructions. - struct <structname>v4l2_dbg_match</structname> @@ -199,6 +199,11 @@ to the type field.How to match the chip, see . + __u32 + size + The register size in bytes. + + __u64 reg A register number. @@ -213,7 +218,7 @@ register.
- Chip Match Types -- cgit v1.1 From 2249aa5c97a017be4e3b5bb0e9a3ca2d2ed31b27 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 29 May 2013 07:59:57 -0300 Subject: [media] v4l2-framework: replace g_chip_ident by g_std in the examples The framework documentation used the g_chip_ident op as an example. This op has been removed, so replace its use in the examples by the g_std op. Signed-off-by: Hans Verkuil Cc: Mauro Carvalho Chehab Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 13 ++++++------- Documentation/zh_CN/video4linux/v4l2-framework.txt | 13 ++++++------- 2 files changed, 12 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index a300b28..24353eca 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -246,7 +246,6 @@ may be NULL if the subdev driver does not support anything from that category. It looks like this: struct v4l2_subdev_core_ops { - int (*g_chip_ident)(struct v4l2_subdev *sd, struct v4l2_dbg_chip_ident *chip); int (*log_status)(struct v4l2_subdev *sd); int (*init)(struct v4l2_subdev *sd, u32 val); ... @@ -346,24 +345,24 @@ Afterwards the subdev module can be unloaded and sd->dev == NULL. You can call an ops function either directly: - err = sd->ops->core->g_chip_ident(sd, &chip); + err = sd->ops->core->g_std(sd, &norm); but it is better and easier to use this macro: - err = v4l2_subdev_call(sd, core, g_chip_ident, &chip); + err = v4l2_subdev_call(sd, core, g_std, &norm); The macro will to the right NULL pointer checks and returns -ENODEV if subdev -is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_chip_ident is -NULL, or the actual result of the subdev->ops->core->g_chip_ident ops. +is NULL, -ENOIOCTLCMD if either subdev->core or subdev->core->g_std is +NULL, or the actual result of the subdev->ops->core->g_std ops. It is also possible to call all or a subset of the sub-devices: - v4l2_device_call_all(v4l2_dev, 0, core, g_chip_ident, &chip); + v4l2_device_call_all(v4l2_dev, 0, core, g_std, &norm); Any subdev that does not support this ops is skipped and error results are ignored. If you want to check for errors use this: - err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip); + err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_std, &norm); Any error except -ENOIOCTLCMD will exit the loop with that error. If no errors (except -ENOIOCTLCMD) occurred, then 0 is returned. diff --git a/Documentation/zh_CN/video4linux/v4l2-framework.txt b/Documentation/zh_CN/video4linux/v4l2-framework.txt index 44c1d93..0da95db 100644 --- a/Documentation/zh_CN/video4linux/v4l2-framework.txt +++ b/Documentation/zh_CN/video4linux/v4l2-framework.txt @@ -247,7 +247,6 @@ i2c_client 结构体，i2c_set_clientdata() 函数可用于保存一个 v4l2_sub 这些结构体定义如下： struct v4l2_subdev_core_ops { - int (*g_chip_ident)(struct v4l2_subdev *sd, struct v4l2_dbg_chip_ident *chip); int (*log_status)(struct v4l2_subdev *sd); int (*init)(struct v4l2_subdev *sd, u32 val); ... @@ -337,24 +336,24 @@ subdev->dev 域就指向了 v4l2_device。 注册之设备后，可通过以下方式直接调用其操作函数： - err = sd->ops->core->g_chip_ident(sd, &chip); + err = sd->ops->core->g_std(sd, &norm); 但使用如下宏会比较容易且合适： - err = v4l2_subdev_call(sd, core, g_chip_ident, &chip); + err = v4l2_subdev_call(sd, core, g_std, &norm); 这个宏将会做 NULL 指针检查，如果 subdev 为 NULL，则返回-ENODEV；如果 -subdev->core 或 subdev->core->g_chip_ident 为 NULL，则返回 -ENOIOCTLCMD； -否则将返回 subdev->ops->core->g_chip_ident ops 调用的实际结果。 +subdev->core 或 subdev->core->g_std 为 NULL，则返回 -ENOIOCTLCMD； +否则将返回 subdev->ops->core->g_std ops 调用的实际结果。 有时也可能同时调用所有或一系列子设备的某个操作函数： - v4l2_device_call_all(v4l2_dev, 0, core, g_chip_ident, &chip); + v4l2_device_call_all(v4l2_dev, 0, core, g_std, &norm); 任何不支持此操作的子设备都会被跳过，并忽略错误返回值。但如果你需要 检查出错码，则可使用如下函数： - err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip); + err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_std, &norm); 除 -ENOIOCTLCMD 外的任何错误都会跳出循环并返回错误值。如果（除 -ENOIOCTLCMD 外）没有错误发生，则返回 0。 -- cgit v1.1 From f41c4332cfeae59e78aeda6c4eb9d0f4d42adbf2 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 29 May 2013 10:19:05 -0300 Subject: [media] DocBook/media/v4l: clarify the QUERYSTD documentation Explicitly mention that this ioctl should return V4L2_STD_UNKNOWN if not signal was detected. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/vidioc-querystd.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/vidioc-querystd.xml b/Documentation/DocBook/media/v4l/vidioc-querystd.xml index fe80a18..2223485 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querystd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querystd.xml @@ -54,7 +54,8 @@ standard automatically. To do so, applications call VIDIOC_QUERYSTD with a pointer to a &v4l2-std-id; type. The driver stores here a set of candidates, this can be a single flag or a set of supported standards if for example the hardware can only -distinguish between 50 and 60 Hz systems. When detection is not +distinguish between 50 and 60 Hz systems. If no signal was detected, +then the driver will return V4L2_STD_UNKNOWN. When detection is not possible or fails, the set must contain all standards supported by the current video input or output. -- cgit v1.1 From 8d4da37c3006f30a7cf75cd7bb33b254afc30279 Mon Sep 17 00:00:00 2001 From: "Lad, Prabhakar" Date: Sun, 26 May 2013 10:08:54 -0300 Subject: [media] media: i2c: mt9p031: add OF support Add OF support for the mt9p031 sensor driver. Alongside this patch sorts the header inclusion alphabetically. Signed-off-by: Lad, Prabhakar Reviewed-by: Sascha Hauer Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/i2c/mt9p031.txt | 40 ++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/mt9p031.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/mt9p031.txt b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt new file mode 100644 index 0000000..cb60443 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt @@ -0,0 +1,40 @@ +* Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor + +The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor with +an active array size of 2592H x 1944V. It is programmable through a simple +two-wire serial interface. + +Required Properties: +- compatible: value should be either one among the following + (a) "aptina,mt9p031" for mt9p031 sensor + (b) "aptina,mt9p031m" for mt9p031m sensor + +- input-clock-frequency: Input clock frequency. + +- pixel-clock-frequency: Pixel clock frequency. + +Optional Properties: +- reset-gpios: Chip reset GPIO + +For further reading on port node refer to +Documentation/devicetree/bindings/media/video-interfaces.txt. + +Example: + + i2c0@1c22000 { + ... + ... + mt9p031@5d { + compatible = "aptina,mt9p031"; + reg = <0x5d>; + reset-gpios = <&gpio3 30 0>; + + port { + mt9p031_1: endpoint { + input-clock-frequency = <6000000>; + pixel-clock-frequency = <96000000>; + }; + }; + }; + ... + }; -- cgit v1.1 From 30cf821ea807018898c7c37a8168a705d49b333f Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sun, 16 Jun 2013 12:15:36 +0200 Subject: pinctrl: update GPIO range doc This updates the GPIO range documentation with the API changes for sparse/random/arbitrary pin-to-GPIO mappings. Reviewed-by: Christian Ruppert Acked-by: Rob Landley Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index f6e664b..3ee2475 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -350,6 +350,23 @@ chip b: - GPIO range : [48 .. 55] - pin range : [64 .. 71] +The above examples assume the mapping between the GPIOs and pins is +linear. If the mapping is sparse or haphazard, an array of arbitrary pin +numbers can be encoded in the range like this: + +static const unsigned range_pins[] = { 14, 1, 22, 17, 10, 8, 6, 2 }; + +static struct pinctrl_gpio_range gpio_range = { + .name = "chip", + .id = 0, + .base = 32, + .pins = &range_pins, + .npins = ARRAY_SIZE(range_pins), + .gc = &chip; +}; + +In this case the pin_base property will be ignored. + When GPIO-specific functions in the pin control subsystem are called, these ranges will be used to look up the appropriate pin controller by inspecting and matching the pin to the pin ranges across all controllers. When a @@ -357,9 +374,9 @@ pin controller handling the matching range is found, GPIO-specific functions will be called on that specific pin controller. For all functionalities dealing with pin biasing, pin muxing etc, the pin -controller subsystem will subtract the range's .base offset from the passed -in gpio number, and add the ranges's .pin_base offset to retrive a pin number. -After that, the subsystem passes it on to the pin control driver, so the driver +controller subsystem will look up the corresponding pin number from the passed +in gpio number, and use the range's internals to retrive a pin number. After +that, the subsystem passes it on to the pin control driver, so the driver will get an pin number into its handled number range. Further it is also passed the range ID value, so that the pin controller knows which range it should deal with. @@ -368,6 +385,7 @@ Calling pinctrl_add_gpio_range from pinctrl driver is DEPRECATED. Please see section 2.1 of Documentation/devicetree/bindings/gpio/gpio.txt on how to bind pinctrl and gpio drivers. + PINMUX interfaces ================= -- cgit v1.1 From 9ee1f7d266aa1e2bfeb20cb5d4ac299c8e8ef8c7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Fri, 14 Jun 2013 17:42:49 +0200 Subject: pinctrl: clarify some dt pinconfig options The bias-pull-* options use values > 0 to indicate that the pull should be activated and optionally also indicate the strength of the pull. Therefore use an default value of 1 for these options. Split the low-power-mode option into low-power-enable and -disable. Update the documentation to describe the param arguments better. Reported-by: James Hogan Signed-off-by: Heiko Stuebner Signed-off-by: Linus Walleij --- .../bindings/pinctrl/pinctrl-bindings.txt | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index ef7cd57..2d730e3 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -158,9 +158,29 @@ input-schmitt - run in schmitt-trigger mode with hysteresis X input-debounce - debounce mode with debound time X power-source - select power source X slew-rate - use slew-rate X -low-power-mode - low power mode +low-power-enable - enable low power mode +low-power-disable - disable low power mode output-low - set the pin to output mode with low level output-high - set the pin to output mode with high level +Arguments for parameters: + +- bias-pull-up, -down and -pin-default take as optional argument 0 to disable + the pull, on hardware supporting it the pull strength in Ohm. bias-disable + will also disable any active pull. + +- drive-strength takes as argument the target strength in mA. + +- input-schmitt takes as argument the adjustable hysteresis in a + driver-specific format + +- input-debounce takes the debounce time as argument or 0 to disable debouncing + +- power-source argument is the custom value describing the source to select + +- slew-rate takes as argument the target rate in a driver-specific format + +All parameters not listed here, do not take an argument. + More in-depth documentation on these parameters can be found in -- cgit v1.1 From 5e654a4655c30a80a0b35fcd235db4c66600046c Mon Sep 17 00:00:00 2001 From: Andrzej Pietrasiewicz Date: Thu, 13 Jun 2013 10:37:25 +0200 Subject: Documentation/usb: gadget_configfs Add documentation for configfs-based usb gadget. Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Kyungmin Park Acked-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/gadget_configfs.txt | 384 ++++++++++++++++++++++++++++++++++ 1 file changed, 384 insertions(+) create mode 100644 Documentation/usb/gadget_configfs.txt (limited to 'Documentation') diff --git a/Documentation/usb/gadget_configfs.txt b/Documentation/usb/gadget_configfs.txt new file mode 100644 index 0000000..8ec2a67 --- /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/ + +e.g.: + +$ mkdir $CONFIGFS_HOME/usb_gadget/g1 + +... +... +... + +$ cd $CONFIGFS_HOME/usb_gadget/g1 + +Each gadget needs to have its vendor id and product id specified: + +$ echo > idVendor +$ echo > 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 > strings/0x409/serialnumber +$ echo > strings/0x409/manufacturer +$ echo > strings/0x409/product + +2. Creating the configurations +------------------------------ + +Each gadget will consist of a number of configurations, their corresponding +directories must be created: + +$ mkdir configs/. + +where can be any string which is legal in a filesystem and the + 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 > 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/. + +where 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/. configs/. + +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 + +where 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/./ + +where . specify the configuration and 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/./strings/ + +e.g.: + +$ rmdir configs/c.1/strings/0x409 + +... +... +... + +and remove the configurations + +$ rmdir configs/. + +e.g.: + +rmdir configs/c.1 + +... +... +... + +Remove functions (function modules are not unloaded, though) + +$ rmdir functions/. + +e.g.: + +$ rmdir functions/ncm.usb0 + +... +... +... + +Remove strings directories in the gadget + +$ rmdir strings/ + +e.g.: + +$ rmdir strings/0x409 + +and finally remove the gadget: + +$ cd .. +$ rmdir + +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. -- cgit v1.1 From 5b92f46c967706d43717aa666c50c6ea0b12da43 Mon Sep 17 00:00:00 2001 From: Andrzej Pietrasiewicz Date: Thu, 13 Jun 2013 10:37:26 +0200 Subject: Documentation/ABI/testing: configfs-based usb gadgets Signed-off-by: Andrzej Pietrasiewicz Signed-off-by: Kyungmin Park Acked-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/configfs-usb-gadget | 81 ++++++++++++++++++++++ Documentation/ABI/testing/configfs-usb-gadget-acm | 8 +++ Documentation/ABI/testing/configfs-usb-gadget-ecm | 16 +++++ Documentation/ABI/testing/configfs-usb-gadget-eem | 2 +- Documentation/ABI/testing/configfs-usb-gadget-ncm | 15 ++++ Documentation/ABI/testing/configfs-usb-gadget-obex | 9 +++ .../ABI/testing/configfs-usb-gadget-phonet | 2 +- .../ABI/testing/configfs-usb-gadget-rndis | 2 +- .../ABI/testing/configfs-usb-gadget-serial | 9 +++ .../ABI/testing/configfs-usb-gadget-subset | 2 +- 10 files changed, 142 insertions(+), 4 deletions(-) create mode 100644 Documentation/ABI/testing/configfs-usb-gadget create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-acm create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-ecm create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-ncm create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-obex create mode 100644 Documentation/ABI/testing/configfs-usb-gadget-serial (limited to 'Documentation') diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget new file mode 100644 index 0000000..01e769d --- /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 0000000..5708a56 --- /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 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 0000000..6b9a582 --- /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 index 10e87d6..dbddf36 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-eem +++ b/Documentation/ABI/testing/configfs-usb-gadget-eem @@ -1,5 +1,5 @@ What: /config/usb-gadget/gadget/functions/eem.name -Date: May 2013 +Date: Jun 2013 KenelVersion: 3.11 Description: The attributes: diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ncm b/Documentation/ABI/testing/configfs-usb-gadget-ncm new file mode 100644 index 0000000..bc309f423 --- /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 0000000..aaa5c96 --- /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 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 index 19b67d3..3e3b742 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-phonet +++ b/Documentation/ABI/testing/configfs-usb-gadget-phonet @@ -1,5 +1,5 @@ What: /config/usb-gadget/gadget/functions/phonet.name -Date: May 2013 +Date: Jun 2013 KenelVersion: 3.11 Description: diff --git a/Documentation/ABI/testing/configfs-usb-gadget-rndis b/Documentation/ABI/testing/configfs-usb-gadget-rndis index ff127dd..822e6da 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-rndis +++ b/Documentation/ABI/testing/configfs-usb-gadget-rndis @@ -1,5 +1,5 @@ What: /config/usb-gadget/gadget/functions/rndis.name -Date: May 2013 +Date: Jun 2013 KenelVersion: 3.11 Description: The attributes: diff --git a/Documentation/ABI/testing/configfs-usb-gadget-serial b/Documentation/ABI/testing/configfs-usb-gadget-serial new file mode 100644 index 0000000..16f130c --- /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 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 index f47170a..154ae59 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-subset +++ b/Documentation/ABI/testing/configfs-usb-gadget-subset @@ -1,5 +1,5 @@ What: /config/usb-gadget/gadget/functions/geth.name -Date: May 2013 +Date: Jun 2013 KenelVersion: 3.11 Description: The attributes: -- cgit v1.1 From 40dcd0e8067b35e247f74409d79443634daf35ac Mon Sep 17 00:00:00 2001 From: Michael Grzeschik Date: Thu, 13 Jun 2013 17:59:56 +0300 Subject: usb: chipidea: add PTW, PTS and STS handling This patch makes it possible to configure the PTW, PTS and STS bits inside the portsc register for host and device mode before the driver starts and the phy can be addressed as hardware implementation is designed. Signed-off-by: Michael Grzeschik Signed-off-by: Marc Kleine-Budde Signed-off-by: Sascha Hauer Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/ci13xxx-imx.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt index 1c04a4c..184a8e0 100644 --- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt @@ -5,6 +5,11 @@ 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 + 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 -- cgit v1.1 From 691962d1593a16d5c8c9a5bb60b586ac3e54acc8 Mon Sep 17 00:00:00 2001 From: Sascha Hauer Date: Thu, 13 Jun 2013 17:59:57 +0300 Subject: usb: chipidea: introduce dual role mode pdata flags Even if a chipidea core is otg capable the board may not be. This allows to explicitly set the core to host/peripheral mode. Without these flags the driver falls back to the old behaviour. Signed-off-by: Sascha Hauer Signed-off-by: Alexander Shishkin Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/ci13xxx-imx.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt index 184a8e0..b4b5b79 100644 --- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt +++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt @@ -9,6 +9,7 @@ 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 -- cgit v1.1 From c91f2a03cfc67753c8ab78f97983e947bb8f7610 Mon Sep 17 00:00:00 2001 From: Leela Krishna Amudala Date: Tue, 18 Jun 2013 06:58:48 +0900 Subject: Documentation: Add examples to samsung-pinctrl device tree bindings documentation This patch adds examples to samsung-pinctrl.txt documentaion file on how to make gpio binding and gpio request Signed-off-by: Leela Krishna Amudala Reviewed-by: Doug Anderson Reviewed-by: Tomasz Figa Acked-by: Linus Walleij Signed-off-by: Kukjin Kim --- .../bindings/pinctrl/samsung-pinctrl.txt | 44 +++++++++++++++++++++- 1 file changed, 42 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index c70fca1..e15cfc4 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -21,8 +21,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 @@ -266,3 +276,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"); + /* ... */ + } -- cgit v1.1 From 23be63f48d928cd5a21db58f73c731357e895250 Mon Sep 17 00:00:00 2001 From: Srinivas Pandruvada Date: Fri, 17 May 2013 23:42:03 +0000 Subject: Thermal: Documentation for x86 package temperature thermal driver Added documentation describing details of the x86 package temperature thermal driver. Signed-off-by: Srinivas Pandruvada Signed-off-by: Zhang Rui --- Documentation/thermal/x86_pkg_temperature_thermal | 47 +++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 Documentation/thermal/x86_pkg_temperature_thermal (limited to 'Documentation') diff --git a/Documentation/thermal/x86_pkg_temperature_thermal b/Documentation/thermal/x86_pkg_temperature_thermal new file mode 100644 index 0000000..17a3a4c --- /dev/null +++ b/Documentation/thermal/x86_pkg_temperature_thermal @@ -0,0 +1,47 @@ +Kernel driver: x86_pkg_temp_thermal +=================== + +Supported chips: +* x86: with package level thermal management +(Verify using: CPUID.06H:EAX[bit 6] =1) + +Authors: Srinivas Pandruvada + +Reference +--- +Intel® 64 and IA-32 Architectures Software Developer’s Manual (Jan, 2013): +Chapter 14.6: PACKAGE LEVEL THERMAL MANAGEMENT + +Description +--------- + +This driver register CPU digital temperature package level sensor as a thermal +zone with maximum two user mode configurable trip points. Number of trip points +depends on the capability of the package. Once the trip point is violated, +user mode can receive notification via thermal notification mechanism and can +take any action to control temperature. + + +Threshold management +-------------------- +Each package will register as a thermal zone under /sys/class/thermal. +Example: +/sys/class/thermal/thermal_zone1 + +This contains two trip points: +- trip_point_0_temp +- trip_point_1_temp + +User can set any temperature between 0 to TJ-Max temperature. Temperature units +are in milli-degree Celsius. Refer to "Documentation/thermal/sysfs-api.txt" for +thermal sys-fs details. + +Any value other than 0 in these trip points, can trigger thermal notifications. +Setting 0, stops sending thermal notifications. + +Thermal notifications: To get kobject-uevent notifications, set the thermal zone +policy to "user_space". For example: echo -n "user_space" > policy + + + + -- cgit v1.1 From d5e9fe8462d3f596a420cc1a25a01928777f139b Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar Date: Mon, 10 Jun 2013 11:33:31 -0400 Subject: ARM: dts: keystone: Add minimal Keystone SOC device tree data Add minimal device tree data for Keystone2 based SOCs. Patch contains mainly ARM related SOC data and nothing about EVM specific yet. Cc: Grant Likely Cc: Arnd Bergmann Cc: arm@kernel.org Acked-by: Olof Johansson Signed-off-by: Santosh Shilimkar --- Documentation/devicetree/bindings/arm/keystone/keystone.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/keystone/keystone.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt new file mode 100644 index 0000000..63c0e6a --- /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. -- cgit v1.1 From cc79dd1ba9c1021c2ac6ae200a65ec38ee8db351 Mon Sep 17 00:00:00 2001 From: Ying Xue Date: Mon, 17 Jun 2013 10:54:37 -0400 Subject: tipc: change socket buffer overflow control to respect sk_rcvbuf As per feedback from the netdev community, we change the buffer overflow protection algorithm in receiving sockets so that it always respects the nominal upper limit set in sk_rcvbuf. Instead of scaling up from a small sk_rcvbuf value, which leads to violation of the configured sk_rcvbuf limit, we now calculate the weighted per-message limit by scaling down from a much bigger value, still in the same field, according to the importance priority of the received message. To allow for administrative tunability of the socket receive buffer size, we create a tipc_rmem sysctl variable to allow the user to configure an even bigger value via sysctl command. It is a size of three (min/default/max) to be consistent with things like tcp_rmem. By default, the value initialized in tipc_rmem[1] is equal to the receive socket size needed by a TIPC_CRITICAL_IMPORTANCE message. This value is also set as the default value of sk_rcvbuf. Originally-by: Jon Maloy Cc: Neil Horman Cc: Jon Maloy [Ying: added sysctl variation to Jon's original patch] Signed-off-by: Ying Xue [PG: don't compile sysctl.c if not config'd; add Documentation] Signed-off-by: Paul Gortmaker Signed-off-by: David S. Miller --- Documentation/sysctl/net.txt | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index 85ab72d..5369879 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -26,7 +26,7 @@ Table : Subdirectories in /proc/sys/net ipv4 IP version 4 x25 X.25 protocol ipx IPX token-ring IBM token ring bridge Bridging decnet DEC net - ipv6 IP version 6 + ipv6 IP version 6 tipc TIPC .............................................................................. 1. /proc/sys/net/core - Network core options @@ -207,3 +207,18 @@ IPX. The /proc/net/ipx_route table holds a list of IPX routes. For each route it gives the destination network, the router node (or Directly) and the network address of the router (or Connected) for internal networks. + +6. TIPC +------------------------------------------------------- + +The TIPC protocol now has a tunable for the receive memory, similar to the +tcp_rmem - i.e. a vector of 3 INTEGERs: (min, default, max) + + # cat /proc/sys/net/tipc/tipc_rmem + 4252725 34021800 68043600 + # + +The max value is set to CONN_OVERLOAD_LIMIT, and the default and min values +are scaled (shifted) versions of that same value. Note that the min value +is not at this point in time used in any meaningful way, but the triplet is +preserved in order to be consistent with things like tcp_rmem. -- cgit v1.1 From b1f254e35d85535b17af2786d06fe88f15f304f7 Mon Sep 17 00:00:00 2001 From: Graeme Gregory Date: Tue, 28 May 2013 10:50:11 +0900 Subject: extcon: Palmas Extcon Driver This is the driver for the USB comparator built into the palmas chip. It handles the various USB OTG events that can be generated by cable insertion/removal. Signed-off-by: Graeme Gregory Signed-off-by: Moiz Sonasath Signed-off-by: Ruchika Kharwar Signed-off-by: Kishon Vijay Abraham I Signed-off-by: George Cherian [kishon@ti.com: adapted palmas usb driver to use the extcon framework] Signed-off-by: Sebastien Guiriec Signed-off-by: Chanwoo Choi Signed-off-by: Myungjoo Ham Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/extcon/extcon-twl.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-twl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt b/Documentation/devicetree/bindings/extcon/extcon-twl.txt new file mode 100644 index 0000000..58f531a --- /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; +}; -- cgit v1.1 From 894db164260c39870ea79e473e1307b4aa5e4257 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Thu, 13 Jun 2013 11:23:38 +0200 Subject: irqchip: renesas-intc-irqpin: DT binding for sense bitfield width Most Renesas irqpin controllers have 4-bit sense fields, however, some have different widths. This patch adds a DT binding to optionally specify such non-standard values. Signed-off-by: Guennadi Liakhovetski Acked-by: Arnd Bergmann Signed-off-by: Simon Horman --- .../bindings/interrupt-controller/renesas,intc-irqpin.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt (limited to 'Documentation') 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 0000000..66fcaf5 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt @@ -0,0 +1,14 @@ +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 -- cgit v1.1 From fe1c9a822ce72c6ec8476a2501c412265ee2172c Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Mon, 17 Jun 2013 20:50:02 +0200 Subject: sh-pfc: Add DT support Support device instantiation through the device tree. The compatible property is used to select the SoC pinmux information. Set the gpio_chip device field to the PFC device to enable automatic GPIO OF support. Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Laurent Pinchart Acked-by: Heiko Stuebner Signed-off-by: Linus Walleij --- .../bindings/pinctrl/renesas,pfc-pinctrl.txt | 135 +++++++++++++++++++++ 1 file changed, 135 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt new file mode 100644 index 0000000..8264cbc --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt @@ -0,0 +1,135 @@ +* Renesas Pin Function Controller (GPIO and Pin Mux/Config) + +The Pin Function Controller (PFC) is a Pin Mux/Config controller. On SH7372, +SH73A0, R8A73A4 and R8A7740 it also acts as a GPIO controller. + + +Pin Control +----------- + +Required Properties: + + - compatible: should be one of the following. + - "renesas,pfc-r8a73a4": for R8A73A4 (R-Mobile APE6) compatible pin-controller. + - "renesas,pfc-r8a7740": for R8A7740 (R-Mobile A1) compatible pin-controller. + - "renesas,pfc-r8a7778": for R8A7778 (R-Mobile M1) compatible pin-controller. + - "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller. + - "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller. + - "renesas,pfc-sh7372": for SH7372 (SH-Mobile AP4) compatible pin-controller. + - "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller. + + - reg: Base address and length of each memory resource used by the pin + controller hardware module. + +Optional properties: + + - #gpio-range-cells: Mandatory when the PFC doesn't handle GPIO, forbidden + otherwise. Should be 3. + +The PFC node also acts as a container for pin configuration nodes. Please refer +to pinctrl-bindings.txt in this directory for the definition of the term "pin +configuration node" and for the common pinctrl bindings used by client devices. + +Each pin configuration node represents desired functions to select on a pin +group or a list of pin groups. The functions and pin groups can be specified +directly in the pin configuration node, or grouped in child subnodes. Several +functions can thus be referenced as a single pin configuration node by client +devices. + +A configuration node or subnode must contain a function and reference at least +one pin group. + +All pin configuration nodes and subnodes names are ignored. All of those nodes +are parsed through phandles and processed purely based on their content. + +Pin Configuration Node Properties: + +- renesas,groups : An array of strings, each string containing the name of a pin + group. + +- renesas,function: A string containing the name of the function to mux to the + pin group(s) specified by the renesas,groups property + + Valid values for pin, group and function names can be found in the group and + function arrays of the PFC data file corresponding to the SoC + (drivers/pinctrl/sh-pfc/pfc-*.c) + + +GPIO +---- + +On SH7372, SH73A0, R8A73A4 and R8A7740 the PFC node is also a GPIO controller +node. + +Required Properties: + + - 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 . Only the + GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. + +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] + [flags]> + +On other mach-shmobile platforms GPIO is handled by the gpio-rcar driver. +Please refer to Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt +for documentation of the GPIO device tree bindings on those platforms. + + +Examples +-------- + +Example 1: SH73A0 (SH-Mobile AG5) pin controller node + + pfc: pfc@e6050000 { + compatible = "renesas,pfc-sh73a0"; + reg = <0xe6050000 0x8000>, + <0xe605801c 0x1c>; + gpio-controller; + #gpio-cells = <2>; + }; + +Example 2: A GPIO LED node that references a GPIO + + #include + + leds { + compatible = "gpio-leds"; + led1 { + gpios = <&pfc 20 GPIO_ACTIVE_LOW>; + }; + }; + +Example 3: KZM-A9-GT (SH-Mobile AG5) default pin state hog and pin control maps + for the MMCIF and SCIFA4 devices + + &pfc { + pinctrl-0 = <&scifa4_pins>; + pinctrl-names = "default"; + + mmcif_pins: mmcif { + renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0"; + renesas,function = "mmc0"; + }; + + scifa4_pins: scifa4 { + renesas,groups = "scifa4_data", "scifa4_ctrl"; + renesas,function = "scifa4"; + }; + }; + +Example 4: KZM-A9-GT (SH-Mobile AG5) default pin state for the MMCIF device + + &mmcif { + pinctrl-0 = <&mmcif_pins>; + pinctrl-names = "default"; + + bus-width = <8>; + vmmc-supply = <®_1p8v>; + status = "okay"; + }; -- cgit v1.1 From 12f3ad8df7f58c61ff16ea851541583693d965e1 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Mon, 17 Jun 2013 20:50:03 +0200 Subject: sh-pfc: Add pinconf support to DT bindings Signed-off-by: Laurent Pinchart Acked-by: Heiko Stuebner Signed-off-by: Linus Walleij --- .../bindings/pinctrl/renesas,pfc-pinctrl.txt | 36 ++++++++++++++++------ 1 file changed, 27 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt index 8264cbc..d5dac7b 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt @@ -30,20 +30,27 @@ The PFC node also acts as a container for pin configuration nodes. Please refer to pinctrl-bindings.txt in this directory for the definition of the term "pin configuration node" and for the common pinctrl bindings used by client devices. -Each pin configuration node represents desired functions to select on a pin -group or a list of pin groups. The functions and pin groups can be specified -directly in the pin configuration node, or grouped in child subnodes. Several -functions can thus be referenced as a single pin configuration node by client -devices. +Each pin configuration node represents a desired configuration for a pin, a +pin group, or a list of pins or pin groups. The configuration can include the +function to select on those pin(s) and pin configuration parameters (such as +pull-up and pull-down). -A configuration node or subnode must contain a function and reference at least -one pin group. +Pin configuration nodes contain pin configuration properties, either directly +or grouped in child subnodes. Both pin muxing and configuration parameters can +be grouped in that way and referenced as a single pin configuration node by +client devices. + +A configuration node or subnode must reference at least one pin (through the +pins or pin groups properties) and contain at least a function or one +configuration parameter. When the function is present only pin groups can be +used to reference pins. All pin configuration nodes and subnodes names are ignored. All of those nodes are parsed through phandles and processed purely based on their content. Pin Configuration Node Properties: +- renesas,pins : An array of strings, each string containing the name of a pin. - renesas,groups : An array of strings, each string containing the name of a pin group. @@ -54,6 +61,10 @@ Pin Configuration Node Properties: function arrays of the PFC data file corresponding to the SoC (drivers/pinctrl/sh-pfc/pfc-*.c) +The pin configuration parameters use the generic pinconf bindings defined in +pinctrl-bindings.txt in this directory. The supported parameters are +bias-disable, bias-pull-up and bias-pull-down. + GPIO ---- @@ -113,8 +124,15 @@ Example 3: KZM-A9-GT (SH-Mobile AG5) default pin state hog and pin control maps pinctrl-names = "default"; mmcif_pins: mmcif { - renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0"; - renesas,function = "mmc0"; + mux { + renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0"; + renesas,function = "mmc0"; + }; + cfg { + renesas,groups = "mmc0_data8_0"; + renesas,pins = "PORT279"; + bias-pull-up; + }; }; scifa4_pins: scifa4 { -- cgit v1.1 From ac4c1a9b33005969b05de0f13ec90ec426a76769 Mon Sep 17 00:00:00 2001 From: Sascha Hauer Date: Tue, 18 Jun 2013 09:23:57 +0800 Subject: staging: drm/imx: Add LDB support This adds support for the LVDS Display Bridge contained in i.MX5 and i.MX6 SoCs. Bit mapping, data width, and video timings are configurable via device tree. Dual-channel mode is supported for a single high-resolution source. Signed-off-by: Sascha Hauer Signed-off-by: Philipp Zabel Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/staging/imx-drm/ldb.txt | 99 ++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 Documentation/devicetree/bindings/staging/imx-drm/ldb.txt (limited to 'Documentation') 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 0000000..ed93778 --- /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 { + /* ... */ + }; + }; +}; -- cgit v1.1 From 1241ef94ccc3aeaeecf73b2889efd9bcd6ffa4f7 Mon Sep 17 00:00:00 2001 From: Padmavathi Venna Date: Tue, 18 Jun 2013 00:02:17 +0900 Subject: clk: samsung: register audio subsystem clocks using common clock framework Audio subsystem is introduced in s5pv210 and exynos platforms. This has seperate clock controller which can control i2s0 and pcm0 clocks. This patch registers the audio subsystem clocks with the common clock framework on Exynos family. Signed-off-by: Padmavathi Venna Reviewed-by: Sylwester Nawrocki Reviewed-by: Doug Anderson Acked-by: Mike Turquette Signed-off-by: Kukjin Kim --- .../devicetree/bindings/clock/clk-exynos-audss.txt | 64 ++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-exynos-audss.txt (limited to 'Documentation') 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 0000000..a120180 --- /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"; +}; -- cgit v1.1 From 4a3afb73cdeaec0b4d4b39b6af0968cfa804b662 Mon Sep 17 00:00:00 2001 From: Padmavathi Venna Date: Tue, 18 Jun 2013 00:02:31 +0900 Subject: ARM: dts: Update Samsung I2S documentation This patch updates the samsung i2s documentation for pinmux and clock entries. Signed-off-by: Padmavathi Venna Signed-off-by: Kukjin Kim --- .../devicetree/bindings/sound/samsung-i2s.txt | 46 +++++++++------------- 1 file changed, 19 insertions(+), 27 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt b/Documentation/devicetree/bindings/sound/samsung-i2s.txt index 3070046..025e66b 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>; }; -- cgit v1.1 From 1609027fc2f4e3784c64a57654c16b9c4f2d10db Mon Sep 17 00:00:00 2001 From: Chander Kashyap Date: Wed, 19 Jun 2013 00:29:34 +0900 Subject: clk: exynos5420: register clocks using common clock framework The EXYNOS5420 clocks are statically listed and registered using the Samsung specific common clock helper functions. Signed-off-by: Chander Kashyap Signed-off-by: Thomas Abraham Reviewed-by: Tomasz Figa Cc: Mike Turquette Signed-off-by: Kukjin Kim --- .../devicetree/bindings/clock/exynos5420-clock.txt | 201 +++++++++++++++++++++ 1 file changed, 201 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/exynos5420-clock.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt new file mode 100644 index 0000000..9bcc4b1 --- /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"; + }; -- cgit v1.1 From 022c674728f45ad22ce2bb5eb628ac9d3dbc3aea Mon Sep 17 00:00:00 2001 From: Alessandro Rubini Date: Tue, 18 Jun 2013 23:47:24 +0200 Subject: FMC: add documentation for the core This is selected sections of the current manual for fmc-bus, as developed outside of the kernel before submission. Like the other patches in this set, it corresponds to commit ab23167f of the repository at ohwr.org Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez Acked-by: Rob Landley Signed-off-by: Greg Kroah-Hartman --- Documentation/00-INDEX | 2 + Documentation/fmc/00-INDEX | 26 ++++ Documentation/fmc/API.txt | 47 ++++++ Documentation/fmc/FMC-and-SDB.txt | 88 +++++++++++ Documentation/fmc/carrier.txt | 311 ++++++++++++++++++++++++++++++++++++++ Documentation/fmc/identifiers.txt | 168 ++++++++++++++++++++ Documentation/fmc/mezzanine.txt | 123 +++++++++++++++ Documentation/fmc/parameters.txt | 56 +++++++ 8 files changed, 821 insertions(+) create mode 100644 Documentation/fmc/00-INDEX create mode 100644 Documentation/fmc/API.txt create mode 100644 Documentation/fmc/FMC-and-SDB.txt create mode 100644 Documentation/fmc/carrier.txt create mode 100644 Documentation/fmc/identifiers.txt create mode 100644 Documentation/fmc/mezzanine.txt create mode 100644 Documentation/fmc/parameters.txt (limited to 'Documentation') diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 45b3df9..0c4cc68 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/fmc/00-INDEX b/Documentation/fmc/00-INDEX new file mode 100644 index 0000000..71304b7 --- /dev/null +++ b/Documentation/fmc/00-INDEX @@ -0,0 +1,26 @@ + +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 diff --git a/Documentation/fmc/API.txt b/Documentation/fmc/API.txt new file mode 100644 index 0000000..06b06b9 --- /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 0000000..fa14e0b --- /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 +. 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 0000000..173f6d6 --- /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 */ + 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/identifiers.txt b/Documentation/fmc/identifiers.txt new file mode 100644 index 0000000..3bb577f --- /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 0000000..87910db --- /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 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 0000000..59edf08 --- /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 -- cgit v1.1 From 6c62a895e572145f8aa24f2040d1bb8eff473313 Mon Sep 17 00:00:00 2001 From: Alessandro Rubini Date: Tue, 18 Jun 2013 23:47:35 +0200 Subject: FMC: add a software carrier driver This fake carrier is designed to help FMC users understand how a carrier driver works, and to experiment the behaviour with EEPROM reprogramming (with a mezzanine driver commited later). This carrier can register up to 4 (fake) mezzanines. We have real carriers (both on PCI-E and VME), but they are bigger things and are not part of this submission. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez Signed-off-by: Greg Kroah-Hartman --- Documentation/fmc/00-INDEX | 3 +++ Documentation/fmc/fmc-fakedev.txt | 36 ++++++++++++++++++++++++++++++++++++ 2 files changed, 39 insertions(+) create mode 100644 Documentation/fmc/fmc-fakedev.txt (limited to 'Documentation') diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index 71304b7..34df5cf 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -24,3 +24,6 @@ mezzanine.txt identifiers.txt - how identification and matching works + +fmc-fakedev.txt + - about drivers/fmc/fmc-fakedev.ko diff --git a/Documentation/fmc/fmc-fakedev.txt b/Documentation/fmc/fmc-fakedev.txt new file mode 100644 index 0000000..e85b74a --- /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 -- cgit v1.1 From 056d83f3c30c398f14eb879f1d1707e3a7808f4a Mon Sep 17 00:00:00 2001 From: Alessandro Rubini Date: Tue, 18 Jun 2013 23:47:46 +0200 Subject: FMC: add a software mezzanine driver This simple do-nothing mezzanine driver shows how to write a mezzanine driver, that can also handle interrupts reported by the carrier. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez Signed-off-by: Greg Kroah-Hartman --- Documentation/fmc/00-INDEX | 3 +++ Documentation/fmc/fmc-trivial.txt | 17 +++++++++++++++++ 2 files changed, 20 insertions(+) create mode 100644 Documentation/fmc/fmc-trivial.txt (limited to 'Documentation') diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index 34df5cf..c22d687 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -27,3 +27,6 @@ identifiers.txt fmc-fakedev.txt - about drivers/fmc/fmc-fakedev.ko + +fmc-trivial.txt + - about drivers/fmc/fmc-trivial.ko diff --git a/Documentation/fmc/fmc-trivial.txt b/Documentation/fmc/fmc-trivial.txt new file mode 100644 index 0000000..d1910bc --- /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. -- cgit v1.1 From 6007b1bd0f752a5c022f7944c65fb96c39d6db3d Mon Sep 17 00:00:00 2001 From: Alessandro Rubini Date: Tue, 18 Jun 2013 23:47:56 +0200 Subject: FMC: add a driver to write mezzanine EEPROM This driver allows to reprogram the EEPROM in a mezzanine, to store its own identifiers during manufacturing or to save other useful data. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez Signed-off-by: Greg Kroah-Hartman --- Documentation/fmc/00-INDEX | 3 + Documentation/fmc/fmc-write-eeprom.txt | 125 +++++++++++++++++++++++++++++++++ 2 files changed, 128 insertions(+) create mode 100644 Documentation/fmc/fmc-write-eeprom.txt (limited to 'Documentation') diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index c22d687..177c3e4 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -30,3 +30,6 @@ fmc-fakedev.txt fmc-trivial.txt - about drivers/fmc/fmc-trivial.ko + +fmc-write-eeprom.txt + - about drivers/fmc/fmc-write-eeprom.ko diff --git a/Documentation/fmc/fmc-write-eeprom.txt b/Documentation/fmc/fmc-write-eeprom.txt new file mode 100644 index 0000000..44a3bc6 --- /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 -- cgit v1.1 From 4debfe409b6e550032bfef9733e9f6f7c5613617 Mon Sep 17 00:00:00 2001 From: Alessandro Rubini Date: Tue, 18 Jun 2013 23:48:07 +0200 Subject: FMC: add a char-device mezzanine driver This driver exports the memory area associated with the mezzanine card as a misc device, so users can access registers. Signed-off-by: Alessandro Rubini Acked-by: Juan David Gonzalez Cobas Acked-by: Emilio G. Cota Acked-by: Samuel Iglesias Gonsalvez Signed-off-by: Greg Kroah-Hartman --- Documentation/fmc/00-INDEX | 5 ++- Documentation/fmc/fmc-chardev.txt | 64 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 68 insertions(+), 1 deletion(-) create mode 100644 Documentation/fmc/fmc-chardev.txt (limited to 'Documentation') diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX index 177c3e4..431c695 100644 --- a/Documentation/fmc/00-INDEX +++ b/Documentation/fmc/00-INDEX @@ -32,4 +32,7 @@ fmc-trivial.txt - about drivers/fmc/fmc-trivial.ko fmc-write-eeprom.txt - - about drivers/fmc/fmc-write-eeprom.ko + - about drivers/fmc/fmc-write-eeprom.ko + +fmc-chardev.txt + - about drivers/fmc/fmc-chardev.ko diff --git a/Documentation/fmc/fmc-chardev.txt b/Documentation/fmc/fmc-chardev.txt new file mode 100644 index 0000000..d9ccb27 --- /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-, 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 -- cgit v1.1 From e4156979c7d34e5197b16fa31c1c7549eae675e5 Mon Sep 17 00:00:00 2001 From: Chao Xie Date: Sun, 5 May 2013 20:25:10 -0700 Subject: Input: pxa27x-keypad - add device tree support Signed-off-by: Chao Xie Signed-off-by: Dmitry Torokhov --- .../devicetree/bindings/input/pxa27x-keypad.txt | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/pxa27x-keypad.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/pxa27x-keypad.txt b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt new file mode 100644 index 0000000..f8674f7 --- /dev/null +++ b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt @@ -0,0 +1,60 @@ +* Marvell PXA Keypad controller + +Required Properties +- compatible : should be "marvell,pxa27x-keypad" +- reg : Address and length of the register set for the device +- interrupts : The interrupt for the keypad controller +- marvell,debounce-interval : How long time the key will be + recognized when it is pressed. It is a u32 value, and bit[31:16] + is debounce interval for direct key and bit[15:0] is debounce + interval for matrix key. The value is in binary number of 2ms + +Optional Properties For Matrix Keyes +Please refer to matrix-keymap.txt + +Optional Properties for Direct Keyes +- marvell,direct-key-count : How many direct keyes are used. +- marvell,direct-key-mask : The mask indicates which keyes + are used. If bit[X] of the mask is set, the direct key X + is used. +- marvell,direct-key-low-active : Direct key status register + tells the level of pins that connects to the direct keyes. + When this property is set, it means that when the pin level + is low, the key is pressed(active). +- marvell,direct-key-map : It is a u16 array. Each item indicates + the linux key-code for the direct key. + +Optional Properties For Rotary +- marvell,rotary0 : It is a u32 value. Bit[31:16] is the + linux key-code for rotary up. Bit[15:0] is the linux key-code + for rotary down. It is for rotary 0. +- marvell,rotary1 : Same as marvell,rotary0. It is for rotary 1. +- marvell,rotary-rel-key : When rotary is used for relative axes + in the device, the value indicates the key-code for relative + axes measurement in the device. It is a u32 value. Bit[31:16] + is for rotary 1, and Bit[15:0] is for rotary 0. + +Examples: + keypad: keypad@d4012000 { + keypad,num-rows = <3>; + keypad,num-columns = <5>; + linux,keymap = <0x0000000e /* KEY_BACKSPACE */ + 0x0001006b /* KEY_END */ + 0x00020061 /* KEY_RIGHTCTRL */ + 0x0003000b /* KEY_0 */ + 0x00040002 /* KEY_1 */ + 0x0100008b /* KEY_MENU */ + 0x01010066 /* KEY_HOME */ + 0x010200e7 /* KEY_SEND */ + 0x01030009 /* KEY_8 */ + 0x0104000a /* KEY_9 */ + 0x02000160 /* KEY_OK */ + 0x02010003 /* KEY_2 */ + 0x02020004 /* KEY_3 */ + 0x02030005 /* KEY_4 */ + 0x02040006>; /* KEY_5 */ + marvell,rotary0 = <0x006c0067>; /* KEY_UP & KEY_DOWN */ + marvell,direct-key-count = <1>; + marvell,direct-key-map = <0x001c>; + marvell,debounce-interval = <0x001e001e>; + }; -- cgit v1.1 From b0fc1da4d0359d3cce8f12e0f014aed0704ae202 Mon Sep 17 00:00:00 2001 From: Florian Vaussard Date: Tue, 18 Jun 2013 15:17:58 +0200 Subject: mfd: twl4030-power: Start transition to DT Support for loading twl4030-power module via devicetree. For now, when booting with a DT, only the poweroff callback feature is supported through the ti,use_poweroff property. Signed-off-by: Florian Vaussard Signed-off-by: Samuel Ortiz --- .../devicetree/bindings/mfd/twl4030-power.txt | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/twl4030-power.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt b/Documentation/devicetree/bindings/mfd/twl4030-power.txt new file mode 100644 index 0000000..8e15ec3 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt @@ -0,0 +1,28 @@ +Texas Instruments TWL family (twl4030) reset and power management module + +The power management module inside the TWL family provides several facilities +to control the power resources, including power scripts. For now, the +binding only supports the complete shutdown of the system after poweroff. + +Required properties: +- compatible : must be "ti,twl4030-power" + +Optional properties: +- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or + SLEEP-to-OFF transition when the system poweroffs. + +Example: +&i2c1 { + clock-frequency = <2600000>; + + twl: twl@48 { + reg = <0x48>; + interrupts = <7>; /* SYS_NIRQ cascaded to intc */ + interrupt-parent = <&intc>; + + twl_power: power { + compatible = "ti,twl4030-power"; + ti,use_poweroff; + }; + }; +}; -- cgit v1.1 From d8968f1f334c18bf65178b757a82864ef3f37613 Mon Sep 17 00:00:00 2001 From: Alexey Kardashevskiy Date: Wed, 19 Jun 2013 11:42:07 +1000 Subject: kvm api doc: fix section numbers Signed-off-by: Alexey Kardashevskiy Signed-off-by: Paolo Bonzini --- Documentation/virtual/kvm/api.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 5f91eda..6365fef 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -2261,7 +2261,7 @@ return indicates the attribute is implemented. It does not necessarily indicate that the attribute can be read or written in the device's current state. "addr" is ignored. -4.77 KVM_ARM_VCPU_INIT +4.82 KVM_ARM_VCPU_INIT Capability: basic Architectures: arm @@ -2285,7 +2285,7 @@ Possible features: Depends on KVM_CAP_ARM_PSCI. -4.78 KVM_GET_REG_LIST +4.83 KVM_GET_REG_LIST Capability: basic Architectures: arm @@ -2305,7 +2305,7 @@ This ioctl returns the guest registers that are supported for the KVM_GET_ONE_REG/KVM_SET_ONE_REG calls. -4.80 KVM_ARM_SET_DEVICE_ADDR +4.84 KVM_ARM_SET_DEVICE_ADDR Capability: KVM_CAP_ARM_SET_DEVICE_ADDR Architectures: arm @@ -2342,7 +2342,7 @@ and distributor interface, the ioctl must be called after calling KVM_CREATE_IRQCHIP, but before calling KVM_RUN on any of the VCPUs. Calling this ioctl twice for any of the base addresses will return -EEXIST. -4.82 KVM_PPC_RTAS_DEFINE_TOKEN +4.85 KVM_PPC_RTAS_DEFINE_TOKEN Capability: KVM_CAP_PPC_RTAS Architectures: ppc -- cgit v1.1 From 6c806a7332e6d36c1f95966b4a8a22f342b68948 Mon Sep 17 00:00:00 2001 From: Xiao Guangrong Date: Wed, 19 Jun 2013 17:09:19 +0800 Subject: KVM: MMU: update the documentation for reverse mapping of parent_pte Update the document to match the current reverse mapping of parent_pte Signed-off-by: Xiao Guangrong Signed-off-by: Paolo Bonzini --- Documentation/virtual/kvm/mmu.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virtual/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt index 43fcb76..869abcc 100644 --- a/Documentation/virtual/kvm/mmu.txt +++ b/Documentation/virtual/kvm/mmu.txt @@ -191,12 +191,12 @@ Shadow pages contain the following information: A counter keeping track of how many hardware registers (guest cr3 or pdptrs) are now pointing at the page. While this counter is nonzero, the page cannot be destroyed. See role.invalid. - multimapped: - Whether there exist multiple sptes pointing at this page. - parent_pte/parent_ptes: - If multimapped is zero, parent_pte points at the single spte that points at - this page's spt. Otherwise, parent_ptes points at a data structure - with a list of parent_ptes. + parent_ptes: + The reverse mapping for the pte/ptes pointing at this page's spt. If + parent_ptes bit 0 is zero, only one spte points at this pages and + parent_ptes points at this single spte, otherwise, there exists multiple + sptes pointing at this page and (parent_ptes & ~0x1) points at a data + structure with a list of parent_ptes. unsync: If true, then the translations in this page may not match the guest's translation. This is equivalent to the state of the tlb when a pte is -- cgit v1.1 From 4730bcfb067a92bd446b4ffd149e0768572c7f19 Mon Sep 17 00:00:00 2001 From: Afzal Mohammed Date: Fri, 14 Jun 2013 19:33:34 +0530 Subject: ARM: dts: AM43x EPOS EVM support Add AM43x ePOS EVM minimal DT source - this is a minimal one to get it booting. Also include it in omap2plus dtbs and document bindings. The hardware is under development. Signed-off-by: Afzal Mohammed Signed-off-by: Benoit Cousson --- Documentation/devicetree/bindings/arm/omap/omap.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index f8288ea..6d498c7 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" -- cgit v1.1 From 0a0fca9d832b704f116a25badd1ca8c16771dcac Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Tue, 4 Jun 2013 13:10:24 +0530 Subject: sched: Rename sched.c as sched/core.c in comments and Documentation Most of the stuff from kernel/sched.c was moved to kernel/sched/core.c long time back and the comments/Documentation never got updated. I figured it out when I was going through sched-domains.txt and so thought of fixing it globally. I haven't crossed check if the stuff that is referenced in sched/core.c by all these files is still present and hasn't changed as that wasn't the motive behind this patch. Signed-off-by: Viresh Kumar Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/cdff76a265326ab8d71922a1db5be599f20aad45.1370329560.git.viresh.kumar@linaro.org Signed-off-by: Ingo Molnar --- Documentation/cgroups/cpusets.txt | 2 +- Documentation/rt-mutex-design.txt | 2 +- Documentation/scheduler/sched-domains.txt | 4 ++-- Documentation/spinlocks.txt | 2 +- Documentation/virtual/uml/UserModeLinux-HOWTO.txt | 4 ++-- 5 files changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index 12e01d4..7740038 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/rt-mutex-design.txt b/Documentation/rt-mutex-design.txt index 33ed800..a5bcd7f 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 443f0c7..4af80b1 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/spinlocks.txt b/Documentation/spinlocks.txt index 9dbe885..97eaf57 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/virtual/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt index a5f8436..f4099ca 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 -- cgit v1.1 From c4fa4946f177ae214523586cd794ac18d34b1430 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Wed, 19 Jun 2013 07:53:09 +0200 Subject: ARM: shmobile: irqpin: add a DT property to enable masking on parent To disable spurious interrupts, that get triggered on certain hardware, the irqpin driver masks them on the parent interrupt controller. To specify such broken devices a .control_parent parameter can be provided in the platform data. In the DT case we need a property, to do the same. Signed-off-by: Guennadi Liakhovetski Acked-by: Magnus Damm Signed-off-by: Simon Horman --- .../devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt index 66fcaf5..1f8b0c5 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt @@ -12,3 +12,5 @@ Optional properties: 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 -- cgit v1.1 From b559c3e8e7ca469921987925baf892ab2038396e Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Tue, 18 Jun 2013 12:29:48 +0200 Subject: gpio-rcar: Reference core gpio documentation in the DT bindings Replaced the detailed gpio-ranges documentation with a reference to the code gpio DT bindings, and mention the gpio flags symbolic names. Signed-off-by: Laurent Pinchart Signed-off-by: Simon Horman --- .../devicetree/bindings/gpio/renesas,gpio-rcar.txt | 18 ++++++------------ 1 file changed, 6 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt index 46d76a0..cb3dc7b 100644 --- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt +++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt @@ -16,18 +16,12 @@ Required Properties: - 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 is used to specify optional parameters as bit flags. Only the GPIO - active low flag (bit 0) is currently supported. - - gpio-ranges: Range of pins managed by the GPIO controller as a 4-cells - tuple using the following syntax. - - <[phandle of the pin controller node] - 0 - [index of the first pin] - [number of pins]> - -Please refer to gpio.txt in this directory for details of the common GPIO -bindings used by client devices. + cell specifies GPIO flags, as defined in . 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 -- cgit v1.1 From 983dbeb35f1543668b8f3b31a735bf2163f2b233 Mon Sep 17 00:00:00 2001 From: Leela Krishna Amudala Date: Wed, 19 Jun 2013 22:16:26 +0900 Subject: pinctrl: exynos: add exynos5420 SoC specific data Add Samsung EXYNOS5420 SoC specific data to enable pinctrl support for all platforms based on EXYNOS5420. Signed-off-by: Leela Krishna Amudala Reviewed-by: Doug Anderson Acked-by: Tomasz Figa Acked-by: Linus Walleij Tested-by : Sunil Joshi Signed-off-by: Kukjin Kim --- Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index e15cfc4..4dee837 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -11,6 +11,7 @@ Required Properties: - "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. -- cgit v1.1 From 1a891cf19cdfb645827969cc6aeaeebdefeb87b2 Mon Sep 17 00:00:00 2001 From: Steven Rostedt Date: Wed, 12 Jun 2013 13:16:25 -0400 Subject: tracing: Add binary '&' filter for events There are some cases when filtering on a set flag of a field of a tracepoint is useful. But currently the only filtering commands for numbered fields is ==, !=, <, <=, >, >=. This does not help when you just want to trace if a specific flag is set. For example: > # sudo trace-cmd record -e brcmfmac:brcmf_dbg -f 'level & 0x40000' > disable all > enable brcmfmac:brcmf_dbg > path = /sys/kernel/debug/tracing/events/brcmfmac/brcmf_dbg/enable > (level & 0x40000) > ^ > parse_error: Invalid operator > When trying to trace brcmf_dbg when level has its 1 << 18 bit set, the filter fails to perform. By allowing a binary '&' operation, this gives the user the ability to test a bit. Note, a binary '|' is not added, as it doesn't make sense as fields must be compared to constants (for now), and ORing a constant will always return true. Link: http://lkml.kernel.org/r/1371057385.9844.261.camel@gandalf.local.home Suggested-by: Arend van Spriel Tested-by: Arend van Spriel Signed-off-by: Steven Rostedt --- Documentation/trace/events.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt index bb24c2a0e..4191124 100644 --- a/Documentation/trace/events.txt +++ b/Documentation/trace/events.txt @@ -183,7 +183,7 @@ The relational-operators depend on the type of the field being tested: The operators available for numeric fields are: -==, !=, <, <=, >, >= +==, !=, <, <=, >, >=, & And for string fields they are: -- cgit v1.1 From c3e13c7c0605677a2c94957b39157f4501cea9a8 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" Date: Mon, 17 Jun 2013 10:59:17 -0400 Subject: tracing: Update documentation on tracepoint glob matching b0f1a59a "tracing/filters: Use a different op for glob match" added glob matching to tracepoint filter strings. It uses the ftrace function tracing glob matching facility that allows for the wild card character (*) to be used at the start and/or end of the matching string. But the documentation still states that the filtering only allows for exact string matches. Cc: Li Zefan Signed-off-by: Steven Rostedt --- Documentation/trace/events.txt | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt index 4191124..37732a2 100644 --- a/Documentation/trace/events.txt +++ b/Documentation/trace/events.txt @@ -187,9 +187,18 @@ The operators available for numeric fields are: And for string fields they are: -==, != +==, !=, ~ -Currently, only exact string matches are supported. +The glob (~) only accepts a wild card character (*) at the start and or +end of the string. For example: + + prev_comm ~ "*sh" + prev_comm ~ "sh*" + prev_comm ~ "*sh*" + +But does not allow for it to be within the string: + + prev_comm ~ "ba*sh" <-- is invalid 5.2 Setting filters ------------------- -- cgit v1.1 From de7edd31457b626e54a0b2a7e8ff4d65492f01ad Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (Red Hat)" Date: Fri, 14 Jun 2013 16:21:43 -0400 Subject: tracing: Disable tracing on warning Add a traceoff_on_warning option in both the kernel command line as well as a sysctl option. When set, any WARN*() function that is hit will cause the tracing_on variable to be cleared, which disables writing to the ring buffer. This is useful especially when tracing a bug with function tracing. When a warning is hit, the print caused by the warning can flood the trace with the functions that producing the output for the warning. This can make the resulting trace useless by either hiding where the bug happened, or worse, by overflowing the buffer and losing the trace of the bug totally. Acked-by: Peter Zijlstra Signed-off-by: Steven Rostedt --- Documentation/kernel-parameters.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 6e3b18a..729d0b9 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3069,6 +3069,19 @@ bytes respectively. Such letter suffixes can also be entirely omitted. See also Documentation/trace/ftrace.txt "trace options" section. + traceoff_on_warning + [FTRACE] enable this option to disable tracing when a + warning is hit. This turns off "tracing_on". Tracing can + be enabled again by echoing '1' into the "tracing_on" + file located in /sys/kernel/debug/tracing/ + + This option is useful, as it disables the trace before + the WARNING dump is called, which prevents the trace to + be filled with content caused by the warning output. + + This option can also be set at run time via the sysctl + option: kernel/traceoff_on_warning + transparent_hugepage= [KNL] Format: [always|madvise|never] -- cgit v1.1 From 5ffd229c02731a91d08ca21e76b503c5bbb5c095 Mon Sep 17 00:00:00 2001 From: Alexey Kardashevskiy Date: Tue, 21 May 2013 13:33:10 +1000 Subject: powerpc/vfio: Implement IOMMU driver for VFIO VFIO implements platform independent stuff such as a PCI driver, BAR access (via read/write on a file descriptor or direct mapping when possible) and IRQ signaling. The platform dependent part includes IOMMU initialization and handling. This implements an IOMMU driver for VFIO which does mapping/unmapping pages for the guest IO and provides information about DMA window (required by a POWER guest). Cc: David Gibson Signed-off-by: Alexey Kardashevskiy Signed-off-by: Paul Mackerras Acked-by: Alex Williamson Signed-off-by: Benjamin Herrenschmidt --- Documentation/vfio.txt | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) (limited to 'Documentation') diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt index 8eda363..c55533c 100644 --- a/Documentation/vfio.txt +++ b/Documentation/vfio.txt @@ -283,6 +283,69 @@ a direct pass through for VFIO_DEVICE_* ioctls. The read/write/mmap interfaces implement the device region access defined by the device's own VFIO_DEVICE_GET_REGION_INFO ioctl. + +PPC64 sPAPR implementation note +------------------------------------------------------------------------------- + +This implementation has some specifics: + +1) Only one IOMMU group per container is supported as an IOMMU group +represents the minimal entity which isolation can be guaranteed for and +groups are allocated statically, one per a Partitionable Endpoint (PE) +(PE is often a PCI domain but not always). + +2) The hardware supports so called DMA windows - the PCI address range +within which DMA transfer is allowed, any attempt to access address space +out of the window leads to the whole PE isolation. + +3) PPC64 guests are paravirtualized but not fully emulated. There is an API +to map/unmap pages for DMA, and it normally maps 1..32 pages per call and +currently there is no way to reduce the number of calls. In order to make things +faster, the map/unmap handling has been implemented in real mode which provides +an excellent performance which has limitations such as inability to do +locked pages accounting in real time. + +So 3 additional ioctls have been added: + + VFIO_IOMMU_SPAPR_TCE_GET_INFO - returns the size and the start + of the DMA window on the PCI bus. + + VFIO_IOMMU_ENABLE - enables the container. The locked pages accounting + is done at this point. This lets user first to know what + the DMA window is and adjust rlimit before doing any real job. + + VFIO_IOMMU_DISABLE - disables the container. + + +The code flow from the example above should be slightly changed: + + ..... + /* Add the group to the container */ + ioctl(group, VFIO_GROUP_SET_CONTAINER, &container); + + /* Enable the IOMMU model we want */ + ioctl(container, VFIO_SET_IOMMU, VFIO_SPAPR_TCE_IOMMU) + + /* Get addition sPAPR IOMMU info */ + vfio_iommu_spapr_tce_info spapr_iommu_info; + ioctl(container, VFIO_IOMMU_SPAPR_TCE_GET_INFO, &spapr_iommu_info); + + if (ioctl(container, VFIO_IOMMU_ENABLE)) + /* Cannot enable container, may be low rlimit */ + + /* Allocate some space and setup a DMA mapping */ + dma_map.vaddr = mmap(0, 1024 * 1024, PROT_READ | PROT_WRITE, + MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); + + dma_map.size = 1024 * 1024; + dma_map.iova = 0; /* 1MB starting at 0x0 from device view */ + dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE; + + /* Check here is .iova/.size are within DMA window from spapr_iommu_info */ + + ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map); + ..... + ------------------------------------------------------------------------------- [1] VFIO was originally an acronym for "Virtual Function I/O" in its -- cgit v1.1 From ef6eb322ce574ba73658a677e83e5da3cfab301b Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 4 Jun 2013 23:17:21 +0200 Subject: clk: nomadik: implement the Nomadik clocks properly The Nomadik clock implementation was a stub just using fixed clocks. This implements the clocks properly instead of relying on them all being on at boot and leaving them all on. The PLLs are on the top locking to the main chrystal oscillator, then the HCLK for the peripherals are below PLL2. The gated clocks are implemented with zero cells and given the clock ID as a property of each node, so every gate need to have its own node in the device tree. This is because the gate registers contain both HCLK gates and PCLK gates, where the latter has HCLK as parent. As can be seen from the register layout, this is a complete mixup, which means all these gates need their own node to properly model parent/child relations for PCLKs apart from the HCLKs. This driver also adds a helpful debugfs file to inspect the hardware state of the clock gates. This is the end result in /clk/clk_summary after applying a proper device tree: ulpiclk 0 0 60000000 mxtal 3 3 19200000 pll2 1 1 864000000 clk48 3 3 48000000 rngcclk 1 1 48000000 usbmclk 0 0 48000000 mshcclk 0 0 48000000 mspclk3 0 0 48000000 x3dclk 0 0 48000000 skeclk 0 0 48000000 owmclk 0 0 48000000 mspclk2 0 0 48000000 mspclk1 0 0 48000000 uart2clk 0 0 48000000 ipbmcclk 0 0 48000000 ipi2cclk 0 0 48000000 usbclk 0 0 48000000 mspclk0 0 0 48000000 uart1clk 1 2 48000000 i2c1clk 0 0 48000000 i2c0clk 0 0 48000000 sdiclk 1 1 48000000 uart0clk 0 0 48000000 sspiclk 0 0 48000000 irdaclk 0 0 48000000 clk72 0 0 72000000 difclk 0 0 72000000 clcdclk 0 0 72000000 clk216 0 0 216000000 hsiclkrx 0 0 216000000 clk108 0 0 108000000 hsiclktx 0 0 108000000 clk27 0 0 27000000 pll1 1 1 264000000 hclk 3 3 264000000 hclkrng 1 1 264000000 hclkusbm 0 0 264000000 hclkcryp 0 0 264000000 hclkhash 0 0 264000000 hclk3d 0 0 264000000 hclkhpi 0 0 264000000 hclksva 0 0 264000000 hclksaa 0 0 264000000 hclkdif 0 0 264000000 hclkusb 0 0 264000000 hclkclcd 0 0 264000000 hclkdma1 0 0 264000000 hclksdram 0 0 264000000 hclksmc 1 1 264000000 hclkdma0 0 0 264000000 pclk 7 9 264000000 pclkmsp3 0 0 264000000 pclkmshc 0 0 264000000 pclkhsem 0 0 264000000 pclkske 0 0 264000000 pclkowm 0 0 264000000 pclkmsp2 0 0 264000000 pclkmsp1 0 0 264000000 pclkuart2 0 0 264000000 pclkxti 0 0 264000000 pclkhsi 0 0 264000000 pclkmsp0 0 0 264000000 pclkuart1 1 1 264000000 pclki2c1 0 0 264000000 pclki2c0 0 0 264000000 pclksdi 1 1 264000000 pclkuart0 1 1 264000000 pclkssp 0 0 264000000 pclkirda 0 0 264000000 timclk 1 1 2400000 Acked-by: Mike Turquette Signed-off-by: Linus Walleij --- .../devicetree/bindings/clock/st,nomadik.txt | 104 +++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/st,nomadik.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/st,nomadik.txt b/Documentation/devicetree/bindings/clock/st,nomadik.txt new file mode 100644 index 0000000..7fc0977 --- /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 -- cgit v1.1 From 89ce43fbbce525f99991ed060b1302bd3fdae9c6 Mon Sep 17 00:00:00 2001 From: Graeme Gregory Date: Wed, 19 Jun 2013 15:24:02 +0300 Subject: mfd: twl-core: Change TWL6025 references to TWL6032 The TWL6025 was never released beyond sample form and was replaced by the PhoenixLite range of chips - TWL6032. Change the references to reference the TWL6032 class and name the registers to twl6032 in line with an actual released chip name to avoid confusion. Currently there are no users of TWL6025 in the code. Signed-off-by: Graeme Gregory Signed-off-by: Oleksandr Kozaruk Acked-by: Lee Jones Reviwed-by: Mark Brown Signed-off-by: Samuel Ortiz --- .../bindings/regulator/twl-regulator.txt | 26 +++++++++++----------- .../devicetree/bindings/usb/twlxxxx-usb.txt | 2 +- 2 files changed, 14 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt b/Documentation/devicetree/bindings/regulator/twl-regulator.txt index 658749b..75b0c16 100644 --- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt @@ -18,20 +18,20 @@ For twl6030 regulators/LDOs - "ti,twl6030-vdd1" for VDD1 SMPS - "ti,twl6030-vdd2" for VDD2 SMPS - "ti,twl6030-vdd3" for VDD3 SMPS -For twl6025 regulators/LDOs +For twl6032 regulators/LDOs - compatible: - - "ti,twl6025-ldo1" for LDO1 LDO - - "ti,twl6025-ldo2" for LDO2 LDO - - "ti,twl6025-ldo3" for LDO3 LDO - - "ti,twl6025-ldo4" for LDO4 LDO - - "ti,twl6025-ldo5" for LDO5 LDO - - "ti,twl6025-ldo6" for LDO6 LDO - - "ti,twl6025-ldo7" for LDO7 LDO - - "ti,twl6025-ldoln" for LDOLN LDO - - "ti,twl6025-ldousb" for LDOUSB LDO - - "ti,twl6025-smps3" for SMPS3 SMPS - - "ti,twl6025-smps4" for SMPS4 SMPS - - "ti,twl6025-vio" for VIO SMPS + - "ti,twl6032-ldo1" for LDO1 LDO + - "ti,twl6032-ldo2" for LDO2 LDO + - "ti,twl6032-ldo3" for LDO3 LDO + - "ti,twl6032-ldo4" for LDO4 LDO + - "ti,twl6032-ldo5" for LDO5 LDO + - "ti,twl6032-ldo6" for LDO6 LDO + - "ti,twl6032-ldo7" for LDO7 LDO + - "ti,twl6032-ldoln" for LDOLN LDO + - "ti,twl6032-ldousb" for LDOUSB LDO + - "ti,twl6032-smps3" for SMPS3 SMPS + - "ti,twl6032-smps4" for SMPS4 SMPS + - "ti,twl6032-vio" for VIO SMPS For twl4030 regulators/LDOs - compatible: - "ti,twl4030-vaux1" for VAUX1 LDO diff --git a/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt b/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt index 36b9aed..0aee0ad 100644 --- a/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt +++ b/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt @@ -8,7 +8,7 @@ TWL6030 USB COMPARATOR usb interrupt number that raises VBUS interrupts when the controller has to act as device - usb-supply : phandle to the regulator device tree node. It should be vusb - if it is twl6030 or ldousb if it is twl6025 subclass. + if it is twl6030 or ldousb if it is twl6032 subclass. twl6030-usb { compatible = "ti,twl6030-usb"; -- cgit v1.1 From 93134c7b40580ae8bb061d278a3ecffd7bbfccd6 Mon Sep 17 00:00:00 2001 From: Kishon Vijay Abraham I Date: Thu, 20 Jun 2013 14:07:37 +0530 Subject: regulator: of: Added a property to indicate bypass mode support Added a property to indicate if the regulator supports bypass mode. Also modified of_get_regulation_constraints() to check for that property and set appropriate constraints. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/regulator.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index ecfc6cc..48a3b8e 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -9,6 +9,7 @@ Optional properties: - regulator-max-microamp: largest current consumers may set - regulator-always-on: boolean, regulator should never be disabled - regulator-boot-on: bootloader/firmware enabled regulator +- regulator-allow-bypass: allow the regulator to go into bypass mode - -supply: phandle to the parent supply/regulator node - regulator-ramp-delay: ramp delay for regulator(in uV/uS) -- cgit v1.1 From d726d8d719b6ac919cc4d5cae73831a2ffe36118 Mon Sep 17 00:00:00 2001 From: Mimi Zohar Date: Mon, 18 Mar 2013 14:48:02 -0400 Subject: integrity: move integrity_audit_msg() This patch moves the integrity_audit_msg() function and defintion to security/integrity/, the parent directory, renames the 'ima_audit' boot command line option to 'integrity_audit', and fixes the Kconfig help text to reflect the actual code. Changelog: - Fixed ifdef inclusion of integrity_audit_msg() (Fengguang Wu) Signed-off-by: Mimi Zohar --- Documentation/kernel-parameters.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index c3bfacb..cb5daa1 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1129,11 +1129,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. The builtin appraise policy appraises all files owned by uid=0. - ima_audit= [IMA] - Format: { "0" | "1" } - 0 -- integrity auditing messages. (Default) - 1 -- enable informational integrity auditing messages. - ima_hash= [IMA] Format: { "sha1" | "md5" } default: "sha1" @@ -1158,6 +1153,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver Format: + integrity_audit=[IMA] + Format: { "0" | "1" } + 0 -- basic integrity auditing messages. (Default) + 1 -- additional integrity auditing messages. + intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option on Enable intel iommu driver. -- cgit v1.1 From f39901c1befa556bc91902516a3e2e460000b4a8 Mon Sep 17 00:00:00 2001 From: Seth Heasley Date: Wed, 19 Jun 2013 16:59:57 -0700 Subject: i2c: i801: SMBus patch for Intel Coleto Creek DeviceIDs This patch adds the i801 SMBus Controller DeviceIDs for the Intel Coleto Creek PCH. Signed-off-by: Seth Heasley Signed-off-by: Wolfram Sang --- Documentation/i2c/busses/i2c-i801 | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index d55b8ab..d29dea0 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -24,6 +24,7 @@ Supported adapters: * Intel Lynx Point-LP (PCH) * Intel Avoton (SOC) * Intel Wellsburg (PCH) + * Intel Coleto Creek (PCH) Datasheets: Publicly available at the Intel website On Intel Patsburg and later chipsets, both the normal host SMBus controller -- cgit v1.1 From 2dbfe74868dd0ed127b6758118468fe275e62508 Mon Sep 17 00:00:00 2001 From: Christian Daudt Date: Fri, 10 May 2013 00:10:07 -0700 Subject: ARM: mmc: bcm281xx SDHCI driver (dt mods) Add SDHCI bindings for the Broadcom 281xx SoCs. Changes from V2: - Documentation cleanups Changes from V1: - split original patch into 2, one for driver and this one for dt Signed-off-by: Christian Daudt Acked-by: Arnd Bergmann --- Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt (limited to 'Documentation') 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 0000000..094ae01 --- /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>; +}; + -- cgit v1.1 From 89ca78a060a101b21cec46f34ad2ade3fafed0d0 Mon Sep 17 00:00:00 2001 From: Lv Zheng Date: Thu, 20 Jun 2013 08:02:44 +0800 Subject: ACPI: Add sysfs ABI documentation Add initial ABI documentation for ACPI devices' sysfs interfaces. Contacts information fields are filled with current ACPI maintainer and the relevant authors are carbon copied. [rjw: Use my e-mail address that's likely to be valid longer.] Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki --- Documentation/ABI/testing/sysfs-bus-acpi | 58 +++++++++++++++++++++++++++++ Documentation/ABI/testing/sysfs-devices-sun | 2 +- 2 files changed, 59 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-acpi (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-acpi b/Documentation/ABI/testing/sysfs-bus-acpi new file mode 100644 index 0000000..7fa9cbc --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-acpi @@ -0,0 +1,58 @@ +What: /sys/bus/acpi/devices/.../path +Date: December 2006 +Contact: Rafael J. Wysocki +Description: + This attribute indicates the full path of ACPI namespace + object associated with the device object. For example, + \_SB_.PCI0. + This file is not present for device objects representing + fixed ACPI hardware features (like power and sleep + buttons). + +What: /sys/bus/acpi/devices/.../modalias +Date: July 2007 +Contact: Rafael J. Wysocki +Description: + This attribute indicates the PNP IDs of the device object. + That is acpi:HHHHHHHH:[CCCCCCC:]. Where each HHHHHHHH or + CCCCCCCC contains device object's PNPID (_HID or _CID). + +What: /sys/bus/acpi/devices/.../hid +Date: April 2005 +Contact: Rafael J. Wysocki +Description: + This attribute indicates the hardware ID (_HID) of the + device object. For example, PNP0103. + This file is present for device objects having the _HID + control method. + +What: /sys/bus/acpi/devices/.../description +Date: October 2012 +Contact: Rafael J. Wysocki +Description: + This attribute contains the output of the device object's + _STR control method, if present. + +What: /sys/bus/acpi/devices/.../adr +Date: October 2012 +Contact: Rafael J. Wysocki +Description: + This attribute contains the output of the device object's + _ADR control method, which is present for ACPI device + objects representing devices having standard enumeration + algorithms, such as PCI. + +What: /sys/bus/acpi/devices/.../uid +Date: October 2012 +Contact: Rafael J. Wysocki +Description: + This attribute contains the output of the device object's + _UID control method, if present. + +What: /sys/bus/acpi/devices/.../eject +Date: December 2006 +Contact: Rafael J. Wysocki +Description: + Writing 1 to this attribute will trigger hot removal of + this device object. This file exists for every device + object that has _EJ0 method. diff --git a/Documentation/ABI/testing/sysfs-devices-sun b/Documentation/ABI/testing/sysfs-devices-sun index 86be984..625ce4b 100644 --- a/Documentation/ABI/testing/sysfs-devices-sun +++ b/Documentation/ABI/testing/sysfs-devices-sun @@ -1,4 +1,4 @@ -Whatt: /sys/devices/.../sun +What: /sys/devices/.../sun Date: October 2012 Contact: Yasuaki Ishimatsu Description: -- cgit v1.1 From c76911bc6b0aa6280bee01ab01a7c790029c47ef Mon Sep 17 00:00:00 2001 From: Lv Zheng Date: Thu, 20 Jun 2013 08:03:13 +0800 Subject: ACPI: Add ACPI namespace documentation ACPI is implemented as a subsystem in Linux, it creates a device tree by mapping specific ACPI namespace objects (Device/Processor/PowerResource/ThermalZone) into Linux device objects. This patch adds documentation for the ACPI device tree. Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/namespace.txt | 395 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 Documentation/acpi/namespace.txt (limited to 'Documentation') diff --git a/Documentation/acpi/namespace.txt b/Documentation/acpi/namespace.txt new file mode 100644 index 0000000..260f6a3 --- /dev/null +++ b/Documentation/acpi/namespace.txt @@ -0,0 +1,395 @@ +ACPI Device Tree - Representation of ACPI Namespace + +Copyright (C) 2013, Intel Corporation +Author: Lv Zheng + + +Abstract: + +The Linux ACPI subsystem converts ACPI namespace objects into a Linux +device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon +receiving ACPI hotplug notification events. For each device object in this +hierarchy there is a corresponding symbolic link in the +/sys/bus/acpi/devices. +This document illustrates the structure of the ACPI device tree. + + +Credit: + +Thanks for the help from Zhang Rui and Rafael J. +Wysocki . + + +1. ACPI Definition Blocks + + The ACPI firmware sets up RSDP (Root System Description Pointer) in the + system memory address space pointing to the XSDT (Extended System + Description Table). The XSDT always points to the FADT (Fixed ACPI + Description Table) using its first entry, the data within the FADT + includes various fixed-length entries that describe fixed ACPI features + of the hardware. The FADT contains a pointer to the DSDT + (Differentiated System Descripition Table). The XSDT also contains + entries pointing to possibly multiple SSDTs (Secondary System + Description Table). + + The DSDT and SSDT data is organized in data structures called definition + blocks that contain definitions of various objects, including ACPI + control methods, encoded in AML (ACPI Machine Language). The data block + of the DSDT along with the contents of SSDTs represents a hierarchical + data structure called the ACPI namespace whose topology reflects the + structure of the underlying hardware platform. + + The relationships between ACPI System Definition Tables described above + are illustrated in the following diagram. + + +---------+ +-------+ +--------+ +------------------------+ + | RSDP | +->| XSDT | +->| FADT | | +-------------------+ | + +---------+ | +-------+ | +--------+ +-|->| DSDT | | + | Pointer | | | Entry |-+ | ...... | | | +-------------------+ | + +---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | | + | Pointer |-+ | ..... | | ...... | | +-------------------+ | + +---------+ +-------+ +--------+ | +-------------------+ | + | Entry |------------------|->| SSDT | | + +- - - -+ | +-------------------| | + | Entry | - - - - - - - -+ | | Definition Blocks | | + +- - - -+ | | +-------------------+ | + | | +- - - - - - - - - -+ | + +-|->| SSDT | | + | +-------------------+ | + | | Definition Blocks | | + | +- - - - - - - - - -+ | + +------------------------+ + | + OSPM Loading | + \|/ + +----------------+ + | ACPI Namespace | + +----------------+ + + Figure 1. ACPI Definition Blocks + + NOTE: RSDP can also contain a pointer to the RSDT (Root System + Description Table). Platforms provide RSDT to enable + compatibility with ACPI 1.0 operating systems. The OS is expected + to use XSDT, if present. + + +2. Example ACPI Namespace + + All definition blocks are loaded into a single namespace. The namespace + is a hierarchy of objects identified by names and paths. + The following naming conventions apply to object names in the ACPI + namespace: + 1. All names are 32 bits long. + 2. The first byte of a name must be one of 'A' - 'Z', '_'. + 3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0' + - '9', '_'. + 4. Names starting with '_' are reserved by the ACPI specification. + 5. The '\' symbol represents the root of the namespace (i.e. names + prepended with '\' are relative to the namespace root). + 6. The '^' symbol represents the parent of the current namespace node + (i.e. names prepended with '^' are relative to the parent of the + current namespace node). + + The figure below shows an example ACPI namespace. + + +------+ + | \ | Root + +------+ + | + | +------+ + +-| _PR | Scope(_PR): the processor namespace + | +------+ + | | + | | +------+ + | +-| CPU0 | Processor(CPU0): the first processor + | +------+ + | + | +------+ + +-| _SB | Scope(_SB): the system bus namespace + | +------+ + | | + | | +------+ + | +-| LID0 | Device(LID0); the lid device + | | +------+ + | | | + | | | +------+ + | | +-| _HID | Name(_HID, "PNP0C0D"): the hardware ID + | | | +------+ + | | | + | | | +------+ + | | +-| _STA | Method(_STA): the status control method + | | +------+ + | | + | | +------+ + | +-| PCI0 | Device(PCI0); the PCI root bridge + | +------+ + | | + | | +------+ + | +-| _HID | Name(_HID, "PNP0A08"): the hardware ID + | | +------+ + | | + | | +------+ + | +-| _CID | Name(_CID, "PNP0A03"): the compatible ID + | | +------+ + | | + | | +------+ + | +-| RP03 | Scope(RP03): the PCI0 power scope + | | +------+ + | | | + | | | +------+ + | | +-| PXP3 | PowerResource(PXP3): the PCI0 power resource + | | +------+ + | | + | | +------+ + | +-| GFX0 | Device(GFX0): the graphics adapter + | +------+ + | | + | | +------+ + | +-| _ADR | Name(_ADR, 0x00020000): the PCI bus address + | | +------+ + | | + | | +------+ + | +-| DD01 | Device(DD01): the LCD output device + | +------+ + | | + | | +------+ + | +-| _BCL | Method(_BCL): the backlight control method + | +------+ + | + | +------+ + +-| _TZ | Scope(_TZ): the thermal zone namespace + | +------+ + | | + | | +------+ + | +-| FN00 | PowerResource(FN00): the FAN0 power resource + | | +------+ + | | + | | +------+ + | +-| FAN0 | Device(FAN0): the FAN0 cooling device + | | +------+ + | | | + | | | +------+ + | | +-| _HID | Name(_HID, "PNP0A0B"): the hardware ID + | | +------+ + | | + | | +------+ + | +-| TZ00 | ThermalZone(TZ00); the FAN thermal zone + | +------+ + | + | +------+ + +-| _GPE | Scope(_GPE): the GPE namespace + +------+ + + Figure 2. Example ACPI Namespace + + +3. Linux ACPI Device Objects + + The Linux kernel's core ACPI subsystem creates struct acpi_device + objects for ACPI namespace objects representing devices, power resources + processors, thermal zones. Those objects are exported to user space via + sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The + format of their names is , where 'bus_id' refers to the + ACPI namespace representation of the given object and 'instance' is used + for distinguishing different object of the same 'bus_id' (it is + two-digit decimal representation of an unsigned integer). + + The value of 'bus_id' depends on the type of the object whose name it is + part of as listed in the table below. + + +---+-----------------+-------+----------+ + | | Object/Feature | Table | bus_id | + +---+-----------------+-------+----------+ + | N | Root | xSDT | LNXSYSTM | + +---+-----------------+-------+----------+ + | N | Device | xSDT | _HID | + +---+-----------------+-------+----------+ + | N | Processor | xSDT | LNXCPU | + +---+-----------------+-------+----------+ + | N | ThermalZone | xSDT | LNXTHERM | + +---+-----------------+-------+----------+ + | N | PowerResource | xSDT | LNXPOWER | + +---+-----------------+-------+----------+ + | N | Other Devices | xSDT | device | + +---+-----------------+-------+----------+ + | F | PWR_BUTTON | FADT | LNXPWRBN | + +---+-----------------+-------+----------+ + | F | SLP_BUTTON | FADT | LNXSLPBN | + +---+-----------------+-------+----------+ + | M | Video Extension | xSDT | LNXVIDEO | + +---+-----------------+-------+----------+ + | M | ATA Controller | xSDT | LNXIOBAY | + +---+-----------------+-------+----------+ + | M | Docking Station | xSDT | LNXDOCK | + +---+-----------------+-------+----------+ + + Table 1. ACPI Namespace Objects Mapping + + The following rules apply when creating struct acpi_device objects on + the basis of the contents of ACPI System Description Tables (as + indicated by the letter in the first column and the notation in the + second column of the table above): + N: + The object's source is an ACPI namespace node (as indicated by the + named object's type in the second column). In that case the object's + directory in sysfs will contain the 'path' attribute whose value is + the full path to the node from the namespace root. + struct acpi_device objects are created for the ACPI namespace nodes + whose _STA control methods return PRESENT or FUNCTIONING. The power + resource nodes or nodes without _STA are assumed to be both PRESENT + and FUNCTIONING. + F: + The struct acpi_device object is created for a fixed hardware + feature (as indicated by the fixed feature flag's name in the second + column), so its sysfs directory will not contain the 'path' + attribute. + M: + The struct acpi_device object is created for an ACPI namespace node + with specific control methods (as indicated by the ACPI defined + device's type in the second column). The 'path' attribute containing + its namespace path will be present in its sysfs directory. For + example, if the _BCL method is present for an ACPI namespace node, a + struct acpi_device object with LNXVIDEO 'bus_id' will be created for + it. + + The third column of the above table indicates which ACPI System + Description Tables contain information used for the creation of the + struct acpi_device objects represented by the given row (xSDT means DSDT + or SSDT). + + The forth column of the above table indicates the 'bus_id' generation + rule of the struct acpi_device object: + _HID: + _HID in the last column of the table means that the object's bus_id + is derived from the _HID/_CID identification objects present under + the corresponding ACPI namespace node. The object's sysfs directory + will then contain the 'hid' and 'modalias' attributes that can be + used to retrieve the _HID and _CIDs of that object. + LNXxxxxx: + The 'modalias' attribute is also present for struct acpi_device + objects having bus_id of the "LNXxxxxx" form (pseudo devices), in + which cases it contains the bus_id string itself. + device: + 'device' in the last column of the table indicates that the object's + bus_id cannot be determined from _HID/_CID of the corresponding + ACPI namespace node, although that object represents a device (for + example, it may be a PCI device with _ADR defined and without _HID + or _CID). In that case the string 'device' will be used as the + object's bus_id. + + +4. Linux ACPI Physical Device Glue + + ACPI device (i.e. struct acpi_device) objects may be linked to other + objects in the Linux' device hierarchy that represent "physical" devices + (for example, devices on the PCI bus). If that happens, it means that + the ACPI device object is a "companion" of a device otherwise + represented in a different way and is used (1) to provide configuration + information on that device which cannot be obtained by other means and + (2) to do specific things to the device with the help of its ACPI + control methods. One ACPI device object may be linked this way to + multiple "physical" devices. + + If an ACPI device object is linked to a "physical" device, its sysfs + directory contains the "physical_node" symbolic link to the sysfs + directory of the target device object. In turn, the target device's + sysfs directory will then contain the "firmware_node" symbolic link to + the sysfs directory of the companion ACPI device object. + The linking mechanism relies on device identification provided by the + ACPI namespace. For example, if there's an ACPI namespace object + representing a PCI device (i.e. a device object under an ACPI namespace + object representing a PCI bridge) whose _ADR returns 0x00020000 and the + bus number of the parent PCI bridge is 0, the sysfs directory + representing the struct acpi_device object created for that ACPI + namespace object will contain the 'physical_node' symbolic link to the + /sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the + corresponding PCI device. + + The linking mechanism is generally bus-specific. The core of its + implementation is located in the drivers/acpi/glue.c file, but there are + complementary parts depending on the bus types in question located + elsewhere. For example, the PCI-specific part of it is located in + drivers/pci/pci-acpi.c. + + +5. Example Linux ACPI Device Tree + + The sysfs hierarchy of struct acpi_device objects corresponding to the + example ACPI namespace illustrated in Figure 2 with the addition of + fixed PWR_BUTTON/SLP_BUTTON devices is shown below. + + +--------------+---+-----------------+ + | LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: | + +--------------+---+-----------------+ + | + | +-------------+-----+----------------+ + +-| LNXPWRBN:00 | N/A | acpi:LNXPWRBN: | + | +-------------+-----+----------------+ + | + | +-------------+-----+----------------+ + +-| LNXSLPBN:00 | N/A | acpi:LNXSLPBN: | + | +-------------+-----+----------------+ + | + | +-----------+------------+--------------+ + +-| LNXCPU:00 | \_PR_.CPU0 | acpi:LNXCPU: | + | +-----------+------------+--------------+ + | + | +-------------+-------+----------------+ + +-| LNXSYBUS:00 | \_SB_ | acpi:LNXSYBUS: | + | +-------------+-------+----------------+ + | | + | | +- - - - - - - +- - - - - - +- - - - - - - -+ + | +-| * PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: | + | | +- - - - - - - +- - - - - - +- - - - - - - -+ + | | + | | +------------+------------+-----------------------+ + | +-| PNP0A08:00 | \_SB_.PCI0 | acpi:PNP0A08:PNP0A03: | + | +------------+------------+-----------------------+ + | | + | | +-----------+-----------------+-----+ + | +-| device:00 | \_SB_.PCI0.RP03 | N/A | + | | +-----------+-----------------+-----+ + | | | + | | | +-------------+----------------------+----------------+ + | | +-| LNXPOWER:00 | \_SB_.PCI0.RP03.PXP3 | acpi:LNXPOWER: | + | | +-------------+----------------------+----------------+ + | | + | | +-------------+-----------------+----------------+ + | +-| LNXVIDEO:00 | \_SB_.PCI0.GFX0 | acpi:LNXVIDEO: | + | +-------------+-----------------+----------------+ + | | + | | +-----------+-----------------+-----+ + | +-| device:01 | \_SB_.PCI0.DD01 | N/A | + | +-----------+-----------------+-----+ + | + | +-------------+-------+----------------+ + +-| LNXSYBUS:01 | \_TZ_ | acpi:LNXSYBUS: | + +-------------+-------+----------------+ + | + | +-------------+------------+----------------+ + +-| LNXPOWER:0a | \_TZ_.FN00 | acpi:LNXPOWER: | + | +-------------+------------+----------------+ + | + | +------------+------------+---------------+ + +-| PNP0C0B:00 | \_TZ_.FAN0 | acpi:PNP0C0B: | + | +------------+------------+---------------+ + | + | +-------------+------------+----------------+ + +-| LNXTHERM:00 | \_TZ_.TZ00 | acpi:LNXTHERM: | + +-------------+------------+----------------+ + + Figure 3. Example Linux ACPI Device Tree + + NOTE: Each node is represented as "object/path/modalias", where: + 1. 'object' is the name of the object's directory in sysfs. + 2. 'path' is the ACPI namespace path of the corresponding + ACPI namespace object, as returned by the object's 'path' + sysfs attribute. + 3. 'modalias' is the value of the object's 'modalias' sysfs + attribute (as described earlier in this document). + NOTE: N/A indicates the device object does not have the 'path' or the + 'modalias' attribute. + NOTE: The PNP0C0D device listed above is highlighted (marked by "*") + to indicate it will be created only when its _STA methods return + PRESENT or FUNCTIONING. -- cgit v1.1 From 3afe6dab86b669dd5bcef07b67d3ba7fb12a69a0 Mon Sep 17 00:00:00 2001 From: Aaron Lu Date: Thu, 20 Jun 2013 15:08:55 +0800 Subject: ACPI / video: add description for brightness_switch_enabled Add description for video module's parameter brightness_switch_enabled into kernel-parameters.txt. Signed-off-by: Aaron Lu Signed-off-by: Rafael J. Wysocki --- Documentation/kernel-parameters.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2fe6e76..7f64e0f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -3229,6 +3229,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted. video= [FB] Frame buffer configuration See Documentation/fb/modedb.txt. + video.brightness_switch_enabled= [0,1] + If set to 1, on receiving an ACPI notify event + generated by hotkey, video driver will adjust brightness + level and then send out the event to user space through + the allocated input device; If set to 0, video driver + will only send out the event without touching backlight + brightness level. + default: 1 + virtio_mmio.device= [VMMIO] Memory mapped virtio (platform) device. -- cgit v1.1 From 70e66e4df19167653aba95b4dacbcfd3254a4019 Mon Sep 17 00:00:00 2001 From: Aaron Lu Date: Fri, 21 Jun 2013 00:15:59 +0200 Subject: ACPI / video: move video_extension.txt to Documentation/acpi ACPI video driver is written according to ACPI spec, appendix B: Video Extensions. So it better be put under the acpi directory instead of the power directory. This patch moves the file there without any other change. Signed-off-by: Aaron Lu Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/video_extension.txt | 37 +++++++++++++++++++++++++++++++++ Documentation/power/video_extension.txt | 37 --------------------------------- 2 files changed, 37 insertions(+), 37 deletions(-) create mode 100644 Documentation/acpi/video_extension.txt delete mode 100644 Documentation/power/video_extension.txt (limited to 'Documentation') diff --git a/Documentation/acpi/video_extension.txt b/Documentation/acpi/video_extension.txt new file mode 100644 index 0000000..b2f9b15 --- /dev/null +++ b/Documentation/acpi/video_extension.txt @@ -0,0 +1,37 @@ +ACPI video extensions +~~~~~~~~~~~~~~~~~~~~~ + +This driver implement the ACPI Extensions For Display Adapters for +integrated graphics devices on motherboard, as specified in ACPI 2.0 +Specification, Appendix B, allowing to perform some basic control like +defining the video POST device, retrieving EDID information or to +setup a video output, etc. Note that this is an ref. implementation +only. It may or may not work for your integrated video device. + +Interfaces exposed to userland through /proc/acpi/video: + +VGA/info : display the supported video bus device capability like Video ROM, CRT/LCD/TV. +VGA/ROM : Used to get a copy of the display devices' ROM data (up to 4k). +VGA/POST_info : Used to determine what options are implemented. +VGA/POST : Used to get/set POST device. +VGA/DOS : Used to get/set ownership of output switching: + Please refer ACPI spec B.4.1 _DOS +VGA/CRT : CRT output +VGA/LCD : LCD output +VGA/TVO : TV output +VGA/*/brightness : Used to get/set brightness of output device + +Notify event through /proc/acpi/event: + +#define ACPI_VIDEO_NOTIFY_SWITCH 0x80 +#define ACPI_VIDEO_NOTIFY_PROBE 0x81 +#define ACPI_VIDEO_NOTIFY_CYCLE 0x82 +#define ACPI_VIDEO_NOTIFY_NEXT_OUTPUT 0x83 +#define ACPI_VIDEO_NOTIFY_PREV_OUTPUT 0x84 + +#define ACPI_VIDEO_NOTIFY_CYCLE_BRIGHTNESS 0x82 +#define ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS 0x83 +#define ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS 0x84 +#define ACPI_VIDEO_NOTIFY_ZERO_BRIGHTNESS 0x85 +#define ACPI_VIDEO_NOTIFY_DISPLAY_OFF 0x86 + diff --git a/Documentation/power/video_extension.txt b/Documentation/power/video_extension.txt deleted file mode 100644 index b2f9b15..0000000 --- a/Documentation/power/video_extension.txt +++ /dev/null @@ -1,37 +0,0 @@ -ACPI video extensions -~~~~~~~~~~~~~~~~~~~~~ - -This driver implement the ACPI Extensions For Display Adapters for -integrated graphics devices on motherboard, as specified in ACPI 2.0 -Specification, Appendix B, allowing to perform some basic control like -defining the video POST device, retrieving EDID information or to -setup a video output, etc. Note that this is an ref. implementation -only. It may or may not work for your integrated video device. - -Interfaces exposed to userland through /proc/acpi/video: - -VGA/info : display the supported video bus device capability like Video ROM, CRT/LCD/TV. -VGA/ROM : Used to get a copy of the display devices' ROM data (up to 4k). -VGA/POST_info : Used to determine what options are implemented. -VGA/POST : Used to get/set POST device. -VGA/DOS : Used to get/set ownership of output switching: - Please refer ACPI spec B.4.1 _DOS -VGA/CRT : CRT output -VGA/LCD : LCD output -VGA/TVO : TV output -VGA/*/brightness : Used to get/set brightness of output device - -Notify event through /proc/acpi/event: - -#define ACPI_VIDEO_NOTIFY_SWITCH 0x80 -#define ACPI_VIDEO_NOTIFY_PROBE 0x81 -#define ACPI_VIDEO_NOTIFY_CYCLE 0x82 -#define ACPI_VIDEO_NOTIFY_NEXT_OUTPUT 0x83 -#define ACPI_VIDEO_NOTIFY_PREV_OUTPUT 0x84 - -#define ACPI_VIDEO_NOTIFY_CYCLE_BRIGHTNESS 0x82 -#define ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS 0x83 -#define ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS 0x84 -#define ACPI_VIDEO_NOTIFY_ZERO_BRIGHTNESS 0x85 -#define ACPI_VIDEO_NOTIFY_DISPLAY_OFF 0x86 - -- cgit v1.1 From 86393865f0c9f7002aa1fc2b8bdce11f3aefcebe Mon Sep 17 00:00:00 2001 From: Aaron Lu Date: Thu, 20 Jun 2013 15:08:57 +0800 Subject: ACPI / video: update video_extension.txt for backlight control The ACPI video driver has changed a lot, and it doesn't export interfaces in /proc any more, so the documentation for it should be updated. This update focuses on ACPI video driver's backlight control. Signed-off-by: Aaron Lu Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/video_extension.txt | 121 ++++++++++++++++++++++++++------- 1 file changed, 95 insertions(+), 26 deletions(-) (limited to 'Documentation') diff --git a/Documentation/acpi/video_extension.txt b/Documentation/acpi/video_extension.txt index b2f9b15..78b32ac 100644 --- a/Documentation/acpi/video_extension.txt +++ b/Documentation/acpi/video_extension.txt @@ -8,30 +8,99 @@ defining the video POST device, retrieving EDID information or to setup a video output, etc. Note that this is an ref. implementation only. It may or may not work for your integrated video device. -Interfaces exposed to userland through /proc/acpi/video: - -VGA/info : display the supported video bus device capability like Video ROM, CRT/LCD/TV. -VGA/ROM : Used to get a copy of the display devices' ROM data (up to 4k). -VGA/POST_info : Used to determine what options are implemented. -VGA/POST : Used to get/set POST device. -VGA/DOS : Used to get/set ownership of output switching: - Please refer ACPI spec B.4.1 _DOS -VGA/CRT : CRT output -VGA/LCD : LCD output -VGA/TVO : TV output -VGA/*/brightness : Used to get/set brightness of output device - -Notify event through /proc/acpi/event: - -#define ACPI_VIDEO_NOTIFY_SWITCH 0x80 -#define ACPI_VIDEO_NOTIFY_PROBE 0x81 -#define ACPI_VIDEO_NOTIFY_CYCLE 0x82 -#define ACPI_VIDEO_NOTIFY_NEXT_OUTPUT 0x83 -#define ACPI_VIDEO_NOTIFY_PREV_OUTPUT 0x84 - -#define ACPI_VIDEO_NOTIFY_CYCLE_BRIGHTNESS 0x82 -#define ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS 0x83 -#define ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS 0x84 -#define ACPI_VIDEO_NOTIFY_ZERO_BRIGHTNESS 0x85 -#define ACPI_VIDEO_NOTIFY_DISPLAY_OFF 0x86 +The ACPI video driver does 3 things regarding backlight control: +1 Export a sysfs interface for user space to control backlight level + +If the ACPI table has a video device, and acpi_backlight=vendor kernel +command line is not present, the driver will register a backlight device +and set the required backlight operation structure for it for the sysfs +interface control. For every registered class device, there will be a +directory named acpi_videoX under /sys/class/backlight. + +The backlight sysfs interface has a standard definition here: +Documentation/ABI/stable/sysfs-class-backlight. + +And what ACPI video driver does is: +actual_brightness: on read, control method _BQC will be evaluated to +get the brightness level the firmware thinks it is at; +bl_power: not implemented, will set the current brightness instead; +brightness: on write, control method _BCM will run to set the requested +brightness level; +max_brightness: Derived from the _BCL package(see below); +type: firmware + +Note that ACPI video backlight driver will always use index for +brightness, actual_brightness and max_brightness. So if we have +the following _BCL package: + +Method (_BCL, 0, NotSerialized) +{ + Return (Package (0x0C) + { + 0x64, + 0x32, + 0x0A, + 0x14, + 0x1E, + 0x28, + 0x32, + 0x3C, + 0x46, + 0x50, + 0x5A, + 0x64 + }) +} + +The first two levels are for when laptop are on AC or on battery and are +not used by Linux currently. The remaining 10 levels are supported levels +that we can choose from. The applicable index values are from 0 (that +corresponds to the 0x0A brightness value) to 9 (that corresponds to the +0x64 brightness value) inclusive. Each of those index values is regarded +as a "brightness level" indicator. Thus from the user space perspective +the range of available brightness levels is from 0 to 9 (max_brightness) +inclusive. + +2 Notify user space about hotkey event + +There are generally two cases for hotkey event reporting: +i) For some laptops, when user presses the hotkey, a scancode will be + generated and sent to user space through the input device created by + the keyboard driver as a key type input event, with proper remap, the + following key code will appear to user space: + + EV_KEY, KEY_BRIGHTNESSUP + EV_KEY, KEY_BRIGHTNESSDOWN + etc. + +For this case, ACPI video driver does not need to do anything(actually, +it doesn't even know this happened). + +ii) For some laptops, the press of the hotkey will not generate the + scancode, instead, firmware will notify the video device ACPI node + about the event. The event value is defined in the ACPI spec. ACPI + video driver will generate an key type input event according to the + notify value it received and send the event to user space through the + input device it created: + + event keycode + 0x86 KEY_BRIGHTNESSUP + 0x87 KEY_BRIGHTNESSDOWN + etc. + +so this would lead to the same effect as case i) now. + +Once user space tool receives this event, it can modify the backlight +level through the sysfs interface. + +3 Change backlight level in the kernel + +This works for machines covered by case ii) in Section 2. Once the driver +received a notification, it will set the backlight level accordingly. This does +not affect the sending of event to user space, they are always sent to user +space regardless of whether or not the video module controls the backlight level +directly. This behaviour can be controlled through the brightness_switch_enabled +module parameter as documented in kernel-parameters.txt. It is recommended to +disable this behaviour once a GUI environment starts up and wants to have full +control of the backlight level. -- cgit v1.1 From 646572c77db7c42beb3d091915c8f97359100c47 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Thu, 13 Jun 2013 16:59:40 +0200 Subject: clk: add support for Rockchip gate clocks This adds basic support for gate-clocks on Rockchip SoCs. There are 16 gates in each register and use the HIWORD_MASK mechanism for changing gate settings. The gate registers form a continuos block which makes the dt node structure a matter of taste, as either all 160 gates can be put into one gate clock spanning all registers or they can be divided into the 10 individual gates containing 16 clocks each. The code supports both approaches. Signed-off-by: Heiko Stuebner Signed-off-by: Mike Turquette --- .../devicetree/bindings/clock/rockchip.txt | 74 ++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/rockchip.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/rockchip.txt b/Documentation/devicetree/bindings/clock/rockchip.txt new file mode 100644 index 0000000..a891c82 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip.txt @@ -0,0 +1,74 @@ +Device Tree Clock bindings for arch-rockchip + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +== Gate clocks == + +The gate registers form a continuos block which makes the dt node +structure a matter of taste, as either all gates can be put into +one gate clock spanning all registers or they can be divided into +the 10 individual gates containing 16 clocks each. +The code supports both approaches. + +Required properties: +- compatible : "rockchip,rk2928-gate-clk" +- reg : shall be the control register address(es) for the clock. +- #clock-cells : from common clock binding; shall be set to 1 +- clock-output-names : the corresponding gate names that the clock controls +- clocks : should contain the parent clock for each individual gate, + therefore the number of clocks elements should match the number of + clock-output-names + +Example using multiple gate clocks: + + clk_gates0: gate-clk@200000d0 { + compatible = "rockchip,rk2928-gate-clk"; + reg = <0x200000d0 0x4>; + clocks = <&dummy>, <&dummy>, + <&dummy>, <&dummy>, + <&dummy>, <&dummy>, + <&dummy>, <&dummy>, + <&dummy>, <&dummy>, + <&dummy>, <&dummy>, + <&dummy>, <&dummy>, + <&dummy>, <&dummy>; + + clock-output-names = + "gate_core_periph", "gate_cpu_gpll", + "gate_ddrphy", "gate_aclk_cpu", + "gate_hclk_cpu", "gate_pclk_cpu", + "gate_atclk_cpu", "gate_i2s0", + "gate_i2s0_frac", "gate_i2s1", + "gate_i2s1_frac", "gate_i2s2", + "gate_i2s2_frac", "gate_spdif", + "gate_spdif_frac", "gate_testclk"; + + #clock-cells = <1>; + }; + + clk_gates1: gate-clk@200000d4 { + compatible = "rockchip,rk2928-gate-clk"; + reg = <0x200000d4 0x4>; + clocks = <&xin24m>, <&xin24m>, + <&xin24m>, <&dummy>, + <&dummy>, <&xin24m>, + <&xin24m>, <&dummy>, + <&xin24m>, <&dummy>, + <&xin24m>, <&dummy>, + <&xin24m>, <&dummy>, + <&xin24m>, <&dummy>; + + clock-output-names = + "gate_timer0", "gate_timer1", + "gate_timer2", "gate_jtag", + "gate_aclk_lcdc1_src", "gate_otgphy0", + "gate_otgphy1", "gate_ddr_gpll", + "gate_uart0", "gate_frac_uart0", + "gate_uart1", "gate_frac_uart1", + "gate_uart2", "gate_frac_uart2", + "gate_uart3", "gate_frac_uart3"; + + #clock-cells = <1>; + }; -- cgit v1.1 From 7542a04b1515f0f878b267beb233c4ef067243fb Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Tue, 23 Apr 2013 04:52:59 -0700 Subject: leds: lp55xx: add support for Device Tree bindings This patch allows the lp5521 driver to be successfully probed and initialised when Device Tree support is enabled. Based on a patch by Gabriel Fernandez, rewritten in accordance with review feedback. Cc: Gabriel Fernandez Signed-off-by: Linus Walleij Acked-by: Milo Kim Signed-off-by: Bryan Wu --- .../devicetree/bindings/leds/leds-lp55xx.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt new file mode 100644 index 0000000..348c88e --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt @@ -0,0 +1,21 @@ +Binding for National Semiconductor LP55xx Led Drivers + +Required properties: +- compatible: "national,lp5521" or "national,lp5523" +- label: Used for naming LEDs +- num-channel: Number of LED channels +- led-cur: Current setting at each led channel (mA x10, 0 if led is not connected) +- max-cur: Maximun current at each led channel. +- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external) + +example: + +lp5521@32 { + compatible = "national,lp5521"; + reg = <0x32>; + label = "lp5521_pri"; + num-channel = /bits/ 8 <3>; + led-cur = /bits/ 8 <0x2f 0x2f 0x2f>; + max-cur = /bits/ 8 <0x5f 0x5f 0x5f>; + clock-mode = /bits/8 <2>; +}; -- cgit v1.1 From 2dac912809490ea3a6e5c16b83b54a08f36fc3d9 Mon Sep 17 00:00:00 2001 From: "Kim, Milo" Date: Tue, 7 May 2013 00:14:48 -0700 Subject: leds: lp55xx: support dynamic channel settings in the device tree structure Currently, the LP55xx DT structure supports max 3 channels. However, LP5523 has max 9 channels and LP5562 has 4 channels. To enhance this constraint, the DT structure has been changed. (a) Use the child node for various channel settings instead of fixed array (b) Remove 'num_channel' property. This value can be retrieved by counting the children node. (c) 'chan-name' property supported (d) Documentation updates for LP5521 and LP5523 (cooloney@gmail.com: fix a coding style issue in leds-lp55xx.txt) Cc: Gabriel Fernandez Signed-off-by: Milo(Woogyom) Kim Reviewed-by: Linus Walleij Signed-off-by: Bryan Wu --- .../devicetree/bindings/leds/leds-lp55xx.txt | 109 +++++++++++++++++++-- 1 file changed, 101 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt index 348c88e..1ed6bb0 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt @@ -2,20 +2,113 @@ Binding for National Semiconductor LP55xx Led Drivers Required properties: - compatible: "national,lp5521" or "national,lp5523" -- label: Used for naming LEDs -- num-channel: Number of LED channels +- reg: I2C slave address +- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external) + +Each child has own specific current settings - led-cur: Current setting at each led channel (mA x10, 0 if led is not connected) - max-cur: Maximun current at each led channel. -- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external) -example: +Optional properties: +- label: Used for naming LEDs + +Alternatively, each child can have specific channel name +- chan-name: Name of each channel name + +example 1) LP5521 +3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0', +'lp5521_pri:channel1' and 'lp5521_pri:channel2' lp5521@32 { compatible = "national,lp5521"; reg = <0x32>; label = "lp5521_pri"; - num-channel = /bits/ 8 <3>; - led-cur = /bits/ 8 <0x2f 0x2f 0x2f>; - max-cur = /bits/ 8 <0x5f 0x5f 0x5f>; - clock-mode = /bits/8 <2>; + clock-mode = /bits/ 8 <2>; + + chan0 { + led-cur = /bits/ 8 <0x2f>; + max-cur = /bits/ 8 <0x5f>; + }; + + chan1 { + led-cur = /bits/ 8 <0x2f>; + max-cur = /bits/ 8 <0x5f>; + }; + + chan2 { + led-cur = /bits/ 8 <0x2f>; + max-cur = /bits/ 8 <0x5f>; + }; +}; + +example 2) LP5523 +9 LED channels with specific name. Internal clock used. +The I2C slave address is configurable with ASEL1 and ASEL0 pins. +Available addresses are 32/33/34/35h. + +ASEL1 ASEL0 Address +------------------------- + GND GND 32h + GND VEN 33h + VEN GND 34h + VEN VEN 35h + +lp5523@32 { + compatible = "national,lp5523"; + reg = <0x32>; + clock-mode = /bits/ 8 <1>; + + chan0 { + chan-name = "d1"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + chan1 { + chan-name = "d2"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + chan2 { + chan-name = "d3"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + chan3 { + chan-name = "d4"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + chan4 { + chan-name = "d5"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + chan5 { + chan-name = "d6"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + chan6 { + chan-name = "d7"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + chan7 { + chan-name = "d8"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; + + chan8 { + chan-name = "d9"; + led-cur = /bits/ 8 <0x14>; + max-cur = /bits/ 8 <0x20>; + }; }; -- cgit v1.1 From e015050cc5ea01e4beba3862dcafef9360c77522 Mon Sep 17 00:00:00 2001 From: "Kim, Milo" Date: Tue, 7 May 2013 00:14:49 -0700 Subject: leds: lp5562: support the device tree feature The LP55xx DT structure is applicable to the LP5562 device. The driver and documentation are updated. Compatible property of the DT : LP5521 and LP5223 were manufactured by National Semiconductor. LP5562 is a new device from Texas Instruments. Cc: Gabriel Fernandez Signed-off-by: Milo(Woogyom) Kim Acked-by: Linus Walleij Signed-off-by: Bryan Wu --- .../devicetree/bindings/leds/leds-lp55xx.txt | 37 ++++++++++++++++++++-- 1 file changed, 35 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt index 1ed6bb0..d517688 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt +++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt @@ -1,7 +1,7 @@ -Binding for National Semiconductor LP55xx Led Drivers +Binding for TI/National Semiconductor LP55xx Led Drivers Required properties: -- compatible: "national,lp5521" or "national,lp5523" +- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562" - reg: I2C slave address - clock-mode: Input clock mode, (0: automode, 1: internal, 2: external) @@ -112,3 +112,36 @@ lp5523@32 { max-cur = /bits/ 8 <0x20>; }; }; + +example 3) LP5562 +4 channels are defined. + +lp5562@30 { + compatible = "ti,lp5562"; + reg = <0x30>; + clock-mode = /bits/8 <2>; + + chan0 { + chan-name = "R"; + led-cur = /bits/ 8 <0x20>; + max-cur = /bits/ 8 <0x60>; + }; + + chan1 { + chan-name = "G"; + led-cur = /bits/ 8 <0x20>; + max-cur = /bits/ 8 <0x60>; + }; + + chan2 { + chan-name = "B"; + led-cur = /bits/ 8 <0x20>; + max-cur = /bits/ 8 <0x60>; + }; + + chan3 { + chan-name = "W"; + led-cur = /bits/ 8 <0x20>; + max-cur = /bits/ 8 <0x60>; + }; +}; -- cgit v1.1 From 76abbdde2d95a3807d0dc6bf9f84d03d0dbd4f3d Mon Sep 17 00:00:00 2001 From: H Hartley Sweeten Date: Tue, 11 Jun 2013 10:38:59 -0700 Subject: pwm: Add sysfs interface Add a simple sysfs interface to the generic PWM framework. /sys/class/pwm/ `-- pwmchipN/ for each PWM chip |-- export (w/o) ask the kernel to export a PWM channel |-- npwm (r/o) number of PWM channels in this PWM chip |-- pwmX/ for each exported PWM channel | |-- duty_cycle (r/w) duty cycle (in nanoseconds) | |-- enable (r/w) enable/disable PWM | |-- period (r/w) period (in nanoseconds) | `-- polarity (r/w) polarity of PWM (normal/inversed) `-- unexport (w/o) return a PWM channel to the kernel Based on work by Lars Poeschel. Signed-off-by: H Hartley Sweeten Cc: Thierry Reding Cc: Lars Poeschel Cc: Ryan Mallon Cc: Rob Landley Signed-off-by: Thierry Reding --- Documentation/ABI/testing/sysfs-class-pwm | 79 +++++++++++++++++++++++++++++++ Documentation/pwm.txt | 37 +++++++++++++++ 2 files changed, 116 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-pwm (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-pwm b/Documentation/ABI/testing/sysfs-class-pwm new file mode 100644 index 0000000..c479d77 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-pwm @@ -0,0 +1,79 @@ +What: /sys/class/pwm/ +Date: May 2013 +KernelVersion: 3.11 +Contact: H Hartley Sweeten +Description: + The pwm/ class sub-directory belongs to the Generic PWM + Framework and provides a sysfs interface for using PWM + channels. + +What: /sys/class/pwm/pwmchipN/ +Date: May 2013 +KernelVersion: 3.11 +Contact: H Hartley Sweeten +Description: + A /sys/class/pwm/pwmchipN directory is created for each + probed PWM controller/chip where N is the base of the + PWM chip. + +What: /sys/class/pwm/pwmchipN/npwm +Date: May 2013 +KernelVersion: 3.11 +Contact: H Hartley Sweeten +Description: + The number of PWM channels supported by the PWM chip. + +What: /sys/class/pwm/pwmchipN/export +Date: May 2013 +KernelVersion: 3.11 +Contact: H Hartley Sweeten +Description: + Exports a PWM channel from the PWM chip for sysfs control. + Value is between 0 and /sys/class/pwm/pwmchipN/npwm - 1. + +What: /sys/class/pwm/pwmchipN/unexport +Date: May 2013 +KernelVersion: 3.11 +Contact: H Hartley Sweeten +Description: + Unexports a PWM channel. + +What: /sys/class/pwm/pwmchipN/pwmX +Date: May 2013 +KernelVersion: 3.11 +Contact: H Hartley Sweeten +Description: + A /sys/class/pwm/pwmchipN/pwmX directory is created for + each exported PWM channel where X is the exported PWM + channel number. + +What: /sys/class/pwm/pwmchipN/pwmX/period +Date: May 2013 +KernelVersion: 3.11 +Contact: H Hartley Sweeten +Description: + Sets the PWM signal period in nanoseconds. + +What: /sys/class/pwm/pwmchipN/pwmX/duty_cycle +Date: May 2013 +KernelVersion: 3.11 +Contact: H Hartley Sweeten +Description: + Sets the PWM signal duty cycle in nanoseconds. + +What: /sys/class/pwm/pwmchipN/pwmX/polarity +Date: May 2013 +KernelVersion: 3.11 +Contact: H Hartley Sweeten +Description: + Sets the output polarity of the PWM signal to "normal" or + "inversed". + +What: /sys/class/pwm/pwmchipN/pwmX/enable +Date: May 2013 +KernelVersion: 3.11 +Contact: H Hartley Sweeten +Description: + Enable/disable the PWM signal. + 0 is disabled + 1 is enabled diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt index 7d2b4c9..1039b68 100644 --- a/Documentation/pwm.txt +++ b/Documentation/pwm.txt @@ -45,6 +45,43 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns); To start/stop toggling the PWM output use pwm_enable()/pwm_disable(). +Using PWMs with the sysfs interface +----------------------------------- + +If CONFIG_SYSFS is enabled in your kernel configuration a simple sysfs +interface is provided to use the PWMs from userspace. It is exposed at +/sys/class/pwm/. Each probed PWM controller/chip will be exported as +pwmchipN, where N is the base of the PWM chip. Inside the directory you +will find: + +npwm - The number of PWM channels this chip supports (read-only). + +export - Exports a PWM channel for use with sysfs (write-only). + +unexport - Unexports a PWM channel from sysfs (write-only). + +The PWM channels are numbered using a per-chip index from 0 to npwm-1. + +When a PWM channel is exported a pwmX directory will be created in the +pwmchipN directory it is associated with, where X is the number of the +channel that was exported. The following properties will then be available: + +period - The total period of the PWM signal (read/write). + Value is in nanoseconds and is the sum of the active and inactive + time of the PWM. + +duty_cycle - The active time of the PWM signal (read/write). + Value is in nanoseconds and must be less than the period. + +polarity - Changes the polarity of the PWM signal (read/write). + Writes to this property only work if the PWM chip supports changing + the polarity. The polarity can only be changed if the PWM is not + enabled. Value is the string "normal" or "inversed". + +enable - Enable/disable the PWM signal (read/write). + 0 - disabled + 1 - enabled + Implementing a PWM driver ------------------------- -- cgit v1.1 From 73e797f79e5edb3d000d1911a2d859f15c446c1a Mon Sep 17 00:00:00 2001 From: Hanjun Guo Date: Fri, 21 Jun 2013 17:09:18 +0800 Subject: Documentation / CPU hotplug: Rephrase the outdated description for MADT entries More than 256 entries in ACPI MADT is supported from ACPI 3.0, so the information in should be Documentation/cpu-hotplug.txt updated. [rjw: Changelog] Suggested-by: Rafael J. Wysocki Signed-off-by: Hanjun Guo Signed-off-by: Rafael J. Wysocki --- Documentation/cpu-hotplug.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index 9f40135..67f733d 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -370,8 +370,10 @@ A: There is no clear spec defined way from ACPI that can give us that CPUs in MADT as hotpluggable CPUS. In the case there are no disabled CPUS we assume 1/2 the number of CPUs currently present can be hotplugged. - Caveat: Today's ACPI MADT can only provide 256 entries since the apicid field - in MADT is only 8 bits. + Caveat: ACPI MADT can only provide 256 entries in systems with only ACPI 2.0c + or earlier ACPI version supported, because the apicid field in MADT is only + 8 bits. From ACPI 3.0, this limitation was removed since the apicid field + was extended to 32 bits with x2APIC introduced. User Space Notification -- cgit v1.1 From a6edca3c1b4e78c099a426bbe1e724bf70cf3515 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sun, 26 May 2013 09:45:23 -0300 Subject: [media] DocBook: remove references to the dropped VIDIOC_DBG_G_CHIP_IDENT ioctl Signed-off-by: Hans Verkuil Cc: Mauro Carvalho Chehab Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/compat.xml | 14 +- Documentation/DocBook/media/v4l/v4l2.xml | 11 +- .../DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml | 271 --------------------- .../DocBook/media/v4l/vidioc-dbg-g-chip-info.xml | 17 +- .../DocBook/media/v4l/vidioc-dbg-g-register.xml | 40 +-- 5 files changed, 24 insertions(+), 329 deletions(-) delete mode 100644 Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index f43542a..0c7195e 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2254,7 +2254,7 @@ video encoding. The VIDIOC_G_CHIP_IDENT ioctl was renamed -to VIDIOC_G_CHIP_IDENT_OLD and &VIDIOC-DBG-G-CHIP-IDENT; +to VIDIOC_G_CHIP_IDENT_OLD and VIDIOC_DBG_G_CHIP_IDENT was introduced in its place. The old struct v4l2_chip_ident was renamed to v4l2_chip_ident_old. @@ -2513,6 +2513,16 @@ that used it. It was originally scheduled for removal in 2.6.35. +
+ V4L2 in Linux 3.11 + + + Remove obsolete VIDIOC_DBG_G_CHIP_IDENT ioctl. + + + +
+
Relation of V4L2 to other Linux multimedia APIs @@ -2596,7 +2606,7 @@ and may change in the future. ioctls. - &VIDIOC-DBG-G-CHIP-IDENT; ioctl. + &VIDIOC-DBG-G-CHIP-INFO; ioctl. &VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index bfe823d..8469fe1 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -141,6 +141,14 @@ structs, ioctls) must be noted in more detail in the history chapter applications. --> + 3.11 + 2013-05-26 + hv + Remove obsolete VIDIOC_DBG_G_CHIP_IDENT ioctl. + + + + 3.10 2013-03-25 hv @@ -493,7 +501,7 @@ and discussions on the V4L mailing list. Video for Linux Two API Specification - Revision 3.10 + Revision 3.11 &sub-common; @@ -547,7 +555,6 @@ and discussions on the V4L mailing list. &sub-create-bufs; &sub-cropcap; - &sub-dbg-g-chip-ident; &sub-dbg-g-chip-info; &sub-dbg-g-register; &sub-decoder-cmd; diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml deleted file mode 100644 index 921e185..0000000 --- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml +++ /dev/null @@ -1,271 +0,0 @@ - - - ioctl VIDIOC_DBG_G_CHIP_IDENT - &manvol; - - - - VIDIOC_DBG_G_CHIP_IDENT - Identify the chips on a TV card - - - - - - int ioctl - int fd - int request - struct v4l2_dbg_chip_ident -*argp - - - - - - Arguments - - - - fd - - &fd; - - - - request - - VIDIOC_DBG_G_CHIP_IDENT - - - - argp - - - - - - - - - Description - - - Experimental - - This is an experimental interface and may change in -the future. - - - For driver debugging purposes this ioctl allows test -applications to query the driver about the chips present on the TV -card. Regular applications must not use it. When you found a chip -specific bug, please contact the linux-media mailing list (&v4l-ml;) -so it can be fixed. - - To query the driver applications must initialize the -match.type and -match.addr or match.name -fields of a &v4l2-dbg-chip-ident; -and call VIDIOC_DBG_G_CHIP_IDENT with a pointer to -this structure. On success the driver stores information about the -selected chip in the ident and -revision fields. On failure the structure -remains unchanged. - - When match.type is -V4L2_CHIP_MATCH_HOST, -match.addr selects the nth non-&i2c; chip -on the TV card. You can enumerate all chips by starting at zero and -incrementing match.addr by one until -VIDIOC_DBG_G_CHIP_IDENT fails with an &EINVAL;. -The number zero always selects the host chip, ⪚ the chip connected -to the PCI or USB bus. - - When match.type is -V4L2_CHIP_MATCH_I2C_DRIVER, -match.name contains the I2C driver name. -For instance -"saa7127" will match any chip -supported by the saa7127 driver, regardless of its &i2c; bus address. -When multiple chips supported by the same driver are present, the -ioctl will return V4L2_IDENT_AMBIGUOUS in the -ident field. - - When match.type is -V4L2_CHIP_MATCH_I2C_ADDR, -match.addr selects a chip by its 7 bit -&i2c; bus address. - - When match.type is -V4L2_CHIP_MATCH_AC97, -match.addr selects the nth AC97 chip -on the TV card. You can enumerate all chips by starting at zero and -incrementing match.addr by one until -VIDIOC_DBG_G_CHIP_IDENT fails with an &EINVAL;. - - On success, the ident field will -contain a chip ID from the Linux -media/v4l2-chip-ident.h header file, and the -revision field will contain a driver -specific value, or zero if no particular revision is associated with -this chip. - - When the driver could not identify the selected chip, -ident will contain -V4L2_IDENT_UNKNOWN. When no chip matched -the ioctl will succeed but the -ident field will contain -V4L2_IDENT_NONE. If multiple chips matched, -ident will contain -V4L2_IDENT_AMBIGUOUS. In all these cases the -revision field remains unchanged. - - This ioctl is optional, not all drivers may support it. It -was introduced in Linux 2.6.21, but the API was changed to the -one described here in 2.6.29. - - We recommended the v4l2-dbg -utility over calling this ioctl directly. It is available from the -LinuxTV v4l-dvb repository; see http://linuxtv.org/repo/ for -access instructions. - - -
- struct <structname>v4l2_dbg_match</structname> - - &cs-ustr; - - - __u32 - type - See for a list of -possible types. - - - union - (anonymous) - - - - __u32 - addr - Match a chip by this number, interpreted according -to the type field. - - - - char - name[32] - Match a chip by this name, interpreted according -to the type field. - - - -
- - - struct <structname>v4l2_dbg_chip_ident</structname> - - &cs-str; - - - struct v4l2_dbg_match - match - How to match the chip, see . - - - __u32 - ident - A chip identifier as defined in the Linux -media/v4l2-chip-ident.h header file, or one of -the values from . - - - __u32 - revision - A chip revision, chip and driver specific. - - - -
- - - - Chip Match Types - - &cs-def; - - - V4L2_CHIP_MATCH_BRIDGE - 0 - Match the nth chip on the card, zero for the - bridge chip. Does not match sub-devices. - - - V4L2_CHIP_MATCH_I2C_DRIVER - 1 - Match an &i2c; chip by its driver name. - - - V4L2_CHIP_MATCH_I2C_ADDR - 2 - Match a chip by its 7 bit &i2c; bus address. - - - V4L2_CHIP_MATCH_AC97 - 3 - Match the nth anciliary AC97 chip. - - - V4L2_CHIP_MATCH_SUBDEV - 4 - Match the nth sub-device. Can't be used with this ioctl. - - - -
- - - - Chip Identifiers - - &cs-def; - - - V4L2_IDENT_NONE - 0 - No chip matched. - - - V4L2_IDENT_AMBIGUOUS - 1 - Multiple chips matched. - - - V4L2_IDENT_UNKNOWN - 2 - A chip is present at this address, but the driver -could not identify it. - - - -
- - - - &return-value; - - - - EINVAL - - The match_type is invalid. - - - - - diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml index 80e8021..4c4603c 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml @@ -131,7 +131,7 @@ to the type field. char name[32] Match a chip by this name, interpreted according -to the type field. +to the type field. Currently unused. @@ -182,21 +182,6 @@ is set, then the driver supports reading registers from the device. If bridge chip. Does not match sub-devices. - V4L2_CHIP_MATCH_I2C_DRIVER - 1 - Match an &i2c; chip by its driver name. Can't be used with this ioctl. - - - V4L2_CHIP_MATCH_I2C_ADDR - 2 - Match a chip by its 7 bit &i2c; bus address. Can't be used with this ioctl. - - - V4L2_CHIP_MATCH_AC97 - 3 - Match the nth anciliary AC97 chip. Can't be used with this ioctl. - - V4L2_CHIP_MATCH_SUBDEV 4 Match the nth sub-device. diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml index e23285f..32c4bde 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml @@ -102,27 +102,6 @@ chip connected to the PCI or USB bus. You can find out which chips are present with the &VIDIOC-DBG-G-CHIP-INFO; ioctl. When match.type is -V4L2_CHIP_MATCH_I2C_DRIVER, -match.name contains the I2C driver name. -For instance -"saa7127" will match any chip -supported by the saa7127 driver, regardless of its &i2c; bus address. -When multiple chips supported by the same driver are present, the -effect of these ioctls is undefined. Again with the -&VIDIOC-DBG-G-CHIP-INFO; ioctl you can find out which &i2c; chips are -present. - - When match.type is -V4L2_CHIP_MATCH_I2C_ADDR, -match.addr selects a chip by its 7 bit &i2c; -bus address. - - When match.type is -V4L2_CHIP_MATCH_AC97, -match.addr selects the nth AC97 chip -on the TV card. - - When match.type is V4L2_CHIP_MATCH_SUBDEV, match.addr selects the nth sub-device. @@ -160,7 +139,7 @@ access instructions. __u32 type - See for a list of + See for a list of possible types. @@ -179,7 +158,7 @@ to the type field. char name[32] Match a chip by this name, interpreted according -to the type field. +to the type field. Currently unused. @@ -232,21 +211,6 @@ register. bridge chip. Does not match sub-devices. - V4L2_CHIP_MATCH_I2C_DRIVER - 1 - Match an &i2c; chip by its driver name. - - - V4L2_CHIP_MATCH_I2C_ADDR - 2 - Match a chip by its 7 bit &i2c; bus address. - - - V4L2_CHIP_MATCH_AC97 - 3 - Match the nth anciliary AC97 chip. - - V4L2_CHIP_MATCH_SUBDEV 4 Match the nth sub-device. -- cgit v1.1 From da6a855320a6e056add76ea0503b01efdbb0de36 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sun, 26 May 2013 10:31:01 -0300 Subject: [media] DocBook: remove obsolete note from the dbg_g_register doc Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml | 9 --------- 1 file changed, 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml index 32c4bde..3d038e7 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml @@ -105,15 +105,6 @@ present with the &VIDIOC-DBG-G-CHIP-INFO; ioctl. V4L2_CHIP_MATCH_SUBDEV, match.addr selects the nth sub-device. - - Success not guaranteed - - Due to a flaw in the Linux &i2c; bus driver these ioctls may -return successfully without actually reading or writing a register. To -catch the most likely failure we recommend a &VIDIOC-DBG-G-CHIP-INFO; -call confirming the presence of the selected &i2c; chip. - - These ioctls are optional, not all drivers may support them. However when a driver supports these ioctls it must also support &VIDIOC-DBG-G-CHIP-INFO;. Conversely it may support -- cgit v1.1 From 7cb59509a74da98721ac169431a9a0bd372e29b0 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 12 Jun 2013 11:28:08 -0300 Subject: [media] v4l2-framework: update documentation 'parent' was renamed to 'dev_parent'. Clarify how/when this should be used. Signed-off-by: Hans Verkuil Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 24353eca..b5e6347b 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -574,9 +574,13 @@ of the video device exits. The default video_device_release() callback just calls kfree to free the allocated memory. +There is also a video_device_release_empty() function that does nothing +(is empty) and can be used if the struct is embedded and there is nothing +to do when it is released. + You should also set these fields: -- v4l2_dev: set to the v4l2_device parent device. +- v4l2_dev: must be set to the v4l2_device parent device. - name: set to something descriptive and unique. @@ -613,15 +617,16 @@ You should also set these fields: If you want to have a separate priority state per (group of) device node(s), then you can point it to your own struct v4l2_prio_state. -- parent: you only set this if v4l2_device was registered with NULL as +- dev_parent: you only set this if v4l2_device was registered with NULL as the parent device struct. This only happens in cases where one hardware device has multiple PCI devices that all share the same v4l2_device core. The cx88 driver is an example of this: one core v4l2_device struct, but - it is used by both an raw video PCI device (cx8800) and a MPEG PCI device - (cx8802). Since the v4l2_device cannot be associated with a particular - PCI device it is setup without a parent device. But when the struct - video_device is setup you do know which parent PCI device to use. + it is used by both a raw video PCI device (cx8800) and a MPEG PCI device + (cx8802). Since the v4l2_device cannot be associated with two PCI devices + at the same time it is setup without a parent device. But when the struct + video_device is initialized you *do* know which parent PCI device to use and + so you set dev_device to the correct PCI device. - flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct -- cgit v1.1 From b610b5928dc04095b9b24b83e4ddbb399d933611 Mon Sep 17 00:00:00 2001 From: "Lad, Prabhakar" Date: Tue, 4 Jun 2013 12:26:23 -0300 Subject: [media] media: i2c: tvp514x: add OF support add OF support for the tvp514x driver. Signed-off-by: Lad, Prabhakar Acked-by: Laurent Pinchart Cc: Hans Verkuil Cc: Mauro Carvalho Chehab Cc: Guennadi Liakhovetski Cc: Sylwester Nawrocki Cc: Sakari Ailus Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: devicetree-discuss@lists.ozlabs.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: davinci-linux-open-source@linux.davincidsp.com Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/i2c/tvp514x.txt | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp514x.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/i2c/tvp514x.txt b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt new file mode 100644 index 0000000..46752cc --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt @@ -0,0 +1,44 @@ +* Texas Instruments TVP514x video decoder + +The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip +digital video decoder that digitizes and decodes all popular baseband analog +video formats into digital video component. The tvp514x decoder supports analog- +to-digital (A/D) conversion of component RGB and YPbPr signals as well as A/D +conversion and decoding of NTSC, PAL and SECAM composite and S-video into +component YCbCr. + +Required Properties : +- compatible : value should be either one among the following + (a) "ti,tvp5146" for tvp5146 decoder. + (b) "ti,tvp5146m2" for tvp5146m2 decoder. + (c) "ti,tvp5147" for tvp5147 decoder. + (d) "ti,tvp5147m1" for tvp5147m1 decoder. + +- hsync-active: HSYNC Polarity configuration for endpoint. + +- vsync-active: VSYNC Polarity configuration for endpoint. + +- pclk-sample: Clock polarity of the endpoint. + +For further reading on port node refer to Documentation/devicetree/bindings/ +media/video-interfaces.txt. + +Example: + + i2c0@1c22000 { + ... + ... + tvp514x@5c { + compatible = "ti,tvp5146"; + reg = <0x5c>; + + port { + tvp514x_1: endpoint { + hsync-active = <1>; + vsync-active = <1>; + pclk-sample = <0>; + }; + }; + }; + ... + }; -- cgit v1.1 From b0e59b85abd42f8a525ff032d5063457e1378808 Mon Sep 17 00:00:00 2001 From: Alexey Kardashevskiy Date: Fri, 21 Jun 2013 09:43:21 -0600 Subject: vfio: fix documentation Signed-off-by: Alexey Kardashevskiy Signed-off-by: Alex Williamson --- Documentation/vfio.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt index 8eda363..e71782a 100644 --- a/Documentation/vfio.txt +++ b/Documentation/vfio.txt @@ -172,12 +172,12 @@ group and can access them as follows: struct vfio_device_info device_info = { .argsz = sizeof(device_info) }; /* Create a new container */ - container = open("/dev/vfio/vfio, O_RDWR); + container = open("/dev/vfio/vfio", O_RDWR); if (ioctl(container, VFIO_GET_API_VERSION) != VFIO_API_VERSION) /* Unknown API version */ - if (!ioctl(container, VFIO_CHECK_EXTENSION, VFIO_X86_IOMMU)) + if (!ioctl(container, VFIO_CHECK_EXTENSION, VFIO_TYPE1_IOMMU)) /* Doesn't support the IOMMU driver we want. */ /* Open the group */ @@ -193,7 +193,7 @@ group and can access them as follows: ioctl(group, VFIO_GROUP_SET_CONTAINER, &container); /* Enable the IOMMU model we want */ - ioctl(container, VFIO_SET_IOMMU, VFIO_X86_IOMMU) + ioctl(container, VFIO_SET_IOMMU, VFIO_TYPE1_IOMMU) /* Get addition IOMMU info */ ioctl(container, VFIO_IOMMU_GET_INFO, &iommu_info); -- cgit v1.1 From d907849e0dbaeacb34e0a6a3b49ebeaf8c49355e Mon Sep 17 00:00:00 2001 From: Daniel Tang Date: Tue, 11 Jun 2013 18:40:18 +1000 Subject: arm: Add device trees for TI-Nspire hardware This patch adds device trees for describing the TI-Nspire hardware. Changes between v1 and v2: * Change "keymap" binding to the standard "linux,keymap" binding. Signed-off-by: Daniel Tang Signed-off-by: Arnd Bergmann --- Documentation/devicetree/bindings/arm/nspire.txt | 14 ++++++++++++++ Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 2 files changed, 15 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/nspire.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/nspire.txt b/Documentation/devicetree/bindings/arm/nspire.txt new file mode 100644 index 0000000..4d08518 --- /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/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 6931c43..b27b057 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. -- cgit v1.1 From 812e8b22ea55218449de310a666dd1ce16f924ed Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Mon, 17 Sep 2012 07:48:33 -0300 Subject: [media] sh-mobile-ceu-driver: support max width and height in DT Some CEU implementations have non-standard (larger) maximum supported width and height values. Add two OF properties to specify them. Signed-off-by: Guennadi Liakhovetski Acked-by: Hans Verkuil Acked-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- .../devicetree/bindings/media/sh_mobile_ceu.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/sh_mobile_ceu.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt b/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt new file mode 100644 index 0000000..1ce4e46 --- /dev/null +++ b/Documentation/devicetree/bindings/media/sh_mobile_ceu.txt @@ -0,0 +1,18 @@ +Bindings, specific for the sh_mobile_ceu_camera.c driver: + - compatible: Should be "renesas,sh-mobile-ceu" + - reg: register base and size + - interrupts: the interrupt number + - interrupt-parent: the interrupt controller + - renesas,max-width: maximum image width, supported on this SoC + - renesas,max-height: maximum image height, supported on this SoC + +Example: + +ceu0: ceu@0xfe910000 { + compatible = "renesas,sh-mobile-ceu"; + reg = <0xfe910000 0xa0>; + interrupt-parent = <&intcs>; + interrupts = <0x880>; + renesas,max-width = <8188>; + renesas,max-height = <8188>; +}; -- cgit v1.1 From d30b82a46942cda5c0af3744142a650db0732a7c Mon Sep 17 00:00:00 2001 From: "lan,Tianyu" Date: Fri, 21 Jun 2013 10:09:15 +0800 Subject: PM / QoS: Update Documentation/power/pm_qos_interface.txt Update PM QoS documentation after recent changes. [rjw: Changelog] Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki --- Documentation/power/pm_qos_interface.txt | 50 +++++++++++++++++++++++++++----- 1 file changed, 43 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt index 79a2a58..4836320 100644 --- a/Documentation/power/pm_qos_interface.txt +++ b/Documentation/power/pm_qos_interface.txt @@ -7,7 +7,7 @@ one of the parameters. Two different PM QoS frameworks are available: 1. PM QoS classes for cpu_dma_latency, network_latency, network_throughput. 2. the per-device PM QoS framework provides the API to manage the per-device latency -constraints. +constraints and PM QoS flags. Each parameters have defined units: * latency: usec @@ -86,13 +86,17 @@ To remove the user mode request for a target value simply close the device node. -2. PM QoS per-device latency framework +2. PM QoS per-device latency and flags framework + +For each device, there are two lists of PM QoS requests. One is maintained +along with the aggregated target of latency value and the other is for PM QoS +flags. Values are updated in response to changes of the request list. + +Target latency value is simply the minimum of the request values held in the +parameter list elements. The PM QoS flags aggregate value is a gather (bitwise +OR) of all list elements' values. Two device PM QoS flags are defined currently: +PM_QOS_FLAG_NO_POWER_OFF and PM_QOS_FLAG_REMOTE_WAKEUP. -For each device a list of performance requests is maintained along with -an aggregated target value. The aggregated target value is updated with -changes to the request list or elements of the list. Typically the -aggregated target value is simply the max or min of the request values held -in the parameter list elements. Note: the aggregated target value is implemented as an atomic variable so that reading the aggregated value does not require any locking mechanism. @@ -119,6 +123,38 @@ the request. s32 dev_pm_qos_read_value(device): Returns the aggregated value for a given device's constraints list. +enum pm_qos_flags_status dev_pm_qos_flags(device, mask) +Check PM QoS flags of the given device against the given mask of flags. +The meaning of the return values is as follows: + PM_QOS_FLAGS_ALL: All flags from the mask are set + PM_QOS_FLAGS_SOME: Some flags from the mask are set + PM_QOS_FLAGS_NONE: No flags from the mask are set + PM_QOS_FLAGS_UNDEFINED: The device's PM QoS structure has not been + initialized or the list of requests is empty. + +int dev_pm_qos_add_ancestor_request(dev, handle, value) +Add a PM QoS request for the first direct ancestor of the given device whose +power.ignore_children flag is unset. + +int dev_pm_qos_expose_latency_limit(device, value) +Add a request to the device's PM QoS list of latency constraints and create +a sysfs attribute pm_qos_resume_latency_us under the device's power directory +allowing user space to manipulate that request. + +void dev_pm_qos_hide_latency_limit(device) +Drop the request added by dev_pm_qos_expose_latency_limit() from the device's +PM QoS list of latency constraints and remove sysfs attribute pm_qos_resume_latency_us +from the device's power directory. + +int dev_pm_qos_expose_flags(device, value) +Add a request to the device's PM QoS list of flags and create sysfs attributes +pm_qos_no_power_off and pm_qos_remote_wakeup under the device's power directory +allowing user space to change these flags' value. + +void dev_pm_qos_hide_flags(device) +Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS list +of flags and remove sysfs attributes pm_qos_no_power_off and pm_qos_remote_wakeup +under the device's power directory. Notification mechanisms: The per-device PM QoS framework has 2 different and distinct notification trees: -- cgit v1.1 From 14c63f17b1fde5a575a28e96547a22b451c71fb5 Mon Sep 17 00:00:00 2001 From: Dave Hansen Date: Fri, 21 Jun 2013 08:51:36 -0700 Subject: perf: Drop sample rate when sampling is too slow This patch keeps track of how long perf's NMI handler is taking, and also calculates how many samples perf can take a second. If the sample length times the expected max number of samples exceeds a configurable threshold, it drops the sample rate. This way, we don't have a runaway sampling process eating up the CPU. This patch can tend to drop the sample rate down to level where perf doesn't work very well. *BUT* the alternative is that my system hangs because it spends all of its time handling NMIs. I'll take a busted performance tool over an entire system that's busted and undebuggable any day. BTW, my suspicion is that there's still an underlying bug here. Using the HPET instead of the TSC is definitely a contributing factor, but I suspect there are some other things going on. But, I can't go dig down on a bug like that with my machine hanging all the time. Signed-off-by: Dave Hansen Acked-by: Peter Zijlstra Cc: paulus@samba.org Cc: acme@ghostprotocols.net Cc: Dave Hansen [ Prettified it a bit. ] Signed-off-by: Ingo Molnar --- Documentation/sysctl/kernel.txt | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index bcff3f9..ab7d16e 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -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: -- cgit v1.1 From 0c4df02d739fed5ab081b330d67403206dd3967e Mon Sep 17 00:00:00 2001 From: Dave Hansen Date: Fri, 21 Jun 2013 08:51:38 -0700 Subject: x86: Add NMI duration tracepoints This patch has been invaluable in my adventures finding issues in the perf NMI handler. I'm as big a fan of printk() as anybody is, but using printk() in NMIs is deadly when they're happening frequently. Even hacking in trace_printk() ended up eating enough CPU to throw off some of the measurements I was making. Signed-off-by: Dave Hansen Acked-by: Peter Zijlstra Cc: paulus@samba.org Cc: acme@ghostprotocols.net Cc: Dave Hansen Signed-off-by: Ingo Molnar --- Documentation/trace/events-nmi.txt | 43 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/trace/events-nmi.txt (limited to 'Documentation') diff --git a/Documentation/trace/events-nmi.txt b/Documentation/trace/events-nmi.txt new file mode 100644 index 0000000..c03c8c8 --- /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 +-0 [000] d.h3 505.397558: nmi_handler: perf_event_nmi_handler() delta_ns: 3236765 handled: 1 +-0 [000] d.h3 505.805893: nmi_handler: perf_event_nmi_handler() delta_ns: 3174234 handled: 1 +-0 [000] d.h3 506.158206: nmi_handler: perf_event_nmi_handler() delta_ns: 3084642 handled: 1 +-0 [000] d.h3 506.334346: nmi_handler: perf_event_nmi_handler() delta_ns: 3080351 handled: 1 + -- cgit v1.1 From a3c910d2e796ce878231350b904105261a8cf09c Mon Sep 17 00:00:00 2001 From: Shan Wei Date: Fri, 21 Jun 2013 15:18:32 +0800 Subject: tcp: doc : fix the syncookies default value syncookies is on for default since in commit e994b7c901 (tcp: Don't make syn cookies initial setting depend on CONFIG_SYSCTL). And fix a typo of CONFIG_SYN_COOKIES. Signed-off-by: Shan Wei Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index f98ca63..3458d63 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 -- cgit v1.1 From bf3156dde3b6718e843152e826a493f80b973655 Mon Sep 17 00:00:00 2001 From: Matt Porter Date: Thu, 20 Jun 2013 16:06:37 -0500 Subject: dmaengine: edma: Add TI EDMA device tree binding The binding definition is based on the generic DMA controller binding. Joel: * Droped reserved and queue DT entries from Documentation for now from the original patch series (v10) * Included properties in Documentation and clarified DMA properties (V11) * Made ti,hwmod option * Clarified DMA entries Acked-by: Arnd Bergmann Signed-off-by: Matt Porter Signed-off-by: Joel A Fernandes Signed-off-by: Sekhar Nori --- Documentation/devicetree/bindings/dma/ti-edma.txt | 34 +++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt new file mode 100644 index 0000000..9fbbdb7 --- /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>; +}; -- cgit v1.1 From f5ce1572109049b90484e2bb44927cb6034c5eb1 Mon Sep 17 00:00:00 2001 From: Sahara Date: Fri, 21 Jun 2013 11:12:31 +0900 Subject: PM / QoS: Add pm_qos and dev_pm_qos to events-power.txt Add PM QOS events section and description to events-power.txt. Signed-off-by: Sahara Signed-off-by: Rafael J. Wysocki --- Documentation/trace/events-power.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'Documentation') diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt index e1498ff..3bd33b8 100644 --- a/Documentation/trace/events-power.txt +++ b/Documentation/trace/events-power.txt @@ -63,3 +63,34 @@ power_domain_target "%s state=%lu cpu_id=%lu" The first parameter gives the power domain name (e.g. "mpu_pwrdm"). The second parameter is the power domain target state. +4. PM QoS events +================ +The PM QoS events are used for QoS add/update/remove request and for +target/flags update. + +pm_qos_add_request "pm_qos_class=%s value=%d" +pm_qos_update_request "pm_qos_class=%s value=%d" +pm_qos_remove_request "pm_qos_class=%s value=%d" +pm_qos_update_request_timeout "pm_qos_class=%s value=%d, timeout_us=%ld" + +The first parameter gives the QoS class name (e.g. "CPU_DMA_LATENCY"). +The second parameter is value to be added/updated/removed. +The third parameter is timeout value in usec. + +pm_qos_update_target "action=%s prev_value=%d curr_value=%d" +pm_qos_update_flags "action=%s prev_value=0x%x curr_value=0x%x" + +The first parameter gives the QoS action name (e.g. "ADD_REQ"). +The second parameter is the previous QoS value. +The third parameter is the current QoS value to update. + +And, there are also events used for device PM QoS add/update/remove request. + +dev_pm_qos_add_request "device=%s type=%s new_value=%d" +dev_pm_qos_update_request "device=%s type=%s new_value=%d" +dev_pm_qos_remove_request "device=%s type=%s new_value=%d" + +The first parameter gives the device name which tries to add/update/remove +QoS requests. +The second parameter gives the request type (e.g. "DEV_PM_QOS_LATENCY"). +The third parameter is value to be added/updated/removed. -- cgit v1.1 From 64a45c986349a00f0d4c96c0daeecdea76e31a96 Mon Sep 17 00:00:00 2001 From: Patrice Chotard Date: Thu, 20 Jun 2013 16:04:59 +0200 Subject: pinctrl: abx500: Add device tree support We use the same way to define pin muxing and pin configuration than for nomadik. So pickup code from pinctrl_nomadik.c to be able to implement pin multiplexing and pin configuration using the device tree. Pin configuration uses generic parsing code. Signed-off-by: Gabriel Fernandez Signed-off-by: Patrice Chotard Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/ste,abx500.txt | 352 +++++++++++++++++++++ 1 file changed, 352 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/ste,abx500.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/ste,abx500.txt b/Documentation/devicetree/bindings/pinctrl/ste,abx500.txt new file mode 100644 index 0000000..e3865e1 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ste,abx500.txt @@ -0,0 +1,352 @@ +ST Ericsson abx500 pinmux controller + +Required properties: +- compatible: "stericsson,ab8500-gpio", "stericsson,ab8540-gpio", + "stericsson,ab8505-gpio", "stericsson,ab9540-gpio", + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +ST Ericsson's pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as input, output, pull up, pull down... + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Required subnode-properties: +- ste,pins : An array of strings. Each string contains the name of a pin or + group. + +Optional subnode-properties: +- ste,function: A string containing the name of the function to mux to the + pin or group. + +- generic pin configuration option to use. Example : + + default_cfg { + ste,pins = "GPIO1"; + bias-disable; + }; + +- ste,config: Handle of pin configuration node containing the generic + pinconfig options to use, as described in pinctrl-bindings.txt in + this directory. Example : + + pcfg_bias_disable: pcfg_bias_disable { + bias-disable; + }; + + default_cfg { + ste,pins = "GPIO1"; + ste.config = <&pcfg_bias_disable>; + }; + +Example board file extract: + +&pinctrl_abx500 { + pinctrl-names = "default"; + pinctrl-0 = <&sysclkreq2_default_mode>, <&sysclkreq3_default_mode>, <&gpio3_default_mode>, <&sysclkreq6_default_mode>, <&pwmout1_default_mode>, <&pwmout2_default_mode>, <&pwmout3_default_mode>, <&adi1_default_mode>, <&dmic12_default_mode>, <&dmic34_default_mode>, <&dmic56_default_mode>, <&sysclkreq5_default_mode>, <&batremn_default_mode>, <&service_default_mode>, <&pwrctrl0_default_mode>, <&pwrctrl1_default_mode>, <&pwmextvibra1_default_mode>, <&pwmextvibra2_default_mode>, <&gpio51_default_mode>, <&gpio52_default_mode>, <&gpio53_default_mode>, <&gpio54_default_mode>, <&pdmclkdat_default_mode>; + + sysclkreq2 { + sysclkreq2_default_mode: sysclkreq2_default { + default_mux { + ste,function = "sysclkreq"; + ste,pins = "sysclkreq2_d_1"; + }; + default_cfg { + ste,pins = "GPIO1"; + bias-disable; + }; + }; + }; + sysclkreq3 { + sysclkreq3_default_mode: sysclkreq3_default { + default_mux { + ste,function = "sysclkreq"; + ste,pins = "sysclkreq3_d_1"; + }; + default_cfg { + ste,pins = "GPIO2"; + output-low; + }; + }; + }; + gpio3 { + gpio3_default_mode: gpio3_default { + default_mux { + ste,function = "gpio"; + ste,pins = "gpio3_a_1"; + }; + default_cfg { + ste,pins = "GPIO3"; + output-low; + }; + }; + }; + sysclkreq6 { + sysclkreq6_default_mode: sysclkreq6_default { + default_mux { + ste,function = "sysclkreq"; + ste,pins = "sysclkreq6_d_1"; + }; + default_cfg { + ste,pins = "GPIO4"; + bias-disable; + }; + }; + }; + pwmout1 { + pwmout1_default_mode: pwmout1_default { + default_mux { + ste,function = "pwmout"; + ste,pins = "pwmout1_d_1"; + }; + default_cfg { + ste,pins = "GPIO14"; + output-low; + }; + }; + }; + pwmout2 { + pwmout2_default_mode: pwmout2_default { + pwmout2_default_mux { + ste,function = "pwmout"; + ste,pins = "pwmout2_d_1"; + }; + pwmout2_default_cfg { + ste,pins = "GPIO15"; + output-low; + }; + }; + }; + pwmout3 { + pwmout3_default_mode: pwmout3_default { + pwmout3_default_mux { + ste,function = "pwmout"; + ste,pins = "pwmout3_d_1"; + }; + pwmout3_default_cfg { + ste,pins = "GPIO16"; + output-low; + }; + }; + }; + adi1 { + + adi1_default_mode: adi1_default { + adi1_default_mux { + ste,function = "adi1"; + ste,pins = "adi1_d_1"; + }; + adi1_default_cfg1 { + ste,pins = "GPIO17","GPIO19","GPIO20"; + bias-disable; + }; + adi1_default_cfg2 { + ste,pins = "GPIO18"; + output-low; + }; + }; + }; + dmic12 { + dmic12_default_mode: dmic12_default { + dmic12_default_mux { + ste,function = "dmic"; + ste,pins = "dmic12_d_1"; + }; + dmic12_default_cfg1 { + ste,pins = "GPIO27"; + output-low; + }; + dmic12_default_cfg2 { + ste,pins = "GPIO28"; + bias-disable; + }; + }; + }; + dmic34 { + dmic34_default_mode: dmic34_default { + dmic34_default_mux { + ste,function = "dmic"; + ste,pins = "dmic34_d_1"; + }; + dmic34_default_cfg1 { + ste,pins = "GPIO29"; + output-low; + }; + dmic34_default_cfg2 { + ste,pins = "GPIO30"; + bias-disable;{ + + }; + }; + }; + dmic56 { + dmic56_default_mode: dmic56_default { + dmic56_default_mux { + ste,function = "dmic"; + ste,pins = "dmic56_d_1"; + }; + dmic56_default_cfg1 { + ste,pins = "GPIO31"; + output-low; + }; + dmic56_default_cfg2 { + ste,pins = "GPIO32"; + bias-disable; + }; + }; + }; + sysclkreq5 { + sysclkreq5_default_mode: sysclkreq5_default { + sysclkreq5_default_mux { + ste,function = "sysclkreq"; + ste,pins = "sysclkreq5_d_1"; + }; + sysclkreq5_default_cfg { + ste,pins = "GPIO42"; + output-low; + }; + }; + }; + batremn { + batremn_default_mode: batremn_default { + batremn_default_mux { + ste,function = "batremn"; + ste,pins = "batremn_d_1"; + }; + batremn_default_cfg { + ste,pins = "GPIO43"; + bias-disable; + }; + }; + }; + service { + service_default_mode: service_default { + service_default_mux { + ste,function = "service"; + ste,pins = "service_d_1"; + }; + service_default_cfg { + ste,pins = "GPIO44"; + bias-disable; + }; + }; + }; + pwrctrl0 { + pwrctrl0_default_mux: pwrctrl0_mux { + pwrctrl0_default_mux { + ste,function = "pwrctrl"; + ste,pins = "pwrctrl0_d_1"; + }; + }; + pwrctrl0_default_mode: pwrctrl0_default { + pwrctrl0_default_cfg { + ste,pins = "GPIO45"; + bias-disable; + }; + }; + }; + pwrctrl1 { + pwrctrl1_default_mux: pwrctrl1_mux { + pwrctrl1_default_mux { + ste,function = "pwrctrl"; + ste,pins = "pwrctrl1_d_1"; + }; + }; + pwrctrl1_default_mode: pwrctrl1_default { + pwrctrl1_default_cfg { + ste,pins = "GPIO46"; + bias-disable; + }; + }; + }; + pwmextvibra1 { + pwmextvibra1_default_mode: pwmextvibra1_default { + pwmextvibra1_default_mux { + ste,function = "pwmextvibra"; + ste,pins = "pwmextvibra1_d_1"; + }; + pwmextvibra1_default_cfg { + ste,pins = "GPIO47"; + bias-disable; + }; + }; + }; + pwmextvibra2 { + pwmextvibra2_default_mode: pwmextvibra2_default { + pwmextvibra2_default_mux { + ste,function = "pwmextvibra"; + ste,pins = "pwmextvibra2_d_1"; + }; + pwmextvibra1_default_cfg { + ste,pins = "GPIO48"; + bias-disable; + }; + }; + }; + gpio51 { + gpio51_default_mode: gpio51_default { + gpio51_default_mux { + ste,function = "gpio"; + ste,pins = "gpio51_a_1"; + }; + gpio51_default_cfg { + ste,pins = "GPIO51"; + output-low; + }; + }; + }; + gpio52 { + gpio52_default_mode: gpio52_default { + gpio52_default_mux { + ste,function = "gpio"; + ste,pins = "gpio52_a_1"; + }; + gpio52_default_cfg { + ste,pins = "GPIO52"; + bias-pull-down; + }; + }; + }; + gpio53 { + gpio53_default_mode: gpio53_default { + gpio53_default_mux { + ste,function = "gpio"; + ste,pins = "gpio53_a_1"; + }; + gpio53_default_cfg { + ste,pins = "GPIO53"; + bias-pull-down; + }; + }; + }; + gpio54 { + gpio54_default_mode: gpio54_default { + gpio54_default_mux { + ste,function = "gpio"; + ste,pins = "gpio54_a_1"; + }; + gpio54_default_cfg { + ste,pins = "GPIO54"; + output-low; + }; + }; + }; + pdmclkdat { + pdmclkdat_default_mode: pdmclkdat_default { + pdmclkdat_default_mux { + ste,function = "pdm"; + ste,pins = "pdmclkdat_d_1"; + }; + pdmclkdat_default_cfg { + ste,pins = "GPIO55", "GPIO56"; + bias-disable; + }; + }; + }; +}; -- cgit v1.1 From 42dc30231ba35939213c33378c17cb81c31b0a37 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Mon, 24 Jun 2013 12:50:16 +0200 Subject: regulator: max8973: initial DT support This patch adds primitive DT support to the max8973 regulator driver. None of the configuration parameters, supported in the platform data are yet available in DT, therefore no configuration is performed if booting with no platform data. This means, that DT instantiation can only be used on boards, where no run-time configuration of the chip is required. In such cases the driver can be used to scale its output voltage. In the future support for configuration parameters should be added. Signed-off-by: Guennadi Liakhovetski Signed-off-by: Mark Brown --- .../bindings/regulator/max8973-regulator.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/max8973-regulator.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt new file mode 100644 index 0000000..8d38ab2 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt @@ -0,0 +1,21 @@ +* Maxim MAX8973 Voltage Regulator + +Required properties: + +- compatible: must be "maxium,max8973" +- reg: the i2c slave address of the regulator. It should be 0x1b. + +Any standard regulator properties can be used to configure the single max8973 +DCDC. + +Example: + + max8973@1b { + compatible = "maxium,max8973"; + reg = <0x1b>; + + regulator-min-microvolt = <935000>; + regulator-max-microvolt = <1200000>; + regulator-boot-on; + regulator-always-on; + }; -- cgit v1.1 From 0b9e49e6704b81fd991827b0b60a0a6d56d06921 Mon Sep 17 00:00:00 2001 From: Matt Porter Date: Mon, 24 Jun 2013 17:31:59 +0530 Subject: spi: omap2-mcspi: add generic DMA request support to the DT binding The binding definition is based on the generic DMA request binding Signed-off-by: Matt Porter Signed-off-by: Joel A Fernandes Signed-off-by: Sourav Poddar Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt b/Documentation/devicetree/bindings/spi/omap-spi.txt index 938809c..4c85c4c 100644 --- a/Documentation/devicetree/bindings/spi/omap-spi.txt +++ b/Documentation/devicetree/bindings/spi/omap-spi.txt @@ -10,7 +10,18 @@ Required properties: input. The default is D0 as input and D1 as output. -Example: +Optional properties: +- dmas: List of DMA specifiers with the controller specific format + as described in the generic DMA client binding. A tx and rx + specifier is required for each chip select. +- dma-names: List of DMA request names. These strings correspond + 1:1 with the DMA specifiers listed in dmas. The string naming + is to be "rxN" and "txN" for RX and TX requests, + respectively, where N equals the chip select number. + +Examples: + +[hwmod populated DMA resources] mcspi1: mcspi@1 { #address-cells = <1>; @@ -20,3 +31,17 @@ mcspi1: mcspi@1 { ti,spi-num-cs = <4>; }; +[generic DMA request binding] + +mcspi1: mcspi@1 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,omap4-mcspi"; + ti,hwmods = "mcspi1"; + ti,spi-num-cs = <2>; + dmas = <&edma 42 + &edma 43 + &edma 44 + &edma 45>; + dma-names = "tx0", "rx0", "tx1", "rx1"; +}; -- cgit v1.1 From d5025f9f535108ba44c7f00573a2a34c18a3ea2b Mon Sep 17 00:00:00 2001 From: James Hogan Date: Thu, 20 Jun 2013 10:26:27 +0100 Subject: pinctrl-tz1090: add TZ1090 pinctrl driver Add a pin control driver for the main pins on the TZ1090 SoC. This doesn't include the low-power pins as they're controlled separately via the Powerdown Controller (PDC) registers. Signed-off-by: James Hogan Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: Linus Walleij Cc: linux-doc@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Linus Walleij --- .../bindings/pinctrl/img,tz1090-pinctrl.txt | 232 +++++++++++++++++++++ 1 file changed, 232 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt new file mode 100644 index 0000000..39bfd9c --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt @@ -0,0 +1,232 @@ +ImgTec TZ1090 pin controller + +Required properties: +- compatible: "img,tz1090-pinctrl" +- reg: Should contain the register physical address and length of the pad + configuration registers (CR_PADS_* and CR_IF_CTL0). + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +TZ1090's pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. For this reason, even seemingly boolean +values are actually tristates in this binding: unspecified, off, or on. +Unspecified is represented as an absent property, and off/on are represented as +integer values 0 and 1. + +Required subnode-properties: +- tz1090,pins : An array of strings. Each string contains the name of a pin or + group. Valid values for these names are listed below. + +Optional subnode-properties: +- tz1090,function: A string containing the name of the function to mux to the + pin or group. Valid values for function names are listed below, including + which pingroups can be muxed to them. +- supported generic pinconfig properties (for further details see + Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt): + - bias-disable + - bias-high-impedance + - bias-bus-hold + - bias-pull-up + - bias-pull-down + - input-schmitt-enable + - input-schmitt-disable + - slew-rate: Integer, control slew rate of pins. + 0: slow (half frequency) + 1: fast + - drive-strength: Integer, control drive strength of pins in mA. + 2: 2mA + 4: 4mA + 8: 8mA + 12: 12mA + + +Note that many of these properties are only valid for certain specific pins +or groups. See the TZ1090 TRM for complete details regarding which groups +support which functionality. The Linux pinctrl driver may also be a useful +reference. + +Valid values for pin and group names are: + + gpio pins: + + These all support bias-high-impediance, bias-pull-up, bias-pull-down, and + bias-bus-hold (which can also be provided to any of the groups below to set + it for all pins in that group). + + They also all support the some form of muxing. Any pins which are contained + in one of the mux groups (see below) can be muxed only to the functions + supported by the mux group. All other pins can be muxed to the "perip" + function which which enables them with their intended peripheral. + + Different pins in the same mux group cannot be muxed to different functions, + however it is possible to mux only a subset of the pins in a mux group to a + particular function and leave the remaining pins unmuxed. This is useful if + the board connects certain pins in a group to other devices to be controlled + by GPIO, and you don't want the usual peripheral to have any control of the + pin. + + ant_sel0, ant_sel1, gain0, gain1, gain2, gain3, gain4, gain5, gain6, gain7, + i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2, i2s_lrclk_out, + i2s_mclk, pa_on, pdm_a, pdm_b, pdm_c, pdm_d, pll_on, rx_hp, rx_on, + scb0_sclk, scb0_sdat, scb1_sclk, scb1_sdat, scb2_sclk, scb2_sdat, sdh_cd, + sdh_clk_in, sdh_wp, sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3, + spi0_cs0, spi0_cs1, spi0_cs2, spi0_din, spi0_dout, spi0_mclk, spi1_cs0, + spi1_cs1, spi1_cs2, spi1_din, spi1_dout, spi1_mclk, tft_blank_ls, tft_blue0, + tft_blue1, tft_blue2, tft_blue3, tft_blue4, tft_blue5, tft_blue6, tft_blue7, + tft_green0, tft_green1, tft_green2, tft_green3, tft_green4, tft_green5, + tft_green6, tft_green7, tft_hsync_nr, tft_panelclk, tft_pwrsave, tft_red0, + tft_red1, tft_red2, tft_red3, tft_red4, tft_red5, tft_red6, tft_red7, + tft_vd12acb, tft_vdden_gd, tft_vsync_ns, tx_on, uart0_cts, uart0_rts, + uart0_rxd, uart0_txd, uart1_rxd, uart1_txd. + + bias-high-impediance: supported. + bias-pull-up: supported. + bias-pull-down: supported. + bias-bus-hold: supported. + function: perip or those supported by pin's mux group. + + other pins: + + These other pins are part of various pin groups below, but can't be + controlled as GPIOs. They do however support bias-high-impediance, + bias-pull-up, bias-pull-down, and bias-bus-hold (which can also be provided + to any of the groups below to set it for all pins in that group). + + clk_out0, clk_out1, tck, tdi, tdo, tms, trst. + + bias-high-impediance: supported. + bias-pull-up: supported. + bias-pull-down: supported. + bias-bus-hold: supported. + + mux groups: + + These all support function, and some support drive configs. + + afe + pins: tx_on, rx_on, pll_on, pa_on, rx_hp, ant_sel0, + ant_sel1, gain0, gain1, gain2, gain3, gain4, + gain5, gain6, gain7. + function: afe, ts_out_0. + input-schmitt-enable: supported. + input-schmitt-disable: supported. + slew-rate: supported. + drive-strength: supported. + pdm_d + pins: pdm_d. + function: pdm_dac, usb_vbus. + sdh + pins: sdh_cd, sdh_wp, sdh_clk_in. + function: sdh, sdio. + sdio + pins: sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, + sdio_d3. + function: sdio, sdh. + spi1_cs2 + pins: spi1_cs2. + function: spi1_cs2, usb_vbus. + tft + pins: tft_red0, tft_red1, tft_red2, tft_red3, + tft_red4, tft_red5, tft_red6, tft_red7, + tft_green0, tft_green1, tft_green2, tft_green3, + tft_green4, tft_green5, tft_green6, tft_green7, + tft_blue0, tft_blue1, tft_blue2, tft_blue3, + tft_blue4, tft_blue5, tft_blue6, tft_blue7, + tft_vdden_gd, tft_panelclk, tft_blank_ls, + tft_vsync_ns, tft_hsync_nr, tft_vd12acb, + tft_pwrsave. + function: tft, ext_dac, not_iqadc_stb, iqdac_stb, ts_out_1, + lcd_trace, phy_ringosc. + input-schmitt-enable: supported. + input-schmitt-disable: supported. + slew-rate: supported. + drive-strength: supported. + + drive groups: + + These all support input-schmitt-enable, input-schmitt-disable, slew-rate, + and drive-strength. + + jtag + pins: tck, trst, tdi, tdo, tms. + scb1 + pins: scb1_sdat, scb1_sclk. + scb2 + pins: scb2_sdat, scb2_sclk. + spi0 + pins: spi0_mclk, spi0_cs0, spi0_cs1, spi0_cs2, spi0_dout, spi0_din. + spi1 + pins: spi1_mclk, spi1_cs0, spi1_cs1, spi1_cs2, spi1_dout, spi1_din. + uart + pins: uart0_txd, uart0_rxd, uart0_rts, uart0_cts, + uart1_txd, uart1_rxd. + drive_i2s + pins: clk_out1, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2, + i2s_lrclk_out, i2s_bclk_out, i2s_mclk. + drive_pdm + pins: clk_out0, pdm_b, pdm_a. + drive_scb0 + pins: scb0_sclk, scb0_sdat, pdm_d, pdm_c. + drive_sdio + pins: sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3, + sdh_wp, sdh_cd, sdh_clk_in. + + convenience groups: + + These are just convenient groupings of pins and don't support any drive + configs. + + uart0 + pins: uart0_cts, uart0_rts, uart0_rxd, uart0_txd. + uart1 + pins: uart1_rxd, uart1_txd. + scb0 + pins: scb0_sclk, scb0_sdat. + i2s + pins: i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2, + i2s_lrclk_out, i2s_mclk. + +Example: + + pinctrl: pinctrl@02005800 { + #gpio-range-cells = <3>; + compatible = "img,tz1090-pinctrl"; + reg = <0x02005800 0xe4>; + }; + +Example board file extract: + + &pinctrl { + uart0_default: uart0 { + uart0_cfg { + tz1090,pins = "uart0_rxd", + "uart0_txd"; + tz1090,function = "perip"; + }; + }; + tft_default: tft { + tft_cfg { + tz1090,pins = "tft"; + tz1090,function = "tft"; + }; + }; + }; + + uart@02004b00 { + pinctrl-names = "default"; + pinctrl-0 = <&uart0_default>; + }; -- cgit v1.1 From b58f0273f0858214da2ee4e1675221e56f7712ec Mon Sep 17 00:00:00 2001 From: James Hogan Date: Thu, 20 Jun 2013 10:26:29 +0100 Subject: pinctrl-tz1090-pdc: add TZ1090 PDC pinctrl driver Add a pin control driver for the TZ1090's low power pins via the powerdown controller SOC_GPIO_CONTROL registers. These pins have individually controlled pull-up, and group controlled schmitt, slew-rate, drive-strength, and power-on-start (pos). The pdc_gpio0 and pdc_gpio1 pins can also be muxed onto the ir_mod_stable_out and ir_mod_power_out functions respectively. If no function is set they remain in GPIO mode. These muxes can be overridden by requesting them as GPIOs. Signed-off-by: James Hogan Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: Linus Walleij Cc: linux-doc@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Linus Walleij --- .../bindings/pinctrl/img,tz1090-pdc-pinctrl.txt | 130 +++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt new file mode 100644 index 0000000..9f7a85b --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt @@ -0,0 +1,130 @@ +ImgTec TZ1090 PDC pin controller + +Required properties: +- compatible: "img,tz1090-pdc-pinctrl" +- reg: Should contain the register physical address and length of the + SOC_GPIO_CONTROL registers in the PDC register region. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +TZ1090-PDC's pin configuration nodes act as a container for an abitrary number +of subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. For this reason, even seemingly boolean +values are actually tristates in this binding: unspecified, off, or on. +Unspecified is represented as an absent property, and off/on are represented as +integer values 0 and 1. + +Required subnode-properties: +- tz1090,pins : An array of strings. Each string contains the name of a pin or + group. Valid values for these names are listed below. + +Optional subnode-properties: +- tz1090,function: A string containing the name of the function to mux to the + pin or group. Valid values for function names are listed below, including + which pingroups can be muxed to them. +- supported generic pinconfig properties (for further details see + Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt): + - bias-disable + - bias-high-impedance + - bias-bus-hold + - bias-pull-up + - bias-pull-down + - input-schmitt-enable + - input-schmitt-disable + - slew-rate: Integer, control slew rate of pins. + 0: slow (half frequency) + 1: fast + - drive-strength: Integer, control drive strength of pins in mA. + 2: 2mA + 4: 4mA + 8: 8mA + 12: 12mA + - low-power-enable: Flag, power-on-start weak pull-down for invalid power. + - low-power-disable: Flag, power-on-start weak pull-down disabled. + +Note that many of these properties are only valid for certain specific pins +or groups. See the TZ1090 TRM for complete details regarding which groups +support which functionality. The Linux pinctrl driver may also be a useful +reference. + +Valid values for pin and group names are: + + pins: + + These all support bias-high-impediance, bias-pull-up, bias-pull-down, and + bias-bus-hold (which can also be provided to any of the groups below to set + it for all gpio pins in that group). + + gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data, ext_power. + + mux groups: + + These all support function. + + gpio0 + pins: gpio0. + function: ir_mod_stable_out. + gpio1 + pins: gpio1. + function: ir_mod_power_out. + + drive groups: + + These support input-schmitt-enable, input-schmitt-disable, slew-rate, + drive-strength, low-power-enable, and low-power-disable. + + pdc + pins: gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data, + ext_power. + +Example: + + pinctrl_pdc: pinctrl@02006500 { + #gpio-range-cells = <3>; + compatible = "img,tz1090-pdc-pinctrl"; + reg = <0x02006500 0x100>; + }; + +Example board file extracts: + + &pinctrl_pdc { + pinctrl-names = "default"; + pinctrl-0 = <&syswake_default>; + + syswake_default: syswakes { + syswake_cfg { + tz1090,pins = "sys_wake0", + "sys_wake1", + "sys_wake2"; + pull-up; + }; + }; + irmod_default: irmod { + gpio0_cfg { + tz1090,pins = "gpio0"; + tz1090,function = "ir_mod_stable_out"; + }; + gpio1_cfg { + tz1090,pins = "gpio1"; + tz1090,function = "ir_mod_power_out"; + }; + }; + }; + + ir: ir@02006200 { + pinctrl-names = "default"; + pinctrl-0 = <&irmod_default>; + }; -- cgit v1.1 From 193b40aeb537b59eaa36e3dfaabedc2025332ebf Mon Sep 17 00:00:00 2001 From: "Yann E. MORIN" Date: Mon, 6 May 2013 14:57:47 +0200 Subject: kconfig: sort found symbols by relevance When searching for symbols, return the symbols sorted by relevance. Sorting is done as thus: - first, symbols that match exactly - then, alphabetical sort Since the search can be a regexp, it is possible that more than one symbol matches exactly. In this case, we can't decide which to sort first, so we fallback to alphabeticall sort. Explain this (new!) sorting heuristic in the documentation. Reported-by: Jean Delvare Signed-off-by: "Yann E. MORIN" Cc: Jean Delvare Cc: Michal Marek Cc: Roland Eggner Cc: Wang YanQing -- Changes v1->v2: - drop the previous, complex heuristic in favour of a simpler heuristic that is both easier to understand, *and* to maintain (Jean) - explain sorting heuristic in the doc (Jean) --- Documentation/kbuild/kconfig.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index 3f429ed..e9f9e76 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt @@ -174,6 +174,19 @@ Searching in menuconfig: /^hotplug + When searching, symbols are sorted thus: + - exact match first: an exact match is when the search matches + the complete symbol name; + - alphabetical order: when two symbols do not match exactly, + they are sorted in alphabetical order (in the user's current + locale). + For example: ^ATH.K matches: + ATH5K ATH9K ATH5K_AHB ATH5K_DEBUG [...] ATH6KL ATH6KL_DEBUG + [...] ATH9K_AHB ATH9K_BTCOEX_SUPPORT ATH9K_COMMON [...] + of which only ATH5K and ATH9K match exactly and so are sorted + first (and in alphabetical order), then come all other symbols, + sorted in alphabetical order. + ______________________________________________________________________ User interface options for 'menuconfig' -- cgit v1.1 From 6e6581e0a94758a4e69fab82407d39312eeff5c4 Mon Sep 17 00:00:00 2001 From: Thomas Pugliese Date: Tue, 18 Jun 2013 13:31:27 -0500 Subject: wusbcore: add entries in Documentation/ABI for new wusbhc sysfs attributes Add documenation for new ABI entries. Signed-off-by: Thomas Pugliese Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc index 25b1e75..5977e28 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 +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 +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. -- cgit v1.1 From 7525be545c839a65bb05ac71e795d17eafcaf20a Mon Sep 17 00:00:00 2001 From: "Sumit.Saxena@lsi.com" Date: Wed, 22 May 2013 12:36:17 +0530 Subject: [SCSI] megaraid_sas: Changelog and driver version update Signed-off-by: Sumit Saxena Signed-off-by: Kashyap Desai Signed-off-by: James Bottomley --- Documentation/scsi/ChangeLog.megaraid_sas | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 09673c7..cc92ca8 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,25 @@ +Release Date : Wed. May 15, 2013 17:00:00 PST 2013 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford + Kashyap Desai + Sumit Saxena +Current Version : 06.600.18.00-rc1 +Old Version : 06.506.00.00-rc1 + 1. Return DID_ERROR for scsi io, when controller is in critical h/w error. + 2. Fix the interrupt mask for Gen2 controller. + 3. Update balance count in driver to be in sync of firmware. + 4. Free event detail memory without device ID check. + 5. Set IO request timeout value provided by OS timeout for Tape devices. + 6. Add support for MegaRAID Fury (device ID-0x005f) 12Gb/s controllers. + 7. Add support to display Customer branding details in syslog. + 8. Set IoFlags to enable Fast Path for JBODs for Invader/Fury(12 Gb/s) + controllers. + 9. Add support for Extended MSI-x vectors for Invader and Fury(12Gb/s + HBA). + 10.Add support for Uneven Span PRL11. + 11.Add support to differentiate between iMR and MR Firmware. + 12.Version and Changelog update. +------------------------------------------------------------------------------- Release Date : Sat. Feb 9, 2013 17:00:00 PST 2013 - (emaild-id:megaraidlinux@lsi.com) Adam Radford -- cgit v1.1 From 8c43d2b0ca10cea9eb62d8996fb93f330be88ada Mon Sep 17 00:00:00 2001 From: Joe Liccese Date: Mon, 25 Jun 2012 12:22:09 -0500 Subject: powerpc: Add T4 LAC device tree binding & defs The Interlaken is a narrow, high speed channelized chip-to-chip interface. To facilitate interoperability between a data path device and a look-aside co-processor, the Interlaken Look-Aside protocol is defined for short transaction-related transfers. Although based on the Interlaken protocol, Interlaken Look-Aside is not directly compatible with Interlaken and can be considered a different operation mode. The Interlaken LA controller connects internal platform to Interlaken serial interface. It accepts LA command through software portals, which are system memory mapped 4KB spaces. The LA commands are then translated into the Interlaken control words and data words, which are sent on TX side to TCAM through SerDes lanes. Signed-off-by: Joe Liccese Signed-off-by: Scott Wood --- .../bindings/powerpc/fsl/interlaken-lac.txt | 309 +++++++++++++++++++++ 1 file changed, 309 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt b/Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt new file mode 100644 index 0000000..641bc13 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt @@ -0,0 +1,309 @@ +=============================================================================== +Freescale Interlaken Look-Aside Controller Device Bindings +Copyright 2012 Freescale Semiconductor Inc. + +CONTENTS + - Interlaken Look-Aside Controller (LAC) Node + - Example LAC Node + - Interlaken Look-Aside Controller (LAC) Software Portal Node + - Interlaken Look-Aside Controller (LAC) Software Portal Child Nodes + - Example LAC SWP Node with Child Nodes + +============================================================================== +Interlaken Look-Aside Controller (LAC) Node + +DESCRIPTION + +The Interlaken is a narrow, high speed channelized chip-to-chip interface. To +facilitate interoperability between a data path device and a look-aside +co-processor, the Interlaken Look-Aside protocol is defined for short +transaction-related transfers. Although based on the Interlaken protocol, +Interlaken Look-Aside is not directly compatible with Interlaken and can be +considered a different operation mode. + +The Interlaken LA controller connects internal platform to Interlaken serial +interface. It accepts LA command through software portals, which are system +memory mapped 4KB spaces. The LA commands are then translated into the +Interlaken control words and data words, which are sent on TX side to TCAM +through SerDes lanes. + +There are two 4KiB spaces defined within the LAC global register memory map. +There is a full register set at 0x0000-0x0FFF (also known as the "hypervisor" +version), and a subset at 0x1000-0x1FFF. The former is a superset of the +latter, and includes certain registers that should not be accessible to +partitioned software. Separate nodes are used for each region, with a phandle +linking the hypervisor node to the normal operating node. + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include "fsl,interlaken-lac". This represents only + those LAC CCSR registers not protected in partitioned + software. The version of the device is determined by the LAC + IP Block Revision Register (IPBRR0) at offset 0x0BF8. + + Table of correspondences between IPBRR0 values and example + chips: + Value Device + ----------- ------- + 0x02000100 T4240 + + The Hypervisor node has a different compatible. It must include + "fsl,interlaken-lac-hv". This node represents the protected + LAC register space and is required except inside a partition + where access to the hypervisor node is to be denied. + + - fsl,non-hv-node + Usage: required in "fsl,interlaken-lac-hv" + Value type: + Definition: Points to the non-protected LAC CCSR mapped register space + node. + + - reg + Usage: required + Value type: + Definition: A standard property. The first resource represents the + Interlaken LAC configuration registers. + + - interrupts: + Usage: required in non-hv node only + Value type: + Definition: Interrupt mapping for Interlaken LAC error IRQ. + +EXAMPLE + lac: lac@229000 { + compatible = "fsl,interlaken-lac" + reg = <0x229000 0x1000>; + interrupts = <16 2 1 18>; + }; + + lac-hv@228000 { + compatible = "fsl,interlaken-lac-hv" + reg = <0x228000 0x1000>; + fsl,non-hv-node = <&lac>; + }; + +=============================================================================== +Interlaken Look-Aside Controller (LAC) Software Portal Container Node + +DESCRIPTION +The Interlaken Look-Aside Controller (LAC) utilizes Software Portals to accept +Interlaken Look-Aside (ILA) commands. The Interlaken LAC software portal +memory map occupies 128KB of memory space. The software portal memory space is +intended to be cache-enabled. WIMG for each software space is required to be +0010 if stashing is enabled; otherwise, WIMG can be 0000 or 0010. + +PROPERTIES + + - #address-cells + Usage: required + Value type: + Definition: A standard property. Must have a value of 1. + + - #size-cells + Usage: required + Value type: + Definition: A standard property. Must have a value of 1. + + - compatible + Usage: required + Value type: + Definition: Must include "fsl,interlaken-lac-portals" + + - ranges + Usage: required + Value type: + Definition: A standard property. Specifies the address and length + of the LAC portal memory space. + +=============================================================================== +Interlaken Look-Aside Controller (LAC) Software Portals Child Nodes + +DESCRIPTION +There are up to 24 available software portals with each software portal +requiring 4KB of consecutive memory within the software portal memory mapped +space. + +PROPERTIES + + - compatible + Usage: required + Value type: + Definition: Must include "fsl,interlaken-lac-portal-vX.Y" where X is + the Major version (IP_MJ) found in the LAC IP Block Revision + Register (IPBRR0), at offset 0x0BF8, and Y is the Minor version + (IP_MN). + + Table of correspondences between version values and example chips: + Value Device + ------ ------- + 1.0 T4240 + + - reg + Usage: required + Value type: + Definition: A standard property. The first resource represents the + Interlaken LAC software portal registers. + + - fsl,liodn + Value type: + Definition: The logical I/O device number (LIODN) for this device. The + LIODN is a number expressed by this device and used to perform + look-ups in the IOMMU (PAMU) address table when performing + DMAs. This property is automatically added by u-boot. + +=============================================================================== +EXAMPLE + +lac-portals { + #address-cells = <0x1>; + #size-cells = <0x1>; + compatible = "fsl,interlaken-lac-portals"; + ranges = <0x0 0xf 0xf4400000 0x20000>; + + lportal0: lac-portal@0 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x204>; + reg = <0x0 0x1000>; + }; + + lportal1: lac-portal@1000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x205>; + reg = <0x1000 0x1000>; + }; + + lportal2: lac-portal@2000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x206>; + reg = <0x2000 0x1000>; + }; + + lportal3: lac-portal@3000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x207>; + reg = <0x3000 0x1000>; + }; + + lportal4: lac-portal@4000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x208>; + reg = <0x4000 0x1000>; + }; + + lportal5: lac-portal@5000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x209>; + reg = <0x5000 0x1000>; + }; + + lportal6: lac-portal@6000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x20A>; + reg = <0x6000 0x1000>; + }; + + lportal7: lac-portal@7000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x20B>; + reg = <0x7000 0x1000>; + }; + + lportal8: lac-portal@8000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x20C>; + reg = <0x8000 0x1000>; + }; + + lportal9: lac-portal@9000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x20D>; + reg = <0x9000 0x1000>; + }; + + lportal10: lac-portal@A000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x20E>; + reg = <0xA000 0x1000>; + }; + + lportal11: lac-portal@B000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x20F>; + reg = <0xB000 0x1000>; + }; + + lportal12: lac-portal@C000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x210>; + reg = <0xC000 0x1000>; + }; + + lportal13: lac-portal@D000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x211>; + reg = <0xD000 0x1000>; + }; + + lportal14: lac-portal@E000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x212>; + reg = <0xE000 0x1000>; + }; + + lportal15: lac-portal@F000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x213>; + reg = <0xF000 0x1000>; + }; + + lportal16: lac-portal@10000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x214>; + reg = <0x10000 0x1000>; + }; + + lportal17: lac-portal@11000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x215>; + reg = <0x11000 0x1000>; + }; + + lportal8: lac-portal@1200 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x216>; + reg = <0x12000 0x1000>; + }; + + lportal19: lac-portal@13000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x217>; + reg = <0x13000 0x1000>; + }; + + lportal20: lac-portal@14000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x218>; + reg = <0x14000 0x1000>; + }; + + lportal21: lac-portal@15000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x219>; + reg = <0x15000 0x1000>; + }; + + lportal22: lac-portal@16000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x21A>; + reg = <0x16000 0x1000>; + }; + + lportal23: lac-portal@17000 { + compatible = "fsl,interlaken-lac-portal-v1.0"; + fsl,liodn = <0x21B>; + reg = <0x17000 0x1000>; + }; +}; -- cgit v1.1 From f986c35689996caddfddb096ead8095c91f7f155 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Tue, 25 Jun 2013 09:07:06 +0200 Subject: regulator: max8973: fix a typo in documentation Fix a s/maxium/maxim/ typo in DT binding documentation. Reported-by: Sergei Shtylyov Signed-off-by: Guennadi Liakhovetski Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/max8973-regulator.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt index 8d38ab2..4f15d8a 100644 --- a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt @@ -2,7 +2,7 @@ Required properties: -- compatible: must be "maxium,max8973" +- compatible: must be "maxim,max8973" - reg: the i2c slave address of the regulator. It should be 0x1b. Any standard regulator properties can be used to configure the single max8973 @@ -11,7 +11,7 @@ DCDC. Example: max8973@1b { - compatible = "maxium,max8973"; + compatible = "maxim,max8973"; reg = <0x1b>; regulator-min-microvolt = <935000>; -- cgit v1.1 From 79b23b564060c5483a489562b01a6eb778a312f7 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Mon, 24 Jun 2013 16:25:32 +0200 Subject: ASoC: tas5086: add support for pwm start mode config The TAS5086 has two alternative modes to start its PWM channels, Mid-Z and Low-Z. Which one to use depends on how the PWM power stages are connected to the TAS5086. This patch adds 6 optional boolean properties to the DT bindings of the driver which allow the user to configure each individual channel to the Mid-Z scheme, and leaves all the others to the default (Low-Z). Signed-off-by: Daniel Mack Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/ti,tas5086.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/ti,tas5086.txt b/Documentation/devicetree/bindings/sound/ti,tas5086.txt index 8ea4f5b..d2866a0 100644 --- a/Documentation/devicetree/bindings/sound/ti,tas5086.txt +++ b/Documentation/devicetree/bindings/sound/ti,tas5086.txt @@ -20,6 +20,17 @@ Optional properties: When not specified, the hardware default of 1300ms is retained. + - ti,mid-z-channel-X: Boolean properties, X being a number from 1 to 6. + If given, channel X will start with the Mid-Z start + sequence, otherwise the default Low-Z scheme is used. + + The correct configuration depends on how the power + stages connected to the PWM output pins work. Not all + power stages are compatible to Mid-Z - please refer + to the datasheets for more details. + + Most systems should not set any of these properties. + Examples: i2c_bus { -- cgit v1.1 From 2352d4bf43b105ec2da5f43211db4a4c9bf34d4e Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Mon, 24 Jun 2013 16:31:30 +0200 Subject: ASoC: adau1701: allow configuration of PLL mode pins The ADAU1701 has 2 hardware pins to configure the PLL mode in accordance to the MCLK-to-LRCLK ratio. These pins have to be stable before the chip is released from reset, and a full reset cycle, including a new firmware download is needed whenever they change. This patch adds GPIO properties to the DT bindings of the Codec, and implements makes the set_sysclk memorize the configured sysclk. Because the run-time parameters are unknown at probe time, the first firmware download is postponed to the first hw_params call, when the driver can determine the mclk/lrclk divider. Subsequent downloads are only issued when the divider configuration changes. Signed-off-by: Daniel Mack Acked-by: Lars-Peter Clausen Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/adi,adau1701.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/adi,adau1701.txt b/Documentation/devicetree/bindings/sound/adi,adau1701.txt index 3afeda7..a9fbed1 100644 --- a/Documentation/devicetree/bindings/sound/adi,adau1701.txt +++ b/Documentation/devicetree/bindings/sound/adi,adau1701.txt @@ -11,6 +11,11 @@ Optional properties: - reset-gpio: A GPIO spec to define which pin is connected to the chip's !RESET pin. If specified, the driver will assert a hardware reset at probe time. + - adi,pll-mode-gpios: An array of two GPIO specs to describe the GPIOs + the ADAU's PLL config pins are connected to. + The state of the pins are set according to the + configured clock divider on ASoC side before the + firmware is loaded. Examples: @@ -19,5 +24,6 @@ Examples: compatible = "adi,adau1701"; reg = <0x34>; reset-gpio = <&gpio 23 0>; + adi,pll-mode-gpios = <&gpio 24 0 &gpio 25 0>; }; }; -- cgit v1.1 From 97d0a868450d08fae0db3f53459852901c6e2f4f Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Mon, 24 Jun 2013 16:31:32 +0200 Subject: ASoC: adau1701: add support for pin muxing The ADAU1701 has 12 pins that can be configured depending on the system configuration. Allow settting the corresponding registers from DT. Signed-off-by: Daniel Mack Acked-by: Lars-Peter Clausen Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/adi,adau1701.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/adi,adau1701.txt b/Documentation/devicetree/bindings/sound/adi,adau1701.txt index a9fbed1..547a49b 100644 --- a/Documentation/devicetree/bindings/sound/adi,adau1701.txt +++ b/Documentation/devicetree/bindings/sound/adi,adau1701.txt @@ -16,6 +16,10 @@ Optional properties: The state of the pins are set according to the configured clock divider on ASoC side before the firmware is loaded. + - adi,pin-config: An array of 12 numerical values selecting one of the + pin configurations as described in the datasheet, + table 53. Note that the value of this property has + to be prefixed with '/bits/ 8'. Examples: @@ -25,5 +29,7 @@ Examples: reg = <0x34>; reset-gpio = <&gpio 23 0>; adi,pll-mode-gpios = <&gpio 24 0 &gpio 25 0>; + adi,pin-config = /bits/ 8 <0x4 0x7 0x5 0x5 0x4 0x4 + 0x4 0x4 0x4 0x4 0x4 0x4>; }; }; -- cgit v1.1 From 80b022e29bfdffb6c9ac0a283bcad3e1030c4c7e Mon Sep 17 00:00:00 2001 From: Jonghwa Lee Date: Tue, 25 Jun 2013 10:08:38 +0900 Subject: regulator: max77693: Add max77693 regualtor driver. This patch adds new regulator driver to support max77693 chip's regulators. max77693 has two linear voltage regulators and one current regulator which can be controlled through I2C bus. This driver also supports device tree. Signed-off-by: Jonghwa Lee Signed-off-by: Myungjoo Ham Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/mfd/max77693.txt | 55 ++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/max77693.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt new file mode 100644 index 0000000..11921cc --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/max77693.txt @@ -0,0 +1,55 @@ +Maxim MAX77693 multi-function device + +MAX77693 is a Multifunction device with the following submodules: +- PMIC, +- CHARGER, +- LED, +- MUIC, +- HAPTIC + +It is interfaced to host controller using i2c. +This document describes the bindings for the mfd device. + +Required properties: +- compatible : Must be "maxim,max77693". +- reg : Specifies the i2c slave address of PMIC block. +- interrupts : This i2c device has an IRQ line connected to the main SoC. +- interrupt-parent : The parent interrupt controller. + +Optional properties: +- regulators : The regulators of max77693 have to be instantiated under subnod + named "regulators" using the following format. + + regulators { + regualtor-compatible = ESAFEOUT1/ESAFEOUT2/CHARGER + standard regulator constratints[*]. + }; + + [*] refer Documentation/devicetree/bindings/regulator/regulator.txt + +Example: + max77693@66 { + compatible = "maxim,max77693"; + reg = <0x66>; + interrupt-parent = <&gpx1>; + interrupts = <5 2>; + + regulators { + esafeout@1 { + regulator-compatible = "ESAFEOUT1"; + regulator-name = "ESAFEOUT1"; + regulator-boot-on; + }; + esafeout@2 { + regulator-compatible = "ESAFEOUT2"; + regulator-name = "ESAFEOUT2"; + }; + charger@0 { + regulator-compatible = "CHARGER"; + regulator-name = "CHARGER"; + regulator-min-microamp = <60000>; + regulator-max-microamp = <2580000>; + regulator-boot-on; + }; + }; + }; -- cgit v1.1 From ad42fc6c84795d19972e7f7dee70fe74bec4c2d8 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 24 Jun 2013 15:06:19 +0200 Subject: pinctrl: rip out the direct pinconf API From the inception ot the pin config API there has been the possibility to get a handle at a pin directly and configure its electrical characteristics. For this reason we had: int pin_config_get(const char *dev_name, const char *name, unsigned long *config); int pin_config_set(const char *dev_name, const char *name, unsigned long config); int pin_config_group_get(const char *dev_name, const char *pin_group, unsigned long *config); int pin_config_group_set(const char *dev_name, const char *pin_group, unsigned long config); After the introduction of the pin control states that will control pins associated with devices, and its subsequent introduction to the device core, as well as the introduction of pin control hogs that can set up states on boot and optionally also at sleep, this direct pin control API is a thing of the past. As could be expected, it has zero in-kernel users. Let's delete this API and make our world simpler. Reported-by: Tony Lindgren Reviewed-by: Stephen Warren Acked-by: Tony Lindgren Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 3ee2475..c5948c7 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -203,15 +203,8 @@ using a certain resistor value - pull up and pull down - so that the pin has a stable value when nothing is driving the rail it is connected to, or when it's unconnected. -Pin configuration can be programmed either using the explicit APIs described -immediately below, or by adding configuration entries into the mapping table; -see section "Board/machine configuration" below. - -For example, a platform may do the following to pull up a pin to VDD: - -#include - -ret = pin_config_set("foo-dev", "FOO_GPIO_PIN", PLATFORM_X_PULL_UP); +Pin configuration can be programmed by adding configuration entries into the +mapping table; see section "Board/machine configuration" below. The format and meaning of the configuration parameter, PLATFORM_X_PULL_UP above, is entirely defined by the pin controller driver. -- cgit v1.1 From 70637a6dcaa6e4cb707d0d50a7ea448f13438786 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Tue, 25 Jun 2013 14:55:42 +0200 Subject: pinctrl: more clarifications for generic pull configs PULL_PIN_DEFAULT is meant for hardware completely hiding any pull settings from the driver, so that it's really only possible to turn the pull on or off, but it not being possible to determine any pull settings from software. Also the binding-documentation for the pull arguments did not match the changes to the expected values. Signed-off-by: Heiko Stuebner Reviewed-by: James Hogan Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index 2d730e3..7498bdc 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -165,9 +165,8 @@ output-high - set the pin to output mode with high level Arguments for parameters: -- bias-pull-up, -down and -pin-default take as optional argument 0 to disable - the pull, on hardware supporting it the pull strength in Ohm. bias-disable - will also disable any active pull. +- bias-pull-up, -down and -pin-default take as optional argument on hardware + supporting it the pull strength in Ohm. bias-disable will disable the pull. - drive-strength takes as argument the target strength in mA. -- cgit v1.1 From 256aeb648741bf095e884793862d3dfa6b1c1fb5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Tue, 25 Jun 2013 14:56:11 +0200 Subject: pinctrl: set unit for debounce time pinconfig to usec Currently the debounce time pinconfig option uses an unspecified "time units" unit. As pinconfig options should use SI units and a real unit is also necessary for generic dt bindings, change it to usec. Currently no driver is using the generic pinconfig option for this, so the unit change is safe to do. Signed-off-by: Heiko Stuebner Reviewed-by: James Hogan Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index 7498bdc..788ab09 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -173,7 +173,8 @@ Arguments for parameters: - input-schmitt takes as argument the adjustable hysteresis in a driver-specific format -- input-debounce takes the debounce time as argument or 0 to disable debouncing +- input-debounce takes the debounce time in usec as argument + or 0 to disable debouncing - power-source argument is the custom value describing the source to select -- cgit v1.1 From a7b3bf55e7435ad38cd17b9da257dc7314d862f6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Tue, 25 Jun 2013 14:56:36 +0200 Subject: pinctrl: remove slew-rate parameter from tz1090 As the binding for slew-rate is under discussion and seems to need more tought it will get removed for now, so it doesn't get an offical release. Therefore remove it again from the only current user, tz1090. Signed-off-by: Heiko Stuebner Reviewed-by: James Hogan Signed-off-by: Linus Walleij --- .../devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt | 5 +---- Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt | 7 +------ 2 files changed, 2 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt index 9f7a85b..a186181 100644 --- a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt @@ -44,9 +44,6 @@ Optional subnode-properties: - bias-pull-down - input-schmitt-enable - input-schmitt-disable - - slew-rate: Integer, control slew rate of pins. - 0: slow (half frequency) - 1: fast - drive-strength: Integer, control drive strength of pins in mA. 2: 2mA 4: 4mA @@ -83,7 +80,7 @@ Valid values for pin and group names are: drive groups: - These support input-schmitt-enable, input-schmitt-disable, slew-rate, + These support input-schmitt-enable, input-schmitt-disable, drive-strength, low-power-enable, and low-power-disable. pdc diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt index 39bfd9c..4b27c99 100644 --- a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt @@ -44,9 +44,6 @@ Optional subnode-properties: - bias-pull-down - input-schmitt-enable - input-schmitt-disable - - slew-rate: Integer, control slew rate of pins. - 0: slow (half frequency) - 1: fast - drive-strength: Integer, control drive strength of pins in mA. 2: 2mA 4: 4mA @@ -124,7 +121,6 @@ Valid values for pin and group names are: function: afe, ts_out_0. input-schmitt-enable: supported. input-schmitt-disable: supported. - slew-rate: supported. drive-strength: supported. pdm_d pins: pdm_d. @@ -153,12 +149,11 @@ Valid values for pin and group names are: lcd_trace, phy_ringosc. input-schmitt-enable: supported. input-schmitt-disable: supported. - slew-rate: supported. drive-strength: supported. drive groups: - These all support input-schmitt-enable, input-schmitt-disable, slew-rate, + These all support input-schmitt-enable, input-schmitt-disable, and drive-strength. jtag -- cgit v1.1 From 5b81d55c4ccf23b9de398f819571dfc8941c7b04 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Tue, 25 Jun 2013 14:57:10 +0200 Subject: pinctrl: remove bindings for pinconf options needing more thought Some options currently take arguments in unspecified driver-specific units. As pointed out by Stephen Warren, driver specific values should not be part of generic devicetree bindings describing the hardware. Therefore remove the critical bindings again, before they become part of an official release. Signed-off-by: Heiko Stuebner Reviewed-by: James Hogan Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index 788ab09..aeb3c99 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -154,10 +154,7 @@ drive-open-source - drive with open source drive-strength - sink or source at most X mA input-schmitt-enable - enable schmitt-trigger mode input-schmitt-disable - disable schmitt-trigger mode -input-schmitt - run in schmitt-trigger mode with hysteresis X input-debounce - debounce mode with debound time X -power-source - select power source X -slew-rate - use slew-rate X low-power-enable - enable low power mode low-power-disable - disable low power mode output-low - set the pin to output mode with low level @@ -170,16 +167,9 @@ Arguments for parameters: - drive-strength takes as argument the target strength in mA. -- input-schmitt takes as argument the adjustable hysteresis in a - driver-specific format - - input-debounce takes the debounce time in usec as argument or 0 to disable debouncing -- power-source argument is the custom value describing the source to select - -- slew-rate takes as argument the target rate in a driver-specific format - All parameters not listed here, do not take an argument. More in-depth documentation on these parameters can be found in -- cgit v1.1 From 701016c0cba594d5dbd26652ed1e52b0fe2926fd Mon Sep 17 00:00:00 2001 From: Srinivas KANDAGATLA Date: Thu, 20 Jun 2013 15:05:38 +0100 Subject: pinctrl: st: Add pinctrl and pinconf support. This patch add pinctrl support to ST SoCs. About hardware: ST Set-Top-Box parts have two blocks called PIO and PIO-mux which handle pin configurations. Each multi-function pin is controlled, driven and routed through the PIO multiplexing block. Each pin supports GPIO functionality (ALT0) and multiple alternate functions(ALT1 - ALTx) that directly connect the pin to different hardware blocks. When a pin is in GPIO mode, Output Enable (OE), Open Drain(OD), and Pull Up (PU) are driven by the related PIO block. Otherwise the PIO multiplexing block configures these parameters and retiming the signal. About driver: This pinctrl driver manages both PIO and PIO-mux block using pinctrl, pinconf, pinmux, gpio subsystems. All the pinctrl related config information can only come from device trees. Signed-off-by: Srinivas Kandagatla Acked-by: Linus Walleij Signed-off-by: Mark Brown --- .../devicetree/bindings/pinctrl/pinctrl-st.txt | 110 +++++++++++++++++++++ 1 file changed, 110 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt new file mode 100644 index 0000000..05bf82a --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt @@ -0,0 +1,110 @@ +*ST pin controller. + +Each multi-function pin is controlled, driven and routed through the +PIO multiplexing block. Each pin supports GPIO functionality (ALT0) +and multiple alternate functions(ALT1 - ALTx) that directly connect +the pin to different hardware blocks. + +When a pin is in GPIO mode, Output Enable (OE), Open Drain(OD), and +Pull Up (PU) are driven by the related PIO block. + +ST pinctrl driver controls PIO multiplexing block and also interacts with +gpio driver to configure a pin. + +Required properties: (PIO multiplexing block) +- compatible : should be "st,--pinctrl" + like st,stih415-sbc-pinctrl, st,stih415-front-pinctrl and so on. +- gpio-controller : Indicates this device is a GPIO controller +- #gpio-cells : Should be one. The first cell is the pin number. +- st,retime-pin-mask : Should be mask to specify which pins can be retimed. + If the property is not present, it is assumed that all the pins in the + bank are capable of retiming. Retiming is mainly used to improve the + IO timing margins of external synchronous interfaces. +- st,bank-name : Should be a name string for this bank as + specified in datasheet. +- st,syscfg : Should be a phandle of the syscfg node. + +Example: + pin-controller-sbc { + #address-cells = <1>; + #size-cells = <1>; + compatible = "st,stih415-sbc-pinctrl"; + st,syscfg = <&syscfg_sbc>; + ranges = <0 0xfe610000 0x5000>; + PIO0: gpio@fe610000 { + gpio-controller; + #gpio-cells = <1>; + reg = <0 0x100>; + st,bank-name = "PIO0"; + }; + ... + pin-functions nodes follow... + }; + + +Contents of function subnode node: +---------------------- +Required properties for pin configuration node: +- st,pins : Child node with list of pins with configuration. + +Below is the format of how each pin conf should look like. + + + +Every PIO is represented with 4-7 parameters depending on retime configuration. +Each parameter is explained as below. + +-bank : Should be bank phandle to which this PIO belongs. +-offset : Offset in the PIO bank. +-mux : Should be alternate function number associated this pin. + Use same numbers from datasheet. +-mode :pin configuration is selected from one of the below values. + IN + IN_PU + OUT + BIDIR + BIDIR_PU + +-rt_type Retiming Configuration for the pin. + Possible retime configuration are: + + ------- ------------- + value args + ------- ------------- + NICLK + ICLK_IO + BYPASS + DE_IO + SE_ICLK_IO + SE_NICLK_IO + +- delay is retime delay in pico seconds as mentioned in data sheet. + +- rt_clk :clk to be use for retime. + Possible values are: + CLK_A + CLK_B + CLK_C + CLK_D + +Example of mmcclk pin which is a bi-direction pull pu with retime config +as non inverted clock retimed with CLK_B and delay of 0 pico seconds: + +pin-controller { + ... + mmc0 { + pinctrl_mmc: mmc { + st,pins { + mmcclk = <&PIO13 4 ALT4 BIDIR_PU NICLK 0 CLK_B>; + ... + }; + }; + ... + }; +}; + +sdhci0:sdhci@fe810000{ + ... + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_mmc>; +}; -- cgit v1.1 From 41cc2aaf802ee21a3eb2c4bcb6995b3bb975bf87 Mon Sep 17 00:00:00 2001 From: Thomas Abraham Date: Tue, 25 Jun 2013 09:20:08 -0700 Subject: Input: samsung-keypad - let device core setup the default pin configuration With device core now able to setup the default pin configuration, the pin configuration code based on the deprecated Samsung specific gpio bindings is removed. Signed-off-by: Thomas Abraham Acked-by: Linus Walleij Signed-off-by: Sachin Kamat Signed-off-by: Dmitry Torokhov --- .../devicetree/bindings/input/samsung-keypad.txt | 24 +++++----------------- 1 file changed, 5 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt b/Documentation/devicetree/bindings/input/samsung-keypad.txt index ce3e394..942d071 100644 --- a/Documentation/devicetree/bindings/input/samsung-keypad.txt +++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt @@ -25,14 +25,6 @@ Required Board Specific Properties: - samsung,keypad-num-columns: Number of column lines connected to the keypad controller. -- row-gpios: List of gpios used as row lines. The gpio specifier for - this property depends on the gpio controller to which these row lines - are connected. - -- col-gpios: List of gpios used as column lines. The gpio specifier for - this property depends on the gpio controller to which these column - lines are connected. - - Keys represented as child nodes: Each key connected to the keypad controller is represented as a child node to the keypad controller device node and should include the following properties. @@ -41,6 +33,9 @@ Required Board Specific Properties: - linux,code: the key-code to be reported when the key is pressed and released. +- pinctrl-0: Should specify pin control groups used for this controller. +- pinctrl-names: Should contain only one value - "default". + Optional Properties specific to linux: - linux,keypad-no-autorepeat: do no enable autorepeat feature. - linux,keypad-wakeup: use any event on keypad as wakeup event. @@ -56,17 +51,8 @@ Example: linux,input-no-autorepeat; linux,input-wakeup; - row-gpios = <&gpx2 0 3 3 0 - &gpx2 1 3 3 0>; - - col-gpios = <&gpx1 0 3 0 0 - &gpx1 1 3 0 0 - &gpx1 2 3 0 0 - &gpx1 3 3 0 0 - &gpx1 4 3 0 0 - &gpx1 5 3 0 0 - &gpx1 6 3 0 0 - &gpx1 7 3 0 0>; + pinctrl-names = "default"; + pinctrl-0 = <&keypad_rows &keypad_columns>; key_1 { keypad,row = <0>; -- cgit v1.1 From b06eb0173ef1d9366d14b4ca3e8e38dc72b03e8b Mon Sep 17 00:00:00 2001 From: Christian Ruppert Date: Tue, 25 Jun 2013 18:29:57 +0200 Subject: irqchip: Add TB10x interrupt controller driver The SOC interrupt controller driver for the Abilis Systems TB10x series of SOCs based on ARC700 CPUs. Signed-off-by: Christian Ruppert Signed-off-by: Pierrick Hascoet Cc: Vineet Gupta Cc: Grant Likely Cc: Rob Herring Cc: Rob Landley Cc: devicetree-discuss@lists.ozlabs.org Link: http://lkml.kernel.org/r/1372177797-9458-1-git-send-email-christian.ruppert@abilis.com Signed-off-by: Thomas Gleixner --- .../interrupt-controller/abilis,tb10x-ictl.txt | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt (limited to 'Documentation') 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 0000000..9d52d5a --- /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>; +}; -- cgit v1.1 From 65ebcc1158891c8c0abef726d59a7840454ad25d Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Tue, 25 Jun 2013 12:15:10 +0100 Subject: ARM: sti: Add STiH415 SOC support The STiH415 is the next generation of HD, AVC set-top box processors for satellite, cable, terrestrial and IP-STB markets. It is an ARM Cortex-A9 1.0 GHz, dual-core CPU. Signed-off-by: Srinivas Kandagatla CC: Stephen Gallimore CC: Stuart Menefy CC: Arnd Bergmann CC: Linus Walleij Signed-off-by: Srinivas Kandagatla Signed-off-by: Olof Johansson --- Documentation/arm/sti/overview.txt | 33 ++++++++++++++++++++++++++++++ Documentation/arm/sti/stih415-overview.txt | 12 +++++++++++ 2 files changed, 45 insertions(+) create mode 100644 Documentation/arm/sti/overview.txt create mode 100644 Documentation/arm/sti/stih415-overview.txt (limited to 'Documentation') diff --git a/Documentation/arm/sti/overview.txt b/Documentation/arm/sti/overview.txt new file mode 100644 index 0000000..1a4e93d --- /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 , (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 0000000..1383e33 --- /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 -- cgit v1.1 From 15969b457734feb46cc813745b039cf4ae9089ff Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Tue, 25 Jun 2013 12:15:23 +0100 Subject: ARM: sti: Add STiH416 SOC support The STiH416 is advanced HD AVC processor with 3D graphics acceleration and 1.2-GHz ARM Cortex-A9 SMP CPU. Signed-off-by: Srinivas Kandagatla CC: Stephen Gallimore CC: Stuart Menefy CC: Arnd Bergmann CC: Linus Walleij Signed-off-by: Srinivas Kandagatla Signed-off-by: Olof Johansson --- Documentation/arm/sti/stih416-overview.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 Documentation/arm/sti/stih416-overview.txt (limited to 'Documentation') diff --git a/Documentation/arm/sti/stih416-overview.txt b/Documentation/arm/sti/stih416-overview.txt new file mode 100644 index 0000000..558444c --- /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 -- cgit v1.1 From 98c33c5a971bbca31160e5e4a362496c4d702357 Mon Sep 17 00:00:00 2001 From: Will Deacon Date: Mon, 24 Jun 2013 18:31:24 +0100 Subject: documentation/iommu: Add description of ARM System MMU binding This patch adds a description of the device tree binding for the ARM System MMU architecture. Cc: Rob Herring Cc: Andreas Herrmann Cc: Joerg Roedel Acked-by: Grant Likely Signed-off-by: Will Deacon Acked-by: Andreas Herrmann Signed-off-by: Joerg Roedel --- .../devicetree/bindings/iommu/arm,smmu.txt | 70 ++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt new file mode 100644 index 0000000..e34c6cd --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt @@ -0,0 +1,70 @@ +* ARM System MMU Architecture Implementation + +ARM SoCs may contain an implementation of the ARM System Memory +Management Unit Architecture, which can be used to provide 1 or 2 stages +of address translation to bus masters external to the CPU. + +The SMMU may also raise interrupts in response to various fault +conditions. + +** System MMU required properties: + +- compatible : Should be one of: + + "arm,smmu-v1" + "arm,smmu-v2" + "arm,mmu-400" + "arm,mmu-500" + + depending on the particular implementation and/or the + version of the architecture implemented. + +- reg : Base address and size of the SMMU. + +- #global-interrupts : The number of global interrupts exposed by the + device. + +- interrupts : Interrupt list, with the first #global-irqs entries + corresponding to the global interrupts and any + following entries corresponding to context interrupts, + specified in order of their indexing by the SMMU. + + For SMMUv2 implementations, there must be exactly one + interrupt per context bank. In the case of a single, + combined interrupt, it must be listed multiple times. + +- mmu-masters : A list of phandles to device nodes representing bus + masters for which the SMMU can provide a translation + and their corresponding StreamIDs (see example below). + Each device node linked from this list must have a + "#stream-id-cells" property, indicating the number of + StreamIDs associated with it. + +** System MMU optional properties: + +- smmu-parent : When multiple SMMUs are chained together, this + property can be used to provide a phandle to the + parent SMMU (that is the next SMMU on the path going + from the mmu-masters towards memory) node for this + SMMU. + +Example: + + smmu { + compatible = "arm,smmu-v1"; + reg = <0xba5e0000 0x10000>; + #global-interrupts = <2>; + interrupts = <0 32 4>, + <0 33 4>, + <0 34 4>, /* This is the first context interrupt */ + <0 35 4>, + <0 36 4>, + <0 37 4>; + + /* + * Two DMA controllers, the first with two StreamIDs (0xd01d + * and 0xd01e) and the second with only one (0xd11c). + */ + mmu-masters = <&dma0 0xd01d 0xd01e>, + <&dma1 0xd11c>; + }; -- cgit v1.1 From 4c730a06c19bb83d2fa4308ee4cbb23abc84c9ca Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT Date: Fri, 21 Jun 2013 15:32:06 +0200 Subject: i2c: mv64xxx: Set bus frequency to 100kHz if clock-frequency is not provided This commit adds checking whether clock-frequency property acquisition has succeeded. If not, the frequency is set to 100kHz by default. The Device Tree binding documentation is updated accordingly. Based on the intials patches from Zbigniew Bodek Signed-off-by: Gregory CLEMENT Signed-off-by: Zbigniew Bodek Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt index f46d928..a1ee681 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt @@ -6,7 +6,11 @@ Required properties : - reg : Offset and length of the register set for the device - compatible : Should be "marvell,mv64xxx-i2c" - interrupts : The interrupt number - - clock-frequency : Desired I2C bus clock frequency in Hz. + +Optional properties : + + - clock-frequency : Desired I2C bus clock frequency in Hz. If not set the +default frequency is 100kHz Examples: -- cgit v1.1 From e4f2379db6c6823c5d4a4c2c912df00c65de51d7 Mon Sep 17 00:00:00 2001 From: Alexey Brodkin Date: Mon, 24 Jun 2013 09:54:27 +0400 Subject: ethernet/arc/arc_emac - Add new driver Driver for non-standard on-chip ethernet device ARC EMAC 10/100, instantiated in some legacy ARC (Synopsys) FPGA Boards such as ARCAngel4/ML50x. Signed-off-by: Alexey Brodkin Cc: Andy Shevchenko Cc: Francois Romieu Cc: Joe Perches Cc: Vineet Gupta Cc: Mischa Jonker Cc: Arnd Bergmann Cc: Grant Likely Cc: Rob Herring Cc: Paul Gortmaker Cc: "David S. Miller" Cc: linux-kernel@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org Cc: Florian Fainelli Cc: David Laight Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/arc_emac.txt | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/arc_emac.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt b/Documentation/devicetree/bindings/net/arc_emac.txt new file mode 100644 index 0000000..bcbc3f0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/arc_emac.txt @@ -0,0 +1,38 @@ +* Synopsys ARC EMAC 10/100 Ethernet driver (EMAC) + +Required properties: +- compatible: Should be "snps,arc-emac" +- reg: Address and length of the register set for the device +- interrupts: Should contain the EMAC interrupts +- clock-frequency: CPU frequency. It is needed to calculate and set polling +period of EMAC. +- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations +bandwidth of external memory controller might be a limiting factor. That's why +it's required to specify which data-rate is supported on current SoC or FPGA. +For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s is +supported (100BASE-TX) set "100". +- phy: PHY device attached to the EMAC via MDIO bus + +Child nodes of the driver are the individual PHY devices connected to the +MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus. + +Optional properties: +- mac-address: 6 bytes, mac address + +Examples: + + ethernet@c0fc2000 { + compatible = "snps,arc-emac"; + reg = <0xc0fc2000 0x3c>; + interrupts = <6>; + mac-address = [ 00 11 22 33 44 55 ]; + clock-frequency = <80000000>; + max-speed = <100>; + phy = <&phy0>; + + #address-cells = <1>; + #size-cells = <0>; + phy0: ethernet-phy@0 { + reg = <1>; + }; + }; -- cgit v1.1 From 2d48d67fa8cd129ea85ea02d91b4a793286866f8 Mon Sep 17 00:00:00 2001 From: Eliezer Tamir Date: Mon, 24 Jun 2013 10:28:03 +0300 Subject: net: poll/select low latency socket support select/poll busy-poll support. Split sysctl value into two separate ones, one for read and one for poll. updated Documentation/sysctl/net.txt Add a new poll flag POLL_LL. When this flag is set, sock_poll will call sk_poll_ll if possible. sock_poll sets this flag in its return value to indicate to select/poll when a socket that can busy poll is found. When poll/select have nothing to report, call the low-level sock_poll again until we are out of time or we find something. Once the system call finds something, it stops setting POLL_LL, so it can return the result to the user ASAP. Signed-off-by: Eliezer Tamir Signed-off-by: David S. Miller --- Documentation/sysctl/net.txt | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index 5369879..e658bbf 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -50,13 +50,27 @@ The maximum number of packets that kernel can handle on a NAPI interrupt, it's a Per-CPU variable. Default: 64 -low_latency_poll +low_latency_read ---------------- -Low latency busy poll timeout. (needs CONFIG_NET_LL_RX_POLL) +Low latency busy poll timeout for socket reads. (needs CONFIG_NET_LL_RX_POLL) Approximate time in us to spin waiting for packets on the device queue. +This sets the default value of the SO_LL socket option. +Can be set or overridden per socket by setting socket option SO_LL. Recommended value is 50. May increase power usage. Default: 0 (off) +low_latency_poll +---------------- +Low latency busy poll timeout for poll and select. (needs CONFIG_NET_LL_RX_POLL) +Approximate time in us to spin waiting for packets on the device queue. +Recommended value depends on the number of sockets you poll on. +For several sockets 50, for several hundreds 100. +For more than that you probably want to use epoll. +Note that only sockets with SO_LL set will be busy polled, so you want to either +selectively set SO_LL on those sockets or set sysctl.net.low_latency_read globally. +May increase power usage. +Default: 0 (off) + rmem_default ------------ -- cgit v1.1 From 762375766143aba42e74713f8364b4953c40a354 Mon Sep 17 00:00:00 2001 From: Cong Wang Date: Mon, 24 Jun 2013 19:46:54 +0800 Subject: doc: fix some syntax errors in netlink mmap sample code Cc: Patrick McHardy Cc: David S. Miller Signed-off-by: Cong Wang Signed-off-by: David S. Miller --- Documentation/networking/netlink_mmap.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netlink_mmap.txt b/Documentation/networking/netlink_mmap.txt index e6088ba..5cc6005 100644 --- a/Documentation/networking/netlink_mmap.txt +++ b/Documentation/networking/netlink_mmap.txt @@ -274,9 +274,9 @@ This example assumes some ring parameters of the ring setup are available. /* Get next frame header */ hdr = rx_ring + frame_offset; - if (hdr->nm_status == NL_MMAP_STATUS_VALID) + if (hdr->nm_status == NL_MMAP_STATUS_VALID) { /* Regular memory mapped frame */ - nlh = (void *hdr) + NL_MMAP_HDRLEN; + nlh = (void *)hdr + NL_MMAP_HDRLEN; len = hdr->nm_len; /* Release empty message immediately. May happen -- cgit v1.1 From d7d35c681fb4eae1fab3d93698e26a106ca7e79e Mon Sep 17 00:00:00 2001 From: Veaceslav Falico Date: Mon, 24 Jun 2013 11:49:33 +0200 Subject: bonding: doc: some details on backup slave arp validation Add some details to bonding documentation on how backup slave arp validation works. Signed-off-by: Veaceslav Falico Signed-off-by: David S. Miller --- Documentation/networking/bonding.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index e7454fc..adee3b4 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -303,6 +303,12 @@ arp_validate such a situation, validation of backup slaves must be disabled. + The validation of ARP requests on backup slaves is mainly + helping bonding to decide which slaves are more likely to + work in case of the active slave failure, it doesn't really + guarantee that the backup slave will work if it's selected + as the next active slave. + This option is useful in network configurations in which multiple bonding hosts are concurrently issuing ARPs to one or more targets beyond a common switch. Should the link between -- cgit v1.1 From 8599b52e14a1611dcb563289421bee76751f1d53 Mon Sep 17 00:00:00 2001 From: Veaceslav Falico Date: Mon, 24 Jun 2013 11:49:34 +0200 Subject: bonding: add an option to fail when any of arp_ip_target is inaccessible Currently, we fail only when all of the ips in arp_ip_target are gone. However, in some situations we might need to fail if even one host from arp_ip_target becomes unavailable. All situations, obviously, rely on the idea that we need *completely* functional network, with all interfaces/addresses working correctly. One real world example might be: vlans on top on bond (hybrid port). If bond and vlans have ips assigned and we have their peers monitored via arp_ip_target - in case of switch misconfiguration (trunk/access port), slave driver malfunction or tagged/untagged traffic dropped on the way - we will be able to switch to another slave. Though any other configuration needs that if we need to have access to all arp_ip_targets. This patch adds this possibility by adding a new parameter - arp_all_targets (both as a module parameter and as a sysfs knob). It can be set to: 0 or any (the default) - which works exactly as it's working now - the slave is up if any of the arp_ip_targets are up. 1 or all - the slave is up if all of the arp_ip_targets are up. This parameter can be changed on the fly (via sysfs), and requires the mode to be active-backup and arp_validate to be enabled (it obeys the arp_validate config on which slaves to validate). Internally it's done through: 1) Add target_last_arp_rx[BOND_MAX_ARP_TARGETS] array to slave struct. It's an array of jiffies, meaning that slave->target_last_arp_rx[i] is the last time we've received arp from bond->params.arp_targets[i] on this slave. 2) If we successfully validate an arp from bond->params.arp_targets[i] in bond_validate_arp() - update the slave->target_last_arp_rx[i] with the current jiffies value. 3) When getting slave's last_rx via slave_last_rx(), we return the oldest time when we've received an arp from any address in bond->params.arp_targets[]. If the value of arp_all_targets == 0 - we still work the same way as before. Also, update the documentation to reflect the new parameter. v3->v4: Kill the forgotten rtnl_unlock(), rephrase the documentation part to be more clear, don't fail setting arp_all_targets if arp_validate is not set - it has no effect anyway but can be easier to set up. Also, print a warning if the last arp_ip_target is removed while the arp_interval is on, but not the arp_validate. v2->v3: Use _bh spinlock, remove useless rtnl_lock() and use jiffies for new arp_ip_target last arp, instead of slave_last_rx(). On bond_enslave(), use the same initialization value for target_last_arp_rx[] as is used for the default last_arp_rx, to avoid useless interface flaps. Also, instead of failing to remove the last arp_ip_target just print a warning - otherwise it might break existing scripts. v1->v2: Correctly handle adding/removing hosts in arp_ip_target - we need to shift/initialize all slave's target_last_arp_rx. Also, don't fail module loading on arp_all_targets misconfiguration, just disable it, and some minor style fixes. Signed-off-by: Veaceslav Falico Signed-off-by: David S. Miller --- Documentation/networking/bonding.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index adee3b4..87bbcfe 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -321,6 +321,25 @@ arp_validate This option was added in bonding version 3.1.0. +arp_all_targets + + Specifies the quantity of arp_ip_targets that must be reachable + in order for the ARP monitor to consider a slave as being up. + This option affects only active-backup mode for slaves with + arp_validation enabled. + + Possible values are: + + any or 0 + + consider the slave up only when any of the arp_ip_targets + is reachable + + all or 1 + + consider the slave up only when all of the arp_ip_targets + are reachable + downdelay Specifies the time, in milliseconds, to wait before disabling -- cgit v1.1 From c4a39551451666229b4ea5e8aae8ca0131d00665 Mon Sep 17 00:00:00 2001 From: Jonathan Brassow Date: Tue, 25 Jun 2013 01:23:59 -0500 Subject: MD: Remember the last sync operation that was performed MD: Remember the last sync operation that was performed This patch adds a field to the mddev structure to track the last sync operation that was performed. This is especially useful when it comes to what is recorded in mismatch_cnt in sysfs. If the last operation was "data-check", then it reports the number of descrepancies found by the user-initiated check. If it was a "repair" operation, then it is reporting the number of descrepancies repaired. etc. Signed-off-by: Jonathan Brassow Signed-off-by: NeilBrown --- Documentation/device-mapper/dm-raid.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt index 2bb3a68..ef8ba9f 100644 --- a/Documentation/device-mapper/dm-raid.txt +++ b/Documentation/device-mapper/dm-raid.txt @@ -223,3 +223,4 @@ Version History 1.5.0 Add message interface to allow manipulation of the sync_action. New status (STATUSTYPE_INFO) fields: sync_action and mismatch_cnt. 1.5.1 Add ability to restore transiently failed devices on resume. +1.5.2 'mismatch_cnt' is zero unless [last_]sync_action is "check". -- cgit v1.1 From 4d0c875dcc4923476f364e83912d134da2df224c Mon Sep 17 00:00:00 2001 From: Julian Anastasov Date: Mon, 24 Jun 2013 22:44:41 +0300 Subject: ipvs: add sync_persist_mode flag Add sync_persist_mode flag to reduce sync traffic by syncing only persistent templates. Signed-off-by: Julian Anastasov Tested-by: Aleksey Chudov Signed-off-by: Simon Horman --- Documentation/networking/ipvs-sysctl.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt index 9573d0c..7a3c047 100644 --- a/Documentation/networking/ipvs-sysctl.txt +++ b/Documentation/networking/ipvs-sysctl.txt @@ -181,6 +181,19 @@ snat_reroute - BOOLEAN always be the same as the original route so it is an optimisation to disable snat_reroute and avoid the recalculation. +sync_persist_mode - INTEGER + default 0 + + Controls the synchronisation of connections when using persistence + + 0: All types of connections are synchronised + 1: Attempt to reduce the synchronisation traffic depending on + the connection type. For persistent services avoid synchronisation + for normal connections, do it only for persistence templates. + In such case, for TCP and SCTP it may need enabling sloppy_tcp and + sloppy_sctp flags on backup servers. For non-persistent services + such optimization is not applied, mode 0 is assumed. + sync_version - INTEGER default 1 -- cgit v1.1 From 040a0a37100563754bb1fee6ff6427420bcfa609 Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst Date: Mon, 24 Jun 2013 10:30:04 +0200 Subject: mutex: Add support for wound/wait style locks Wound/wait mutexes are used when other multiple lock acquisitions of a similar type can be done in an arbitrary order. The deadlock handling used here is called wait/wound in the RDBMS literature: 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. For full documentation please read Documentation/ww-mutex-design.txt. References: https://lwn.net/Articles/548909/ Signed-off-by: Maarten Lankhorst Acked-by: Daniel Vetter Acked-by: Rob Clark Acked-by: Peter Zijlstra Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Cc: rostedt@goodmis.org Cc: daniel@ffwll.ch Cc: Linus Torvalds Cc: Andrew Morton Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/51C8038C.9000106@canonical.com Signed-off-by: Ingo Molnar --- Documentation/ww-mutex-design.txt | 344 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 344 insertions(+) create mode 100644 Documentation/ww-mutex-design.txt (limited to 'Documentation') diff --git a/Documentation/ww-mutex-design.txt b/Documentation/ww-mutex-design.txt new file mode 100644 index 0000000..8a112dc --- /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. -- cgit v1.1 From 9803f868944e879c4623c0d910e81f1ae89ccfb4 Mon Sep 17 00:00:00 2001 From: Christian Ruppert Date: Wed, 26 Jun 2013 10:55:06 +0200 Subject: i2c-designware: make SDA hold time configurable This patch makes the SDA hold time configurable through device tree. Signed-off-by: Christian Ruppert Signed-off-by: Pierrick Hascoet Acked-by: Vineet Gupta for arch/arc bits Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/i2c-designware.txt | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt b/Documentation/devicetree/bindings/i2c/i2c-designware.txt index e42a2ee..7fd7fa2 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt @@ -10,6 +10,10 @@ Recommended properties : - clock-frequency : desired I2C bus clock frequency in Hz. +Optional properties : + - i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds. + This option is only supported in hardware blocks version 1.11a or newer. + Example : i2c@f0000 { @@ -20,3 +24,14 @@ Example : interrupts = <11>; clock-frequency = <400000>; }; + + i2c@1120000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "snps,designware-i2c"; + reg = <0x1120000 0x1000>; + interrupt-parent = <&ictl>; + interrupts = <12 1>; + clock-frequency = <400000>; + i2c-sda-hold-time-ns = <300>; + }; -- cgit v1.1 From 340cba6092c2c1688629d327b74e7eb746a571a7 Mon Sep 17 00:00:00 2001 From: Jingoo Han Date: Fri, 21 Jun 2013 16:24:54 +0900 Subject: pci: Add PCIe driver for Samsung Exynos Exynos5440 has a PCIe controller which can be used as Root Complex. This driver supports a PCIe controller as Root Complex mode. Signed-off-by: Surendranath Gurivireddy Balla Signed-off-by: Siva Reddy Kallam Signed-off-by: Jingoo Han Acked-by: Bjorn Helgaas Acked-by: Kukjin Kim Cc: Pratyush Anand Cc: Mohit KUMAR Signed-off-by: Arnd Bergmann --- .../devicetree/bindings/pci/designware-pcie.txt | 73 ++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/designware-pcie.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt new file mode 100644 index 0000000..e2371f5 --- /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>; + }; -- cgit v1.1 From d475f942b1dd6a897dac3ad4ed98d6994b275378 Mon Sep 17 00:00:00 2001 From: Michael Holzheu Date: Thu, 6 Jun 2013 09:52:08 +0200 Subject: s390/sclp: Add SCLP character device driver Add a character misc device "sclp_ctl" that allows to run SCCBs from user space using the SCLP_CTL_SCCB ioctl. Signed-off-by: Michael Holzheu Signed-off-by: Martin Schwidefsky --- Documentation/ioctl/ioctl-number.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 237acab..2a5f0e1 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -72,6 +72,7 @@ Code Seq#(hex) Include File Comments 0x06 all linux/lp.h 0x09 all linux/raid/md_u.h 0x10 00-0F drivers/char/s390/vmcp.h +0x10 10-1F arch/s390/include/uapi/sclp_ctl.h 0x12 all linux/fs.h linux/blkpg.h 0x1b all InfiniBand Subsystem -- cgit v1.1 From bd206b51bca1e0a1c5f4b00218d56213a1f6d3bd Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Mon, 20 May 2013 00:04:35 +0900 Subject: doc: Fix typo in documentation/bcache.txt Correct spelling typo in documentation/bcache.txt Signed-off-by: Masanari Iida Signed-off-by: Kent Overstreet --- Documentation/bcache.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bcache.txt b/Documentation/bcache.txt index b3a7e7d..c3365f2 100644 --- a/Documentation/bcache.txt +++ b/Documentation/bcache.txt @@ -181,7 +181,7 @@ want for getting the best possible numbers when benchmarking. In practice this isn't an issue because as soon as a write comes along it'll cause the btree node to be split, and you need almost no write traffic for - this to not show up enough to be noticable (especially since bcache's btree + this to not show up enough to be noticeable (especially since bcache's btree nodes are huge and index large regions of the device). But when you're benchmarking, if you're trying to warm the cache by reading a bunch of data and there's no other traffic - that can be a problem. @@ -222,7 +222,7 @@ running it's in passthrough mode or caching). sequential_cutoff - A sequential IO will bypass the cache once it passes this threshhold; the + A sequential IO will bypass the cache once it passes this threshold; the most recent 128 IOs are tracked so sequential IO can be detected even when it isn't all done at once. @@ -296,7 +296,7 @@ cache_miss_collisions since the synchronization for cache misses was rewritten) cache_readaheads - Count of times readahead occured. + Count of times readahead occurred. SYSFS - CACHE SET: @@ -362,7 +362,7 @@ unregister SYSFS - CACHE SET INTERNAL: This directory also exposes timings for a number of internal operations, with -separate files for average duration, average frequency, last occurence and max +separate files for average duration, average frequency, last occurrence and max duration: garbage collection, btree read, btree node sorts and btree splits. active_journal_entries @@ -417,7 +417,7 @@ freelist_percent space. io_errors - Number of errors that have occured, decayed by io_error_halflife. + Number of errors that have occurred, decayed by io_error_halflife. metadata_written Sum of all non data writes (btree writes and all other metadata). -- cgit v1.1 From cecd628d9a9966ed0af1237df5cc5818945fe9f2 Mon Sep 17 00:00:00 2001 From: Gabriel de Perthuis Date: Thu, 27 Jun 2013 02:12:07 +0200 Subject: bcache: Refresh usage docs Mention udev autoregistration, symlinks. Write down some sysfs paths. Signed-off-by: Gabriel de Perthuis Signed-off-by: Kent Overstreet --- Documentation/bcache.txt | 37 ++++++++++++++++++++++++------------- 1 file changed, 24 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/bcache.txt b/Documentation/bcache.txt index c3365f2..32b6c31 100644 --- a/Documentation/bcache.txt +++ b/Documentation/bcache.txt @@ -46,29 +46,33 @@ you format your backing devices and cache device at the same time, you won't have to manually attach: make-bcache -B /dev/sda /dev/sdb -C /dev/sdc -To make bcache devices known to the kernel, echo them to /sys/fs/bcache/register: +bcache-tools now ships udev rules, and bcache devices are known to the kernel +immediately. Without udev, you can manually register devices like this: echo /dev/sdb > /sys/fs/bcache/register echo /dev/sdc > /sys/fs/bcache/register -To register your bcache devices automatically, you could add something like -this to an init script: +Registering the backing device makes the bcache device show up in /dev; you can +now format it and use it as normal. But the first time using a new bcache +device, it'll be running in passthrough mode until you attach it to a cache. +See the section on attaching. - echo /dev/sd* > /sys/fs/bcache/register_quiet +The devices show up as: -It'll look for bcache superblocks and ignore everything that doesn't have one. + /dev/bcache -Registering the backing device makes the bcache show up in /dev; you can now -format it and use it as normal. But the first time using a new bcache device, -it'll be running in passthrough mode until you attach it to a cache. See the -section on attaching. +As well as (with udev): -The devices show up at /dev/bcacheN, and can be controlled via sysfs from -/sys/block/bcacheN/bcache: + /dev/bcache/by-uuid/ + /dev/bcache/by-label/ - - - Both functions get the device IRQ by calling - drm_dev_to_irq. This inline function will call a - bus-specific operation to retrieve the IRQ number. For platform devices, - platform_get_irq(..., 0) is used to retrieve the - IRQ number. - - - drm_irq_install starts by calling the - irq_preinstall driver operation. The operation - is optional and must make sure that the interrupt will not get fired by - clearing all pending interrupt flags or disabling the interrupt. - - - The IRQ will then be requested by a call to - request_irq. If the DRIVER_IRQ_SHARED driver - feature flag is set, a shared (IRQF_SHARED) IRQ handler will be - requested. - - - The IRQ handler function must be provided as the mandatory irq_handler - driver operation. It will get passed directly to - request_irq and thus has the same prototype as all - IRQ handlers. It will get called with a pointer to the DRM device as the - second argument. - - - Finally the function calls the optional - irq_postinstall driver operation. The operation - usually enables interrupts (excluding the vblank interrupt, which is - enabled separately), but drivers may choose to enable/disable interrupts - at a different time. - - - drm_irq_uninstall is similarly used to uninstall an - IRQ handler. It starts by waking up all processes waiting on a vblank - interrupt to make sure they don't hang, and then calls the optional - irq_uninstall driver operation. The operation - must disable all hardware interrupts. Finally the function frees the IRQ - by calling free_irq. + support a single interrupt per device, devices that use more than one + IRQs need to be handled manually. + + Managed IRQ Registration + + Both the drm_irq_install and + drm_irq_uninstall functions get the device IRQ by + calling drm_dev_to_irq. This inline function will + call a bus-specific operation to retrieve the IRQ number. For platform + devices, platform_get_irq(..., 0) is used to + retrieve the IRQ number. + + + drm_irq_install starts by calling the + irq_preinstall driver operation. The operation + is optional and must make sure that the interrupt will not get fired by + clearing all pending interrupt flags or disabling the interrupt. + + + The IRQ will then be requested by a call to + request_irq. If the DRIVER_IRQ_SHARED driver + feature flag is set, a shared (IRQF_SHARED) IRQ handler will be + requested. + + + The IRQ handler function must be provided as the mandatory irq_handler + driver operation. It will get passed directly to + request_irq and thus has the same prototype as all + IRQ handlers. It will get called with a pointer to the DRM device as the + second argument. + + + Finally the function calls the optional + irq_postinstall driver operation. The operation + usually enables interrupts (excluding the vblank interrupt, which is + enabled separately), but drivers may choose to enable/disable interrupts + at a different time. + + + drm_irq_uninstall is similarly used to uninstall an + IRQ handler. It starts by waking up all processes waiting on a vblank + interrupt to make sure they don't hang, and then calls the optional + irq_uninstall driver operation. The operation + must disable all hardware interrupts. Finally the function frees the IRQ + by calling free_irq. + + + + Manual IRQ Registration + + Drivers that require multiple interrupt handlers can't use the managed + IRQ registration functions. In that case IRQs must be registered and + unregistered manually (usually with the request_irq + and free_irq functions, or their devm_* equivalent). + + + When manually registering IRQs, drivers must not set the DRIVER_HAVE_IRQ + driver feature flag, and must not provide the + irq_handler driver operation. They must set the + drm_device irq_enabled + field to 1 upon registration of the IRQs, and clear it to 0 after + unregistering the IRQs. + + Memory Manager Initialization -- cgit v1.1 From 02c030a718e7fc6e066c6169c195f53b461df408 Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Sat, 22 Jun 2013 16:10:29 +0200 Subject: drm/doc: Remove outdated note about i915 driver not behaving properly The i915 driver has been fixed not to modify the mode argument of the encoder mode_fixup operation. Remove the related comment from the documentation. Signed-off-by: Laurent Pinchart Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie --- Documentation/DocBook/drm.tmpl | 4 ---- 1 file changed, 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index a608094..cea420d 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -1868,10 +1868,6 @@ void intel_crt_init(struct drm_device *dev) bool (*mode_fixup)(struct drm_encoder *encoder, const struct drm_display_mode *mode, struct drm_display_mode *adjusted_mode); - - FIXME: The mode argument be const, but the i915 driver modifies - mode->clock in intel_dp_mode_fixup. - Let encoders adjust the requested mode or reject it completely. This operation returns true if the mode is accepted (possibly after being -- cgit v1.1 From 421cda3e324fce40e3f7abdf3d31cae1d0deddcd Mon Sep 17 00:00:00 2001 From: Laurent Pinchart Date: Sat, 22 Jun 2013 16:10:30 +0200 Subject: drm/doc: Document the KMS property API Signed-off-by: Laurent Pinchart Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie --- Documentation/DocBook/drm.tmpl | 143 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 143 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index cea420d..4d54ac8 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -1236,6 +1236,15 @@ int max_width, max_height; Miscellaneous + void (*set_property)(struct drm_crtc *crtc, + struct drm_property *property, uint64_t value); + + Set the value of the given CRTC property to + value. See + for more information about properties. + + + void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b, uint32_t start, uint32_t size); @@ -1385,6 +1394,15 @@ int max_width, max_height; . + + void (*set_property)(struct drm_plane *plane, + struct drm_property *property, uint64_t value); + + Set the value of the given plane property to + value. See + for more information about properties. + + @@ -1594,6 +1612,15 @@ int max_width, max_height; Miscellaneous + void (*set_property)(struct drm_connector *connector, + struct drm_property *property, uint64_t value); + + Set the value of the given connector property to + value. See + for more information about properties. + + + void (*destroy)(struct drm_connector *connector); Destroy the connector when not needed anymore. See @@ -2187,6 +2214,122 @@ void intel_crt_init(struct drm_device *dev) + + + + KMS Properties + + Drivers may need to expose additional parameters to applications than + those described in the previous sections. KMS supports attaching + properties to CRTCs, connectors and planes and offers a userspace API to + list, get and set the property values. + + + Properties are identified by a name that uniquely defines the property + purpose, and store an associated value. For all property types except blob + properties the value is a 64-bit unsigned integer. + + + KMS differentiates between properties and property instances. Drivers + first create properties and then create and associate individual instances + of those properties to objects. A property can be instantiated multiple + times and associated with different objects. Values are stored in property + instances, and all other property information are stored in the propery + and shared between all instances of the property. + + + Every property is created with a type that influences how the KMS core + handles the property. Supported property types are + + + DRM_MODE_PROP_RANGE + Range properties report their minimum and maximum + admissible values. The KMS core verifies that values set by + application fit in that range. + + + DRM_MODE_PROP_ENUM + Enumerated properties take a numerical value that + ranges from 0 to the number of enumerated values defined by the + property minus one, and associate a free-formed string name to each + value. Applications can retrieve the list of defined value-name pairs + and use the numerical value to get and set property instance values. + + + + DRM_MODE_PROP_BITMASK + Bitmask properties are enumeration properties that + additionally restrict all enumerated values to the 0..63 range. + Bitmask property instance values combine one or more of the + enumerated bits defined by the property. + + + DRM_MODE_PROP_BLOB + Blob properties store a binary blob without any format + restriction. The binary blobs are created as KMS standalone objects, + and blob property instance values store the ID of their associated + blob object. + Blob properties are only used for the connector EDID property + and cannot be created by drivers. + + + + + To create a property drivers call one of the following functions depending + on the property type. All property creation functions take property flags + and name, as well as type-specific arguments. + + + struct drm_property *drm_property_create_range(struct drm_device *dev, int flags, + const char *name, + uint64_t min, uint64_t max); + Create a range property with the given minimum and maximum + values. + + + struct drm_property *drm_property_create_enum(struct drm_device *dev, int flags, + const char *name, + const struct drm_prop_enum_list *props, + int num_values); + Create an enumerated property. The props + argument points to an array of num_values + value-name pairs. + + + struct drm_property *drm_property_create_bitmask(struct drm_device *dev, + int flags, const char *name, + const struct drm_prop_enum_list *props, + int num_values); + Create a bitmask property. The props + argument points to an array of num_values + value-name pairs. + + + + + Properties can additionally be created as immutable, in which case they + will be read-only for applications but can be modified by the driver. To + create an immutable property drivers must set the DRM_MODE_PROP_IMMUTABLE + flag at property creation time. + + + When no array of value-name pairs is readily available at property + creation time for enumerated or range properties, drivers can create + the property using the drm_property_create function + and manually add enumeration value-name pairs by calling the + drm_property_add_enum function. Care must be taken to + properly specify the property type through the flags + argument. + + + After creating properties drivers can attach property instances to CRTC, + connector and plane objects by calling the + drm_object_attach_property. The function takes a + pointer to the target object, a pointer to the previously created property + and an initial instance value. + + + -- cgit v1.1 From ee89bd6bc73d1d14555418a2642172448052f1dd Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Sun, 9 Jun 2013 11:46:43 +0200 Subject: lib: Move fonts from drivers/video/console/ to lib/fonts/ Several drivers need font support independent of CONFIG_VT, cfr. commit 9cbce8d7e1dae0744ca4f68d62aa7de18196b6f4, "console/font: Refactor font support code selection logic"). Hence move the fonts and their support logic from drivers/video/console/ to its own library directory lib/fonts/. This also allows to limit processing of drivers/video/console/Makefile to CONFIG_VT=y again. [Kevin Hilman : Update arch/arm/boot/compressed/Makefile] Signed-off-by: Geert Uytterhoeven --- Documentation/DocBook/device-drivers.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index c36892c..fca3419 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -297,10 +297,10 @@ KAO --> Frame Buffer Fonts - Refer to the file drivers/video/console/fonts.c for more information. + Refer to the file lib/fonts/fonts.c for more information. -- cgit v1.1 From ccc414f83914178c7ab04ac4d4f0331fe4c37231 Mon Sep 17 00:00:00 2001 From: Thomas Gleixner Date: Fri, 28 Jun 2013 11:45:15 +0200 Subject: genirq: Add the generic chip to the genirq docbook Signed-off-by: Thomas Gleixner Cc: Randy Dunlap --- Documentation/DocBook/genericirq.tmpl | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl index b342234..d16d21b 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. + + + Generic interrupt chip + + 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. + +!Ekernel/irq/generic-chip.c + + Structures -- cgit v1.1 From cc57caf0cfe74e536910f587a369af4a8550a4ee Mon Sep 17 00:00:00 2001 From: Rahul Sharma Date: Wed, 19 Jun 2013 18:21:07 +0530 Subject: drm/exynos: add new compatible strings for hdmi subsystem This patch adds new combatible strings for hdmi, mixer, ddc and hdmiphy. It follows the convention of using compatible string which represent the SoC in which the IP was added for the first time. Drivers continue to support the previous compatible strings but further addition of these compatible strings in device tree is deprecated. Signed-off-by: Rahul Sharma Reviewed-by: Tomasz Figa Signed-off-by: Inki Dae --- Documentation/devicetree/bindings/video/exynos_hdmi.txt | 7 +++++-- Documentation/devicetree/bindings/video/exynos_hdmiddc.txt | 7 +++++-- Documentation/devicetree/bindings/video/exynos_hdmiphy.txt | 7 +++++-- Documentation/devicetree/bindings/video/exynos_mixer.txt | 8 ++++++-- 4 files changed, 21 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index 589edee..c71d0f0 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -1,7 +1,10 @@ Device-Tree bindings for drm hdmi driver Required properties: -- compatible: value should be "samsung,exynos5-hdmi". +- compatible: value should be one among the following: + 1) "samsung,exynos5-hdmi" + 2) "samsung,exynos4210-hdmi" + 3) "samsung,exynos4212-hdmi" - reg: physical base address of the hdmi and length of memory mapped region. - interrupts: interrupt number to the cpu. @@ -15,7 +18,7 @@ Required properties: Example: hdmi { - compatible = "samsung,exynos5-hdmi"; + compatible = "samsung,exynos4212-hdmi"; reg = <0x14530000 0x100000>; interrupts = <0 95 0>; hpd-gpio = <&gpx3 7 0xf 1 3>; diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt index fa166d9..41eee97 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt @@ -1,12 +1,15 @@ Device-Tree bindings for hdmiddc driver Required properties: -- compatible: value should be "samsung,exynos5-hdmiddc". +- compatible: value should be one of the following + 1) "samsung,exynos5-hdmiddc" + 2) "samsung,exynos4210-hdmiddc" + - reg: I2C address of the hdmiddc device. Example: hdmiddc { - compatible = "samsung,exynos5-hdmiddc"; + compatible = "samsung,exynos4210-hdmiddc"; reg = <0x50>; }; diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt index 858f4f9..162f641 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt @@ -1,12 +1,15 @@ Device-Tree bindings for hdmiphy driver Required properties: -- compatible: value should be "samsung,exynos5-hdmiphy". +- compatible: value should be one of the following: + 1) "samsung,exynos5-hdmiphy" + 2) "samsung,exynos4210-hdmiphy". + 3) "samsung,exynos4212-hdmiphy". - reg: I2C address of the hdmiphy device. Example: hdmiphy { - compatible = "samsung,exynos5-hdmiphy"; + compatible = "samsung,exynos4210-hdmiphy"; reg = <0x38>; }; diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt b/Documentation/devicetree/bindings/video/exynos_mixer.txt index 9b2ea03..9131b99 100644 --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt @@ -1,7 +1,11 @@ Device-Tree bindings for mixer driver Required properties: -- compatible: value should be "samsung,exynos5-mixer". +- compatible: value should be one of the following: + 1) "samsung,exynos5-mixer" + 2) "samsung,exynos4210-mixer" + 3) "samsung,exynos5250-mixer" + - reg: physical base address of the mixer and length of memory mapped region. - interrupts: interrupt number to the cpu. @@ -9,7 +13,7 @@ Required properties: Example: mixer { - compatible = "samsung,exynos5-mixer"; + compatible = "samsung,exynos5250-mixer"; reg = <0x14450000 0x10000>; interrupts = <0 94 0>; }; -- cgit v1.1 From def5e095719dbc808c856dd5c64749b867b3984a Mon Sep 17 00:00:00 2001 From: Rahul Sharma Date: Wed, 19 Jun 2013 18:21:08 +0530 Subject: drm/exynos: add support for exynos5420 mixer Add support for exynos5420 mixer IP in the drm mixer driver. Signed-off-by: Rahul Sharma Acked-by: Seung-Woo Kim Reviewed-by: Tomasz Figa Signed-off-by: Inki Dae --- Documentation/devicetree/bindings/video/exynos_mixer.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt b/Documentation/devicetree/bindings/video/exynos_mixer.txt index 9131b99..3334b0a 100644 --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt +++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt @@ -5,6 +5,7 @@ Required properties: 1) "samsung,exynos5-mixer" 2) "samsung,exynos4210-mixer" 3) "samsung,exynos5250-mixer" + 4) "samsung,exynos5420-mixer" - reg: physical base address of the mixer and length of memory mapped region. -- cgit v1.1 From c67f1a300a72a67c1fa71cada8380bbe8412d046 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Mon, 17 Jun 2013 02:50:33 -0300 Subject: [media] V4L2: add documentation for V4L2 clock helpers and asynchronous probing Add documentation for the V4L2 clock and V4L2 asynchronous probing APIs to v4l2-framework.txt. Signed-off-by: Guennadi Liakhovetski Reviewed-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 73 +++++++++++++++++++++++++++- 1 file changed, 71 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index b5e6347b..6c4866b 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -325,8 +325,27 @@ that width, height and the media bus pixel code are equal on both source and sink of the link. Subdev drivers are also free to use this function to perform the checks mentioned above in addition to their own checks. -A device (bridge) driver needs to register the v4l2_subdev with the -v4l2_device: +There are currently two ways to register subdevices with the V4L2 core. The +first (traditional) possibility is to have subdevices registered by bridge +drivers. This can be done when the bridge driver has the complete information +about subdevices connected to it and knows exactly when to register them. This +is typically the case for internal subdevices, like video data processing units +within SoCs or complex PCI(e) boards, camera sensors in USB cameras or connected +to SoCs, which pass information about them to bridge drivers, usually in their +platform data. + +There are however also situations where subdevices have to be registered +asynchronously to bridge devices. An example of such a configuration is a Device +Tree based system where information about subdevices is made available to the +system independently from the bridge devices, e.g. when subdevices are defined +in DT as I2C device nodes. The API used in this second case is described further +below. + +Using one or the other registration method only affects the probing process, the +run-time bridge-subdevice interaction is in both cases the same. + +In the synchronous case a device (bridge) driver needs to register the +v4l2_subdev with the v4l2_device: int err = v4l2_device_register_subdev(v4l2_dev, sd); @@ -393,6 +412,30 @@ controlled through GPIO pins. This distinction is only relevant when setting up the device, but once the subdev is registered it is completely transparent. +In the asynchronous case subdevice probing can be invoked independently of the +bridge driver availability. The subdevice driver then has to verify whether all +the requirements for a successful probing are satisfied. This can include a +check for a master clock availability. If any of the conditions aren't satisfied +the driver might decide to return -EPROBE_DEFER to request further reprobing +attempts. Once all conditions are met the subdevice shall be registered using +the v4l2_async_register_subdev() function. Unregistration is performed using +the v4l2_async_unregister_subdev() call. Subdevices registered this way are +stored in a global list of subdevices, ready to be picked up by bridge drivers. + +Bridge drivers in turn have to register a notifier object with an array of +subdevice descriptors that the bridge device needs for its operation. This is +performed using the v4l2_async_notifier_register() call. To unregister the +notifier the driver has to call v4l2_async_notifier_unregister(). The former of +the two functions takes two arguments: a pointer to struct v4l2_device and a +pointer to struct v4l2_async_notifier. The latter contains a pointer to an array +of pointers to subdevice descriptors of type struct v4l2_async_subdev type. The +V4L2 core will then use these descriptors to match asynchronously registered +subdevices to them. If a match is detected the .bound() notifier callback is +called. After all subdevices have been located the .complete() callback is +called. When a subdevice is removed from the system the .unbind() method is +called. All three callbacks are optional. + + V4L2 sub-device userspace API ----------------------------- @@ -1065,3 +1108,29 @@ available event type is 'class base + 1'. An example on how the V4L2 events may be used can be found in the OMAP 3 ISP driver (drivers/media/platform/omap3isp). + + +V4L2 clocks +----------- + +Many subdevices, like camera sensors, TV decoders and encoders, need a clock +signal to be supplied by the system. Often this clock is supplied by the +respective bridge device. The Linux kernel provides a Common Clock Framework for +this purpose. However, it is not (yet) available on all architectures. Besides, +the nature of the multi-functional (clock, data + synchronisation, I2C control) +connection of subdevices to the system might impose special requirements on the +clock API usage. E.g. V4L2 has to support clock provider driver unregistration +while a subdevice driver is holding a reference to the clock. For these reasons +a V4L2 clock helper API has been developed and is provided to bridge and +subdevice drivers. + +The API consists of two parts: two functions to register and unregister a V4L2 +clock source: v4l2_clk_register() and v4l2_clk_unregister() and calls to control +a clock object, similar to the respective generic clock API calls: +v4l2_clk_get(), v4l2_clk_put(), v4l2_clk_enable(), v4l2_clk_disable(), +v4l2_clk_get_rate(), and v4l2_clk_set_rate(). Clock suppliers have to provide +clock operations that will be called when clock users invoke respective API +methods. + +It is expected that once the CCF becomes available on all relevant +architectures this API will be removed. -- cgit v1.1 From 086eca2905d0d1ea6b5e22d62648c6b818c51846 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Fri, 14 Jun 2013 12:38:15 -0300 Subject: [media] exynos4-is: Add Exynos5250 SoC support to fimc-lite driver This patch adds support for the Exynos5250 SoC variant of the FIMC-LITE IP. A 'compatible' string is added for Exynos5250 compatible devices and the capture DMA handling is reworked to use the FLITE_REG_CIFCNTSEQ register, masking output DMA buffer address slots. The frame interrupt is enabled so there are now 2 interrupts per frame. This likely can be optimized in future by using any status registers that allow to figure out what the last and the currently written frame buffer is. It would also be more reliable in cases where there are high interrupt service latencies. Signed-off-by: Shaik Ameer Basha Signed-off-by: Arun Kumar K Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Documentation/devicetree/bindings/media/exynos-fimc-lite.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt index de9f6b7..0bf6fb7 100644 --- a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt +++ b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt @@ -2,8 +2,10 @@ Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE) Required properties: -- compatible : should be "samsung,exynos4212-fimc-lite" for Exynos4212 and - Exynos4412 SoCs; +- compatible : should be one of: + "samsung,exynos4212-fimc-lite" for Exynos4212/4412 SoCs, + "samsung,exynos5250-fimc-lite" for Exynos5250 compatible + devices; - reg : physical base address and size of the device memory mapped registers; - interrupts : should contain FIMC-LITE interrupt; -- cgit v1.1 From f7354e6c230ec62d221e51aa3f970fd3d5eb2067 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Fri, 31 May 2013 10:38:23 -0300 Subject: [media] exynos4-is: Add support for Exynos5250 MIPI-CSIS Add compatible property for the Exynos5250 and enable the frame start and frame end interrupts. These interrupts are needed for the Exynos5 FIMC-IS firmware. The driver enables those interrupt only where available, depending on the 'compatible' property. This can be optimized further, by exposing some API at the subdev driver, so the host driver can enable extra interrupts only for the image processing chains involving FIMC-IS. Signed-off-by: Shaik Ameer Basha Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Documentation/devicetree/bindings/media/samsung-mipi-csis.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt index 5f8e28e..be45f0b 100644 --- a/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt +++ b/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt @@ -5,8 +5,8 @@ Required properties: - compatible : "samsung,s5pv210-csis" for S5PV210 (S5PC110), "samsung,exynos4210-csis" for Exynos4210 (S5PC210), - "samsung,exynos4212-csis" for Exynos4212/Exynos4412 - SoC series; + "samsung,exynos4212-csis" for Exynos4212/Exynos4412, + "samsung,exynos5250-csis" for Exynos5250; - reg : offset and length of the register set for the device; - interrupts : should contain MIPI CSIS interrupt; the format of the interrupt specifier depends on the interrupt controller; -- cgit v1.1 From 188ab116dd9273bb8950481e7764d7eb4f21afb6 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Fri, 14 Jun 2013 19:28:40 -0300 Subject: [media] Documentation: Update driver's directory in video4linux/fimc.txt Update the documentation with the driver's path changed in commit 56fa1a6a6a7da91e7ece8b01b0ae8adb2926e434 [media] s5p-fimc: Change the driver directory to exynos4-is Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/fimc.txt | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt index 25f4d34..e51f1b5 100644 --- a/Documentation/video4linux/fimc.txt +++ b/Documentation/video4linux/fimc.txt @@ -1,6 +1,6 @@ Samsung S5P/EXYNOS4 FIMC driver -Copyright (C) 2012 Samsung Electronics Co., Ltd. +Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd. --------------------------------------------------------------------------- The FIMC (Fully Interactive Mobile Camera) device available in Samsung @@ -10,7 +10,7 @@ data from LCD controller (FIMD) through the SoC internal writeback data path. There are multiple FIMC instances in the SoCs (up to 4), having slightly different capabilities, like pixel alignment constraints, rotator availability, LCD writeback support, etc. The driver is located at -drivers/media/platform/s5p-fimc directory. +drivers/media/platform/exynos4-is directory. 1. Supported SoCs ================= @@ -36,21 +36,21 @@ Not currently supported: ===================== - media device driver - drivers/media/platform/s5p-fimc/fimc-mdevice.[ch] + drivers/media/platform/exynos4-is/media-dev.[ch] - camera capture video device driver - drivers/media/platform/s5p-fimc/fimc-capture.c + drivers/media/platform/exynos4-is/fimc-capture.c - MIPI-CSI2 receiver subdev - drivers/media/platform/s5p-fimc/mipi-csis.[ch] + drivers/media/platform/exynos4-is/mipi-csis.[ch] - video post-processor (mem-to-mem) - drivers/media/platform/s5p-fimc/fimc-core.c + drivers/media/platform/exynos4-is/fimc-core.c - common files - drivers/media/platform/s5p-fimc/fimc-core.h - drivers/media/platform/s5p-fimc/fimc-reg.h - drivers/media/platform/s5p-fimc/regs-fimc.h + drivers/media/platform/exynos4-is/fimc-core.h + drivers/media/platform/exynos4-is/fimc-reg.h + drivers/media/platform/exynos4-is/regs-fimc.h 4. User space interfaces ======================== @@ -143,7 +143,8 @@ or retrieve the information from /dev/media? with help of the media-ctl tool: 6. Platform support =================== -The machine code (plat-s5p and arch/arm/mach-*) must select following options +The machine code (arch/arm/plat-samsung and arch/arm/mach-*) must select +following options: CONFIG_S5P_DEV_FIMC0 mandatory CONFIG_S5P_DEV_FIMC1 \ -- cgit v1.1 From 5c0ba4e0762e6dabd14a5c276652e2defec38de7 Mon Sep 17 00:00:00 2001 From: Al Viro Date: Wed, 15 May 2013 13:52:59 -0400 Subject: [readdir] introduce iterate_dir() and dir_context iterate_dir(): new helper, replacing vfs_readdir(). struct dir_context: contains the readdir callback (and will get more stuff in it), embedded into whatever data that callback wants to deal with; eventually, we'll be passing it to ->readdir() replacement instead of (data,filldir) pair. Signed-off-by: Al Viro --- Documentation/filesystems/porting | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index 4db22f6..85a4a03 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -445,3 +445,6 @@ 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 -- cgit v1.1 From 2233f31aade393641f0eaed43a71110e629bb900 Mon Sep 17 00:00:00 2001 From: Al Viro Date: Wed, 22 May 2013 21:44:23 -0400 Subject: [readdir] ->readdir() is gone everything's converted to ->iterate() Signed-off-by: Al Viro --- Documentation/filesystems/Locking | 2 +- Documentation/filesystems/porting | 3 +++ Documentation/filesystems/vfs.txt | 4 ++-- 3 files changed, 6 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 0706d32..bdd82b2 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -414,7 +414,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/porting b/Documentation/filesystems/porting index 85a4a03..206a1bd 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -448,3 +448,6 @@ 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 bc4b06b..4a35f66 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -777,7 +777,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 +815,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 -- cgit v1.1 From da53be12bbb4fabbe2e9f6f908de0cf478b5161d Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Tue, 21 May 2013 15:22:44 -0700 Subject: Don't pass inode to ->d_hash() and ->d_compare() Instances either don't look at it at all (the majority of cases) or only want it to find the superblock (which can be had as dentry->d_sb). A few cases that want more are actually safe with dentry->d_inode - the only precaution needed is the check that it hadn't been replaced with NULL by rmdir() or by overwriting rename(), which case should be simply treated as cache miss. Signed-off-by: Linus Torvalds Signed-off-by: Al Viro --- Documentation/filesystems/Locking | 6 ++---- Documentation/filesystems/vfs.txt | 19 ++++++++----------- 2 files changed, 10 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index bdd82b2..f94a362 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 *); diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 4a35f66..51ba44e 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -901,10 +901,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 +947,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. -- cgit v1.1 From 1c8c601a8c0dc59fe64907dcd9d512a3d181ddc7 Mon Sep 17 00:00:00 2001 From: Jeff Layton Date: Fri, 21 Jun 2013 08:58:15 -0400 Subject: locks: protect most of the file_lock handling with i_lock Having a global lock that protects all of this code is a clear scalability problem. Instead of doing that, move most of the code to be protected by the i_lock instead. The exceptions are the global lists that the ->fl_link sits on, and the ->fl_block list. ->fl_link is what connects these structures to the global lists, so we must ensure that we hold those locks when iterating over or updating these lists. Furthermore, sound deadlock detection requires that we hold the blocked_list state steady while checking for loops. We also must ensure that the search and update to the list are atomic. For the checking and insertion side of the blocked_list, push the acquisition of the global lock into __posix_lock_file and ensure that checking and update of the blocked_list is done without dropping the lock in between. On the removal side, when waking up blocked lock waiters, take the global lock before walking the blocked list and dequeue the waiters from the global list prior to removal from the fl_block list. With this, deadlock detection should be race free while we minimize excessive file_lock_lock thrashing. Finally, in order to avoid a lock inversion problem when handling /proc/locks output we must ensure that manipulations of the fl_block list are also protected by the file_lock_lock. Signed-off-by: Jeff Layton Signed-off-by: Al Viro --- Documentation/filesystems/Locking | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index f94a362..c2963a7 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -342,7 +342,7 @@ prototypes: locking rules: - file_lock_lock may block + inode->i_lock may block fl_copy_lock: yes no fl_release_private: maybe no @@ -355,12 +355,19 @@ prototypes: 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 file_lock_lock may block +lm_compare_owner: yes[1] maybe 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 is generally called with *an* inode->i_lock held. It +may not be the i_lock of the inode for either file_lock being compared! 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. When doing a search for deadlocks, the file_lock_lock is also held. --------------------------- buffer_head ----------------------------------- prototypes: -- cgit v1.1 From 3999e49364193f7dbbba66e2be655fe91ba1fced Mon Sep 17 00:00:00 2001 From: Jeff Layton Date: Fri, 21 Jun 2013 08:58:19 -0400 Subject: locks: add a new "lm_owner_key" lock operation Currently, the hashing that the locking code uses to add these values to the blocked_hash is simply calculated using fl_owner field. That's valid in most cases except for server-side lockd, which validates the owner of a lock based on fl_owner and fl_pid. In the case where you have a small number of NFS clients doing a lot of locking between different processes, you could end up with all the blocked requests sitting in a very small number of hash buckets. Add a new lm_owner_key operation to the lock_manager_operations that will generate an unsigned long to use as the key in the hashtable. That function is only implemented for server-side lockd, and simply XORs the fl_owner and fl_pid. Signed-off-by: Jeff Layton Acked-by: J. Bruce Fields Signed-off-by: Al Viro --- Documentation/filesystems/Locking | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index c2963a7..2db7c9e 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -349,6 +349,7 @@ 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 */ @@ -358,16 +359,21 @@ locking rules: inode->i_lock file_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 is generally called with *an* inode->i_lock held. It -may not be the i_lock of the inode for either file_lock being compared! 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. When doing a search for deadlocks, the file_lock_lock is also held. +[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 file_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: -- cgit v1.1 From 7b2296afb392bc21a50f42e7c7f4b19d3fea8c6d Mon Sep 17 00:00:00 2001 From: Jeff Layton Date: Fri, 21 Jun 2013 08:58:20 -0400 Subject: locks: give the blocked_hash its own spinlock There's no reason we have to protect the blocked_hash and file_lock_list with the same spinlock. With the tests I have, breaking it in two gives a barely measurable performance benefit, but it seems reasonable to make this locking as granular as possible. Signed-off-by: Jeff Layton Signed-off-by: Al Viro --- Documentation/filesystems/Locking | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 2db7c9e..7d9ca7a 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -357,20 +357,20 @@ prototypes: locking rules: - inode->i_lock file_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 + 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 file_lock_lock is also held. The +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. -- cgit v1.1 From ee999fb3f17faa3af6028bf7130707fe0d4157a4 Mon Sep 17 00:00:00 2001 From: Tomasz Figa Date: Tue, 25 Jun 2013 16:08:10 +0200 Subject: mfd: max8998: Add support for Device Tree This patch adds Device Tree support to max8998 driver. Signed-off-by: Tomasz Figa Acked-by: Mark Brown Signed-off-by: Samuel Ortiz --- Documentation/devicetree/bindings/mfd/max8998.txt | 119 ++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/max8998.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/max8998.txt b/Documentation/devicetree/bindings/mfd/max8998.txt new file mode 100644 index 0000000..23a3650 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/max8998.txt @@ -0,0 +1,119 @@ +* Maxim MAX8998, National/TI LP3974 multi-function device + +The Maxim MAX8998 is a multi-function device which includes voltage/current +regulators, real time clock, battery charging controller and several +other sub-blocks. It is interfaced using an I2C interface. Each sub-block +is addressed by the host system using different i2c slave address. + +PMIC sub-block +-------------- + +The PMIC sub-block contains a number of voltage and current regulators, +with controllable parameters and dynamic voltage scaling capability. +In addition, it includes a real time clock and battery charging controller +as well. It is accessible at I2C address 0x66. + +Required properties: +- compatible: Should be one of the following: + - "maxim,max8998" for Maxim MAX8998 + - "national,lp3974" or "ti,lp3974" for National/TI LP3974. +- reg: Specifies the i2c slave address of the pmic block. It should be 0x66. + +Optional properties: +- interrupt-parent: Specifies the phandle of the interrupt controller to which + the interrupts from MAX8998 are routed to. +- interrupts: Interrupt specifiers for two interrupt sources. + - First interrupt specifier is for main interrupt. + - Second interrupt specifier is for power-on/-off interrupt. +- max8998,pmic-buck1-dvs-gpios: GPIO specifiers for two host gpios used + for buck 1 dvs. The format of the gpio specifier depends on the gpio + controller. +- max8998,pmic-buck2-dvs-gpio: GPIO specifier for host gpio used + for buck 2 dvs. The format of the gpio specifier depends on the gpio + controller. +- max8998,pmic-buck1-default-dvs-idx: Default voltage setting selected from + the possible 4 options selectable by the dvs gpios. The value of this + property should be 0, 1, 2 or 3. If not specified or out of range, + a default value of 0 is taken. +- max8998,pmic-buck2-default-dvs-idx: Default voltage setting selected from + the possible 2 options selectable by the dvs gpios. The value of this + property should be 0 or 1. If not specified or out of range, a default + value of 0 is taken. +- max8998,pmic-buck-voltage-lock: If present, disallows changing of + preprogrammed buck dvfs voltages. + +Additional properties required if max8998,pmic-buck1-dvs-gpios is defined: +- max8998,pmic-buck1-dvs-voltage: An array of 4 voltage values in microvolts + for buck1 regulator that can be selected using dvs gpio. + +Additional properties required if max8998,pmic-buck2-dvs-gpio is defined: +- max8998,pmic-buck2-dvs-voltage: An array of 2 voltage values in microvolts + for buck2 regulator that can be selected using dvs gpio. + +Regulators: All the regulators of MAX8998 to be instantiated shall be +listed in a child node named 'regulators'. Each regulator is represented +by a child node of the 'regulators' node. + + regulator-name { + /* standard regulator bindings here */ + }; + +Following regulators of the MAX8998 PMIC block are supported. Note that +the 'n' in regulator name, as in LDOn or BUCKn, represents the LDO or BUCK +number as described in MAX8998 datasheet. + + - LDOn + - valid values for n are 2 to 17 + - Example: LDO2, LDO10, LDO17 + - BUCKn + - valid values for n are 1 to 4. + - Example: BUCK1, BUCK2, BUCK3, BUCK4 + + - ENVICHG: Battery Charging Current Monitor Output. This is a fixed + voltage type regulator + + - ESAFEOUT1: (ldo19) + - ESAFEOUT2: (ld020) + +Standard regulator bindings are used inside regulator subnodes. Check + Documentation/devicetree/bindings/regulator/regulator.txt +for more details. + +Example: + + pmic@66 { + compatible = "maxim,max8998-pmic"; + reg = <0x66>; + interrupt-parent = <&wakeup_eint>; + interrupts = <4 0>, <3 0>; + + /* Buck 1 DVS settings */ + max8998,pmic-buck1-default-dvs-idx = <0>; + max8998,pmic-buck1-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */ + <&gpx0 1 1 0 0>; /* SET2 */ + max8998,pmic-buck1-dvs-voltage = <1350000>, <1300000>, + <1000000>, <950000>; + + /* Buck 2 DVS settings */ + max8998,pmic-buck2-default-dvs-idx = <0>; + max8998,pmic-buck2-dvs-gpio = <&gpx0 0 3 0 0>; /* SET3 */ + max8998,pmic-buck2-dvs-voltage = <1350000>, <1300000>; + + /* Regulators to instantiate */ + regulators { + ldo2_reg: LDO2 { + regulator-name = "VDD_ALIVE_1.1V"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + }; + + buck1_reg: BUCK1 { + regulator-name = "VDD_ARM_1.2V"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + }; + }; + }; -- cgit v1.1 From 330a1eb7775ba876dbd46b9885556e57f705e3d4 Mon Sep 17 00:00:00 2001 From: Michael Ellerman Date: Fri, 28 Jun 2013 18:15:16 +1000 Subject: powerpc/perf: Core EBB support for 64-bit book3s Add support for EBB (Event Based Branches) on 64-bit book3s. See the included documentation for more details. EBBs are a feature which allows the hardware to branch directly to a specified user space address when a PMU event overflows. This can be used by programs for self-monitoring with no kernel involvement in the inner loop. Most of the logic is in the generic book3s code, primarily to avoid a proliferation of PMU callbacks. Signed-off-by: Michael Ellerman Signed-off-by: Benjamin Herrenschmidt --- Documentation/powerpc/00-INDEX | 2 + Documentation/powerpc/pmu-ebb.txt | 137 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 139 insertions(+) create mode 100644 Documentation/powerpc/pmu-ebb.txt (limited to 'Documentation') diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index dd9e9280..05026ce 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX @@ -14,6 +14,8 @@ hvcs.txt - IBM "Hypervisor Virtual Console Server" Installation Guide mpc52xx.txt - Linux 2.6.x on MPC52xx family +pmu-ebb.txt + - Description of the API for using the PMU with Event Based Branches. qe_firmware.txt - describes the layout of firmware binaries for the Freescale QUICC Engine and the code that parses and uploads the microcode therein. diff --git a/Documentation/powerpc/pmu-ebb.txt b/Documentation/powerpc/pmu-ebb.txt new file mode 100644 index 0000000..73cd163 --- /dev/null +++ b/Documentation/powerpc/pmu-ebb.txt @@ -0,0 +1,137 @@ +PMU Event Based Branches +======================== + +Event Based Branches (EBBs) are a feature which allows the hardware to +branch directly to a specified user space address when certain events occur. + +The full specification is available in Power ISA v2.07: + + https://www.power.org/documentation/power-isa-version-2-07/ + +One type of event for which EBBs can be configured is PMU exceptions. This +document describes the API for configuring the Power PMU to generate EBBs, +using the Linux perf_events API. + + +Terminology +----------- + +Throughout this document we will refer to an "EBB event" or "EBB events". This +just refers to a struct perf_event which has set the "EBB" flag in its +attr.config. All events which can be configured on the hardware PMU are +possible "EBB events". + + +Background +---------- + +When a PMU EBB occurs it is delivered to the currently running process. As such +EBBs can only sensibly be used by programs for self-monitoring. + +It is a feature of the perf_events API that events can be created on other +processes, subject to standard permission checks. This is also true of EBB +events, however unless the target process enables EBBs (via mtspr(BESCR)) no +EBBs will ever be delivered. + +This makes it possible for a process to enable EBBs for itself, but not +actually configure any events. At a later time another process can come along +and attach an EBB event to the process, which will then cause EBBs to be +delivered to the first process. It's not clear if this is actually useful. + + +When the PMU is configured for EBBs, all PMU interrupts are delivered to the +user process. This means once an EBB event is scheduled on the PMU, no non-EBB +events can be configured. This means that EBB events can not be run +concurrently with regular 'perf' commands, or any other perf events. + +It is however safe to run 'perf' commands on a process which is using EBBs. The +kernel will in general schedule the EBB event, and perf will be notified that +its events could not run. + +The exclusion between EBB events and regular events is implemented using the +existing "pinned" and "exclusive" attributes of perf_events. This means EBB +events will be given priority over other events, unless they are also pinned. +If an EBB event and a regular event are both pinned, then whichever is enabled +first will be scheduled and the other will be put in error state. See the +section below titled "Enabling an EBB event" for more information. + + +Creating an EBB event +--------------------- + +To request that an event is counted using EBB, the event code should have bit +63 set. + +EBB events must be created with a particular, and restrictive, set of +attributes - this is so that they interoperate correctly with the rest of the +perf_events subsystem. + +An EBB event must be created with the "pinned" and "exclusive" attributes set. +Note that if you are creating a group of EBB events, only the leader can have +these attributes set. + +An EBB event must NOT set any of the "inherit", "sample_period", "freq" or +"enable_on_exec" attributes. + +An EBB event must be attached to a task. This is specified to perf_event_open() +by passing a pid value, typically 0 indicating the current task. + +All events in a group must agree on whether they want EBB. That is all events +must request EBB, or none may request EBB. + +EBB events must specify the PMC they are to be counted on. This ensures +userspace is able to reliably determine which PMC the event is scheduled on. + + +Enabling an EBB event +--------------------- + +Once an EBB event has been successfully opened, it must be enabled with the +perf_events API. This can be achieved either via the ioctl() interface, or the +prctl() interface. + +However, due to the design of the perf_events API, enabling an event does not +guarantee that it has been scheduled on the PMU. To ensure that the EBB event +has been scheduled on the PMU, you must perform a read() on the event. If the +read() returns EOF, then the event has not been scheduled and EBBs are not +enabled. + +This behaviour occurs because the EBB event is pinned and exclusive. When the +EBB event is enabled it will force all other non-pinned events off the PMU. In +this case the enable will be successful. However if there is already an event +pinned on the PMU then the enable will not be successful. + + +Reading an EBB event +-------------------- + +It is possible to read() from an EBB event. However the results are +meaningless. Because interrupts are being delivered to the user process the +kernel is not able to count the event, and so will return a junk value. + + +Closing an EBB event +-------------------- + +When an EBB event is finished with, you can close it using close() as for any +regular event. If this is the last EBB event the PMU will be deconfigured and +no further PMU EBBs will be delivered. + + +EBB Handler +----------- + +The EBB handler is just regular userspace code, however it must be written in +the style of an interrupt handler. When the handler is entered all registers +are live (possibly) and so must be saved somehow before the handler can invoke +other code. + +It's up to the program how to handle this. For C programs a relatively simple +option is to create an interrupt frame on the stack and save registers there. + +Fork +---- + +EBB events are not inherited across fork. If the child process wishes to use +EBBs it should open a new event for itself. Similarly the EBB state in +BESCR/EBBHR/EBBRR is cleared across fork(). -- cgit v1.1 From b56ece9a3ac3c9708b8f1cebf4ba24c258d40e52 Mon Sep 17 00:00:00 2001 From: Daniel Drake Date: Sun, 30 Jun 2013 18:37:24 -0700 Subject: Input: add OLPC AP-SP driver The OLPC XO-1.75 and XO-4 laptops include a PS/2 touchpad and an AT keyboard, yet they do not have a hardware PS/2 controller. Instead, a firmware runs on a dedicated core ("Security Processor", part of the SoC) that acts as a PS/2 controller through bit-banging. Communication between the main cpu (Application Processor) and the Security Processor happens via a standard command mechanism implemented by the SoC. Add a driver for this interface to enable keyboard/mouse input on this platform. Original author: Saadia Baloch Signed-off-by: Daniel Drake Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/serio/olpc,ap-sp.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 Documentation/devicetree/bindings/serio/olpc,ap-sp.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt new file mode 100644 index 0000000..0e72183 --- /dev/null +++ b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt @@ -0,0 +1,13 @@ +OLPC AP-SP serio interface + +Required properties: +- compatible : "olpc,ap-sp" +- reg : base address and length of SoC's WTM registers +- interrupts : SP-AP interrupt + +Example: + ap-sp@d4290000 { + compatible = "olpc,ap-sp"; + reg = <0xd4290000 0x1000>; + interrupts = <40>; + } -- cgit v1.1 From 4b5e5f41c8e114bb856347134657eb9e1cccc822 Mon Sep 17 00:00:00 2001 From: Bart Van Assche Date: Fri, 28 Jun 2013 14:57:42 +0200 Subject: IB/srp: Make HCA completion vector configurable Several InfiniBand HCAs allow configuring the completion vector per CQ. This allows spreading the workload created by IB completion interrupts over multiple MSI-X vectors and hence over multiple CPU cores. In other words, configuring the completion vector properly not only allows reducing latency on an initiator connected to multiple SRP targets but also allows improving throughput. Signed-off-by: Bart Van Assche Acked-by: David Dillow Signed-off-by: Roland Dreier --- Documentation/ABI/stable/sysfs-driver-ib_srp | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-driver-ib_srp b/Documentation/ABI/stable/sysfs-driver-ib_srp index 481aae9..5c53d28 100644 --- a/Documentation/ABI/stable/sysfs-driver-ib_srp +++ b/Documentation/ABI/stable/sysfs-driver-ib_srp @@ -54,6 +54,13 @@ Description: Interface for making ib_srp connect to a new target. ib_srp. Specifying a value that exceeds cmd_sg_entries is only safe with partial memory descriptor list support enabled (allow_ext_sg=1). + * comp_vector, a number in the range 0..n-1 specifying the + MSI-X completion vector. Some HCA's allocate multiple (n) + MSI-X vectors per HCA port. If the IRQ affinity masks of + these interrupts have been configured such that each MSI-X + interrupt is handled by a different CPU then the comp_vector + parameter can be used to spread the SRP completion workload + over multiple CPU's. What: /sys/class/infiniband_srp/srp--/ibdev Date: January 2, 2006 -- cgit v1.1 From 86f120031a21fe4e7333a84f55d9e243c781e6e9 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Tue, 2 Jul 2013 15:35:11 +0930 Subject: ABI: Clarify when /sys/module/MODULENAME is created /sys/module/MODULENAME is not created unconditionally. This can be confusing so document the current conditions. Signed-off-by: Jean Delvare Cc: Rusty Russell Cc: Rob Landley Signed-off-by: Rusty Russell --- Documentation/ABI/stable/sysfs-module | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-module b/Documentation/ABI/stable/sysfs-module index a0dd21c..6272ae5 100644 --- a/Documentation/ABI/stable/sysfs-module +++ b/Documentation/ABI/stable/sysfs-module @@ -4,9 +4,13 @@ Description: /sys/module/MODULENAME The name of the module that is in the kernel. This - module name will show up either if the module is built - directly into the kernel, or if it is loaded as a - dynamic module. + module name will always show up if the module is loaded as a + dynamic module. If it is built directly into the kernel, it + will only show up if it has a version or at least one + parameter. + + Note: The conditions of creation in the built-in case are not + by design and may be removed in the future. /sys/module/MODULENAME/parameters This directory contains individual files that are each -- cgit v1.1 From 1067964305df131ede2c08c2f3c9b3892640f1c6 Mon Sep 17 00:00:00 2001 From: Daniel Borkmann Date: Fri, 28 Jun 2013 19:49:39 +0200 Subject: lib: vsprintf: add IPv4/v6 generic %p[Ii]S[pfs] format specifier In order to avoid making code that deals with printing both, IPv4 and IPv6 addresses, unnecessary complicated as for example ... if (sa.sa_family == AF_INET6) printk("... %pI6 ...", ..sin6_addr); else printk("... %pI4 ...", ..sin_addr.s_addr); ... it would be better to introduce a format specifier that can deal with those kind of situations internally; just as we have a "struct sockaddr" for generic mapping into "struct sockaddr_in" or "struct sockaddr_in6" as e.g. done in "union sctp_addr". Then, we could reduce the above statement into something like: printk("... %pIS ..", &sockaddr); In case our pointer is NULL, pointer() then deals with that already at an earlier point in time internally. While we're at it, support for both %piS/%pIS, where 'S' stands for sockaddr, comes (almost) for free. Additionally to that, postfix specifiers 'p', 'f' and 's' are supported as suggested and initially implemented in 2009 by Joe Perches [1]. Handling of those additional specifiers orientate on the initial RFC that was proposed. Also we support IPv6 compressed format specified by 'c' and various other IPv4 extensions as stated in the documentation part. Likely, there are many other areas than just SCTP in the kernel to make use of this extension as well. [1] http://patchwork.ozlabs.org/patch/31480/ Signed-off-by: Daniel Borkmann CC: Joe Perches CC: linux-kernel@vger.kernel.org Signed-off-by: David S. Miller --- Documentation/printk-formats.txt | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'Documentation') diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 3af5ae6..3e8cb73 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt @@ -121,6 +121,38 @@ IPv6 addresses: print a compressed IPv6 address as described by http://tools.ietf.org/html/rfc5952 +IPv4/IPv6 addresses (generic, with port, flowinfo, scope): + + %pIS 1.2.3.4 or 0001:0002:0003:0004:0005:0006:0007:0008 + %piS 001.002.003.004 or 00010002000300040005000600070008 + %pISc 1.2.3.4 or 1:2:3:4:5:6:7:8 + %pISpc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345 + %p[Ii]S[pfschnbl] + + For printing an IP address without the need to distinguish whether it's + of type AF_INET or AF_INET6, a pointer to a valid 'struct sockaddr', + specified through 'IS' or 'iS', can be passed to this format specifier. + + The additional 'p', 'f', and 's' specifiers are used to specify port + (IPv4, IPv6), flowinfo (IPv6) and scope (IPv6). Ports have a ':' prefix, + flowinfo a '/' and scope a '%', each followed by the actual value. + + In case of an IPv6 address the compressed IPv6 address as described by + http://tools.ietf.org/html/rfc5952 is being used if the additional + specifier 'c' is given. The IPv6 address is surrounded by '[', ']' in + case of additional specifiers 'p', 'f' or 's' as suggested by + https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07 + + In case of IPv4 addresses, the additional 'h', 'n', 'b', and 'l' + specifiers can be used as well and are ignored in case of an IPv6 + address. + + Further examples: + + %pISfc 1.2.3.4 or [1:2:3:4:5:6:7:8]/123456789 + %pISsc 1.2.3.4 or [1:2:3:4:5:6:7:8]%1234567890 + %pISpfc 1.2.3.4:12345 or [1:2:3:4:5:6:7:8]:12345/123456789 + UUID/GUID addresses: %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f -- cgit v1.1 From 0c1dcfd53b1066c411d3885cf8156abf59694360 Mon Sep 17 00:00:00 2001 From: Sebastian Hesselbarth Date: Tue, 11 Jun 2013 08:38:50 +0200 Subject: clocksource: Add Marvell Orion SoC timer This patch add a DT enabled driver for timers found on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, and Discovery Innovation). It installs a free- running clocksource on timer0 and a clockevent source on timer1. Corresponding device tree documentation is also added. Signed-off-by: Sebastian Hesselbarth Signed-off-by: Daniel Lezcano Tested-by: Ezequiel Garcia Tested-by: Andrew Lunn --- .../devicetree/bindings/timer/marvell,orion-timer.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Documentation/devicetree/bindings/timer/marvell,orion-timer.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt b/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt new file mode 100644 index 0000000..62bb826 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt @@ -0,0 +1,17 @@ +Marvell Orion SoC timer + +Required properties: +- compatible: shall be "marvell,orion-timer" +- reg: base address of the timer register starting with TIMERS CONTROL register +- interrupt-parent: phandle of the bridge interrupt controller +- interrupts: should contain the interrupts for Timer0 and Timer1 +- clocks: phandle of timer reference clock (tclk) + +Example: + timer: timer { + compatible = "marvell,orion-timer"; + reg = <0x20300 0x20>; + interrupt-parent = <&bridge_intc>; + interrupts = <1>, <2>; + clocks = <&core_clk 0>; + }; -- cgit v1.1 From 0baac4db56b1895743391a348ee9ce4ae5076f9f Mon Sep 17 00:00:00 2001 From: CoolCold Date: Wed, 26 Jun 2013 19:46:58 +0400 Subject: md: remove doubled description for sync_max, merging it within sync_min/sync_max After last md.txt edits for sync_min/max, sync_max description became doubled. Removing 1st copy, merging details into common sync_min/sync_max section. Signed-off-by: Roman Ovchinnikov Signed-off-by: NeilBrown --- Documentation/md.txt | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/md.txt b/Documentation/md.txt index e0ddd32..fbb2fcb 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -566,13 +566,6 @@ also have when it reaches the current sync_max (below) and possibly at other times. - sync_max - This is a number of sectors at which point a resync/recovery - process will pause. When a resync is active, the value can - only ever be increased, never decreased. The value of 'max' - effectively disables the limit. - - sync_speed This shows the current actual speed, in K/sec, of the current sync_action. It is averaged over the last 30 seconds. @@ -593,6 +586,12 @@ also have that number to reach sync_max. Then you can either increase "sync_max", or can write 'idle' to "sync_action". + The value of 'max' for "sync_max" effectively disables the limit. + When a resync is active, the value can only ever be increased, + never decreased. + The value of '0' is the minimum for "sync_min". + + Each active md device may also have attributes specific to the personality module that manages it. -- cgit v1.1 From a608026eacaee59cf0f1fa5caad60320f5b4a373 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Thu, 27 Jun 2013 23:42:17 -0700 Subject: Input: ads7846 - add device tree bindings Signed-off-by: Daniel Mack Signed-off-by: Dmitry Torokhov --- .../devicetree/bindings/input/ads7846.txt | 91 ++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/ads7846.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/ads7846.txt new file mode 100644 index 0000000..5f7619c --- /dev/null +++ b/Documentation/devicetree/bindings/input/ads7846.txt @@ -0,0 +1,91 @@ +Device tree bindings for TI's ADS7843, ADS7845, ADS7846, ADS7873, TSC2046 +SPI driven touch screen controllers. + +The node for this driver must be a child node of a SPI controller, hence +all mandatory properties described in + + Documentation/devicetree/bindings/spi/spi-bus.txt + +must be specified. + +Additional required properties: + + compatible Must be one of the following, depending on the + model: + "ti,tsc2046" + "ti,ads7843" + "ti,ads7845" + "ti,ads7846" + "ti,ads7873" + + interrupt-parent + interrupts An interrupt node describing the IRQ line the chip's + !PENIRQ pin is connected to. + vcc-supply A regulator node for the supply voltage. + + +Optional properties: + + ti,vref-delay-usecs vref supply delay in usecs, 0 for + external vref (u16). + ti,vref-mv The VREF voltage, in millivolts (u16). + ti,keep-vref-on set to keep vref on for differential + measurements as well + ti,swap-xy swap x and y axis + ti,settle-delay-usec Settling time of the analog signals; + a function of Vcc and the capacitance + on the X/Y drivers. If set to non-zero, + two samples are taken with settle_delay + us apart, and the second one is used. + ~150 uSec with 0.01uF caps (u16). + ti,penirq-recheck-delay-usecs If set to non-zero, after samples are + taken this delay is applied and penirq + is rechecked, to help avoid false + events. This value is affected by the + material used to build the touch layer + (u16). + ti,x-plate-ohms Resistance of the X-plate, + in Ohms (u16). + ti,y-plate-ohms Resistance of the Y-plate, + in Ohms (u16). + ti,x-min Minimum value on the X axis (u16). + ti,y-min Minimum value on the Y axis (u16). + ti,x-max Maximum value on the X axis (u16). + ti,y-max Minimum value on the Y axis (u16). + ti,pressure-min Minimum reported pressure value + (threshold) - u16. + ti,pressure-max Maximum reported pressure value (u16). + ti,debounce-max Max number of additional readings per + sample (u16). + ti,debounce-tol Tolerance used for filtering (u16). + ti,debounce-rep Additional consecutive good readings + required after the first two (u16). + ti,pendown-gpio-debounce Platform specific debounce time for the + pendown-gpio (u32). + pendown-gpio GPIO handle describing the pin the !PENIRQ + line is connected to. + linux,wakeup use any event on touchscreen as wakeup event. + + +Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC:: + + spi_controller { + tsc2046@0 { + reg = <0>; /* CS0 */ + compatible = "ti,tsc2046"; + interrupt-parent = <&gpio1>; + interrupts = <8 0>; /* BOOT6 / GPIO 8 */ + spi-max-frequency = <1000000>; + pendown-gpio = <&gpio1 8 0>; + vcc-supply = <®_vcc3>; + + ti,x-min = /bits/ 16 <0>; + ti,x-max = /bits/ 16 <8000>; + ti,y-min = /bits/ 16 <0>; + ti,y-max = /bits/ 16 <4800>; + ti,x-plate-ohms = /bits/ 16 <40>; + ti,pressure-max = /bits/ 16 <255>; + + linux,wakeup; + }; + }; -- cgit v1.1 From 39e24a16283c6780a9049db75a91bcf6b5943b9a Mon Sep 17 00:00:00 2001 From: Sachin Kamat Date: Mon, 24 Jun 2013 15:06:57 +0530 Subject: regulator: s5m8767: Update s5m8767-regulator bindings document s5m8767 regulator is used on Exynos platforms which use pin controller to configure GPIOs. Update the example accordingly. [This had previously been broken by code changes which failed to update the documentation -- broonie] Signed-off-by: Sachin Kamat Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/s5m8767-regulator.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt index a35ff99..7364f711 100644 --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt @@ -103,13 +103,13 @@ Example: s5m8767,pmic-buck-default-dvs-idx = <0>; - s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 1 0 0>, /* DVS1 */ - <&gpx0 1 1 0 0>, /* DVS2 */ - <&gpx0 2 1 0 0>; /* DVS3 */ + s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 0>, /* DVS1 */ + <&gpx0 1 0>, /* DVS2 */ + <&gpx0 2 0>; /* DVS3 */ - s5m8767,pmic-buck-ds-gpios = <&gpx2 3 1 0 0>, /* SET1 */ - <&gpx2 4 1 0 0>, /* SET2 */ - <&gpx2 5 1 0 0>; /* SET3 */ + s5m8767,pmic-buck-ds-gpios = <&gpx2 3 0>, /* SET1 */ + <&gpx2 4 0>, /* SET2 */ + <&gpx2 5 0>; /* SET3 */ s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>, <1250000>, <1200000>, -- cgit v1.1 From 48bde8d3620f5f3c6ae9ff599eb404055ae51664 Mon Sep 17 00:00:00 2001 From: Al Viro Date: Wed, 3 Jul 2013 16:19:23 +0400 Subject: Document ->tmpfile() Signed-off-by: Al Viro --- Documentation/filesystems/Locking | 2 ++ Documentation/filesystems/vfs.txt | 5 +++++ 2 files changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 7d9ca7a..e95d313 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -64,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 @@ -91,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. diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 51ba44e..aeff462 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 ======================== -- cgit v1.1 From 90d06a46835ba73deffb483970fdc2bffa4bb274 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Tue, 18 Jun 2013 14:49:29 -0700 Subject: coccicheck: span checks across CPUs This adds parallelism by default to the "coccicheck" target using spatch's "-max" and "-index" arguments. Signed-off-by: Kees Cook Signed-off-by: Nicolas Palix Signed-off-by: Michal Marek --- Documentation/coccinelle.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt index 18de785..408439d 100644 --- a/Documentation/coccinelle.txt +++ b/Documentation/coccinelle.txt @@ -91,6 +91,11 @@ To enable verbose messages set the V= variable, for example: make coccicheck MODE=report V=1 +By default, coccicheck tries to run as parallel as possible. To change +the parallelism, set the J= variable. For example, to run across 4 CPUs: + + make coccicheck MODE=report J=4 + Using Coccinelle with a single semantic patch ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.1 From 78a95b9b4b3dcb53736a1834e8557d3e1668562a Mon Sep 17 00:00:00 2001 From: Nicolas Palix Date: Thu, 20 Jun 2013 14:00:19 +0200 Subject: Coccinelle: Update the documentation - The new default mode is 'report'. - The available modes are detailed a bit more. - Some information about the use of spatch options are also given concerning the use of indexing tools. Signed-off-by: Nicolas Palix Signed-off-by: Michal Marek --- Documentation/coccinelle.txt | 39 ++++++++++++++++++++++++++------------- 1 file changed, 26 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt index 408439d..81a329f 100644 --- a/Documentation/coccinelle.txt +++ b/Documentation/coccinelle.txt @@ -48,7 +48,7 @@ A Coccinelle-specific target is defined in the top level Makefile. This target is named 'coccicheck' and calls the 'coccicheck' front-end in the 'scripts' directory. -Four modes are defined: patch, report, context, and org. The mode to +Four basic modes are defined: patch, report, context, and org. The mode to use is specified by setting the MODE variable with 'MODE='. 'patch' proposes a fix, when possible. @@ -62,18 +62,24 @@ diff-like style.Lines of interest are indicated with '-'. 'org' generates a report in the Org mode format of Emacs. Note that not all semantic patches implement all modes. For easy use -of Coccinelle, the default mode is "chain" which tries the previous -modes in the order above until one succeeds. +of Coccinelle, the default mode is "report". -To make a report for every semantic patch, run the following command: +Two other modes provide some common combinations of these modes. - make coccicheck MODE=report +'chain' tries the previous modes in the order above until one succeeds. -NB: The 'report' mode is the default one. +'rep+ctxt' runs successively the report mode and the context mode. + It should be used with the C option (described later) + which checks the code on a file basis. -To produce patches, run: +Examples: + To make a report for every semantic patch, run the following command: - make coccicheck MODE=patch + make coccicheck MODE=report + + To produce patches, run: + + make coccicheck MODE=patch The coccicheck target applies every semantic patch available in the @@ -129,26 +135,33 @@ To check only newly edited code, use the value 2 for the C flag, i.e. make C=2 CHECK="scripts/coccicheck" +In these modes, which works on a file basis, there is no information +about semantic patches displayed, and no commit message proposed. + This runs every semantic patch in scripts/coccinelle by default. The COCCI variable may additionally be used to only apply a single semantic patch as shown in the previous section. -The "chain" mode is the default. You can select another one with the +The "report" mode is the default. You can select another one with the MODE variable explained above. -In this mode, there is no information about semantic patches -displayed, and no commit message proposed. - Additional flags ~~~~~~~~~~~~~~~~~~ Additional flags can be passed to spatch through the SPFLAGS variable. - make SPFLAGS=--use_glimpse coccicheck + make SPFLAGS=--use-glimpse coccicheck + make SPFLAGS=--use-idutils coccicheck See spatch --help to learn more about spatch options. +Note that the '--use-glimpse' and '--use-idutils' options +require external tools for indexing the code. None of them is +thus active by default. However, by indexing the code with +one of these tools, and according to the cocci file used, +spatch could proceed the entire code base more quickly. + Proposing new semantic patches ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.1 From c1b40e447af8695666d4c11cfec4a7407e6a124d Mon Sep 17 00:00:00 2001 From: Stuart Menefy Date: Wed, 26 Jun 2013 12:48:38 +0100 Subject: clocksource: arm_global_timer: Add ARM global timer support This is a simple driver for the global timer module found in the Cortex A9-MP cores from revision r1p0 onwards. This should be able to perform the functions of the system timer and the local timer in an SMP system. The global timer has the following features: The global timer is a 64-bit incrementing counter with an auto-incrementing feature. It continues incrementing after sending interrupts. The global timer is memory mapped in the private memory region. The global timer is accessible to all Cortex-A9 processors in the cluster. Each Cortex-A9 processor has a private 64-bit comparator that is used to assert a private interrupt when the global timer has reached the comparator value. All the Cortex-A9 processors in a design use the banked ID, ID27, for this interrupt. ID27 is sent to the Interrupt Controller as a Private Peripheral Interrupt. The global timer is clocked by PERIPHCLK. Signed-off-by: Stuart Menefy Signed-off-by: Srinivas Kandagatla CC: Arnd Bergmann CC: Rob Herring CC: Linus Walleij CC: Will Deacon CC: Thomas Gleixner Signed-off-by: Daniel Lezcano --- .../devicetree/bindings/arm/global_timer.txt | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/global_timer.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt b/Documentation/devicetree/bindings/arm/global_timer.txt new file mode 100644 index 0000000..1e54898 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/global_timer.txt @@ -0,0 +1,24 @@ + +* ARM Global Timer + Cortex-A9 are often associated with a per-core Global timer. + +** Timer node required properties: + +- compatible : Should be "arm,cortex-a9-global-timer" + Driver supports versions r2p0 and above. + +- interrupts : One interrupt to each core + +- reg : Specify the base address and the size of the GT timer + register window. + +- clocks : Should be phandle to a clock. + +Example: + + timer@2c000600 { + compatible = "arm,cortex-a9-global-timer"; + reg = <0x2c000600 0x20>; + interrupts = <1 13 0xf01>; + clocks = <&arm_periph_clk>; + }; -- cgit v1.1 From ec97946ed038f4b3faa587bc76152b198805b0c4 Mon Sep 17 00:00:00 2001 From: Nicolas Palix Date: Wed, 3 Jul 2013 16:41:01 +0200 Subject: Coccinelle: Update information about the minimal version required The naming convention of options has changed one year ago. The options have been recently updated in the cocci file and in scripts/coccicheck. This patch also adds this information in the documentation. Signed-off-by: Nicolas Palix Signed-off-by: Michal Marek --- Documentation/coccinelle.txt | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt index 81a329f..7f773d5 100644 --- a/Documentation/coccinelle.txt +++ b/Documentation/coccinelle.txt @@ -6,15 +6,17 @@ Copyright 2010 Gilles Muller Getting Coccinelle ~~~~~~~~~~~~~~~~~~~~ -The semantic patches included in the kernel use the 'virtual rule' -feature which was introduced in Coccinelle version 0.1.11. +The semantic patches included in the kernel use features and options +which are provided by Coccinelle version 1.0.0-rc11 and above. +Using earlier versions will fail as the option names used by +the Coccinelle files and coccicheck have been updated. -Coccinelle (>=0.2.0) is available through the package manager +Coccinelle is available through the package manager of many distributions, e.g. : - - Debian (>=squeeze) - - Fedora (>=13) - - Ubuntu (>=10.04 Lucid Lynx) + - Debian + - Fedora + - Ubuntu - OpenSUSE - Arch Linux - NetBSD @@ -36,11 +38,6 @@ as a regular user, and install it with sudo make install -The semantic patches in the kernel will work best with Coccinelle version -0.2.4 or later. Using earlier versions may incur some parse errors in the -semantic patch code, but any results that are obtained should still be -correct. - Using Coccinelle on the Linux kernel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- cgit v1.1 From 0f8975ec4db2c8b5bd111b211292ca9be0feb6b8 Mon Sep 17 00:00:00 2001 From: Pavel Emelyanov Date: Wed, 3 Jul 2013 15:01:20 -0700 Subject: mm: soft-dirty bits for user memory changes tracking The soft-dirty is a bit on a PTE which helps to track which pages a task writes to. In order to do this tracking one should 1. Clear soft-dirty bits from PTEs ("echo 4 > /proc/PID/clear_refs) 2. Wait some time. 3. Read soft-dirty bits (55'th in /proc/PID/pagemap2 entries) To do this tracking, the writable bit is cleared from PTEs when the soft-dirty bit is. Thus, after this, when the task tries to modify a page at some virtual address the #PF occurs and the kernel sets the soft-dirty bit on the respective PTE. Note, that although all the task's address space is marked as r/o after the soft-dirty bits clear, the #PF-s that occur after that are processed fast. This is so, since the pages are still mapped to physical memory, and thus all the kernel does is finds this fact out and puts back writable, dirty and soft-dirty bits on the PTE. Another thing to note, is that when mremap moves PTEs they are marked with soft-dirty as well, since from the user perspective mremap modifies the virtual memory at mremap's new address. Signed-off-by: Pavel Emelyanov Cc: Matt Mackall Cc: Xiao Guangrong Cc: Glauber Costa Cc: Marcelo Tosatti Cc: KOSAKI Motohiro Cc: Stephen Rothwell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.txt | 7 ++++++- Documentation/vm/soft-dirty.txt | 36 ++++++++++++++++++++++++++++++++++++ 2 files changed, 42 insertions(+), 1 deletion(-) create mode 100644 Documentation/vm/soft-dirty.txt (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index fd8d0d5..fcc22c9 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -473,7 +473,8 @@ This file is only present if the CONFIG_MMU kernel configuration option is enabled. The /proc/PID/clear_refs is used to reset the PG_Referenced and ACCESSED/YOUNG -bits on both physical and virtual pages associated with a process. +bits on both physical and virtual pages associated with a process, and the +soft-dirty bit on pte (see Documentation/vm/soft-dirty.txt for details). To clear the bits for all the pages associated with the process > echo 1 > /proc/PID/clear_refs @@ -482,6 +483,10 @@ To clear the bits for the anonymous pages associated with the process To clear the bits for the file mapped pages associated with the process > echo 3 > /proc/PID/clear_refs + +To clear the soft-dirty bit + > echo 4 > /proc/PID/clear_refs + Any other value written to /proc/PID/clear_refs will have no effect. The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags diff --git a/Documentation/vm/soft-dirty.txt b/Documentation/vm/soft-dirty.txt new file mode 100644 index 0000000..9a12a59 --- /dev/null +++ b/Documentation/vm/soft-dirty.txt @@ -0,0 +1,36 @@ + SOFT-DIRTY PTEs + + The soft-dirty is a bit on a PTE which helps to track which pages a task +writes to. In order to do this tracking one should + + 1. Clear soft-dirty bits from the task's PTEs. + + This is done by writing "4" into the /proc/PID/clear_refs file of the + task in question. + + 2. Wait some time. + + 3. Read soft-dirty bits from the PTEs. + + This is done by reading from the /proc/PID/pagemap. The bit 55 of the + 64-bit qword is the soft-dirty one. If set, the respective PTE was + written to since step 1. + + + Internally, to do this tracking, the writable bit is cleared from PTEs +when the soft-dirty bit is cleared. So, after this, when the task tries to +modify a page at some virtual address the #PF occurs and the kernel sets +the soft-dirty bit on the respective PTE. + + Note, that although all the task's address space is marked as r/o after the +soft-dirty bits clear, the #PF-s that occur after that are processed fast. +This is so, since the pages are still mapped to physical memory, and thus all +the kernel does is finds this fact out and puts both writable and soft-dirty +bits on the PTE. + + + This feature is actively used by the checkpoint-restore project. You +can find more details about it on http://criu.org + + +-- Pavel Emelyanov, Apr 9, 2013 -- cgit v1.1 From 541c237c0923f567c9c4cabb8a81635baadc713f Mon Sep 17 00:00:00 2001 From: Pavel Emelyanov Date: Wed, 3 Jul 2013 15:01:22 -0700 Subject: pagemap: prepare to reuse constant bits with page-shift In order to reuse bits from pagemap entries gracefully, we leave the entries as is but on pagemap open emit a warning in dmesg, that bits 55-60 are about to change in a couple of releases. Next, if a user issues soft-dirty clear command via the clear_refs file (it was disabled before v3.9) we assume that he's aware of the new pagemap format, note that fact and report the bits in pagemap in the new manner. The "migration strategy" looks like this then: 1. existing users are not affected -- they don't touch soft-dirty feature, thus see old bits in pagemap, but are warned and have time to fix themselves 2. those who use soft-dirty know about new pagemap format 3. some time soon we get rid of any signs of page-shift in pagemap as well as this trick with clear-soft-dirty affecting pagemap format. Signed-off-by: Pavel Emelyanov Cc: Matt Mackall Cc: Xiao Guangrong Cc: Glauber Costa Cc: Marcelo Tosatti Cc: KOSAKI Motohiro Cc: Stephen Rothwell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/pagemap.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt index 7587493..fd7c3cf 100644 --- a/Documentation/vm/pagemap.txt +++ b/Documentation/vm/pagemap.txt @@ -15,7 +15,8 @@ There are three components to pagemap: * Bits 0-54 page frame number (PFN) if present * Bits 0-4 swap type if swapped * Bits 5-54 swap offset if swapped - * Bits 55-60 page shift (page size = 1< Date: Wed, 3 Jul 2013 15:02:25 -0700 Subject: memcg: update TODO list in Documentation hugetlb cgroup has already been implemented. Signed-off-by: Li Zefan Acked-by: KAMEZAWA Hiroyuki Acked-by: Rob Landley Cc: Michal Hocko Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/cgroups/memory.txt | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index ddf4f93..327acec 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -834,10 +834,9 @@ Test: 12. TODO -1. Add support for accounting huge pages (as a separate controller) -2. Make per-cgroup scanner reclaim not-shared pages first -3. Teach controller to account for shared-pages -4. Start reclamation in the background when the limit is +1. Make per-cgroup scanner reclaim not-shared pages first +2. Teach controller to account for shared-pages +3. Start reclamation in the background when the limit is not yet hit but the usage is getting closer Summary -- cgit v1.1 From 26c0c5bf38159673f0ae28c38fc9f90dbeb4d4aa Mon Sep 17 00:00:00 2001 From: Mel Gorman Date: Wed, 3 Jul 2013 15:04:45 -0700 Subject: documentation: update address_space_operations The documentation for address_space_operations is partially out of date. Signed-off-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/vfs.txt | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 1f0ba30..fc5d2a1 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -559,7 +559,6 @@ your filesystem. The following members are defined: struct address_space_operations { int (*writepage)(struct page *page, struct writeback_control *wbc); int (*readpage)(struct file *, struct page *); - int (*sync_page)(struct page *); int (*writepages)(struct address_space *, struct writeback_control *); int (*set_page_dirty)(struct page *page); int (*readpages)(struct file *filp, struct address_space *mapping, @@ -581,6 +580,8 @@ struct address_space_operations { /* migrate the contents of a page to the specified target */ int (*migratepage) (struct page *, struct page *); int (*launder_page) (struct page *); + int (*is_partially_uptodate) (struct page *, read_descriptor_t *, + unsigned long); int (*error_remove_page) (struct mapping *mapping, struct page *page); int (*swap_activate)(struct file *); int (*swap_deactivate)(struct file *); @@ -612,13 +613,6 @@ struct address_space_operations { In this case, the page will be relocated, relocked and if that all succeeds, ->readpage will be called again. - sync_page: called by the VM to notify the backing store to perform all - queued I/O operations for a page. I/O operations for other pages - associated with this address_space object may also be performed. - - This function is optional and is called only for pages with - PG_Writeback set while waiting for the writeback to complete. - writepages: called by the VM to write out pages associated with the address_space object. If wbc->sync_mode is WBC_SYNC_ALL, then the writeback_control will specify a range of pages that must be @@ -747,6 +741,11 @@ struct address_space_operations { prevent redirtying the page, it is kept locked during the whole operation. + is_partially_uptodate: Called by the VM when reading a file through the + pagecache when the underlying blocksize != pagesize. If the required + block is up to date then the read can complete without needing the IO + to bring the whole page up to date. + error_remove_page: normally set to generic_error_remove_page if truncation is ok for this address space. Used for memory failure handling. Setting this implies you deal with pages going away under you, -- cgit v1.1 From 543cc115339baa44fbea877b3d8673aca652622f Mon Sep 17 00:00:00 2001 From: Mel Gorman Date: Wed, 3 Jul 2013 15:04:46 -0700 Subject: documentation: document the is_dirty_writeback aops callback Signed-off-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/vfs.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index fc5d2a1..f93a882 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -582,6 +582,7 @@ struct address_space_operations { int (*launder_page) (struct page *); int (*is_partially_uptodate) (struct page *, read_descriptor_t *, unsigned long); + void (*is_dirty_writeback) (struct page *, bool *, bool *); int (*error_remove_page) (struct mapping *mapping, struct page *page); int (*swap_activate)(struct file *); int (*swap_deactivate)(struct file *); @@ -746,6 +747,15 @@ struct address_space_operations { block is up to date then the read can complete without needing the IO to bring the whole page up to date. + is_dirty_writeback: Called by the VM when attempting to reclaim a page. + The VM uses dirty and writeback information to determine if it needs + to stall to allow flushers a chance to complete some IO. Ordinarily + it can use PageDirty and PageWriteback but some filesystems have + more complex state (unstable pages in NFS prevent reclaim) or + do not set those flags due to locking problems (jbd). This callback + allows a filesystem to indicate to the VM if a page should be + treated as dirty or writeback for the purposes of stalling. + error_remove_page: normally set to generic_error_remove_page if truncation is ok for this address space. Used for memory failure handling. Setting this implies you deal with pages going away under you, -- cgit v1.1 From 48a9db462d99494583dad829969616ac90a8df4e Mon Sep 17 00:00:00 2001 From: Bartlomiej Zolnierkiewicz Date: Wed, 3 Jul 2013 15:05:06 -0700 Subject: drivers/dma: remove unused support for MEMSET operations There have never been any real users of MEMSET operations since they have been introduced in January 2007 by commit 7405f74badf4 ("dmaengine: refactor dmaengine around dma_async_tx_descriptor"). Therefore remove support for them for now, it can be always brought back when needed. [sebastian.hesselbarth@gmail.com: fix drivers/dma/mv_xor] Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Kyungmin Park Signed-off-by: Sebastian Hesselbarth Cc: Vinod Koul Acked-by: Dan Williams Cc: Tomasz Figa Cc: Herbert Xu Cc: Olof Johansson Cc: Kevin Hilman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/crypto/async-tx-api.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/crypto/async-tx-api.txt b/Documentation/crypto/async-tx-api.txt index ba046b8..7bf1be2 100644 --- a/Documentation/crypto/async-tx-api.txt +++ b/Documentation/crypto/async-tx-api.txt @@ -222,5 +222,4 @@ drivers/dma/: location for offload engine drivers include/linux/async_tx.h: core header file for the async_tx api crypto/async_tx/async_tx.c: async_tx interface to dmaengine and common code crypto/async_tx/async_memcpy.c: copy offload -crypto/async_tx/async_memset.c: memory fill offload crypto/async_tx/async_xor.c: xor and xor zero sum offload -- cgit v1.1 From 1df0a4711f6e93c1073dd82f6e7905748842e2b3 Mon Sep 17 00:00:00 2001 From: Bernie Thompson Date: Wed, 3 Jul 2013 15:07:03 -0700 Subject: rtc: add ability to push out an existing wakealarm using sysfs This adds the ability for the rtc sysfs code to handle += characters at the beginning of a wakealarm setting string. This will allow the user to attempt to push out an existing wakealarm by a provided amount. In the case that the += characters are provided but the alarm is not active -EINVAL is returned. his is useful, at least for my purposes in suspend/resume testing. The basic test goes something like: 1. Set a wake alarm from userspace 5 seconds in the future 2. Start the suspend process (echo mem > /sys/power/state) 3. After ~2.5 seconds if userspace is still running (using another thread to check this), move the wake alarm 5 more seconds If the "move" involves an unset of the wakealarm then there's a period of time where the system is midway through suspending but has no wake alarm. It will get stuck. We'd rather not remove the "move" since the idea is to avoid a cancelled suspend when the alarm fires _during_ suspend. It is difficult for the test to tell the difference between a suspend that was cancelled because the alarm fired too early and a suspend that was Signed-off-by: Bernie Thompson Cc: Alessandro Zummo Cc: Doug Anderson Cc: "Rafael J. Wysocki" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/rtc.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt index 32aa400..596b60c 100644 --- a/Documentation/rtc.txt +++ b/Documentation/rtc.txt @@ -153,9 +153,10 @@ since_epoch: The number of seconds since the epoch according to the RTC time: RTC-provided time wakealarm: The time at which the clock will generate a system wakeup event. This is a one shot wakeup event, so must be reset - after wake if a daily wakeup is required. Format is either - seconds since the epoch or, if there's a leading +, seconds - in the future. + after wake if a daily wakeup is required. Format is seconds since + the epoch by default, or if there's a leading +, seconds in the + future, or if there is a leading +=, seconds ahead of the current + alarm. IOCTL INTERFACE --------------- -- cgit v1.1 From b57a0505e750b3d7b2d39e9823b276d8ca1a08fe Mon Sep 17 00:00:00 2001 From: Dan Carpenter Date: Wed, 3 Jul 2013 15:08:08 -0700 Subject: Documentation/CodingStyle: allow multiple return statements per function A surprising number of newbies interpret this section to mean that only one return statement is allowed per function. Part of the problem is that the "one return statement per function" rule is an actual style guideline that people are used to from other projects. Signed-off-by: Dan Carpenter Cc: Eduardo Valentin Cc: Rob Landley Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/CodingStyle | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index e00b8f0..7fe0546 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -389,7 +389,8 @@ Albeit deprecated by some people, the equivalent of the goto statement is used frequently by compilers in form of the unconditional jump instruction. The goto statement comes in handy when a function exits from multiple -locations and some common work such as cleanup has to be done. +locations and some common work such as cleanup has to be done. If there is no +cleanup needed then just return directly. The rationale is: -- cgit v1.1 From 4d8eaaae7629074b6d3455cb71632f5969f34de7 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Wed, 3 Jul 2013 15:08:10 -0700 Subject: docbook: add futexes to kernel-locking docbook Add Fast User Mutexes (futexes) to kernel-locking docbook. Signed-off-by: Randy Dunlap Acked-by: Rob Landley Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/DocBook/kernel-locking.tmpl | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index 67e7ab4..09e884e 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl @@ -1955,12 +1955,17 @@ machines due to caching. - + Mutex API reference !Iinclude/linux/mutex.h !Ekernel/mutex.c + + Futex API reference +!Ikernel/futex.c + + Further reading -- cgit v1.1 From a11edb59a05d8d5195419bd1fc28d82752324158 Mon Sep 17 00:00:00 2001 From: Zhang Yanfei Date: Wed, 3 Jul 2013 15:08:36 -0700 Subject: /dev/oldmem: Remove the interface /dev/oldmem provides the interface for us to access the "old memory" in the dump-capture kernel. Unfortunately, no one actually uses this interface. And this interface could actually cause some real problems if used on ia64 where the cached/uncached accesses are mixed. See the discussion from the link: https://lkml.org/lkml/2013/4/12/386. So Eric suggested that we should remove /dev/oldmem as an unused piece of code. [akpm@linux-foundation.org: mention /dev/oldmem obsolescence in devices.txt] Suggested-by: "Eric W. Biederman" Signed-off-by: Zhang Yanfei Cc: Vivek Goyal Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: "H. Peter Anvin" Cc: Benjamin Herrenschmidt Cc: Fenghua Yu Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Matt Fleming Cc: Michael Holzheu Cc: Paul Mackerras Cc: Ralf Baechle Cc: Tony Luck Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/devices.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devices.txt b/Documentation/devices.txt index b901591..23721d3 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -100,8 +100,7 @@ Your cooperation is appreciated. 10 = /dev/aio Asynchronous I/O notification interface 11 = /dev/kmsg Writes to this come out as printk's, reads export the buffered printk records. - 12 = /dev/oldmem Used by crashdump kernels to access - the memory of the kernel that crashed. + 12 = /dev/oldmem OBSOLETE - replaced by /proc/vmcore 1 block RAM disk 0 = /dev/ram0 First RAM disk -- cgit v1.1 From 987bf6fe3b1409b1cdf4352b3c421260c95d52f2 Mon Sep 17 00:00:00 2001 From: Zhang Yanfei Date: Wed, 3 Jul 2013 15:08:38 -0700 Subject: Documentation/kdump/kdump.txt: remove /dev/oldmem description Signed-off-by: Zhang Yanfei Cc: Vivek Goyal Cc: "Eric W. Biederman" Cc: "H. Peter Anvin" Cc: Benjamin Herrenschmidt Cc: Dave Hansen Cc: Fenghua Yu Cc: Heiko Carstens Cc: Martin Schwidefsky Cc: Matt Fleming Cc: Michael Holzheu Cc: Paul Mackerras Cc: Ralf Baechle Cc: Tony Luck Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kdump/kdump.txt | 31 ++++++------------------------- 1 file changed, 6 insertions(+), 25 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 9c7fd988..bec123e 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -47,19 +47,12 @@ parameter. Optionally the size of the ELF header can also be passed when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax. -With the dump-capture kernel, you can access the memory image, or "old -memory," in two ways: - -- Through a /dev/oldmem device interface. A capture utility can read the - device file and write out the memory in raw format. This is a raw dump - of memory. Analysis and capture tools must be intelligent enough to - determine where to look for the right information. - -- Through /proc/vmcore. This exports the dump as an ELF-format file that - you can write out using file copy commands such as cp or scp. Further, - you can use analysis tools such as the GNU Debugger (GDB) and the Crash - tool to debug the dump file. This method ensures that the dump pages are - correctly ordered. +With the dump-capture kernel, you can access the memory image through +/proc/vmcore. This exports the dump as an ELF-format file that you can +write out using file copy commands such as cp or scp. Further, you can +use analysis tools such as the GNU Debugger (GDB) and the Crash tool to +debug the dump file. This method ensures that the dump pages are correctly +ordered. Setup and Installation @@ -423,18 +416,6 @@ the following command: cp /proc/vmcore -You can also access dumped memory as a /dev/oldmem device for a linear -and raw view. To create the device, use the following command: - - mknod /dev/oldmem c 1 12 - -Use the dd command with suitable options for count, bs, and skip to -access specific portions of the dump. - -To see the entire memory, use the following command: - - dd if=/dev/oldmem of=oldmem.001 - Analysis ======== -- cgit v1.1 From ed5edee2f8547d5c2b28de21cb1471aaea71ee0a Mon Sep 17 00:00:00 2001 From: Alexandre Bounine Date: Wed, 3 Jul 2013 15:08:59 -0700 Subject: rapidio: documentation update Update RapidIO documentation files to reflect modularization changes. Signed-off-by: Alexandre Bounine Cc: Matt Porter Cc: Li Yang Cc: Kumar Gala Cc: Andre van Herk Cc: Micha Nelissen Cc: Stef van Os Cc: Jean Delvare Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/rapidio/rapidio.txt | 98 +++++++++++++++++++++++++++++++++------ Documentation/rapidio/sysfs.txt | 1 + 2 files changed, 86 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/rapidio/rapidio.txt b/Documentation/rapidio/rapidio.txt index a9c16c9..717f5aa 100644 --- a/Documentation/rapidio/rapidio.txt +++ b/Documentation/rapidio/rapidio.txt @@ -73,28 +73,44 @@ data structure. This structure includes lists of all devices and local master ports that form the same network. It also contains a pointer to the default master port that is used to communicate with devices within the network. +2.5 Device Drivers + +RapidIO device-specific drivers follow Linux Kernel Driver Model and are +intended to support specific RapidIO devices attached to the RapidIO network. + +2.6 Subsystem Interfaces + +RapidIO interconnect specification defines features that may be used to provide +one or more common service layers for all participating RapidIO devices. These +common services may act separately from device-specific drivers or be used by +device-specific drivers. Example of such service provider is the RIONET driver +which implements Ethernet-over-RapidIO interface. Because only one driver can be +registered for a device, all common RapidIO services have to be registered as +subsystem interfaces. This allows to have multiple common services attached to +the same device without blocking attachment of a device-specific driver. + 3. Subsystem Initialization --------------------------- In order to initialize the RapidIO subsystem, a platform must initialize and register at least one master port within the RapidIO network. To register mport -within the subsystem controller driver initialization code calls function +within the subsystem controller driver's initialization code calls function rio_register_mport() for each available master port. -RapidIO subsystem uses subsys_initcall() or device_initcall() to perform -controller initialization (depending on controller device type). - After all active master ports are registered with a RapidIO subsystem, an enumeration and/or discovery routine may be called automatically or by user-space command. +RapidIO subsystem can be configured to be built as a statically linked or +modular component of the kernel (see details below). + 4. Enumeration and Discovery ---------------------------- 4.1 Overview ------------ -RapidIO subsystem configuration options allow users to specify enumeration and +RapidIO subsystem configuration options allow users to build enumeration and discovery methods as statically linked components or loadable modules. An enumeration/discovery method implementation and available input parameters define how any given method can be attached to available RapidIO mports: @@ -115,8 +131,8 @@ several methods to initiate an enumeration and/or discovery process: endpoint waits for enumeration to be completed. If the specified timeout expires the discovery process is terminated without obtaining RapidIO network information. NOTE: a timed out discovery process may be restarted later using - a user-space command as it is described later if the given endpoint was - enumerated successfully. + a user-space command as it is described below (if the given endpoint was + enumerated successfully). (b) Statically linked enumeration and discovery process can be started by a command from user space. This initiation method provides more flexibility @@ -138,15 +154,42 @@ When a network scan process is started it calls an enumeration or discovery routine depending on the configured role of a master port: host or agent. Enumeration is performed by a master port if it is configured as a host port by -assigning a host device ID greater than or equal to zero. A host device ID is -assigned to a master port through the kernel command line parameter "riohdid=", -or can be configured in a platform-specific manner. If the host device ID for -a specific master port is set to -1, the discovery process will be performed -for it. +assigning a host destination ID greater than or equal to zero. The host +destination ID can be assigned to a master port using various methods depending +on RapidIO subsystem build configuration: + + (a) For a statically linked RapidIO subsystem core use command line parameter + "rapidio.hdid=" with a list of destination ID assignments in order of mport + device registration. For example, in a system with two RapidIO controllers + the command line parameter "rapidio.hdid=-1,7" will result in assignment of + the host destination ID=7 to the second RapidIO controller, while the first + one will be assigned destination ID=-1. + + (b) If the RapidIO subsystem core is built as a loadable module, in addition + to the method shown above, the host destination ID(s) can be specified using + traditional methods of passing module parameter "hdid=" during its loading: + - from command line: "modprobe rapidio hdid=-1,7", or + - from modprobe configuration file using configuration command "options", + like in this example: "options rapidio hdid=-1,7". An example of modprobe + configuration file is provided in the section below. + + NOTES: + (i) if "hdid=" parameter is omitted all available mport will be assigned + destination ID = -1; + (ii) the "hdid=" parameter in systems with multiple mports can have + destination ID assignments omitted from the end of list (default = -1). + +If the host device ID for a specific master port is set to -1, the discovery +process will be performed for it. The enumeration and discovery routines use RapidIO maintenance transactions to access the configuration space of devices. +NOTE: If RapidIO switch-specific device drivers are built as loadable modules +they must be loaded before enumeration/discovery process starts. +This requirement is cased by the fact that enumeration/discovery methods invoke +vendor-specific callbacks on early stages. + 4.2 Automatic Start of Enumeration and Discovery ------------------------------------------------ @@ -266,7 +309,36 @@ method's module initialization routine calls rio_register_scan() to attach an enumerator to a specified mport device (or devices). The basic enumerator implementation demonstrates this process. -5. References +4.6 Using Loadable RapidIO Switch Drivers +----------------------------------------- + +In the case when RapidIO switch drivers are built as loadable modules a user +must ensure that they are loaded before the enumeration/discovery starts. +This process can be automated by specifying pre- or post- dependencies in the +RapidIO-specific modprobe configuration file as shown in the example below. + + File /etc/modprobe.d/rapidio.conf: + ---------------------------------- + + # Configure RapidIO subsystem modules + + # Set enumerator host destination ID (overrides kernel command line option) + options rapidio hdid=-1,2 + + # Load RapidIO switch drivers immediately after rapidio core module was loaded + softdep rapidio post: idt_gen2 idtcps tsi57x + + # OR : + + # Load RapidIO switch drivers just before rio-scan enumerator module is loaded + softdep rio-scan pre: idt_gen2 idtcps tsi57x + + -------------------------- + +NOTE: In the example above, one of "softdep" commands must be removed or +commented out to keep required module loading sequence. + +A. References ------------- [1] RapidIO Trade Association. RapidIO Interconnect Specifications. diff --git a/Documentation/rapidio/sysfs.txt b/Documentation/rapidio/sysfs.txt index 1987817..271438c 100644 --- a/Documentation/rapidio/sysfs.txt +++ b/Documentation/rapidio/sysfs.txt @@ -40,6 +40,7 @@ device_rev - returns the device revision level (see 4.1 for switch specific details) lprev - returns name of previous device (switch) on the path to the device that that owns this attribute + modalias - returns the device modalias In addition to the files listed above, each device has a binary attribute file that allows read/write access to the device configuration registers using -- cgit v1.1 From 8da01af45e197110cbce84fb5ccb54645f051ac6 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Wed, 3 Jul 2013 15:09:08 -0700 Subject: Documentation/accounting/getdelays.c: avoid strncpy in accounting tool Avoid strncpy anti-pattern. [akpm@linux-foundation.org: remove the str[cpy|dup] altogether] Signed-off-by: Kees Cook Cc: Andreas Schwab Cc: Rob Landley Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/accounting/getdelays.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index f8ebcde..c6a06b7 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -272,7 +272,7 @@ int main(int argc, char *argv[]) char *logfile = NULL; int loop = 0; int containerset = 0; - char containerpath[1024]; + char *containerpath = NULL; int cfd = 0; int forking = 0; sigset_t sigset; @@ -299,7 +299,7 @@ int main(int argc, char *argv[]) break; case 'C': containerset = 1; - strncpy(containerpath, optarg, strlen(optarg) + 1); + containerpath = optarg; break; case 'w': logfile = strdup(optarg); -- cgit v1.1 From c5dbcf8b70b50b1f6ef4850f61d79204ea46d761 Mon Sep 17 00:00:00 2001 From: Jan Luebbe Date: Wed, 3 Jul 2013 15:09:12 -0700 Subject: pps-gpio: add device-tree binding and support Instead of allocating a struct pps_gpio_platform_data in the DT case, store the necessary information in struct pps_gpio_device_data itself. This avoids an additional allocation and the ifdef. It also gets rid of some indirection. Also use dev_err instead of pr_err in the changed code. Signed-off-by: Jan Luebbe Acked-by: Arnd Bergmann Acked-by: Rodolfo Giometti Cc: Grant Likely Cc: Rob Herring Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/devicetree/bindings/pps/pps-gpio.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/pps/pps-gpio.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt b/Documentation/devicetree/bindings/pps/pps-gpio.txt new file mode 100644 index 0000000..40bf9c3 --- /dev/null +++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt @@ -0,0 +1,20 @@ +Device-Tree Bindings for a PPS Signal on GPIO + +These properties describe a PPS (pulse-per-second) signal connected to +a GPIO pin. + +Required properties: +- compatible: should be "pps-gpio" +- gpios: one PPS GPIO in the format described by ../gpio/gpio.txt + +Optional properties: +- assert-falling-edge: when present, assert is indicated by a falling edge + (instead of by a rising edge) + +Example: + pps { + compatible = "pps-gpio"; + gpios = <&gpio2 6 0>; + + assert-falling-edge; + }; -- cgit v1.1 From 8eed2641df55f7a3e69699b50a63f5705533886f Mon Sep 17 00:00:00 2001 From: Sachin Kamat Date: Mon, 1 Jul 2013 15:15:36 +0900 Subject: of/documentation: Update hpd gpio property for exynos_hdmi Signed-off-by: Sachin Kamat Signed-off-by: Rahul Sharma Signed-off-by: Inki Dae --- Documentation/devicetree/bindings/video/exynos_hdmi.txt | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index c71d0f0..323983b 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -11,9 +11,7 @@ Required properties: - hpd-gpio: following information about the hotplug gpio pin. a) phandle of the gpio controller node. b) pin number within the gpio controller. - c) pin function mode. - d) optional flags and pull up/down. - e) drive strength. + c) optional flags and pull up/down. Example: @@ -21,5 +19,5 @@ Example: compatible = "samsung,exynos4212-hdmi"; reg = <0x14530000 0x100000>; interrupts = <0 95 0>; - hpd-gpio = <&gpx3 7 0xf 1 3>; + hpd-gpio = <&gpx3 7 1>; }; -- cgit v1.1 From 1baa3b4e06f1e03f4fbbbc3734ea3b9a7a1134ec Mon Sep 17 00:00:00 2001 From: Sachin Kamat Date: Thu, 4 Jul 2013 11:48:38 +0530 Subject: regulator: s5m8767: Fix a trivial typo in documentation Changed volatage to voltage. Signed-off-by: Sachin Kamat Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt index 7364f711..d1660a9 100644 --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt @@ -1,6 +1,6 @@ * Samsung S5M8767 Voltage and Current Regulator -The Samsung S5M8767 is a multi-function device which includes volatage and +The Samsung S5M8767 is a multi-function device which includes voltage and current regulators, rtc, charger controller and other sub-blocks. It is interfaced to the host controller using a i2c interface. Each sub-block is addressed by the host system using different i2c slave address. This document -- cgit v1.1 From 489cceeeb808199f55dbff2adaddd7394fb88de6 Mon Sep 17 00:00:00 2001 From: Sachin Kamat Date: Thu, 4 Jul 2013 11:48:39 +0530 Subject: regulator: max8997: Fix a trivial typo in documentation Changed volatage to voltage. Signed-off-by: Sachin Kamat Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/max8997-regulator.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt index 9e5e51d..5c186a7 100644 --- a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt @@ -1,6 +1,6 @@ * Maxim MAX8997 Voltage and Current Regulator -The Maxim MAX8997 is a multi-function device which includes volatage and +The Maxim MAX8997 is a multi-function device which includes voltage and current regulators, rtc, charger controller and other sub-blocks. It is interfaced to the host controller using a i2c interface. Each sub-block is addressed by the host system using different i2c slave address. This document -- cgit v1.1 From 25c83b5c2e82560406d5265f42cd147f1eb441d0 Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Thu, 4 Jul 2013 10:35:41 +0100 Subject: dt:net:stmmac: Add support to dwmac version 3.610 and 3.710 This patch adds dt support to dwmac version 3.610 and 3.710 these versions are integrated in STiH415 and STiH416 ARM A9 SOCs. To support these IP version, some of the device tree properties are extended. Signed-off-by: Srinivas Kandagatla Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/stmmac.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index 060bbf0..e1ddfcc 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -12,6 +12,10 @@ Required properties: property - phy-mode: String, operation mode of the PHY interface. Supported values are: "mii", "rmii", "gmii", "rgmii". +- snps,phy-addr phy address to connect to. +- snps,pbl Programmable Burst Length +- snps,fixed-burst Program the DMA to use the fixed burst mode +- snps,mixed-burst Program the DMA to use the mixed burst mode Optional properties: - mac-address: 6 bytes, mac address -- cgit v1.1 From 0e0764715d8116484d808f5b3985ca043080788e Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Thu, 4 Jul 2013 10:35:48 +0100 Subject: dt:net:stmmac: Add dt specific phy reset callback support. This patch adds phy reset callback support for stmmac driver via device trees. It adds three new properties to gmac device tree bindings to define the reset signal via gpio. With this patch users can conveniently pass reset gpio number with pre, pulse and post delay in micro secs via DTs. active low: _________ ____________ | | | | |_______________| active high: ________________ | | | | ________| |___________ Signed-off-by: Srinivas Kandagatla Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/stmmac.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index e1ddfcc..261c563 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -13,6 +13,12 @@ Required properties: - phy-mode: String, operation mode of the PHY interface. Supported values are: "mii", "rmii", "gmii", "rgmii". - snps,phy-addr phy address to connect to. +- snps,reset-gpio gpio number for phy reset. +- snps,reset-active-low boolean flag to indicate if phy reset is active low. +- snps,reset-delays-us is triplet of delays + The 1st cell is reset pre-delay in micro seconds. + The 2nd cell is reset pulse in micro seconds. + The 3rd cell is reset post-delay in micro seconds. - snps,pbl Programmable Burst Length - snps,fixed-burst Program the DMA to use the fixed burst mode - snps,mixed-burst Program the DMA to use the mixed burst mode -- cgit v1.1 From 290ad0f9d954b445788bf26652b239c59cec2060 Mon Sep 17 00:00:00 2001 From: Markus Pargmann Date: Sun, 26 May 2013 11:53:20 +0200 Subject: dma: imx-dma: Add oftree support Adding devicetree support for imx-dma driver. Use driver name for function 'imx_dma_is_general_purpose' because the devicename for devicetree initialized devices is different. Signed-off-by: Markus Pargmann Reviewed-by: Arnd Bergmann Reviewed-by: Shawn Guo Acked-by: Sascha Hauer Signed-off-by: Vinod Koul --- .../devicetree/bindings/dma/fsl-imx-dma.txt | 48 ++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/fsl-imx-dma.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt new file mode 100644 index 0000000..2717ecb --- /dev/null +++ b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt @@ -0,0 +1,48 @@ +* Freescale Direct Memory Access (DMA) Controller for i.MX + +This document will only describe differences to the generic DMA Controller and +DMA request bindings as described in dma/dma.txt . + +* DMA controller + +Required properties: +- compatible : Should be "fsl,-dma". chip can be imx1, imx21 or imx27 +- reg : Should contain DMA registers location and length +- interrupts : First item should be DMA interrupt, second one is optional and + should contain DMA Error interrupt +- #dma-cells : Has to be 1. imx-dma does not support anything else. + +Optional properties: +- #dma-channels : Number of DMA channels supported. Should be 16. +- #dma-requests : Number of DMA requests supported. + +Example: + + dma: dma@10001000 { + compatible = "fsl,imx27-dma"; + reg = <0x10001000 0x1000>; + interrupts = <32 33>; + #dma-cells = <1>; + #dma-channels = <16>; + }; + + +* DMA client + +Clients have to specify the DMA requests with phandles in a list. + +Required properties: +- dmas: List of one or more DMA request specifiers. One DMA request specifier + consists of a phandle to the DMA controller followed by the integer + specifiying the request line. +- dma-names: List of string identifiers for the DMA requests. For the correct + names, have a look at the specific client driver. + +Example: + + sdhci1: sdhci@10013000 { + ... + dmas = <&dma 7>; + dma-names = "rx-tx"; + ... + }; -- cgit v1.1 From 9479e17c9bb455c01b369d294e01de8fa9b0a8d3 Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Thu, 30 May 2013 22:23:32 +0800 Subject: dma: imx-sdma: move to generic device tree bindings Update imx-sdma driver to adopt generic DMA device tree bindings. It calls of_dma_controller_register() with imx-sdma specific of_dma_xlate to get the generic DMA device tree helper support. The #dma-cells for imx-sdma must be 3, which includes request ID, peripheral type and priority. The existing way of requesting channel, clients directly call dma_request_channel(), still work there, and will be removed after all imx-sdma clients get converted to generic DMA device tree helper. Signed-off-by: Shawn Guo Signed-off-by: Vinod Koul Acked-by: Arnd Bergmann --- .../devicetree/bindings/dma/fsl-imx-sdma.txt | 56 ++++++++++++++++++++++ 1 file changed, 56 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt index d1e3f44..68cee4f5 100644 --- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt +++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt @@ -4,14 +4,70 @@ Required properties: - compatible : Should be "fsl,-sdma" - reg : Should contain SDMA registers location and length - interrupts : Should contain SDMA interrupt +- #dma-cells : Must be <3>. + The first cell specifies the DMA request/event ID. See details below + about the second and third cell. - fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM scripts firmware +The second cell of dma phandle specifies the peripheral type of DMA transfer. +The full ID of peripheral types can be found below. + + ID transfer type + --------------------- + 0 MCU domain SSI + 1 Shared SSI + 2 MMC + 3 SDHC + 4 MCU domain UART + 5 Shared UART + 6 FIRI + 7 MCU domain CSPI + 8 Shared CSPI + 9 SIM + 10 ATA + 11 CCM + 12 External peripheral + 13 Memory Stick Host Controller + 14 Shared Memory Stick Host Controller + 15 DSP + 16 Memory + 17 FIFO type Memory + 18 SPDIF + 19 IPU Memory + 20 ASRC + 21 ESAI + +The third cell specifies the transfer priority as below. + + ID transfer priority + ------------------------- + 0 High + 1 Medium + 2 Low + Examples: sdma@83fb0000 { compatible = "fsl,imx51-sdma", "fsl,imx35-sdma"; reg = <0x83fb0000 0x4000>; interrupts = <6>; + #dma-cells = <3>; fsl,sdma-ram-script-name = "sdma-imx51.bin"; }; + +DMA clients connected to the i.MX SDMA controller must use the format +described in the dma.txt file. + +Examples: + +ssi2: ssi@70014000 { + compatible = "fsl,imx51-ssi", "fsl,imx21-ssi"; + reg = <0x70014000 0x4000>; + interrupts = <30>; + clocks = <&clks 49>; + dmas = <&sdma 24 1 0>, + <&sdma 25 1 0>; + dma-names = "rx", "tx"; + fsl,fifo-depth = <15>; +}; -- cgit v1.1 From 62971b29825adb06908bad81e7679d1f7904b24d Mon Sep 17 00:00:00 2001 From: Ludovic Desroches Date: Thu, 13 Jun 2013 10:39:39 +0200 Subject: dmaengine: at_hdmac: add FIFO configuration parameter to DMA DT binding For most devices the FIFO configuration is the same i.e. when half FIFO size is available/filled, a source/destination request is serviced. But USART devices have to do it when there is enough space/data available to perform a single AHB access so the ASAP configuration. Acked-by: Nicolas Ferre Acked-by: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Ludovic Desroches Signed-off-by: Nicolas Ferre --- Documentation/devicetree/bindings/dma/atmel-dma.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt index c80e8a3..c280a0e 100644 --- a/Documentation/devicetree/bindings/dma/atmel-dma.txt +++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt @@ -24,8 +24,11 @@ The three cells in order are: 1. A phandle pointing to the DMA controller. 2. The memory interface (16 most significant bits), the peripheral interface (16 less significant bits). -3. The peripheral identifier for the hardware handshaking interface. The -identifier can be different for tx and rx. +3. Parameters for the at91 DMA configuration register which are device +dependant: + - bit 7-0: peripheral identifier for the hardware handshaking interface. The + identifier can be different for tx and rx. + - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 1 for ASAP. Example: -- cgit v1.1 From 67eacc1583909d0588c8d5d80c16298c899a6382 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Tue, 18 Jun 2013 18:16:57 +0200 Subject: DMA: shdma: add DT support This patch adds Device Tree support to the shdma driver. No special DT properties are used, only standard DMA DT bindings are implemented. Since shdma controllers reside on SoCs, their configuration is SoC-specific and shall be passed to the driver from the SoC platform data, using the auxdata procedure. Signed-off-by: Guennadi Liakhovetski Acked-by: Arnd Bergmann Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/shdma.txt | 75 +++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/shdma.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/shdma.txt b/Documentation/devicetree/bindings/dma/shdma.txt new file mode 100644 index 0000000..c15994a --- /dev/null +++ b/Documentation/devicetree/bindings/dma/shdma.txt @@ -0,0 +1,75 @@ +* SHDMA Device Tree bindings + +Sh-/r-mobile and r-car systems often have multiple identical DMA controller +instances, capable of serving any of a common set of DMA slave devices, using +the same configuration. To describe this topology we require all compatible +SHDMA DT nodes to be placed under a DMA multiplexer node. All such compatible +DMAC instances have the same number of channels and use the same DMA +descriptors. Therefore respective DMA DT bindings can also all be placed in the +multiplexer node. Even if there is only one such DMAC instance on a system, it +still has to be placed under such a multiplexer node. + +* DMA multiplexer + +Required properties: +- compatible: should be "renesas,shdma-mux" +- #dma-cells: should be <1>, see "dmas" property below + +Optional properties (currently unused): +- dma-channels: number of DMA channels +- dma-requests: number of DMA request signals + +* DMA controller + +Required properties: +- compatible: should be "renesas,shdma" + +Example: + dmac: dma-mux0 { + compatible = "renesas,shdma-mux"; + #dma-cells = <1>; + dma-channels = <6>; + dma-requests = <256>; + reg = <0 0>; /* Needed for AUXDATA */ + #address-cells = <1>; + #size-cells = <1>; + ranges; + + dma0: shdma@fe008020 { + compatible = "renesas,shdma"; + reg = <0xfe008020 0x270>, + <0xfe009000 0xc>; + interrupt-parent = <&gic>; + interrupts = <0 34 4 + 0 28 4 + 0 29 4 + 0 30 4 + 0 31 4 + 0 32 4 + 0 33 4>; + interrupt-names = "error", + "ch0", "ch1", "ch2", "ch3", + "ch4", "ch5"; + }; + + dma1: shdma@fe018020 { + ... + }; + + dma2: shdma@fe028020 { + ... + }; + }; + +* DMA client + +Required properties: +- dmas: a list of <[DMA multiplexer phandle] [MID/RID value]> pairs, + where MID/RID values are fixed handles, specified in the SoC + manual +- dma-names: a list of DMA channel names, one per "dmas" entry + +Example: + dmas = <&dmac 0xd1 + &dmac 0xd2>; + dma-names = "tx", "rx"; -- cgit v1.1 From c73e41c898bb59aaf50098c2c672c7132a88fdbc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Heiko=20St=C3=BCbner?= Date: Thu, 27 Jun 2013 11:55:35 -0400 Subject: mmc: dw_mmc-pltfm: add Rockchip variant Cortex-A9 SoCs from Rockchip use a slightly modified variant of dw_mmc controllers that seems to require the SDMMC_CMD_USE_HOLD_REG bit to always be set. There also seem to be no other modifications (additional register etc) present, so to keep the footprint low, add this small variant to the pltfm driver. Signed-off-by: Heiko Stuebner Acked-by: Seungwon Jeon Signed-off-by: Chris Ball --- .../devicetree/bindings/mmc/rockchip-dw-mshc.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt new file mode 100644 index 0000000..8a3d91d --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt @@ -0,0 +1,23 @@ +* Rockchip specific extensions to the Synopsis Designware Mobile + Storage Host Controller + +The Synopsis designware mobile storage host controller is used to interface +a SoC with storage medium such as eMMC or SD/MMC cards. This file documents +differences between the core Synopsis dw mshc controller properties described +by synopsis-dw-mshc.txt and the properties used by the Rockchip specific +extensions to the Synopsis Designware Mobile Storage Host Controller. + +Required Properties: + +* compatible: should be + - "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following + +Example: + + rkdwmmc0@12200000 { + compatible = "rockchip,rk2928-dw-mshc"; + reg = <0x12200000 0x1000>; + interrupts = <0 75 0>; + #address-cells = <1>; + #size-cells = <0>; + }; -- cgit v1.1 From 1b6c79361ba5ce30b40f0f7d6fc2421dc5fcbe0c Mon Sep 17 00:00:00 2001 From: Markus Pargmann Date: Sun, 26 May 2013 12:35:38 +0200 Subject: video: imxfb: Add DT support Add devicetree support for imx framebuffer driver. It uses the generic display bindings and helper functions. Signed-off-by: Markus Pargmann Cc: Fabio Estevam Cc: Mark Rutland Acked-by: Jean-Christophe PLAGNIOL-VILLARD Acked-by: Sascha Hauer --- .../devicetree/bindings/video/fsl,imx-fb.txt | 51 ++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt new file mode 100644 index 0000000..46da08d --- /dev/null +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt @@ -0,0 +1,51 @@ +Freescale imx21 Framebuffer + +This framebuffer driver supports devices imx1, imx21, imx25, and imx27. + +Required properties: +- compatible : "fsl,-fb", chip should be imx1 or imx21 +- reg : Should contain 1 register ranges(address and length) +- interrupts : One interrupt of the fb dev + +Required nodes: +- display: Phandle to a display node as described in + Documentation/devicetree/bindings/video/display-timing.txt + Additional, the display node has to define properties: + - bits-per-pixel: Bits per pixel + - fsl,pcr: LCDC PCR value + +Optional properties: +- fsl,dmacr: DMA Control Register value. This is optional. By default, the + register is not modified as recommended by the datasheet. +- fsl,lscr1: LCDC Sharp Configuration Register value. + +Example: + + imxfb: fb@10021000 { + compatible = "fsl,imx21-fb"; + interrupts = <61>; + reg = <0x10021000 0x1000>; + display = <&display0>; + }; + + ... + + display0: display0 { + model = "Primeview-PD050VL1"; + native-mode = <&timing_disp0>; + bits-per-pixel = <16>; + fsl,pcr = <0xf0c88080>; /* non-standard but required */ + display-timings { + timing_disp0: 640x480 { + hactive = <640>; + vactive = <480>; + hback-porch = <112>; + hfront-porch = <36>; + hsync-len = <32>; + vback-porch = <33>; + vfront-porch = <33>; + vsync-len = <2>; + clock-frequency = <25000000>; + }; + }; + }; -- cgit v1.1 From 1b2c14b44adcb7836528640bfdc40bf7499d987d Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 8 Jul 2013 10:48:28 -0300 Subject: MAINTAINERS & ABI: Update to point to my new email As mchehab@redhat.com is no longer valid, update it to reflect the new one. Signed-off-by: Mauro Carvalho Chehab --- Documentation/ABI/testing/sysfs-devices-edac | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-edac b/Documentation/ABI/testing/sysfs-devices-edac index 30ee78a..6568e00 100644 --- a/Documentation/ABI/testing/sysfs-devices-edac +++ b/Documentation/ABI/testing/sysfs-devices-edac @@ -77,7 +77,7 @@ Description: Read/Write attribute file that controls memory scrubbing. What: /sys/devices/system/edac/mc/mc*/max_location Date: April 2012 -Contact: Mauro Carvalho Chehab +Contact: Mauro Carvalho Chehab linux-edac@vger.kernel.org Description: This attribute file displays the information about the last available memory slot in this memory controller. It is used by @@ -85,7 +85,7 @@ Description: This attribute file displays the information about the last What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/size Date: April 2012 -Contact: Mauro Carvalho Chehab +Contact: Mauro Carvalho Chehab linux-edac@vger.kernel.org Description: This attribute file will display the size of dimm or rank. For dimm*/size, this is the size, in MB of the DIMM memory @@ -96,14 +96,14 @@ Description: This attribute file will display the size of dimm or rank. What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_dev_type Date: April 2012 -Contact: Mauro Carvalho Chehab +Contact: Mauro Carvalho Chehab linux-edac@vger.kernel.org Description: This attribute file will display what type of DRAM device is being utilized on this DIMM (x1, x2, x4, x8, ...). What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_edac_mode Date: April 2012 -Contact: Mauro Carvalho Chehab +Contact: Mauro Carvalho Chehab linux-edac@vger.kernel.org Description: This attribute file will display what type of Error detection and correction is being utilized. For example: S4ECD4ED would @@ -111,7 +111,7 @@ Description: This attribute file will display what type of Error detection What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_label Date: April 2012 -Contact: Mauro Carvalho Chehab +Contact: Mauro Carvalho Chehab linux-edac@vger.kernel.org Description: This control file allows this DIMM to have a label assigned to it. With this label in the module, when errors occur @@ -126,14 +126,14 @@ Description: This control file allows this DIMM to have a label assigned What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_location Date: April 2012 -Contact: Mauro Carvalho Chehab +Contact: Mauro Carvalho Chehab linux-edac@vger.kernel.org Description: This attribute file will display the location (csrow/channel, branch/channel/slot or channel/slot) of the dimm or rank. What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_mem_type Date: April 2012 -Contact: Mauro Carvalho Chehab +Contact: Mauro Carvalho Chehab linux-edac@vger.kernel.org Description: This attribute file will display what type of memory is currently on this csrow. Normally, either buffered or -- cgit v1.1 From 57d1617137dd61825a3a7cebf61015f58afce510 Mon Sep 17 00:00:00 2001 From: Eduardo Valentin Date: Fri, 7 Jun 2013 11:11:53 -0400 Subject: thermal: ti-soc-thermal: use standard GPIO DT bindings This change updates the ti-soc-thermal driver to use standard GPIO DT bindings to read the GPIO number associated to thermal shutdown IRQ, in case the device features it. Previously, the code was using a specific DT bindings. As now OMAP supports the standard way to model GPIOs, there is no point in having a ti specific binding. Cc: Zhang Rui Cc: Grant Likely Cc: Rob Herring Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Eduardo Valentin --- Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt index 1953b33..0c9222d 100644 --- a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt +++ b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt @@ -17,8 +17,9 @@ Required properties: - interrupts : this entry should indicate which interrupt line the talert signal is routed to; Specific: -- ti,tshut-gpio : this entry should be used to inform which GPIO -line the tshut signal is routed to; +- gpios : this entry should be used to inform which GPIO +line the tshut signal is routed to. The informed GPIO will +be treated as an IRQ; - regs : this entry must also be specified and it is specific to each bandgap version, because the mapping may change from soc to soc, apart of depending on available features. @@ -37,7 +38,7 @@ bandgap { 0x4a002378 0x18>; compatible = "ti,omap4460-bandgap"; interrupts = <0 126 4>; /* talert */ - ti,tshut-gpio = <86>; + gpios = <&gpio3 22 0>; /* tshut */ }; OMAP4470: @@ -47,7 +48,7 @@ bandgap { 0x4a002378 0x18>; compatible = "ti,omap4470-bandgap"; interrupts = <0 126 4>; /* talert */ - ti,tshut-gpio = <86>; + gpios = <&gpio3 22 0>; /* tshut */ }; OMAP5430: -- cgit v1.1 From 7e40c92019cef784fffbdfc51c6e731e7ee6ba10 Mon Sep 17 00:00:00 2001 From: Runzhen Wang Date: Fri, 28 Jun 2013 16:14:56 +0800 Subject: perf tools: fix a typo of a Power7 event name In the Power7 PMU guide: https://www.power.org/documentation/commonly-used-metrics-for-performance-analysis/ PM_BRU_MPRED is referred to as PM_BR_MPRED. It fixed the typo by changing the name of the event in kernel and documentation accordingly. This patch changes the ABI, there are some reasons I think it's ok: - It is relatively new interface, specific to the Power7 platform. - No tools that we know of actually use this interface at this point (none are listed near the interface). - Users of this interface (eg oprofile users migrating to perf) would be more used to the "PM_BR_MPRED" rather than "PM_BRU_MPRED". - These are in the ABI/testing at this point rather than ABI/stable, so hoping we have some wiggle room. Signed-off-by: Runzhen Wang Acked-by: Michael Ellerman Cc: icycoder@gmail.com Cc: linuxppc-dev@lists.ozlabs.org Cc: Michael Ellerman Cc: Paul Mackerras Cc: Runzhen Wang Cc: Sukadev Bhattiprolu Cc: Xiao Guangrong Link: http://lkml.kernel.org/r/1372407297-6996-2-git-send-email-runzhen@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo --- Documentation/ABI/testing/sysfs-bus-event_source-devices-events | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events index 8b25ffb..3c1cc24 100644 --- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events @@ -29,7 +29,7 @@ Description: Generic performance monitoring events What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL /sys/devices/cpu/events/PM_BRU_FIN - /sys/devices/cpu/events/PM_BRU_MPRED + /sys/devices/cpu/events/PM_BR_MPRED /sys/devices/cpu/events/PM_CMPLU_STALL /sys/devices/cpu/events/PM_CMPLU_STALL_BRU /sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS -- cgit v1.1 From cbf55001b2ddb814329735641be5d29b08c82b08 Mon Sep 17 00:00:00 2001 From: Eliezer Tamir Date: Mon, 8 Jul 2013 16:20:34 +0300 Subject: net: rename low latency sockets functions to busy poll Rename functions in include/net/ll_poll.h to busy wait. Clarify documentation about expected power use increase. Rename POLL_LL to POLL_BUSY_LOOP. Add need_resched() testing to poll/select busy loops. Note, that in select and poll can_busy_poll is dynamic and is updated continuously to reflect the existence of supported sockets with valid queue information. Signed-off-by: Eliezer Tamir Signed-off-by: David S. Miller --- Documentation/sysctl/net.txt | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index e658bbf..7323b88 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -53,22 +53,24 @@ Default: 64 low_latency_read ---------------- Low latency busy poll timeout for socket reads. (needs CONFIG_NET_LL_RX_POLL) -Approximate time in us to spin waiting for packets on the device queue. +Approximate time in us to busy loop waiting for packets on the device queue. This sets the default value of the SO_LL socket option. -Can be set or overridden per socket by setting socket option SO_LL. -Recommended value is 50. May increase power usage. +Can be set or overridden per socket by setting socket option SO_LL, which is +the preferred method of enabling. +If you need to enable the feature globally via sysctl, a value of 50 is recommended. +Will increase power usage. Default: 0 (off) low_latency_poll ---------------- Low latency busy poll timeout for poll and select. (needs CONFIG_NET_LL_RX_POLL) -Approximate time in us to spin waiting for packets on the device queue. +Approximate time in us to busy loop waiting for events. Recommended value depends on the number of sockets you poll on. For several sockets 50, for several hundreds 100. For more than that you probably want to use epoll. Note that only sockets with SO_LL set will be busy polled, so you want to either selectively set SO_LL on those sockets or set sysctl.net.low_latency_read globally. -May increase power usage. +Will increase power usage. Default: 0 (off) rmem_default -- cgit v1.1 From f8f191f1addf0b31f188fd88e71e97200871c99c Mon Sep 17 00:00:00 2001 From: Wanpeng Li Date: Mon, 8 Jul 2013 16:00:16 -0700 Subject: mm/page_alloc: fix doc for numa_zonelist_order The default zonelist order selecter will select "node" order if any nodes DMA zone comprises greater than 70% of its local memory instead of 60%, according to default_zonelist_order::low_kmem_size > total * 70/100. Signed-off-by: Wanpeng Li Reviewed-by: Michal Hocko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/vm.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index dcc75a9..36ecc26 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -510,7 +510,7 @@ Specify "[Dd]efault" to request automatic configuration. Autoconfiguration will select "node" order in following case. (1) if the DMA zone does not exist or (2) if the DMA zone comprises greater than 50% of the available memory or -(3) if any node's DMA zone comprises greater than 60% of its local memory and +(3) if any node's DMA zone comprises greater than 70% of its local memory and the amount of local memory is big enough. Otherwise, "zone" order will be selected. Default order is recommended unless -- cgit v1.1 From f49cbdde495f62e1c2d906b16e833cec27de5e59 Mon Sep 17 00:00:00 2001 From: Wanpeng Li Date: Mon, 8 Jul 2013 16:00:16 -0700 Subject: mm/thp: fix doc for transparent huge zero page Transparent huge zero page is used during the page fault instead of in khugepaged. # ls /sys/kernel/mm/transparent_hugepage/ defrag enabled khugepaged use_zero_page # ls /sys/kernel/mm/transparent_hugepage/khugepaged/ alloc_sleep_millisecs defrag full_scans max_ptes_none pages_collapsed pages_to_scan scan_sleep_millisecs This patch corrects the documentation just like the codes done. Signed-off-by: Wanpeng Li Acked-by: Kirill A. Shutemov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/transhuge.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt index 8785fb8..4a63953 100644 --- a/Documentation/vm/transhuge.txt +++ b/Documentation/vm/transhuge.txt @@ -120,8 +120,8 @@ By default kernel tries to use huge zero page on read page fault. It's possible to disable huge zero page by writing 0 or enable it back by writing 1: -echo 0 >/sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page -echo 1 >/sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page +echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page +echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page khugepaged will be automatically started when transparent_hugepage/enabled is set to "always" or "madvise, and it'll -- cgit v1.1 From 1b3a5d02ee070c8f9943333b9b6370f486601e0f Mon Sep 17 00:00:00 2001 From: Robin Holt Date: Mon, 8 Jul 2013 16:01:42 -0700 Subject: reboot: move arch/x86 reboot= handling to generic kernel Merge together the unicore32, arm, and x86 reboot= command line parameter handling. Signed-off-by: Robin Holt Cc: H. Peter Anvin Cc: Russell King Cc: Guan Xuetao Cc: Russ Anderson Cc: Robin Holt Acked-by: Ingo Molnar Acked-by: Guan Xuetao Acked-by: Russell King Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 25dc4a0..75236f1 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2681,9 +2681,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Run specified binary instead of /init from the ramdisk, used for early userspace startup. See initrd. - reboot= [BUGS=X86-32,BUGS=ARM,BUGS=IA-64] Rebooting mode - Format: [,[,...]] - See arch/*/kernel/reboot.c or arch/*/kernel/process.c + reboot= [KNL] + Format (x86 or x86_64): + [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \ + [[,]s[mp]#### \ + [[,]b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]] \ + [[,]f[orce] + Where reboot_mode is one of warm (soft) or cold (hard) or gpio, + reboot_type is one of bios, acpi, kbd, triple, efi, or pci, + reboot_force is either force or not specified, + reboot_cpu is s[mp]#### with #### being the processor + to be used for rebooting. relax_domain_level= [KNL, SMP] Set scheduler's default relax_domain_level. -- cgit v1.1 From f9b493ac9b833fd9dd3bbd50460adb33f29e1238 Mon Sep 17 00:00:00 2001 From: Kyungsik Lee Date: Mon, 8 Jul 2013 16:01:48 -0700 Subject: arm: add support for LZ4-compressed kernel Integrates the LZ4 decompression code to the arm pre-boot code. Signed-off-by: Kyungsik Lee Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Russell King Cc: Borislav Petkov Cc: Florian Fainelli Cc: Yann Collet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/x86/boot.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt index 3840b6f..fc66d42 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt @@ -657,9 +657,10 @@ Protocol: 2.08+ uncompressed data should be determined using the standard magic numbers. The currently supported compression formats are gzip (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA - (magic number 5D 00), and XZ (magic number FD 37). The uncompressed - payload is currently always ELF (magic number 7F 45 4C 46). - + (magic number 5D 00), XZ (magic number FD 37), and LZ4 (magic number + 02 21). The uncompressed payload is currently always ELF (magic + number 7F 45 4C 46). + Field name: payload_length Type: read Offset/size: 0x24c/4 -- cgit v1.1 From b78ba72cda78314c11ac8f47617240bc8d0e89da Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Tue, 9 Jul 2013 10:22:31 +0200 Subject: Documentation: Fix references to defunct linux-net@vger.kernel.org linux-net@vger.kernel.org was replaced by netdev@oss.sgi.com was replaced by netdev@vger.kernel.org. Signed-off-by: Geert Uytterhoeven Signed-off-by: David S. Miller --- Documentation/networking/arcnet.txt | 7 ++++--- Documentation/networking/vortex.txt | 2 +- 2 files changed, 5 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/arcnet.txt b/Documentation/networking/arcnet.txt index 9ff5795..aff97f4 100644 --- a/Documentation/networking/arcnet.txt +++ b/Documentation/networking/arcnet.txt @@ -70,9 +70,10 @@ list, mail to linux-arcnet@tichy.ch.uj.edu.pl. There are archives of the mailing list at: http://epistolary.org/mailman/listinfo.cgi/arcnet -The people on linux-net@vger.kernel.org have also been known to be very -helpful, especially when we're talking about ALPHA Linux kernels that may or -may not work right in the first place. +The people on linux-net@vger.kernel.org (now defunct, replaced by +netdev@vger.kernel.org) have also been known to be very helpful, especially +when we're talking about ALPHA Linux kernels that may or may not work right +in the first place. Other Drivers and Info diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt index b4038ff..9a8041d 100644 --- a/Documentation/networking/vortex.txt +++ b/Documentation/networking/vortex.txt @@ -359,7 +359,7 @@ steps you should take: - OK, it's a driver problem. You need to generate a report. Typically this is an email to the - maintainer and/or linux-net@vger.kernel.org. The maintainer's + maintainer and/or netdev@vger.kernel.org. The maintainer's email address will be in the driver source or in the MAINTAINERS file. - The contents of your report will vary a lot depending upon the -- cgit v1.1 From a83f58bcb24003b9de2364de7c829a263423ead7 Mon Sep 17 00:00:00 2001 From: Helge Deller Date: Sat, 29 Jun 2013 13:24:16 +0200 Subject: parisc: document the shadow registers Signed-off-by: Helge Deller Cc: # 3.10 --- Documentation/parisc/registers | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/parisc/registers b/Documentation/parisc/registers index dd3cadd..10c7d17 100644 --- a/Documentation/parisc/registers +++ b/Documentation/parisc/registers @@ -78,6 +78,14 @@ Shadow Registers used by interruption handler code TOC enable bit 1 ========================================================================= + +The PA-RISC architecture defines 7 registers as "shadow registers". +Those are used in RETURN FROM INTERRUPTION AND RESTORE instruction to reduce +the state save and restore time by eliminating the need for general register +(GR) saves and restores in interruption handlers. +Shadow registers are the GRs 1, 8, 9, 16, 17, 24, and 25. + +========================================================================= Register usage notes, originally from John Marvin, with some additional notes from Randolph Chung. -- cgit v1.1 From 3e5b7d8b491c3710b7e007eab0a643f923932e3d Mon Sep 17 00:00:00 2001 From: Dave Chinner Date: Wed, 10 Jul 2013 07:03:59 +1000 Subject: xfs: update mount options documentation Because it's horribly out of date. And mark various deprecated options as deprecated and give them a removal date. Signed-off-by: Dave Chinner Reviewed-by: Mark Tinguely Signed-off-by: Ben Myers --- Documentation/filesystems/xfs.txt | 317 +++++++++++++++++++++++++------------- 1 file changed, 209 insertions(+), 108 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 83577f0..12525b1 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt @@ -18,6 +18,8 @@ Mount Options ============= When mounting an XFS filesystem, the following options are accepted. +For boolean mount options, the names with the (*) suffix is the +default behaviour. allocsize=size Sets the buffered I/O end-of-file preallocation size when @@ -25,97 +27,128 @@ When mounting an XFS filesystem, the following options are accepted. Valid values for this option are page size (typically 4KiB) through to 1GiB, inclusive, in power-of-2 increments. - attr2/noattr2 - The options enable/disable (default is disabled for backward - compatibility on-disk) an "opportunistic" improvement to be - made in the way inline extended attributes are stored on-disk. - When the new form is used for the first time (by setting or - removing extended attributes) the on-disk superblock feature - bit field will be updated to reflect this format being in use. + The default behaviour is for dynamic end-of-file + preallocation size, which uses a set of heuristics to + optimise the preallocation size based on the current + allocation patterns within the file and the access patterns + to the file. Specifying a fixed allocsize value turns off + the dynamic behaviour. + + attr2 + noattr2 + The options enable/disable an "opportunistic" improvement to + be made in the way inline extended attributes are stored + on-disk. When the new form is used for the first time when + attr2 is selected (either when setting or removing extended + attributes) the on-disk superblock feature bit field will be + updated to reflect this format being in use. + + The default behaviour is determined by the on-disk feature + bit indicating that attr2 behaviour is active. If either + mount option it set, then that becomes the new default used + by the filesystem. CRC enabled filesystems always use the attr2 format, and so will reject the noattr2 mount option if it is set. - barrier - Enables the use of block layer write barriers for writes into - the journal and unwritten extent conversion. This allows for - drive level write caching to be enabled, for devices that - support write barriers. + barrier (*) + nobarrier + Enables/disables the use of block layer write barriers for + writes into the journal and for data integrity operations. + This allows for drive level write caching to be enabled, for + devices that support write barriers. discard - Issue command to let the block device reclaim space freed by the - filesystem. This is useful for SSD devices, thinly provisioned - LUNs and virtual machine images, but may have a performance - impact. - - dmapi - Enable the DMAPI (Data Management API) event callouts. - Use with the "mtpt" option. - - grpid/bsdgroups and nogrpid/sysvgroups - These options define what group ID a newly created file gets. - When grpid is set, it takes the group ID of the directory in - which it is created; otherwise (the default) it takes the fsgid - of the current process, unless the directory has the setgid bit - set, in which case it takes the gid from the parent directory, - and also gets the setgid bit set if it is a directory itself. - - ihashsize=value - In memory inode hashes have been removed, so this option has - no function as of August 2007. Option is deprecated. - - ikeep/noikeep - When ikeep is specified, XFS does not delete empty inode clusters - and keeps them around on disk. ikeep is the traditional XFS - behaviour. When noikeep is specified, empty inode clusters - are returned to the free space pool. The default is noikeep for - non-DMAPI mounts, while ikeep is the default when DMAPI is in use. - - inode64 - Indicates that XFS is allowed to create inodes at any location - in the filesystem, including those which will result in inode - numbers occupying more than 32 bits of significance. This is - the default allocation option. Applications which do not handle - inode numbers bigger than 32 bits, should use inode32 option. + nodiscard (*) + Enable/disable the issuing of commands to let the block + device reclaim space freed by the filesystem. This is + useful for SSD devices, thinly provisioned LUNs and virtual + machine images, but may have a performance impact. + + Note: It is currently recommended that you use the fstrim + application to discard unused blocks rather than the discard + mount option because the performance impact of this option + is quite severe. + + grpid/bsdgroups + nogrpid/sysvgroups (*) + These options define what group ID a newly created file + gets. When grpid is set, it takes the group ID of the + directory in which it is created; otherwise it takes the + fsgid of the current process, unless the directory has the + setgid bit set, in which case it takes the gid from the + parent directory, and also gets the setgid bit set if it is + a directory itself. + + filestreams + Make the data allocator use the filestreams allocation mode + across the entire filesystem rather than just on directories + configured to use it. + + ikeep + noikeep (*) + When ikeep is specified, XFS does not delete empty inode + clusters and keeps them around on disk. When noikeep is + specified, empty inode clusters are returned to the free + space pool. inode32 - Indicates that XFS is limited to create inodes at locations which - will not result in inode numbers with more than 32 bits of - significance. This is provided for backwards compatibility, since - 64 bits inode numbers might cause problems for some applications - that cannot handle large inode numbers. - - largeio/nolargeio + inode64 (*) + When inode32 is specified, it indicates that XFS limits + inode creation to locations which will not result in inode + numbers with more than 32 bits of significance. + + When inode64 is specified, it indicates that XFS is allowed + to create inodes at any location in the filesystem, + including those which will result in inode numbers occupying + more than 32 bits of significance. + + inode32 is provided for backwards compatibility with older + systems and applications, since 64 bits inode numbers might + cause problems for some applications that cannot handle + large inode numbers. If applications are in use which do + not handle inode numbers bigger than 32 bits, the inode32 + option should be specified. + + + largeio + nolargeio (*) If "nolargeio" is specified, the optimal I/O reported in - st_blksize by stat(2) will be as small as possible to allow user - applications to avoid inefficient read/modify/write I/O. - If "largeio" specified, a filesystem that has a "swidth" specified - will return the "swidth" value (in bytes) in st_blksize. If the - filesystem does not have a "swidth" specified but does specify - an "allocsize" then "allocsize" (in bytes) will be returned - instead. - If neither of these two options are specified, then filesystem - will behave as if "nolargeio" was specified. + st_blksize by stat(2) will be as small as possible to allow + user applications to avoid inefficient read/modify/write + I/O. This is typically the page size of the machine, as + this is the granularity of the page cache. + + If "largeio" specified, a filesystem that was created with a + "swidth" specified will return the "swidth" value (in bytes) + in st_blksize. If the filesystem does not have a "swidth" + specified but does specify an "allocsize" then "allocsize" + (in bytes) will be returned instead. Otherwise the behaviour + is the same as if "nolargeio" was specified. logbufs=value - Set the number of in-memory log buffers. Valid numbers range - from 2-8 inclusive. - The default value is 8 buffers for filesystems with a - blocksize of 64KiB, 4 buffers for filesystems with a blocksize - of 32KiB, 3 buffers for filesystems with a blocksize of 16KiB - and 2 buffers for all other configurations. Increasing the - number of buffers may increase performance on some workloads - at the cost of the memory used for the additional log buffers - and their associated control structures. + Set the number of in-memory log buffers. Valid numbers + range from 2-8 inclusive. + + The default value is 8 buffers. + + If the memory cost of 8 log buffers is too high on small + systems, then it may be reduced at some cost to performance + on metadata intensive workloads. The logbsize option below + controls the size of each buffer and so is also relevent to + this case. logbsize=value - Set the size of each in-memory log buffer. - Size may be specified in bytes, or in kilobytes with a "k" suffix. - Valid sizes for version 1 and version 2 logs are 16384 (16k) and - 32768 (32k). Valid sizes for version 2 logs also include - 65536 (64k), 131072 (128k) and 262144 (256k). - The default value for machines with more than 32MiB of memory - is 32768, machines with less memory use 16384 by default. + Set the size of each in-memory log buffer. The size may be + specified in bytes, or in kilobytes with a "k" suffix. + Valid sizes for version 1 and version 2 logs are 16384 (16k) + and 32768 (32k). Valid sizes for version 2 logs also + include 65536 (64k), 131072 (128k) and 262144 (256k). The + logbsize must be an integer multiple of the log + stripe unit configured at mkfs time. + + The default value for for version 1 logs is 32768, while the + default value for version 2 logs is MAX(32768, log_sunit). logdev=device and rtdev=device Use an external log (metadata journal) and/or real-time device. @@ -124,16 +157,11 @@ When mounting an XFS filesystem, the following options are accepted. optional, and the log section can be separate from the data section or contained within it. - mtpt=mountpoint - Use with the "dmapi" option. The value specified here will be - included in the DMAPI mount event, and should be the path of - the actual mountpoint that is used. - noalign - Data allocations will not be aligned at stripe unit boundaries. - - noatime - Access timestamps are not updated when a file is read. + Data allocations will not be aligned at stripe unit + boundaries. This is only relevant to filesystems created + with non-zero data alignment parameters (sunit, swidth) by + mkfs. norecovery The filesystem will be mounted without running log recovery. @@ -144,8 +172,14 @@ When mounting an XFS filesystem, the following options are accepted. the mount will fail. nouuid - Don't check for double mounted file systems using the file system uuid. - This is useful to mount LVM snapshot volumes. + Don't check for double mounted file systems using the file + system uuid. This is useful to mount LVM snapshot volumes, + and often used in combination with "norecovery" for mounting + read-only snapshots. + + noquota + Forcibly turns off all quota accounting and enforcement + within the filesystem. uquota/usrquota/uqnoenforce/quota User disk quota accounting enabled, and limits (optionally) @@ -160,24 +194,64 @@ When mounting an XFS filesystem, the following options are accepted. enforced. Refer to xfs_quota(8) for further details. sunit=value and swidth=value - Used to specify the stripe unit and width for a RAID device or - a stripe volume. "value" must be specified in 512-byte block - units. - If this option is not specified and the filesystem was made on - a stripe volume or the stripe width or unit were specified for - the RAID device at mkfs time, then the mount system call will - restore the value from the superblock. For filesystems that - are made directly on RAID devices, these options can be used - to override the information in the superblock if the underlying - disk layout changes after the filesystem has been created. - The "swidth" option is required if the "sunit" option has been - specified, and must be a multiple of the "sunit" value. + Used to specify the stripe unit and width for a RAID device + or a stripe volume. "value" must be specified in 512-byte + block units. These options are only relevant to filesystems + that were created with non-zero data alignment parameters. + + The sunit and swidth parameters specified must be compatible + with the existing filesystem alignment characteristics. In + general, that means the only valid changes to sunit are + increasing it by a power-of-2 multiple. Valid swidth values + are any integer multiple of a valid sunit value. + + Typically the only time these mount options are necessary if + after an underlying RAID device has had it's geometry + modified, such as adding a new disk to a RAID5 lun and + reshaping it. swalloc Data allocations will be rounded up to stripe width boundaries when the current end of file is being extended and the file size is larger than the stripe width size. + wsync + When specified, all filesystem namespace operations are + executed synchronously. This ensures that when the namespace + operation (create, unlink, etc) completes, the change to the + namespace is on stable storage. This is useful in HA setups + where failover must not result in clients seeing + inconsistent namespace presentation during or after a + failover event. + + +Deprecated Mount Options +======================== + + delaylog/nodelaylog + Delayed logging is the only logging method that XFS supports + now, so these mount options are now ignored. + + Due for removal in 3.12. + + ihashsize=value + In memory inode hashes have been removed, so this option has + no function as of August 2007. Option is deprecated. + + Due for removal in 3.12. + + irixsgid + This behaviour is now controlled by a sysctl, so the mount + option is ignored. + + Due for removal in 3.12. + + osyncisdsync + osyncisosync + O_SYNC and O_DSYNC are fully supported, so there is no need + for these options any more. + + Due for removal in 3.12. sysctls ======= @@ -189,15 +263,20 @@ The following sysctls are available for the XFS filesystem: in /proc/fs/xfs/stat. It then immediately resets to "0". fs.xfs.xfssyncd_centisecs (Min: 100 Default: 3000 Max: 720000) - The interval at which the xfssyncd thread flushes metadata - out to disk. This thread will flush log activity out, and - do some processing on unlinked inodes. + The interval at which the filesystem flushes metadata + out to disk and runs internal cache cleanup routines. - fs.xfs.xfsbufd_centisecs (Min: 50 Default: 100 Max: 3000) - The interval at which xfsbufd scans the dirty metadata buffers list. + fs.xfs.filestream_centisecs (Min: 1 Default: 3000 Max: 360000) + The interval at which the filesystem ages filestreams cache + references and returns timed-out AGs back to the free stream + pool. - fs.xfs.age_buffer_centisecs (Min: 100 Default: 1500 Max: 720000) - The age at which xfsbufd flushes dirty metadata buffers to disk. + fs.xfs.speculative_prealloc_lifetime + (Units: seconds Min: 1 Default: 300 Max: 86400) + The interval at which the background scanning for inodes + with unused speculative preallocation runs. The scan + removes unused preallocation from clean inodes and releases + the unused space back to the free pool. fs.xfs.error_level (Min: 0 Default: 3 Max: 11) A volume knob for error reporting when internal errors occur. @@ -254,9 +333,31 @@ The following sysctls are available for the XFS filesystem: by the xfs_io(8) chattr command on a directory to be inherited by files in that directory. + fs.xfs.inherit_nodefrag (Min: 0 Default: 1 Max: 1) + Setting this to "1" will cause the "nodefrag" flag set + by the xfs_io(8) chattr command on a directory to be + inherited by files in that directory. + fs.xfs.rotorstep (Min: 1 Default: 1 Max: 256) In "inode32" allocation mode, this option determines how many files the allocator attempts to allocate in the same allocation group before moving to the next allocation group. The intent is to control the rate at which the allocator moves between allocation groups when allocating extents for new files. + +Deprecated Sysctls +================== + + fs.xfs.xfsbufd_centisecs (Min: 50 Default: 100 Max: 3000) + Dirty metadata is now tracked by the log subsystem and + flushing is driven by log space and idling demands. The + xfsbufd no longer exists, so this syctl does nothing. + + Due for removal in 3.14. + + fs.xfs.age_buffer_centisecs (Min: 100 Default: 1500 Max: 720000) + Dirty metadata is now tracked by the log subsystem and + flushing is driven by log space and idling demands. The + xfsbufd no longer exists, so this syctl does nothing. + + Due for removal in 3.14. -- cgit v1.1 From 34a956db3774e8cba3f6b52aa9c1d67cf9a496fe Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Tue, 2 Jul 2013 18:41:03 -0400 Subject: Add support driver for Intel Rapid Start Technology Intel Rapid Start Technology is a firmware-based suspend-to-disk implementation. Once placed in S3, the device will wake once either a timeout elapses or the battery reaches a critical level. It will then resume to the firmware and copy the contents of RAM to a specialised partition, and then power off the machine. If the user turns the machine back on the firmware will copy the contents of the partition back to RAM and then resume from S3 as normal. This driver provides an interface for configuring the wakeup events and timeout. It still requires firmware support and an appropriate suspend partition. Signed-off-by: Matthew Garrett Signed-off-by: Matthew Garrett --- .../ABI/testing/sysfs-driver-intel-rapid-start | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-rapid-start (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-intel-rapid-start b/Documentation/ABI/testing/sysfs-driver-intel-rapid-start new file mode 100644 index 0000000..5a7d2e2 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-intel-rapid-start @@ -0,0 +1,21 @@ +What: /sys/bus/acpi/intel-rapid-start/wakeup_events +Date: July 2, 2013 +KernelVersion: 3.11 +Contact: Matthew Garrett +Description: An integer representing a set of wakeup events as follows: + 1: Wake to enter hibernation when the wakeup timer expires + 2: Wake to enter hibernation when the battery reaches a + critical level + + These values are ORed together. For example, a value of 3 + indicates that the system will wake to enter hibernation when + either the wakeup timer expires or the battery reaches a + critical level. + +What: /sys/bus/acpi/intel-rapid-start/wakeup_time +Date: July 2, 2013 +KernelVersion: 3.11 +Contact: Matthew Garrett +Description: An integer representing the length of time the system will + remain asleep before waking up to enter hibernation. + This value is in minutes. -- cgit v1.1 From 9d0eb0ab432aaa9160cf2675aee73b3900b9bc18 Mon Sep 17 00:00:00 2001 From: Jim Ramsay Date: Wed, 10 Jul 2013 23:41:19 +0100 Subject: dm: add switch target dm-switch is a new target that maps IO to underlying block devices efficiently when there is a large number of fixed-sized address regions but there is no simple pattern to allow for a compact mapping representation such as dm-stripe. Though we have developed this target for a specific storage device, Dell EqualLogic, we have made an effort to keep it as general purpose as possible in the hope that others may benefit. Originally developed by Jim Ramsay. Simplified by Mikulas Patocka. Signed-off-by: Jim Ramsay Signed-off-by: Mikulas Patocka Signed-off-by: Alasdair G Kergon --- Documentation/device-mapper/switch.txt | 126 +++++++++++++++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 Documentation/device-mapper/switch.txt (limited to 'Documentation') diff --git a/Documentation/device-mapper/switch.txt b/Documentation/device-mapper/switch.txt new file mode 100644 index 0000000..2fa7493 --- /dev/null +++ b/Documentation/device-mapper/switch.txt @@ -0,0 +1,126 @@ +dm-switch +========= + +The device-mapper switch target creates a device that supports an +arbitrary mapping of fixed-size regions of I/O across a fixed set of +paths. The path used for any specific region can be switched +dynamically by sending the target a message. + +It maps I/O to underlying block devices efficiently when there is a large +number of fixed-sized address regions but there is no simple pattern +that would allow for a compact representation of the mapping such as +dm-stripe. + +Background +---------- + +Dell EqualLogic and some other iSCSI storage arrays use a distributed +frameless architecture. In this architecture, the storage group +consists of a number of distinct storage arrays ("members") each having +independent controllers, disk storage and network adapters. When a LUN +is created it is spread across multiple members. The details of the +spreading are hidden from initiators connected to this storage system. +The storage group exposes a single target discovery portal, no matter +how many members are being used. When iSCSI sessions are created, each +session is connected to an eth port on a single member. Data to a LUN +can be sent on any iSCSI session, and if the blocks being accessed are +stored on another member the I/O will be forwarded as required. This +forwarding is invisible to the initiator. The storage layout is also +dynamic, and the blocks stored on disk may be moved from member to +member as needed to balance the load. + +This architecture simplifies the management and configuration of both +the storage group and initiators. In a multipathing configuration, it +is possible to set up multiple iSCSI sessions to use multiple network +interfaces on both the host and target to take advantage of the +increased network bandwidth. An initiator could use a simple round +robin algorithm to send I/O across all paths and let the storage array +members forward it as necessary, but there is a performance advantage to +sending data directly to the correct member. + +A device-mapper table already lets you map different regions of a +device onto different targets. However in this architecture the LUN is +spread with an address region size on the order of 10s of MBs, which +means the resulting table could have more than a million entries and +consume far too much memory. + +Using this device-mapper switch target we can now build a two-layer +device hierarchy: + + Upper Tier – Determine which array member the I/O should be sent to. + Lower Tier – Load balance amongst paths to a particular member. + +The lower tier consists of a single dm multipath device for each member. +Each of these multipath devices contains the set of paths directly to +the array member in one priority group, and leverages existing path +selectors to load balance amongst these paths. We also build a +non-preferred priority group containing paths to other array members for +failover reasons. + +The upper tier consists of a single dm-switch device. This device uses +a bitmap to look up the location of the I/O and choose the appropriate +lower tier device to route the I/O. By using a bitmap we are able to +use 4 bits for each address range in a 16 member group (which is very +large for us). This is a much denser representation than the dm table +b-tree can achieve. + +Construction Parameters +======================= + + [...] + [ ]+ + + + The number of paths across which to distribute the I/O. + + + The number of 512-byte sectors in a region. Each region can be redirected + to any of the available paths. + + + The number of optional arguments. Currently, no optional arguments + are supported and so this must be zero. + + + The block device that represents a specific path to the device. + + + The offset of the start of data on the specific (in units + of 512-byte sectors). This number is added to the sector number when + forwarding the request to the specific path. Typically it is zero. + +Messages +======== + +set_region_mappings : []: []:... + +Modify the region table by specifying which regions are redirected to +which paths. + + + The region number (region size was specified in constructor parameters). + If index is omitted, the next region (previous index + 1) is used. + Expressed in hexadecimal (WITHOUT any prefix like 0x). + + + The path number in the range 0 ... ( - 1). + Expressed in hexadecimal (WITHOUT any prefix like 0x). + +Status +====== + +No status line is reported. + +Example +======= + +Assume that you have volumes vg1/switch0 vg1/switch1 vg1/switch2 with +the same size. + +Create a switch device with 64kB region size: + dmsetup create switch --table "0 `blockdev --getsize /dev/vg1/switch0` + switch 3 128 0 /dev/vg1/switch0 0 /dev/vg1/switch1 0 /dev/vg1/switch2 0" + +Set mappings for the first 7 entries to point to devices switch0, switch1, +switch2, switch0, switch1, switch2, switch1: + dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1 -- cgit v1.1 From 64b0dc517ea1b35d02565a779e6cb77ae9045685 Mon Sep 17 00:00:00 2001 From: Eliezer Tamir Date: Wed, 10 Jul 2013 17:13:36 +0300 Subject: net: rename busy poll socket op and globals Rename LL_SO to BUSY_POLL_SO Rename sysctl_net_ll_{read,poll} to sysctl_busy_{read,poll} Fix up users of these variables. Fix documentation for sysctl. a patch for the socket.7 man page will follow separately, because of limitations of my mail setup. Signed-off-by: Eliezer Tamir Signed-off-by: David S. Miller --- Documentation/sysctl/net.txt | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index d69e14c..1c15043 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -50,26 +50,27 @@ The maximum number of packets that kernel can handle on a NAPI interrupt, it's a Per-CPU variable. Default: 64 -low_latency_read +busy_read ---------------- Low latency busy poll timeout for socket reads. (needs CONFIG_NET_LL_RX_POLL) Approximate time in us to busy loop waiting for packets on the device queue. -This sets the default value of the SO_LL socket option. -Can be set or overridden per socket by setting socket option SO_LL, which is -the preferred method of enabling. -If you need to enable the feature globally via sysctl, a value of 50 is recommended. +This sets the default value of the SO_BUSY_POLL socket option. +Can be set or overridden per socket by setting socket option SO_BUSY_POLL, +which is the preferred method of enabling. If you need to enable the feature +globally via sysctl, a value of 50 is recommended. Will increase power usage. Default: 0 (off) -low_latency_poll +busy_poll ---------------- Low latency busy poll timeout for poll and select. (needs CONFIG_NET_LL_RX_POLL) Approximate time in us to busy loop waiting for events. Recommended value depends on the number of sockets you poll on. For several sockets 50, for several hundreds 100. For more than that you probably want to use epoll. -Note that only sockets with SO_LL set will be busy polled, so you want to either -selectively set SO_LL on those sockets or set sysctl.net.low_latency_read globally. +Note that only sockets with SO_BUSY_POLL set will be busy polled, +so you want to either selectively set SO_BUSY_POLL on those sockets or set +sysctl.net.busy_read globally. Will increase power usage. Default: 0 (off) -- cgit v1.1 From 61b0d76017a50c263c303fa263b295b04e0c68f6 Mon Sep 17 00:00:00 2001 From: Seth Jennings Date: Wed, 10 Jul 2013 16:05:05 -0700 Subject: zswap: add documentation Add the documentation file for the zswap functionality Signed-off-by: Seth Jennings Acked-by: Rik van Riel Cc: Greg Kroah-Hartman Cc: Nitin Gupta Cc: Minchan Kim Cc: Konrad Rzeszutek Wilk Cc: Dan Magenheimer Cc: Robert Jennings Cc: Jenifer Hopper Cc: Mel Gorman Cc: Johannes Weiner Cc: Larry Woodman Cc: Benjamin Herrenschmidt Cc: Dave Hansen Cc: Joe Perches Cc: Joonsoo Kim Cc: Cody P Schafer Cc: Hugh Dickens Cc: Paul Mackerras Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/zswap.txt | 68 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 Documentation/vm/zswap.txt (limited to 'Documentation') diff --git a/Documentation/vm/zswap.txt b/Documentation/vm/zswap.txt new file mode 100644 index 0000000..7e492d8 --- /dev/null +++ b/Documentation/vm/zswap.txt @@ -0,0 +1,68 @@ +Overview: + +Zswap is a lightweight compressed cache for swap pages. It takes pages that are +in the process of being swapped out and attempts to compress them into a +dynamically allocated RAM-based memory pool. zswap basically trades CPU cycles +for potentially reduced swap I/O.  This trade-off can also result in a +significant performance improvement if reads from the compressed cache are +faster than reads from a swap device. + +NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memory +reclaim. This interaction has not be fully explored on the large set of +potential configurations and workloads that exist. For this reason, zswap +is a work in progress and should be considered experimental. + +Some potential benefits: +* Desktop/laptop users with limited RAM capacities can mitigate the +    performance impact of swapping. +* Overcommitted guests that share a common I/O resource can +    dramatically reduce their swap I/O pressure, avoiding heavy handed I/O + throttling by the hypervisor. This allows more work to get done with less + impact to the guest workload and guests sharing the I/O subsystem +* Users with SSDs as swap devices can extend the life of the device by +    drastically reducing life-shortening writes. + +Zswap evicts pages from compressed cache on an LRU basis to the backing swap +device when the compressed pool reaches it size limit. This requirement had +been identified in prior community discussions. + +To enabled zswap, the "enabled" attribute must be set to 1 at boot time. e.g. +zswap.enabled=1 + +Design: + +Zswap receives pages for compression through the Frontswap API and is able to +evict pages from its own compressed pool on an LRU basis and write them back to +the backing swap device in the case that the compressed pool is full. + +Zswap makes use of zbud for the managing the compressed memory pool. Each +allocation in zbud is not directly accessible by address. Rather, a handle is +return by the allocation routine and that handle must be mapped before being +accessed. The compressed memory pool grows on demand and shrinks as compressed +pages are freed. The pool is not preallocated. + +When a swap page is passed from frontswap to zswap, zswap maintains a mapping +of the swap entry, a combination of the swap type and swap offset, to the zbud +handle that references that compressed swap page. This mapping is achieved +with a red-black tree per swap type. The swap offset is the search key for the +tree nodes. + +During a page fault on a PTE that is a swap entry, frontswap calls the zswap +load function to decompress the page into the page allocated by the page fault +handler. + +Once there are no PTEs referencing a swap page stored in zswap (i.e. the count +in the swap_map goes to 0) the swap code calls the zswap invalidate function, +via frontswap, to free the compressed entry. + +Zswap seeks to be simple in its policies. Sysfs attributes allow for one user +controlled policies: +* max_pool_percent - The maximum percentage of memory that the compressed + pool can occupy. + +Zswap allows the compressor to be selected at kernel boot time by setting the +“compressor” attribute. The default compressor is lzo. e.g. +zswap.compressor=deflate + +A debugfs interface is provided for various statistic about pool size, number +of pages stored, and various counters for the reasons pages are rejected. -- cgit v1.1 From 6e63a3a294fdf91eaaac1061a9c7a5f53d16ac25 Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Wed, 19 Jun 2013 20:38:58 +0530 Subject: watchdog: delete mpcore_wdt driver Interrupt request doesn't use the right API: The TWD watchdog uses a per-cpu interrupt (usually interrupt #30), and the GIC configuration should flag it as such. With this setup, request_irq() should fail, and the right API is request_percpu_irq(), together with enable_percpu_irq()/disable_percpu_irq(). Nothing ensures the userspace ioctl() will end-up kicking the watchdog on the right CPU. There are no users of this driver since a long time and it makes more sense to get rid of it as nobody is looking to fix it. In case somebody wakes up after this has been removed and needs it, please revert this driver and pick these updates (These were never pushed to mainline): http://comments.gmane.org/gmane.linux.ports.arm.kernel/245998 Signed-off-by: Viresh Kumar Acked-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck --- Documentation/watchdog/watchdog-parameters.txt | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt index 04fddbac..f9492fe 100644 --- a/Documentation/watchdog/watchdog-parameters.txt +++ b/Documentation/watchdog/watchdog-parameters.txt @@ -194,14 +194,6 @@ reset: Watchdog Interrupt/Reset Mode. 0 = interrupt, 1 = reset nowayout: Watchdog cannot be stopped once started (default=kernel config parameter) ------------------------------------------------- -mpcore_wdt: -mpcore_margin: MPcore timer margin in seconds. - (0 < mpcore_margin < 65536, default=60) -nowayout: Watchdog cannot be stopped once started - (default=kernel config parameter) -mpcore_noboot: MPcore watchdog action, set to 1 to ignore reboots, - 0 to reboot (default=0 -------------------------------------------------- mv64x60_wdt: nowayout: Watchdog cannot be stopped once started (default=kernel config parameter) -- cgit v1.1 From 938d0a840d0f97b627111fd038a735f3924fd987 Mon Sep 17 00:00:00 2001 From: Lubomir Rintel Date: Tue, 18 Jun 2013 19:44:48 +0200 Subject: watchdog: Add Broadcom BCM2835 watchdog timer driver This adds a driver for watchdog timer hardware present on Broadcom BCM2835 SoC, used in Raspberry Pi and Roku 2 devices. Signed-off-by: Lubomir Rintel Tested-by: Stephen Warren Reviewed-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Cc: linux-rpi-kernel@lists.infradead.org Cc: linux-watchdog@vger.kernel.org Cc: devicetree-discuss@lists.ozlabs.org --- Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt index d209366..f801d71 100644 --- a/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt @@ -5,9 +5,14 @@ Required properties: - compatible : should be "brcm,bcm2835-pm-wdt" - reg : Specifies base physical address and size of the registers. +Optional properties: + +- timeout-sec : Contains the watchdog timeout in seconds + Example: watchdog { compatible = "brcm,bcm2835-pm-wdt"; reg = <0x7e100000 0x28>; + timeout-sec = <10>; }; -- cgit v1.1 From 26c57ef1ea35f2e7b73db5fad3c81c388d6d056a Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn Date: Tue, 18 Jun 2013 17:19:45 +0200 Subject: watchdog: New watchdog driver for MEN A21 watchdogs This patch adds the driver for the watchdog devices found on MEN Mikro Elektronik A21 VMEbus CPU Carrier Boards. It has DT-support and uses the watchdog framework. Signed-off-by: Johannes Thumshirn Reviewed-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck --- .../devicetree/bindings/gpio/men-a021-wdt.txt | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/men-a021-wdt.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/men-a021-wdt.txt b/Documentation/devicetree/bindings/gpio/men-a021-wdt.txt new file mode 100644 index 0000000..370dee3 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/men-a021-wdt.txt @@ -0,0 +1,25 @@ +Bindings for MEN A21 Watchdog device connected to GPIO lines + +Required properties: +- compatible: "men,a021-wdt" +- gpios: Specifies the pins that control the Watchdog, order: + 1: Watchdog enable + 2: Watchdog fast-mode + 3: Watchdog trigger + 4: Watchdog reset cause bit 0 + 5: Watchdog reset cause bit 1 + 6: Watchdog reset cause bit 2 + +Optional properties: +- None + +Example: + watchdog { + compatible ="men,a021-wdt"; + gpios = <&gpio3 9 1 /* WD_EN */ + &gpio3 10 1 /* WD_FAST */ + &gpio3 11 1 /* WD_TRIG */ + &gpio3 6 1 /* RST_CAUSE[0] */ + &gpio3 7 1 /* RST_CAUSE[1] */ + &gpio3 8 1>; /* RST_CAUSE[2] */ + }; -- cgit v1.1 From 0db0628d90125193280eabb501c94feaf48fa9ab Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Wed, 19 Jun 2013 14:53:51 -0400 Subject: kernel: delete __cpuinit usage from all core kernel files The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. This removes all the uses of the __cpuinit macros from C files in the core kernel directories (kernel, init, lib, mm, and include) that don't really have a specific maintainer. [1] https://lkml.org/lkml/2013/5/20/589 Signed-off-by: Paul Gortmaker --- Documentation/cpu-hotplug.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index edd4b4d..786dc82 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -267,8 +267,8 @@ Q: If i have some kernel code that needs to be aware of CPU arrival and A: This is what you would need in your kernel code to receive notifications. #include - static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb, - unsigned long action, void *hcpu) + static int foobar_cpu_callback(struct notifier_block *nfb, + unsigned long action, void *hcpu) { unsigned int cpu = (unsigned long)hcpu; @@ -285,7 +285,7 @@ A: This is what you would need in your kernel code to receive notifications. return NOTIFY_OK; } - static struct notifier_block __cpuinitdata foobar_cpu_notifer = + static struct notifier_block foobar_cpu_notifer = { .notifier_call = foobar_cpu_callback, }; -- cgit v1.1 From 7d4ddbaa1466f0c06bbca8ad702f4f4b313b8f33 Mon Sep 17 00:00:00 2001 From: Gabor Juhos Date: Wed, 1 May 2013 10:53:54 +0200 Subject: of: add vendor prefix for Qualcomm Atheros, Inc. This prefix will be used in various compatible properties for the devices from Qualcomm Atheros, Inc. Cc: Luis R. Rodriguez Signed-off-by: Gabor Juhos Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index d5a79ca..1e4aa2e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -43,6 +43,7 @@ nxp NXP Semiconductors onnn ON Semiconductor Corp. picochip Picochip Ltd powervr PowerVR (deprecated, use img) +qca Qualcomm Atheros, Inc. qcom Qualcomm, Inc. ralink Mediatek/Ralink Technology Corp. ramtron Ramtron International -- cgit v1.1 From cfd1ee3e37360ac6ec8c737e63e70c5d583f1e51 Mon Sep 17 00:00:00 2001 From: Zhangfei Gao Date: Mon, 17 Jun 2013 13:04:59 +0800 Subject: of: add vendor prefixes for hisilicon Signed-off-by: Zhangfei Gao Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1e4aa2e..366ce9b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -26,6 +26,7 @@ est ESTeem Wireless Modems fsl Freescale Semiconductor GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. +hisilicon Hisilicon Limited. hp Hewlett Packard ibm International Business Machines (IBM) idt Integrated Device Technologies, Inc. -- cgit v1.1